Historia del kernel Linux: decisiones que aún importan

Versión breve de la historia del kernel de Linux

La historia del kernel de Linux va desde la versión 0.01, publicada en septiembre de 1991, hasta la serie 7.x, que hoy arranca en servidores. La lista de versiones es la parte menos interesante. Un pequeño número de decisiones definió su estructura, y cada una todavía tiene consecuencias en una máquina que alquile esta tarde. La razón por la que en 1991 hacía falta un kernel nuevo pertenece a la historia más amplia de Unix, las licencias de AT&T y la demanda que frenó BSD.

Las fechas y los números de versión proceden de kernel.org y del historial de versiones que publica. Estado actual a agosto de 2026: la versión 7.0 llegó el 12 de abril de 2026, la 7.1 el 14 de junio de 2026 y la 7.2 está en fase de release candidates.

Por qué sigue siendo importante la elección de la GPL en 1992

La versión 0.01 se publicó el 17 de septiembre de 1991 con una licencia que Torvalds había escrito personalmente. Exigía distribuir el código fuente y añadía una línea aún más importante: "No puede distribuir esto a cambio de una tarifa, ni siquiera por los costes de 'gestión'". En 1991, el software se distribuía en disquetes, y copiar y enviar disquetes costaba dinero. Esa cláusula hacía imposible una distribución comercial de Linux.

La cambió. El paso a la GNU General Public License (GPL) se anunció en las notas de la versión 0.12 en enero de 1992 y entró en vigor el 1 de febrero de 1992. La versión 0.95, publicada en marzo de 1992, fue la primera versión distribuida con esa licencia. Todas las empresas creadas posteriormente sobre Linux se basan en ese cambio.

El kernel está sujeto únicamente a la versión 2 de la GPL y nunca pasó a la versión 3. Torvalds se negó en 2007, sobre todo por la regla contra la tivoización de GPLv3, que exige que un dispositivo que distribuya código GPL también permita aceptar una copia modificada de ese código. Consideraba que el hardware bloqueado era una decisión comercial del fabricante. En 2017, los desarrolladores del kernel publicaron el Kernel Enforcement Statement, que incorpora de todos modos una parte de GPLv3: quien corrige una infracción después de recibir una notificación conserva su licencia, en lugar de perderla permanentemente con la primera infracción.

De esto se derivan dos consecuencias en un servidor. El binario del kernel que arranca incluye el derecho a obtener el código fuente correspondiente, por lo que nadie puede entregarte un kernel de Linux que no puedas inspeccionar o recompilar. Además, el aviso de copyright del kernel indica que la licencia no cubre los programas de usuario que utilizan los servicios del kernel mediante llamadas de sistema normales. Por eso las bases de datos propietarias y los agentes de monitorización se distribuyen para Linux sin infringir la licencia. Una licencia permisiva genera una presión opuesta. Conviene entender esta diferencia antes de elegir una plataforma: consulta Linux y FreeBSD como plataformas de servidor.

Por qué el kernel monolítico se impuso en la práctica

El 29 de enero de 1992, Andrew Tanenbaum publicó un mensaje titulado "LINUX is obsolete" en el grupo de noticias comp.os.minix. Presentó dos argumentos. Los kernels monolíticos, en los que los controladores y los sistemas de archivos se ejecutan dentro de un único espacio de direcciones privilegiado, eran un diseño de la década de 1970. Los microkernels, en los que esas partes se ejecutan como procesos normales, eran el futuro. Además, Linux estaba estrechamente ligado al Intel 386, por lo que nunca sería portable.

La afirmación sobre la portabilidad se respondió mediante ports. La versión 1.2, publicada en marzo de 1995, añadió Alpha, SPARC y MIPS. La versión 2.0, publicada en junio de 1996, añadió un port de Alpha de 64 bits.

La afirmación sobre el diseño se respondió con un compromiso. Linux nunca se convirtió en un microkernel. Incorporó módulos de kernel cargables: archivos de objeto que se insertan en un kernel en ejecución y se pueden retirar después, de modo que un controlador se distribuye por separado del binario del kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod muestra lo que está cargado en ese momento. modinfo muestra el archivo del que procede el módulo y los parámetros que acepta. En un servidor virtual, gran parte de la ruta de almacenamiento y red depende de módulos. Por eso una misma imagen del kernel puede arrancar en hardware que nunca ha visto. El kernel sólo anuncia el hardware nuevo. Después, un daemon de user space decide qué módulo cargar y qué nombre asignar al dispositivo. Así, la gestión de dispositivos pasó a integrarse en el sistema init. Esto también explica en parte por qué systemd se volvió difícil de evitar.

