Historia del kernel Linux: decisiones clave y su impacto

Resumen de la historia del kernel de Linux

La historia del kernel de Linux abarca desde la versión 0.01 en septiembre de 1991 hasta la serie 7.x que arranca hoy en los servidores. La lista de lanzamientos es la parte menos interesante. Un pequeño número de decisiones definieron la estructura del sistema, y cada una de ellas sigue teniendo consecuencias en la máquina que usted alquila esta tarde.

Las fechas y los números de versión aquí mencionados provienen de kernel.org y del historial de lanzamientos que publica. El estado actual, a agosto de 2026, es el siguiente: 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 se encuentra en fase de candidatos a lanzamiento (release candidates).

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

La versión 0.01 se publicó el 17 de septiembre de 1991 bajo una licencia que el propio Torvalds redactó. Esta requería que el código fuente fuera distribuido y añadía una línea más importante: "No puede distribuir esto a cambio de una tarifa, ni siquiera por gastos de 'gestión'". En 1991, el software se distribuía en disquetes, y copiar y enviar disquetes cuesta dinero. Esa cláusula hacía imposible una distribución comercial de Linux.

Él 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, en marzo de 1992, fue la primera versión publicada bajo esta licencia. Todo negocio construido posteriormente sobre Linux descansa en ese cambio.

El kernel es exclusivamente GPL versión 2 y nunca migró a la versión 3. Torvalds se negó en 2007, principalmente debido a la regla anti-tivoización de la GPLv3, que exige que un dispositivo que incluya código GPL también acepte una copia modificada de dicho código. Él consideró que el hardware bloqueado era un asunto exclusivo del fabricante. En 2017, los desarrolladores del kernel publicaron la Kernel Enforcement Statement, que toma prestado un elemento de la GPLv3: quien corrige una infracción tras ser notificado mantiene su licencia, en lugar de perderla permanentemente ante el primer incumplimiento.

Esto tiene dos consecuencias en un servidor. El binario del kernel que usted inicia conlleva el derecho a obtener el código fuente correspondiente, por lo que nadie puede entregarle un kernel de Linux que usted no pueda inspeccionar o recompilar. Además, el aviso de copyright del kernel establece que la licencia no cubre los programas de usuario que utilizan los servicios del kernel mediante llamadas al sistema estándar; por eso, las bases de datos y los agentes de monitorización propietarios se distribuyen para Linux sin infringir nada. Una licencia permisiva genera la presión opuesta, y vale la pena comprender esa diferencia antes de elegir una plataforma: consulte Linux y FreeBSD como plataformas de servidor.

Por qué el kernel monolítico ganó 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. Hizo dos afirmaciones. Los kernels monolíticos, donde los controladores y sistemas de archivos se ejecutan dentro de un mismo espacio de direcciones privilegiado, eran un diseño de la década de 1970, mientras que los microkernels, donde esas partes se ejecutan como procesos ordinarios, eran el futuro. Y Linux estaba atado al Intel 386, por lo que nunca viajaría.

La afirmación sobre la portabilidad fue respondida mediante la portabilidad. La versión 1.2 en marzo de 1995 añadió Alpha, SPARC y MIPS. La versión 2.0 en junio de 1996 añadió un puerto Alpha de 64 bits.

La afirmación sobre el diseño fue respondida mediante un compromiso. Linux nunca se convirtió en un microkernel. Obtuvo módulos de kernel cargables: archivos objeto que se insertan en un kernel en ejecución y se eliminan de nuevo, de modo que un controlador se distribuye por separado del binario del kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod enumera lo que está cargado en este momento. modinfo imprime el archivo del que proviene el módulo y los parámetros que acepta. En un servidor virtual, la mayor parte de la ruta de disco y red son módulos, razón por la cual una imagen de kernel arranca en hardware que nunca ha conocido.

Los módulos compraron esa flexibilidad sin el costo que conllevaba el diseño de microkernel. Aislar un controlador en su propio proceso significa pagar por un cambio de contexto y un mensaje en cada llamada, y en 1992 ese costo era elevado.

El costo que Linux mantuvo es el que se debe planificar: un módulo se ejecuta con privilegios completos de kernel, por lo que un módulo defectuoso derriba toda la máquina en lugar de un solo proceso. Los módulos fuera del árbol (out-of-tree) son donde esto afecta. Un controlador de proveedor que no está en la línea principal (mainline) debe reconstruirse contra cada nuevo kernel, que es lo que hace DKMS durante una actualización, y cuando esa compilación falla, el dispositivo simplemente desaparece después del reinicio.

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

Linux 2.0 en junio de 1996 fue el primer kernel en soportar multiprocesamiento simétrico (SMP), lo que significa más de una CPU ejecutando un mismo kernel. La primera implementación utilizaba un único bloqueo, el big kernel lock (BKL), por lo que solo un procesador podía estar dentro del código del kernel a la vez. Por tanto, una segunda CPU ayudaba en una carga de trabajo que computara en espacio de usuario, pero ayudaba muy poco con una carga de llamadas al sistema, ya que estas se encolaban detrás del mismo bloqueo.

