Tras los últimos cambios en torno al tiempo de soporte de las versiones de Linux, quedaba todavía una duda por resolver: cuál sería, de acuerdo a la cadencia mantenida a lo largo de los últimos años, la versión LTS del presente y aunque auguramos que sería la 6.6, llegó su lanzamiento sin noticias al respecto. Pero ya está claro: Linux 6.6 es la nueva versión LTS del kernel.

Así lo confirma la tabla de longterm release kernels que se puede consultar en The Linux Kernel Archives y que ha salido actualizada en los últimos días con la versión que nos ocupa. En resumen, Linux 6.6 tendrá soporte hasta diciembre de 2026. Nada fuera de lo normal, pero lo suficiente como marcarla como la nueva LTS del kernel para 2023.

Cabe recordar, pues, los cambios en el tiempo de soporte de las versiones de Linux a los que hacíamos mención al principio de esta entrada, y es que el mismo se ha reducido de los 6 a los 2 años por los motivos que ahí se recogen, incluyendo falta de implicación empresarial y, por lo tanto, falta de mano de obra, pero también falta de interés por parte de los usuarios en estirar tanto el chicle, habida cuenta de que cada año se asigna una nueva versión LTS.

De hecho, el hachazo se dio tan de improviso que tres de las versiones LTS de Linux más recientes se despedirán al unísono en diciembre de 2026: Linux 5.10, Linux 5.15 y Linux 6.6. Las demás lo harán un poco antes: Linux 4.14 terminará su recorrido en enero de 2024, Linux 4.19 en diciembre de ese mismo año y Linux 5.4 hará lo propio en diciembre de 2025.

Solo queda una, cuya suerte será diferente al resto, ya que tal y como os contamos hace poco ha emergido una nueva categoría de soporte extendido -al margen de los mantenedores habituales, eso sí, pero con todas las garantías de calidad- Linux 6.1 se ha convertido en la primera versión SLTS del kernel, por lo que gozará de un mínimo de 10 años de soporte: se lanzó en diciembre de 2022 y se alargará hasta diciembre de 2032.

Por su parte, Linux 6.6 vio la luz a finales del pasado octubre y como añadido al conjunto de novedades que trajo consigo y de las que nos hicimos eco en ese artículo, había una que se ha resistido unas semanas en hacerse notar, como son las siglas LTS y lo que ello significa. Dicho lo cual, todavía se espera un lanzamiento más del kernel antes de acabar el año.

Fuente Muy Linux.

Uno de los hechos más importantes de Linux 6 es la proliferación en su interior de código escrito en Rust, el lenguaje creado en su momento por Mozilla y que opera de manera independiente desde hace tiempo. Como suele ser habitual dentro del mundillo desde hace una década y media, la introducción de nuevas tecnologías tiende a sembrar debates, y este caso no es un excepción.

El veterano Steven Vaughan-Nichols ha hecho para ZDNet un repaso de la situación de Rust en el kernel Linux a partir de la conferencia dada por Miguel Ojeda en la Linux Plumbers Conference celebrada en la ciudad de Richmond, ubicada en el estado estadounidense de Virginia. Aquí se señalaron tanto las presuntas virtudes que debería aportar el lenguaje como algunas cosas no tan positivas que han surgido en torno a él, aunque la implementación sigue madurando y cuenta con un fuerte apoyo de compañías como Cisco, Samsung y Canonical.

Entre otras cosas recogidas están unas frases de Wedson Almeida Filho, ingeniero de software en Microsoft, quien dijo que siente “que Rust ahora está listo para unirse a C como lenguaje práctico para implementar el kernel. Puede ayudarnos a reducir la cantidad de posibles errores y vulnerabilidades de seguridad en el código privilegiado, al mismo tiempo que funciona bien con el núcleo central y preserva sus características de rendimiento”.

Llegados a este punto, nos encontramos con una de las principales promesas de Rust, y es la de mejorar la seguridad en torno a la memoria. Linus Torvalds mostró en su momento cierto escepticismo sobre esta capacidad, pero si ha dado su visto bueno a la inclusión del lenguaje, nos suponemos que se habrá convencido.

