Linux 7.3 me está pareciendo especialmente interesante por una razón: no necesita una única novedad espectacular para demostrar hacia dónde está evolucionando Linux.
Si en Linux 7.1 ya vimos cómo el kernel seguía preparando el terreno para nuevas generaciones de hardware, y en Linux 7.2 encontramos mejoras importantes en planificación, almacenamiento, memoria y compatibilidad, Linux 7.3 continúa esa evolución prestando bastante atención a algo que para mí resulta especialmente importante: reducir cuellos de botella reales.
Y eso puede terminar siendo mucho más útil que incorporar una característica espectacular que simplemente quede bien en un listado de novedades.
Cuando trabajamos con servidores con muchos núcleos, almacenamiento NVMe extremadamente rápido, virtualización, GPU modernas o cargas cada vez más paralelas, las pequeñas ineficiencias empiezan a importar. Operaciones que hace unos años quedaban completamente ocultas tras la lentitud relativa del hardware ahora pueden convertirse en una parte medible del coste de ejecutar una carga.
Ahí es donde creo que Linux 7.3 resulta especialmente interesante.
Tenemos mejoras en Btrfs y EXT4, trabajo alrededor de AMD, Intel y NVIDIA, avances de Nova y Rust y muchas optimizaciones internas que intentan eliminar trabajo innecesario.
Pero Linux 7.3 también está dejando otra historia bastante curiosa.
Mientras el kernel intenta reducir sus propios cuellos de botella técnicos, el proyecto Linux empieza a enfrentarse a un nuevo cuello de botella humano: la capacidad para revisar todo el código que ahora puede producirse o modificarse con ayuda de inteligencia artificial.
Vamos a ver qué cambia y, sobre todo, por qué creo que algunas de estas novedades importan bastante más de lo que parece.
Principales novedades de Linux 7.3
Linux 7.3 no gira alrededor de un único cambio. Lo interesante es precisamente la cantidad de pequeñas mejoras repartidas por diferentes partes del kernel.
Entre las áreas que más me llaman la atención están:
- mejoras de rendimiento en Btrfs;
- más paralelismo y optimizaciones internas en EXT4;
- trabajo sobre IOmap y las rutas de entrada y salida;
- mejor aprovechamiento de almacenamiento NVMe muy rápido;
- novedades para GPU AMD antiguas y modernas;
- avances del soporte de Intel Nova Lake y Xe3P;
- mejoras en Nouveau y evolución de Nova para NVIDIA;
- más presencia de Rust dentro del subsistema gráfico;
- cambios relacionados con redes, memoria y otras partes del kernel;
- y el creciente impacto de los LLM y agentes de IA sobre el propio proceso de desarrollo de Linux.
Lo importante es no interpretar esta lista como si actualizar el kernel fuese a acelerar automáticamente cualquier ordenador.
No funciona así.
Muchas de las mejoras de rendimiento que estamos viendo atacan rutas concretas, patrones específicos de E/S o determinadas configuraciones de hardware. Eso significa que puede haber cargas donde el impacto sea muy evidente y otras donde prácticamente no exista diferencia.
Para mí, esta distinción es importante.
Prefiero ver una optimización que elimina un cuello de botella real en una situación específica a una promesa genérica de “Linux 7.3 es un 20 % más rápido”.
Ese tipo de cifra global tendría poco sentido.
Un servidor dedicado a almacenamiento, una estación de trabajo, un portátil y una máquina ejecutando virtualización intensiva utilizan el kernel de maneras muy diferentes.
Por eso creo que la mejor forma de entender las novedades de Linux 7.3 no es preguntarnos únicamente cuánto mejora el rendimiento, sino algo mucho más útil:
¿Dónde estaba haciendo Linux trabajo innecesario y qué se ha cambiado para reducirlo?
Btrfs y EXT4 son dos ejemplos perfectos.
Btrfs y EXT4: Linux 7.3 quiere aprovechar mejor los SSD NVMe
Btrfs reduce sobrecarga en algunas rutas de E/S
Uno de los apartados que más me llama la atención de Linux 7.3 es Btrfs.
Hay cambios internos relacionados con IOmap que permiten mejorar de manera importante determinadas rutas de E/S directa. En algunas pruebas concretas se ha pasado de aprovechar aproximadamente la mitad del rendimiento teórico disponible a acercarse al 95 %.
La cifra llama la atención, pero para mí lo verdaderamente interesante no es el porcentaje.
Es por qué existe esa diferencia.
Con los NVMe actuales, el problema ya no siempre está en el dispositivo.
Durante muchos años era relativamente fácil que determinadas ineficiencias del software quedaran escondidas detrás de un disco físicamente mucho más lento.
Si el almacenamiento necesita muchísimo tiempo para completar una operación, unos cuantos pasos adicionales dentro del sistema operativo pueden resultar prácticamente irrelevantes.
Con un NVMe moderno ocurre justo lo contrario.
El dispositivo puede responder tan rápido que la propia ruta que siguen los datos dentro del kernel empieza a importar.
Reducir llamadas, bloqueos, pasos intermedios o trabajo duplicado puede traducirse entonces en una diferencia medible.
También me parecen interesantes las mejoras relacionadas con fsync, el registro de determinadas operaciones y las escrituras concurrentes.
Aquí volvemos a encontrar pruebas donde ciertos cambios ofrecen mejoras de varias veces sobre cargas muy específicas.
Y aquí es donde conviene frenar un poco el entusiasmo.
Qué significan realmente las mejoras de rendimiento de Btrfs
Que una prueba concreta mejore cuatro o cinco veces no significa que Btrfs vaya a ser cuatro o cinco veces más rápido después de instalar Linux 7.3.
Ni mucho menos.
Los benchmarks suelen ejercitar rutas muy determinadas y en condiciones cuidadosamente controladas. Una carga real puede depender de otros límites completamente distintos: CPU, memoria, sincronización, red, controlador, dispositivo físico o incluso de la propia aplicación.
Por eso yo no vendería Linux 7.3 como una actualización capaz de multiplicar automáticamente el rendimiento de cualquier servidor Btrfs.
Lo que sí me parece importante es que esas pruebas permiten detectar trabajo innecesario que realmente existía dentro del kernel.
Y eliminarlo es valioso aunque no todos los usuarios vayan a percibir exactamente el mismo porcentaje.
En sistemas capaces de generar enormes cantidades de operaciones por segundo, cada capa de sobrecarga eliminada deja más margen para que el hardware haga el trabajo que realmente queremos.
EXT4 todavía tiene margen para mejorar
EXT4 es otro buen ejemplo.
Podría parecer que un sistema de archivos tan utilizado y con tantos años de desarrollo tiene ya poco margen para optimizaciones importantes.
Linux 7.3 vuelve a demostrar que no necesariamente es así.
Las escrituras de E/S directa pueden ejecutarse con mayor paralelismo en determinados escenarios y la reorganización de partes relacionadas con IOmap permite simplificar rutas críticas y reducir llamadas indirectas.
Individualmente pueden parecer cambios bastante pequeños.
Pero imaginemos almacenamiento Gen5 NVMe capaz de trabajar con millones de operaciones de entrada y salida por segundo.
En ese escenario, una capa de software que antes prácticamente no importaba puede empezar a aparecer en los perfiles de rendimiento.
Cuando el SSD deja de ser el cuello de botella
Para mí, este es uno de los conceptos más interesantes de Linux 7.3.
Cuanto más rápido se vuelve el hardware, más visibles son algunas ineficiencias del software.
Hace unos años podíamos echarle casi toda la culpa al disco.
Ahora no siempre podemos.
Si el NVMe ya es capaz de mover datos a una velocidad enorme, empieza a importar cuánto trabajo hace Linux antes de solicitar la operación, cómo coordina varias escrituras, cuántas estructuras debe recorrer y qué bloqueos introduce durante el proceso.
No significa que Linux 7.3 transforme mágicamente cualquier SSD en otro más rápido.
Significa algo más interesante: el kernel sigue adaptándose a un mundo donde el almacenamiento moderno puede ser suficientemente rápido como para exponer sus propias ineficiencias internas.
AMD: más soporte para GPU nuevas sin abandonar las antiguas
Mejoras para tarjetas AMD desde Southern Islands hasta Polaris
Otro aspecto que me gusta especialmente es el trabajo relacionado con tarjetas gráficas AMD que ya tienen bastantes años.
Linux 7.3 incorpora avances para generaciones GFX6 a GFX8, cubriendo hardware que va desde Southern Islands hasta Polaris, incluyendo mejoras relacionadas con modificadores de formato DRM.
Si solo miramos las últimas GPU del mercado, puede parecer un trabajo poco emocionante.
Yo lo veo justo al contrario.
Uno de los grandes puntos fuertes de Linux siempre ha sido alargar muchísimo la vida útil del hardware.
Una tarjeta gráfica que dejó de estar en los titulares hace muchos años puede seguir formando parte de un equipo perfectamente funcional.
Mejorar su compatibilidad, interoperabilidad gráfica o comportamiento ante determinados bloqueos aporta un valor real a usuarios que no tienen ninguna necesidad de sustituir ese hardware.
Por qué mejorar una GPU de hace diez años sigue siendo importante
Además, el impacto cambia completamente dependiendo del entorno.
En un equipo doméstico, recuperarse correctamente de un bloqueo de GPU puede significar simplemente evitar un reinicio bastante molesto.
En infraestructura compartida, la historia es distinta.
Si una misma máquina ejecuta varios trabajos, recuperar correctamente un dispositivo puede evitar tener que reiniciar el sistema completo e interrumpir cargas que no tenían absolutamente nada que ver con el problema original.
De repente, una mejora aparentemente pequeña deja de serlo.
Ese tipo de cambios me gustan especialmente porque son un buen recordatorio de que compatibilidad no significa únicamente conseguir que un dispositivo muestre imagen.
También significa recuperación, estabilidad, interoperabilidad y comportamiento correcto ante situaciones que probablemente no ocurren durante un benchmark de cinco minutos.
Linux 7.3 también prepara el terreno para nuevas GPU AMD
Al mismo tiempo, AMD continúa preparando Linux para hardware mucho más reciente y para generaciones que seguirán llegando.
Se está trabajando sobre nuevos bloques gráficos, Display Core y soporte para futuras plataformas.
Y ese equilibrio me parece una de las características más interesantes del ecosistema Linux.
Por un lado, seguimos viendo mejoras para GPU con más de una década.
Por otro, el kernel se prepara con antelación para hardware que todavía está entrando en el mercado.
Mantener hardware antiguo mientras se construye el soporte del nuevo es exactamente el tipo de evolución que espero encontrar en Linux.
No obliga a elegir entre conservar compatibilidad y mirar hacia delante.
Hace ambas cosas a la vez.
Intel Nova Lake y Xe3P avanzan hacia un soporte más completo
De soporte experimental a hardware utilizable por defecto
Las novedades relacionadas con Intel Nova Lake también son interesantes, especialmente alrededor de los gráficos Xe3P.
Aquí creo que conviene diferenciar dos cosas que muchas veces se mezclan cuando hablamos de soporte de hardware en Linux.
Una cosa es que exista código dentro del kernel y un desarrollador pueda activar manualmente determinadas opciones para probar una plataforma.
Otra muy distinta es que ese soporte esté suficientemente maduro como para que una distribución pueda arrancar y funcionar sobre el hardware sin configuraciones especiales.
Entre ambos estados existe una distancia enorme.
Para un entusiasta acostumbrado a compilar kernels puede parecer simplemente cuestión de cambiar una opción.
Para una distribución, un fabricante o una empresa que tiene que desplegar cientos de sistemas, no.
El objetivo no es que el hardware pueda funcionar si sabes exactamente qué parámetro activar.
El objetivo es que funcione como parte normal de la plataforma.
Por qué este cambio importa a fabricantes y distribuciones Linux
Para mí, ese paso desde experimental hasta utilizable por defecto es lo que realmente determina cuándo una plataforma empieza a considerarse soportada.
Un fabricante necesita poder entregar una máquina sin una lista de instrucciones especiales para activar la GPU.
Una distribución necesita configurar su kernel con opciones razonables para millones de usuarios.
Y un administrador quiere instalar el sistema y encontrar un comportamiento predecible.
Por eso no mediría la importancia de estos cambios únicamente por si añaden una nueva característica gráfica visible.
La madurez del soporte también es una característica.
De hecho, probablemente sea una de las más importantes.
Un kernel moderno tiene que estar preparado para hardware que todavía está llegando sin sacrificar estabilidad en las plataformas existentes.
Linux 7.3 continúa precisamente ese trabajo.
NVIDIA, Nouveau y Nova: qué mejora realmente en Linux 7.3
Nova continúa avanzando con Rust, GSP y nuevas arquitecturas
Con NVIDIA conviene ser especialmente cuidadoso porque es muy fácil mezclar capas distintas.
Linux 7.3 continúa avanzando dentro del ecosistema gráfico abierto de NVIDIA.
Nouveau recibe mejoras, mientras Nova, el nuevo controlador escrito en Rust, sigue progresando en áreas relacionadas con GSP, virtualización y arquitecturas modernas como Hopper y Blackwell.
Personalmente, Nova me parece uno de los proyectos más interesantes que tenemos ahora mismo alrededor de los controladores gráficos de Linux.
No solamente por NVIDIA, sino porque también representa una aplicación muy visible de Rust dentro del kernel.
Pero precisamente porque NVIDIA está tan asociada actualmente con inteligencia artificial, creo que debemos separar muy bien realidad y expectativas.
Nova y Nouveau no son lo mismo que CUDA
Yo no convertiría estas novedades en un titular diciendo que Linux 7.3 va a acelerar automáticamente la inferencia sobre una NVIDIA H100, L4 o A10.
No funciona así.
Las GPU NVIDIA que se utilizan habitualmente en centros de datos para CUDA e inferencia dependen principalmente del controlador de NVIDIA, CUDA y del entorno de ejecución empleado por cada carga.
Por tanto, una mejora dentro de DRM, Nouveau o Nova no equivale automáticamente a conseguir más tokens por segundo ejecutando un modelo de IA.
Estamos hablando de capas diferentes.
Puede haber avances muy importantes dentro del ecosistema abierto de NVIDIA sin que eso implique una mejora inmediata en un benchmark CUDA.
Y creo que esta aclaración es cada vez más necesaria.
Estamos en una época donde basta con colocar las palabras “Linux”, “NVIDIA” e “inteligencia artificial” en la misma frase para que resulte tentador construir una conclusión mucho más espectacular de lo que realmente permiten los datos.
Prefiero separar claramente cada pieza.
Nova puede ser un proyecto enormemente relevante sin necesidad de atribuirle mejoras que pertenecen a otro stack.
Más cambios de Linux 7.3 en seguridad, redes y el propio kernel
Linux 7.3 no termina en almacenamiento y gráficos.
El desarrollo de un kernel incorpora cientos de cambios repartidos entre subsistemas, y muchos de ellos no producen una función que podamos mostrar en una captura de pantalla.
Eso no significa que sean secundarios.
Redes, memoria, planificación, criptografía, controladores y diferentes API internas continúan evolucionando.
Aquí, sin embargo, prefiero evitar un error bastante habitual en los artículos de novedades: convertir cada commit en una supuesta revolución.
Una nueva API puede ser enormemente importante para desarrolladores del kernel y prácticamente invisible para un usuario final.
Una reorganización interna puede no cambiar absolutamente nada en una interfaz y, sin embargo, reducir trabajo en una ruta que se ejecuta millones de veces.
Y una optimización de red puede resultar esencial para cargas muy concretas sin alterar el rendimiento de un portátil doméstico.
Ese contexto importa.
Rust continúa ganando presencia dentro de Linux
Uno de los movimientos más interesantes de los últimos años es precisamente la incorporación gradual de Rust dentro del kernel.
Nova vuelve a servirnos como ejemplo.
No se trata simplemente de poder decir que “Linux usa Rust”.
La cuestión interesante será comprobar dónde aporta realmente ventajas prácticas: controladores nuevos, reducción de determinadas clases de errores relacionados con memoria y creación de componentes que puedan mantenerse a largo plazo.
Yo tampoco interpretaría cada nuevo componente en Rust como una sustitución inmediata de C dentro de Linux.
El kernel tiene una enorme base de código, multitud de subsistemas y décadas de desarrollo.
Los cambios de este tamaño se producen gradualmente.
Pero que proyectos importantes como Nova estén sirviendo de campo de aplicación real demuestra que Rust está dejando de ser únicamente una posibilidad teórica dentro de Linux.
La IA está creando un nuevo cuello de botella en el desarrollo de Linux
Probablemente esta sea la parte de Linux 7.3 que más me hace reflexionar.
Y curiosamente no tiene que ver directamente con Btrfs, AMD, Intel o NVIDIA.
Tiene que ver con cómo se está desarrollando el propio Linux.
Los mantenedores del subsistema de red han reconocido sentirse desbordados por el volumen de parches, correcciones y pequeñas modificaciones que parecen estar siendo generadas o asistidas con agentes de IA y grandes modelos de lenguaje.
Esto anticipa un problema que creo que veremos muchísimo durante los próximos años.
Hasta ahora hemos hablado constantemente de que la inteligencia artificial permite escribir código más rápido.
Perfecto.
¿Pero quién revisa todo ese código?
Cada vez es más fácil generar parches
Un LLM puede encontrar una modificación pequeña, generar un parche, preparar una descripción e incluso ayudar a detectar lugares potencialmente mejorables.
Si hacemos que el coste de producir una propuesta de cambio caiga enormemente, es lógico que aparezcan muchas más propuestas.
El problema es que producir y aceptar un parche son dos cosas completamente diferentes.
Que una modificación compile tampoco significa necesariamente que sea correcta.
Y mucho menos dentro del kernel.
Linux tiene que funcionar sobre una cantidad enorme de hardware, configuraciones y cargas diferentes.
Un cambio aparentemente trivial puede interactuar con un controlador poco habitual, una condición de carrera, un estado de error raro o una combinación de hardware que quien generó el parche nunca ha tenido delante.
El problema ya no es escribir código, sino revisarlo
Aquí está para mí la parte fundamental.
Si podemos generar diez veces más parches pero seguimos teniendo aproximadamente el mismo número de mantenedores capaces de entenderlos, probarlos y decidir si deben integrarse, no hemos eliminado el cuello de botella: simplemente lo hemos desplazado.
Antes podía ser costoso escribir la modificación.
Ahora puede resultar costoso revisarla.
Y la revisión humana experta no escala automáticamente porque un modelo pueda producir más líneas de código por minuto.
Hay además una asimetría bastante incómoda.
Generar un parche mediocre puede resultar muy barato.
Demostrar cuidadosamente por qué ese parche es incorrecto puede requerir muchísimo más tiempo.
Si ese patrón se repite cientos o miles de veces, la herramienta que supuestamente iba a acelerar el desarrollo puede terminar aumentando la cantidad de trabajo que soportan las personas más difíciles de reemplazar: los mantenedores con experiencia.
Por qué revisar código del kernel no puede convertirse en un trámite
En una aplicación convencional, un error puede afectar a una función concreta.
Dentro del kernel, un pequeño problema puede manifestarse únicamente bajo carga, producir corrupción, provocar un bloqueo, afectar a hardware muy específico o aparecer como una condición de carrera que solo se reproduce una vez cada varios millones de operaciones.
Por eso la revisión no puede reducirse a:
“compila, los tests pasan, adelante”.
La experiencia acumulada de los mantenedores sigue siendo esencial.
Esto no significa que los LLM sean inútiles.
De hecho, pueden ayudar precisamente en la otra dirección.
Los LLM también pueden ayudar a solucionar el problema
Los modelos pueden servir para detectar patrones, revisar cambios, resumir discusiones, buscar inconsistencias y automatizar partes repetitivas del proceso.
Los propios mantenedores están explorando este tipo de herramientas.
Por eso no creo que la historia correcta sea simplemente “la IA está arruinando Linux”.
La situación es bastante más interesante.
La IA puede ayudar a escribir y revisar código.
El reto consiste en encontrar un equilibrio donde aumente la capacidad real de mantener software, no únicamente la cantidad de código que somos capaces de producir.
Generar más no siempre significa avanzar más rápido.
A veces significa exactamente lo contrario.
Linux 7.3 no es Red Hat Enterprise Linux 7.3
Hay otra cuestión que merece una aclaración porque la propia búsqueda puede resultar confusa.
Si buscamos “Linux 7.3”, podemos acabar fácilmente en documentación de Red Hat Enterprise Linux 7.3.
Pero Linux 7.3 y RHEL 7.3 no son la misma cosa.
Red Hat Enterprise Linux 7.3 es una versión histórica de la distribución RHEL 7.
Linux 7.3, en el contexto de este artículo, hace referencia a una versión del kernel Linux.
La coincidencia de numeración no crea ninguna relación entre ambas.
Kernel Linux y distribución Linux no significan lo mismo
El kernel es el núcleo del sistema operativo: gestiona procesos, memoria, dispositivos, sistemas de archivos, redes y la comunicación fundamental con el hardware.
Una distribución Linux incorpora ese kernel junto con una enorme cantidad de software adicional: instalador, gestor de paquetes, bibliotecas, servicios, herramientas de administración, entorno de usuario y una política determinada de actualizaciones y soporte.
Por eso pueden existir versiones de distribuciones cuya numeración se parezca a la del kernel sin que tengan relación alguna.
Puede parecer una aclaración demasiado básica para quien lleva años administrando Linux, pero creo que merece la pena incluirla.
Los buscadores no siempre distinguen bien la intención y una consulta corta como Linux 7.3 puede mezclar documentación separada por muchos años.
¿Merece la pena actualizar a Linux 7.3?
Esta es probablemente la pregunta práctica más importante.
Y mi respuesta es: depende completamente de qué necesitemos del kernel.
Si estamos probando hardware reciente, trabajando con una característica que acaba de recibir soporte, haciendo benchmarks, desarrollando controladores o tenemos una carga que puede beneficiarse específicamente de alguna de las optimizaciones que hemos visto, Linux 7.3 puede ser muy interesante.
También tiene sentido probarlo en laboratorios, estaciones de trabajo donde podamos volver fácilmente al kernel anterior y entornos donde queramos evaluar nuevas funciones antes de un futuro despliegue.
En producción sería más prudente.
Cuándo tiene sentido probar el kernel más reciente
Yo probaría Linux 7.3 especialmente cuando exista una razón concreta.
Por ejemplo:
- queremos evaluar mejoras de Btrfs o EXT4 con nuestra carga;
- utilizamos hardware cuyo soporte está avanzando;
- necesitamos validar un controlador nuevo;
- estamos preparando futuras plataformas;
- queremos medir cambios de latencia, E/S o comportamiento bajo concurrencia;
- o simplemente administramos un entorno de pruebas destinado precisamente a validar nuevas versiones.
Ahí el kernel reciente tiene sentido porque estamos buscando algo concreto.
Por qué no instalaría Linux 7.3 inmediatamente en todos los servidores
Lo que no haría es instalarlo automáticamente en todos los servidores de producción simplemente porque aparece un benchmark donde una operación determinada mejora varias veces.
Un benchmark no conoce nuestra infraestructura.
Nosotros sí deberíamos conocerla.
Un servidor puede depender de módulos externos, software certificado para versiones determinadas, políticas de soporte, hipervisores, controladores específicos o simplemente de una estabilidad que vale mucho más que conseguir unos puntos adicionales en una prueba sintética.
Para mí hay una diferencia esencial entre:
probar el kernel más reciente
y
utilizar el kernel que realmente necesita nuestra infraestructura.
No siempre son el mismo.
Y no pasa nada.
Linux nos permite tener ambas cosas.
Linux 7.3 parece una versión diseñada para eliminar fricción
Si tuviera que quedarme con una sola idea de Linux 7.3 sería esa:
eliminar fricción.
Menos sobrecarga en determinadas rutas de entrada y salida.
Más rendimiento en operaciones concretas de Btrfs.
Más paralelismo en EXT4.
Mejor aprovechamiento de almacenamiento NVMe extremadamente rápido.
Mejor comportamiento y compatibilidad para algunas GPU antiguas.
Preparación para nuevas generaciones de AMD e Intel.
Evolución de Nouveau y Nova.
Más trabajo real con Rust dentro del subsistema gráfico.
Y muchas pequeñas optimizaciones que individualmente quizá no parezcan demasiado espectaculares.
Para mí, ahí está precisamente el valor.
No necesito que cada nueva versión de Linux consiga mágicamente un 20 % más de rendimiento general.
Eso no sería realista.
Prefiero que el kernel siga encontrando los lugares donde realiza trabajo innecesario y vaya eliminándolo.
Porque en servidores con decenas de núcleos, almacenamiento capaz de superar millones de IOPS, redes cada vez más rápidas y cargas enormemente paralelas, reducir pequeñas ineficiencias puede tener mucho más impacto del que parece.
Y curiosamente Linux 7.3 también nos deja otra lección.
Mientras los desarrolladores eliminan cuellos de botella técnicos dentro del kernel, el proyecto empieza a encontrarse con otro fuera de él.
La inteligencia artificial puede multiplicar la cantidad de código y parches que somos capaces de generar.
Pero todavía necesitamos personas capaces de entender qué hace cada cambio y si realmente debe formar parte de Linux.
Quizá esa termine siendo una de las historias más interesantes de esta etapa del kernel:
podemos automatizar cada vez más la creación de código, pero la capacidad de revisar correctamente ese código se está convirtiendo en un recurso cada vez más valioso.
Dudas de la comunidad
¿Qué es Linux 7.3?
Linux 7.3 hace referencia a una versión del kernel Linux, es decir, el núcleo encargado de gestionar hardware, memoria, procesos, sistemas de archivos, redes y otros recursos fundamentales del sistema. No debe confundirse con la numeración de una distribución concreta.
¿Qué novedades trae Linux 7.3?
Entre las áreas más interesantes están las optimizaciones de Btrfs y EXT4, mejoras relacionadas con IOmap y almacenamiento NVMe, novedades para hardware AMD e Intel, avances de Nouveau y Nova para NVIDIA y más trabajo con Rust dentro del kernel. También está siendo especialmente interesante el debate alrededor del aumento de parches generados o asistidos mediante IA.
¿Linux 7.3 mejora el rendimiento?
Sí existen mejoras de rendimiento en cargas y rutas específicas, pero no deberíamos interpretarlas como un incremento general para cualquier ordenador. El impacto dependerá del sistema de archivos, hardware, patrón de E/S y carga utilizada.
¿Qué mejoras incluye Linux 7.3 para Btrfs y EXT4?
Btrfs recibe optimizaciones que buscan reducir sobrecarga en determinadas operaciones y rutas de E/S, mientras que EXT4 mejora el paralelismo en algunos escenarios y simplifica ciertas rutas internas relacionadas con IOmap.
¿Linux 7.3 mejora el rendimiento de los SSD NVMe?
Puede ayudar a aprovechar mejor almacenamiento muy rápido en aquellas cargas donde la sobrecarga del propio kernel se estaba convirtiendo en un límite. Eso no significa que cualquier NVMe vaya a ser automáticamente más rápido después de actualizar.
¿Qué novedades trae Linux 7.3 para AMD, Intel y NVIDIA?
AMD recibe mejoras tanto para GPU antiguas como para hardware futuro. Intel continúa avanzando el soporte de Nova Lake y Xe3P. En NVIDIA siguen evolucionando Nouveau y Nova, este último escrito en Rust y relacionado con áreas como GSP y nuevas arquitecturas.
¿Linux 7.3 hará más rápida una NVIDIA H100 para inteligencia artificial?
No podemos concluirlo a partir de las mejoras de Nova, Nouveau o DRM. Las cargas CUDA e inferencia en centros de datos utilizan principalmente el stack de controladores de NVIDIA, CUDA y sus correspondientes runtimes. Son capas diferentes.
¿Qué relación tiene Linux 7.3 con la inteligencia artificial?
Además de las aplicaciones habituales de Linux en infraestructura de IA, esta versión está coincidiendo con un debate importante dentro del propio proyecto: la facilidad para generar muchos más parches mediante LLM y agentes frente a la capacidad limitada de los mantenedores para revisarlos.
¿Cuándo estará disponible Linux 7.3?
Linux 7.3 está sujeto al ciclo normal de desarrollo del kernel antes de alcanzar una versión estable. Conviene comprobar el estado concreto de la versión en el momento de instalarla y no asumir que una versión en desarrollo es apropiada para producción.
¿Merece la pena actualizar a Linux 7.3?
Puede merecer mucho la pena si necesitamos alguna de sus mejoras concretas, hardware reciente o queremos evaluar su rendimiento. En servidores de producción, actualizaría después de probar la versión con la carga, módulos, controladores y software que realmente utilizamos.
¿Linux 7.3 y RHEL 7.3 son lo mismo?
No. Linux 7.3 hace referencia al kernel, mientras que Red Hat Enterprise Linux 7.3 es una versión histórica de la distribución RHEL 7. La coincidencia de números no significa que sean la misma versión ni que exista relación directa entre ellas.
Opinión Personal
Linux 7.3 me parece una de esas versiones que demuestran que la evolución del kernel no siempre depende de una novedad espectacular. Muchas veces, lo realmente importante está en eliminar pequeñas ineficiencias, mejorar rutas críticas y aprovechar mejor un hardware que cada vez es más rápido.
Me interesan especialmente los cambios en Btrfs, EXT4 y el trabajo para reducir sobrecarga en determinadas operaciones de entrada y salida. Con SSD NVMe cada vez más rápidos, creo que este tipo de optimizaciones van a tener más importancia, porque el cuello de botella ya no siempre está en el dispositivo de almacenamiento.
También valoro mucho que Linux siga mejorando el soporte de hardware antiguo mientras prepara nuevas generaciones de AMD, Intel y NVIDIA. Para mí, esa capacidad de alargar la vida útil de los equipos sin dejar de mirar hacia el futuro sigue siendo una de las grandes fortalezas del ecosistema Linux.
Y probablemente uno de los temas más interesantes sea el impacto de la inteligencia artificial en el propio desarrollo del kernel. Si las herramientas de IA permiten generar cada vez más código y más parches, la gran pregunta será quién puede revisar todo ese trabajo con el nivel de rigor que exige un proyecto como Linux. Creo que ese equilibrio entre automatización y supervisión humana será cada vez más importante.
En definitiva, no espero que Linux 7.3 haga que cualquier equipo sea mágicamente mucho más rápido. Lo que sí me gusta es ver cómo el kernel continúa atacando cuellos de botella concretos y eliminando trabajo innecesario allí donde realmente puede marcar una diferencia.
¿Qué te parece Linux 7.3? ¿Hay alguna novedad que te interese especialmente o alguna mejora que quieras probar cuando esté disponible? Te leo en los comentarios.
