Mis deseos para el escritorio Linux en 2024

El escritorio Linux está viviendo el mejor momento de su historia, aunque desde algunos círculos todo se ve al revés. La Steam Deck ha logrado ser un relativo éxito en ventas, pero lo realmente importante es que a niveles generales ha tenido una recepción bastante buena, lo que muestra la madurez del sistema en términos tecnológicos. Por otro lado, Linux ha cerrado el 2023 con una cuota cercana al 4% en el escritorio, un porcentaje que sin duda sigue siendo bajo, pero que representa una evidente mejora si la comparamos con aquella época en la que retener el 1% era todo un logro.

La evolución y mejora del escritorio Linux se ha asentado principalmente en dos grandes pilares desde mi punto de vista. Primero está systemd, que ha asentado un marco homogéneo e integrado que ha permitido que el sistema mejore en aspectos como la automatización y la propia integración entre los componentes, dando así una menor sensación de collage que cuando sysvinit y Upstart eran los reyes. Linux es ahora un sistema más integrado y más desatendido, por lo que requiere de menos intervención del usuario para su instalación, configuración y mantenimiento.

Segundo, está la mejora de los controladores de la pila gráfica estándar del sistema, compuesta por Mesa y los drivers para las gráficas presentes en el kernel. Nadie imaginaba hace diez años que con una gráfica de Radeon y los drivers presentes por defecto se podría ejecutar videojuegos triple A con unos resultados que pudiesen hasta superar a Windows, pero es algo que estamos viviendo y de lo que no todo el mundo es consciente.

Volviendo a mí, desde hace años siento desinterés por las distribuciones Linux, más que nada porque veo muchas propuestas y casi ninguna aporta algo realmente nuevo y útil para el usuario común. De todo lo nuevo, lo único que ha captado mi atención son los sistemas operativos inmutables, los cuales se han mostrado, desde mi punto de vista, como un mejor cimiento para tener un sistema Linux orientado al escritorio y de calidad.

Más allá de las características que aumentan la resiliencia del sistema, como el poner en modo de solo lectura parte del sistema de ficheros, la separación de las aplicaciones del sistema (con Flatpak, Podman, Distrobox y Toolbox principalmente), las actualizaciones atómicas y las imágenes de sistema o instantáneas para volver hacia atrás, lo que más me ha gustado de los sistemas operativos inmutables es que reducen mucho la atención que necesitan del usuario, por lo que son mucho más desatendidos.

Por lo demás, mi atención se ha alejado de las distribuciones y las batallas entre escritorios para centrarse más en aspectos como el soporte de los gráficos y la multimedia, áreas que sorprendentemente siguen sin despertar un gran interés entre los usuarios de Linux, a pesar de que son críticas para tener un sistema de escritorio funcional.

Con todo lo dicho, no hace falta ser un lince para adivinar cuáles son mis deseos para el escritorio Linux en 2024, pero aún así voy a desgranarlo todo en apartados para que no quede un batiburrillo difícil de deshilachar.

Que Wayland se asiente definitivamente

Wayland se ha convertido, por méritos propios, en la mayor eterna promesa de la historia del escritorio Linux, sin embargo, parece que en este 2024 va a empezar a ver la luz al final del túnel. El protocolo gráfico no solo empieza a mostrar madurez, sino que también está asentando los cimientos para soportar características como el HDR, una meta que con Xorg se mostraba inalcanzable, y no será porque no se intentó (incluso NVIDIA metió mano al asunto sin resultados tangibles).

La trayectoria de Wayland ha sido un tormento por culpa de un diseño más centrado en pintar ventanas que en soportar un escritorio. Pintar ventanas y soportar un escritorio puede parecer lo mismo desde lejos, pero a la hora de la verdad se ha traducido en que no se tuvieron en cuenta en el diseño original del protocolo una serie de características que son inherentes a un sistema de escritorio y que Wayland no era capaz de soportar.

