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