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.

La descontinuación de la rama estable de CentOS ha traído una interesante competencia entre los ahora llamados derivados o variantes de Enterprise Linux (EL). ¿Cuál de esas distribuciones es la más usada en estos momentos? Según datos expuestos por CIQ y procedentes de las últimas métricas de seguimiento realizadas por Extra Packages for Enterprise Linux (EPEL), Rocky Linux está superando a todas las demás variantes.

Para los que anden perdidos, EPEL es un Grupo de Interés Especial (SIG) vinculado a Fedora y que se encarga de crear, mantener y gestionar paquetes adicionales de alta calidad para Red Hat Enterprise Linux (RHEL) y otros sistemas basados en EL. Los paquetes proporcionados por EPEL están basados en los disponibles para Fedora y la intención es que no entren en conflicto ni reemplacen a los suministrados por los repositorios oficiales del sistema.

En el gráfico se puede ver a Rocky Linux en primer lugar, con unas 500.000 instancias, seguido de RHEL, con algo menos de 400.000. En tercer lugar está AlmaLinux con unas 300.000 instancias, que supera de manera inconsistente a CentOS Steam, mientras que Oracle Linux resulta la menos popular entre los usuarios de EPEL al no alcanzar las 100.000 instancias. En el gráfico que se puede ver bajo estas líneas, Rocky Linux ocupa el primer lugar.

¿Y qué suministra EPEL a través de sus repositorios? Entre los componentes más destacados están p7zip, phpMyAdmin, phpldapadmin, Pidgin y los escritorios MATE, Xfce y KDE Plasma, ya que en RHEL 8 se tomó la decisión de poner solo GNOME a disposición. EPEL no es solo un complemento para adaptar RHEL y los derivados de EL al escritorio, sino que también proporciona componentes que pueden ser de gran utilidad en un entorno de servidor, que es a fin de cuentas la principal área a la que van destinados estos sistemas.

El mayor empuje de Rocky Linux frente a otros derivados de EL no debería sorprender si vemos que ha sido recomendado por Google como el mejor sustituto para CentOS en Google Cloud y básicamente ha sabido moverse donde importa para posicionarse. En la actualidad la compañía que lo desarrolla, CIQ, intenta mantener la compatibilidad con RHEL y para ello cuenta con el apoyo de empresas como Oracle y SUSE, con las que ha creado OpenELA.

Fuente: Muy Linux.

La beta de LMDE 6 ‘Faye’ ha sido publicada para continuar con el desarrollo del próximo sistema de Linux Mint basado en Debian, cuyas iniciales significan Linux Mint Debian Edition. La intención con este sistema es ofrecer la misma experiencia de escritorio a la vez que se garantiza que el software es compatible más allá de Ubuntu, que día de hoy sigue siendo la base tecnológica principal.

LMDE 6 ‘Faye’ incluye, al menos por ahora, Cinnamon 5.8.4 como escritorio, Linux 6.1​_ como kernel y Mesa 22.3.6 como pila que suministra los controladores del espacio de usuario (OpenGL, Vulkan y OpenCL). Para la gestión de la paquetería tradicional está APT 2.6.1 junto a Synaptic 0.91.3, mientras que como soporte de paquetería universal está Flatpak 1.14 de manera preinstalada.

Linux Mint se esfuerza para que la experiencia ofrecida a través de las dos bases tecnológicas que emplea (Ubuntu y Debian) sea consistente, por lo que el usuario no debería llevarse un impacto importante a la hora de usar LMDE. El hecho de que Ubuntu sea una derivada de Debian es otro factor que reduce el cambio que supone cambiar de una a otra.

Si uno va cruzando datos, descubre fácilmente que LMDE 6 ‘Faye’ está basado en Debian 12 ‘Bookworm’, la última versión estable de la archiconocida distribución comunitaria. Aunque sigue manteniendo la política de servir software estanco en su rama estable, no es menos cierto que Debian ha sido capaz de introducir software más reciente en cada lanzamiento, así que los usuarios pueden ver que, al menos de momento, ‘Bookworm’ no tiene muchas cosas que se puedan considerar como viejas (dentro de un año lo serán).

Otro punto que juega a favor de Debian Stable es Flatpak, que permite obtener versiones recientes de las aplicaciones sin comprometer la base estable y estanca que ofrece, ya q​_ue estas funcionan separadas del sistema operativo. La inmadurez de Flatpak hace que todavía arrastre ciertos problemas de integración, pero su uso es una mejor solución que mezclar repositorios de distintas ramas o introducir PPA de Ubuntu, dos vías que pueden terminar por romper el sistema.

