Historia de las distribuciones Linux y sus familias

Qué es realmente una distribución de Linux

La historia de las distribuciones de Linux empieza con una carencia: el kernel de Linux por sí solo no hace nada que una persona pueda utilizar. Arranca y detecta el hardware. Después se detiene. Alguien tiene que añadir un userland, decidir cómo se instala y actualiza el software y comprometerse a corregirlo durante años. Una distribución es ese conjunto de decisiones, además del grupo de personas que permanece después.

Tiene cinco partes. Cambie cualquiera de ellas y obtendrá una distribución distinta, aunque la mayoría de los binarios coincidan:

• Un kernel, en la versión elegida por el proyecto, con los parches y controladores que haya añadido.
• Un userland: la biblioteca de C, el shell, el sistema init y los comandos estándar.
• Un formato de paquetes y la herramienta que los instala.
• Una política de versiones: qué puede cambiar, con qué frecuencia y durante cuánto tiempo se corrige cada versión.
• Personas: mantenedores de paquetes, un equipo de seguridad y alguien que responda cuando un paquete falla.

El kernel es la parte compartida, por lo que dos distribuciones de Linux están mucho más cerca entre sí que cualquiera de ellas de otro Unix. Conviene tenerlo presente al comparar Linux y FreeBSD como plataformas de servidor, donde un solo proyecto desarrolla el kernel y el userland base, y los publica juntos. En Linux, esas piezas proceden de proyectos upstream independientes, y la distribución es la que hace que funcionen de forma coherente.

Historia de las distribuciones de Linux en tres familias

Tres proyectos iniciados en 1993 y 1994 se convirtieron en familias: Slackware, Debian y Red Hat. Actualmente, casi todas las imágenes de un panel de control de VPS pertenecen a una de ellas o derivan de una de ellas. Un derivado hereda el formato de paquetes, la estructura de archivos y, por lo general, las prácticas de publicación de versiones. Por eso, una distribución derivada de Debian sigue comportándose como Debian aunque se elimine la identidad de marca.

Las distribuciones independientes merecen su propio apartado porque no derivaron de ningún otro proyecto. Arch, Gentoo, Alpine, NixOS y Void desarrollaron su propio gestor de paquetes y sus propias reglas. Dos de ellas, Arch y Alpine, acabaron apareciendo en la lista de imágenes de su proveedor por motivos que no tenían relación con el entorno de escritorio.

1992: las distribuciones anteriores a las familias

