Como usuario, fan y defensor de Linux, he chocado muchas veces con la opinión de la comunidad. Uno de los principales puntos en los que suelo chocar con los demás es la experiencia con los gráficos, un aspecto que a la mayoría no le importa debido a que ha dado por buena una pila mediocre en la que la mayoría los drivers eran muy mejorables hasta hace poco y en la que el diseño de Xorg hace imposible la eliminación del tearing. Aquí es donde entra uno de los temas más candentes, Wayland, ya que el protocolo ha generado a su alrededor un agrio debate entre sus defensores y detractores.

Mi postura en torno a Wayland no es ningún secreto. Por un lado defiendo el protocolo porque me parece un avance en la dirección correcta en lo que respecta al despliegue de gráficos en GNU/Linux. Una vez se haya asentado, la pila será más simple al encargarse el compositor de muchas de las funciones de Xorg (Wayland es un protocolo que se implementa en el compositor).

Por otro lado es obvio que el diseño de Wayland se ha quedado corto en muchos aspectos, haciendo que sea difícil de implementar y trabajar y que se haya necesitado de soluciones externas para mitigar algunas de sus carencias, destacando aquí PipeWire.

KDE Plasma Vs GNOME en Wayland: Proyección frente consolidación

En lo que respecta a mi uso personal, Wayland se ha convertido en una de las razones de por qué mi distrohopping ha bajado muchos enteros. Desde hace tiempo uso Fedora Workstation, que destaca por el uso de GNOME en su configuración base y es uno de los sistemas de referencia del entorno.

No es ningún secreto que la sesión de Wayland sobre GNOME es la implementación más avanzada del protocolo vista en un escritorio, pero eso podría cambiar dentro de poco, lo que ha hecho que me pregunte si debería de volver a KDE Plasma.

Cierto es que la implementación de Wayland en Mutter (el compositor de GNOME) sigue estando más pulida que la de Kwin, pero es innegable que en este 2021 el compositor de KDE Plasma ha metido turbo a su adaptación del protocolo, lo que ha llamado poderosamente mi atención porque a mí lo que me encandila del mundo de la tecnología no es lo que existe, sino aquello que atesora un enorme potencial que a veces no todo el mundo ve. Esto ya lo viví en su momento con AMDGPU y lo vivo ahora con las gráficas dedicadas de Intel y la proyección de Wayland en Kwin.

La meteórica proyección de Wayland en KDE durante el presente año no solo se ha traducido en una mejora en la experiencia de usuario, sino también en características que están siendo implementadas antes en Kwin que en Mutter. Por ejemplo, la sesión sobre Wayland de KDE Plasma ya soporta FreeSync/tasa de refresco variable, mientras que el código para hacer lo mismo en GNOME todavía no ha sido fusionado.

Si bien la implementación de Wayland en Mutter sigue estando más pulida, el escenario podría cambiar radicalmente una vez que Kwin haya conseguido ponerse a la altura en ese sentido, ya que nos podríamos encontrar con que el compositor de KDE Plasma es más avanzado en cuanto a características.

Mi pesadilla con DMA-BUF en GNOME

Soy un asiduo usuario de Wayland. De hecho, uso Wayland para absolutamente todo menos la grabación de gameplays, cosa que no puedo hacer debido a que el soporte de DMA-BUF para Radeon no está consolidado en GNOME y a una regresión que afecta específicamente a Fedora 34 Workstation.

El tema de la implementación de DMA-BUF para Radeon en GNOME es algo que me tiene un poco quemado al ser una característica necesaria para la grabación de gameplays y otros contenidos que funcionan a pantalla completa. Debido a que el soporte todavía no está estable para Radeon, me veo obligado a hacer dichas grabaciones desde Xorg, y es una pena porque, como ya he dicho en otras ocasiones, es lo único que impide mi migración total (sí, hasta juego desde la sesión de Wayland).

De hecho, el uso de DMA-BUF es lo que despierta mi interés por las gráficas dedicadas de Intel, ya que el soporte de dicho búfer para esas GPU fue consolidado en GNOME 3.38. Por otro lado, GNOME 41 está a la vuelta de la esquina y el problema con Radeon sigue presente y no pinta que vaya a ser resuelto a corto plazo.

GNOME Vs KDE Plasma Vs gráficas dedicadas de Intel: ¡La carrera de los ratones!