Continuando con los aspectos de la seguridad relacionados con la memoria que sobre el papel mejora Rust, los desarrolladores Alex Gaynor y Geoffrey Thomas explicaron en la Linux Security Summit de 2019 que casi dos tercios de los agujeros de seguridad que se encuentran en Linux provienen de problemas de seguridad en la memoria y que el origen está en debilidades inherentes a C y C++. Aquí es donde entraría Rust, que por su diseño debería evitar estos problemas mediante el uso de API más seguras.

Rust es un lenguaje de programación que ha despertado mucho interés, pero cuya popularidad al menos en producción sigue estando por detrás de otros que son mucho más veteranos. Su implementación dentro del kernel ha derivado en que los programadores están siguiendo la última versión del compilador de Rust, lo cual es bastante inusual en un proyecto de tendencia conservadora como Linux.

El intentar emplear la última versión del compilador de Rust ha despertado cierta preocupación entre algunos desarrolladores de Linux, en especial por el posible uso de características que todavía están consideradas como inestables y por cuestiones relacionadas con la retrocompatibilidad. El emplear cosas cuya presencia futura no está garantizada es algo que, por lógica, siembra dudas en un proyecto que necesita que sus cimientos sean lo más estables posible.

Otro asunto que ha surgido es la demanda de portar hacia atrás el soporte de Rust a versiones LTS de Linux. Una vez más, nos encontramos con la política conservadora empleada para el desarrollo del kernel, la cual tiende a no dejar la puerta abierta a portar cosas hacia atrás, aunque sea algo que se permite bajo ciertas condiciones.

Y siguiendo con más desafíos, está que los desarrolladores que programan en Rust están dispuestos a no cumplir, o al menos no cumplir del todo, la regla contra los controladores duplicados. Esto es debido a que algunos están abiertos a experimentar con el lenguaje para ver qué resultados obtienen. Aquí se suma el hecho de que la abstracción requerida para los drivers escritos en Rust no está ahí y que la fusión podría romper una regla relacionada con el desarrollo del kernel, así que Miguel Ojeda y su equipo han solicitado un excepción para los controladores hechos con el lenguaje originario de Mozilla.

Fedora, la distribución comunitaria patrocinada por Red Hat, cumple hoy su vigésimo aniversario. Veinte años han pasado desde el anuncio de Fedora Core 1, que fue el pistoletazo de salida de un proyecto creado con el fin de acelerar el desarrollo de las tecnologías que son implementadas en Red Hat Enteprise Linux (RHEL) y que en la actualidad señala el rumbo tecnológico de Linux, sobre todo entre las distribuciones que usan systemd.

Con el nombre original de Fedora Core, la distribución fue creada el 6 de noviembre de 2003 a partir de una bifurcación de Red Hat Linux. Además de acelerar el desarrollo de tecnologías, permitió al gigante del sombrero rojo centrarse más en sus soluciones de pago, que es a fin de cuentas de lo que vive al menos en un principio. Aunque está patrocinada por la compañía y cuenta con una fuerte implicación de empleados de esta, a nivel oficial es una distribución comunitaria con un desarrollo abierto y que proporciona los sistemas que impulsa de forma gratuita.

Fedora Core 1 fue proporcionado en su momento como “una plataforma Linux completa construida exclusivamente a partir de software de código abierto. Disponible sin costo alguno, la versión satisface las necesidades de los desarrolladores, probadores y otros entusiastas de la tecnología en la comunidad que desean participar y acelerar el proceso de desarrollo tecnológico”. Aquí nos encontramos con dos pilares del proyecto que en la actualidad se mantienen tal cual: el impulso de tecnologías y el fuerte enfoque en el código abierto.

El enfoque experimental de Fedora es algo de sobras conocido y que ha convertido con el paso de los años a esta distribución en la gran referente de la evolución tecnológica de Linux, ya que componentes como systemd, Wayland y PipeWire que se estrenaron ahí.

Por otro lado está el apostar en lo máximo posible por software de código abierto y que esté libre de patentes que son usadas con fines ofensivos, así que, más allá del soporte de hardware, el usuario no se encontrará por defecto con ningún componente privativo o sujeto a patentes ofensivas. Aquí es donde entra RPM Fusion, el repositorio radicado en Francia que se centra en proporcionar soporte de multimedia (códecs, drivers y aplicaciones), Steam y el controlador de NVIDIA para Fedora, RHEL y CentOS.

Para los curiosos, lo único privativo que hay en los repositorios oficiales de Fedora son los microcódigos para los procesadores, el firmware privativo aprobado oficialmente para el kernel Linux y el firmware para las Wi-Fi de Intel.