MCC Interim Linux apareció en febrero de 1992, ensamblado por Owen Le Blanc en el Manchester Computing Centre. Incluía el kernel y las herramientas de GNU (GNU's not Unix) en un par de imágenes de disquete, con un instalador basado en menús. Existía porque hacerlo manualmente requería un día de trabajo.

SLS (Softlanding Linux System), publicada por Peter MacDonald en 1992, fue más allá e incorporó X (the X Window System) y redes TCP/IP. SLS es la razón por la que la palabra distribución tiene el significado actual. También tenía errores y su mantenimiento era lento. En 1993, dos personas decidieron corregirla por separado. Una la reconstruyó. La otra empezó de nuevo con reglas escritas.

Slackware, 1993: la familia más antigua que sigue publicando versiones

Patrick Volkerding publicó Slackware 1.00 el 16 de julio de 1993, a partir de SLS y con los errores corregidos. El proyecto sigue manteniéndose, por lo que es la distribución de Linux más antigua que aún existe.

Un paquete de Slackware es un archivo tar comprimido que contiene un script de instalación. No hay resolución de dependencias: ningún componente comprueba que la biblioteca que necesita el paquete nuevo ya esté instalada en el disco. Esa decisión determinó todo lo demás. Si la herramienta no resuelve las dependencias, el conjunto publicado debe ser coherente desde el principio, por lo que las versiones se publican con poca frecuencia y adoptan un enfoque conservador. Slackware 15.0 llegó en febrero de 2022, seis años después de 14.2.

La familia es pequeña. Las primeras versiones de SUSE, a mediados de la década de 1990, se basaron en Slackware, antes de que el proyecto siguiera su propio camino con YaST y, posteriormente, el formato de paquetes RPM. Esta última parte causa confusión. SUSE y openSUSE usan paquetes RPM, pero no son derivados de Red Hat. El formato se extendió. La línea de descendencia no.

Debian, 1993: un contrato social y un flujo de tres ramas

Ian Murdock anunció Debian el 16 August 1993, tres semanas después de Slackware y por el mismo motivo. El nombre combina el de su pareja, Debra, con el suyo. El Debian Manifesto llegó en January 1994 y fijó las condiciones: esta distribución se mantendría de forma abierta por voluntarios, no por una empresa.

Debian también dejó esas condiciones por escrito. El Debian Social Contract y las DFSG (directrices de software libre de Debian) se adoptaron en July 1997, y las DFSG se convirtieron en la base de la Open Source Definition en 1998. Un documento escrito para establecer qué pertenece a una distribución terminó definiendo una categoría de licencias para toda la industria. También por eso tu sources.list tiene componentes: main contiene software que cumple las directrices, contrib y non-free contienen el que no las cumple, y Debian 12 añadió non-free-firmware para que un portátil con una tarjeta inalámbrica pudiera instalarse sin tener que buscar los componentes por separado.

Las herramientas son la otra herencia. dpkg instala un paquete y se detiene cuando falta algo; muestra dpkg: dependency problems prevent configuration of. APT (advanced package tool), que se convirtió en la opción predeterminada con Debian 2.1 en 1999, es la capa que determina qué más debe descargar y en qué orden. Cada comando apt de cada derivada de Debian desciende de ese trabajo.

El proceso de publicación tiene tres ramas y una regla. Un mantenedor carga paquetes en unstable, cuyo nombre en clave permanente es sid. Un script migra el paquete a testing después de aproximadamente 5 a 10 días, si se compiló para las arquitecturas de publicación y no incorporó ningún nuevo error crítico para la publicación. Después testing entra en congelación, el equipo de publicación resuelve lo que queda y stable se publica cuando la lista de errores es suficientemente corta. No se publica en una fecha fija. Por eso Debian stable parece antigua y funciona bien: los números de versión dejan de cambiar durante la congelación, mientras las correcciones de seguridad se retroportan a esas versiones.

La gobernanza también está documentada, con un líder del proyecto elegido y resoluciones generales vinculantes. En 2014, ese mecanismo eligió systemd como sistema init predeterminado, y las personas que no estuvieron de acuerdo crearon Devuan, que publicó su primera versión en 2017. Debian no fue la primera distribución en hacer ese cambio ni la última, y los motivos por los que siguió ocurriendo, junto con las objeciones que resultaron acertadas, se explican en el relato de cómo systemd sustituyó a SysV init. Sus derivadas principales son Ubuntu, Raspberry Pi OS, Proxmox VE, Kali y Linux Mint.

Red Hat, 1994: RPM y la división entre Fedora y RHEL

Marc Ewing publicó la primera versión de Red Hat Linux alrededor de Halloween de 1994. La empresa de Bob Young la compró en 1995, y ambos construyeron la primera empresa de Linux que vendía soporte en lugar de software. Red Hat salió a bolsa el 11 de agosto de 1999. IBM completó la adquisición de la empresa en julio de 2019 por unos 34 mil millones de dólares, por lo que la distribución contra la que se certifica la mayor parte del software empresarial pertenece a IBM desde entonces.

La contribución técnica duradera es RPM (Red Hat package manager), escrito por Erik Troan y Marc Ewing para Red Hat Linux 2.0 en 1995. Un RPM declara sus dependencias y se genera a partir de un archivo spec, una receta de compilación que cualquiera puede ejecutar. Esta segunda propiedad fue la que hizo posibles las reconstrucciones independientes del producto empresarial de Red Hat.

Red Hat Linux 9, publicado en 2003, fue la última versión de la línea original. La empresa la dividió en dos: Fedora Core 1, publicado en noviembre de 2003 como versión comunitaria de desarrollo rápido, y RHEL (Red Hat Enterprise Linux), que había comenzado como Advanced Server 2.1 en 2002, como versión de pago y desarrollo lento. La causa es clara. Un producto no puede ser a la vez el lugar donde se prueban las versiones nuevas y la plataforma que un banco ejecuta sin cambios durante diez años. Ambas partes están vinculadas: una versión principal de RHEL parte de una versión de Fedora, se estabiliza y después se congela. La herramienta de paquetes avanzó con el mismo calendario, desde yum en la década de 2000 hasta dnf como opción predeterminada de Fedora en 2015, con rpm por debajo de ambas.

Por qué CentOS dejó de ser una reconstrucción gratuita de RHEL

CentOS comenzó en 2004 con una tarea sencilla: tomar los paquetes de código fuente que Red Hat publicaba, eliminar las marcas comerciales, reconstruirlos y distribuir el resultado gratuitamente. Se convirtió en la distribución de servidor gratuita predeterminada durante una década, y Red Hat incorporó el proyecto en 2014.

El 8 de diciembre de 2020, Red Hat anunció que CentOS Linux 8 finalizaría el 31 de diciembre de 2021, ocho años antes de la fecha publicada, y que el nombre continuaría como CentOS Stream. Stream no es una reconstrucción. Es la rama a partir de la que se generan las versiones menores de RHEL, por lo que va por delante de RHEL en lugar de ir por detrás. Para una máquina que pretende mantener durante años, ir por delante es la dirección incorrecta, porque recibe los cambios antes que los clientes de pago de Red Hat.

En 2021 aparecieron dos reconstrucciones. Gregory Kurtzer, cofundador de CentOS, inició Rocky Linux. CloudLinux financió AlmaLinux. En junio de 2023, Red Hat dejó de publicar las fuentes de RHEL en cualquier lugar excepto CentOS Stream y su portal de clientes. Rocky mantuvo el objetivo de crear reconstrucciones idénticas. AlmaLinux cambió su objetivo a la compatibilidad ABI (interfaz binaria de aplicaciones), lo que significa que el software creado para RHEL se ejecuta, sin prometer que la lista de errores coincida línea por línea. Oracle, SUSE y CIQ crearon OpenELA más tarde ese año para publicar fuentes compartidas. Toda esa secuencia, desde la separación de 2003 hasta el cambio de fuentes de 2023 y lo que promete ahora cada reconstrucción, se explica en el análisis más extenso de Red Hat, CentOS, Rocky y AlmaLinux.

Si la lista de imágenes de un proveedor todavía indica CentOS, averigüe a cuál se refiere antes de usarlo como base.

cat /etc/os-release

NAME="CentOS Stream" es una rama de desarrollo continua que precede a RHEL. NAME="AlmaLinux" o NAME="Rocky Linux" es una reconstrucción que la sigue, con un periodo de diez años.

Ubuntu, 2004: una instantánea de Debian unstable con calendario

Ubuntu 4.10 se publicó el 20 de octubre de 2004, con financiación de Mark Shuttleworth. Su relación con Debian es mecánica, no sentimental. Cada ciclo comienza importando paquetes de Debian unstable en la nueva versión de Ubuntu. Esas importaciones continúan hasta el Debian Import Freeze, a mitad del ciclo. Después, Ubuntu mantiene sus propios cambios. Muchos paquetes de Ubuntu son el paquete de Debian más un delta, y el changelog indica cuál.

La otra mitad es el calendario. Debian publica cuando está listo. Ubuntu publica en abril y octubre, y el número de versión es la fecha: 24.04 salió en abril de 2024. Una de cada dos versiones publicadas en abril es una LTS (long term support), que es lo que quiere decir un proveedor cuando ofrece Ubuntu sin ningún calificativo. Qué versión de las dos debe instalarse en un servidor es el tema central de elegir entre Ubuntu LTS y las versiones provisionales, y pasar de una LTS a la siguiente tiene su propio procedimiento, descrito en la actualización de 24.04 a 26.04.

Hay un detalle que los administradores de servidores deben comprobar cada año. El archivo de Ubuntu está dividido en componentes. main recibe mantenimiento de Canonical durante todo el periodo de soporte. universe recibe mantenimiento de la comunidad, y su cobertura de seguridad es un compromiso diferente. apt install no muestra ninguna diferencia. Un comando permite comprobarlo:

apt-cache policy nginx

Una línea de repositorio que termina en /main indica que el equipo de seguridad de Canonical es responsable de ese paquete. Una línea que termina en /universe indica que la comunidad es responsable. Compruébelo para todo lo que esté expuesto a Internet.

Arch, 2002: actualizaciones continuas y el coste de una actualización parcial

Judd Vinet publicó Arch 0.1 el 11 de marzo de 2002, con un gestor de paquetes escrito por él mismo, pacman, y recetas de compilación que son simples scripts de shell. Arch no tiene versiones publicadas. Los medios de instalación son instantáneas fechadas de los mismos repositorios de actualización continua. Por tanto, una máquina instalada en 2019 y actualizada cada semana ejecuta el mismo Arch que una instalada hoy. El AUR (repositorio de usuarios de Arch) contiene recetas de compilación aportadas por los usuarios. Son recetas, no paquetes revisados. Por eso, leer un PKGBUILD antes de ejecutarlo forma parte del trabajo.

Las actualizaciones continuas tienen un modo de fallo, y siempre lo provoca el administrador. La instalación de un solo paquete con pacman -Sy foo actualiza la base de datos de paquetes y después instala un binario nuevo enlazado con bibliotecas más recientes que las instaladas en el disco. Los programas fallan entonces de esta forma:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

La operación compatible es pacman -Syu, que actualiza todo conjuntamente. El proyecto también publica noticias que indican cuándo es necesaria una intervención manual antes de determinadas actualizaciones. Ejecutar la actualización sin leerlas puede dejar una máquina que no arranca.

Por eso Arch es una mala opción para un servidor que se vaya a dejar sin supervisión. Un equipo actualizado cada semana funciona bien. Un equipo actualizado una sola vez, un año después, aplica todas las intervenciones omitidas en una única ejecución.

Alpine: una distribución pequeña que los contenedores hicieron popular

Alpine comenzó alrededor de 2005 como una bifurcación de LEAF (Linux embedded appliance framework), que a su vez descendía de Linux Router Project. Natanael Copa la creó para dispositivos, no para equipos de escritorio. Sustituye la mayor parte del userland habitual: musl en lugar de la biblioteca C de GNU, BusyBox en lugar de las utilidades principales de GNU, OpenRC en lugar de systemd y apk como gestor de paquetes. Alpine 3.0, publicada en 2014, fue la versión que cambió a musl.

Los contenedores la hicieron popular. Una capa base de Alpine ocupa una fracción del espacio de una capa base de Debian o Ubuntu. Por eso, desde 2016 se convirtió en una imagen base habitual, y muchas personas que nunca instalaron Alpine la ejecutaron a diario.

El coste es que musl no es glibc, y la diferencia aparece en errores que parecen no tener relación. Un binario enlazado con glibc falla en Alpine con un mensaje que hace buscar un archivo que ya existe:

sh: ./myapp: not found

El programa existe. Su intérprete ELF no existe porque falta el cargador de glibc. Python es la otra sorpresa habitual: las wheels precompiladas para manylinux no se pueden instalar en musl. Por eso, pip intenta compilar desde el código fuente y se detiene cuando no hay ningún compilador instalado. El estándar de wheels musllinux de 2021 resolvió el problema para los proyectos que publican esas wheels, pero no para los demás.

Como sistema operativo anfitrión en un VPS, Alpine se instala rápidamente, ocupa poco espacio y obliga a apartarse del procedimiento que asume la mayoría de la documentación. Toda guía que indique ejecutar systemctl enable debe traducirse a rc-update add.

La generación inmutable: actualizaciones atómicas y servidores basados en imágenes

La rama más reciente cambia el modelo de actualización en lugar de la lista de paquetes. Un sistema basado en ostree mantiene /usr en modo de solo lectura. Una actualización es un árbol de sistema de archivos completo que se descarga, se prepara y se activa en el siguiente reinicio. El árbol anterior se conserva como una entrada de arranque, por lo que una actualización defectuosa se revierte reiniciando con la versión anterior.

Fedora Silverblue llevó este modelo al escritorio en 2018 y Fedora CoreOS lo llevó a los servidores en 2019, después de que Red Hat adquiriera CoreOS en 2018. Flatcar Container Linux continuó el proyecto original Container Linux cuando este se retiró en 2020. openSUSE MicroOS llega al mismo resultado mediante instantáneas de btrfs y transactional-update. En 2024, Red Hat añadió un modo basado en imágenes a RHEL, desarrollado sobre bootc, en el que el sistema operativo se distribuye como una imagen de contenedor y una máquina se actualiza apuntándola a un tag nuevo. Talos Linux lleva este enfoque más lejos y elimina por completo el shell y SSH: la máquina se configura mediante una API, por lo que no hay nada en lo que iniciar sesión. NixOS, publicado por primera vez en 2007, llega desde otra dirección. Todo el sistema se construye a partir de una única configuración declarativa y las generaciones anteriores siguen disponibles para el arranque.

Es probable que tu proveedor no ofrezca ninguno de estos sistemas como una imagen de un solo clic, porque espera que se configuren durante el primer arranque mediante Ignition o cloud-init, en lugar de que un administrador edite archivos mediante SSH. Resultan útiles cuando hay muchas máquinas idénticas. Esa es precisamente tu situación cuando estás administrando varios servidores Linux a la vez y necesitas demostrar que cada uno es idéntico a los demás.

¿Durante cuánto tiempo se admite una versión?

La política de versiones es el aspecto de una distribución con el que convivirá durante más tiempo, y se publica como un número de años. Estas son las ventanas de soporte de las 5 versiones de servidor actuales.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine admite cada rama 3.x durante 2 años. Por eso se adapta mejor a una imagen de contenedor que se reconstruye con frecuencia que a un host que no se modifica. El equipo de seguridad de Debian cubre una versión estable durante aproximadamente 3 años. Después, el equipo de LTS mantiene las arquitecturas habituales hasta aproximadamente 5 años en total. Ubuntu LTS ofrece 5 años para los paquetes de main. Una suscripción a Ubuntu Pro amplía ese periodo a 10 años y es gratuita para uso personal en un número reducido de máquinas. RHEL 10 publica 10 años. El complemento de soporte de ciclo de vida ampliado de pago prolonga ese periodo hasta 13 años. AlmaLinux 10 iguala la ventana de RHEL de 10 años sin ninguna suscripción. Esa es precisamente la razón por la que existen las reconstrucciones.

Arch no tiene una fila aquí porque una distribución rolling no tiene una versión cuyo soporte deba mantenerse. En Arch, el dato importante es cuánto tiempo puede dejar una máquina sin modificar. Ese periodo se mide en semanas.

Por qué la lista de imágenes de tu VPS tiene este aspecto

Un proveedor ofrece las imágenes que los clientes solicitan por nombre y que se instalan sin intervención en su hipervisor. Por eso, casi todas las listas empiezan con Ubuntu LTS y Debian stable, añaden AlmaLinux o Rocky para quienes usan software certificado para RHEL y dejan Alpine, Arch y Fedora más abajo. Cuando sabes qué es un VPS y cómo llega la imagen al disco, el patrón resulta claro: el proveedor elige sistemas operativos que soportan una instalación desatendida y siguen teniendo soporte durante más tiempo del que el cliente medio mantiene el servidor.

La elección te compromete con algo más que un gestor de paquetes. Determina la actualización que ejecutarás dentro de tres años, y esas actualizaciones son completamente distintas según la familia. Debian y Ubuntu admiten actualizaciones importantes en el mismo sistema. La familia Red Hat las realiza mediante leapp. Arch no tiene actualizaciones de versión porque no tiene versiones. En Alpine, se edita /etc/apk/repositories y se ejecuta apk upgrade --available. La elección también determina qué software puedes instalar sin añadir un repositorio de terceros, quién publica el parche cuando aparece una entrada CVE (common vulnerabilities and exposures) relacionada con algo que ejecutas y qué sistema init y biblioteca C supondrá que están disponibles el software que instales en el futuro.

Hay otro efecto que es fácil de subestimar. La mayoría de las respuestas publicadas en Internet suponen un procedimiento de la familia Debian o de la familia Red Hat. Por tanto, elegir una distribución distinta implica traducir las instrucciones durante toda la vida de la máquina. Elige la familia cuya política de versiones coincida con la frecuencia con la que estás dispuesto a intervenir en el servidor y mantenla. Cambiar los paquetes instalados encima es fácil. Cambiar la distribución subyacente implica reconstruir el servidor.

FAQ

¿En qué familia de distribuciones Linux está mi servidor?

Ejecute cat /etc/os-release. El campo ID indica la distribución y ID_LIKE indica su familia, por lo que una máquina Ubuntu muestra ID_LIKE=debian y una máquina AlmaLinux muestra ID_LIKE="rhel centos fedora". El gestor de paquetes proporciona otra pista. apt y dpkg corresponden a la familia Debian, dnf y rpm corresponden a la familia Red Hat, apk corresponde a Alpine y pacman corresponde a Arch.

¿CentOS sigue siendo una versión gratuita de RHEL?

No. CentOS Linux 8, la última reconstrucción con ese nombre, llegó al final de su vida útil el 31 de diciembre de 2021, y CentOS Linux 7 llegó al final de su vida útil el 30 de junio de 2024. El proyecto que permanece, CentOS Stream, es la rama a partir de la cual se crean las versiones menores de RHEL, por lo que recibe los cambios antes que RHEL y no después. Las reconstrucciones gratuitas que asumieron el papel anterior son AlmaLinux y Rocky Linux, ambas con ciclos de soporte de diez años.

¿Por qué Debian stable incluye números de versión tan antiguos?

Porque el número de versión queda congelado mientras siguen llegando las correcciones. Debian incorpora parches de seguridad a la versión que publicó en lugar de importar una versión upstream más reciente, por lo que un paquete que muestra 2.4.57-2+deb13u1 puede incluir una corrección publicada la semana pasada. El sufijo posterior a la versión upstream es la revisión de Debian, y apt changelog <package> enumera lo que se incorporó en ella. Evaluar la seguridad de un servidor Debian por sus números de versión conduce siempre a una conclusión incorrecta.

¿Debería ejecutar una distribución rolling release como Arch en un VPS?

Sólo si la actualizará según un calendario. Una distribución rolling presupone que todas las máquinas convergen en el conjunto de paquetes actual, por lo que actualizar un paquete con pacman -Sy foo deja bibliotecas incompatibles y errores como cannot open shared object file. Ejecute pacman -Syu con regularidad, lea la página de noticias del proyecto antes de cada ejecución y el sistema será estable. Si lo deja sin actualizar durante un año, la primera actualización será la operación arriesgada.

¿Qué cambia realmente en una distribución immutable o atomic?

Cambia cuándo se aplican las actualizaciones y cómo se deshacen. /usr se monta en modo de sólo lectura, una actualización se prepara como un árbol nuevo completo y el cambio se realiza al reiniciar, manteniendo el árbol anterior como entrada de arranque para poder revertirlo. La máquina queda completamente actualizada o completamente sin actualizar, sin un estado parcialmente aplicado. Ya no puede instalar software editando archivos directamente, por lo que las aplicaciones se trasladan a contenedores o a paquetes por capas.