La fragmentación ha sido una de las señas de identidad y una de las grandes maldiciones de GNU/Linux. La naturaleza software libre y de código abierto del sistema permite a cualquiera bufircarlo y redustribuirlo. Si bien eso abre la puerta a adaptarlo a propósitos muy distintos, no es menos cierto que la situación en el escritorio ha derivado en algo que empieza a ser absurdo.

Una de las peores cosas que se han asimilado dentro del mundillo del software libre es entender que bifurcar puede ser una solución para todo. Con esto no quiero ser categórico debido a que hay casos en los que una bifurcación defensiva ha sido necesaria para salvar un proyecto, como LibreOffice, Perconna y MariaDB en su momento, pero a nivel de sistemas operativos se ha llegado a un punto en el que se bifurca de manera constante, hasta el extremo de perder el foco de los que son los verdaderos problemas que arrastramos desde hace décadas.

En la actualidad existen decenas de distribuciones orientadas al escritorio. Cada vez hay más y más propuestas, algunas con un enfoque más específico, como ChimeraOS y Nobara Linux, otras más generales como ZorinOS. Lo peor es que ninguno de los cambios de enfoque termina abordando los que son para mí los tres grandes desafíos del escritorio Linux: controladores gráficos, soporte multimedia y sonido.

Controladores gráficos en Linux

Los controladores o drivers gráficos son un aspecto que tradicionalmente ha cojeado mucho en Linux, aunque no se puede negar que, desde la aparición de AMDGPU, la situación ha mejorado bastante, pero desgraciadamente Intel a duras penas está empezando a enterarse de que ya no estamos en el año 2008 y que un buen soporte de OpenGL no es suficiente para cubrir todas las necesidades en un escenario estándar.

En Linux hemos dependido durante mucho tiempo de NVIDIA y su driver privativo, ya que era la única forma de tener una aceleración por hardware decente y era el único medio que permitía aprovechar de manera correcta una GPU. Su principal competidora, la pila gráfica estándar compuesta por los drivers del kernel y los del espacio del usuario proporcionados por Mesa, estaban por entonces más orientados a ofrecer un soporte básico que a competir con el gigante verde y con lo que se podía obtener con Windows, y es que, guste o no, el sistema operativo de Microsoft era infinitamente superior en lo que respecta a procesamiento de gráficos.

El desempeño ofrecido por pila gráfica estándar de GNU/Linux era paupérrimo hasta la aparición de AMDGPU. De los tres grandes del sector, Intel era el único que proporcionaba controladores oficiales, pero estos por general rendían aproximadamente la mitad que en Windows debido a que el objetivo, como ya he dicho, era proporcionar un soporte básico, no uno de calidad.

AMDGPU ha sido el gran acicate para cambiarlo todo en la pila gráfica estándar gracias a que puso los cimientos de toda una revolución. Hasta la aparición del controlador de código abierto y oficial del gigante rojo, la idea de ejecutar videojuegos triple A con la pila gráfica estándar de GNU/Linux era más un sueño de frikis que algo que se pudiera hacer de verdad, pero afortunadamente las cosas han cambiado mucho y ahí tenemos a la Steam Deck como principal testigo de este cambio.

La necesidad de que la pila gráfica estándar fuera competente no solo viene por el hecho de tener una alternativa de código abierto frente a lo proporcionado por NVIDIA, sino también para tener un marco que ofreciera una mejor integración y unos mayores niveles de compatibilidad. Mi viejo tutorial de cómo eliminar el tearing en KDE Plasma y NVIDIA sigue salvando vidas todavía, aunque se supone que Wayland debería de poner fin a este asunto.

Fuente: Unsplash

Sin embargo, y a pesar de las mejoras, no se puede decir que la situación sea idílica. Por un lado tenemos a Intel, cuyas gráficas dedicadas han sido de cara a los usuarios de Linux un montón de expectativas incumplidas. ANV, el driver de Vulkan, que sigue estando a años luz de lo que pueden ofrecer RADV (Vulkan para Radeon) y el controlador oficial de NVIDIA, mientras que XeSS, que en su momento fue anunciada como una tecnología de código abierto, sigue siendo privativa y estando claramente enfocada a Windows. Es triste ver que la única de las tres grandes que ofrece soporte completo y oficial para la pila gráfica estándar y VA-API haya dejado su soporte para Linux a medio hacer, pero Intel tiene que espabilar y ver que no estamos en el año 2008.

Por otro lado tenemos a NVIDIA, cuya contribución a la pila gráfica estándar roza lo nulo. A día de hoy los usuarios tienen que seguir tirando de Nouveau en este frente, un driver que, siguiendo la senda de los tiempos antiguos, está más orientado a ofrecer un soporte básico que uno de calidad. Afortunadamente, todo apunta a que dentro de poco se le subsanará la carencia de soporte para Vulkan con NVK, pero que nadie se haga ilusiones, porque mientras Nouveau siga sin despegar, su combinación con NVK a duras penas hará que pueda competir con la combinación de AMDGPU y RADV.