La situación fue tal que el núcleo duro de los desarrolladores de Wine, compuesto por algunos de los mejores ingenieros que hay dentro del software libre, fue incapaz de implementar Wayland con éxito. Por suerte, la consultora Collabora ha recogido el testigo y parece que está logrando su objetivo, pero que nadie espere que Wine soporte Wayland por defecto en el corto plazo (yo apuesto dos años como mínimo).

En lo que respecta a que Wayland sea tenido en cuenta por parte de los desarrolladores, ese paso depende totalmente de Ubuntu, distribución que acapara desde hace muchos años a más de la mitad de los usuarios del escritorio Linux. Por otro lado, hay un proyecto que podría dar la campanada como la tecnología que termine de asentar el protocolo: KDE Plasma.

Cuando se habla de Wayland sobre un escritorio, GNOME ha llevado siempre la delantera, pero esto podría cambiar radicalmente en los próximos meses si KDE Plasma consigue estabilizar su experiencia con el protocolo durante el transcurso de 2024, y es que, de conseguir eso, empezaría con unos cimientos mucho mejor ajustados al mundo real y por ende podría atraer a bastantes usuarios, sobre todo aquellos que son jugadores de videojuegos.

La sesión sobre Wayland de KDE Plasma ya proporciona en fase estable características como la tasa de refresco variable (VRR), el arrendamiento del gestor de renderización directa (DRM) requerido para soportar la realidad virtual en Wayland y el escalado fraccional, mientras que en GNOME, al menos las dos primeras cosas, todavía se encuentran en fase de desarrollo. Esto ha motivado a Nobara, una de las distribuciones de referencia del Linux Gaming, a cambiar GNOME por KDE Plasma con el fin de aprovecharse de esas posibilidades con menos complicaciones.

Desde KDE han trabajado bastante en los últimos años para tener una implementación de Wayland más ajustada a la realidad del usuario promedio que GNOME. Aquí se puede destacar el soporte para el tearing implementado en el protocolo, el cual lleva la firma de un destacado desarrollador de KDE. De hecho, parece que KDE y Valve han ganado bastante protagonismo en el desarrollo de Wayland, algo en lo que posiblemente haya influido la Steam Deck.

Decir que KDE Plasma puede ser la tecnología que asiente a Wayland definitivamente parecía una locura hace dos años, pero en estos momentos suena a algo verosímil. Si eso ocurre, es probable que Wayland sea el cimiento para iniciar la era dorada de KDE Plasma.

Otros aspectos a tener en cuenta son la consolidación definitiva de Wayland en Ubuntu a partir de la versión 24.04 LTS y la progresión de proyectos como Sway y el compositor modular que desarrolla, wl-roots, que ha logrado hacerse con el estatus de estándar de freedesktop.

Sobre GNOME, obviamente en estos momentos sigue siendo la mejor implementación de Wayland que hay en un escritorio, pero no es menos cierto que en el presente año las cosas pueden cambiar bastante viendo el empuje de KDE Plasma y la cada vez mayor adopción de Sway o wl-roots por parte de proyectos que no ven viable el desarrollo de un compositor propio basado en Wayland.

Mejores drivers gráficos

Como ya he dicho, la mejora del escritorio Linux en los últimos años no se entiende sin la mejora de los drivers proporcionados a través de la pila gráfica estándar del sistema. Esto empezó con la publicación de AMDGPU, el driver oficial de AMD para las gráficas Radeon presente en el kernel Linux, que ha servido como acicate para el inicio de una revolución que ha hecho posible la existencia de la Steam Deck.

Linux ganó con AMDGPU algo que no tenía antes: un driver gráfico de código abierto que saca partido de verdad a una GPU en el espectro x86. Hasta el anuncio de este driver, los usuarios de Linux tenían que conformarse con NVIDIA y su siempre controvertido driver privativo si querían tener potencia en ese frente, pero aquello empezó a cambiar cuando AMD, después de muchos años de peticiones y de arrastrar una situación económica bastante mala, decidiera apostar por un enfoque más abierto que ha mantenido hasta el día de hoy, aunque no sin amagos de querer revertirlo.

