¿Por qué Canonical avanza tan rápido con Mir? ¿Qué hay de Wayland?

Desde que Canonical anunció que usará Mir por defecto en Ubuntu 13.10, he leído varios comentarios en la tubosféra de gente que se ha sorprendido de que Mir haya avanzado tanto e incluso titulares que hablan de sustitución de X.Org, sin olvidar el qué-hay-de-wayland. La mayoría de personas no conoce gran cosa de cómo funcionan los gráficos en Linux (no les culpo), y los anuncios de Canonical (especialmente los peculiares posts de Mark Shuttleworth) no ayudan demasiado a comprenderlo.

XMir en Ubuntu 13.10

Resumiendo, el servidor gráfico que Canonical va a usar en 13.10 es XMir, lo cual quiere decir que el verdadero servidor gráfico es X.org. Mir se utilizará para dibujar la imagen en la pantalla, funcionando en la práctica como un driver de X.org, que dibujará lo que le piden vía EGL (en el hardware que lo soporte, en el que no lo soporte no se usará XMir). Lo de que el servidor gráfico seguirá siendo en realidad X.org no es menosprecio: será X.org, y no Mir, quien gestione las ventanas, quien comunique a las aplicaciones los eventos de fuentes de entrada, quien las avise de la necesidad de redibujarse, etc.

De ahí que decir que Ubuntu 13.10 usará Mir "en lugar de X" sea una estupidez. X.org no sólo va a estar presente, sino que va a seguir en el centro, e imponiendo sus limitaciones habituales.

Dada la arquitectura e historial de X.org, es fácil prever que haya benchmarks en los que XMir sea más rápido que los drivers "2D" de X.org, pero también otros donde no lo sea (porque para las operaciones "2D" que usan los toolkits de escritorio tradicionales, la aceleración "3D" vía Mesa a veces es más lenta que la aceleración "2D" del driver, o que hacerlo en la CPU). Hace años que existen intentos similares de utilizar aceleración GL en X.org: Xgl, glucose, o más recientemente Glamor. En Phoronix (y si, ya se que sus benchmarks no son los mejores del mundo) han concluído que XMir es más lento que X.org. Y el programador de kwin ya ha avisado de que Xmir causa pequeños defectos en kwin en ocasiones.

Una de cal y otra de arena, pero a Canonical no le preocupa demasiado porque quiere avanzar rápido con Mir para la siguiente versión, 14.04, que es LTS. Me temo que los usuarios de 13.10 van a hacer un poco de conejillos de indias, aunque lo más probable es que la mayoría no tenga problemas o no note diferencias de velocidad ni en un sentido ni en otro, más allá del placebo.

Wayland

Respecto a Wayland, hay gente que a la luz de esta noticia se congratula que Ubuntu se libre tan rápido de X.org (falso, como ya hemos visto), y se queja de que, a pesar de todo este tiempo de ventaja, Wayland sigue sin ver la luz y de que se esté desarrollando a velocidad glacial. Afirmar tal cosa es no comprender lo que es Wayland, lo que pretende, y la diferencia que lo separa de Mir.

Wayland hace tiempo que está "preparado". Por ejemplo, el equivalente a XMir que Ubuntu usará en 13.10, XWayland, existe hace tiempo y se puede usar. Respecto al reemplazo completo de X.org, si esperan a que Wayland "progrese" y pueda usarse como servidor gráfico, pueden esperar sentados, porque eso no va a ocurrir. Ni tan siquiera Weston, que es el servidor gráfico de ejemplo de Wayland, va a mejorar en el sentido de llegar a ser usado como reemplazo de X.org, ya que, como digo, es tan sólo de ejemplo. No veremos jamás una versión de Wayland/Weston que las distros adopten como reemplazo de X.org, sino una versión de GNOME o KDE en la que sus gestores de ventanas empiecen a utilizar Wayland. La próxima versión de GNOME ya añade soporte de Wayland en gnome-shell, kwin también está en ello.

Y ahí, diminuta pero presente e importante, está la diferencia fundamental con Mir. Como aspirante a reemplazar X.org, Wayland es algo más que la creación de un servidor gráfico alternativo. En realidad, es un meta-proyecto colaborativo que involucra a toda la comunidad gráfica libre para coordinarse y establecer estándares y mejorar el protocolo a la vez que se porta software a la API de Wayland. Aunque XWayland exista y esté soportado, no es el centro de atención; para un proyecto que aspira a reemplazar X.org, limitarse a XWayland no es atractivo, su objetivo es proporcionar un escritorio Wayland puro. Y esta exaltación comunitaria no es un capricho, el mundo gráfico es muy extenso y complejo y para hacer las cosas bien es imprescindible escuchar a todos (personalmente creo que el mayor fallo de Mir es el hecho de ser una solución autista, diseñada por y para satisfacer los caprichos de un solo software, Unity).

La manera correcta de medir el progreso de Wayland, por tanto, no es la evolución de Wayland, que por mucho que evolucione no va a sustituir a X.org por si mismo, sino 1) la aparición de servidores gráficos / gestores de ventana que implementen la API de Wayland (y hay unos cuantos en camino, incluyendo algunos muy psicodélicos) 2) la migración a APIs Wayland de aplicaciones con "propósito gráfico especial" (que no se porten automáticamente con el port de un toolkit: ej, reproductores de vídeo).

Desde esta perspectiva las cosas son bastante diferentes. GTK y QT tienen soporte de Wayland, y de Mir también gracias a parches de Canonical, y bien es cierto que con eso se soportan casi todas las aplicaciones. Pero Wayland, además también está soportado en Clutter, en EFL (Enlightenment), en SDL, en mplayer, en XBMC, en Chromium, en WebkitGTK, en bindings para Java. En la próxima versión, Wayland incluirá en el protocolo soporte de gestión de color, soporte de sub-superficies (útil para implementar plugins dentro del navegador como dios manda,), pantallas de alta resolución, soporte de "multi-asiento". Algunas de esas cosas son mejoras del protocolo, otras características de Weston, algunas son ambas cosas. Pero todas ellas están a un nivel completamente diferente de XMir, o XWayland: se trata de reemplazar a X.org todo lo que se pueda, no de satisfacer una visión particular con un entorno de escritorio.