Mesa 22 ya está disponible para continuar con el desarrollo y la evolución de la pila de drivers encargada de suministrar el soporte para las API Vulkan y OpenGL en Linux y otros sistemas operativos tipo Unix. En esta ocasión nos encontramos con la adopción de Vulkan 1.3 y ciertas mejoras significativas para Intel, cuyo soporte intenta mejorar a toda velocidad ante la proximidad de sus gráficas dedicadas.

Para empezar, tenemos el soporte de Vulkan 1.3, o al menos la inclusión de algunas de sus extensiones, en ANV (Intel) y RADV (Radeon). Sin embargo, la adopción de dicha versión de la API no tiene que confundir a los usuarios, porque mientras RADV es capaz de competir en potencia con lo ofrecido por NVIDIA desde hace tiempo, por ahora ANV se encuentra algo lejos de tener un estado óptimo para la ejecución de videojuegos.

En lo que respecta a Intel, Mesa 22 ha traído el soporte para Alder Lake N y ha empezado a hacer lo mismo (fase inicial) con la futura generación de procesadores de la compañía: Raptor Lake. Por otro lado, el soporte de Adaptive Sync/VRR ha llegado a los drivers de OpenGL y Vulkan, lo que obviamente apunta sobre todo a una futura ejecución de videojuegos a través de una gráfica dedicada.

RADV no ha incluido en esta ocasión muchas novedades de impacto, cosa normal si tenemos en cuenta que este driver de Vulkan está bastante maduro como mínimo para la ejecución de videojuegos, incluso títulos triple AAA compilados para Windows, así que nos limitaremos a mencionar el soporte para el estándar de compresión de texturas ETC2 emulado y la mejora del soporte para el trazado de rayos, cuyo estado actual no tiene por qué ser óptimo.

Para RadeonSI, el driver de OpenGL para Radeon, ha llegado el soporte de eliminación de sombreados de la Geometría de Próxima Generación (NGG) para las gráficas Navi 1x que han llegado a consumo y el soporte de textura dispersa. Moviéndonos hacia un terreno más abstracto, pero sin salirnos de Radeon, está la mejora del rendimiento de VCE para renderizado de vídeo.

A pesar de que Radeon e Intel siguen caminos separados en Mesa debido a que sus drivers son diferentes, de vez en cuando hay cosas que llegan a los dos fabricantes, como el soporte de sombreadores de malla (mesh shaders) para ANV sobre las gráficas DG2/Alchemist y RADV.

El controversial Wayland también ha recibido algo importante con Mesa 22, más concretamente el soporte de retroalmentación de DMA-BUF en el código de EGL, que debería representar un paso importante en los sistemas con varias gráficas que funcionan bajo una sesión de Wayland. El propósito es obtener más información sobre la GPU empleada por el compositor y para intercambiar búferes de manera más eficiente entre las gráficas primaria y secundaria.

Por lo demás, tenemos el soporte de OpenGL ES 3.1 en el código de D3D12 de Microsoft con las miras puestas en soportar la versión 4 de la API de Khronos Group; el soporte de OpenGL 4.3 para WMware SVGA, si bien aquí se requiere Linux 5.17 o posterior; el soporte de textura dispersa para Zink, el driver que se encarga de renderizar OpenGL sobre Vulkan; el hecho de que el driver de Vulkan V3DV para Raspberry Pi funcione en Android; el soporte básico de Clover OpenCL para Freedreno; además de las típicas correcciones y mejoras del rendimiento.

Mesa 22 puede ser instalado a través de la compilación de su código fuente, una vía que para la mayoría de los mortales no es muy práctica y que conlleva sus riesgos, así que lo recomendable es usar una distribución rolling release y bleeding edge como Arch Linux, Manjaro o Gentoo. Si se tiene un poco de paciencia, debería de llegar a Fedora 35 como una actualización estándar y a Flathub de la misma manera debido a que es empleado como dependencia por aplicaciones como Steam y Minigalaxy, mientras que los usuarios de Ubuntu pueden recurrir a los PPA stable y fresh de Kisak.

AMDGPU ha sido el revulsivo, el pilar y la revolución que la pila gráfica estándar de Linux necesitaba para competir con lo ofrecido por NVIDIA a través de su driver privativo. Mucho han cambiado las cosas desde que AMD lo anunciara en 2016, hasta el extremo que actualmente las gráficas Radeon rinden igual que sus rivales verdes a la hora de ejecutar videojuegos.

El desarrollo de AMDGPU, lejos de disminuir, ha ido a más, sobre todo viendo que es uno de los principales motores de la Steam Deck, la consola/mini-PC de Valve que funciona con SteamOS 3 por defecto. Esto ha repercutido en que se sigan aspectos como la cantidad de líneas de código del driver, que ha ido aumentando a buena velocidad con el paso del tiempo.