AMDGPU abrió la puerta a hacer algo que era inimaginable hace algunos años: ejecutar videojuegos triple A de Windows con la pila gráfica estándar de Linux, sin necesidad de emplear componentes privativos de terceros. Sin embargo, es importante tener en cuenta que el driver no cumple del todo con las especificaciones de la Free Software Foundation al requerir de un firmware privativo para liberar toda la potencia de los procesadores gráficos que soporta.

Debido a que la pila gráfica de Linux está partida en dos, con el kernel por un lado y Mesa por otro, es obvio que AMDGPU no ha estado solo para materializar la revolución se inició con él. Mucho mérito ha tenido también RADV, el driver de Vulkan para AMD presente en Mesa y de origen comunitario, sin el cual la Steam Deck sería inviable, y RadeonSI, que se encarga de soportar OpenGL con unos resultados que poco o nada tienen que envidiar a NVIDIA (valga la redundancia).

Además de un soporte para Radeon que se muestra maduro, en el año 2023 fue incluido NVK, otro driver de Vulkan presente en Mesa, pero que se apoya en el driver Nouveau (el driver de código abierto presente en Linux dirigido a las gráficas de NVIDIA). Desgraciadamente, Nouveau no es un producto oficial, sino derivado de la ingeniería inversa, lo que se traduce en un aprovechamiento muy limitado de las gráficas de NVIDIA y en pocas opciones de que pueda ser empleado en contextos como la ejecución de aplicaciones exigentes a nivel de GPU. Pese a ello, NVK ha despertado cierta esperanza para ofrecer algo mejor que solo un soporte básico para escritorio y aplicaciones que no hacen un uso intensivo de la gráfica.

Pero mi gran deseo para 2024 en este apartado es que ANV, el driver de Vulkan para las gráficas de Intel presente en Mesa, madure de una vez para mostrarse como un rival digno de RADV. Las gráficas dedicadas de Intel generaron grandes expectativas entre los usuarios de Linux, y si bien se han mostrado como productos interesantes para la multimedia (tanto reproducción como el generar contenidos) y la ejecución de OpenGL, el pobre soporte para Vulkan termina convirtiendo a esos productos en una mala opción para jugar desde Linux.

Las gráficas dedicadas de Intel son verdaderas bestias con la ejecución de OpenGL, pero cuando se trata de Vulkan, llegan hasta a ser aplastadas por una vieja Radeon RX 590. Desgraciadamente, el lamentable estado con el que fueron comercializados esos productos, sobre todo en Windows, ha hecho que la compañía centrara todos sus esfuerzos en el sistema de Microsoft y haya dejado a los usuarios de Linux como segundo plato, incumpliendo así las expectativas que muchos teníamos.

En resumidas cuentas, me gustaría que Intel se tomara en serio el desarrollo de ANV de una puñetera vez, porque el escritorio Linux ya no está en el contexto del año 2008. Intel es la única de las tres grandes del espectro x86 que ofrece soporte oficial a través del kernel, OpenGL, Vulkan y VA-API, por lo que tiene todos los cimientos para barrer a sus competidores del mercado de gráficas dedicadas para Linux.

Algunos posiblemente me salten con la cantinela de los pocos usuarios, pero la cuota ha subido durante el transcurso de la última década y no creo que Intel esté en condiciones de rechazar a clientes si quiere que su segmento de gráficas dedicadas sobreviva en el futuro, más viendo que muy pocos usuarios de Windows contemplan la compra de una gráfica que no sea de NVIDIA.

Mejor soporte multimedia

