Aunque he mencionado a Fedora Workstation en el título con el fin de que no fuera muy largo, lo que voy a exponer en este artículo de opinión puede extenderse a la edición con KDE y al resto de spins mutables dirigidos al escritorio, ya que la cuestión no se centrará en GNOME ni en las “polémicas” propuestas que ciertos empleados de Red Hat hacen en torno a la distribución, sino en la situación de la base tecnológica empleada por los sistemas mutables del proyecto Fedora dirigidos al escritorio.

Como bien sabrán los que siguen la trayectoria de Fedora, en los últimos días apareció una propuesta para eliminar las bibliotecas de 32-bit que ha sido rechazada. Como ya pasó en su momento cuando se planteó eliminar el soporte para legacy BIOS, se generó un gran revuelo y aparecieron muchas quejas por parte de los usuarios. Por mi parte, en el tema de BIOS me puse del lado de los usuarios porque creo que el firmware de la placa base no es una barrera legítima para impedir el uso de un sistema operativo, más viendo que por entonces todavía quedaban máquinas BIOS lo suficientemente potentes como para ejecutar Fedora, sin embargo, en el tema de los paquetes compilados para x86 de 32-bit sí me he mostrado a favor de su eliminación.

La gente que me sigue de cerca sabrá que soy usuario de Fedora Silverblue, sistema operativo inmutable que uso de manera ortodoxa. Esto quiere decir que, salvo firewall-config, todas las aplicaciones gráficas adicionales que tengo instaladas están en formato Flatpak menos el cliente de pCloud, el cual está en AppImage debido a que oficialmente se sirve así. Las herramientas de programación las tengo en contenedores de Toolbx y los servicios no esenciales, como los que componen un LAMP, los tengo en contenedores de Podman. Es más, hasta desinstalo el Firefox que viene en formato RPM para sustituirlo por el Flatpak proporcionado por Mozilla y el único componente de terceros que tengo instalado directamente sobre el sistema anfitrión es steam-devices, que me permite integrar los mandos para videojuegos en el cliente de Steam.

Debido a que uso Fedora Silverblue de manera ortodoxa (vale, no al 100%, pero me quedo cerca), todas las aplicaciones de 32-bit que uso están en formato Flatpak, aunque diría que Steam es la única. Por otro lado, tiendo a no ejecutar los juegos nativos para Linux, así que tiro de alguna bifurcación de Proton que está compilada para x86 de 64-bit, más concretamente la que va dirigida a la versión 3 de la arquitectura si hablamos de la variante de la capa de compatibilidad proporcionada por CachyOS.

Y tras la sesión de aburrimiento, voy a empezar a ir al grano.

Hace unos meses decidí darle una oportunidad a Fedora Workstation, obviamente sobre una máquina virtual debido a que mi ordenador principal tiene potencia más que de sobra para hacer lo mismo que en una máquina física menos jugar, así que no necesito instalar los sistemas operativos en una máquina física para tener una idea precisa de lo que ofrecen salvo en caso de que quisiera probar el soporte de Wayland y los controladores gráficos.

Al principio, tras instalar el sistema, todo bien con Fedora Workstation, pero todo se torció al empezar a usar RPM Fusion, el conocido repositorio de terceros radicado en Francia y que se encarga de proporcionar códecs privativos, códecs bajo patentes ofensivas, aplicaciones de multimedia que están fuertemente atadas a esos códecs, el driver oficial de NVIDIA y Steam en formato RPM. Lo que vi es que, mientras instalaba cosas procedentes de RPM Fusion, algunas bibliotecas se downgradeaban. Esto presenta dos grandes inconvenientes: aumenta de manera considerable las probabilidades de rotura y puede terminar reintroduciendo vulnerabilidades que han sido parcheadas.