Otro aspecto que se puede destacar de Fedora es la estrecha relación que mantiene con GNOME, formando con Red Hat el que posiblemente sea el triángulo más conocido del código abierto. De hecho, Fedora ha jugado durante mucho tiempo el rol de facto de sistema operativo de referencia de GNOME, papel que al menos en términos oficiales ya está en manos de GNOME OS, pero en el fondo la existencia de este último no ha cambiado nada de la relación que había de antes.

Si hablamos de usuarios, la realidad es que Fedora es muy popular desde hace poco, más concretamente desde una versión 25 que fue un punto de inflexión en términos cualitativos y probablemente una reacción ante el Snap impulsado por Canonical, sobre todo porque Flatpak no tenía a ninguna distribución que lo tuviera por bandera.

En los últimos años se pueden destacar dos cosas de la trayectoria de Fedora: el acercamiento a KDE y la apuesta por la inmutabilidad. Lo primero queda plasmado en hechos como el patrocinio del Akademy y en la aprobación de la eliminación de la sesión de Xorg para la versión 40 de la distribución, mientras que de lo segundo está la apuesta por OSTree, un mecanismo de actualizaciones atómicas originario de Red Hat y que está implementado en Silverblue, Kinoite y la edición para IoT.

Y esta es nuestra entrada sobre el vigésimo aniversario de Fedora, obviamente con muchos episodios omitidos porque veinte años dan para mucho. Gusten o no la distribución y sobre todo la compañía que la patrocina, la situación tecnológica de Linux sería muy distinta sin su aportación.

¿Cuál es el impacto de emplear cifrado de disco en Linux? En Phoronix han publicado unas pruebas en las que han comparado el desempeño de Fedora Workstation 38 con y sin cifrado de disco y con unos resultados que respaldan su uso.

Para hacer la comparativa, en Phoronix han tomado un portátil Lenovo ThinkPad P14s de cuarta generación, el cual incluye un procesador Ryzen 7 PRO 7840U de AMD, 64GB de memoria RAM (de los cuales 4 están reservados como memoria de vídeo) y una unidad SSD Kioxia de la serie XG8 con 1TB de capacidad.

El sistema operativo fue Fedora Workstation 38 con el sistema de ficheros Btrfs (el usado por defecto), Linux 6.5.6, Mesa 23.1.8 y la sesión de Wayland funcionando. Para el cifrado de disco se ha empleado la opción “Cifrar mis datos” que proporciona el instalador Anaconda sobre un particionado automático. El uso del cifrado de disco conllevaba la desactivación de la compresión zstd en anteriores versiones de la distribución, pero eso ya no es así, por lo que la comparativa es más justa al ser las condiciones más iguales.

Si se activa el cifrado de disco en Fedora siguiendo el procedimiento mostrado, el usuario verá que el volumen de Btrfs que sostiene el sistema está cifrado con LUKS, pero no así las particiones de arranque, tanto la de EFI como el directorio /boot, que está en EXT4.

Aquí no vamos a recoger los resultados de todas las pruebas, sino solamente los más interesantes para así mostrar los aspectos generales y si merece la pena habilitar el cifrado de disco al menos en la distribución comunitaria patrocinada por Red Hat.

La primera prueba presentada ha sido realizada con Flexible IO Tester, y en ella se puede comprobar que el desempeño con lecturas aleatorias de 4K con cifrado de disco es un 83% al visto haciendo lo mismo sin cifrado de disco. Si tenemos en cuenta que se está usando un SSD por interfaz NVMe, en un uso real esta diferencia no debería ser muy apreciable.

Además del desempeño, otro aspecto que tiende a preocupar cuando se emplea cifrado de disco es el uso del procesador. Aquí, al menos con Flexible IO Tester, no hay una diferencia apreciable, así que en este sentido y dejando de lado los temas relacionados con la seguridad importa poco usar o no el cifrado de disco.

No podemos obviar las operaciones de escritura aleatoria de 4K, donde se puede ver que el cifrado de disco logra obtener un resultado ligeramente mejor.

Las lecturas secuenciales de bloques de 4KB muestran un resultado claramente a favor de la instalación de Fedora Workstation 38 sin cifrado de disco, pero la cosa se equilibra bastante al subir el tamaño de los bloques a 2MB.

