Red Hat ha anunciado la disponibilidad general de Red Hat Enterprise (RHEL) Linux 9.5, la segunda y última versión del sistema que verá la luz esta año y la quinta actualización de la rama actual, la cual acumula ya un par de años y medio de andadura. En retrospectiva, este lanzamiento se aúpa todo lo que vino antes: RHEL 9.0, RHEL 9.1, RHEL 9.2, RHEL 9.3, RHEL 9.4…

Y así llegamos a RHEL 9.5, aunque como sucede con todas esas notas, la presente solo recoge lo más destacado de un lanzamiento enorme, a pesar de que en su mayor parte se trata de actualizaciones, al menos en lo que respecta a la base del sistema. Con excepciones, si se puede decir así, y es que RHEL 9.5 mantiene componentes como el kernel Linux 5.14 (o en en el caso del escritorio, systemd 239 y GNOME 40, pero con Wyaldn por defecto, ojo) sin apenas cambios.

Es decir, prácticamente todo RHEL 9.5 está actualizado, pero en lo que podríamos denominar como modo mantenimiento. Hay multitud de cambios en los componentes base y la cadena de software del sistema. En el anuncio de lanzamiento oficial, no obstante, se enfocan en, valga la redundancia, el foco de interés con el que se ha ido desarrollando la distribución desde su llegada: la automatización y la integración de herramientas avanzadas para entornos híbridos y el multicloud, aunque no sea lo único.

Por ejemplo, esta versión introduce mejoras clave en Red Hat Insights, la plataforma de análisis predictivo y gestión proactiva, que ahora permite un monitoreo más exhaustivo y optimización en tiempo real. También mejora la integración con con Ansible para automatizar flujos de trabajo complejos, reforzando el enfoque en la infraestructura como código (IaC) y la automatización de tareas de mantenimiento.

Además, RHEL 9.5 amplía su capacidad para entornos Edge, permitiendo configuraciones más precisas en la creación de imágenes y gestión de sistemas remotos. La nueva versión facilita el despliegue de contenedores, con mejoras en compatibilidad y seguridad en Red Hat Universal Base Image (UBI) para aplicaciones modernas. En cuanto a la seguridad, se introducen nuevas herramientas de autenticación y cifrado, así como un soporte mejorado para criptografía avanzada, incluyendo soporte ampliado para FIPS 140-3 y mejoras en SELinux y OpenSSL.

«Nos comprometemos a hacer de Red Hat Enterprise Linux la plataforma zero trust más segura del mercado, para que las empresas puedan enfrentar cada desafío con una base sólida y segura en los niveles más fundamentales del sistema. Este compromiso permite a las organizaciones adoptar la próxima ola de innovaciones tecnológicas con confianza», explica Gunnar Hellekson, vicepresidente y director general de Red Hat Enterprise Linux.

Por supuesto, todo lo dicho no es más que una mera avanzadilla de lo que esta versión trae consigo. Para más datos, las notas de lanzamiento de Red Hat Enterprise Linux 9.5.

Fuente: Muy Linux.

 

 

 

Recogíamos el viernes el lanzamiento de Linux Lite 7.2, la nueva versión de una distribución que, como su propio nombre indica, tiene pretensiones de ligera… ¿en comparación con qué? Con el Linux de escritorio corriente, se entiende. Pero ¿cuáles son los requisitos recomendados para disfrutar de una experiencia decente con Linux en PC? Vamos a verlo.

El asunto es un poco peliagudo porque pese a que es cierto que Linux permite «resucitar» cacharros que deberían estar viviendo una segunda vida como materiales reciclados, la experiencia de uso, que al fin y al cabo es casi tan importante como que algo funcione, puede no compensar en absoluto el esfuerzo. Pongamos algunos ejemplos de ello porque, en efecto, depende todo también del caso de uso al que dediquemos el equipo en cuestión.

Por ejemplo, Linux Lite no es tan Lite ahora como lo fue en su día, aunque lo cierto es que nunca fue una distribución ligera de referencia, o no más que otras que juegan en su misma liga, léase otras distribuciones con Xfce como entorno de escritorio, sin importar los requisitos que comuniquen. De hecho, redactando la noticia me surgió la duda de cuáles eran los requisitos de Linux Lite… y son estos:

Requisitos mínimos:

• • CPU 1Ghz
  • 2GB RAM
  • 20GB HDD/SD
  • Pantalla VGA 1024×768
  • Lector DVD o puerto USB (para la instalación)

Requisitos recomendados:

• • CPU 2GHz
  • 4GB RAM
  • 40GB HDD/SSD+
  • Pantalla VGA, DVI, HDMI 1366×768
  • Lector DVD o puerto USB (para la instalación)

Cabe apuntar que Linux Lite ya no da soporte a equipos de 32-bit, si bien este debería ser un tema superado. Lo de seguir usando sistemas de 32-bit, salvo dependencia irrenunciable, no es un problema de obsolescencia programada de ningún tipo, sino de obsolescencia a secas. Todo tiene su momento y el de los 32-bit pasó hace mucho, hablando siempre de x86 en PC.

Si los requisitos de Linux Lite pueden sorprender, ni se acercan a los de propuestas como Tiny Core Linux, distribución que con una CPU i486DX y 128 MB de RAM ya tira… Y hay ejemplos más extremos. Pero son curiosidades o, si acaso, soluciones-parche para casos de uso muy específicos y nunca con visos de largo plazo.

