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.