Historia de las distribuciones Linux y su linaje

Qué es realmente una distribución de Linux

La historia de las distribuciones de Linux comienza con una carencia: el kernel de Linux por sí solo no realiza ninguna función útil para el usuario. Arranca y detecta el hardware. Después, se detiene. Alguien debe añadir un espacio de usuario (userland), elegir cómo se instala y actualiza el software, y comprometerse a mantenerlo durante años. Una distribución es ese conjunto de decisiones, además del grupo de personas que permanece detrás.

Consta de cinco partes. Si cambia cualquiera de ellas, obtiene una distribución diferente, incluso cuando la mayoría de los binarios coincidan:

• Un kernel, en una versión elegida por el proyecto, con los parches y controladores que este haya añadido.
• Un espacio de usuario: la biblioteca C, el shell, el sistema de inicio (init), los comandos estándar.
• Un formato de paquete y la herramienta que lo instala.
• Una política de versiones: qué puede cambiar, con qué frecuencia y durante cuánto tiempo se mantiene 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 respecto a otro Unix. Vale la pena tener esto en cuenta al comparar Linux y FreeBSD como plataformas de servidor, donde el kernel y el espacio de usuario base son desarrollados por un mismo proyecto y publicados conjuntamente. En Linux, esas piezas provienen de fuentes independientes (upstreams), y la distribución es el elemento que logra que todas ellas funcionen en conjunto.

Historia de las distribuciones Linux en tres familias

Tres proyectos iniciados en 1993 y 1994 se convirtieron en familias: Slackware, Debian y Red Hat. Casi todas las imágenes en un panel de control de VPS hoy en día pertenecen a una de ellas o a un descendiente. Un descendiente hereda el formato de paquete, la estructura de archivos y, por lo general, los hábitos de lanzamiento; por eso, un derivado de Debian sigue pareciéndose a Debian una vez eliminada la marca.

Las independientes merecen su propia línea, ya que no derivan de nadie. Arch, Gentoo, Alpine, NixOS y Void crearon su propio gestor de paquetes y sus propias reglas. Dos de ellas, Arch y Alpine, terminaron en la lista de imágenes de su proveedor de todos modos, por razones ajenas al escritorio.

1992: las distribuciones antes de las familias

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

SLS (Softlanding Linux System), lanzada por Peter MacDonald en 1992, fue más allá al añadir X (el X Window System) y redes TCP/IP. SLS es la razón por la que el término distribución tiene su significado actual. También presentaba errores y su mantenimiento era lento, por lo que en 1993 dos personas decidieron solucionar esto por separado. Una de ellas reconstruyó el sistema. La otra comenzó de nuevo basándose en reglas escritas.

Slackware, 1993: la familia más antigua que sigue en distribución

Patrick Volkerding lanzó Slackware 1.00 el 16 de julio de 1993, construido a partir de SLS tras corregir sus errores. Sigue en mantenimiento, lo que la convierte en la distribución de Linux más antigua que sobrevive.

Un paquete de Slackware es un archivo tar comprimido que contiene un script de instalación. No existe resolución de dependencias: nada verifica si la librería que requiere su nuevo paquete ya está en el disco. Esa decisión única definió todo lo demás. Si la herramienta no resuelve dependencias, el conjunto distribuido debe ser coherente por diseño, por lo que las versiones son poco frecuentes y conservadoras. Slackware 15.0 llegó en febrero de 2022, seis años después de la 14.2.

La familia es pequeña. Las primeras versiones de SUSE a mediados de la década de 1990 se construyeron sobre Slackware, antes de que el proyecto siguiera su propio camino con YaST y, más tarde, con el formato de paquete RPM. Esa última parte confunde a la gente. SUSE y openSUSE utilizan paquetes RPM y no son derivados de Red Hat. El formato viajó. El linaje, no.

Debian, 1993: un contrato social y una arquitectura de tres ramas

Ian Murdock anunció Debian el 16 de agosto de 1993, tres semanas después de Slackware y por la misma razón. El nombre combina el de su pareja, Debra, con el suyo propio. El Manifiesto de Debian se publicó en enero de 1994 y estableció las condiciones: esta distribución sería mantenida abiertamente por voluntarios, no por una empresa.