Entonces… ¿cuáles son los recomendados para una experiencia decente con Linux en PC? Decente, que no óptima. Los recomendados de Linux se acercan bastante a lo que yo recomendaría , con un matiz importante: los 4 GB de RAM se han quedado muy atrás; 8 GB de RAM, repito, para una experiencia decente… Y es que el software actual no está optimizado para escenarios de hace dos décadas.

Solo con abrir el navegador web (Linux Lite lleva Chrome por defecto, no encuentro la lógica) se te va al traste toda la eficiencia que pueda aportar un gestor de ventanas ligero, y aunque hay alternativas incluso para esto, cuando hablamos de una experiencia de uso decente no hay atajos ni trucos. Y, por supuesto, no se trata ahora de comparar Linux con otros sistemas.

Un apunte en este sentido: que muchos equipos no puedan instalar Windows 11 debido a sus requisitos, no significa que estén obsoletos, ni mucho menos. La prueba más evidente de ello es que funcionan bien con Windows 10. ¿Funcionarían mejor con Linux? Lo más probable es que sí, aun cuando tendrían que afrontar los mismos cuellos de botella, el principal de los cuales es, insisto, el navegador web. Que lo mismo no necesitas un navegador web plenamente operativo…, pero esa es otra historia.

¿Realmente Linux es capaz de revivir una máquina de más de 10 años? No lo dudes. La experiencia que comparto en ese artículo se mantiene y depende de aspectos críticos, determinantes para que todo funcione como es de esperar y la sensación de arrastre no se lleve la paciencia de uno por delante. Claro que con 1Ghz y 1GB de RAM instalas Linux… Pero vas a sufrirlo y mucho. ¿Y con 2Ghz y 4GB de RAM? Irás más suelto, desde luego.

Sin embargo, si lo que quieres es tener una experiencia de uso decente con Linux en PC, los requisitos recomendados son CPU a 3GHz y 8GB de RAM. Vas a ir justo, pero vas a poder funcionar. Sobra añadir que la elección de distribución y entorno de escritorio también importa, así como que se puede optimizar el sistema para sacar el máximo provecho de los recursos.

Con respecto a la actualización de componentes, siempre que la base acompañe un mínimo, los que más se notan al actualizar son, por este orden, el almacenamiento y la memoria: pasar de HDD a SSD supone una mejora sustancial y la ampliación de RAM te ayudará en las tareas del día, por lo que si no tienes más remedio que aguantar con lo que tienes, pero te puedes permitir renovar algún componente de vez en cuando, estos son los más relevantes… y económicos, ya que estamos.

Imágenes generadas con IA

Entonces… ¿cuáles son los recomendados para una experiencia decente con Linux en PC? Decente, que no óptima. Los recomendados de Linux se acercan bastante a lo que yo recomendaría , con un matiz importante: los 4 GB de RAM se han quedado muy atrás; 8 GB de RAM, repito, para una experiencia decente… Y es que el software actual no está optimizado para escenarios de hace dos décadas.

Solo con abrir el navegador web (Linux Lite lleva Chrome por defecto, no encuentro la lógica) se te va al traste toda la eficiencia que pueda aportar un gestor de ventanas ligero, y aunque hay alternativas incluso para esto, cuando hablamos de una experiencia de uso decente no hay atajos ni trucos. Y, por supuesto, no se trata ahora de comparar Linux con otros sistemas.

Un apunte en este sentido: que muchos equipos no puedan instalar Windows 11 debido a sus requisitos, no significa que estén obsoletos, ni mucho menos. La prueba más evidente de ello es que funcionan bien con Windows 10. ¿Funcionarían mejor con Linux? Lo más probable es que sí, aun cuando tendrían que afrontar los mismos cuellos de botella, el principal de los cuales es, insisto, el navegador web. Que lo mismo no necesitas un navegador web plenamente operativo…, pero esa es otra historia.

¿Realmente Linux es capaz de revivir una máquina de más de 10 años? No lo dudes. La experiencia que comparto en ese artículo se mantiene y depende de aspectos críticos, determinantes para que todo funcione como es de esperar y la sensación de arrastre no se lleve la paciencia de uno por delante. Claro que con 1Ghz y 1GB de RAM instalas Linux… Pero vas a sufrirlo y mucho. ¿Y con 2Ghz y 4GB de RAM? Irás más suelto, desde luego.

Sin embargo, si lo que quieres es tener una experiencia de uso decente con Linux en PC, los requisitos recomendados son CPU a 3GHz y 8GB de RAM. Vas a ir justo, pero vas a poder funcionar. Sobra añadir que la elección de distribución y entorno de escritorio también importa, así como que se puede optimizar el sistema para sacar el máximo provecho de los recursos.

Con respecto a la actualización de componentes, siempre que la base acompañe un mínimo, los que más se notan al actualizar son, por este orden, el almacenamiento y la memoria: pasar de HDD a SSD supone una mejora sustancial y la ampliación de RAM te ayudará en las tareas del día, por lo que si no tienes más remedio que aguantar con lo que tienes, pero te puedes permitir renovar algún componente de vez en cuando, estos son los más relevantes… y económicos, ya que estamos.

