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.

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.