Linux 7.4-rc2 ya está fuera y trae una frase que llevaba meses sin oírse en el núcleo de Linux: en eBPF, las correcciones llegan más rápido que los reportes nuevos. Linus Torvalds publicó la segunda candidata el domingo 8 de noviembre a las 19:47, hora del este. Hay una primera señal de respiro, y viene del subsistema más castigado por la caza de fallos con inteligencia artificial.
Datos clave: versión, Linux 7.4-rc2, publicada el 8 de noviembre de 2026. Antecesora inmediata, la rc1 más grande registrada, con casi 20.000 envíos. Firma destacada de la rc2, Alexei Starovoitov, con 40 envíos en el registro corto. Frente citado, eBPF, donde corregir ya supera a reportar.
El tamaño marca el ciclo entero. La ventana de integración de la 7.4 reunió casi 20.000 envíos frente a unos 15.000 habituales, y esa ventana dejó piezas como OverlayFS y Linux 7.4 con la IA hallando fallas de seguridad. Torvalds lo repite con la rc2 en la mano: es otra candidata grande, pegada a la mayor primera candidata que recuerda el proyecto.
Parte de ese volumen tiene truco estadístico. El mantenedor guardó para esta semana una tanda de limpiezas automáticas hechas con Coccinelle, la herramienta que reescribe patrones de código en todo el árbol. Son cambios de una o dos líneas, repartidos por miles de archivos, y por eso la estadística de diferencias se ve enorme al primer vistazo.
Torvalds admite el motivo sin vueltas: recibió esas limpiezas durante la ventana de integración, estaba de viaje y prefirió no tocarlas con la rc1 ya saturada. Al filtrar ese ruido, el dibujo queda bastante normal. Nada de un área desbocada ni de un parche gigante con un solo dueño.
Un reparto en tercios y un nombre propio
Sin el ruido de las limpiezas, el resto se reparte en tres bloques parecidos. Un tercio va a controladores, con gráficos, red y sonido al frente. Otro tercio toca red y BPF. El tercio final se lo reparten sistemas de archivos, gestión de memoria y código de arquitectura. Es la foto típica de una candidata en fase de estabilización.
Dentro de ese reparto, un nombre se repite más que ningún otro. Alexei Starovoitov, cocreador de eBPF y responsable de su mantenimiento, firma 40 envíos en el registro corto de la rc2. eBPF permite correr programas pequeños en un entorno aislado dentro del propio núcleo, y sirve para red, observabilidad y seguridad. Es código delicado: un error ahí toca el corazón del sistema.
Phoronix, el medio que sigue cada candidata al detalle, destacó además trabajo concreto de esta entrega: una optimización de FAT32 con mejoras de hasta 162 veces en el caso medido y ajustes de AMDGPU ligados a HDMI 2.2. Son el tipo de cambios que un usuario nota sin saber de qué candidata vinieron: copiar a una memoria externa o conectar una pantalla.
El dato que Torvalds subrayó no fue un parche suelto. Fue una frase de Starovoitov: en el lado de BPF, las correcciones ya entran más rápido que los reportes nuevos. El mantenedor principal lo recibió con cautela pública. Suena muy bien si es cierto, escribió, y dejó la puerta abierta a que otras áreas tarden más en llegar a ese punto.
La cautela tiene historia detrás. Desde abril, cuando Anthropic puso en circulación Mythos, su modelo buscador de fallos, los equipos de mantenimiento reciben reportes a un ritmo que no existía. The Register reunió el contexto con cifras de la industria: Microsoft corrigió 974 fallos en septiembre, tras 622 en julio y 206 en junio, y Oracle atendió 1.449 en un solo mes.
Corregir deja de ser correr detrás
Torvalds lleva semanas con el mismo mensaje para quien desarrolla el núcleo: el trabajo disparado por la inteligencia artificial debe entrar en la ventana de integración, como desarrollo normal, y no caer en plena fase de estabilización como una lluvia de arreglos tardíos. Cada arreglo, venga de una persona o de un modelo, pasa por revisión humana y por la firma de un responsable.
Para el lector que usa Linux en el trabajo, la lectura práctica es directa. Una candidata rc2 no se instala en un servidor de producción: se prueba en una máquina secundaria, se revisa que arranque limpio y se reporta cualquier regresión con el registro en la mano. Las distribuciones hacen ese trabajo a gran escala y de ahí salen los avisos que depuran la versión final.
Conviene seguir este ciclo si el equipo depende de contenedores, redes rápidas o herramientas de observabilidad, porque eBPF sostiene buena parte de ese mundo. Si la corrección supera al reporte en ese subsistema, el beneficio baja en cadena: menos parches urgentes, menos reinicios forzados y una base más tranquila para los servicios que corren encima.
El calendario mantiene su ritmo semanal. Tras la rc2 quedan las candidatas rc3 a rc7 si nada se tuerce, con la versión final apuntando a finales de diciembre; OSTechNix citó el 20 de diciembre como fecha que maneja el equipo de mantenimiento. Torvalds cerró su mensaje con el pedido de siempre, el que sostiene todo el edificio: sigan probando.