Eliminar ese bloqueo llevó quince años. Los usuarios restantes fueron migrados a bloqueos de grano fino, en gran medida por Arnd Bergmann, y el BKL fue eliminado en la versión 2.6.39, lanzada el 18 de mayo de 2011. El planificador avanzó a la misma escala de tiempo lenta: el planificador O(1) en la 2.6.0, el Completely Fair Scheduler (CFS) a partir de la 2.6.23 en 2007, y EEVDF, que reemplazó a CFS en la 6.6 en octubre de 2023.

Ese trabajo es la razón por la que un plan de 4 vCPU no es nada extraordinario hoy en día. También marca un límite que conviene conocer. En un servidor virtual compartido, su kernel planifica sus hilos y el hipervisor planifica su kernel. Ejecute top y lea el campo %st. El steal time es tiempo de CPU que su kernel estaba listo para usar y que el host entregó a otro invitado, por lo que ningún ajuste dentro de su kernel puede recuperarlo.

Por qué la serie 2.6 cambió la forma en que se compila el kernel

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

La división se eliminó después de la 2.6. La línea principal ahora abre una ventana de fusión de unas dos semanas, acepta nuevo trabajo, luego ejecuta candidatos de lanzamiento hasta que la actividad disminuye y realiza un lanzamiento cada 9 a 10 semanas, la cadencia que kernel.org todavía documenta. La otra mitad del modelo llegó el 4 de marzo de 2005 con el primer lanzamiento del árbol estable, una actualización exclusiva de correcciones para la 2.6.11, mantenida por Greg Kroah-Hartman y Chris Wright. El árbol estable acepta correcciones y rechaza funcionalidades nuevas.

Un efecto secundario: el número de versión dejó de ser una promesa. Las versiones 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 resultarle molesto, razón por la cual la 7.0 sucedió a la 6.19 en abril de 2026. Lo que importa para un servidor es qué rama sigue su distribución y si esa rama todavía recibe correcciones.

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

Desde febrero de 2002, el kernel se desarrolló en BitKeeper, un sistema de control de versiones distribuido y propietario de la empresa BitMover de Larry McVoy, comenzando con la serie 2.5. BitMover otorgó a los desarrolladores del kernel una licencia gratuita con condiciones: no se podía trabajar en una herramienta de control de versiones de la competencia y no se podía realizar ingeniería inversa en BitKeeper. A muchos desarrolladores no les agradaba construir un kernel libre con una herramienta que no tenían permitido analizar.

La relación se rompió en abril de 2005, después de que Andrew Tridgell demostrara un programa que interactuaba con repositorios de BitKeeper. BitMover calificó esto como ingeniería inversa y retiró la licencia gratuita. El kernel perdió su sistema de control de versiones en medio 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 era autohospedado, lo que significa que el propio historial de git ya se guardaba en git. La primera fusió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 entregó el mantenimiento a Junio Hamano y regresó al kernel.

El diseño surgió directamente del problema: miles de colaboradores y mantenedores que extraen código unos de otros a través de una red en la que nadie confía. Cada objeto se nombra mediante el hash de su contenido, por lo que cambiar un solo byte del historial antiguo cambia el nombre de cada commit posterior. Es por eso que un clon es una evidencia más que una simple declaración. Cada canalización de despliegue, cada repositorio de configuración, el host de código al que la mayoría de los equipos envían sus cambios y el servidor git que usted mismo puede ejecutar surgieron de una disputa de licencias sobre un kernel.

Lo que promete el modelo LTS y lo que no

Mainline no es lo que usted ejecuta. Una versión mainline es reemplazada entre 9 y 10 semanas después. El árbol estable incluye correcciones durante unas pocas semanas tras cada lanzamiento. Las ramas Longterm, habitualmente denominadas LTS, las mantienen durante años, y son sobre las que construyen las distribuciones.

La versión 2.6.32, lanzada en diciembre de 2009, fue donde el modelo demostró su valía. 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 aparición.

La promesa ha cambiado más de una vez. Fueron dos años, luego seis años para algunas ramas. En 2023, los mantenedores de la rama estable redujeron el valor predeterminado a dos años, porque realizar backports en árboles antiguos consume tiempo de los mantenedores y las ramas antiguas reciben pocas pruebas reales. El 25 de febrero de 2026, Greg Kroah-Hartman publicó de nuevo proyecciones más largas, tras consultar con las empresas que dependen de esas ramas, y 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 enumera 6 ramas longterm a fecha de 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, tiene prevista su finalización en Dec 2028, lo que supone 3.1 años de correcciones.

Considere esas fechas como un mínimo y no como un contrato. Las proyecciones de 6.6 y 6.12 se desplazaron hacia adelante en febrero de 2026, y una rama que nadie utiliza puede ser eliminada antes. Su distribución normalmente toma la decisión por usted: Debian 13 incluye la 6.12, y Ubuntu 26.04 LTS incluye la 7.0. Esa diferencia es el contenido práctico de la cuestión de LTS frente a versiones intermedias en un servidor, y es lo que realmente cambia bajo el sistema cuando actualiza Ubuntu 24.04 a 26.04.