El soporte multimedia es otro de los tradicionales tendones de Aquiles del escritorio Linux. Aquí se unen dos apartados: primero, la prevalencia de los formatos privativos y/o patentados en un sector que en algunos aspectos sigue moviéndose bajo parámetros más bien propios de hace cuarenta años. Segundo, está la falta de drivers a la altura, sobre todo en lo que se refiere a procesar la multimedia mediante hardware (la GPU para más señas).

Sobre los formatos, no queda otra que fomentar el uso de VP9, AV1 y Opus entre los creadores de contenido y las plataformas de vídeo y audio. YouTube impulsa desde hace tiempo VP9 para todo canal o vídeo que alcanza unos mínimos de repercusión, e incluso reprocesa vídeos en AV1 si tienen muchísimo éxito, pero cuando nos salimos de ahí, nos encontramos con un panorama dominado por H.264, un códec que tiene una variante publicada bajo GPLv2, pero que no está libre de unas patentes que ciertas distribuciones se niegan a tragar, entre ellas Fedora y openSUSE.

Fomentar el uso de formatos realmente libres, tanto a nivel de licencia como de patentes, es fundamental para que el escritorio Linux pueda mejorar en la multimedia, porque de no ser así muchos usuarios tendrán que cumplimentar pasos adicionales, aunque estos puedan ser resueltos mediante un checkbox como en Ubuntu.

En lo que respecta a los drivers, me gustaría que las distribuciones preinstalaran libva-utils, pero reconozco que esta es una decisión que pueden conllevar sus riesgos debido a que el soporte para Linux en ese frente no está tan maduro como en Windows. Por otro lado, me gustaría que AMD se implicara más y publicara un Radeon Media Driver equivalente al conocido Intel Media Driver. Si el gigante rojo hace eso, daría todo un golpe sobre la mesa que dejaría temblando a la competencia en el sector doméstico, porque en el profesional todavía anda bastante lejos de lo que ofrece NVIDIA.

En este punto no puedo dejar de lado a PipeWire, el servidor de transmisión de multimedia que se encarga de la captura de la pantalla en Wayland, del soporte de audio y en un futuro de la captura de dispositivos de vídeo como las webcams. Su consolidación definitiva debería producirse dentro de unos meses con el lanzamiento de Ubuntu 24.04 LTS, y es que, cuando se trata de soporte para Linux, la mayoría sigue teniendo a la distribución de Canonical como la gran referente. Si Ubuntu no adopta algo, es poco probable que los desarrolladores de aplicaciones lo tengan en cuenta.

Sistemas operativos inmutables más maduros

No es ningún secreto que me he vuelto un ferviente seguidor de las distribuciones Linux inmutables, no todas, sino las que siguen el enfoque aplicado por Fedora Silverblue, openSUSE MicroOS (Aeon y Kalpa) y Vanilla OS, que apuestan por conceptos como las actualizaciones atómicas, la separación de las aplicaciones del sistema empleando Flatpak y contenedores y la disponibilidad out of the box de imágenes del sistema o instantáneas para volver a un estado anterior. Pero antes de continuar, me gustaría dejar claro que esas características no son inherentes a los sistemas operativos inmutables, sino que pueden encontrarse o ser instaladas en sistemas mutables.

Centrándome en la experiencia de usuario, lo que me gusta de los sistemas inmutables es que intentan hacer que el usuario se centre más en las aplicaciones, pudiendo así desentenderse del sistema operativo y su mantenimiento. Esto es algo que ya comenté hace tiempo cuando dije que Fedora Silverblue hizo que mi uso de Linux se volviera aburrido debido a la poca atención que requería, y en la actualidad, con las actualizaciones del sistema y Flatpak totalmente automatizadas, no me entero de nada.

Enciendo la computadora, la uso y la apagado. Cuando vuelvo a encender todo está al día sin necesidad de que abra una terminal o GNOME Software, pero debido a que Fedora es una distribución de lanzamiento puntual, sí tengo que realizar el cambio de versión de forma manual, y para colmo GNOME Software no garantiza nada si has anulado paquetes del sistema base, cosa que es mi caso con la compilación RPM de Firefox proporcionada por la distribución.