Si hace dos años anunciamos que AMDGPU representaba el 10% del código de Linux, acaparando 2,71 millones de líneas de código de las aproximadamente 27,81 millones que tenía el kernel por entonces, ahora nos hacemos eco de que el driver Open Source de AMD ha superado las tres millones de líneas en Linux 5.17 y apunta a quedarse cerca de las cuatro millones para la siguiente versión del kernel.

AMDGPU, en el actual estado de Linux 5.17, ocupa unas 3,38 millones de líneas, aunque el dato es un tanto engañoso, ya que de esa cantidad, 2,91 millones de líneas contienen código real, 339.000 son líneas de comentarios y 130.000 son líneas en blanco. A pesar de ello, eso no anula el hecho de que estamos ante el driver que más ocupa a nivel de código del kernel Linux, más viendo que i915 (Intel) “solo” acapara unas 341.000 líneas. Todos esos datos quedan dentro de los 30,63 millones de líneas del kernel, de las cuales 22,7 millones son código real, 3,84 millones comentarios y 4,03 líneas en blanco.

Pero el crecimiento de AMDGPU, lejos de detenerse, irá todavía a más en Linux 5.18, ocupando en estos momentos 3,82 de líneas, de las cuales 3,29 son código real, 391.000 comentarios y 136.000 líneas en blanco.

El rápido crecimiento de AMDGPU, como ya expusimos en su momento, responde a que buena parte del código está en ficheros de cabecera (header) autogenerados para la documentación interna y los registros de datos. Afortunadamente, el compilador elimina los ficheros de cabecera que no son utilizados, por lo que el driver resultante no debería de ser, al menos sobre el papel, bloatware. Esos ficheros de cabecera son importantes, sobre todo porque aportan documentación que puede ser útil para el desarrollo del driver.

Además de un aumento en la cantidad de líneas de código, AMDGPU no para de ganar nuevas características con cada lanzamiento del kernel, una línea de desarrollo que con la Steam Deck, sobre todo si tiene éxito con SteamOS, se verá reforzada. Por ejemplo, para Linux 5.18 se espera que el modo FreeSync esté habilitado por defecto, aunque el uso de la tecnología de tasa de refresco variable también depende de que sea implementada en el compositor empleado para el despliegue de los gráficos (Mutter, Kwin, Sway… ).

Como vemos, el driver Open Source de AMD para Linux está en buena forma, a pesar de depender de un firmware privativo que se encuentra incluido en la línea oficial del kernel. Sin embargo, el gigante rojo, que en los últimos años ha gozado de una posición relativamente cómoda, tendrá que lidiar en los próximos meses con la aparición de las gráficas dedicadas de Intel y con la adopción de los estándares de Wayland por parte de NVIDIA, una situación que podría devolverla al tercer puesto que ocupó en tiempo pasados, aunque afortunadamente en unas condiciones muchísimo mejores que las tenía cuando Catalyst/FGLRX era el driver de referencia.

Zorin OS 16.1 es la primera actualización de la más reciente versión de este ‘Linux para todos los públicos’ y, como tal, llega básicamente con actualizaciones en la paquetería y poco más, aunque llega de una, lo cual siempre es de agradecer.

¿Qué significa lo anterior? Que si la edición principal de Zorin OS 16 se lanzó el agosto pasado y Zorin OS 16 Lite se retrasó hasta diciembre, Zorin OS 16.1 se presenta con ambas ediciones listas para su descarga… porque ten esto en cuenta: si ya tienes instalada Zorin OS 16, no tienes que hacer nada para estar al día, más que aplicar las actualizaciones corrientes del sistema.

Por lo demás, recuerda que Zorin OS (Core) es la distribución destacada de este proyecto: usa una variante del escritorio GNOME repleta de funciones y con muy buena pinta al ojo; mientras que Zorin OS lite se basa en Xfce y está dirigida a equipos de recursos más modestos… eso sí, sin perder apenas elegancia en comparación con la edición principal.

Con respecto a las novedades que trae Zorin OS 16.1 en general, las más importantes a nivel de base derivan de la actualización del sistema a Ubuntu 20.04.4 LTS, incluyendo kernel y controladores gráficos libres, pero también privativos, ya que con este lanzamiento se añade soporte para las RTX 3050.

Por otro lado, el equipo de Zorin mantiene actualizadas por su cuenta muchas otras aplicaciones, además de desarrollar alguna que otra propia, por lo general derivada de aplicaciones de GNOME o KDE, y en este grupo también hay actualizaciones, especialmente entre las aplicaciones que preinstala el sistema. De todas, destacan LibreOffice 7.3, la última versión de la suite ofimática lanzada a principios del mes pasado.

Por último, cabe recordar que además de Zorin OS y Zorin OS Lite existe Zorin OS Pro, una versión de pago que sirve de sustento económico al proyecto y en la que se suelen incluir un gran montón de aplicaciones preinstaladas, así como diferentes diseños de escritorio exclusivos que imitan a Windows, macOS, Chrome OS, Ubuntu, etc.