Los módulos proporcionaron esa flexibilidad sin asumir el coste del diseño de microkernel. Aislar un controlador en su propio proceso implica pagar un cambio de contexto y el envío de un mensaje en cada llamada. En 1992, ese coste era elevado.

El coste que Linux conserva es el que debe tener en cuenta: un módulo se ejecuta con privilegios completos de kernel. Por eso, un módulo defectuoso puede detener toda la máquina en lugar de afectar sólo a un proceso. El problema es especialmente visible con los módulos externos al árbol principal. Un controlador de un proveedor que no está incluido en mainline debe recompilarse para cada kernel nuevo. Eso es lo que hace DKMS durante una actualización. Si la compilación falla, el dispositivo simplemente no estará disponible después del reinicio.

Por qué SMP tardó quince años en completarse

Linux 2.0, publicado en junio de 1996, fue el primer kernel compatible con el multiprocesamiento simétrico (SMP), es decir, con más de una CPU ejecutando un mismo kernel. La primera implementación usaba un único bloqueo, el bloqueo grande del kernel (BKL), por lo que sólo un procesador podía ejecutar código del kernel en cada momento. Por tanto, una segunda CPU ayudaba a las cargas que calculaban en el espacio de usuario, pero ayudaba muy poco con las cargas basadas en llamadas al sistema, porque esas llamadas quedaban en cola detrás del mismo bloqueo.

Eliminar ese bloqueo tardó quince años. Los usos restantes se convirtieron para utilizar bloqueos de grano fino, en gran medida gracias a Arnd Bergmann, y el BKL se eliminó en 2.6.39, publicado el 18 de mayo de 2011. El planificador avanzó en una escala temporal igualmente lenta: el planificador O(1) en 2.6.0, el Completely Fair Scheduler (CFS) desde 2.6.23 en 2007 y EEVDF, que sustituyó a CFS en 6.6 en octubre de 2023.

Ese trabajo explica por qué un plan de 4 vCPU no resulta excepcional actualmente. También señala un límite que conviene conocer. En un servidor virtual compartido, el kernel planifica los hilos y el hipervisor planifica el kernel. Ejecute top y lea el campo %st. El tiempo de steal es el tiempo de CPU que el kernel estaba preparado para utilizar, pero que el host asignó a otro invitado. Por tanto, ningún ajuste dentro del kernel puede recuperarlo.

Por qué la serie 2.6 cambió la forma de compilar el kernel

Antes de 2.6, los números de versión se dividían en pares. Un segundo número par indicaba una serie estable (2.4); uno impar indicaba desarrollo (2.5). 2.4 se publicó el 4 de enero de 2001 y 2.6 el 17 de diciembre de 2003, por lo que los usuarios esperaron casi tres años hasta la siguiente serie estable. Las distribuciones no podían esperar y aplicaban backports. Dos proveedores que distribuían "2.4" podían entregar kernels con miles de parches de diferencia.

La separación se abandonó después de 2.6. Ahora mainline abre una ventana de integración de unas dos semanas, incorpora trabajo nuevo, ejecuta release candidates hasta que el desarrollo se estabiliza y publica una versión cada 9 o 10 semanas, según la cadencia que kernel.org sigue documentando. La otra mitad del modelo llegó el 4 de marzo de 2005 con la primera versión del stable tree: una actualización que sólo incluía correcciones para 2.6.11, mantenida por Greg Kroah-Hartman y Chris Wright. El stable tree acepta correcciones y rechaza funcionalidades.

Un efecto secundario fue que el número de versión dejó de ser una garantía. 3.0, 4.0, 5.0 y 7.0 no son reescrituras. Torvalds aumenta el primer número cuando el segundo crece lo suficiente como para molestarlo; por eso 7.0 siguió a 6.19 en abril de 2026. Para un servidor, lo importante es qué rama sigue la distribución y si esa rama todavía recibe correcciones.

Cómo la ruptura con BitKeeper produjo git en abril de 2005

Desde febrero de 2002, el kernel se desarrollaba en BitKeeper, un sistema de control de versiones distribuido y propietario de la empresa BitMover, de Larry McVoy. Se empezó a utilizar con la serie 2.5. BitMover ofrecía a los desarrolladores del kernel una licencia gratuita con condiciones: no podían trabajar en una herramienta de control de versiones competidora y no podían aplicar ingeniería inversa a BitKeeper. A muchos desarrolladores no les gustaba crear un kernel libre con una herramienta cuyo código no podían leer.