A estas alturas creo que ha quedado claro que la posibilidad de que vuelva a KDE Plasma dependen de DMA-BUF y las posibilidades de grabar desde Wayland. No voy a negar que cada vez que veo “more Wayland patches” o algo similar en las noticias sobre KDE Plasma se me ponen los dientes largos, y es que la proyección de Wayland en Kwin está siendo tan grande que el año que viene podríamos ver un vuelco en su competencia con Mutter.

He convertido a las gráficas dedicadas de Intel, a GNOME y a KDE Plasma en tres involuntarios competidores de una carrera para ver qué paso doy. Las gráficas dedicadas de Intel tienen la ventaja de garantizarme el buen soporte de Wayland (si Intel cumple las expectativas a nivel de drivers) y me harían ganar un soporte decente para la codificación por hardware, pero tienen el inconveniente de tener que tirar de la tarjeta de débito. GNOME sigue por ahí, y salvo el punto mencionado, su sesión de Wayland es bastante usable, pero su principal fuerte son sus aplicaciones para la organización personal, las cuales me son muy difíciles de sustituir. Por su parte, KDE Plasma tiene a su favor el empuje de Wayland en Kwin, pero habrá que ver si es capaz de cumplir con mis exigencias.

Veremos cómo termina esto, pero viendo cómo se las están gastando los mineros, me temo que el resultado será arriesgarme con la compra de una gráfica dedicada de Intel de salida, a pesar de que ANV, el driver de Vulkan para Intel incluido en Mesa, pinta que no estará del todo listo para la ejecución de videojuegos desde Linux cuando llegue el momento.

Pese a todo, mi posible regreso a KDE Plasma no sería a corto plazo, sino que será algo que me plantee cuando KDE neon haya migrado a la base de Ubuntu 22.04 LTS, con Manjaro KDE y el spin de Fedora con KDE como los otros aspirantes a gobernar mis ordenadores.

Hay pocas distribuciones Linux que den este tipo de sorpresas y Manjaro es una de ellas. Hablamos de cambiar los defaults habituales, por lo general tótems del software libre, por alternativas más discutibles e incluso privativas, como es el caso que nos ocupa: Manjaro Cinnamon pone a Vivaldi como navegador web predeterminado y aunque no deja de ser una anécdota por la nula importancia de este sabor concreto…

En efecto, es una decisión polémica por lo que supone: reemplazar software libre por software privativo, cuando no es algo imprescindible. Como sabéis, es muy común que las distribuciones Linux incluyan complementos privativos para ofrecer la funcionalidad básica o deseada, es decir, tanto para que determinados componentes de hardware funcionen, como para que lo hagan con las mejores garantías. Esto se hace por lo general a través de controladores.

Pero también es común que las grandes distros Linux faciliten la instalación de aplicaciones privativas populares, como Steam, Spotify, VSCode u otras tantas. Lo que resulta del todo inusual es encontrarse con una distribución que preinstale alguna de estas aplicaciones, mucho menos con una que reemplace una aplicación de software libre con una de software privativo, cuando la libre cumple con una exigencias de calidad contratadas.

El por qué se actúa así, es obvio: la mayoría de las grandes distribuciones aspiran a ofrecer solo software libre, pero anteponen la experiencia de usuario y por eso preinstalan o facilitan la instalación de software privativo. No lo hacen por gusto. Y luego está Manjaro.

Como recordaréis, Manjaro ya tuvo su polémica con este asunto hace un par de años, cuando cerró un acuerdo con FreeOffice para incluir su suite ofimática como opción por defecto. FreeOffice es una interesante alternativa a LibreOffice con una mejor compatibilidad con Microsoft Office, pero atendiendo a criterios como calidad y libertad, el cambio no tenía sentido. Manjaro lo hizo por dinero, pero el escándalo fue tal que terminaron reculando y dejando elegir al usuario qué usar durante el proceso de instalación.

Pues bien, si el cambio de LibreOffice por FreeOffice fue controvertido, el de Firefox por Vivaldi no lo es menos, habida cuenta de que se tropieza con la misma piedra: cambiar software libre por privativo, cuando el libre cumple con su función con todas las garantías. De hecho, el caso de Firefox es más sangrante, pues a diferencia del plus que supone ofrecer una mejor compatibilidad con Microsoft Office, con los navegadores no se da esa ventaja.