Pues bien, los beneficios íntegros obtenidos de las ventas de Zorin OS 16.1 la semana que viene irán dirigidos a tres entidades solidarias en apoyo a Ucrania, ya que los fundadores del proyecto Zorin son de descendencia ucraniana, aunque residen en Irlanda.

En todo caso, la descarga de Zorin OS 16.1 ya está disponible en el sitio oficial en cualquiera de sus ediciones: Zorin OS 16.1 Pro, Zorin OS 16.1 Core, que vendría a ser la equivalente a la anterior pero gratis y sin los extras de este, y Zorin OS 16.1 Lite.

Podman 4.0 es la nueva versión de este cada vez más popular motor de contenedores desarrollado originalmente por Red Hat y uno de los principales exponentes de la OCI (Open Container Initiative) de The Linux Foundation.

Podman se dio a conocer hace unos años como una tímida alternativa a Docker que, sin embargo, no ha dejado de crecer y atraer adeptos, especialmente entre los usuarios de sistemas Red Hat y SUSE al tratarse de software nativo, de código abierto y bien integrado con tecnologías como systemd, cgroups u otras propias del entorno de Linux.

Al igual que Docker, Podman permite desarrollar, gestionar y ejecutar contenedores, pods e imágenes de contenedores; a diferencia de Docker, Podman se ofrece con todas sus funciones abiertas, sin limitaciones de funcionalidad sujetas a extensiones de pago. Además, Podman proporciona una interfaz compatible con Docker.

Pero si hay algo que caracterice a Podman, es su faceta de motor de contenedores sin demonio, esto es, no necesita de un servicio centralizado u otros procesos secundarios para funcionar:solo consume cuando hay algún contenedor en marcha; así como permite la creación de contenedores con o sin root, gracias a su integración con Buildah.

Con respecto a Podman 4.0, se trata, de acuerdo a anuncio oficial de lanzamiento, de una de sus versiones más destacadas de las publicadas hasta la fecha, con más de 60 nuevas características en su haber, multitud de correcciones y otros cambios de interés que auguran una nueva vida para el proyecto.

En esos «cambios de interés» se encuentra la primera gran novedad de Podman 4.0: soporte muy mejorado para Windows y macOS, una prioridad para el proyecto que se sustenta en el «soporte para montar el socket Podman API en el sistema host, permitiendo usar herramientas como Docker Compose en lugar de hacerlo dentro de una máquina virtual de Podman», explican.

Por supuesto, no se puede hablar estos días de Windows en el ámbito del desarrollo sin mencionar a WSL2, Windows Subsystem for Linux o el subsistema de Windows para Linux, del que ahora se sirve Podman para mejorar ampliamente su soporte en Windows. Un soporte para el que ya se anticipan mejoras en el lanzamiento de Podman 4.1.

Al margen de este esperado soporte, quizás la novedad más importante de Podman 4.0 en general sea la reescritura de la pila de red, que mejor el soporte para contenedores en múltiples redes, soporte IPv6 y el rendimiento. Para evitar problemas, por el momento se mantendrá la pila actual, por lo que se advierte para nuevas instalaciones.

Para más datos acerca de Podman 4.0, las notas de lanzamiento desgranan todos los cambios, aunque para una lectura más comprensiva vale la pena echar un vistazo a la documentación del proyecto. En todo caso, en el blog oficial se adelantan artículos más detallados explicando las principales novedades de este lanzamiento en los próximos días.

Project Zero, el equipo de analistas de seguridad compuesto por empleados de Google dedicado principalmente a hallar vulnerabilidades de día cero (zero-day), ha publicado un informe en el que se muestra a Linux como proyecto más rápido que compañías como Apple y Microsoft a la hora de corregir fallos de seguridad.

Para realizar el informe, Project Zero ha tomado todos los fallos de seguridad corregidos desde enero de 2019 hasta diciembre de 2021. El equipo de analistas de seguridad de Google ha recalcado el trabajo que hace para dificultar el terreno a los actores maliciosos, pero también ha comentado sobre su informe que “hay una serie de advertencias con nuestros datos, la mayor de las cuales es que analizaremos una pequeña cantidad de muestras, por lo que las diferencias en los números pueden o no ser estadísticamente significativas”.

Project Zero notifica al vendedor y le concede 90 días para corregir un fallo antes de hacerlo público, pudiendo dar 14 días de gracia si se confirma que hay planes serios de publicar un parche antes de los 104 días. Del informe, lo más interesante es la tabla en la que se comparan los fallos corregidos con el tiempo empleado para publicar los correspondientes parches.

Por lo que se puede ver en la tabla, Linux (en este caso el kernel como proyecto) ha sido el vendedor más rápido a la hora de solucionar sus vulnerabilidades, habiendo conseguido corregir el 96% de los fallos reportados por Project Zero dentro del límite estándar de 90 días. Esto quiere decir que de 24 de las 25 vulnerabilidades reportadas por los investigadores en seguridad de Google han sido resueltas dentro del plazo que el gigante del buscador considera como razonable, mientras que el fallo restante excedió tanto el plazo estándar como el periodo de gracia.