La relación se rompió en abril de 2005, después de que Andrew Tridgell demostrara un programa que se comunicaba con repositorios de BitKeeper. BitMover consideró que eso era ingeniería inversa y retiró la licencia gratuita. El kernel perdió su sistema de control de versiones en mitad de un ciclo de desarrollo.

El trabajo en git comenzó el 3 de abril de 2005. Torvalds lo anunció el 6 de abril. El 7 de abril, git ya se gestionaba a sí mismo: su propio historial ya se almacenaba en git. La primera combinación de varias ramas se ejecutó el 18 de abril. En junio de 2005, git gestionó el lanzamiento de 2.6.12. Poco después, Torvalds cedió el mantenimiento a Junio Hamano y volvió al kernel.

El diseño surgió directamente del problema: miles de colaboradores y mantenedores que extraen cambios unos de otros a través de una red en la que nadie confía. Cada objeto recibe como nombre el hash de su contenido, por lo que cambiar un solo byte del historial antiguo cambia el nombre de cada commit posterior. Por eso un clon es una prueba, no una afirmación. Cada pipeline de despliegue, cada repositorio de configuración, el host de código al que envían cambios la mayoría de los equipos y el servidor git que puede ejecutar usted mismo surgieron de una discusión sobre licencias relacionada con un kernel.

Qué promete el modelo LTS y qué no

Mainline no es lo que se ejecuta en producción. Una versión mainline queda sustituida entre 9 y 10 semanas después. La rama estable recibe correcciones durante unas semanas después de cada versión. Las ramas longterm, normalmente denominadas LTS, reciben correcciones durante años. Son las ramas en las que se basan las distribuciones.

2.6.32, publicada en diciembre de 2009, demostró que el modelo funcionaba. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 y Ubuntu 10.04 LTS la incluyeron, y la rama se mantuvo hasta febrero de 2016, más de seis años después de su publicación. Red Hat fue aún más lejos y mantuvo su kernel basado en 2.6.32 con sus propios backports hasta que RHEL 6 dejó de mantenerse en 2020. Reproducir gratis esa década de soporte es el motivo por el que existió CentOS y lo sustituyeron Rocky Linux y AlmaLinux.

La promesa ha cambiado más de una vez. Primero fueron dos años y después seis años para algunas ramas. En 2023, los mantenedores de stable redujeron de nuevo el valor predeterminado a dos años, porque adaptar correcciones a árboles antiguos consume tiempo de los mantenedores y las ramas antiguas reciben pocas pruebas reales. El 25 de febrero de 2026, Greg Kroah-Hartman volvió a publicar previsiones más largas, después de hablar con las empresas que dependen de esas ramas. El marco actual abarca de tres a seis años.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org muestra 6 ramas longterm en agosto de 2026. La más antigua, 5.10, habrá recibido correcciones durante 6.0 años cuando finalice en Dec 2026. La más reciente, 6.18, está prevista hasta Dec 2028, lo que supone 3.1 años de correcciones.

Interprete esas fechas como un mínimo, no como un contrato. Las previsiones de 6.6 y 6.12 se ampliaron en febrero de 2026, pero una rama que nadie utiliza puede dejar de mantenerse. Normalmente, la distribución toma la decisión por usted: Debian 13 incluye 6.12 y Ubuntu 26.04 LTS incluye 7.0. Esa diferencia es el contenido práctico de la cuestión de LTS frente a una versión intermedia en un servidor, y es lo que realmente cambia internamente cuando actualiza Ubuntu 24.04 a 26.04.

De aquí se deriva una confusión frecuente. uname -r en Ubuntu 24.04 muestra algo parecido a 6.8.0-51-generic. Ese valor combina una base del proyecto upstream con los backports propios de la distribución. Por tanto, el número indica dónde comenzó la rama, pero no qué correcciones contiene. Los escáneres que evalúan un kernel mediante su cadena de versión generan alertas falsas contra los kernels de las distribuciones precisamente por este motivo.

De qué está discutiendo el kernel ahora mismo

Hay dos debates abiertos, y ambos tratan sobre quién hace el trabajo.

Rust se incorporó como infraestructura en 6.1, en diciembre de 2022. En 7.0 se eliminó la etiqueta experimental, por lo que los lenguajes principales del kernel son C, ensamblador y Rust, y la compilación ya no necesita un compilador nightly. El debate trata sobre el mantenimiento. Un mantenedor de C que cambia una interfaz puede romper bindings de Rust que no lee, y la discusión se centra en quién debe repararlos.