Volviendo a LMDE 6 ‘Faye’, si uno quiere iniciar el instalador en modo experto debe introducir el siguiente comando:

sudo live-installer-expert-mode

Por otro lado, si está experimentando problemas con las aplicaciones de KDE, posiblemente sea por la ausencia de los siguientes paquetes:

sudo apt install kdelibs-bin kdelibs5-data kdelibs5-plugins

Otro punto que juega a favor de Debian Stable es Flatpak, que permite obtener versiones recientes de las aplicaciones sin comprometer la base estable y estanca que ofrece, ya que estas funcionan separadas del sistema operativo. La inmadurez de Flatpak hace que todavía arrastre ciertos problemas de integración, pero su uso es una mejor solución que mezclar repositorios de distintas ramas o introducir PPA de Ubuntu, dos vías que pueden terminar por romper el sistema.​_

Volviendo a LMDE 6 ‘Faye’, si uno quiere iniciar el instalador en modo experto debe introducir el siguiente comando:

sudo live-installer-expert-mode

Por otro lado, si está experimentando problemas con las aplicaciones de KDE, posiblemente sea por la ausencia de los siguientes paquetes:

sudo apt install kdelibs-bin kdelibs5-data kdelibs5-plugins

Otro punto que juega a favor de Debian Stable es Flatpak, que permite obtener versiones recientes de las aplicaciones sin comprometer la base estable y estanca que ofrece, ya que estas funcionan separadas del sistema operativo. La inmadurez de Flatpak hace que todavía arrastre ciertos problemas de integración, pero su uso es una mejor solución que mezclar repositorios de distintas ramas o introducir PPA de Ubuntu, dos vías que pueden terminar por romper el sistema.​_​_

Volviendo a LMDE 6 ‘Faye’, si uno quiere iniciar el instalador en modo experto debe introducir el siguiente comando:

sudo live-installer-expert-mode

Por otro lado, si está experimentando problemas con las aplicaciones de KDE, posiblemente sea por la ausencia de los siguientes paquetes:

sudo apt install kdelibs-bin kdelibs5-data kdelibs5-plugins

Fuente: Muy Linux.

¡Ay, Ubuntu y la gestión de software! Parece mentira que el «Linux para seres humanos» lleve tanto tiempo haciéndolo tan mal en una cuestión como esta, elemental donde las haya, pero tal vez y solo tal vez, la nueva tienda de aplicaciones de la distribución sea parte de la solución, ahora que acaba de posicionarse como la opción por defecto en Ubuntu 23.10.

En efecto, la posibilidad de la que nos hacíamos eco el mes pasado va cristalizando y, a falta de saber si se mantiene o no la decisión, algo que con Canonical nunca se tiene por seguro, ya se puede probar el invento sin mayores complicaciones. Es decir, ya no es necesario instalar y desinstalar nada, porque como acabamos de señalar, el nuevo Centro de aplicaciones es desde la última actualización del sistema, la opción predeterminada.

Centro de aplicaciones (App Center en inglés), así se llama la nueva tienda de aplicaciones, con la que Canonical intentará hacernos olvidar ese desastre llamado Snap Store, un fork de GNOME Software con todo lo malo de este y un poco más made in Ubuntu. O lo que es lo mismo, una tienda de aplicaciones lenta, pesada, propensa a los fallos y, para rematar, con soporte prioritario para los paquetes Snap, relegando los Deb, aunque se mantenía el soporte, instalación de paquetes externos incluida.

¿Qué aporta el nuevo Centro de aplicaciones? Se trata, después del nuevo instalador de sistema de la distribución, del segundo componente desarrollado en Flutter, tecnología por la que Canonical ha apostado para sus propias aplicaciones de escritorio. En consecuencia, tiene muchas similitudes con lo ya visto: un muy buen aspecto, así como una perfecta integración visual con GNOME (al menos, con el GNOME de Ubuntu) y, más importante, un consumo y rendimiento muy por encima de lo que había.

Fuente: Muy Linux.

Dos años y medio después del lanzamiento de su anterior versión mayor llega Mageia 9, una nueva iteración de esta heredera espiritual de la clásica Mandriva cuya relevancia, al igual que ocurre con OpenMandriva, otra que tal, nunca se ha acercado siquiera a la que tuvo en su día la distribución francobrasileña. Dicho lo cual, ahí sigue, fiel a su idiosincrasia comunitaria y a su propuesta inicial.