Imágenes generadas con IA

Entonces… ¿cuáles son los recomendados para una experiencia decente con Linux en PC? Decente, que no óptima. Los recomendados de Linux se acercan bastante a lo que yo recomendaría , con un matiz importante: los 4 GB de RAM se han quedado muy atrás; 8 GB de RAM, repito, para una experiencia decente… Y es que el software actual no está optimizado para escenarios de hace dos décadas.

Solo con abrir el navegador web (Linux Lite lleva Chrome por defecto, no encuentro la lógica) se te va al traste toda la eficiencia que pueda aportar un gestor de ventanas ligero, y aunque hay alternativas incluso para esto, cuando hablamos de una experiencia de uso decente no hay atajos ni trucos. Y, por supuesto, no se trata ahora de comparar Linux con otros sistemas.

Un apunte en este sentido: que muchos equipos no puedan instalar Windows 11 debido a sus requisitos, no significa que estén obsoletos, ni mucho menos. La prueba más evidente de ello es que funcionan bien con Windows 10. ¿Funcionarían mejor con Linux? Lo más probable es que sí, aun cuando tendrían que afrontar los mismos cuellos de botella, el principal de los cuales es, insisto, el navegador web. Que lo mismo no necesitas un navegador web plenamente operativo…, pero esa es otra historia.

¿Realmente Linux es capaz de revivir una máquina de más de 10 años? No lo dudes. La experiencia que comparto en ese artículo se mantiene y depende de aspectos críticos, determinantes para que todo funcione como es de esperar y la sensación de arrastre no se lleve la paciencia de uno por delante. Claro que con 1Ghz y 1GB de RAM instalas Linux… Pero vas a sufrirlo y mucho. ¿Y con 2Ghz y 4GB de RAM? Irás más suelto, desde luego.

Sin embargo, si lo que quieres es tener una experiencia de uso decente con Linux en PC, los requisitos recomendados son CPU a 3GHz y 8GB de RAM. Vas a ir justo, pero vas a poder funcionar. Sobra añadir que la elección de distribución y entorno de escritorio también importa, así como que se puede optimizar el sistema para sacar el máximo provecho de los recursos.

Con respecto a la actualización de componentes, siempre que la base acompañe un mínimo, los que más se notan al actualizar son, por este orden, el almacenamiento y la memoria: pasar de HDD a SSD supone una mejora sustancial y la ampliación de RAM te ayudará en las tareas del día, por lo que si no tienes más remedio que aguantar con lo que tienes, pero te puedes permitir renovar algún componente de vez en cuando, estos son los más relevantes… y económicos, ya que estamos.

Imágenes generadas con IA

Entonces… ¿cuáles son los recomendados para una experiencia decente con Linux en PC? Decente, que no óptima. Los recomendados de Linux se acercan bastante a lo que yo recomendaría , con un matiz importante: los 4 GB de RAM se han quedado muy atrás; 8 GB de RAM, repito, para una experiencia decente… Y es que el software actual no está optimizado para escenarios de hace dos décadas.

Solo con abrir el navegador web (Linux Lite lleva Chrome por defecto, no encuentro la lógica) se te va al traste toda la eficiencia que pueda aportar un gestor de ventanas ligero, y aunque hay alternativas incluso para esto, cuando hablamos de una experiencia de uso decente no hay atajos ni trucos. Y, por supuesto, no se trata ahora de comparar Linux con otros sistemas.

Un apunte en este sentido: que muchos equipos no puedan instalar Windows 11 debido a sus requisitos, no significa que estén obsoletos, ni mucho menos. La prueba más evidente de ello es que funcionan bien con Windows 10. ¿Funcionarían mejor con Linux? Lo más probable es que sí, aun cuando tendrían que afrontar los mismos cuellos de botella, el principal de los cuales es, insisto, el navegador web. Que lo mismo no necesitas un navegador web plenamente operativo…, pero esa es otra historia.

¿Realmente Linux es capaz de revivir una máquina de más de 10 años? No lo dudes. La experiencia que comparto en ese artículo se mantiene y depende de aspectos críticos, determinantes para que todo funcione como es de esperar y la sensación de arrastre no se lleve la paciencia de uno por delante. Claro que con 1Ghz y 1GB de RAM instalas Linux… Pero vas a sufrirlo y mucho. ¿Y con 2Ghz y 4GB de RAM? Irás más suelto, desde luego.

Sin embargo, si lo que quieres es tener una experiencia de uso decente con Linux en PC, los requisitos recomendados son CPU a 3GHz y 8GB de RAM. Vas a ir justo, pero vas a poder funcionar. Sobra añadir que la elección de distribución y entorno de escritorio también importa, así como que se puede optimizar el sistema para sacar el máximo provecho de los recursos.

Con respecto a la actualización de componentes, siempre que la base acompañe un mínimo, los que más se notan al actualizar son, por este orden, el almacenamiento y la memoria: pasar de HDD a SSD supone una mejora sustancial y la ampliación de RAM te ayudará en las tareas del día, por lo que si no tienes más remedio que aguantar con lo que tienes, pero te puedes permitir renovar algún componente de vez en cuando, estos son los más relevantes… y económicos, ya que estamos.

Imágenes generadas con IA.

 

Fuente: Muy Linux.

 