Lo siguiente que han empleado en Phoronix para comparar el desempeño es SQLite 3.41.2. En este frente las diferencias no son notables, así que, de todas las pruebas realizas, dejaremos la que ha dejado mejor a la instalación que no ha empleado cifrado de disco.

Las siguientes pruebas siguen la tendencia de un rendimiento bastante parejo, con la instalación sin cifrado de disco mostrando un desempeño muy ligeramente superior, pero la diferencia es tan escasa que debería ser difícil de apreciar con la vista y un uso normal de la computadora.

Con FS-Mark 3.3 repetimos lo de poner la prueba que deja mejor a la instalación sin cifrado de disco.

La diferencia roza lo nulo compilando tanto Linux 6.1 como Mesa 21.

Aplicando diversos efectos en GIMP se continúa con la misma tendencia, por lo que dejaremos solo la prueba con la rotación, que es la que aparentemente ha mostrado la mayor diferencia.

Como vemos, a niveles generales el impacto de emplear cifrado de disco en Fedora Workstation 38 es reducido, así que su uso es bastante recomendable sobre todo en portátiles tienden a salir del hogar. De esta manera, en caso de robo, el ladrón lo tendrá bastante más difícil para acceder a los datos y quién sabe, si no tiene conocimientos de informática, llega a la conclusión de que el ordenador está roto y termina instalando Windows encima.

Fuente: Muy Linux.

 

 

Cinnamon era uno de los grandes escritorios de Linux que todavía no tenían ningún plan trazado para soportar Wayland, pero tras los tambores de descontinuación de Xorg que han empezado a sonar desde GNOME, Linux Mint ha anunciado que ha empezado a trabajar en el soporte del protocolo gráfico.

Uno de los grandes defectos que arrastra Wayland son las dificultades que implica su implementación y el trabajar con él, cosas que quedaron en evidencia cuando el núcleo duro de Wine se rindió en su momento para que luego el testigo fuera tomado por Collabora. Esto ya deja entrever que la sesión de Cinnamon sobre Wayland no estará disponible como característica en fase estable en el corto plazo.

Desde Linux Mint explican que, tras priorizar las herramientas de las imágenes ISO y el soporte de SecureBoot en la versión 21.3 de su distribución, están en condiciones de centrar esfuerzos en el soporte de Wayland para Cinnamon. Por otro lado, adelantan que la sesión de Xorg estará con casi toda probabilidad por defecto en la mencionada versión 21.3 y en la serie 22.

Los responsables esperan que con el lanzamiento de Cinnamon 6.0, que será implementado en Linux Mint 21.3, se incluya soporte experimental de Wayland, con una sesión que debería ser accesible desde el gestor gráfico de sesiones. En un principio la sesión de Wayland no será tan estable ni tendrá todas las funcionalidades proporcionadas por la de Xorg, pero estará ahí para aquellos que quieran contribuir y reportar errores.

A pesar de las carencias y las cosas que están rotas, la sesión de Cinnamon sobre Wayland podrá ser iniciada y tendría que ser capaz de ejecutar la mayoría de las aplicaciones, además de permitir manipular ventanas y lidiar con los espacios de trabajo. El pronóstico más optimista apunta a que el soporte de Wayland no estará completamente listo hasta el año 2026, cuando se lance la serie 23 de Linux Mint. Eso le da a los responsables algo más de dos años para identificar y solucionar problemas.

Linux Mint no da garantías de soportar Wayland en condiciones a través de Cinnamon en el futuro cercano, pero al menos ya está manos a la obra en el soporte del protocolo. Por un lado, el hecho de que el compositor de Cinnamon, Muffin, sea una bifurcación de Mutter puede allanar algunos aspectos, pero por otro está que Wayland es de por sí un hueso duro de roer.

Fuente : Muy Linux.

Linus Torvalds ha anunciado la publicación en fase estable de Linux 6.6, la última versión del kernel de código abierto. Como suele ser habitual, hay una cantidad destacable de novedades que abarcan diversos frentes.

Lo primero que sobresale de Linux 6.6 es el nuevo planificador de tareas, EEVDF (Earliest Eligible Virtual Deadline First), que viene a sustituir a un CFS que fue fusionado en Linux 2.6.23 y cuya función es muy importante para lograr un buen rendimiento y buenas latencias, por lo que uno ya puede imaginarse los apartados en los que pretende mejorar.