Regresando a un plano más general, los sistemas operativos inmutables tienen bastante potencial, pero dejando a SteamOS 3 a un lado debido a que en realidad no compite con nadie dentro de Linux, Fedora Silverblue se encuentra un tanto sola debido a que es la única que muestra cierto nivel de madurez. Los demás sistemas similares siguen siendo proyectos que necesitan ser pulidos para ofrecer una experiencia sin grandes sobresaltos.

Otro punto en el que los sistemas operativos inmutables necesitan mejorar es la configuración inicial o posinstalación, que llega a ser un poco aparatosa debido al requerimiento de reinicios. El proceso es en realidad corto si uno usa estos sistemas operativos de forma ortodoxa, o sea, delegando todo lo que se pueda en Flatpak, pero algo más de agilidad en este frente no vendría mal y Vanilla OS es la única que tiene algo en esa dirección de entre los sistemas que he usado en serio (que no son todos).

Creo que los sistemas operativos inmutables son el futuro del escritorio Linux, y lejos de ser un deseo, es algo que ha empezado a materializarse con la Steam Deck. De todos los sistemas operativos que he usado de manera intensiva y por un largo periodo de tiempo (incluido Windows), Fedora Silverblue es el que menos atención me ha requerido, y eso lo ha logrado siendo un producto inacabado. El ofrecer un marco que requiera de poca atención por parte del usuario con el fin de que pueda centrarse en las aplicaciones es importante para que un sistema operativo sea amigable para los perfiles con menos conocimientos, y propuestas como Silverblue y MicroOS caminan en esa dirección.

Que Flatpak siga madurando

Y para terminar me gustaría que el formato de paquetes que más uso con diferencia para las aplicaciones, Flatpak, siga madurando en aspectos como la integración y el soporte de ciertas características que todavía se le escapa.

Es obvio que Flatpak necesita madurar, aunque su estado actual es suficiente para cubrir mis bajas exigencias, ya que la informática no va mucho conmigo desde hace unos años. Dentro de todo lo que he usado en este formato durante el pasado año 2023, mi mayor sorpresa fue ver que la compilación Flatpak de ProtonUp-Qt es capaz de integrarse con el reempaquetado en el mismo de Steam, algo que descubrí de manera forzada después de que se me reportara el abandono de la recompilación Flatpak de Proton GloriousEggroll.

Pero la evolución de Flatpak no solo depende del propio formato de paquetes, sino también de la evolución de XDG Desktop Portal, que puede ser definido como una API que sirve para exponer interfaces de D-Bus mediante “portales”, los cuales son usados para acceder a recursos como el acceso de ficheros, a impresoras, la apertura de URI y más. Si XDG Desktop Portal no amplía y mejora sus posibilidades, la propia evolución de Flatpak corre riesgo de verse frenado o al menos ralentizado.

Sobre aplicaciones concretas en formato Flatpak solo tengo dos peticiones para este 2024: que LibreOffice, al igual que Firefox, emplee el diálogo o selector de ficheros de XDG Desktop Portal para integrarse mejor en KDE Plasma y que GNOME Boxes cuente con redireccionamiento de los USB, aunque esto último lo veo bastante menos probable que lo primero.

Fuente: www.muylinux.com

 

 

openSIL, la nueva iniciativa de AMD para impulsar un firmware más abierto

La Cumbre Regional de la Open Compute Project Foundation (OCP) celebrada los días 19 y 20 de abril en Praga (República Checa) ha dejado una noticia muy importante en torno a AMD: el anuncio de que reemplazará el clásico AGESA por openSIL tanto a nivel de servidor como cliente, si bien ya empezó a mostrar ciertos detalles el mes anterior.