Continuando con NVIDIA, por ahí anda el driver de código abierto y oficial, que fue anunciado en mayo de 2022. A pesar de la euforia mostrada por buena parte de la comunidad, yo avisé que la falta de soporte para OpenGL y Vulkan apuntaba a que dicho controlador para el kernel se quedaría en el limbo al menos para su uso en escritorio, y así ha sido viendo lo acontecido desde entonces.

En resumidas, todavía queda mucho por mejorar en lo que respecta a controladores gráficos para Linux. En el tintero me he dejado casos específicos como la computación profesional con una gráfica de AMD, cosa que al menos de momento requiere de emplear AMDGPU-PRO, e incluso con esas NVIDIA resulta mejor para ese contexto debido a que el gigante verde porta muchas de las tecnologías que desarrolla a todos los sistemas operativos que soporta oficialmente.

En la actualidad la pelota se encuentra principalmente en el tejado de las tres grandes, Intel, AMD y NVIDIA, y es que sin la implicación de las corporaciones va a ser imposible tener una pila gráfica estándar capaz de hacer de todo.

Sin embargo, la comunidad podría intentar mover más intereses y recursos en este frente para darle más prioridad, porque el tener unos drivers gráficos mediocres es una de las razones que han empujado a GNU/Linux a tener que conformarse con software de “bajo consumo”, ya que los drivers gráficos mediocres hacen que el sistema no pueda hacer uso de características avanzadas de procesamiento de gráficos y por ende tiene que conformarse con tecnologías más básicas.

Soporte para multimedia

El soporte de multimedia es otro aspecto en el que GNU/Linux siempre ha cojeado, pero aquí el sistema no tiene toda la culpa debido al dominio de los formatos privativos y patentados dentro del sector.

El dominio de los formatos privativos y patentados en el sector de la multimedia pone bastantes piedras a la hora de dotar a GNU/Linux de un buen soporte, y no solo por motivos filosóficos, sino también legales. Aquí el ejemplo más claro lo tenemos en Mesa, del que se ha permitido su compilación sin los soportes de H.264, H.265 y VC-1 por hardware para las gráficas de Radeon. La razón de este movimiento se basa en el hecho de que AMD no paga los correspondientes royalties para soportar dichos formatos a través de Mesa, lo que plantea una cuestión legal que puede tener graves consecuencias.

En lo que respecta a distribuciones, son pocas las que lo ponen fácil para tener todo lo necesario sin que el usuario tenga que estar añadiendo paquetes adicionales, a veces procedentes de repositorios de terceros como en los casos de Fedora y openSUSE. Es más, la compilación Flatpak de Firefox requiere de un paquete que posiblemente se tenga que instalar aparte para tener un buen soporte de multimedia:

flatpak install org.freedesktop.Platform.ffmpeg-full

En Mozilla se llegó a plantear el establecimiento del paquete ffmpeg-full como dependencia dura de la compilación Flatpak de Firefox, pero descartaron la idea debido a algo ya expuesto: los posibles problemas legales por emplear códecs patentados sin pagar los royalties. ¿Has probado el comando y te dice que el paquete ya está presente en el sistema? Eso es debido a que otra aplicación lo ha instalado a modo de dependencia, como por ejemplo alguna de las relacionadas con la grabación o edición de vídeo o posiblemente Steam.

No quiero olvidarme de la propia industria de la multimedia, que en la tercera década del Siglo XXI sigue moviéndose bajo parámetros más bien propios de los años 80 del siglo pasado, y es que resulta vergonzoso que un formato en su día privativo y patentado como MP3 se impusiera a un OGG que es de código abierto y está libre royalties. La ciega apuesta por las patentes de la industria de la multimedia es, desde mi punto vista, una postura irracional y obsoleta.

En lo que respecta a la comunidad, esta debería de fomentar mucho más los formatos libres en lugar de limitarse a amoldarse a lo que hay en el mercado. Por ejemplo, en la actualidad hay editores de vídeo como Flowblade que no soportan AV1, el formato de vídeo que apunta a ser el futuro del sector, mientras que un H.264/x264 que empieza a ser un problema sigue dominando de forma clara (el problema no es por las patentes, sino por el espacio que llega a ocupar si se quiere tener calidad a resoluciones altas).

Pese a todo, por lo general instalar los paquetes Good, Bad y Ugly de GStreamer, además de una versión completa de FFmpeg, debería ser suficiente para reproducir todos los formatos de vídeo y audio comunes, tanto privativos y patentados como de código abierto.

Sonido

Y por últimos tenemos el sonido, y no me refiero al soporte mediante códecs, sino a través del firmware, las API y los servidores de sonido. La precariedad del soporte para el procesamiento de gráficos ha dejado la cuestión del sonido en un segundo plano, pero el escritorio GNU/Linux tiene que empezar a poner la cuestión sobre la mesa si quiere ser de verdad un rival para Windows y macOS.