De esto se deriva una trampa. uname -r en Ubuntu 24.04 muestra algo parecido a 6.8.0-51-generic. Eso es una base upstream más los backports propios de la distribución, por lo que el número le indica dónde comenzó la rama y no qué correcciones contiene. Los escáneres que evalúan un kernel por su cadena de versión generan falsas alarmas contra los kernels de las distribuciones precisamente por este motivo.

Sobre qué discute el kernel actualmente

Existen dos debates activos, y ambos tratan sobre quién debe realizar el trabajo.

Rust se integró como infraestructura en la versión 6.1 en diciembre de 2022. En la 7.0 se eliminó la etiqueta de experimental, por lo que los lenguajes principales del kernel son C, ensamblador y Rust, y la compilación ya no requiere un compilador nightly. La disputa gira en torno al mantenimiento. Un mantenedor de C que modifica una interfaz puede romper los bindings de Rust que no lee, y la discusión trata sobre quién tiene la responsabilidad de repararlos.

El segundo debate es la contribución mediante IA. Sasha Levin propuso una política en julio de 2025, tras un aumento en el volumen de parches asistidos por máquinas en las listas de correo. El documento se integró el 23 de diciembre de 2025 y ahora forma parte de la documentación de procesos del kernel en docs.kernel.org/process/coding-assistants.html. Un agente de IA no debe añadir una etiqueta Signed-off-by, ya que esa línea certifica el Developer Certificate of Origin (DCO) y solo una persona puede certificarlo. La asistencia se declara con una etiqueta Assisted-by:, cambiada 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. El humano que envía el parche lo revisa y asume la responsabilidad del mismo.

La presión detrás de esta política es el tiempo de revisión. Generar un parche toma segundos, mientras que revisarlo consume la tarde de un mantenedor. Una etiqueta no soluciona ese desequilibrio. Lo que sí preserva es la procedencia: el historial sigue registrando quién firmó cada cambio, que es la propiedad que el DCO fue introducido para proteger en 2004.

Lo que esta historia significa para el servidor que alquila

• La licencia es el motivo por el cual puede leer y reconstruir el kernel que arranca su proveedor, y por el cual el software propietario sigue ejecutándose en él.
• El diseño monolítico es la razón por la que un error en un controlador reinicia toda la máquina, y por la que un módulo fuera del árbol (out-of-tree) debe reconstruirse en cada actualización del kernel.
• El modelo de versiones es la razón por la cual el número de versión le dice poco, mientras que la rama y su fecha de fin de vida útil le dicen casi todo.
• El tipo de virtualización decide lo que puede hacer: en KVM arranca su propio kernel y carga módulos, mientras que en la virtualización por contenedores que comparte el kernel del host, uname -r muestra la versión del host, modprobe falla y varios sysctls son de solo lectura.

FAQ

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

Torvalds decidió no adoptar la GPLv3 en 2007, principalmente debido a su requisito contra la "tivoización", que obliga a que un dispositivo que distribuye código GPL también acepte una versión modificada de dicho código. Él considera que el hardware bloqueado es un asunto del fabricante. Además, el cambio de licencia es prácticamente imposible, ya que los derechos de autor del kernel pertenecen a miles de colaboradores y no existe un acuerdo de cesión de derechos al que recurrir. El kernel es exclusivamente GPL-2.0, por lo que el código ofrecido únicamente bajo GPLv3 no puede integrarse.

¿Es el kernel de Linux un kernel monolítico o un microkernel?

Es monolítico, con módulos cargables. Los controladores y sistemas de archivos se ejecutan dentro del espacio de direcciones del kernel, y lsmod muestra los que están cargados en este momento. El resultado es velocidad por un lado y un mayor radio de impacto por otro: un módulo defectuoso puede provocar un kernel panic en toda la máquina, mientras que en un microkernel solo se perdería un proceso. El panorama ha cambiado desde 1992 gracias a los sistemas de archivos FUSE en 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, que se lanza cada 9 a 10 semanas, y es donde aterrizan primero las nuevas funcionalidades. Stable toma la versión mainline más reciente y recibe correcciones de errores durante unas semanas. Las ramas longterm siguen recibiendo correcciones durante años, y son sobre las que las distribuciones construyen sus kernels. kernel.org enumera las ramas longterm actuales con una fecha de fin de vida útil proyectada para cada una.

¿Acepta el kernel de Linux código escrito por IA?

Sí, bajo una política establecida en diciembre de 2025. La herramienta debe ser nombrada 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 código, lo que significa que ha revisado el parche y asume la responsabilidad del mismo bajo el Developer Certificate of Origin.

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

La que mantenga su distribución, en casi todos los casos. Un kernel de distribución es una rama longterm con correcciones adaptadas (backported) y las pruebas del proveedor, y es sobre lo que se basan las imágenes de su proveedor y sus acuerdos de soporte. Compile un kernel mainline más reciente cuando necesite un controlador o una funcionalidad específica, y verifique la fecha de fin de vida útil de la rama a la que se va a cambiar antes de comprometerse con ella.