O sea, es cierto que los navegadores basados en Chromium ofrecen un mejor rendimiento que Firefox, y que su compatibilidad con los sitios de Google puede ser mejor, pero no se justifica en el mismo grado el cambio. Y no solo eso: a diferencia de lo sucedido con FreeOffice, Vivaldi no ha pagado nada -o no lo han dicho, aunque tampoco parece el caso- y el cambio se da únicamente en Manjaro Cinnamon, una de las ediciones comunitarias de la distribución, y no en las oficiales.

Por lo que cuentan en el blog de Vivaldi, donde le han dado más importancia de la que cabría esperar a este tema, Manjaro ya ofrece en sus repositorios a Vivaldi, además, con un tema personalizado incluido para que su integración con el escritorio sea óptima; y ahora dan el paso en Manjaro Cinnamon para hacer de este la opción predeterminada (en los comentarios de ese artículo se cuenta que FerenOS fue la primera distribución Linux en poner a Vivaldi como navegador por defecto).

¿Qué os parece la noticia?

A mí, como usuario de Vivaldi, no me gusta. Si quiero Vivaldi me lo instalo yo, pero no me metas software privativo en la imagen de instalación a menos que sea imprescindible, que no lo es. Y si reniegas de Firefox, que razones hay unas cuantas para hacerlo, vete por una alternativa libre, como son Chromium o Brave. Que sí, que Vivaldi está muy chulo, es fiable y tal, pero no es de código abierto y no hay excusas que valgan, por más que se crean que sí las hay.

Fuente: Muylinux

La implementación de Wayland por parte de NVIDIA ha sido una de las mayores batallas tecnológicas que se hayan visto en Linux. El gigante del procesamiento gráfico no daba su brazo a torcer al mantener su apuesta por EGLStreams como búfer para Wayland, mientras que el resto, incluidos Intel y AMD, apostaron por el estándar GBM.

Después de muchos años de tiras y aflojas, el futuro regreso de Intel al mercado de las gráficas dedicadas, la precipitada defunción de Xorg y sobre todo el fracaso del propio EGLStreams forzaron a NVIDIA a rectificar para adoptar GBM, más viendo las altas probabilidades de que Wayland sea establecido por defecto en la próxima LTS de Ubuntu.

NVIDIA todavía tiene trabajo por delante para ponerse al día con su soporte de Wayland, que en teoría debería de permitir que su driver oficial funcione correctamente con las sesiones de Wayland ya existentes, sin necesidad de introducir modificaciones en los compositores (o al menos no tan radicales como los que requería EGLStreams).

James Jones, ingeniero de NVIDIA, ha anunciado que el driver de la compañía ya funciona por defecto en Sway usando GBM. La consecución de este hito ha necesitado de introducir las funciones de ‘gbm_bo_create_with_modifiers2’ y de ‘gbm_surface_create_with_modifiers2’ en el backend de GBM de Mesa debido a que las funciones de ‘gbm_*_create_with_modifiers’ carecían de soporte para flags.

Sway es un gestor de ventanas y compositor de Wayland inspirado en i3 que decidió en el lanzamiento de su versión 1.0 abandonar el soporte de EGLStreams. Drew DeVault, creador de Sway, repitió una archiconocida frase de Linus Torvalds y anunció que el compositor dejaría de soportar el driver oficial de NVIDIA. Por otro lado, el compositor es uno de los mejores exponentes de Wayland, y hay quien lo considera como la mejor implementación del protocolo.

La claudicación de NVIDIA ante los estándares de Wayland ha necesitado de introducir en Mesa un backend alternativo de GBM para soportar el driver de la compañía, que actualmente también se encuentra trabajando en el soporte de DMA-BUF y en otras mejoras relacionadas con Wayland.

La versión 470 del driver del gigante verde ha puesto los cimientos para soportar Wayland, pero hay otros componentes que deben ser parcheados para que todo funcione como se espera (o sea, con las sesiones de Wayland existentes).

NVIDIA, a la caza de Radeon

NVIDIA siempre ha tenido muchos intereses en torno a Linux, pero estos siempre han estado ligados a los servidores, la supercomputación y la inteligencia artificial. Mientras tanto, y hasta hace poco, la corporación no veía a Linux como un sistema de escritorio que pudiese ser usado como Windows y macOS, pero parece que eso está empezando a cambiar, ya que, aparte del soporte de Wayland, la llegada de DLSS a Proton fue la respuesta al anuncio de FidelityFX Super Resolution (FSR).