Debian puso las condiciones por escrito. El Contrato Social de Debian y las DFSG (directrices de software libre de Debian) se adoptaron en julio de 1997, y las DFSG se convirtieron en la base de la Definición de Código Abierto en 1998. Un documento redactado para decidir qué incluir en una distribución terminó definiendo una categoría de licencias para toda la industria. Es también la razón por la que su sources.list tiene componentes: main contiene software que cumple con las directrices, contrib y non-free contienen lo 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 necesidad de buscar componentes por separado.

Las herramientas son la otra herencia. dpkg instala un paquete y se niega si falta algo, mostrando dpkg: dependency problems prevent configuration of. APT (advanced package tool), que se convirtió en el estándar con Debian 2.1 en 1999, es la capa que calcula qué más descargar y en qué orden. Cada comando apt en cualquier derivado de Debian desciende de ese trabajo.

El mecanismo de lanzamiento tiene tres ramas y una regla. Un mantenedor sube el código a 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ó en las arquitecturas de lanzamiento y no presenta nuevos errores críticos. Luego, testing se congela, el equipo de lanzamiento resuelve lo que queda, y stable se lanza cuando la lista de errores es lo suficientemente corta. No en una fecha fija. Por eso Debian stable parece antigua y funciona bien: los números de versión se detienen en la congelación, mientras que las correcciones de seguridad se siguen aplicando mediante backports.

La gobernanza también está documentada, con un líder de proyecto electo y resoluciones generales vinculantes. En 2014, ese mecanismo eligió systemd como sistema de inicio predeterminado, y las personas que no estuvieron de acuerdo crearon la bifurcación Devuan, que realizó su primer lanzamiento en 2017. Los descendientes más grandes son Ubuntu, Raspberry Pi OS, Proxmox VE, Kali y Linux Mint.

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

Marc Ewing lanzó la primera versión de Red Hat Linux cerca de Halloween de 1994. La empresa de Bob Young la adquirió en 1995 y ambos construyeron el primer negocio de Linux que vendía soporte en lugar de software. Red Hat salió a bolsa el 11 de agosto de 1999. IBM cerró la adquisición de la compañía en julio de 2019 por unos 34 mil millones de dólares, por lo que la distribución para la que se certifica la mayor parte del software empresarial ha sido propiedad de 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 produce a partir de un archivo spec, una receta de compilación que cualquiera puede ejecutar. Esa segunda propiedad es la que permitió, más adelante, realizar reconstrucciones independientes del producto empresarial de Red Hat.

Red Hat Linux 9, en 2003, fue la última de la línea original. La empresa la dividió en dos: Fedora Core 1 en noviembre de 2003 como la versión comunitaria rápida, y RHEL (Red Hat Enterprise Linux), que había comenzado como Advanced Server 2.1 en 2002, como la versión lenta de pago. La causa es evidente. Un mismo producto no puede ser, a la vez, el lugar donde se prueban las nuevas versiones y la plataforma que un banco ejecuta sin cambios durante diez años. Ambas mitades están vinculadas: una versión mayor de RHEL se deriva de una versión de Fedora, se estabiliza y luego se congela. La herramienta de paquetes evolucionó siguiendo el mismo calendario, desde yum en la década de 2000 hasta dnf como valor predeterminado en Fedora en 2015, con rpm como base de ambos.

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 publicaba Red Hat, eliminar las marcas registradas, reconstruirlos y distribuir el resultado. Se convirtió en la distribución de servidor gratuita por defecto durante una década, y Red Hat integró el proyecto en su estructura 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 de la que se derivan las versiones menores de RHEL, por lo que se ejecuta por delante de RHEL en lugar de por detrás. Para una máquina que pretende mantener durante años, ir por delante es la dirección incorrecta, ya que usted recibe los cambios antes que los clientes de pago de Red Hat.

