Cuando casi 20.000 commits caen en una sola ventana de fusión, lo lógico sería esperar una segunda versión de pruebas explosiva. Linux 7.4-rc2, publicada el 9 de noviembre de 2026, hace justo lo contrario: Linus Torvalds la describe como bastante benigna, y tiene sus razones. Lo interesante no es lo que dice el número, sino lo que se esconde dentro de él.
Primero, un poco de contexto. Una versión candidata, o rc, no es un lanzamiento: es una instantánea semanal para que los testers cacen regresiones antes de la versión final. En teoría, a partir del rc1 solo deberían entrar correcciones de errores, no funciones nuevas. El rc2 llegó ocho días después del rc1, y es el segundo de los siete u ocho puntos de control habituales. Cuando toque el rc7 o el rc8, el 7.4 estará prácticamente hecho.
El tamaño del rc2 se explica en buena parte por una decisión de Torvalds. Durante la ventana de fusión recogió un buen montón de conversiones automáticas hechas con Coccinelle, una herramienta que aplica cambios mecánicos sobre el código mediante scripts, y las dejó aparcadas para el rc2. Confesó que no quería lidiar con ellas durante un viaje y que, siendo sinceros, tampoco le apetecía después. Son sobre todo cambios de una o dos líneas repartidos por miles de archivos, que inflan el diffstat, el resumen estadístico de líneas tocadas, sin aportar demasiado contenido. A eso se suman los volcados de registros de GPU de AMD, que también engordaron el volumen del ciclo.
Si restas ese ruido, el parche se reparte en tres bloques más o menos parejos: controladores (GPU, red, sonido), red y BPF, y el resto, que incluye sistemas de archivos, gestión de memoria y actualizaciones de arquitectura. Dicho de otro modo, lo que parece un rc2 gigantesco es en realidad uno bastante normal con mucho maquillaje numérico.
Aun así, hay corrección real y de la que importa. La que más se notará en el día a día es una aceleración de FAT32. Matheus Alves de Almeida hace que el sistema preasigne espacio antes de que los archivos crezcan, con un nuevo ayudante llamado fat_preallocate() y una ruta específica para FAT que evita volver a comprobar el tamaño del archivo. Los benchmarks de Phoronix hablan de mejoras de hasta unas 162 veces, pero ojo con el contexto: son montajes síncronos con clústeres pequeños, un escenario concreto y no el copiado habitual de fotos a un pendrive. Otra optimización de FAT, fusionada antes en el ciclo, llegaba a anunciar hasta 265 veces en condiciones parecidas.
En gestión de memoria hay un cambio estructural: un nuevo árbol Core MM que enruta algunos parches a través de David Hildenbrand y no solo de Andrew Morton. Este primer lote destapó lo que el propio Hildenbrand llamó errores desagradables y de larga duración, repartidos por páginas enormes transparentes, GUP, KSM, userfaultfd, hmem, memfd y hugetlb. Las correcciones abarcan fugas de información, escrituras fuera de límites, pérdida de datos, corrupción, usos después de liberar, bloqueos y bucles imposibles de matar.
BPF, el subsistema que permite ejecutar programas seguros dentro del kernel, se lleva otra buena ración: Alexei Starovoitov envió 40 parches y Chris Mason añadió otros 33, con arreglos de seguimiento escalar, manejo de pila, seguridad de arenas de memoria y casos límite de búferes de red. El resto del árbol incluye protección de concurrencia en Bluetooth, rechazo de marcas IPsec mal formadas en xfrm, correcciones en NVMe, trabajo de Sean Christopherson sobre el MMU de invitados en KVM y un barrido de 22 parches en hwmon de Guenter Roeck.
Aquí está la parte que va más allá de cualquier parche. Según la fuente, aproximadamente una quinta parte de lo publicado este ciclo viene de herramientas de IA, y Torvalds no lo disimula. Sobre el origen de las correcciones de memoria, Hildenbrand fue directo: la mayoría de los problemas los reportó Anthropic, otros aparecieron al rehacer correcciones propuestas y algunos simplemente se corrigieron en la lista de correo. Son informes reales llegando al buzón de seguridad del kernel, y en algunas áreas los mantenedores cuentan que las correcciones encontradas por IA empiezan a superar a los informes nuevos. BPF es la zona que Torvalds señaló como candidata a llegar a ese punto.
Su postura no es prohibir, sino ordenar el tiempo. Prefiere con mucho que la avalancha entre durante la ventana de fusión, filtrada por los mantenedores, antes que verla aparecer como correcciones sueltas durante las semanas de rc, que deberían quedar libres para perseguir regresiones de verdad. Es una teoría sensata, y este rc2 es su primera prueba seria. La fuente añade que el propio Torvalds ya se ayuda de herramientas como Claude Code para generar parches, un giro llamativo respecto a quien llegó a tachar buena parte de la industria de la IA de puro marketing. Conviene tomar ese dato con la prudencia debida, porque llega de segunda mano.
Lo que sostiene el sistema no es la herramienta, sino la cultura de revisión de los mantenedores y la regla de que cada parche lleva un nombre humano detrás. Si esa cadena se rompe, ningún volumen récord sirve de nada. El rc2 está pensado para desarrolladores y entusiastas, no para producción. Lo prudente es seguir con el kernel estable de tu distribución hasta que el 7.4 salga y acumule unas cuantas actualizaciones.
Si se mantiene el ritmo habitual, la versión final podría llegar sobre el 20 de diciembre con siete candidatas, o el 27 de diciembre con ocho. Además, se espera de forma generalizada que Greg Kroah-Hartman lo adopte como próximo kernel LTS a principios de 2027, lo que le daría años de correcciones retroportadas. Es una expectativa, no un anuncio, así que mejor no darla por hecha. Un kernel no se mide por lo grande que sea su ventana de fusión, sino por lo que aguanta después. Estas semanas de rc dirán si el proyecto puede absorber un volumen récord de cambios asistidos por IA sin que la estabilidad lo pague, y esa respuesta pesará más que cualquier cifra de commits. El propio Torvalds cerró su aviso sin triunfalismo: ni contener la respiración, ni dejar de probar.
Fuente: Phoronix
Añadir comentario
Comentarios