El soporte de DMA-BUF es uno de los aspectos más interesantes debido a que dicha característica es imprescindible para la grabación de gameplays desde una sesión de Wayland. De momento todo apunta a que no va a estar habilitada por defecto en GNOME 41 para las gráficas Radeon, por lo que se mantendría oficialmente como algo exclusivo de Intel. NVIDIA tiene ahí un frente para explotar una debilidad típica de Radeon que también se da en Windows: las tecnologías asociadas o relacionadas.

Las gráficas Radeon ofrecen una “potencia bruta” comparable a la de NVIDIA, incluso en Linux, pero cuando se trata de tecnologías, NVIDIA siempre va al menos un paso por delante. Las soluciones de codificación por hardware de NVIDIA para Linux son muy superiores a las de AMD, con DLSS y en trazado de rayos el gigante verde parece ir una generación por delante de FSR y la implementación del trazado de rayos de Radeon, y así sucesivamente.

El hecho de que NVIDIA vaya por delante en tecnologías es un buen punto a su favor, por lo que después de que se haya amoldado a los estándares de Wayland y tras sumarse Intel al mercado de las gráficas dedicadas, es muy probable que veamos a Radeon volviendo a ocupar el tercer puesto, aunque en unas circunstancias muchísimo mejores que las que había en los tiempos de Catalyst/FGLRX.

Fuente: Muylinux

LibreELEC 10 ya está entre nosotros para continuar con la evolución de esta distribución Linux que ha sido creada por y para Kodi, el popular centro multimedia conocido antes como Xbox Media Center. El sistema surgió hace tiempo como una escisión en OpenELEC que llevó a una parte importante de la comunidad a crear su propio proyecto.

Con lo ya expuesto queda en evidencia el enfoque de LibreELEC, cuyo soporte más allá de x86 puede ser considerado incluso más importante que en otras distribuciones más centradas en cubrir el escritorio de propósito general. Por lo demás, se trata de un sistema en el que la actualización del mencionado Kodi es el gran protagonista, aunque la presencia de componentes como Linux 5.10 también ayudan a la hora de abarcar más hardware.

Los desarrolladores han destacado que LibreELEC 10 no tendrá imágenes para las versiones de la 0 a la 3 de Rapsberry Pi debido a que aún siguen trabajando en la reescritura del driver gráfico. Además de eso, han reconocido que por ahora están centrando sus esfuerzos en la cuarta versión del conocido mini-PC, para la cual el sistema que nos ocupa debería ser funcional, si bien posiblemente todavía queden cosas por pulir.

Sobre el Raspberry Pi 4, los responsables comentan que han conseguido hacer funcionar la salida de HDR (HDR10 y HLG) y el audio HD (Dolby TrueHD y DTS HD), que se suman al HDMI para reproducir vídeo a 4K y 30fps y la decodificación con H.264 y H.265. Sin embargo, también hay algunos inconvenientes, como el hecho de que no haya desentrelazado en la decodificación por hardware, los problemas detectados en la salida a 4K y 50/60 imágenes por segundo, la necesidad de modificar ficheros u opciones para la decodificación por hardware con H.264 a 50 y 60 imágenes por segundo, que Kodi se ejecuta en un televisor 4K a la resolución de 4.096×2.160 píxeles en lugar de 3.840×2.160 justo después de instalarlo y que el complemento Hyperion no funciona.

LibreELEC 10 usa Kodi 19 “Matrix” como interfaz. La última versión del conocido mediacenter trajo muchas novedades de interés, las cuales en un porcentaje importante también han llegado a LibreELEC debido a su enfoque. Por otro lado, el sistema ha migrado a GBM y V4L2, dos cambios que en teoría los usuarios no tendrían que notar en un principio.

LibreELEC 10 puede ser descargado para x86 y placas Raspberry Pi, Allwinner, Rockchip, Amlogic y NXP desde el sitio web oficial del proyecto. Los desarrolladores han dicho que las versiones beta y candidatas de lanzamiento instaladas serán actualizadas a la rama estable, pero que aquellos que todavía siguen usando LibreELEC 9.2 tendrán que actualizar manualmente. Se recomienda encarecidamente la realización de copias de seguridad debido a algunos cambios disruptivos como el uso de Python 3.

Fuente: Muylinux