El cimiento inicial de Linux para los chips de sonido fue Open Sound System (OSS), sin embargo, su creador, Hannu Savolainen, después de ser contratado por 4Front Technologies, decidió en 2002 lanzar la cuarta versión del componente como software privativo, lo que motivó su sustitución por Advanced Linux Sound Architecture (ALSA). Es importante tener en cuenta que el desarrollo de ALSA fue iniciado en el año 1998, así que no nació como respuesta a la conversión de OSS en software privativo.

ALSA, como cimiento del soporte de sonido de GNU/Linux, ha sido y es empleado por los diversos servidores que han aparecido a lo largo del tiempo, principalmente PulseAudio, JACK y PipeWire. El primero está orientado para su uso en escritorio, el segundo a contextos profesionales y el último intenta ser una solución de transmisión de multimedia todoterreno que sirva tanto para contextos domésticos como profesionales, abarcando no solo sonido, sino también imagen, de ahí que OBS Studio se apoye en PipeWire para capturar el escritorio desde una sesión de Wayland (aunque en realidad este soporte es independiente del servidor gráfico).

Pero volviendo al tema que realmente me ocupa en esta entrada, temas como las latencias, fallos en el servidor o que un sonido termine provocando cortes en otro que se esta reproduciendo (por ejemplo una notificación que salta y corta por un instante una canción) son situaciones que el escritorio Linux todavía afronta. Es cierto que lo ofrecido actualmente posiblemente satisfaga a la mayoría de usuarios comunes, pero la calidad en este sentido es insuficiente para muchos usuarios exigentes y profesionales.

Fuente: Pexels

En lo que respecta al soporte para el hardware, hoy en día todavía es posible encontrarse modelos de chip Realtek que son realmente problemáticos en Linux, como por ejemplo el ALC1220, y la actitud de Creative tampoco ayuda debido a que pocas tarjetas de sonido dedicadas Sound Blaster funcionan, lo que empuja a los usuarios de Linux a tener que buscar alternativas en ASUS.

Uno de los motivos de por qué el soporte para los chips de audio y los servidores de sonido no ocupa muchas portadas es debido a que el hardware de Realtek, presente en casi todas las placas base, suele ser suficiente para la inmensa mayoría de los usuarios. Esto es igual en Windows, y por eso desde hace muchos años las ventas de tarjetas de sonido dedicadas están por los suelos y se reducen a profesionales y usuarios a los que el chip de sonido Realtek se les ha estropeado o no funciona correctamente.

Para no ser negativo con todo, el soporte para micrófonos USB es un punto que me ha sorprendido para bien. Los usuarios de Linux podemos comprar una gran variedad de hardware en este sentido, tanto profesional como productos orientados al gaming, que al final pueden servir para lo mismo si uno solo quiere hablar, pero es positivo que uno pueda comprar un micrófono de Røde, HyperX y Razer y ver que funciona out of the box y sin más complicaciones que ajustar el volumen. Eso sí, lo de tener las aplicaciones oficiales de los fabricantes es otro cantar.

Desde mi punto de vista, el tema con el sonido tiene más relación con el servidor que con el componente que se encarga de dar soporte al chip de sonido. GNU/Linux tiene aquí una larga historia de promesas incumplidas, con software al que le cuesta muchos años alcanzar unos niveles decentes de madurez. Ya es hora de poner toda la carne en un único asador y PipeWire tiene todas las papeletas.

Conclusión

¿Qué tiene que ver todo el tocho que he expuesto con la fragmentación? Pues indirectamente ya he dado la respuesta: que la fragmentación no está contribuyendo en absoluto a resolver algunos de los principales problemas que tiene el escritorio GNU/Linux, y crear más distribuciones no va a aportar nada positivo si no se cambia el enfoque.

La creación de más distribuciones tiende a la creación de más gestores de paquetes, más compositores y más escritorios, pero no mejores drivers gráficos, un mejor soporte multimedia y un mejor soporte para los chips de sonido (tanto a través de ALSA como el servidor de turno). Además, los gestores de paquetes, los compositores y los escritorios son tres áreas que están más que saturadas, hay demasiadas opciones viendo la cantidad de usuarios que tiene GNU/Linux en total.

Los esfuerzos deben ser reorientados para centrarlos en los puntos en los que el sistema necesita mejorar. Es cierto que no todo depende de la comunidad y que hay obstáculos de procedencia externa que no pueden ser superados a menos que ciertos sectores giren de verdad hacia las tecnologías abiertas y los estándares, pero está claro que la creación de más distribuciones nos llevó hace años a una dinámica de dar vueltas en círculos que todavía se mantiene y apunta a mantenerse en el futuro.

Si la comunidad empuja para dar prioridad a aspectos como los controladores gráficos, la multimedia y el soporte para los chips de sonido, es probable que logre arrastrar a alguna que otra empresa para que contribuya más en la dirección correcta, con especial mención a NVIDIA y Creative.

La entrada La fragmentación en Linux desvía el foco de los verdaderos problemas es original de MuyLinux