En 2021 aparecieron dos reconstrucciones. Rocky Linux fue iniciado por Gregory Kurtzer, cofundador de CentOS. AlmaLinux fue financiado por CloudLinux. En junio de 2023, Red Hat dejó de publicar las fuentes de RHEL en cualquier lugar que no fuera CentOS Stream y su portal de clientes. Rocky mantuvo su objetivo de realizar reconstrucciones idénticas. AlmaLinux cambió su meta hacia la compatibilidad ABI (interfaz binaria de aplicación), lo que significa que el software compilado para RHEL funciona, sin la promesa de que la lista de errores coincida línea por línea. Oracle, SUSE y CIQ crearon OpenELA más tarde ese mismo año para publicar fuentes compartidas.

Si la lista de imágenes de un proveedor todavía indica CentOS, averigüe a cuál se refiere antes de basar su infraestructura en ella.

cat /etc/os-release

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

Ubuntu 20.04: una instantánea de Debian unstable, basada en el calendario

Ubuntu 4.10 se lanzó el 20 de octubre de 2004, financiado por Mark Shuttleworth. Su relación con Debian es mecánica más que sentimental. Cada ciclo comienza importando paquetes de Debian unstable a la nueva versión de Ubuntu. Estas importaciones continúan hasta el Debian Import Freeze, a mitad del ciclo; a partir de ese momento, Ubuntu aplica sus propios cambios. Muchos paquetes de Ubuntu son el paquete de Debian más un delta, y el registro de cambios indica cuál es.

La otra mitad es el calendario. Debian se lanza cuando está listo. Ubuntu se lanza en abril y octubre, y el número de versión es la fecha: 24.04 salió en abril de 2024. Cada segundo lanzamiento de abril es una LTS (soporte a largo plazo), que es a lo que se refiere un proveedor cuando lista Ubuntu sin calificativos. Cuál de las dos versiones elegir para un servidor es el tema central de elegir entre Ubuntu LTS y versiones provisionales, y pasar de una LTS a la siguiente tiene su propio procedimiento, cubierto en la actualización de 24.04 a 26.04.

Un detalle confunde a los administradores de servidores cada año. El archivo de Ubuntu está dividido en componentes. main es mantenido por Canonical durante todo el periodo de soporte. universe es mantenido por la comunidad, y su cobertura de seguridad es una promesa diferente. apt install no muestra información sobre esta diferencia. Un comando permite verificarlo:

apt-cache policy nginx

Una línea de repositorio que termina en /main significa que el equipo de seguridad de Canonical es responsable de ese paquete. Una línea que termina en /universe significa que lo es la comunidad. Verifique esto para cualquier servicio expuesto a internet.

Arch, 2002: rolling releases y el coste de una actualización parcial

Judd Vinet lanzó Arch 0.1 el 11 de marzo de 2002, con un gestor de paquetes que él mismo escribió, pacman, y recetas de compilación que son simples scripts de shell. Arch no tiene versiones de lanzamiento. Los medios de instalación son instantáneas fechadas de los mismos repositorios rolling, por lo que una máquina instalada en 2019 y actualizada cada semana ejecuta el mismo Arch que una instalada hoy. El AUR (Arch user repository) contiene recetas de compilación aportadas por los usuarios. Son recetas, no paquetes revisados, por lo que leer un PKGBUILD antes de ejecutarlo es parte del trabajo.

El modelo rolling tiene un modo de fallo, y es autoinfligido en cada ocasión. Instalar un solo paquete con pacman -Sy foo refresca la base de datos de paquetes y luego instala un nuevo binario vinculado a bibliotecas más recientes que las que hay en el disco. Los programas fallan entonces de esta manera:

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

La operación soportada es pacman -Syu, que actualiza todo de forma conjunta. El proyecto también publica entradas de noticias que indican que se requiere intervención manual antes de ciertas actualizaciones, y ejecutar la actualización sin leerlas puede dejar una máquina que no arranca.

Esto hace que Arch sea una mala elección para un servidor que planea ignorar. Un equipo actualizado semanalmente está bien. Un equipo actualizado una vez, un año después, le presenta todas las intervenciones omitidas en una sola ejecución.

Alpine: una distribución pequeña que se hizo famosa gracias a los contenedores

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