Linux Lite 7.2 es la nueva versión de esta derivada de Ubuntu, o quizás de Xubuntu, habida cuenta de que utiliza el entorno de escritorio de Xfce, bien tuneado para que Linux Lite no arrastre contraprestaciones a nivel práctico o visual.

Basada en Ubuntu 24.04 LTS, Linux Lite 7.2 comparte todas las novedades de sistema con esta, incluyendo componentes como el kernel Linux 6.8, systemd 255 o Mesa 24, aunque facilita la instalación de otros más actuales, como el kernel Linux 6.11, disponible en los repositorios de la distribución.

Es decir, Linux Lite 7.2 se queda con la base de Ubuntu 24.04 LTS, pero toma también de la más reciente Ubuntu 24.10, que a su vez será la que nutra la próxima Ubuntu 24.04.2 LTS, cuyo lanzamiento no se espera hasta principios de año. La mejor prueba de ello está en las versiones de algunas de las aplicaciones por defecto del sistema, véase GIMP 2.10.36.

Cabe recordar a este respecto lo «especial» que es Linux Linux con el tema aplicaciones: su navegador predeterminado es Google Chrome, no incluye soporte de Snap o Flatpak preinstalado (aunque es muy sencillo conseguirlo)… Y luego está el actualizador del sistema, un desarrollo propio remozado en el framework Yad para esta versión y supuestamente más rápido, ligero y responsivo.

Lo que sí tiene Linux Lite, por curioso que parezca, es un asistente basado en inteligencia artificial propia, al que dedican un espacio destacado en las novedades de este lanzamiento. No se trata de un chatbot de propósito general, sino enfocado en ofrecer ayudar sobre la distribución, su uso y herramientas… y tiene una aplicación en línea a disposición de cualquiera.

Para más datos acerca de este lanzamiento, incluyendo instrucciones para la actualización desde la versión anterior y los enlaces de descarga de la nueva, el anuncio oficial.

Fuente: Muy Linux.

 

 

Valve sorprendió a propios y extraños al anunciar que SteamOS 3, el sistema operativo de la Steam Deck, se basaría en Arch Linux en lugar de Debian y que sería un sistema operativo inmutable. La compañía tenía motivos para el cambio de base, empezando con el fácil acceso a software reciente y además en un estado bastante vanilla.

Viendo la buena acogida que ha tenido la Steam Deck entre el público general, parece que a Valve le ha interesado profundizar su relación con la distribución madre de SteamOS 3, ya que Levente Polyak, actual líder de Arch Linux, ha anunciado una colaboración directa con la compañía. Viendo la trayectoria de la responsable de Steam en torno a Linux, un movimiento como este no debería sorprender.

Polyak ha explicado en el anuncio que “Valve está brindando su generoso apoyo para dos proyectos críticos que tendrán un gran impacto en nuestra distribución: una infraestructura de servicio de compilación y un enclave de firma seguro. Al respaldar el trabajo de manera independiente sobre estos temas, Valve nos permite trabajar en ellos sin estar limitados únicamente por el tiempo libre de nuestros voluntarios.”

“Esta oportunidad nos permite abordar algunos de los mayores desafíos pendientes que hemos estado enfrentando durante un tiempo. La colaboración acelerará el progreso que de otra manera nos llevaría mucho más tiempo lograr y, en última instancia, nos permitirá avanzar en algunos de los proyectos que teníamos planeados. Estamos increíblemente agradecidos a Valve por hacer esto posible y por su compromiso explícito de ayudar y apoyar a Arch Linux”.

Otro punto que ha destacado Polyak es que “estos proyectos seguirán nuestros flujos de trabajo habituales de desarrollo y de construcción de consensos”. Dicho de otra manera, que Arch Linux debería seguir funcionando igual que siempre, pero con los beneficios y aceleración que aportará la colaboración con Valve.

Si esta relación funciona de manera honesta, ambas partes se verían beneficiadas. Arch Linux podrá acelerar su desarrollo gracias a las aportaciones de Valve, mientras que esta última posiblemente obtenga unos paquetes con un mejor punto de partida para la creación de SteamOS. Según han recogido en GamingOnLinux, uno de los aspectos que podrían verse mejorados es la seguridad de los paquetes servidos a través de los repositorios.

Además de la colaboración con Arch Linux, Valve intenta en estos momentos acelerar el desarrollo de Wayland a través de dos vías: la inclusión de protocolos procedentes de proyectos de terceros y la introducción de una fase más en el desarrollo de protocolos para Wayland. Por ahora ambas vías siguen abiertas según sus respectivas peticiones de fusión y hasta podrían terminar siendo complementarias dependiendo de las decisiones que se terminen tomando.

 

Fuente: Muy Linux.

 

 

La cuota de Linux en PC se estabiliza por encima del 4%. En concreto, Linux cerró septiembre con un 4,48% de cuota de mercado, un 4,5 de facto según marca StatCounter, lo que se traduce en una constante digna de mención como es la que nos ocupa.

Esto no tiene nada que ver con vaivenes pasados más complicados de digerir. Son datos de StatCounter, que desde la desaparición de NetmarketShare (un medidor tradicionalmente más optimista para con Linux) ha quedado como referente para este tipo de métricas, aun cuando hay que tener en cuenta que no reflejan la realidad con rigor, porque no hay una manera certera de hacerlo.

