{"id":9518,"date":"2026-08-20T12:21:50","date_gmt":"2026-08-20T10:21:50","guid":{"rendered":"https:\/\/www.hostingtg.com\/blog\/?p=9518"},"modified":"2026-08-20T12:21:52","modified_gmt":"2026-08-20T10:21:52","slug":"linux-7-2","status":"publish","type":"post","link":"https:\/\/www.hostingtg.com\/blog\/linux-7-2\/","title":{"rendered":"Linux 7.2: novedades, mejoras de rendimiento y todo lo que cambia en el nuevo kernel"},"content":{"rendered":"\n

Linux 7.2 ya est\u00e1 aqu\u00ed y, al menos para m\u00ed, es una de esas versiones del kernel que resultan m\u00e1s interesantes cuando dejas de buscar la gran caracter\u00edstica revolucionaria<\/strong> y empiezas a mirar todo lo que ha cambiado debajo del cap\u00f3.<\/p>\n\n\n\n

No hay una \u00fanica novedad que transforme por completo la experiencia de utilizar Linux. Lo que encontramos es algo diferente: mejoras en planificaci\u00f3n de tareas, almacenamiento, gesti\u00f3n de memoria, gr\u00e1ficos, virtualizaci\u00f3n y compatibilidad con las pr\u00f3ximas generaciones de hardware de AMD e Intel.<\/p>\n\n\n\n

Y personalmente creo que eso es exactamente lo que deber\u00eda hacer una buena actualizaci\u00f3n del kernel<\/a>.<\/p>\n\n\n\n

Linux lleva a\u00f1os enfrent\u00e1ndose a un hardware cada vez m\u00e1s complejo. Tenemos procesadores con m\u00e1s n\u00facleos, diferentes niveles de cach\u00e9, almacenamiento NVMe capaz de mover cantidades enormes de informaci\u00f3n, aceleradores especializados, sistemas de virtualizaci\u00f3n m\u00e1s sofisticados y tarjetas gr\u00e1ficas que requieren soporte para est\u00e1ndares cada vez m\u00e1s exigentes.<\/p>\n\n\n\n

Linux 7.2 contin\u00faa adapt\u00e1ndose a ese escenario.<\/p>\n\n\n\n

Entre sus novedades destaca especialmente Cache Aware Scheduling<\/strong>, una forma de planificaci\u00f3n que intenta aprovechar mejor c\u00f3mo est\u00e1n organizadas f\u00edsicamente las cach\u00e9s de los procesadores modernos. Tambi\u00e9n encontramos optimizaciones de entrada y salida, cambios relacionados con Btrfs y memoria, m\u00e1s soporte para AMD e Intel, mejoras para AMDGPU y HDMI 2.1 FRL, novedades en virtualizaci\u00f3n confidencial y la retirada progresiva de componentes asociados a la veterana arquitectura i486.<\/p>\n\n\n\n

Pero hay adem\u00e1s otro cambio que quiz\u00e1 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<\/strong>.<\/p>\n\n\n\n

Todo junto hace que Linux 7.2 sea una versi\u00f3n bastante representativa de hacia d\u00f3nde se dirige el kernel.<\/p>\n\n\n\n

\"linux<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Cache Aware Scheduling: Linux 7.2 quiere aprovechar mejor la cach\u00e9 de la CPU<\/h2>\n\n\n\n

Una de las novedades de Linux<\/a> 7.2 que m\u00e1s me interesa es la llamada Cache Aware Scheduling<\/strong>, o planificaci\u00f3n con reconocimiento de cach\u00e9.<\/p>\n\n\n\n

Dicho as\u00ed puede sonar como una optimizaci\u00f3n extremadamente t\u00e9cnica y bastante alejada del usuario normal. En realidad, la idea que existe detr\u00e1s es relativamente sencilla: cuando el kernel decide d\u00f3nde ejecutar determinadas tareas, no siempre deber\u00eda considerar todos los n\u00facleos equivalentes desde el punto de vista del acceso a memoria y cach\u00e9.<\/p>\n\n\n\n

Qu\u00e9 es la programaci\u00f3n con reconocimiento de cach\u00e9<\/h3>\n\n\n\n

Los procesadores modernos disponen de diferentes niveles de memoria cach\u00e9. Algunas cach\u00e9s pertenecen a un n\u00facleo concreto mientras que otras, como determinadas Last Level Cache o LLC<\/strong>, pueden ser compartidas por grupos de n\u00facleos.<\/p>\n\n\n\n

Eso significa que dos n\u00facleos que parecen similares desde fuera pueden encontrarse en posiciones distintas dentro de la topolog\u00eda interna del procesador.<\/p>\n\n\n\n

Si tenemos varias tareas estrechamente relacionadas que acceden continuamente a los mismos datos, enviarlas sin ning\u00fan tipo de consideraci\u00f3n a n\u00facleos que no comparten la misma cach\u00e9 puede generar trabajo adicional.<\/p>\n\n\n\n

Hay que mover informaci\u00f3n, volver a cargar determinados datos y realizar accesos que potencialmente podr\u00edan haberse evitado.<\/p>\n\n\n\n

La planificaci\u00f3n consciente de cach\u00e9 intenta que el scheduler tenga m\u00e1s informaci\u00f3n sobre esa organizaci\u00f3n.<\/p>\n\n\n\n

No se trata simplemente de decir \u201ceste procesador tiene 32 n\u00facleos y podemos utilizar cualquiera de ellos\u201d. La pregunta pasa a ser algo m\u00e1s parecida a:<\/p>\n\n\n\n

\u00bfQu\u00e9 n\u00facleos comparten recursos y d\u00f3nde tiene m\u00e1s sentido ejecutar conjuntamente estas tareas?<\/strong><\/p>\n\n\n\n

Con procesadores cada vez m\u00e1s complejos, esta cuesti\u00f3n tiene bastante sentido.<\/p>\n\n\n\n

Por qu\u00e9 compartir la cach\u00e9 de \u00faltimo nivel puede afectar al rendimiento<\/h3>\n\n\n\n

En cargas de trabajo paralelas, el rendimiento no depende \u00fanicamente de cu\u00e1ntos n\u00facleos tengamos.<\/p>\n\n\n\n

Tambi\u00e9n importa cu\u00e1nto tardan esos n\u00facleos en acceder a los datos que necesitan.<\/p>\n\n\n\n

Cuando varias tareas comparten mucha informaci\u00f3n, mantenerlas en una zona del procesador donde puedan aprovechar mejor una cach\u00e9 com\u00fan puede reducir determinados accesos y mejorar la eficiencia.<\/p>\n\n\n\n

Eso resulta especialmente interesante en servidores y m\u00e1quinas con muchos n\u00facleos, donde la topolog\u00eda interna puede ser bastante m\u00e1s compleja que en un PC dom\u00e9stico convencional.<\/p>\n\n\n\n

Es tambi\u00e9n una buena muestra de c\u00f3mo est\u00e1 cambiando la optimizaci\u00f3n de sistemas operativos.<\/p>\n\n\n\n

Durante a\u00f1os, aumentar el rendimiento consist\u00eda muchas veces en tener una CPU m\u00e1s r\u00e1pida. Ahora tenemos que aprovechar correctamente arquitecturas con numerosos n\u00facleos, jerarqu\u00edas de memoria diferentes y recursos compartidos.<\/p>\n\n\n\n

El sistema operativo necesita saber cada vez m\u00e1s c\u00f3mo est\u00e1 construido f\u00edsicamente el procesador<\/strong>.<\/p>\n\n\n\n

\u00bfVa a hacer Linux 7.2 que cualquier PC sea m\u00e1s r\u00e1pido?<\/h3>\n\n\n\n

Aqu\u00ed conviene controlar bastante las expectativas.<\/p>\n\n\n\n

No significa que instalemos Linux 7.2 y autom\u00e1ticamente todos nuestros programas vayan a funcionar mucho m\u00e1s r\u00e1pido.<\/p>\n\n\n\n

En mi caso, este tipo de optimizaciones me parecen interesantes precisamente porque no las interpreto como un supuesto \u201cturbo\u201d universal.<\/p>\n\n\n\n

La mejora depender\u00e1 much\u00edsimo del procesador, de su topolog\u00eda y, sobre todo, de la carga de trabajo.<\/p>\n\n\n\n

Habr\u00e1 situaciones donde organizar mejor las tareas alrededor de las cach\u00e9s compartidas pueda aportar beneficios perceptibles y otras donde pr\u00e1cticamente no exista diferencia.<\/p>\n\n\n\n

Aun as\u00ed, me parece una direcci\u00f3n muy l\u00f3gica para Linux.<\/p>\n\n\n\n

Cuantos m\u00e1s n\u00facleos y estructuras internas distintas tengan las pr\u00f3ximas generaciones de CPU, m\u00e1s importante ser\u00e1 que el scheduler no vea el procesador simplemente como una colecci\u00f3n plana de n\u00facleos id\u00e9nticos.<\/p>\n\n\n\n

Mejoras de rendimiento en almacenamiento, I\/O y memoria<\/h2>\n\n\n\n

Cuando hablamos de una nueva versi\u00f3n del kernel es bastante habitual fijarnos primero en los procesadores y las tarjetas gr\u00e1ficas.<\/p>\n\n\n\n

Sin embargo, en servidores y estaciones de trabajo el rendimiento del almacenamiento puede ser igual o incluso m\u00e1s importante.<\/p>\n\n\n\n

Linux 7.2 introduce diferentes cambios relacionados con la entrada y salida, los sistemas de archivos y la gesti\u00f3n de memoria<\/strong>, continuando el trabajo de optimizaci\u00f3n que lleva realiz\u00e1ndose durante varias versiones.<\/p>\n\n\n\n

Y aqu\u00ed encontramos precisamente uno de los apartados donde una mejora aparentemente peque\u00f1a dentro del kernel puede terminar teniendo consecuencias bastante mayores en determinadas cargas reales.<\/p>\n\n\n\n

Cambios en la entrada y salida que pueden importar en servidores<\/h3>\n\n\n\n

Los dispositivos NVMe modernos pueden alcanzar niveles de rendimiento enormes. A medida que el almacenamiento se vuelve m\u00e1s r\u00e1pido, la propia sobrecarga que introduce el sistema operativo adquiere m\u00e1s importancia.<\/p>\n\n\n\n

Cuando un SSD era relativamente lento, unas peque\u00f1as ineficiencias pod\u00edan quedar ocultas detr\u00e1s de la latencia del propio dispositivo.<\/p>\n\n\n\n

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\u00e1s.<\/p>\n\n\n\n

Por eso personalmente me resultan interesantes las optimizaciones de I\/O que llegan con Linux 7.2.<\/p>\n\n\n\n

No necesariamente porque vayan a convertir cualquier SSD en uno mucho m\u00e1s r\u00e1pido, sino porque el kernel necesita seguir adapt\u00e1ndose a dispositivos capaces de mover datos a velocidades que hace pocos a\u00f1os eran dif\u00edciles de imaginar en un sistema convencional.<\/p>\n\n\n\n

Hay cargas donde esto puede ser especialmente importante.<\/p>\n\n\n\n

Pienso, por ejemplo, en bases de datos<\/strong>, plataformas de virtualizaci\u00f3n, servidores que manejan numerosos archivos y aplicaciones que realizan muchas operaciones simult\u00e1neas sobre disco.<\/p>\n\n\n\n

En esos escenarios, peque\u00f1as mejoras acumuladas pueden terminar produciendo diferencias apreciables.<\/p>\n\n\n\n

Btrfs tambi\u00e9n mejora en Linux 7.2<\/h3>\n\n\n\n

Btrfs vuelve a recibir atenci\u00f3n en esta versi\u00f3n del kernel.<\/p>\n\n\n\n

Linux 7.2 contin\u00faa optimizando determinadas operaciones del sistema de archivos, incluyendo cambios relacionados con su rendimiento y la manera de gestionar diferentes operaciones de lectura y escritura.<\/p>\n\n\n\n

Esto es particularmente relevante porque Btrfs lleva a\u00f1os pasando de ser una tecnolog\u00eda que muchos usuarios consideraban experimental a convertirse en una opci\u00f3n habitual dentro de algunas distribuciones Linux.<\/p>\n\n\n\n

Cuanto mayor es su adopci\u00f3n, mayor importancia adquieren las optimizaciones que no necesariamente a\u00f1aden una caracter\u00edstica espectacular, pero reducen sobrecarga o mejoran determinadas rutas internas.<\/p>\n\n\n\n

Tambi\u00e9n 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\u00f1o originales fueron tomadas.<\/p>\n\n\n\n

Los NVMe actuales pueden manejar un paralelismo enorme.<\/p>\n\n\n\n

Aprovecharlos correctamente requiere que cada una de las capas situadas entre una aplicaci\u00f3n y el dispositivo f\u00edsico intente introducir la menor fricci\u00f3n posible.<\/p>\n\n\n\n

MGLRU, swap y gesti\u00f3n de memoria<\/h3>\n\n\n\n

Linux 7.2 tambi\u00e9n contin\u00faa trabajando en diferentes aspectos relacionados con memoria.<\/p>\n\n\n\n

Aqu\u00ed entran tecnolog\u00edas como MGLRU<\/strong>, adem\u00e1s de mejoras y ajustes en \u00e1reas como swap y memoria compartida.<\/p>\n\n\n\n

MGLRU forma parte del trabajo realizado durante los \u00faltimos a\u00f1os para mejorar c\u00f3mo Linux decide qu\u00e9 p\u00e1ginas de memoria debe conservar y cu\u00e1les puede liberar cuando existe presi\u00f3n de memoria.<\/p>\n\n\n\n

Estas optimizaciones resultan especialmente importantes porque la gesti\u00f3n de memoria es una de esas partes del sistema que pueden afectar a pr\u00e1cticamente cualquier carga, pero cuyos beneficios no siempre aparecen de manera evidente en un benchmark sencillo.<\/p>\n\n\n\n

Un servidor con memoria suficiente puede comportarse perfectamente hasta que comienza a enfrentarse a presi\u00f3n sostenida.<\/p>\n\n\n\n

Es precisamente en esas situaciones donde las decisiones del kernel empiezan a marcar diferencias mucho mayores.<\/p>\n\n\n\n

\u00bfD\u00f3nde pueden notarse realmente estas optimizaciones?<\/h3>\n\n\n\n

Aqu\u00ed aplicar\u00eda el mismo criterio que con Cache Aware Scheduling.<\/p>\n\n\n\n

No instalar\u00eda Linux 7.2 esperando que autom\u00e1ticamente cualquier SSD o aplicaci\u00f3n pase a funcionar mucho m\u00e1s r\u00e1pido.<\/p>\n\n\n\n

Pero hay escenarios donde la combinaci\u00f3n de almacenamiento r\u00e1pido, operaciones intensivas de E\/S y grandes cantidades de memoria puede hacer que estas mejoras tengan mucho sentido.<\/p>\n\n\n\n

Bases de datos, virtualizaci\u00f3n, servidores de almacenamiento, compilaciones de gran tama\u00f1o y aplicaciones con muchas operaciones concurrentes son buenos ejemplos.<\/p>\n\n\n\n

Para m\u00ed, este apartado es adem\u00e1s 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\u00e1s espectaculares.<\/p>\n\n\n\n

Linux 7.2 mejora el soporte para AMD y prepara el terreno para Zen 6<\/h2>\n\n\n\n

AMD vuelve a ocupar una parte importante del desarrollo de Linux 7.2.<\/p>\n\n\n\n

Hay cambios destinados a hardware actual, pero tambi\u00e9n bastante trabajo que prepara al kernel para la pr\u00f3xima generaci\u00f3n de productos de la compa\u00f1\u00eda.<\/p>\n\n\n\n

Esto lleva ocurriendo desde hace a\u00f1os y es una de las cosas que m\u00e1s valoro del desarrollo de Linux: el kernel no se prepara solamente para el ordenador que tenemos hoy delante<\/strong>.<\/p>\n\n\n\n

Cuando llegan nuevas generaciones de procesadores y dispositivos, parte del trabajo necesario para soportarlos correctamente ya lleva meses integrado en el proyecto.<\/p>\n\n\n\n

M\u00e1s trabajo para AMD Zen 6 y futuras plataformas<\/h3>\n\n\n\n

Linux 7.2 contin\u00faa preparando soporte para AMD Zen 6<\/strong>.<\/p>\n\n\n\n

Es importante entender este tipo de incorporaci\u00f3n como un proceso.<\/p>\n\n\n\n

El soporte de un nuevo procesador no aparece normalmente de golpe en una \u00fanica versi\u00f3n del kernel.<\/p>\n\n\n\n

Primero llegan identificadores, cambios de topolog\u00eda, administraci\u00f3n de energ\u00eda, monitorizaci\u00f3n, correcciones y diferentes piezas necesarias para que la arquitectura vaya funcionando correctamente.<\/p>\n\n\n\n

Versiones posteriores terminan completando ese puzle.<\/p>\n\n\n\n

Por eso resulta habitual encontrar referencias a generaciones de procesadores que todav\u00eda no est\u00e1n ampliamente disponibles.<\/p>\n\n\n\n

Y creo que eso es positivo.<\/p>\n\n\n\n

Cuando finalmente ese hardware llega a manos de los usuarios, resulta mucho mejor que el ecosistema Linux ya lleve tiempo preparando el terreno.<\/p>\n\n\n\n

AMD ISP4 mejora el soporte para hardware de port\u00e1tiles modernos<\/h3>\n\n\n\n

Otro cambio que me parece especialmente interesante es la incorporaci\u00f3n del controlador AMD ISP4<\/strong>.<\/p>\n\n\n\n

Los port\u00e1tiles modernos integran una enorme cantidad de componentes que necesitan trabajar correctamente con el sistema operativo.<\/p>\n\n\n\n

C\u00e1maras, controladores de imagen, gesti\u00f3n de energ\u00eda, audio, sensores y otros elementos pueden marcar la diferencia entre tener una m\u00e1quina plenamente funcional o un equipo donde siempre existe alguna caracter\u00edstica problem\u00e1tica.<\/p>\n\n\n\n

Durante mucho tiempo, uno de los t\u00f3picos asociados a Linux era precisamente que determinados port\u00e1tiles nuevos requer\u00edan meses de correcciones para alcanzar una compatibilidad realmente buena.<\/p>\n\n\n\n

La situaci\u00f3n ha mejorado much\u00edsimo.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Hay que integrar correctamente todo el conjunto de componentes del equipo.<\/p>\n\n\n\n

AMDGPU incorpora soporte inicial para HDMI 2.1 FRL<\/h3>\n\n\n\n

Otra de las novedades importantes es el soporte inicial para HDMI 2.1 FRL en AMDGPU<\/strong>.<\/p>\n\n\n\n

Esta era una de esas asignaturas pendientes dentro del soporte gr\u00e1fico de AMD en Linux.<\/p>\n\n\n\n

FRL, o Fixed Rate Link, forma parte de las tecnolog\u00edas que permiten aprovechar algunas de las capacidades de HDMI 2.1, especialmente cuando hablamos de resoluciones elevadas y frecuencias de refresco altas.<\/p>\n\n\n\n

Para un usuario con una configuraci\u00f3n convencional quiz\u00e1 no sea una novedad demasiado llamativa.<\/p>\n\n\n\n

Sin embargo, para quien conecta una Radeon a pantallas modernas de altas prestaciones, este tipo de soporte puede tener bastante m\u00e1s relevancia.<\/p>\n\n\n\n

Hay que interpretar adem\u00e1s la palabra \u201cinicial\u201d con cuidado.<\/p>\n\n\n\n

Que aparezca soporte para una tecnolog\u00eda no significa que absolutamente todas las configuraciones posibles est\u00e9n inmediatamente resueltas.<\/p>\n\n\n\n

Pero es un paso importante para ir cerrando una diferencia que todav\u00eda exist\u00eda frente a las capacidades disponibles en otros sistemas.<\/p>\n\n\n\n

Qu\u00e9 puede significar para usuarios de Radeon<\/h3>\n\n\n\n

En la pr\u00e1ctica, la noticia m\u00e1s importante no es una \u00fanica funci\u00f3n gr\u00e1fica.<\/p>\n\n\n\n

Es que AMDGPU sigue ganando capacidades necesarias para acompa\u00f1ar a monitores y televisores que cada vez utilizan resoluciones y frecuencias m\u00e1s elevadas.<\/p>\n\n\n\n

Eso incluye tecnolog\u00edas relacionadas con HDMI, compresi\u00f3n de flujo, sincronizaci\u00f3n y diferentes modos de funcionamiento.<\/p>\n\n\n\n

Me parece una evoluci\u00f3n importante precisamente porque este tipo de mejoras suelen pasar desapercibidas hasta que alguien conecta una pantalla nueva y descubre que una determinada combinaci\u00f3n no funciona como esperaba.<\/p>\n\n\n\n

Cuantas menos excepciones de este tipo existan, mejor ser\u00e1 la experiencia general de utilizar Linux en hardware moderno.<\/p>\n\n\n\n

Intel tambi\u00e9n mira al futuro con Diamond Rapids, Nova Lake y Panther Lake<\/h2>\n\n\n\n

AMD no es la \u00fanica compa\u00f1\u00eda para la que Linux 7.2 prepara soporte anticipadamente.<\/p>\n\n\n\n

Intel contin\u00faa incorporando cambios relacionados con distintas generaciones de hardware, entre ellas Diamond Rapids, Nova Lake y Panther Lake<\/strong>, adem\u00e1s de mejoras asociadas a gr\u00e1ficos, correcci\u00f3n de errores de memoria y otros subsistemas.<\/p>\n\n\n\n

Otra vez encontramos exactamente el mismo patr\u00f3n: el kernel se desarrolla pensando varios pasos por delante del hardware que actualmente domina el mercado.<\/p>\n\n\n\n

Soporte anticipado para las pr\u00f3ximas generaciones de procesadores<\/h3>\n\n\n\n

Cuando aparece el nombre de un procesador futuro dentro de las novedades de una versi\u00f3n del kernel puede parecer extra\u00f1o.<\/p>\n\n\n\n

\u00bfPor qu\u00e9 necesita Linux soportar una CPU que todav\u00eda no tiene pr\u00e1cticamente nadie?<\/p>\n\n\n\n

Precisamente porque hacerlo tarde ser\u00eda un problema.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Esto es especialmente relevante en Linux porque el kernel termina utiliz\u00e1ndose en entornos extremadamente diferentes.<\/p>\n\n\n\n

Una nueva arquitectura Intel puede acabar en ordenadores dom\u00e9sticos, estaciones de trabajo, servidores, centros de datos o infraestructura de nube.<\/p>\n\n\n\n

Cada escenario tiene necesidades distintas.<\/p>\n\n\n\n

Por eso el soporte no consiste simplemente en \u201creconocer el procesador\u201d.<\/p>\n\n\n\n

El kernel tiene que conocer correctamente sus capacidades, gesti\u00f3n energ\u00e9tica, topolog\u00eda, caracter\u00edsticas de seguridad, rendimiento y numerosos detalles adicionales.<\/p>\n\n\n\n

Mejoras de ECC y gr\u00e1ficos Intel<\/h3>\n\n\n\n

Linux 7.2 tambi\u00e9n contin\u00faa trabajando en \u00e1reas relacionadas con ECC y los gr\u00e1ficos Intel<\/strong>.<\/p>\n\n\n\n

ECC resulta particularmente importante en servidores y estaciones donde la integridad de memoria importa m\u00e1s que en un ordenador convencional.<\/p>\n\n\n\n

Por otro lado, la evoluci\u00f3n de los gr\u00e1ficos Intel se ha acelerado considerablemente durante los \u00faltimos a\u00f1os.<\/p>\n\n\n\n

Ya no hablamos \u00fanicamente de las gr\u00e1ficas integradas tradicionales.<\/p>\n\n\n\n

Intel tambi\u00e9n compite en gr\u00e1ficos dedicados, lo que obliga a su soporte Linux a cubrir escenarios mucho m\u00e1s amplios.<\/p>\n\n\n\n

En mi caso, lo que encuentro interesante de todos estos nombres \u2014Diamond Rapids, Nova Lake o Panther Lake\u2014 no es memorizar qu\u00e9 cambio concreto llega para cada uno.<\/p>\n\n\n\n

Lo realmente importante es observar c\u00f3mo funciona el desarrollo del kernel.<\/p>\n\n\n\n

Linux intenta llegar preparado al hardware, no reaccionar varios meses despu\u00e9s.<\/p>\n\n\n\n

Y esa filosof\u00eda es especialmente valiosa en un sistema operativo que puede terminar ejecut\u00e1ndose pr\u00e1cticamente en cualquier tipo de m\u00e1quina.<\/p>\n\n\n\n

Virtualizaci\u00f3n confidencial: los m\u00f3dulos TDX pueden actualizarse en ejecuci\u00f3n<\/h2>\n\n\n\n

Linux 7.2 tambi\u00e9n introduce mejoras relacionadas con tecnolog\u00edas de virtualizaci\u00f3n confidencial.<\/p>\n\n\n\n

Una de ellas afecta a Intel TDX<\/strong>, que permite actualizar determinados m\u00f3dulos durante la ejecuci\u00f3n.<\/p>\n\n\n\n

Para un usuario dom\u00e9stico puede parecer un cambio bastante distante.<\/p>\n\n\n\n

En infraestructura de servidores, sin embargo, poder corregir o actualizar determinados componentes sin necesidad de reiniciar completamente una m\u00e1quina puede tener bastante m\u00e1s valor.<\/p>\n\n\n\n

Qu\u00e9 es TDX y por qu\u00e9 importa<\/h3>\n\n\n\n

TDX forma parte del conjunto de tecnolog\u00edas dise\u00f1adas para crear entornos de ejecuci\u00f3n virtualizados donde incluso determinados componentes de la infraestructura anfitriona tienen un acceso limitado a la informaci\u00f3n que est\u00e1 procesando una m\u00e1quina virtual.<\/p>\n\n\n\n

La idea forma parte del concepto m\u00e1s amplio de computaci\u00f3n confidencial<\/strong>.<\/p>\n\n\n\n

Tradicionalmente protegemos la informaci\u00f3n cuando est\u00e1 almacenada y cuando viaja por una red.<\/p>\n\n\n\n

La computaci\u00f3n confidencial intenta mejorar tambi\u00e9n su protecci\u00f3n mientras est\u00e1 siendo procesada.<\/p>\n\n\n\n

Esto tiene aplicaciones evidentes en servicios cloud, entornos empresariales y plataformas donde diferentes clientes utilizan una misma infraestructura f\u00edsica.<\/p>\n\n\n\n

Actualizar sin reiniciar puede ser clave en infraestructura cr\u00edtica<\/h3>\n\n\n\n

Desde el punto de vista operativo, la posibilidad de realizar determinadas actualizaciones en ejecuci\u00f3n es probablemente la parte m\u00e1s interesante.<\/p>\n\n\n\n

En un ordenador personal reiniciar puede ser una molestia de un par de minutos.<\/p>\n\n\n\n

En un servidor que ejecuta servicios importantes, un reinicio puede implicar migraciones, ventanas de mantenimiento, redundancia adicional y coordinaci\u00f3n con otros sistemas.<\/p>\n\n\n\n

No significa que podamos eliminar todos los reinicios ni aplicar cualquier actualizaci\u00f3n sin interrupciones.<\/p>\n\n\n\n

Pero reducirlos all\u00ed donde sea posible tiene un valor bastante claro.<\/p>\n\n\n\n

Es tambi\u00e9n otra muestra de hasta qu\u00e9 punto el kernel Linux necesita responder a escenarios que van much\u00edsimo m\u00e1s all\u00e1 de un PC de escritorio.<\/p>\n\n\n\n

Linux contin\u00faa dejando atr\u00e1s componentes hist\u00f3ricos de i486<\/h2>\n\n\n\n

No todas las novedades consisten en a\u00f1adir c\u00f3digo.<\/p>\n\n\n\n

Linux 7.2 contin\u00faa tambi\u00e9n el proceso de despedirse de componentes relacionados con la antigua arquitectura i486<\/strong>.<\/p>\n\n\n\n

Para quienes llevan muchos a\u00f1os siguiendo Linux, este tipo de decisiones puede tener cierto componente nost\u00e1lgico.<\/p>\n\n\n\n

Durante d\u00e9cadas una de las grandes fortalezas del kernel ha sido su capacidad de ejecutar una enorme variedad de hardware, incluyendo m\u00e1quinas extraordinariamente antiguas.<\/p>\n\n\n\n

Pero esa compatibilidad tampoco es gratuita.<\/p>\n\n\n\n

Por qu\u00e9 mantener compatibilidad indefinidamente tambi\u00e9n tiene un coste<\/h3>\n\n\n\n

Cada arquitectura antigua que permanece dentro de un proyecto del tama\u00f1o del kernel puede implicar excepciones, rutas espec\u00edficas de c\u00f3digo, pruebas y condicionantes que los desarrolladores deben seguir teniendo en cuenta.<\/p>\n\n\n\n

Llega un momento en el que hay que preguntarse si ese mantenimiento contin\u00faa teniendo sentido.<\/p>\n\n\n\n

Personalmente creo que eliminar soporte extremadamente antiguo cuando ya pr\u00e1cticamente no existen usuarios reales afectados forma parte de la evoluci\u00f3n normal de un proyecto.<\/p>\n\n\n\n

Conservar compatibilidad por el simple hecho de conservarla puede terminar dificultando cambios que beneficien a millones de sistemas actuales.<\/p>\n\n\n\n

Esto no significa que Linux est\u00e9 abandonando de repente su tradici\u00f3n de funcionar en una gran variedad de dispositivos.<\/p>\n\n\n\n

Sigue siendo probablemente uno de los kernels con mayor diversidad de hardware del mundo.<\/p>\n\n\n\n

Significa simplemente que esa compatibilidad tiene que revisarse de vez en cuando.<\/p>\n\n\n\n

Y, parad\u00f3jicamente, eliminar determinadas piezas antiguas puede ayudar a mantener m\u00e1s sano el c\u00f3digo que necesitan las m\u00e1quinas modernas.<\/p>\n\n\n\n

La IA y los LLM empiezan a cambiar c\u00f3mo se desarrolla el kernel Linux<\/h2>\n\n\n\n

Probablemente una de las cosas que m\u00e1s me ha llamado la atenci\u00f3n alrededor del ciclo de Linux 7.2 no sea una funci\u00f3n concreta del kernel.<\/p>\n\n\n\n

Es la presencia creciente de inteligencia artificial y modelos de lenguaje en el propio proceso de desarrollo<\/strong>.<\/p>\n\n\n\n

Herramientas basadas en IA pueden ayudar a buscar errores, analizar c\u00f3digo, generar propuestas de parches, revisar cambios o detectar determinados patrones.<\/p>\n\n\n\n

En un proyecto tan grande como Linux, cualquier tecnolog\u00eda capaz de acelerar ese trabajo tiene un potencial enorme.<\/p>\n\n\n\n

Pero tambi\u00e9n plantea un problema bastante interesante.<\/p>\n\n\n\n

M\u00e1s parches, revisiones e informes de errores asistidos por IA<\/h3>\n\n\n\n

Crear c\u00f3digo ha sido tradicionalmente una tarea costosa.<\/p>\n\n\n\n

Un desarrollador ten\u00eda que entender el problema, localizar d\u00f3nde modificar el sistema, escribir una soluci\u00f3n y preparar el cambio.<\/p>\n\n\n\n

Los LLM pueden reducir parte de ese coste.<\/p>\n\n\n\n

Tambi\u00e9n pueden permitir analizar cantidades de c\u00f3digo que manualmente requerir\u00edan mucho m\u00e1s tiempo.<\/p>\n\n\n\n

Eso puede producir m\u00e1s informes de errores, m\u00e1s propuestas y m\u00e1s posibles correcciones.<\/p>\n\n\n\n

En principio parece una ventaja evidente.<\/p>\n\n\n\n

Pero Linux no puede integrar c\u00f3digo simplemente porque alguien \u2014o alg\u00fan sistema\u2014 sea capaz de producirlo.<\/p>\n\n\n\n

Cada cambio necesita revisi\u00f3n.<\/p>\n\n\n\n

Y cuanto m\u00e1s cr\u00edtico es el software, mayor debe ser la exigencia.<\/p>\n\n\n\n

El problema puede pasar de generar c\u00f3digo a poder revisarlo<\/h3>\n\n\n\n

Aqu\u00ed creo que est\u00e1 uno de los debates m\u00e1s importantes que veremos durante los pr\u00f3ximos a\u00f1os.<\/p>\n\n\n\n

Si las herramientas de IA permiten generar parches diez veces m\u00e1s r\u00e1pido, pero la capacidad humana para revisarlos apenas aumenta, entonces no hemos eliminado el cuello de botella.<\/p>\n\n\n\n

Lo hemos desplazado.<\/p>\n\n\n\n

Podemos acabar con una cantidad enorme de propuestas que necesitan ser comprobadas por desarrolladores que conocen perfectamente cada subsistema.<\/p>\n\n\n\n

Y revisar c\u00f3digo generado autom\u00e1ticamente tampoco tiene por qu\u00e9 ser m\u00e1s sencillo que escribirlo.<\/p>\n\n\n\n

Si una propuesta parece correcta pero introduce un fallo extremadamente sutil, la revisi\u00f3n puede incluso requerir m\u00e1s esfuerzo.<\/p>\n\n\n\n

Por qu\u00e9 la revisi\u00f3n humana sigue siendo cr\u00edtica<\/h3>\n\n\n\n

Linux se ejecuta en servidores, tel\u00e9fonos, sistemas industriales, infraestructura de red, superordenadores y una cantidad pr\u00e1cticamente innumerable de dispositivos.<\/p>\n\n\n\n

Un error en el kernel puede tener consecuencias muy superiores a las de un fallo dentro de una aplicaci\u00f3n convencional.<\/p>\n\n\n\n

Por eso sigo pensando que generar m\u00e1s c\u00f3digo no sirve de mucho si no podemos verificarlo con el mismo nivel de exigencia<\/strong>.<\/p>\n\n\n\n

La IA puede convertirse en una herramienta tremendamente \u00fatil para el desarrollo de Linux.<\/p>\n\n\n\n

Ser\u00eda absurdo ignorar su capacidad para automatizar tareas repetitivas, detectar problemas y acelerar investigaciones.<\/p>\n\n\n\n

Pero tambi\u00e9n obliga a replantear qu\u00e9 significa revisar una contribuci\u00f3n y c\u00f3mo se mantiene la confianza en un proyecto donde cada vez ser\u00e1 m\u00e1s f\u00e1cil producir grandes cantidades de c\u00f3digo.<\/p>\n\n\n\n

No me extra\u00f1ar\u00eda que este asunto terminara siendo bastante m\u00e1s importante para el futuro del kernel que muchas caracter\u00edsticas t\u00e9cnicas individuales.<\/p>\n\n\n\n

\u00bfMerece la pena actualizar a Linux 7.2?<\/h2>\n\n\n\n

Llegados a este punto aparece inevitablemente la pregunta:<\/p>\n\n\n\n

\u00bfDeber\u00eda actualizar a Linux 7.2?<\/strong><\/p>\n\n\n\n

Mi respuesta ser\u00eda que depende completamente del sistema.<\/p>\n\n\n\n

Que exista una versi\u00f3n m\u00e1s nueva del kernel no significa que todas las m\u00e1quinas deban actualizar<\/a> inmediatamente.<\/p>\n\n\n\n

Usuarios de escritorio y hardware reciente<\/h3>\n\n\n\n

En un ordenador personal, especialmente si utilizamos hardware relativamente nuevo, actualizar puede tener bastante sentido.<\/p>\n\n\n\n

Las versiones recientes del kernel suelen incorporar:<\/p>\n\n\n\n

    \n
  • compatibilidad con nuevos dispositivos;<\/li>\n\n\n\n
  • mejoras de AMDGPU e Intel;<\/li>\n\n\n\n
  • correcciones;<\/li>\n\n\n\n
  • mejor gesti\u00f3n energ\u00e9tica;<\/li>\n\n\n\n
  • optimizaciones de rendimiento;<\/li>\n\n\n\n
  • soporte para nuevas plataformas.<\/li>\n<\/ul>\n\n\n\n

    Si tenemos un componente que funciona mal con un kernel antiguo o necesitamos espec\u00edficamente alguna de las novedades de Linux 7.2, disponer de una versi\u00f3n m\u00e1s reciente puede solucionar problemas reales.<\/p>\n\n\n\n

    Las distribuciones rolling release normalmente son las primeras en adoptar kernels recientes precisamente porque su filosof\u00eda consiste en ofrecer versiones nuevas con rapidez.<\/p>\n\n\n\n

    Servidores y sistemas en producci\u00f3n<\/h3>\n\n\n\n

    La situaci\u00f3n cambia bastante cuando hablamos de servidores.<\/p>\n\n\n\n

    Personalmente, no actualizar\u00eda una m\u00e1quina de producci\u00f3n simplemente porque Linux 7.2 exista.<\/p>\n\n\n\n

    En ese contexto sigo prefiriendo estabilidad, pruebas y kernels mantenidos por la propia distribuci\u00f3n<\/strong> antes que perseguir constantemente la \u00faltima versi\u00f3n.<\/p>\n\n\n\n

    Un kernel reciente puede incluir mejoras muy interesantes, pero tambi\u00e9n introduce c\u00f3digo que ha tenido menos tiempo para probarse en configuraciones reales.<\/p>\n\n\n\n

    Adem\u00e1s, distribuciones empresariales y versiones estables suelen trasladar correcciones importantes a kernels anteriores mediante backports.<\/p>\n\n\n\n

    Por tanto, utilizar una versi\u00f3n num\u00e9ricamente m\u00e1s antigua no significa necesariamente estar utilizando un kernel inseguro o completamente desactualizado.<\/p>\n\n\n\n

    Por qu\u00e9 no siempre conviene perseguir el kernel m\u00e1s nuevo<\/h3>\n\n\n\n

    La versi\u00f3n adecuada depende del objetivo.<\/p>\n\n\n\n

    Si estamos probando hardware nuevo, desarrollando software, utilizando una distribuci\u00f3n rolling release o necesitamos una caracter\u00edstica espec\u00edfica, Linux 7.2 puede resultar muy interesante.<\/p>\n\n\n\n

    Si administramos infraestructura cr\u00edtica, la pregunta deber\u00eda ser otra:<\/p>\n\n\n\n

    \u00bfQu\u00e9 problema estoy resolviendo actualizando?<\/strong><\/p>\n\n\n\n

    Si no existe una respuesta clara, quiz\u00e1 sea mejor esperar a que nuestra distribuci\u00f3n pruebe e integre la versi\u00f3n correspondiente.<\/p>\n\n\n\n

    Esto me parece especialmente importante porque en tecnolog\u00eda tendemos a asociar autom\u00e1ticamente \u201cm\u00e1s nuevo\u201d con \u201cmejor\u201d.<\/p>\n\n\n\n

    En producci\u00f3n, muchas veces mejor significa m\u00e1s predecible<\/strong>.<\/p>\n\n\n\n

    \u00bfCu\u00e1ndo llegar\u00e1 Linux 7.2 a mi distribuci\u00f3n?<\/h2>\n\n\n\n

    La publicaci\u00f3n de Linux 7.2 no significa que todos los usuarios vayan a recibirlo inmediatamente.<\/p>\n\n\n\n

    El kernel y las distribuciones Linux siguen ciclos de desarrollo diferentes.<\/p>\n\n\n\n

    Una distribuci\u00f3n decide qu\u00e9 versi\u00f3n utilizar, qu\u00e9 parches adicionales incorporar y durante cu\u00e1nto tiempo mantenerla.<\/p>\n\n\n\n

    Rolling releases frente a distribuciones estables<\/h3>\n\n\n\n

    Distribuciones rolling release suelen incorporar kernels recientes bastante r\u00e1pido.<\/p>\n\n\n\n

    Su modelo est\u00e1 pensado precisamente para mantener paquetes y componentes cercanos a las \u00faltimas versiones disponibles.<\/p>\n\n\n\n

    En distribuciones estables el enfoque puede ser completamente distinto.<\/p>\n\n\n\n

    Una versi\u00f3n de Debian, Ubuntu u otra distribuci\u00f3n con ciclos definidos puede mantener durante mucho tiempo una rama del kernel concreta y aplicar sobre ella actualizaciones de seguridad, correcciones y backports.<\/p>\n\n\n\n

    Eso no debe interpretarse autom\u00e1ticamente como una desventaja.<\/p>\n\n\n\n

    De hecho, es exactamente lo que muchos administradores buscan en servidores.<\/p>\n\n\n\n

    Quieren una base relativamente estable donde los cambios est\u00e9n controlados.<\/p>\n\n\n\n

    Por qu\u00e9 el kernel de tu distribuci\u00f3n puede tardar en actualizarse<\/h3>\n\n\n\n

    Antes de adoptar una nueva versi\u00f3n, los mantenedores pueden necesitar probar:<\/p>\n\n\n\n

      \n
    • controladores;<\/li>\n\n\n\n
    • m\u00f3dulos externos;<\/li>\n\n\n\n
    • sistemas de archivos;<\/li>\n\n\n\n
    • mecanismos de arranque;<\/li>\n\n\n\n
    • herramientas de seguridad;<\/li>\n\n\n\n
    • virtualizaci\u00f3n;<\/li>\n\n\n\n
    • compatibilidad con hardware;<\/li>\n\n\n\n
    • parches propios de la distribuci\u00f3n.<\/li>\n<\/ul>\n\n\n\n

      Todo eso lleva tiempo.<\/p>\n\n\n\n

      Por eso no recomendar\u00eda instalar manualmente Linux 7.2 \u00fanicamente para conseguir tener el n\u00famero de versi\u00f3n m\u00e1s alto.<\/p>\n\n\n\n

      Si necesitamos espec\u00edficamente una funci\u00f3n nueva, entonces s\u00ed tiene sentido valorar las distintas opciones.<\/p>\n\n\n\n

      En caso contrario, seguir el kernel oficialmente mantenido por nuestra distribuci\u00f3n contin\u00faa siendo una decisi\u00f3n perfectamente v\u00e1lida.<\/p>\n\n\n\n

      Linux 7.2 muestra hacia d\u00f3nde se dirige el kernel<\/h2>\n\n\n\n

      Despu\u00e9s de repasar sus novedades, Linux 7.2 me parece una actualizaci\u00f3n bastante representativa de la evoluci\u00f3n que est\u00e1 siguiendo el kernel.<\/p>\n\n\n\n

      No hay una sola funci\u00f3n que pueda resumir toda la versi\u00f3n.<\/p>\n\n\n\n

      Y quiz\u00e1 sea precisamente eso lo interesante.<\/p>\n\n\n\n

      Tenemos Cache Aware Scheduling<\/strong>, que intenta adaptar mejor la planificaci\u00f3n a la estructura f\u00edsica de los procesadores modernos.<\/p>\n\n\n\n

      Encontramos mejoras de entrada y salida para un mundo donde los dispositivos NVMe pueden procesar cantidades enormes de informaci\u00f3n.<\/p>\n\n\n\n

      AMD e Intel contin\u00faan incorporando soporte para generaciones de hardware que todav\u00eda est\u00e1n llegando al mercado.<\/p>\n\n\n\n

      AMDGPU avanza con tecnolog\u00edas como HDMI 2.1 FRL.<\/p>\n\n\n\n

      La virtualizaci\u00f3n confidencial sigue evolucionando.<\/p>\n\n\n\n

      Al mismo tiempo, el kernel contin\u00faa eliminando algunas piezas heredadas de arquitecturas hist\u00f3ricas como i486.<\/p>\n\n\n\n

      Y por encima de todos esos cambios aparece una transformaci\u00f3n que afecta a c\u00f3mo se desarrolla el propio proyecto: la utilizaci\u00f3n cada vez mayor de herramientas de IA y LLM.<\/p>\n\n\n\n

      Todo apunta en la misma direcci\u00f3n.<\/p>\n\n\n\n

      Los ordenadores son cada vez menos simples.<\/p>\n\n\n\n

      Tenemos m\u00e1s n\u00facleos, m\u00e1s niveles de cach\u00e9, arquitecturas h\u00edbridas, almacenamiento extremadamente r\u00e1pido, componentes especializados y entornos virtualizados donde la seguridad necesita extenderse incluso a los datos que est\u00e1n siendo procesados.<\/p>\n\n\n\n

      El kernel necesita entender cada vez mejor esa complejidad.<\/p>\n\n\n\n

      Por eso, en mi caso, no veo Linux 7.2 como una versi\u00f3n que vaya a cambiar radicalmente la experiencia de todos los usuarios de un d\u00eda para otro.<\/p>\n\n\n\n

      La veo como una versi\u00f3n que contin\u00faa preparando los cimientos.<\/p>\n\n\n\n

      Y muchas veces ese tipo de actualizaciones terminan siendo m\u00e1s importantes a largo plazo que una caracter\u00edstica espectacular que ocupa todos los titulares durante unas semanas.<\/p>\n\n\n\n

      Linux 7.2 deja bastante claro hacia d\u00f3nde est\u00e1 evolucionando el kernel: m\u00e1s consciente del hardware, m\u00e1s preparado para arquitecturas complejas y cada vez m\u00e1s optimizado para las m\u00e1quinas que utilizaremos durante los pr\u00f3ximos a\u00f1os<\/strong>.<\/p>\n\n\n\n

      Dudas de la comunidad<\/h2>\n\n\n\n

      \u00bfQu\u00e9 es Linux 7.2?<\/h3>\n\n\n\n

      Linux 7.2 es una versi\u00f3n del kernel Linux<\/strong>, el componente central que se encarga de gestionar hardware, memoria, procesos, dispositivos, sistemas de archivos y numerosos recursos del sistema.<\/p>\n\n\n\n

      No es una distribuci\u00f3n nueva.<\/p>\n\n\n\n

      Ubuntu, Debian, Fedora, Arch Linux y otras distribuciones utilizan el kernel Linux, pero cada una decide qu\u00e9 versi\u00f3n integrar y cu\u00e1ndo hacerlo.<\/p>\n\n\n\n

      \u00bfCu\u00e1les son las principales novedades de Linux 7.2?<\/h3>\n\n\n\n

      Entre las novedades m\u00e1s importantes encontramos mejoras de planificaci\u00f3n 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\u00f3n confidencial y la retirada progresiva de determinados componentes asociados a i486.<\/p>\n\n\n\n

      \u00bfQu\u00e9 es Cache Aware Scheduling?<\/h3>\n\n\n\n

      Es una mejora de planificaci\u00f3n que tiene en cuenta c\u00f3mo est\u00e1n organizadas las cach\u00e9s de la CPU.<\/p>\n\n\n\n

      La idea es que determinadas tareas relacionadas puedan ejecutarse de una forma que aproveche mejor los recursos de cach\u00e9 compartidos entre n\u00facleos, reduciendo potencialmente accesos innecesarios.<\/p>\n\n\n\n

      Su impacto depender\u00e1 de la arquitectura del procesador y de la carga de trabajo.<\/p>\n\n\n\n

      \u00bfLinux 7.2 mejora el rendimiento?<\/h3>\n\n\n\n

      S\u00ed incluye diferentes optimizaciones de rendimiento, pero no existe un aumento universal aplicable a todos los ordenadores.<\/p>\n\n\n\n

      El impacto depender\u00e1 enormemente del hardware, la aplicaci\u00f3n y la carga utilizada.<\/p>\n\n\n\n

      Una m\u00e1quina con muchos n\u00facleos o un servidor con almacenamiento NVMe puede beneficiarse de determinados cambios de forma diferente a un port\u00e1til convencional.<\/p>\n\n\n\n

      \u00bfQu\u00e9 novedades trae Linux 7.2 para AMD?<\/h3>\n\n\n\n

      Linux 7.2 contin\u00faa preparando soporte para futuras plataformas como Zen 6 e introduce mejoras para hardware AMD actual.<\/p>\n\n\n\n

      Tambi\u00e9n destaca la incorporaci\u00f3n de AMD ISP4 y el avance del soporte HDMI 2.1 FRL dentro de AMDGPU.<\/p>\n\n\n\n

      \u00bfQu\u00e9 mejoras incorpora Linux 7.2 para Intel?<\/h3>\n\n\n\n

      El kernel sigue preparando soporte para futuras generaciones como Diamond Rapids, Nova Lake y Panther Lake, adem\u00e1s de continuar mejorando diferentes \u00e1reas relacionadas con gr\u00e1ficos, ECC y plataformas Intel.<\/p>\n\n\n\n

      \u00bfLinux 7.2 mejora Btrfs y el rendimiento de almacenamiento?<\/h3>\n\n\n\n

      Btrfs y diferentes rutas relacionadas con entrada y salida reciben optimizaciones.<\/p>\n\n\n\n

      Eso no significa que cualquier unidad vaya a experimentar autom\u00e1ticamente una gran subida de rendimiento, pero determinadas cargas intensivas de almacenamiento pueden beneficiarse de las mejoras internas.<\/p>\n\n\n\n

      \u00bfLinux 7.2 elimina el soporte para i486?<\/h3>\n\n\n\n

      Linux contin\u00faa retirando componentes hist\u00f3ricos asociados a la arquitectura i486.<\/p>\n\n\n\n

      Es parte de un proceso de simplificaci\u00f3n del kernel mediante la eliminaci\u00f3n de c\u00f3digo destinado a hardware extremadamente antiguo y con un uso real cada vez menor.<\/p>\n\n\n\n

      \u00bfMerece la pena actualizar a Linux 7.2?<\/h3>\n\n\n\n

      Depende.<\/p>\n\n\n\n

      En hardware nuevo o en sistemas donde necesitemos alguna caracter\u00edstica o controlador concreto puede tener sentido.<\/p>\n\n\n\n

      En servidores de producci\u00f3n prefiero seguir el kernel probado y mantenido por la distribuci\u00f3n salvo que exista una raz\u00f3n t\u00e9cnica clara para actualizar.<\/p>\n\n\n\n

      La \u00faltima versi\u00f3n disponible no es autom\u00e1ticamente la mejor versi\u00f3n para todas las m\u00e1quinas.<\/p>\n\n\n\n

      \u00bfCu\u00e1ndo llegar\u00e1 Linux 7.2 a Ubuntu, Debian, Fedora o Arch Linux?<\/h3>\n\n\n\n

      Depender\u00e1 de la pol\u00edtica de cada distribuci\u00f3n.<\/p>\n\n\n\n

      Las distribuciones rolling release suelen adoptar kernels recientes con mayor rapidez, mientras que las distribuciones estables pueden mantener durante m\u00e1s tiempo una versi\u00f3n anterior aplicando correcciones y actualizaciones de seguridad.<\/p>\n\n\n\n

      Por eso la publicaci\u00f3n de Linux 7.2 no implica que vaya a aparecer inmediatamente en todas las distribuciones.<\/p>\n\n\n\n

      Opini\u00f3n Personal<\/strong><\/p>\n\n\n\n

      Linux 7.2 me parece una de esas versiones que demuestran que la evoluci\u00f3n del kernel no necesita una funci\u00f3n revolucionaria para ser realmente importante. Lo que m\u00e1s valoro es la suma de mejoras en planificaci\u00f3n, almacenamiento, memoria, gr\u00e1ficos, virtualizaci\u00f3n 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\u00f3nde se dirige el hardware: m\u00e1s n\u00facleos, arquitecturas m\u00e1s complejas y una necesidad cada vez mayor de que el sistema operativo entienda c\u00f3mo est\u00e1 organizado f\u00edsicamente el procesador.<\/p>\n\n\n\n

      Tambi\u00e9n creo que conviene mantener cierta perspectiva. No actualizar\u00eda un servidor de producci\u00f3n simplemente porque exista una versi\u00f3n nueva del kernel. En esos entornos sigo prefiriendo estabilidad, pruebas y el soporte de la propia distribuci\u00f3n antes que perseguir siempre la \u00faltima versi\u00f3n disponible. Linux 7.2 puede aportar mejoras importantes, pero su impacto real depender\u00e1 much\u00edsimo del hardware y de la carga de trabajo.<\/p>\n\n\n\n

      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\u00f3digo o acelerar la creaci\u00f3n de parches, pero tambi\u00e9n plantean una cuesti\u00f3n importante: generar m\u00e1s c\u00f3digo no sirve de mucho si despu\u00e9s no existe suficiente capacidad humana para revisarlo con el mismo nivel de exigencia.<\/p>\n\n\n\n

      En conjunto, veo Linux 7.2 como una actualizaci\u00f3n muy completa y, sobre todo, como una muestra bastante clara de hacia d\u00f3nde est\u00e1 evolucionando Linux durante los pr\u00f3ximos a\u00f1os.<\/p>\n\n\n\n

      \u00bfQu\u00e9 te parece Linux 7.2? \u00bfHay alguna novedad que te resulte especialmente interesante o tienes pensado actualizar tu equipo? Te leo en los comentarios.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

      Linux 7.2 ya est\u00e1 aqu\u00ed y, al menos para m\u00ed, es una de esas versiones del kernel que resultan m\u00e1s interesantes cuando dejas de buscar la gran caracter\u00edstica revolucionaria y empiezas a mirar todo lo que ha cambiado debajo del cap\u00f3. No hay una \u00fanica novedad que transforme por completo la experiencia de utilizar Linux. […]<\/p>\n","protected":false},"author":1,"featured_media":9519,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_aifi_custom_prompt":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[317,1466,779,838],"class_list":["post-9518","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-noticias","tag-actualizacion","tag-distros","tag-linux","tag-unix"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/9518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=9518"}],"version-history":[{"count":1,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/9518\/revisions"}],"predecessor-version":[{"id":9521,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/9518\/revisions\/9521"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/9519"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=9518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=9518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=9518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}