Los contenedores la hicieron popular. Una capa base de Alpine es una pequeña fracción del tamaño de una base de Debian o Ubuntu, por lo que a partir de 2016 se convirtió en una imagen base común, y una gran cantidad de personas que nunca instalaron Alpine la ejecutaron a diario.

El coste es que musl no es glibc, y la brecha aparece como errores que parecen no estar relacionados. Un binario vinculado contra glibc falla en Alpine con un mensaje que hace que los usuarios busquen un archivo que ya está ahí:

sh: ./myapp: not found

El programa existe. Su intérprete ELF no, porque el cargador de glibc está ausente. Python es la otra sorpresa habitual: los wheels precompilados para manylinux no se instalan en musl, por lo que pip recurre a compilar desde el código fuente y se detiene cuando no hay un compilador instalado. El estándar de wheels musllinux de 2021 solucionó esto para los proyectos que publican esos wheels, y para nadie más.

Como sistema operativo anfitrión en un VPS, Alpine se instala con poco peso y se actualiza rápido, y le aparta del camino que asume la mayoría de la documentación. Cada guía que le indica ejecutar systemctl enable necesita ser traducida 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 como de solo lectura. Una actualización es un árbol completo del sistema de archivos nuevo, que se descarga, se prepara y al que se cambia en el siguiente reinicio. El árbol anterior permanece como una entrada de arranque, por lo que una actualización fallida se revierte reiniciando con la versión antigua.

Fedora Silverblue llevó esto al escritorio en 2018 y Fedora CoreOS lo llevó a los servidores en 2019, después de que Red Hat comprara CoreOS en 2018. Flatcar Container Linux continuó el Container Linux original cuando este fue retirado en 2020. openSUSE MicroOS llega al mismo punto mediante instantáneas de btrfs y transactional-update. En 2024, Red Hat añadió un modo basado en imágenes a RHEL, construido sobre bootc, donde el sistema operativo se distribuye como una imagen de contenedor y una máquina se actualiza apuntándola a una nueva etiqueta. Talos Linux va más allá y elimina el shell y SSH por completo: la máquina se configura a través de una API, por lo que no hay nada a lo que iniciar sesión. NixOS, lanzado por primera vez en 2007, llega desde una dirección diferente. Todo el sistema se construye a partir de una configuración declarativa y las generaciones anteriores siguen siendo arrancables.

Probablemente su proveedor no ofrezca ninguna de estas opciones como una imagen de un solo clic, porque esperan ser configuradas en el primer arranque mediante Ignition o cloud-init en lugar de que un administrador edite archivos vía SSH. Estas opciones son rentables en muchas máquinas idénticas, que es la situación en la que se encuentra una vez que está administrando varios servidores Linux a la vez y necesita que cada uno sea demostrablemente igual a los demás.

¿Cuánto tiempo se mantiene 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 una cantidad de años. A continuación se muestran los periodos para 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 mantiene cada rama 3.x durante 2 años, por lo que es más adecuada para una imagen de contenedor que se reconstruye con frecuencia que para un host que no se toca. El equipo de seguridad de Debian cubre una versión estable durante unos 3 años, y el equipo de LTS extiende el soporte para las arquitecturas comunes hasta aproximadamente 5 años en total. Una versión Ubuntu LTS ofrece 5 años para los paquetes en main, y una suscripción a Ubuntu Pro amplía ese periodo a 10 años, de forma gratuita para uso personal en un número reducido de máquinas. RHEL 10 publica 10 años, que el complemento de pago de soporte de ciclo de vida extendido amplía a 13. AlmaLinux 10 iguala el periodo de RHEL de 10 años sin necesidad de suscripción, que es la razón de ser de estas reconstrucciones.

Arch no aparece en esta lista, ya que una distribución de tipo rolling release no tiene versiones que mantener. El número relevante para Arch es cuánto tiempo puede dejar una máquina sin tocar, y eso se mide en semanas.

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