Sea como fuere, son los datos de StatCounter los que generan los titulares y, por lo tanto, la asunción de cuotas de mercado que damos por ciertas, como que Windows domina el segmento del PC con más del 70% o que Chrome hace lo propio en el de los navegadores web con más del 65%. Son datos que tomamos por hecho, pese a no ser absolutos, porque no tenemos otros.

Ergo, desterremos de una vez del imaginario colectivo que Linux es el 1%, porque no lo es. Linux es el 4 y pico por ciento, tal y como ha venido demostrando poco a poco su crecimiento: entre la pasada década y esta se alcanzó el 2% y desde el último par de años el ascenso ha sido más rápido. Los hitos más destacados los tuvimos a principios del año pasado y el presente, cuando Linux superó el 3 y 4 por ciento de cuota de mercado respectivamente.

Lo positivo de la nueva marca es que está siendo consistente a lo largo de los meses: febrero 4,03%, marzo 4,05%, abril 3,88%, mayo 3,77%, junio 4,05%, julio 4,44%, agosto 4,55%… se han dado altos y bajos, pero manteniendo una constancia que, no lo olvidemos, tiene el el «sistema desconocido» que recogen las estadísticas de StatCounter con un porcentaje muy similar (lleva oscilando entre el 4 y el 6 desde hace más de un año) parte de lo que le correspondería, que no todo, ojo.

¿Y si a la cuota de Linux le sumáramos la de lo que también es Linux, como ChromeOS? Entonces hablaríamos del 6,75%. ¿Y si a eso le añadimos la cuota de Android, que a fin de cuentas también es Linux? Entonces… Estaríamos haciendo trampas. A nosotros mismos, usuarios y amantes del escritorio Linux que usamos por diferentes motivos. Resulta más interesante observar cómo varía la presencia de Linux en los mercados alrededor del mundo, por continentes, por países…

Por ejemplo, en África Linux tiene un 2,64%, en Asia un 6,39%, en Europa un 3,07%… En América del Norte un 3,93%, en América del Sur un 3,17% (no sé por qué separa al continente en dos partes)… Y ya por países, en España sigue anclado en el 3,16%, en México en el 2,37%, en Colombia en el 3,01%, en Argentina en el 3,2%… (por mencionar algunos de los países desde donde más nos leéis).

Ahora bien ¿queréis alucinar un poco? Porque hay países donde la cuota de Linux es muy superior a la media, mucho más de lo que cualquiera podría imaginar. Unos ejemplos de menos a más: en Finlandia llega al 4,95%, en Serbia al 5,02%, Yemen 5,21%, Laos 5,6%, Macao 5,65%, Seychelles 5,74%, Hong Kong 5,81%, Montenegro 6,27%, Venezuela 6,65%, Grecia 6,96%, Cuba 7,41%, Turquía 7,46%, Irak 7,89%, Singapur 8,37%, Panamá 9,57%, Sudán 11%, Groenlandia 11,72%, Noruega 17,03%, India 17,32%… Todo ello según datos de StatCounter, cabe repetir.

¿Seguirá fluctuando la cuota de mercado global de Linux? Es lo más probable, pero por lo que llevamos de 2023 y 2024, el crecimiento parece estable. Así que quedaos con el dato, para cuando se necesite: somos el 4%. Como mínimo.

 

Fuente: Muy Linux.

 

Si eres usuario de SUSE u openSUSE, ya la tienes en los repositorios y si no, la puedes descargar igualmente, si es que te interesa hacerte con una nueva fuente tipográfica de código abierto llamada… SUSE. La puedes usar en el sistema, en una página web… Donde quieras.

«Nos complace anunciar el lanzamiento del tipo de letra oficial SUSE, apropiadamente llamado “SUSE”. La familia de fuentes SUSE admite más de 200 idiomas de base latina», anunciaba Ivo Totev, Director de Innovación de SUSE, en el blog de la compañía. «Ahora lucimos más SUSE que nunca. La publicación de nuestra familia de fuentes oficial como código abierto es la opción obvia para SUSE, y eso es exactamente lo que hemos hecho».

SUSE es una tipografía sans serif diseñada por René Bieder, que incorpora un híbrido único entre características geométricas y monoespaciadas. Capta la esencia de SUSE, una empresa reconocida por sus soluciones de código abierto. Esta versátil familia de tipos de letra incluye los siguientes estilos: Thin, ExtraLight, Light, Regular, Medium, SemiBold, Bold y ExtraBold.

SUSE fue creada para reflejar el espíritu innovador y de código abierto de la empresa SUSE. Proporciona claridad y legibilidad, lo que lo hace ideal tanto para medios digitales como impresos. El diseño híbrido combina precisión geométrica con estabilidad monoespaciada, asegurando una estética moderna y eficiente.

SUSE se destaca por su diseño distintivo, perfecto para proyectos modernos, de código abierto y centrados en la tecnología. Su variedad de pesos permite flexibilidad en el diseño, desde titulares hasta el cuerpo del texto, lo que garantiza coherencia y armonía en diferentes casos de uso.