Dos años y medio, sobra decirlo, dan para mucho y más en materia tecnológica, por lo que el lanzamiento que nos ocupa llega repleto de novedades… para los usuarios de esta distribución, claro está. Y es que el salto de Mageia 8 a Mageia 9 se da sobre un cúmulo de actualizaciones importante, así como algunos retoques en el material propio del proyecto, léase las herramientas de administración que proporciona.

Así, Mageia 9 incluye mejoras, entre otros, en elementos tales como el instalador del sistema o el centro de control -herederos ambos de Mandriva, y no precisamente en lo espiritual- o el asistente de bienvenida, que ha sido reescrito de cero. Sin embargo, salvo detalles nada cambia apenas, los usuarios habituales de la distribución lo encontrarás todo en su sitio y con el mismo aspecto de siempre.

Las actualizaciones que recibe esta versión son lo más destacado, del kernel Linux 6.4(.9) a systemd 253(.7) o Mesa 23.1(.5). Mageia 9 ofrece asimismo PulseAudio y PipeWire instalados por defecto, aunque es el primero el elegido para gestionar el audio; así como se incluye URPMI y DNF para la gestión de paquetes, pero es el primero el utilizado de manera predeterminada.

Las novedades de Mageia 9 continúan con la oferta de escritorios de la distribución, cuya cara visible es la de KDE Plasma 5.27(.5), acompañado por KDE Frameworks 5.105 y KDE Gear 23.04, aunque la variedad está garantizada con GNOME 44(.2), Xfce 4.18, LXQt 1.3, Cinnamon 5.6, MATE 1.26 e incluso Enlightenment, LXDE o IceWM. Cada cual, eso sí, se instala con un medio diferente.

Es decir, para instalar de cero se pueden usar la instalación clásica o los medios en vivo y de estos últimos solo hay imágenes para los escritorios Plasma, GNOME y Xfce; el resto se realiza a través de la imagen completa, disponible para 32 y 64 bits. Esta última, además, es la necesaria para realizar la actualización de la versión previa a la actual.

Amplía la información sobre Mageia 9 en las notas de lanzamiento y descarga la distribución en la página oficial.

Fuente: Muy Linux.

Rocky Linux acaba de publicar una declaración en la que recalca su intención de mantenerse como “una alternativa 1 a 1 totalmente compatible con Red Hat Enterprise Linux (RHEL)”. Tomando lo escrito literalmente, se puede concluir que pretende seguir siendo clon a nivel binario, pero puede que la cosa no llegue a tanto a la hora de la verdad.

La modificación de las condiciones bajo las cuales se puede redistribuir el código fuente de RHEL, sobre todo el GPL y variantes de la licencia, ha desatado toda una tormenta en el mundo de Linux. Además de fuertes críticas por parte de la comunidad, la subsidiaria de IBM tiene que hacer frente a rivales como SUSE y Oracle, que junto a CIQ han decidido crear OpenELA, una nueva “asociación comercial colaborativa para fomentar el desarrollo de distribuciones compatibles con RHEL que proporcionen el código fuente abierto y gratuito de Enterprise Linux (EL)”.

Rocky Linux no ha dudado en mostrar músculo a través de OpenELA, de la cual los responsables de la distribución dicen que apoya su “misión al brindar garantía adicional de que la base de código abierto para Rocky Linux siempre estará disponible a través de una colaboración neutral con el proveedor e impulsada por la comunidad”. Aquí nos encontramos, básicamente, con una repetición del principio sobre el que se cimenta la existencia de OpenELA.

En resumidas cuentas, Rocky Linux mantiene su intención de ser el perfecto reemplazo para una rama estable de CentOS que ha dejado de existir, aunque la versión 7 seguirá estando soportada, al menos por ahora, hasta el 30 de junio de 2024. Esto contrasta con la decisión de AlmaLinux, la otra distribución con aspiraciones clónicas, que ha decidido cambiar su enfoque para limitarse a ofrecer compatibilidad a nivel de ABI.

Sin embargo, y como han indicado desde Linuxiac, la compatibilidad 1 a 1 (1:1) no tiene por qué significar que la cosa vaya fallo por fallo (bug to bug), sino que más bien apunta a referirse a una compatibilidad plena de una distribución con la otra a nivel de software y paquetes. Esto puede deberse a que Red Hat ha restringido el acceso público al código fuente de RHEL a los repositorios de CentOS Stream.

La situación parece ser un tanto caótica en estos momentos, así que habrá que esperar un tiempo para ver si todo se asienta y qué resultados terminan dando las dos estrategias en liza: la de AlmaLinux y su compatibilidad solo a nivel de ABI y la de OpenELA con su enfoque al menos más cercano a la compatibilidad 1 a 1.

Fuente : Muy Linux.