AGESA, que son las iniciales de AMD Generic Encapsulated Software Architecture, es una biblioteca de procedimientos desarrollada por el gigante rojo de los procesadores que es utilizada para la Inicialización de la Plataforma (PI) en placas base para la arquitectura AMD64. Como pare de la BIOS de las placase base en la que es implementada, es la responsable de la inicialización de los núcleos del procesador, el chipset, la memoria principal y del controlador HyperTransport.

AGESA fue de código abierto a principios de 2011 con el objetivo de contribuir al desarrollo de Coreboot. Sin embargo, dichos lanzamientos nunca contribuyeron al desarrollo de Coreboot más allá de la familia de procesadores Bulldozer (Bulldozer, Pledriver, Steamroller y Excavator), ya que las publicaciones para generaciones posteriores se detuvieron.

Aparentemente openSIL, que es el acrónimo de Open-Source Silicon Initialization Library, viene a recuperar la senda que AGESA perdió hace tiempo. Entre los proveedores de firmware involucrados en openSIL están 9elements y AMI, mientras que AMD hizo en el evento de Praga una demostración con UEFI y Coreboot.

Además de aperturismo (esperemos que como verdadero Open Source), el gigante rojo de los procesadores pretende que openSIL sea una solución liviana, simple, transparente, segura y fácil de incrementar, cosa que en estos momentos no se puede decir un AGESA que, al menos en el sector doméstico, empieza a ser cuestionado. La compañía ha programado el comienzo del despliegue de openSIL para el año 2026.

Raj Kapoor, arquitecto jefe de firmware de AMD, comentó durante la presentación de openSIL sobre los desafíos que han tenido que afrontar con AGESA para adaptarlo a Coreboot en los dispositivos Ryzen dirigidos a ser Chromebooks, los ordenadores personales que emplean Chrome OS como sistema operativo.

Esto parece reforzar dos cosas: su llegada a equipos de consumo y que puede ayudar a facilitarle las cosas a Linux en algunos frentes, pero veremos si al final openSIL llega de verdad a equipos con Windows (los cuales muchas veces son comprados para instalarles Linux), equipos sin sistema operativo (que son cada vez más comunes) y a placas base sueltas que son compradas para montar equipos de sobremesa. Kapoor dijo durante la sesión de preguntas y respuestas que “AGESA llegará al final de su vida útil y openSIL lo reemplazará” en todos los productos. Por otro lado, se espera que el código de la prueba de concepto de openSIL para AMD Genoa llegue pronto.

AMD anunció durante la prsentación que openSIL será de código abierto y que su especificación también será abierta, por lo que la compañía aprovechó el evento para invitar a todos los proveedores de silicio a participar en su desarrollo, mejora y evolución. Sin embargo, hay que tener en cuenta que AMD es toda una experta a la hora de hacer las cosas a medias, así que sería mejor mantener la prudencia mientras no haya resultados reales que sean de verdad desplegados en el mercado de masas.

Como vemos, openSIL tiene muy buena pinta, pero viendo que todavía es un proyecto de cara al futuro y el precedente de AGESA, por ahora sería mejor mantener la prudencia y contener la euforia. Además de las intenciones, habrá que ver si a Intel y Microsoft no les molesta la nueva iniciativa del gigante rojo, porque de ser así, posiblemente hagan uso de sus poderosos puños monopolísticos para hacer que AMD limite sus objetivos.

Fuente: www.muylinux.com

Mesa 22 incluye soporte de Vulkan 1.3 y notables mejoras para AMD e Intel

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.

Fuente: https://www.muylinux.com/

Valve sigue contratando desarrolladores para trabajar en Linux

valve-amd

Podría parecer que las Steam Machines han pinchado y que lo que hay es lo que habrá, en referencia a la actual marcha de Linux en Steam, donde el catálogo indie ya es impresionante y no para de crecer pese a que los estrenos AAA se siguen haciendo de rogar, pero la compañía de Gabe Newell mantiene su apuesta por la consolidación de una plataforma de juego en PC alternativa a Windows.

