Linux 7.2 ya está aquí y, al menos para mí, es una de esas versiones del kernel que resultan más interesantes cuando dejas de buscar la gran característica revolucionaria y empiezas a mirar todo lo que ha cambiado debajo del capó.
No hay una única novedad que transforme por completo la experiencia de utilizar Linux. Lo que encontramos es algo diferente: mejoras en planificación de tareas, almacenamiento, gestión de memoria, gráficos, virtualización y compatibilidad con las próximas generaciones de hardware de AMD e Intel.
Y personalmente creo que eso es exactamente lo que debería hacer una buena actualización del kernel.
Linux lleva años enfrentándose a un hardware cada vez más complejo. Tenemos procesadores con más núcleos, diferentes niveles de caché, almacenamiento NVMe capaz de mover cantidades enormes de información, aceleradores especializados, sistemas de virtualización más sofisticados y tarjetas gráficas que requieren soporte para estándares cada vez más exigentes.
Linux 7.2 continúa adaptándose a ese escenario.
Entre sus novedades destaca especialmente Cache Aware Scheduling, una forma de planificación que intenta aprovechar mejor cómo están organizadas físicamente las cachés de los procesadores modernos. También encontramos optimizaciones de entrada y salida, cambios relacionados con Btrfs y memoria, más soporte para AMD e Intel, mejoras para AMDGPU y HDMI 2.1 FRL, novedades en virtualización confidencial y la retirada progresiva de componentes asociados a la veterana arquitectura i486.
Pero hay además otro cambio que quizá no aparece dentro de las especificaciones del kernel y que me parece igual de interesante: la creciente presencia de herramientas de inteligencia artificial y LLM en su proceso de desarrollo.
Todo junto hace que Linux 7.2 sea una versión bastante representativa de hacia dónde se dirige el kernel.
Cache Aware Scheduling: Linux 7.2 quiere aprovechar mejor la caché de la CPU
Una de las novedades de Linux 7.2 que más me interesa es la llamada Cache Aware Scheduling, o planificación con reconocimiento de caché.
Dicho así puede sonar como una optimización extremadamente técnica y bastante alejada del usuario normal. En realidad, la idea que existe detrás es relativamente sencilla: cuando el kernel decide dónde ejecutar determinadas tareas, no siempre debería considerar todos los núcleos equivalentes desde el punto de vista del acceso a memoria y caché.
Qué es la programación con reconocimiento de caché
Los procesadores modernos disponen de diferentes niveles de memoria caché. Algunas cachés pertenecen a un núcleo concreto mientras que otras, como determinadas Last Level Cache o LLC, pueden ser compartidas por grupos de núcleos.
Eso significa que dos núcleos que parecen similares desde fuera pueden encontrarse en posiciones distintas dentro de la topología interna del procesador.
Si tenemos varias tareas estrechamente relacionadas que acceden continuamente a los mismos datos, enviarlas sin ningún tipo de consideración a núcleos que no comparten la misma caché puede generar trabajo adicional.
Hay que mover información, volver a cargar determinados datos y realizar accesos que potencialmente podrían haberse evitado.
La planificación consciente de caché intenta que el scheduler tenga más información sobre esa organización.
No se trata simplemente de decir “este procesador tiene 32 núcleos y podemos utilizar cualquiera de ellos”. La pregunta pasa a ser algo más parecida a:
¿Qué núcleos comparten recursos y dónde tiene más sentido ejecutar conjuntamente estas tareas?
Con procesadores cada vez más complejos, esta cuestión tiene bastante sentido.
Por qué compartir la caché de último nivel puede afectar al rendimiento
En cargas de trabajo paralelas, el rendimiento no depende únicamente de cuántos núcleos tengamos.
También importa cuánto tardan esos núcleos en acceder a los datos que necesitan.
Cuando varias tareas comparten mucha información, mantenerlas en una zona del procesador donde puedan aprovechar mejor una caché común puede reducir determinados accesos y mejorar la eficiencia.
Eso resulta especialmente interesante en servidores y máquinas con muchos núcleos, donde la topología interna puede ser bastante más compleja que en un PC doméstico convencional.
Es también una buena muestra de cómo está cambiando la optimización de sistemas operativos.
Durante años, aumentar el rendimiento consistía muchas veces en tener una CPU más rápida. Ahora tenemos que aprovechar correctamente arquitecturas con numerosos núcleos, jerarquías de memoria diferentes y recursos compartidos.
El sistema operativo necesita saber cada vez más cómo está construido físicamente el procesador.
¿Va a hacer Linux 7.2 que cualquier PC sea más rápido?
Aquí conviene controlar bastante las expectativas.
No significa que instalemos Linux 7.2 y automáticamente todos nuestros programas vayan a funcionar mucho más rápido.
En mi caso, este tipo de optimizaciones me parecen interesantes precisamente porque no las interpreto como un supuesto “turbo” universal.
La mejora dependerá muchísimo del procesador, de su topología y, sobre todo, de la carga de trabajo.
Habrá situaciones donde organizar mejor las tareas alrededor de las cachés compartidas pueda aportar beneficios perceptibles y otras donde prácticamente no exista diferencia.
Aun así, me parece una dirección muy lógica para Linux.
Cuantos más núcleos y estructuras internas distintas tengan las próximas generaciones de CPU, más importante será que el scheduler no vea el procesador simplemente como una colección plana de núcleos idénticos.
Mejoras de rendimiento en almacenamiento, I/O y memoria
Cuando hablamos de una nueva versión del kernel es bastante habitual fijarnos primero en los procesadores y las tarjetas gráficas.
Sin embargo, en servidores y estaciones de trabajo el rendimiento del almacenamiento puede ser igual o incluso más importante.
Linux 7.2 introduce diferentes cambios relacionados con la entrada y salida, los sistemas de archivos y la gestión de memoria, continuando el trabajo de optimización que lleva realizándose durante varias versiones.
Y aquí encontramos precisamente uno de los apartados donde una mejora aparentemente pequeña dentro del kernel puede terminar teniendo consecuencias bastante mayores en determinadas cargas reales.
Cambios en la entrada y salida que pueden importar en servidores
Los dispositivos NVMe modernos pueden alcanzar niveles de rendimiento enormes. A medida que el almacenamiento se vuelve más rápido, la propia sobrecarga que introduce el sistema operativo adquiere más importancia.
Cuando un SSD era relativamente lento, unas pequeñas ineficiencias podían quedar ocultas detrás de la latencia del propio dispositivo.
Cuando tenemos almacenamiento capaz de procesar cantidades muy elevadas de operaciones por segundo, reducir trabajo innecesario dentro de la ruta de entrada y salida empieza a importar mucho más.
Por eso personalmente me resultan interesantes las optimizaciones de I/O que llegan con Linux 7.2.
No necesariamente porque vayan a convertir cualquier SSD en uno mucho más rápido, sino porque el kernel necesita seguir adaptándose a dispositivos capaces de mover datos a velocidades que hace pocos años eran difíciles de imaginar en un sistema convencional.
Hay cargas donde esto puede ser especialmente importante.
Pienso, por ejemplo, en bases de datos, plataformas de virtualización, servidores que manejan numerosos archivos y aplicaciones que realizan muchas operaciones simultáneas sobre disco.
En esos escenarios, pequeñas mejoras acumuladas pueden terminar produciendo diferencias apreciables.
Btrfs también mejora en Linux 7.2
Btrfs vuelve a recibir atención en esta versión del kernel.
Linux 7.2 continúa optimizando determinadas operaciones del sistema de archivos, incluyendo cambios relacionados con su rendimiento y la manera de gestionar diferentes operaciones de lectura y escritura.
Esto es particularmente relevante porque Btrfs lleva años pasando de ser una tecnología que muchos usuarios consideraban experimental a convertirse en una opción habitual dentro de algunas distribuciones Linux.
Cuanto mayor es su adopción, mayor importancia adquieren las optimizaciones que no necesariamente añaden una característica espectacular, pero reducen sobrecarga o mejoran determinadas rutas internas.
También estamos en un punto donde los sistemas de archivos tienen que adaptarse a hardware de almacenamiento muy diferente al existente cuando muchas de sus decisiones de diseño originales fueron tomadas.
Los NVMe actuales pueden manejar un paralelismo enorme.
Aprovecharlos correctamente requiere que cada una de las capas situadas entre una aplicación y el dispositivo físico intente introducir la menor fricción posible.
MGLRU, swap y gestión de memoria
Linux 7.2 también continúa trabajando en diferentes aspectos relacionados con memoria.
Aquí entran tecnologías como MGLRU, además de mejoras y ajustes en áreas como swap y memoria compartida.
MGLRU forma parte del trabajo realizado durante los últimos años para mejorar cómo Linux decide qué páginas de memoria debe conservar y cuáles puede liberar cuando existe presión de memoria.
Estas optimizaciones resultan especialmente importantes porque la gestión de memoria es una de esas partes del sistema que pueden afectar a prácticamente cualquier carga, pero cuyos beneficios no siempre aparecen de manera evidente en un benchmark sencillo.
Un servidor con memoria suficiente puede comportarse perfectamente hasta que comienza a enfrentarse a presión sostenida.
Es precisamente en esas situaciones donde las decisiones del kernel empiezan a marcar diferencias mucho mayores.
¿Dónde pueden notarse realmente estas optimizaciones?
Aquí aplicaría el mismo criterio que con Cache Aware Scheduling.
No instalaría Linux 7.2 esperando que automáticamente cualquier SSD o aplicación pase a funcionar mucho más rápido.
Pero hay escenarios donde la combinación de almacenamiento rápido, operaciones intensivas de E/S y grandes cantidades de memoria puede hacer que estas mejoras tengan mucho sentido.
Bases de datos, virtualización, servidores de almacenamiento, compilaciones de gran tamaño y aplicaciones con muchas operaciones concurrentes son buenos ejemplos.
Para mí, este apartado es además una buena muestra de algo que ocurre constantemente con Linux: muchas de las mejoras realmente importantes no son necesariamente las que generan los titulares más espectaculares.
Linux 7.2 mejora el soporte para AMD y prepara el terreno para Zen 6
AMD vuelve a ocupar una parte importante del desarrollo de Linux 7.2.
Hay cambios destinados a hardware actual, pero también bastante trabajo que prepara al kernel para la próxima generación de productos de la compañía.
Esto lleva ocurriendo desde hace años y es una de las cosas que más valoro del desarrollo de Linux: el kernel no se prepara solamente para el ordenador que tenemos hoy delante.
Cuando llegan nuevas generaciones de procesadores y dispositivos, parte del trabajo necesario para soportarlos correctamente ya lleva meses integrado en el proyecto.
Más trabajo para AMD Zen 6 y futuras plataformas
Linux 7.2 continúa preparando soporte para AMD Zen 6.
Es importante entender este tipo de incorporación como un proceso.
El soporte de un nuevo procesador no aparece normalmente de golpe en una única versión del kernel.
Primero llegan identificadores, cambios de topología, administración de energía, monitorización, correcciones y diferentes piezas necesarias para que la arquitectura vaya funcionando correctamente.
Versiones posteriores terminan completando ese puzle.
Por eso resulta habitual encontrar referencias a generaciones de procesadores que todavía no están ampliamente disponibles.
Y creo que eso es positivo.
Cuando finalmente ese hardware llega a manos de los usuarios, resulta mucho mejor que el ecosistema Linux ya lleve tiempo preparando el terreno.
AMD ISP4 mejora el soporte para hardware de portátiles modernos
Otro cambio que me parece especialmente interesante es la incorporación del controlador AMD ISP4.
Los portátiles modernos integran una enorme cantidad de componentes que necesitan trabajar correctamente con el sistema operativo.
Cámaras, controladores de imagen, gestión de energía, audio, sensores y otros elementos pueden marcar la diferencia entre tener una máquina plenamente funcional o un equipo donde siempre existe alguna característica problemática.
Durante mucho tiempo, uno de los tópicos asociados a Linux era precisamente que determinados portátiles nuevos requerían meses de correcciones para alcanzar una compatibilidad realmente buena.
La situación ha mejorado muchísimo.
Y la llegada de controladores como AMD ISP4 es otra muestra de que el soporte del kernel ya no consiste solamente en conseguir que arranquen la CPU y la GPU.
Hay que integrar correctamente todo el conjunto de componentes del equipo.
AMDGPU incorpora soporte inicial para HDMI 2.1 FRL
Otra de las novedades importantes es el soporte inicial para HDMI 2.1 FRL en AMDGPU.
Esta era una de esas asignaturas pendientes dentro del soporte gráfico de AMD en Linux.
FRL, o Fixed Rate Link, forma parte de las tecnologías que permiten aprovechar algunas de las capacidades de HDMI 2.1, especialmente cuando hablamos de resoluciones elevadas y frecuencias de refresco altas.
Para un usuario con una configuración convencional quizá no sea una novedad demasiado llamativa.
Sin embargo, para quien conecta una Radeon a pantallas modernas de altas prestaciones, este tipo de soporte puede tener bastante más relevancia.
Hay que interpretar además la palabra “inicial” con cuidado.
Que aparezca soporte para una tecnología no significa que absolutamente todas las configuraciones posibles estén inmediatamente resueltas.
Pero es un paso importante para ir cerrando una diferencia que todavía existía frente a las capacidades disponibles en otros sistemas.
Qué puede significar para usuarios de Radeon
En la práctica, la noticia más importante no es una única función gráfica.
Es que AMDGPU sigue ganando capacidades necesarias para acompañar a monitores y televisores que cada vez utilizan resoluciones y frecuencias más elevadas.
Eso incluye tecnologías relacionadas con HDMI, compresión de flujo, sincronización y diferentes modos de funcionamiento.
Me parece una evolución importante precisamente porque este tipo de mejoras suelen pasar desapercibidas hasta que alguien conecta una pantalla nueva y descubre que una determinada combinación no funciona como esperaba.
Cuantas menos excepciones de este tipo existan, mejor será la experiencia general de utilizar Linux en hardware moderno.
Intel también mira al futuro con Diamond Rapids, Nova Lake y Panther Lake
AMD no es la única compañía para la que Linux 7.2 prepara soporte anticipadamente.
Intel continúa incorporando cambios relacionados con distintas generaciones de hardware, entre ellas Diamond Rapids, Nova Lake y Panther Lake, además de mejoras asociadas a gráficos, corrección de errores de memoria y otros subsistemas.
Otra vez encontramos exactamente el mismo patrón: el kernel se desarrolla pensando varios pasos por delante del hardware que actualmente domina el mercado.
Soporte anticipado para las próximas generaciones de procesadores
Cuando aparece el nombre de un procesador futuro dentro de las novedades de una versión del kernel puede parecer extraño.
¿Por qué necesita Linux soportar una CPU que todavía no tiene prácticamente nadie?
Precisamente porque hacerlo tarde sería un problema.
Los fabricantes y desarrolladores necesitan integrar los cambios antes de que el hardware llegue al mercado para que distribuciones, controladores y herramientas tengan tiempo de adaptarse.
Esto es especialmente relevante en Linux porque el kernel termina utilizándose en entornos extremadamente diferentes.
Una nueva arquitectura Intel puede acabar en ordenadores domésticos, estaciones de trabajo, servidores, centros de datos o infraestructura de nube.
Cada escenario tiene necesidades distintas.
Por eso el soporte no consiste simplemente en “reconocer el procesador”.
El kernel tiene que conocer correctamente sus capacidades, gestión energética, topología, características de seguridad, rendimiento y numerosos detalles adicionales.
Mejoras de ECC y gráficos Intel
Linux 7.2 también continúa trabajando en áreas relacionadas con ECC y los gráficos Intel.
ECC resulta particularmente importante en servidores y estaciones donde la integridad de memoria importa más que en un ordenador convencional.
Por otro lado, la evolución de los gráficos Intel se ha acelerado considerablemente durante los últimos años.
Ya no hablamos únicamente de las gráficas integradas tradicionales.
Intel también compite en gráficos dedicados, lo que obliga a su soporte Linux a cubrir escenarios mucho más amplios.
En mi caso, lo que encuentro interesante de todos estos nombres —Diamond Rapids, Nova Lake o Panther Lake— no es memorizar qué cambio concreto llega para cada uno.
Lo realmente importante es observar cómo funciona el desarrollo del kernel.
Linux intenta llegar preparado al hardware, no reaccionar varios meses después.
Y esa filosofía es especialmente valiosa en un sistema operativo que puede terminar ejecutándose prácticamente en cualquier tipo de máquina.
Virtualización confidencial: los módulos TDX pueden actualizarse en ejecución
Linux 7.2 también introduce mejoras relacionadas con tecnologías de virtualización confidencial.
Una de ellas afecta a Intel TDX, que permite actualizar determinados módulos durante la ejecución.
Para un usuario doméstico puede parecer un cambio bastante distante.
En infraestructura de servidores, sin embargo, poder corregir o actualizar determinados componentes sin necesidad de reiniciar completamente una máquina puede tener bastante más valor.
Qué es TDX y por qué importa
TDX forma parte del conjunto de tecnologías diseñadas para crear entornos de ejecución virtualizados donde incluso determinados componentes de la infraestructura anfitriona tienen un acceso limitado a la información que está procesando una máquina virtual.
La idea forma parte del concepto más amplio de computación confidencial.
Tradicionalmente protegemos la información cuando está almacenada y cuando viaja por una red.
La computación confidencial intenta mejorar también su protección mientras está siendo procesada.
Esto tiene aplicaciones evidentes en servicios cloud, entornos empresariales y plataformas donde diferentes clientes utilizan una misma infraestructura física.
Actualizar sin reiniciar puede ser clave en infraestructura crítica
Desde el punto de vista operativo, la posibilidad de realizar determinadas actualizaciones en ejecución es probablemente la parte más interesante.
En un ordenador personal reiniciar puede ser una molestia de un par de minutos.
En un servidor que ejecuta servicios importantes, un reinicio puede implicar migraciones, ventanas de mantenimiento, redundancia adicional y coordinación con otros sistemas.
No significa que podamos eliminar todos los reinicios ni aplicar cualquier actualización sin interrupciones.
Pero reducirlos allí donde sea posible tiene un valor bastante claro.
Es también otra muestra de hasta qué punto el kernel Linux necesita responder a escenarios que van muchísimo más allá de un PC de escritorio.
Linux continúa dejando atrás componentes históricos de i486
No todas las novedades consisten en añadir código.
Linux 7.2 continúa también el proceso de despedirse de componentes relacionados con la antigua arquitectura i486.
Para quienes llevan muchos años siguiendo Linux, este tipo de decisiones puede tener cierto componente nostálgico.
Durante décadas una de las grandes fortalezas del kernel ha sido su capacidad de ejecutar una enorme variedad de hardware, incluyendo máquinas extraordinariamente antiguas.
Pero esa compatibilidad tampoco es gratuita.
Por qué mantener compatibilidad indefinidamente también tiene un coste
Cada arquitectura antigua que permanece dentro de un proyecto del tamaño del kernel puede implicar excepciones, rutas específicas de código, pruebas y condicionantes que los desarrolladores deben seguir teniendo en cuenta.
Llega un momento en el que hay que preguntarse si ese mantenimiento continúa teniendo sentido.
Personalmente creo que eliminar soporte extremadamente antiguo cuando ya prácticamente no existen usuarios reales afectados forma parte de la evolución normal de un proyecto.
Conservar compatibilidad por el simple hecho de conservarla puede terminar dificultando cambios que beneficien a millones de sistemas actuales.
Esto no significa que Linux esté abandonando de repente su tradición de funcionar en una gran variedad de dispositivos.
Sigue siendo probablemente uno de los kernels con mayor diversidad de hardware del mundo.
Significa simplemente que esa compatibilidad tiene que revisarse de vez en cuando.
Y, paradójicamente, eliminar determinadas piezas antiguas puede ayudar a mantener más sano el código que necesitan las máquinas modernas.
La IA y los LLM empiezan a cambiar cómo se desarrolla el kernel Linux
Probablemente una de las cosas que más me ha llamado la atención alrededor del ciclo de Linux 7.2 no sea una función concreta del kernel.
Es la presencia creciente de inteligencia artificial y modelos de lenguaje en el propio proceso de desarrollo.
Herramientas basadas en IA pueden ayudar a buscar errores, analizar código, generar propuestas de parches, revisar cambios o detectar determinados patrones.
En un proyecto tan grande como Linux, cualquier tecnología capaz de acelerar ese trabajo tiene un potencial enorme.
Pero también plantea un problema bastante interesante.
Más parches, revisiones e informes de errores asistidos por IA
Crear código ha sido tradicionalmente una tarea costosa.
Un desarrollador tenía que entender el problema, localizar dónde modificar el sistema, escribir una solución y preparar el cambio.
Los LLM pueden reducir parte de ese coste.
También pueden permitir analizar cantidades de código que manualmente requerirían mucho más tiempo.
Eso puede producir más informes de errores, más propuestas y más posibles correcciones.
En principio parece una ventaja evidente.
Pero Linux no puede integrar código simplemente porque alguien —o algún sistema— sea capaz de producirlo.
Cada cambio necesita revisión.
Y cuanto más crítico es el software, mayor debe ser la exigencia.
El problema puede pasar de generar código a poder revisarlo
Aquí creo que está uno de los debates más importantes que veremos durante los próximos años.
Si las herramientas de IA permiten generar parches diez veces más rápido, pero la capacidad humana para revisarlos apenas aumenta, entonces no hemos eliminado el cuello de botella.
Lo hemos desplazado.
Podemos acabar con una cantidad enorme de propuestas que necesitan ser comprobadas por desarrolladores que conocen perfectamente cada subsistema.
Y revisar código generado automáticamente tampoco tiene por qué ser más sencillo que escribirlo.
Si una propuesta parece correcta pero introduce un fallo extremadamente sutil, la revisión puede incluso requerir más esfuerzo.
Por qué la revisión humana sigue siendo crítica
Linux se ejecuta en servidores, teléfonos, sistemas industriales, infraestructura de red, superordenadores y una cantidad prácticamente innumerable de dispositivos.
Un error en el kernel puede tener consecuencias muy superiores a las de un fallo dentro de una aplicación convencional.
Por eso sigo pensando que generar más código no sirve de mucho si no podemos verificarlo con el mismo nivel de exigencia.
La IA puede convertirse en una herramienta tremendamente útil para el desarrollo de Linux.
Sería absurdo ignorar su capacidad para automatizar tareas repetitivas, detectar problemas y acelerar investigaciones.
Pero también obliga a replantear qué significa revisar una contribución y cómo se mantiene la confianza en un proyecto donde cada vez será más fácil producir grandes cantidades de código.
No me extrañaría que este asunto terminara siendo bastante más importante para el futuro del kernel que muchas características técnicas individuales.
¿Merece la pena actualizar a Linux 7.2?
Llegados a este punto aparece inevitablemente la pregunta:
¿Debería actualizar a Linux 7.2?
Mi respuesta sería que depende completamente del sistema.
Que exista una versión más nueva del kernel no significa que todas las máquinas deban actualizar inmediatamente.
Usuarios de escritorio y hardware reciente
En un ordenador personal, especialmente si utilizamos hardware relativamente nuevo, actualizar puede tener bastante sentido.
Las versiones recientes del kernel suelen incorporar:
- compatibilidad con nuevos dispositivos;
- mejoras de AMDGPU e Intel;
- correcciones;
- mejor gestión energética;
- optimizaciones de rendimiento;
- soporte para nuevas plataformas.
Si tenemos un componente que funciona mal con un kernel antiguo o necesitamos específicamente alguna de las novedades de Linux 7.2, disponer de una versión más reciente puede solucionar problemas reales.
Las distribuciones rolling release normalmente son las primeras en adoptar kernels recientes precisamente porque su filosofía consiste en ofrecer versiones nuevas con rapidez.
Servidores y sistemas en producción
La situación cambia bastante cuando hablamos de servidores.
Personalmente, no actualizaría una máquina de producción simplemente porque Linux 7.2 exista.
En ese contexto sigo prefiriendo estabilidad, pruebas y kernels mantenidos por la propia distribución antes que perseguir constantemente la última versión.
Un kernel reciente puede incluir mejoras muy interesantes, pero también introduce código que ha tenido menos tiempo para probarse en configuraciones reales.
Además, distribuciones empresariales y versiones estables suelen trasladar correcciones importantes a kernels anteriores mediante backports.
Por tanto, utilizar una versión numéricamente más antigua no significa necesariamente estar utilizando un kernel inseguro o completamente desactualizado.
Por qué no siempre conviene perseguir el kernel más nuevo
La versión adecuada depende del objetivo.
Si estamos probando hardware nuevo, desarrollando software, utilizando una distribución rolling release o necesitamos una característica específica, Linux 7.2 puede resultar muy interesante.
Si administramos infraestructura crítica, la pregunta debería ser otra:
¿Qué problema estoy resolviendo actualizando?
Si no existe una respuesta clara, quizá sea mejor esperar a que nuestra distribución pruebe e integre la versión correspondiente.
Esto me parece especialmente importante porque en tecnología tendemos a asociar automáticamente “más nuevo” con “mejor”.
En producción, muchas veces mejor significa más predecible.
¿Cuándo llegará Linux 7.2 a mi distribución?
La publicación de Linux 7.2 no significa que todos los usuarios vayan a recibirlo inmediatamente.
El kernel y las distribuciones Linux siguen ciclos de desarrollo diferentes.
Una distribución decide qué versión utilizar, qué parches adicionales incorporar y durante cuánto tiempo mantenerla.
Rolling releases frente a distribuciones estables
Distribuciones rolling release suelen incorporar kernels recientes bastante rápido.
Su modelo está pensado precisamente para mantener paquetes y componentes cercanos a las últimas versiones disponibles.
En distribuciones estables el enfoque puede ser completamente distinto.
Una versión de Debian, Ubuntu u otra distribución con ciclos definidos puede mantener durante mucho tiempo una rama del kernel concreta y aplicar sobre ella actualizaciones de seguridad, correcciones y backports.
Eso no debe interpretarse automáticamente como una desventaja.
De hecho, es exactamente lo que muchos administradores buscan en servidores.
Quieren una base relativamente estable donde los cambios estén controlados.
Por qué el kernel de tu distribución puede tardar en actualizarse
Antes de adoptar una nueva versión, los mantenedores pueden necesitar probar:
- controladores;
- módulos externos;
- sistemas de archivos;
- mecanismos de arranque;
- herramientas de seguridad;
- virtualización;
- compatibilidad con hardware;
- parches propios de la distribución.
Todo eso lleva tiempo.
Por eso no recomendaría instalar manualmente Linux 7.2 únicamente para conseguir tener el número de versión más alto.
Si necesitamos específicamente una función nueva, entonces sí tiene sentido valorar las distintas opciones.
En caso contrario, seguir el kernel oficialmente mantenido por nuestra distribución continúa siendo una decisión perfectamente válida.
Linux 7.2 muestra hacia dónde se dirige el kernel
Después de repasar sus novedades, Linux 7.2 me parece una actualización bastante representativa de la evolución que está siguiendo el kernel.
No hay una sola función que pueda resumir toda la versión.
Y quizá sea precisamente eso lo interesante.
Tenemos Cache Aware Scheduling, que intenta adaptar mejor la planificación a la estructura física de los procesadores modernos.
Encontramos mejoras de entrada y salida para un mundo donde los dispositivos NVMe pueden procesar cantidades enormes de información.
AMD e Intel continúan incorporando soporte para generaciones de hardware que todavía están llegando al mercado.
AMDGPU avanza con tecnologías como HDMI 2.1 FRL.
La virtualización confidencial sigue evolucionando.
Al mismo tiempo, el kernel continúa eliminando algunas piezas heredadas de arquitecturas históricas como i486.
Y por encima de todos esos cambios aparece una transformación que afecta a cómo se desarrolla el propio proyecto: la utilización cada vez mayor de herramientas de IA y LLM.
Todo apunta en la misma dirección.
Los ordenadores son cada vez menos simples.
Tenemos más núcleos, más niveles de caché, arquitecturas híbridas, almacenamiento extremadamente rápido, componentes especializados y entornos virtualizados donde la seguridad necesita extenderse incluso a los datos que están siendo procesados.
El kernel necesita entender cada vez mejor esa complejidad.
Por eso, en mi caso, no veo Linux 7.2 como una versión que vaya a cambiar radicalmente la experiencia de todos los usuarios de un día para otro.
La veo como una versión que continúa preparando los cimientos.
Y muchas veces ese tipo de actualizaciones terminan siendo más importantes a largo plazo que una característica espectacular que ocupa todos los titulares durante unas semanas.
Linux 7.2 deja bastante claro hacia dónde está evolucionando el kernel: más consciente del hardware, más preparado para arquitecturas complejas y cada vez más optimizado para las máquinas que utilizaremos durante los próximos años.
Dudas de la comunidad
¿Qué es Linux 7.2?
Linux 7.2 es una versión del kernel Linux, el componente central que se encarga de gestionar hardware, memoria, procesos, dispositivos, sistemas de archivos y numerosos recursos del sistema.
No es una distribución nueva.
Ubuntu, Debian, Fedora, Arch Linux y otras distribuciones utilizan el kernel Linux, pero cada una decide qué versión integrar y cuándo hacerlo.
¿Cuáles son las principales novedades de Linux 7.2?
Entre las novedades más importantes encontramos mejoras de planificación mediante Cache Aware Scheduling, optimizaciones de I/O y memoria, cambios en Btrfs, nuevo soporte para hardware AMD e Intel, avances en AMDGPU y HDMI 2.1 FRL, mejoras relacionadas con virtualización confidencial y la retirada progresiva de determinados componentes asociados a i486.
¿Qué es Cache Aware Scheduling?
Es una mejora de planificación que tiene en cuenta cómo están organizadas las cachés de la CPU.
La idea es que determinadas tareas relacionadas puedan ejecutarse de una forma que aproveche mejor los recursos de caché compartidos entre núcleos, reduciendo potencialmente accesos innecesarios.
Su impacto dependerá de la arquitectura del procesador y de la carga de trabajo.
¿Linux 7.2 mejora el rendimiento?
Sí incluye diferentes optimizaciones de rendimiento, pero no existe un aumento universal aplicable a todos los ordenadores.
El impacto dependerá enormemente del hardware, la aplicación y la carga utilizada.
Una máquina con muchos núcleos o un servidor con almacenamiento NVMe puede beneficiarse de determinados cambios de forma diferente a un portátil convencional.
¿Qué novedades trae Linux 7.2 para AMD?
Linux 7.2 continúa preparando soporte para futuras plataformas como Zen 6 e introduce mejoras para hardware AMD actual.
También destaca la incorporación de AMD ISP4 y el avance del soporte HDMI 2.1 FRL dentro de AMDGPU.
¿Qué mejoras incorpora Linux 7.2 para Intel?
El kernel sigue preparando soporte para futuras generaciones como Diamond Rapids, Nova Lake y Panther Lake, además de continuar mejorando diferentes áreas relacionadas con gráficos, ECC y plataformas Intel.
¿Linux 7.2 mejora Btrfs y el rendimiento de almacenamiento?
Btrfs y diferentes rutas relacionadas con entrada y salida reciben optimizaciones.
Eso no significa que cualquier unidad vaya a experimentar automáticamente una gran subida de rendimiento, pero determinadas cargas intensivas de almacenamiento pueden beneficiarse de las mejoras internas.
¿Linux 7.2 elimina el soporte para i486?
Linux continúa retirando componentes históricos asociados a la arquitectura i486.
Es parte de un proceso de simplificación del kernel mediante la eliminación de código destinado a hardware extremadamente antiguo y con un uso real cada vez menor.
¿Merece la pena actualizar a Linux 7.2?
Depende.
En hardware nuevo o en sistemas donde necesitemos alguna característica o controlador concreto puede tener sentido.
En servidores de producción prefiero seguir el kernel probado y mantenido por la distribución salvo que exista una razón técnica clara para actualizar.
La última versión disponible no es automáticamente la mejor versión para todas las máquinas.
¿Cuándo llegará Linux 7.2 a Ubuntu, Debian, Fedora o Arch Linux?
Dependerá de la política de cada distribución.
Las distribuciones rolling release suelen adoptar kernels recientes con mayor rapidez, mientras que las distribuciones estables pueden mantener durante más tiempo una versión anterior aplicando correcciones y actualizaciones de seguridad.
Por eso la publicación de Linux 7.2 no implica que vaya a aparecer inmediatamente en todas las distribuciones.
Opinión Personal
Linux 7.2 me parece una de esas versiones que demuestran que la evolución del kernel no necesita una función revolucionaria para ser realmente importante. Lo que más valoro es la suma de mejoras en planificación, almacenamiento, memoria, gráficos, virtualización y soporte para nuevas generaciones de AMD e Intel. Especialmente interesante me parece el enfoque de Cache Aware Scheduling, porque refleja muy bien hacia dónde se dirige el hardware: más núcleos, arquitecturas más complejas y una necesidad cada vez mayor de que el sistema operativo entienda cómo está organizado físicamente el procesador.
También creo que conviene mantener cierta perspectiva. No actualizaría un servidor de producción simplemente porque exista una versión nueva del kernel. En esos entornos sigo prefiriendo estabilidad, pruebas y el soporte de la propia distribución antes que perseguir siempre la última versión disponible. Linux 7.2 puede aportar mejoras importantes, pero su impacto real dependerá muchísimo del hardware y de la carga de trabajo.
Otro punto que me parece especialmente interesante es la creciente presencia de la inteligencia artificial en el desarrollo del kernel. Los LLM pueden ayudar a detectar errores, revisar código o acelerar la creación de parches, pero también plantean una cuestión importante: generar más código no sirve de mucho si después no existe suficiente capacidad humana para revisarlo con el mismo nivel de exigencia.
En conjunto, veo Linux 7.2 como una actualización muy completa y, sobre todo, como una muestra bastante clara de hacia dónde está evolucionando Linux durante los próximos años.
¿Qué te parece Linux 7.2? ¿Hay alguna novedad que te resulte especialmente interesante o tienes pensado actualizar tu equipo? Te leo en los comentarios.