Los aspectos más básicos del algoritmo EEVDF es que está diseñado para garantizar que los procesos que no reciben la atención que deberían sean seleccionados la próxima vez, mientras que los procesos que han recibido más atención de la que merecían son “castigados”. La consecuencia de este enfoque es, al menos sobre el papel, mejorar la latencia de las tareas que CFS se dejaba atrás y minimizar las otras tareas que se programan en exceso de forma rutinaria.

La segunda novedad destacada de Linux 6.6 es el soporte de la característica de hardware de pila oculta de Intel, que ha llegado tras años de discusiones. La pila oculta funciona manteniendo una pila secundaria (sombra) que no puede ser modificada directamente. Al administrar la pila, el procesador envía la dirección de retorno tanto a la pila normal como a la oculta con permiso especial.

El procesador extrae la copia instantánea de la copia oculta y la compara con la normal, y en caso de diferir, genera un fallo de protección de control que puede evitar los ataques de programación orientada al retorno (ROP) que intentan modificar la pila. Funciona en el espacio de usuario y de forma nativa solo en kernels de 64-bit, mientras que el soporte para 32-bit solo a través de emulación de IA32.

La entrada-salida directa asíncrona usando io_uring ha visto su rendimiento/latencia mejorado hasta en un 37%. Por otro lado, el sistema de ficheros Xfs ha incluido las primeras piezas para la infraestructura que le permitirá aplicar la comprobación de disco (fsck) en línea y poder así repararse solo sin tener que desmontar.

Continuando con los sistemas de ficheros más populares, Btrfs es capaz ahora de mantener el propietario y la fecha originales del subvolumen en la creación de un subvolumen auxiliar, cuando antes se establecían como valores predeterminados la fecha de creación del subvolumen auxiliar y root como propietario.

Otras cosas importantes de Btrfs en Linux 6.6 son el establecimiento de la función de verificación de la integridad como obsoleta y la restauración del rendimiento de la limpieza tras la reescritura llevada a cabo en Linux 6.4.

Obviamente, no vamos a olvidarnos de EXT4, el gran dominador del espectro Deb, que en este lanzamiento ha introducido comprobación y actualización periódica del superbloque y se ha acelerado la escritura de anexos en la asignación retratada (delalloc).

Los responsables de Kubernetes, el conocido orquestador de contenedores que ha sido el principal cimiento de la revolución de Linux en la nube, han tomado la decisión de adoptar SUSE Open Build Service (OBS) para generar y publicar sus paquetes en su nuevo repositorio oficial: pkgs.k8s.io. Este movimiento es de manera implícita un reconocimiento a los esfuerzos y el enfoque impulsados desde hace tiempo por parte del espectro del camaleón.

Desde el blog oficial de SUSE comentan que “este es un paso importante para Kubernetes en su objetivo de confiar en una infraestructura de propiedad comunitaria para todos los componentes críticos (que incluye repositorios de paquetes), pero también en la automatización y simplificación en la generación de múltiples paquetes para múltiples ramas de su pila de software, manteniendo al mismo tiempo la confianza a lo largo de la cadena”.

Desde la corporación del camaleón han aprovechado para recordar qué es OBS (no confundir con OBS Studio, el software de grabación de vídeo), el cual consiste básicamente en una herramienta que automatiza la generación y la distribución de una amplia gama de componentes de software que abarca paquetes, imágenes de disco y contenedores para diversas distribuciones, entre ellas SUSE Linux Enterprise Server, openSUSE, Red Hat Enterprise Linux, Ubuntu y Debian. Además, proporciona soporte para múltiples arquitecturas de procesador: x86, ARM64, PPC64LE, IBM Z, etc.

Además de un amplio soporte para distribuciones y arquitecturas de procesador, la adopción de Open Build Service se apoya en otras características como el uso generalizado de mecanismos de firma, la generación de una lista de materiales de software (SBOM) completamente transitiva y su capacidad de compilación segura respaldada. Es posible implementarlo localmente, en la nube o usarlo directamente a través de la instancia build.opensuse.org disponible gratuitamente para todos los proyectos de código abierto.