La tipografía de SUSE se publicó a finales de junio bajo la licencia SIL Open Font License 1.1, según se puede ver en GitHub , donde se dan todos los detalles técnicos acerca de la misma; aunque no ha sido hasta hace unos días cuando se hizo público el lanzamiento. Si te interesa probarla, además de en los repositorios de SUSE y openSUSE y en GitHub, está disponible en Google Fonts, para descargar o usarla en la web.

¿Será está la próxima fuente tipográfica predeterminada de SUSE y openSUSE? Todo parece indicar que sí, si bien de momento no ha sido implementada de tal forma. Sea como fuere, ahí tienes una opción más que se une a otras más conocidas y extendidas como Ubuntu (¡de Ubuntu¡) o Cantarell de GNOME.

Fuente: Muy Linux.

En los últimos tiempos han surgido iniciativas para hacer que los fallos de Linux sean más fáciles de leer. Si systemd 255 introdujo un pantallazo azul de la muerte cuyo uso es opcional, hace poco se ha propuesto para Linux 6.12 la muestra de un código QR cuando se produce un kernel panic.

Los códigos QR se han mostrado como muy eficaces para almacenar una gran cantidad de información en poco espacio, así que, procedente del repositorio DRM-Misc-Next, se ha propuesto su implementación en DRM Panic, que es el componente encargado de mostrar un mensaje cuando se produce un kernel panic a través de los drivers gráficos soportados.

Pero antes de continuar, hay que dejar claro que aquí DRM no hace referencia a la gestión de derechos digitales de plataformas como Netflix o SkyShowtime, sino a la gestión de renderización directa. Dicho con otras palabras, nos estamos refiriendo al subsistema del kernel Linux responsable de interactuar con las GPU modernas, el cual abarca los drivers AMDGPU, el viejo Radeon dirigido principalmente a viejas gráficas publicadas bajo la marca ATI, además de los drivers de Intel i915 y Xe, siendo el primero el actual y el segundo su sucesor para procesadores gráficos modernos. Obviamente hay muchos otros controladores, pero en el ecosistema x86 esos son los más populares y los que tienen mayor proyección.

La información arrojada por un kernel panic tiende a no ser muy amigable, así que un código QR puede ser una buena herramienta para almacenar más información y de manera que se pueda consultar en el futuro, con la posibilidad de obtenerla de forma que sea más comprensible para el usuario. La característica es opcional y está escrita en Rust, por lo que el soporte para dicho lenguaje debe estar habilitada en la compilación del kernel.

Profundizando un poco en la característica, tiene una opción llamada DRM_PANIC_SCREEN_QR_CODE que añade un generador de códigos QR y una pantalla de pánico con un código de QR. El código QR contendrá las últimas líneas de kmsg y otra información de depuración. Esto debería facilitar al usuario el reporte de un kernel panic con toda la información disponible. Otra opción, DRM_PANIC_SCREEN_QR_CODE_URL, establece la URL base para reportar un kernel panic y en caso de estar establecido en propio código QR contendrá la URL y el kmsg comprimidos con zlib como un parámetro de la URL. En caso de estar vacío, el código QR solo contendrá solamente el kmsg como texto sin comprimir.

Por ahora la intención es introducir el soporte para el código QR en Linux 6.12, pero todavía queda bastante para su lanzamiento (la versión 6.11 se encuentra en RC) y es posible que se demore. No se trata de una característica que vaya a revolucionar nada y muchos posiblemente la vean inútil, pero es probable que algunos usuarios vean aquí una vía para obtener una mejor información de una de las incidencias más desagradables que uno puede tener a la hora de usar Linux.

 

Fuente: Muy Linux.

 

A pesar de haber moderado su actitud, Linus Torvalds sigue sorprendiendo con sus declaraciones y reflexiones, que en no pocas ocasiones se desmarcan de los tópicos que muchos atribuyen a una persona de su perfil. Siguiendo esta tónica, el creador de Linux ha expuesto en la conferencia Open Source Summit China 2024 su punto de vista sobre la adopción de Rust en el kernel, su postura en torno a la inteligencia artificial y cómo se toma ciertas tecnologías.

Sobre la situación de Rust en Linux, parece que ha habido cierto cambio en la visión de Linus Torvalds. Si en el pasado sus declaraciones denotaban cierto escepticismo sobre cómo terminaría funcionando Rust a la hora de la verdad, en la última Open Source Summit celebrada en China ha dicho que “esperaba que las actualizaciones fueran más rápidas, pero parte del problema es que los antiguos desarrolladores del kernel están acostumbrados a C y no conocen Rust. No les entusiasma precisamente tener que aprender un lenguaje nuevo que en algunos aspectos es muy diferente. Así que ha habido cierta reacción contra Rust”.

El desconocimiento por parte de los desarrolladores y su resistencia a adoptar una tecnología más reciente no es el único motivo según ha explicado Torvalds, ya que “otra razón ha sido que la infraestructura de Rust en sí no ha sido súper estable”.

Continuando con tecnologías que están de moda, Linus Torvalds también ha expresado su postura en torno a la inteligencia artificial (IA). Si bien no comparte el exceso de entusiasmo que ha despertado, sí ve que las herramientas apoyadas en inteligencia artificial contribuirán a la revisión de código y a la detección de errores.