El segundo debate trata sobre las contribuciones de la IA. Sasha Levin propuso una política en julio de 2025, después de que un volumen creciente de parches asistidos por máquinas llegara a las listas. El documento se incorporó el 23 de diciembre de 2025 y ahora forma parte de la documentación del proceso del propio kernel en docs.kernel.org/process/coding-assistants.html. Un agente de IA no debe añadir una etiqueta Signed-off-by, porque esa línea certifica el Developer Certificate of Origin (DCO) y sólo una persona puede certificarlo. La asistencia se declara con una etiqueta Assisted-by:, modificada desde Co-developed-by: durante la revisión porque una herramienta no es un autor. El código generado debe ser compatible con GPL-2.0-only. La persona que envía el parche lo revisa y asume la responsabilidad correspondiente.

La presión que motiva esta política es el tiempo de revisión. Generar un parche lleva segundos, mientras que revisarlo puede ocupar toda la tarde de un mantenedor. Una etiqueta no corrige ese desequilibrio. Lo que sí conserva es la procedencia: el historial sigue registrando quién firmó cada cambio, que es precisamente la propiedad que el DCO se creó para proteger en 2004.

Qué significa este historial para el servidor que alquila

• La licencia permite leer y reconstruir el kernel que arranca su proveedor, y explica por qué el software propietario sigue funcionando en él.
• El diseño monolítico explica por qué un error en un controlador reinicia toda la máquina y por qué un módulo externo al árbol debe reconstruirse después de cada actualización del kernel.
• El modelo de publicación explica por qué el número de versión aporta poca información, mientras que la rama y su fecha de fin de vida útil indican casi todo.
• El tipo de virtualización determina qué puede hacer: en KVM puede arrancar su propio kernel y cargar módulos, mientras que en la virtualización basada en contenedores, que comparte el kernel del host, uname -r muestra la versión del host, modprobe falla y varios sysctl son de solo lectura.

FAQ

¿Por qué el kernel de Linux sigue bajo GPLv2 y no bajo GPLv3?

Torvalds descartó GPLv3 en 2007, principalmente por su requisito contra la tivoización, que obliga a un dispositivo que distribuye código GPL a aceptar también una versión modificada de ese código. Considera que el hardware bloqueado forma parte del negocio del fabricante. Además, relicenciar el kernel es prácticamente imposible, porque los derechos de autor pertenecen a miles de colaboradores y no existe un acuerdo de cesión al que recurrir. El kernel usa GPL-2.0-only, por lo que el código ofrecido únicamente bajo GPLv3 no se puede integrar.

¿El kernel de Linux es monolítico o es un microkernel?

Es monolítico y admite módulos cargables. Los controladores y los sistemas de archivos se ejecutan dentro del espacio de direcciones del kernel, y lsmod muestra los que están cargados actualmente. El resultado ofrece velocidad, pero también un mayor radio de impacto: un módulo defectuoso puede provocar un panic en toda la máquina, mientras que un microkernel perdería un solo proceso. Esta diferencia se ha reducido desde 1992 gracias a los sistemas de archivos FUSE en el espacio de usuario y a los programas eBPF que el kernel verifica antes de ejecutarlos.

¿Cuál es la diferencia entre los kernels mainline, stable y longterm?

Mainline es el árbol de Torvalds. Se publica cada 9 a 10 semanas y las funciones nuevas llegan primero allí. Stable toma la versión más reciente de mainline y recibe correcciones de errores durante unas semanas. Las ramas longterm siguen recibiendo correcciones durante años, y son la base de los kernels que compilan las distribuciones. kernel.org muestra las ramas longterm actuales con una fecha prevista de fin de vida para cada una.

¿El kernel de Linux acepta código escrito por una IA?

Sí, conforme a una política adoptada en diciembre de 2025. La herramienta debe indicarse en una etiqueta Assisted-by:, un agente de IA no debe añadir una línea Signed-off-by y el código generado debe ser compatible con GPL-2.0-only. El remitente humano firma el cambio, lo que significa que revisó el parche y asume la responsabilidad correspondiente conforme al Developer Certificate of Origin.

¿Qué versión del kernel debería ejecutar en un servidor?

En casi todos los casos, la que mantenga su distribución. El kernel de una distribución combina una rama longterm, correcciones retroportadas y las pruebas del proveedor. Además, es el kernel que presuponen las imágenes de su proveedor y sus acuerdos de soporte. Compile un kernel mainline más reciente cuando necesite un controlador o una función concretos. Antes de adoptarlo, compruebe la fecha de fin de vida de la rama a la que va a migrar.