SUSE explica que las razones de Kubernetes para adoptar OBS se basan principalmente en la automatización de la generación de los paquetes para múltiples distribuciones de Linux y para una amplia gama de arquitecturas de procesador, todo ello manteniendo la cadena de confianza a través de los mecanismos de firma. La empresa del camaleón ha proporcionado a Kubernetes el uso gratuito de su plataforma build.opensuse.org y soporte para la implementación de sus proyectos.

SUSE ha reafirmado que creen que el código abierto reside en la libertad para elegir, así que tiene entre sus objetivos simplificar el soporte para la heterogeneidad que conlleva dicha posición. Aquí Open Build Service juega un papel importante al proporcionar a Kubernetes y otros proyectos la capacidad de crear y empaquetar de forma automática productos para diversas distribuciones Linux y abarcando varias arquitecturas según sea necesario. Los procesos de generación y distribución de software se realizan de manera transparente y segura con el fin de ofrecer confianza.

Además de la elección de Open Build Service por parte de Kubernetes, SUSE está considerando otras formas en que OBS podría simplificar el trabajo del orquestador de contenedores y aumentar al mismo tiempo la confianza en los entornos digitales, así que puede que esto sea solo el principio de una relación entre Kubernetes y SUSE.

Fuente: Muy Linux.​_

Las restricciones aplicadas a la redistribución del código fuente de Red Hat Enterprise Linux (RHEL) han supuesto todo un terremoto entre los que fueron los clones de dicho sistema. Mientras que CIQ (Rocky Linux), Oracle y SUSE decidieron unir sus fuerzas en torno a OpenELA, AlmaLinux sigue una senda aparentemente independiente y más acorde a los límites puestos por Red Hat con la que va a intentar mantener la compatibilidad con la Interfaz Binaria de Aplicaciones (ABI).

Benny Vasquez, presidenta de AlmaLinux OS Foundation, ha explicado en la convención All Things Open sobre los pasos que la distribución está dando con el fin de seguir manteniendo la compatibilidad con RHEL sin emplear código directo de este. Es importante tener en cuenta que AlmaLinux, al contrario que CIQ, Oracle y SUSE, sigue manteniendo una postura más amigable con IBM y Red Hat, aunque veremos si la mantiene en un futuro viendo la dirección en la que se mueven el gigante azul y su subsidiaria.

A pesar de los obstáculos que Red Hat ha puesto, en AlmaLinux están decididos en seguir en el mercado de los clones de RHEL, pero sin serlo realmente debido a las circunstancias actuales: “Continuaremos apuntando a producir una distribución de Linux a largo plazo y de nivel empresarial que esté alineada y sea compatible a nivel de ABI con RHEL en respuesta a las necesidades de nuestra comunidad, en la medida de lo posible, de modo que el software que se ejecuta en RHEL funcione en AlmaLinux”.

La vía para conseguir la compatibilidad a nivel de ABI es bastante lógica y consiste en emplear el código fuente de CentOS Stream, el cual todavía está disponible de forma pública, es de total libre redistribución y es el empleado como base para RHEL. Esto quiere decir que AlmaLinux se basa ahora principalmente en CentOS Stream. Vasquez comentó sobre eso que, “de todos los paquetes, el 99% todavía se ve exactamente igual a RHEL”. De esa pequeña fracción que no lo hace, “alrededor del 24% de esos paquetes requieren parches manuales”.

La parte más complicada para AlmaLinux está siendo los parches del kernel, ya que no pueden tomar las actualizaciones para ese componente sin violar los acuerdos de licencia de Red Hat. Para cubrir ese frente, Vasquez dijo que extraen los parches de otras fuentes o que al menos se esperan a que Oracle los publique, lo que abre la puerta a implementarlos de manera más rápida que el sistema del que ahora es una bifurcación.

Lejos de ser una idea, Benny Vasquez explicó sobre la más rápida recepción de los parches de seguridad que “los exploits del microcódigo de AMD fueron parchados antes que en RHEL porque tardaron un poco más en salir. Llegamos, probamos y salimos aproximadamente una semana antes que ellos”.

Desde AlmaLinux se han tomado muy en serio lo de mantener la compatibilidad con RHEL, así que gestionarán todo caso de aplicación que funciona en el segundo pero no en el primero como si fuera un fallo: “Cualquier cambio importante entre RHEL y AlmaLinux, cualquier aplicación que deje de funcionar, es un error y debe corregirse”.