Otra cosa que el creador de Linux ha mencionado sobre la IA es que hecho que NVIDIA se involucre mucho más en kernel, hasta el extremo de decir que el gigante verde ha pasado “de estar en mi lista de empresas que no son buenas a mi lista de empresas que están haciendo un trabajo realmente bueno”. Aquí nos encontramos con una aparente rectificación de su icónico fuck you, que vino después de decir que NVIDIA era “la peor empresa con la que habían tratado” los responsables del kernel y que era “foco de contínuos problemas para Linux”.

Y por último nos encontramos con sectores como la computación en la nube y tecnologías como Kubernetes, que al parecer no son del interés de Torvalds, quien prefiere estar centrado en el kernel Linux. Obviamente, el ingeniero finés no niega la importancia de la nube y tecnologías como Kubernetes, pero que a la hora de la verdad no son su problema. Por otro lado, ha comentado que lo bueno del código abierto es que cada uno se especializa en lo que le interesa.

Lo que dice Linus Torvalds en los eventos suele ser tenido en cuenta no solo por el debate que puedan generar sus palabras, sino también porque a veces da pistas sobre posibles decisiones en torno al desarrollo de Linux. El ingeniero finés estuvo acompañado en la conferencia por Dirk Hohndel, quien es director de la oficina del programa de código abierto de Verizon y amigo del creador de Linux.

Fuente: Muy Linux.

 

El Equipo del Kernel de Canonical, CKT en sus siglas en inglés, ha anunciado una nueva política de selección de versiones de Linux con la que pretenden suministrar los lanzamientos más recientes del kernel a través de Ubuntu.

Lo primero que explica el CKT es que los encargados del kernel manejan una fecha de publicación fluida con el fin de ajustarla a los problemas que pudieran surgir en el desarrollo, si bien el actual calendario hace que tengamos una nueva versión de Linux cada dos o tres meses. Por su parte, Ubuntu maneja como distribución un calendario fijo, con un lanzamiento cada seis meses que solo se retrasa en circunstancias extremas.

Debido a que los lanzamientos del Linux y de Ubuntu no están alineados, se puede dar el caso de que una versión del kernel sea publicada en unas fechas similares al de un nuevo lanzamiento de la distribución o que la versión de Linux sea publicada después del lanzamiento de Ubuntu debido a que fue retrasada. Por otro lado está la política del propio CKT, que ha estimado en un mes el tiempo requerido entre la nueva versión de Linux y el kernel asociado a Ubuntu para que sea considerado lo suficientemente estable para su publicación en los repositorios.

Lo planteado por el CKT puede ser un problema cuando una nueva versión de Linux es lanzada solo cuatro semanas antes de una nueva publicación de Ubuntu o una semanas después de la fecha programada para el sistema operativo. Para ilustrar la situación con un ejemplo, el equipo ha publicado un gráfico en el que se ve que el lanzamiento de Ubuntu 24.10 casi coincide con el de Linux 6.11.

El CKT reconoce que la situación que se le plantea es un dilema, ya que, con su esquema actual, debería incluir en Ubuntu 24.10 un kernel que ya tiene entre dos y tres meses en lugar del último, cuyo lanzamiento en caso de cumplirse la fecha se produciría poco antes de la publicación del sistema. Esto plantea si es mejor incluir un kernel que tiene dos o tres meses o si acortar el proceso de clarificación para llegar a la fecha de lanzamiento, con la posibilidad de que la segunda opción derive en un producto que proporciona menos confianza, o si ajustar la fecha de lanzamiento de Ubuntu.

Sobre la política en torno a la introducción de un kernel reciente en Ubuntu, el CKT ha explicado lo siguiente: “La forma en que CKT ha elegido históricamente una versión upstream del kernel de Linux fue con un enfoque conservador de ‘esperar y ver’. Dada la ventana de estabilización de un mes requerida, una versión upstream del kernel que se lanzará casi con seguridad sería la selección tentativa, con un posible salto de último minuto a una versión más reciente en caso de que se lance en un plazo viable. Este enfoque garantizaría la estabilidad en el día de lanzamiento designado, pero estaba resultando impopular entre los consumidores que buscaban adoptar las últimas características y soporte de hardware, así como entre los proveedores de silicio que buscaban un compromiso de versión más firme para alinear su soporte de Ubuntu.”

“La intención detrás de esta publicación es describir una nueva política que el CKT está adoptando con respecto a la selección de la versión del kernel para una próxima versión de Ubuntu. Para brindar a los usuarios lo último en características y soporte de hardware, Ubuntu ahora suministrará la última versión disponible del kernel de Linux upstream en la fecha de congelación de lanzamiento especificada de Ubuntu, incluso si el upstream aún se encuentra en estado de Lanzamiento Candidato (RC)”.

De entre los términos recurrentes mencionados por el CKT, está el lanzamiento apretado (Tight Release), que consiste en “cuando un kernel upstream está en las candidatas de lanzamiento de la 4 a la 6 dentro de la congelación de características (Feature Freeze). La suposición aquí es que el kernel upstream está lo suficientemente avanzado como para que el equipo del kernel tenga gran confianza en que se lanzará antes de la beta congelada de Ubuntu. Sin embargo, la versión upstream del kernel estará tan cerca de la versión de Ubuntu que necesitará un período limitado para realizar pruebas, solucionar problemas e integrar componentes dependientes”.

