Wayland vs. X11 en Linux
Hablemos un poco sobre qué es Wayland y qué es X11 en esta «guerra» (una más) dentro del mundo de GNU/Linux
KDE vs. GNOME. Systemd o no Systemd. Entornos gráficos vs. gestores de ventanas tiling. Arch vs. Ubuntu. Flatpack vs. Snap ….
Dentro del mundo de GNU/Linux hay un montón de «guerras» internas. Nada que haga llegar la sangre al río, pero sí que los fervientes defensores de una u otra opción se decanten por su preferencia en detrimento de la otra. Y todo el mundo cargado de argumentos.
En este caso vamos a hablar sobre Wayland. Veremos qué es exactamente eso de Wayland, X11 y porque adoptar una u otra tecnología en nuestra distribución GNU/Linux.
Este artículo es una traducción/adaptación del artículo en inglés publicado por Nate Graham para su blog, que puedes leer aquí:
En él nos habla de lo que motivó este nuevo proyecto, de qué quería solucionar y de porque lleva tantos años queriéndose aplicar. Lo hace desde el punto de vista de un colaborador de KDE. Empecemos…
Hablemos sobre qué es Wayland
Wayland. Aparece con frecuencia: «Error X solucionado en la sesión de Plasma Wayland». «La sesión de Plasma Wayland ahora es compatible con la función Y». Y últimamente están apareciendo bastante en las noticias con el anuncio de que Fedora KDE propone eliminar la sesión Plasma X11 para la versión 40 y solo incluir la sesión Plasma Wayland en el arranque gráfico de su sistema. He leído mucho sobre nerviosismo y miedo al respecto últimamente.
¡Así que hoy hablemos de ello!
¿Qué es Wayland?
Wayland es un conjunto de protocolos que rigen cómo un compositor gráfico de un sistema operativo dibuja cosas en la pantalla (ventanas, botones, etc) y cómo las aplicaciones interactúan con la infraestructura de dibujo en la pantalla del compositor.
Es similar a los protocolos HTTP y SMTP que rigen cómo los navegadores web y los clientes de correo electrónico envían y reciben páginas web y datos.
Wayland también incluye una implementación de esos protocolos en un conjunto de bibliotecas extremadamente livianas llamadas libwayland-client y libwayland-server que ofrecen API estables y versionadas. Aplicaciones y compositores como KWin de KDE y Mutter de GNOME utilizan esas API para hacer cosas.
¿Por qué existe Wayland?
En pocas palabras, porque X11, aquello a lo que reemplaza, está muerto.
X11 ha estado en modo de mantenimiento durante años y recientemente no ha obtenido ningún desarrollo real más que cambios en el sistema de compatibilidad XWayland que permite que las aplicaciones X11 utilicen un compositor Wayland.
Tener algo tan central como el servidor de gráfico de ventanas sin mantenimiento es un problema importante, ya que significa que no hay correcciones de errores, ni parches de seguridad ni nuevas características que le permitan mantenerse al día con un mundo cambiante.
¿Por qué murió X11?
El modelo de desarrollo fundamental de X11 era tener un servidor de ventanas pesado, llamado Xorg, que manejaría todo y todos lo usarían. Bueno, en teoría podría haber otros, y en varios momentos los hubo, pero en la práctica escribir uno nuevo que no sea una bifurcación de uno antiguo es casi imposible.
Todos prefirieron estandarizar en un único servidor X y migraron al unísono de uno a otro cuando estuvo disponible una bifurcación mejor, porque era conveniente. Y era conveniente porque centralizaba recursos de desarrollo limitados y cuando se agregaba una función al servidor X, todos obtenían acceso a esa nueva función automáticamente.
Pero había un inconveniente: debido a que todos usaban Xorg, cualquier característica añadida para soportar cualquier caso de uso podía romper todo lo que todos los demás usaban, y esto sucedía con frecuencia. Las correcciones de errores con frecuencia hacían retroceder funciones poco conocidas que otros proyectos estaban usando.
En esencia, Xorg se volvió demasiado grande, demasiado complicado y demasiado frágil para tocarlo sin correr el riesgo de romper todo el ecosistema Linux. Hoy es estable porque ha estado esencialmente congelado durante años. Pero esa estabilidad ha ido de la mano del estancamiento.
Como todos sabemos en el mundo de la tecnología, los proyectos que no pueden adaptarse mueren. Los proyectos que dependen de ellos también mueren.
¿De qué manera Wayland es mejor?
Wayland fue concebido por desarrolladores de X que querían evitar repetir sus propios errores. Además de muchas diferencias técnicas, al ser un conjunto mínimo de protocolos y dos bibliotecas de cliente y servidor extremadamente ligeras, todo el trabajo pesado se delegó a compositores individuales, que se convirtieron en los servidores de ventana de sus entornos.
Una nueva característica agregada a uno no desestabilizaría a ningún otro compositor. Los compositores también eran libres de implementar nuevas funciones a través de protocolos privados fuera de los estándar que las aplicaciones dirigidas solo a ese compositor podían usar.
Espera, eso suena como si apesta.
Wayland no ha estado libre de problemas, es cierto. Debido a que fue inventado por desarrolladores de X conmocionados, en mi opinión fue demasiado lejos en la otra dirección.
Los protocolos básicos mínimos de Wayland carecen de la mayoría de las funciones que las aplicaciones y los escritorios no triviales realmente necesitan para funcionar, como bloqueo de pantalla, uso compartido de pantalla, activación de ventanas entre aplicaciones, etc.
Todos los compositores necesitaban encontrar formas de hacer estas cosas ellos mismos. Y esa necesidad de que cada compositor implemente todo por sí mismo fragmenta los esfuerzos de desarrollo y pone en desventaja a los equipos pequeños sin la experiencia de desarrolladores gráficos de gran impacto. Estos son problemas reales y no deberíamos esconderlos debajo de la alfombra.
Sí, pero existen soluciones
Con el tiempo, los protocolos básicos mínimos se han ampliado para cubrir lo que se necesita para que funcionen un escritorio Linux y aplicaciones sofisticadas. Gran parte de este trabajo es muy reciente, impulsado por KDE y financiado por Blue Systems y Valve Software.
Por lo tanto, es probable que la mayoría de las quejas que leas acerca de que a Wayland le falta esto o aquello (como el escalado fraccional, el uso compartido de pantalla o los atajos globales) de hace más de uno o dos años sean incorrectas hoy.
Además, el problema de la fragmentación del esfuerzo se está resolviendo mediante wlroots, una biblioteca de implementaciones de Wayland que puede utilizar para crear un compositor de Wayland.
No lo usamos en el compositor KWin de KDE porque ya hicimos la mayor parte de ese trabajo nosotros mismos antes de que existiera wlroots, pero es un gran beneficio para cualquiera que escriba un nuevo compositor desde cero hoy en día. Y existe la posibilidad de que podamos portar KWin para usar wlroots en el futuro.
¿Por qué tarda tanto en adoptarse este nuevo proyecto?
El hecho de que el protocolo central mínimo de Wayland le impidiera reemplazar completamente lo que pretendía reemplazar fue una mala decisión de diseño arquitectónico por parte de sus autores que paralizó la perspectiva de su rápida adopción cuando se lanzó en 2008.
No se ve el mismo problema con otros proyectos más nuevos como Systemd y PipeWire, que se adoptaron mucho más rápido.
Y, lamentablemente, guiar nuevos protocolos a lo largo del proceso de aprobación para solucionar este problema es un ejercicio político agotador. Exige empatía y compromiso con personas de otros proyectos que abordan el problema que intentas resolver desde una perspectiva fundamentalmente diferente.
Alguien puede no estar de acuerdo con que valga la pena resolver el problema. El descarrilamiento de bicicletas descarrila la discusión y todos se desmoralizan y dejan de trabajar en ello. Durante mucho tiempo, la urgencia de sacarlo adelante fue baja porque X aún no estaba muerto.
Así que tomó más de 15 años y el resultado fue que los trapos sucios de Wayland se ventilaran en público durante todo ese tiempo. Y eso apesta. Pero… ya estamos ahí.
Ahora existen protocolos estándar para casi todo lo que cualquiera necesita. Se está trabajando activamente en las pocas omisiones obvias que quedan (como la calibración del color de la pantalla) como una cuestión prioritaria.
¿Entonces ya hemos llegado a la meta?
Las aplicaciones Plasma y KDE funcionan muy bien en Wayland, especialmente en la próxima versión Plasma 6. Como dije, todavía hay algunas omisiones, pero esas carencias están siendo rápidamente solucionadas a día de hoy.
La mayoría de las aplicaciones de terceros que no son nativas de Wayland también funcionan bien a través de la capa de compatibilidad de XWayland. Pero hay algunos que no lo hacen, porque se integran muy profundamente en alguna parte del sistema de una manera que requiere soporte X11. Estos deben migrarse para utilizar las nuevas API de Wayland.
Muchos desarrolladores de aplicaciones se acostumbraron a desconectarse de las noticias de Wayland cuando todavía era un juguete y no hicieron el trabajo de migración. Bueno, ya no es un juguete, y ahora muchos se sienten sorprendidos por la repentina urgencia de portar sus aplicaciones para usar Wayland. Eso es comprensible. Pero esta vez es real y ahora es el momento de llegar al puerto.
Para cualquier protocolo que aún no sea lo suficientemente bueno y necesite revisión, se necesita el aporte de los desarrolladores de aplicaciones para revisarlo o incluso proponer otros nuevos. Este proceso lleva mucho tiempo, por lo que es mejor empezar cuanto antes. Pero no va a desaparecer simplemente.
Lo que nos lleva a Fedora KDE
Fedora siempre ha sido una distribución «de vanguardia» que impulsa el estado técnico del arte en Linux mediante la adopción de nueva tecnología una vez que está casi lista, lo que hace que mejore rápidamente de una manera que de otro modo no lo habría hecho.
Fedora fue la primera distribución en adoptar Systemd, PulseAudio y PipeWire. Fue la primera en utilizar la sesión de Plasma Wayland de forma predeterminada. Y ahora Fedora KDE quiere ser la primera en eliminar por completo la sesión de Plasma X11 y hacer que todos utilicen la sesión de Plasma Wayland.
Debe quedar claro que el público objetivo de Fedora está formado por personas entusiasmadas con el cambio. Si eres tú, ¡todos estos proyectos deberían parecer emocionantes y geniales! Si no… entonces Fedora no es para ti. Y eso está bien.
El mundo Linux tiene aproximadamente quinientos millones de distribuciones. ¿Qué es eso que dices? ¿Solo unos 20 de ellas son buenas? Bueno, es justo, pero incluso si ese número sacado de la imaginación es exacto, ¡todavía hay 19 distribuciones que no son Fedora! Reinstalar su sistema operativo es desagradable, pero es importante elegir el que mejor se adapte a sus necesidades y preferencias. La elección conlleva la responsabilidad de elegir sabiamente.
Tal vez tengas miedo de que Fedora sea un “canario en la mina de carbón” que muestra cómo va a ir todo. Y no te equivocarías en eso, pero las transiciones aún llevan tiempo. Las distribuciones que incluyen intencionalmente software antiguo como Ubuntu LTS o Debian Stable te permitirán seguir usando X11 durante años y años.
Probablemente Arch también seguirá enviando X11 por un tiempo. Tienes opciones. Para cuando Ubuntu LTS también elimine X11, todo estará completamente listo.
Resumen
Wayland es un reemplazo de X11, que está muerto. A pesar de un proceso de desarrollo complicado, está lo suficientemente preparado para las aplicaciones Plasma y KDE como para que Fedora KDE lo esté presionando bastante.
Muchas aplicaciones de terceros ya son nativas de Wayland, pero muchas no lo son y necesitan esforzarse para migrarlas a Wayland. Si todavía falta algo que necesitan, deben dar un paso adelante para ser parte del proceso de agregarlo.
Este proceso está sucediendo y no va a dejar de suceder. Necesitamos trabajar juntos para que esto suceda más rápido y sin problemas.
Espero que te haya resultado interesante la lectura. No dejes de visitar el original escrito por Nate Graham y leer los comentarios que se van desarrollando sobre el artículo.