Un proveedor distribuye las imágenes que los clientes solicitan por nombre y que se instalan de forma desatendida en su hipervisor. Por eso, casi todas las listas comienzan con una versión Ubuntu LTS y una Debian estable, añaden AlmaLinux o Rocky para quienes utilizan software certificado para RHEL, y mantienen Alpine, Arch y Fedora más abajo en la página. Una vez que sabe qué es un VPS y cómo llega la imagen al disco, el patrón se entiende con claridad: el proveedor selecciona sistemas operativos que soportan una instalación desatendida y que mantienen soporte durante más tiempo del que el cliente promedio conserva el servidor.

Esta elección le compromete a algo más que a un gestor de paquetes. Determina la actualización que ejecutará dentro de tres años, y estas difieren completamente según la familia. Debian y Ubuntu soportan actualizaciones mayores in situ. La familia Red Hat las gestiona mediante leapp. Arch no tiene actualizaciones porque no tiene versiones. La de Alpine consiste en editar /etc/apk/repositories y ejecutar apk upgrade --available. La elección también define qué software puede instalar sin añadir repositorios de terceros, quién distribuye el parche cuando aparece una entrada CVE (vulnerabilidades y exposiciones comunes) en algo que usted ejecuta, y qué sistema de inicio y biblioteca C asumirá su futuro software que está presente.

Existe un efecto más que es fácil subestimar. La mayoría de las respuestas escritas en Internet asumen una ruta de la familia Debian o de la familia Red Hat, por lo que elegir fuera de esas dos significa traducir las instrucciones durante toda la vida útil de la máquina. Elija la familia cuya política de versiones coincida con la frecuencia con la que está dispuesto a intervenir en el servidor y manténgala. Cambiar los paquetes instalados es sencillo. Cambiar la distribución que los sustenta implica reconstruir el equipo desde cero.

FAQ

¿A qué familia de distribución Linux pertenece mi servidor?

Ejecute cat /etc/os-release. El campo ID indica la distribución y ID_LIKE nombra su familia; por ejemplo, una máquina Ubuntu reporta ID_LIKE=debian y una máquina AlmaLinux reporta ID_LIKE="rhel centos fedora". El gestor de paquetes es otro indicador. apt y dpkg corresponden a la familia Debian, dnf y rpm a la familia Red Hat, apk a Alpine y pacman a Arch.

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

No. CentOS Linux 8, la última reconstrucción con ese nombre, finalizó el 31 de diciembre de 2021, y CentOS Linux 7 alcanzó el fin de su vida útil el 30 de junio de 2024. El proyecto superviviente, CentOS Stream, es la rama sobre la que se construyen las versiones menores de RHEL, por lo que recibe los cambios antes que RHEL en lugar de después. Las reconstrucciones gratuitas que asumieron el rol anterior son AlmaLinux y Rocky Linux, ambas con ciclos de vida de diez años.

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

Porque el número de versión se congela mientras las correcciones siguen llegando. Debian aplica parches de seguridad a la versión publicada en lugar de importar una versión más reciente del desarrollador original (upstream), por lo que un paquete que indica 2.4.57-2+deb13u1 puede incluir una corrección publicada la semana pasada. El sufijo tras la versión original es la revisión de Debian, y apt changelog <package> detalla los cambios incluidos. Juzgar la seguridad de un servidor Debian por sus números de versión siempre arroja un resultado incorrecto.

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

Solo si planea actualizarla de forma programada. Una distribución rolling asume que cada máquina converge hacia el conjunto de paquetes actual, por lo que actualizar un solo paquete con pacman -Sy foo deja librerías incompatibles y errores como cannot open shared object file. Ejecute pacman -Syu con regularidad y lea la página de noticias del proyecto antes de cada actualización para mantener el sistema estable. Si deja pasar un año, la primera actualización se vuelve arriesgada.

¿Qué cambia realmente una distribución inmutable o atómica?

Cambia el momento en que se aplican las actualizaciones y cómo se revierten. /usr se monta como solo lectura, la actualización se prepara como un árbol completo nuevo y el cambio ocurre al reiniciar, manteniendo el árbol anterior como una entrada de arranque para revertir cambios. Obtiene una máquina que está completamente actualizada o no lo está, sin estados intermedios. Se pierde la capacidad de instalar software editando archivos directamente, por lo que las aplicaciones se trasladan a contenedores o paquetes superpuestos.