Además de la compatibilidad, AlmaLinux tiene un repositorio de software llamado Synergy que proporciona paquetes que no están disponibles ni en RHEL ni en EPEL, el Grupo de Interés Especial (SIG) vinculado a Fedora y que se encarga de crear, mantener y gestionar paquetes adicionales para Red Hat Enterprise Linux (RHEL) y otros sistemas basados en Enterprise Linux.

El 1% de diferencia que CentOS Stream representa frente a RHEL puede suponer todo un dolor de cabeza para todos aquellos que en el pasado fueron clones y ahora luchan por mantener la compatibilidad. AlmaLinux sigue apostando por una postura amable con IBM y Red Hat, pero veremos si las dos últimas no dan un nuevo bandazo si ven que los exclones empiezan a dar demasiados buenos resultados en términos de calidad y compatibilidad.

Disponible desde hace casi un año, Linux 6.1​_ es la última versión LTS del kernel hasta el momento en ver la luz; una cuyo periodo de soporte extendido, al igual que el resto de versiones LTS, estaba previsto que durase seis años. Pero todo cambió con el reciente anuncio en torno al mantenimiento de dichas versiones y, en lo que respecta a esta en concreto, lo ha vuelto a hacer… para mejor, eso sí.

Poniendo en orden la historia de Linux LTS, de las versiones con soporte extendido del kernel, comenzaron su andadura ofreciendo dos años de soporte, que más adelante pasaron a ser seis años. Sin embargo, todo ha cambiado de una semanas a esta parte. A finales del septiembre se anunció una drástica modificación en el periodo de soporte de las versiones LTS de Linux, que ahora recuperan los dos años de actualizaciones.

Estas versiones LTS de Linux son muy valoradas por muchas partes, ya que garantizan un periodo de mantenimiento durante el cual se recibirán parches de seguridad y correcciones limitadas, propiciando así la compatibilidad y estabilidad del componente a largo plazo en diferentes proyectos. Pese a ello, el mantenimiento, a cargo de desarrolladores habituales del kernel, no es baladí y ya se advirtió que de no contar con implicación empresarial podría suceder lo que ha terminado sucediendo.

Cabe mencionar otro dato relevante que también ha pesado para la reducción en el tiempo de soporte de Linux LTS, y es que a la falta de apoyos externos por los supuestos interesados en que estas versiones existan o en que el periodo sea tan extenso, se ha sumado el poco uso que se les da. Es decir, conforme pasa el tiempo cada vez cuentan con menos usuarios, lo que tiene su lógica puesto que no reciben nuevas características ni amplían su soporte de hardware.

Así las cosas, por un lado faltan manos para encargarse del mantenimiento de Linux LTS como corresponde, por el otro lo largo del recorrido hace que pierdan el interés… pero sigue habiendo partes que se poyan en ellas y, con esto en mente, se acaba de anunciar lo que parecer ser un impulso extraordinario para encontrar el equilibrio: las versiones SLTS de Linux, o lo que es lo mismo, las versiones «Super LTS (por Long Term Support).

Linux 6.1 será la primera versión SLTS del kernel y su soporte se extenderá por un mínimo de 10 años. O eso es lo que han adelantado en el comunicado oficial de CIP, padrinos de este programa. CIP es el acrónimo de Civil Infrastructure Platform y se trata de un proyecto de The Linux Foundation enfocado en «impulsar la colaboración e innovación del código abierto en torno al software industrial para productos utilizados en la automatización y la infraestructura civil».

Al final todo queda en casa y no solo por tratarse CIP de un proyecto bajo el ala de The Linux Foundation. «Los kernels de CIP se desarrollan y revisan con la misma meticulosa atención que los kernels LTS habituales», explica Yoshi Kobayashi, responsable del proyecto. «Nuestros desarrolladores participan activamente en la revisión y prueba de Linux LTS, contribuyendo a la calidad y seguridad general de la plataforma».

En resumen, nace la iniciativa Linux SLTS y la punta de lanza es Linux 6.1, cuyo soporte iniciar se iba a extender hasta 2028, tras el primer cambio hasta 2026, aunque debía ser 2024 y tras este segundo que recogemos ahora, hasta 2032 «como mínimo». Falta por ver qué versión le sucederá, aun cuando no parece que vaya a seguir la cadencia anual de Linux LTS, cuyo próximo candidato también desconocemos (¿quizás Linux 6.6? Lo sabremos en breve).

Fuente: Muy Linux.