El tema de las bibliotecas que no deberían ir hacia atrás y las posibilidades de rotura del sistema que eso conlleva nos trae al menú de GRUB de los sistemas mutables de Fedora, el cual solo muestra las versiones del kernel que están presentes. En consecuencia, si el fallo que impide el inicio del sistema se encuentra en Mesa, systemd, el escritorio u otro componente, el usuario no podrá usar su computadora y tendrá que recurrir a una imagen en vivo de Fedora y utilizar el incómodo chroot. En Silverblue el tema es diferente gracias a que GRUB muestra por defecto las dos últimas imágenes del sistema, por lo que es posible revertir a la versión anterior en caso de que la última dé problemas, pudiendo retroceder en prácticamente cualquier paquete que haya sido actualizado o instalado en la última actualización.

Paquetes que están instalados sobre el sistema anfitrión (layered) en Fedora Silverblue 42.

Otro aspecto a tener en cuenta y que ha introducido una enorme complejidad en la configuración de Workstation, la edición KDE y el resto de spins mutables de Fedora son las castraciones en el soporte de multimedia, las cuales derivan de que algunos de los códecs más populares están sujetos a patentes ofensivas y su inclusión en Fedora, que está radicada en Estados Unidos, puede traerle problemas legales a la distribución. Las castraciones en el soporte de multimedia han derivado en una mayor dependencia de RPM Fusion si uno quiere ceñirse a la paquetería “tradicional”, teniendo ahora que instalar, ni más ni menos, que una versión alternativa de Mesa que muy posiblemente no pase por las pruebas que realizan los responsables de Fedora. Aquí nos encontramos con otro escenario de altas probabilidades de rotura y la introducción de una complejidad en la configuración del sistema que empieza alcanzar niveles aberrantes.

Una vez más, y como pasa con las aplicaciones de 32-bit, yo delego todo el soporte de multimedia en Flatpak a través de Flathub, por lo que en mi caso, con Silverblue, la configuración es más ligera, automatizada y sobre todo reduzco las probabilidades de rotura al separar las aplicaciones y el Mesa que soporta los códecs patentados o privativos del sistema operativo.

Fedora Workstation vivió su mejor momento hace cuatro o cinco años, pero en la actualidad es un sistema operativo cuya configuración es absurdamente compleja, bastante más complicada que en las distribuciones basadas en Debian, y que requiere de la introducción de modificaciones que conllevan unas altas probabilidades de rotura del sistema o de reintroducción de vulnerabilidades que están parcheadas. Para usar Fedora Workstation o cualquier otra edición o spin mutable, prefiero mucho antes pasarme a Linux Mint, ya que, de entre los sistemas Linux mutables para escritorio, me parece el mejor diseñado y el mejor ejecutado, aunque la primera oportunidad se la daría a Aeon Desktop y la segunda a AlmaLinux.

Cambiando el Mesa de Fedora por el de RPM Fusion en Fedora Workstation 42.

En la actualidad no le veo mucho sentido al uso de los escritorios mutables de Fedora por parte de muchos usuarios finales. Sinceramente, para mí solo son verdaderamente útiles para desarrolladores del kernel, desarrolladores de drivers y personas que estén involucradas de verdad en el desarrollo de Red Hat Enterprise Linux, pero para un usuario común e incluso muchos desarrolladores que lidian con tecnologías que trabajan a alto nivel, el uso de un escritorio atómico sería más conveniente con el fin de reducir las probabilidades de rotura.

El mantener las bibliotecas de 32-bit en Fedora no es una cuestión sobre la compatibilidad con ciertas tecnologías antiguas o que no se ponen al día (Steam, cof, cof), sino que más bien es un ancla que retiene un modelo que se ha vuelto insostenible en el escritorio Linux en general y en Fedora en particular, muy especial cuando se habla de escritorios precocinados. Derivar todo lo que se pueda a Flatpak y tecnologías de contenedores debería ser la tendencia en el escritorio, mientras que los sistemas mutables tradicionales deberían ser relegados a distribuciones do it yourself (DIY) como Arch Linux, Gentoo o Void Linux.

La entrada Fedora Workstation, un sistema superado por las circunstancias es original de MuyLinux