Otro término a destacar es el lanzamiento inestable: “Cuando un kernel upstream todavía está en la ventana de fusión abierta o en candidata de lanzamiento de la 1 a la 3 dentro la congelación de características, esto se conocerá como versión inestable. En esta situación, el CKT confía en que el kernel upstream todavía estará en un estado RC en la beta congelada de Ubuntu, donde la versión del kernel está congelada y, por lo tanto, no se puede esperar una estabilidad completa o incluso soporte completo de componentes dependientes”.

Obviamente, la situación no solo consiste en meter la última versión del kernel o confiar en una candidata de lanzamiento que está en una fase avanzada, ya que hay componentes como el driver de NVIDIA y el soporte de ZFS que tienen que ser tenidos en cuenta. Esto introduce bastante complejidad en lo que respecta a tomar la decisión de introducir un kernel más reciente en Ubuntu con el fin de ofrecer un mejor soporte para aquellos que usan un hardware reciente.

En lo que respecta a los lanzamientos LTS de Ubuntu, Livepatch seguirá funcionando como de costumbre para los kernels liberados; no existirá ningún kernel puente, una opción para los usuarios que desean actualizar a la versión pendiente pero que requieren de componentes dependientes que aún no están estabilizados, por lo que todas las actualizaciones estarán deshabilitadas hasta la estabilización; además de que se proporcionará un kernel estabilizado para la primera versión de mantenimiento. Dicho con otras palabras, parece que la política será algo más conservadora con los lanzamiento LTS de Ubuntu, cosa normal si tenemos en cuenta el perfil del producto.

El CKT reconoce que con esta nueva política puede ser más agresivo a la hora de proporcionar una nueva versión del kernel. Sin embargo, avisa que por ahora solo puede anunciar lo que hará en la próxima versión de Ubuntu, o sea, la 24.10, que por ahora apunta a incorporar Linux 6.11. De cumplirse los plazos mostrados en los gráficos, el kernel ya debería estar en fase estable para el día de lanzamiento del sistema operativo.

 

Fuente: Muy Linux.

Podman 5.2 ya está disponible como la nueva versión del motor de contenedores de código abierto, multiplataforma y que funciona sin daemon. En esta ocasión nos encontramos con un lanzamiento que no incluye un número significativo de novedades, de las cuales la primera mencionada no va dirigida a Linux.

Comenzando con lo que ya hemos adelantado, Podman soporta a partir de este lanzamiento libkrun como backend para crear máquinas virtuales en macOS. La principal ventaja de usar libkrun como backend es que permite montar las GPU en la máquina virtual para acelerar las tareas, si bien por defecto todavía se sigue usando applehv.

La segunda novedad más importante de Podman 5.2 es que Quadlet soporta ahora los ficheros .build, lo que permite que las imágenes puedan ser creadas por Quadlet y que luego sean utilizadas como contenedores de Quadlet. Para los que anden perdidos, Quadlet es una herramienta para ejecutar contenedores de Podman en systemd de forma óptima al permitir que los contenedores se ejecuten en systemd de forma declarativa.

El contenedor (.container) de Quadlet y los ficheros .pod soportan un nuevo campo, NetworkAlias, con el que es posible añadir alias de red. Por otro lado, las rutas de búsqueda directa de Quadlet han sido ampliadas para incluir entradas directas de nivel superior (container.d, pod.d) y entradas directas de unidades truncadas (unit-.container.d).

En lo que respecta a los comandos, se ha introducido un nuevo, podman system check, que se encargará de identificar y a ser posible corregir corrupciones dentro del almacenamiento local de contenedores, mientras podman machine reset restablecerá todos los proveedores disponibles en el sistema operativo actual (por ejemplo, garantizando que las máquinas virtuales de la máquina podman HyperV y WSL se eliminarán en Windows).

Podman 5.2 también ha introducido un puñado de cambios de calado, de entre los que destaca que a partir de este lanzamiento se requiere una nueva API de montaje del kernel que ha sido introducida en Linux 5.2, que las unidades de imágenes (.image) de Quadlet tienen ahora una dependencia sobre network-online.target y que la opción --device de podman create y podman run ya no es ignorada cuando la opción --privileged también es especificada.

Continuando con más cambios, tenemos el uso de virtiofs en lugar de 9p sobre Linux si virtiofsd está instalado en el sistema anfitrión y se quiere montar el sistema de ficheros del anfitrión en las máquinas virtuales creadas con podman machine, la posibilidad de usar las opciones --squash y --layers=false al mismo tiempo en podman build, la capacidad de Podman de pasar un tiempo de espera para la detención del contenedor a systemd cuando se crean cgroups, el marcado de la opción --volume-driver como obsoleta en podman machine init, además de que los comandos podman start y podman stop ya no imprimen el ID completo del pod iniciado o detenido, sino la entrada del usuario utilizada para especificar el pod.

Y estas son las novedades más importantes de Podman 5.2. Los que quieran conocer todos los detalles pueden consultar el anuncio oficial y el registro de cambios, mientras que para obtener el motor de contenedores uno puede consultar las instrucciones al respecto o esperar a que sea suministrado a través de los repositorios de la distribución Linux utilizada si esta es rolling release o una bleeding edge relativamente “agresiva”, y eso sin contar la posibilidad de que existan repositorios externos.

KI