Hace exactamente un mes que informamos de la contratación de un nuevo desarrollador para mejorar el soporte de AMD en Linux, cuando se suma otro al equipo. Y no solo eso, siguen contratando: ahora buscan a alguien que pueda ayudar a pulir el rendimiento del compilador de shaders, una oferta llamativa según cuentan en Phoronix, dado que el experto Tom Stellard habría dejado AMD por Red Hat recientemente para trabajar en lo mismo.

 En cuanto a la nueva incorporación, se trata de otro reputado experto en la materia, Keith Packard, exempleado de Intel y SUSE, ahora en HP Enterprise. Más allá de la empresa Packard es conocido por su fuerte implicación en Debian, como desarrollador, miembro de la dirección y el comité técnico, además de por su trabajo en sistema de ventanas X.Org. A diferencia de sus cuatro nuevos compañeros, sin embargo, Packard no se dedicará a tiempo completo, sino que hará labores de consultoría, tal y como explica en su blog.

Lo más interesante de todas estas contrataciones, es de cajón, es que todos estos desarrolladores trabajan para mejorar el soporte de controladores libres, por lo que el beneficio para usuario de GNU/Linux existe incluso si no juega. Los esfuerzos del equipo se centran como es habitual en el stack gráfico de AMD, el más necesitado, pero también el más lógico para contribuir.

No es solo que Valve esté haciendo lo que AMD no hace: Intel hacen sus deberes, y de NVIDIA no se espera nada a pesar de que en las últimas fechas han tenido movimientos sin concretar en la buena dirección. Hablando siempre de controladores gráficos abiertos, claro.

Fuente: www.muylinux.com

Disponible el kernel Linux 4.5

linux-4.5

Ya tenemos entre nosotros a Linux 4.5, la nueva versión del kernel más mediático de la informática. Como es habitual, ha sido el mismo Linus Torvalds quien ha hecho el anuncio oficial, pero nosotros preferimos coger como referencia Kernel Newbies, donde “humanizan” un poco la información.

Los usuarios de AMD posiblemente sean los más beneficiados en este lanzamiento, ya que se ha añadido soporte experimental para Powerplay a AMDGPU, el driver libre más reciente para esta marca de procesadores gráficos. En teoría esto tendría que ofrecer una frecuencia dinámica según según las necesidades de rendimiento, mejorando la gestión de energía. Esta tecnología ya estaba presente en Catalyst, y por motivos de estabilidad no estará activada por defecto en todos los modelos de APU y GPU. Por otro lado también se hamejorado de forma notable el rendimiento del driver, algo que ha motivado a Canonical a portar este soporte para Ubuntu 16.04 y dejar Catalyst/Crimson en favor de AMDGPU.

Los usuarios de viejas gráficas AMD seguirán usando el driver libre Radeon, que siempre se ha mostrado muy solvente para tareas básicas y también es capaz de realizar ciertas tareas pesadas a partir de la vieja serie 4.000 de las ATI Radeon.

Por otro lado se ha mejorado el manejo de la escalabilidad en Btrfs a través de un soporte experimental; se ha añadido una nueva llamada de sistema, copy_file_range(2), que permite copiar un rango de datos de un fichero a otro evitando costes de transferencia desde el kernel al espacio de usuario y viceversa; se ha añadido soporte para Undefined Behavior Sanitizer de GCC; mejorado la estabilidad de la jerarquía unificada de Cgroup y añadido la habilitación de DAX por inodo en el sistema de ficheros XFS. Además se ha conseguido mejorar ligeramente la eficiencia energética.

Aunque no lo parezca, salvando quizá la parte de AMD, no estamos ante un lanzamiento revolucionario, pero un software tan complejo como lo es Linux siempre da mucho que contar, incluso en esas versiones que ofrecen novedades y cambios que el usuario común difícilmente puede notar.

Fuente: www.muylinux.com


Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /home1/uiolibre/public_html/wp-content/plugins/simple-lightbox/includes/class.utilities.php on line 545