13 de julio de 2013

¿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.

13 comentarios:

  1. Dices “La mayoría de personas no conoce gran cosa de cómo funcionan los gráficos en Linux (no les culpo)”, entonces, ¿te atreves a escribir una de tus excelentes entradas para describirlo?

    Yo he buscado algo sobre cómo funciona la arquitectura gráfica en Linux (incluyendo tanto X.org como los drivers del kernel) y la verdad es que no he encontrado nada que realmente me lo aclare (o que yo no lo he entendido, claro).

    ¿Podrías, si no te apetece escribir :), dar algunas pistas de documentación sobre esto?

    Muchas gracias ;)

    ResponderEliminar
    Respuestas
    1. Esto anduvo corriendo por ahí hace un tiempo http://blog.mecheye.net/2012/06/the-linux-graphics-stack/

      Eliminar
    2. en este enlace muestra algunos de los cambios que se avecinan
      http://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/

      Eliminar
  2. Anónimo6:06 a. m.

    Diego simplemente gracias por darnos esta interesante explicación sobre la verdad de MIR, por favor siga informando, su opinión es valiosa, ojalá más personas que entienden del tema se tomaran el tiempo en plasmar sus opiniones y conocimientos, adelante.

    ResponderEliminar
  3. Anónimo2:30 p. m.

    '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.'

    No acabo de ver la diferencia entre reemplazar X.org a empezar a utilizar Wayland. ¿Que falta para que empecemos a probar una distribución linux estandar con Gnome o KDE basada en Wayland?

    Muchas gracias.

    ResponderEliminar
    Respuestas
    1. En GNOME 3.10, se supone que gnome-shell actuará como servidor Wayland

      Eliminar
  4. Anónimo4:19 p. m.

    Segun entiendo Wayland puede trabajar con xorg corriendo como un cliente wayland ( xwayland) . Es posible que tambien se pueda usar MIR como cliente de Wayland a futuro ¿?

    ResponderEliminar
    Respuestas
    1. Si, pero dudo que haya interés en hacer algo así.

      Eliminar
  5. Anónimo12:26 a. m.

    en un mundo polar, donde cada cual va por su lado... el fracaso
    unir convenientemente los dos paradigmas inteligentemente
    es el triunfo...

    ResponderEliminar
  6. '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.'

    ¿Eso claramente no es duplicación de código? Ya que tanto GNOME, como KDE crearan su propio servidor gráfico, siguiendo las especificaciones del protocolo Wayland. ¿Porqué uno usar un sólo servidor gráfico(así como xorg, o al menos no veo un xorg para cada entorno gráfico) para todos los escritorios?

    ResponderEliminar
    Respuestas
    1. Creo, pero sin estar seguro, que el código de Kwin y Gnome Shell depende del toolkit que utilizan y no tanto del servidor gráfico. GTK+3 y Qt5 son los toolkits que sostienen/sostendrán muchos de los entornos de escritorio que se usan en GNU/Linux, así que en teoría, no hay que duplicar el código para usar Kwin ni Gnome Shell una vez que los toolkits sean absolutamente compatibles con Wayland (en progreso). Esto significa que para ver el gnome shell y kwin en wayland no hay que reprogramar todo el código, sino que habrá que hackearlo por un tiempo. Por otro lado, el estado actual de los toolkits hace posible pensar que pronto, con suerte en este año, veremos un escritorio estable y funcional en Wayland... aunque muy probablemente haya bastantes dependencias con X todavía para los programas que suelen incluir las distros o los que el usuario utilice.

      Eliminar
  7. En parte si. En la práctica, compartirán librerías de bajo nivel. El problema es que ya no existe un "servidor" gráfico, sino un servidor + gestor de ventanas.

    ResponderEliminar
  8. Y creo que ese es uno de los objetivos más ambiciosos de Wayland: dejar atrás al "hombre de en medio con sus 30 años de código a cuestas" en la cadena de eventos que llevan tus gráficos a la pantalla.

    Para mí, ambos proyectos son interesantes, pero sí a muy distintos niveles. Poner a Unity 7/8 como la apuesta y construir un servidor gráfico alrededor del mismo durante un par de años (para que esté bien completo y funcional, no para que pase de XMir a Mir) es una apuesta débil. Aunque he leído buenas reseñas con respecto al Unity 7 de Ubuntu 13.04, no creo que sea un software generalmente bien recibido en el escritorio, no hablemos ahora de las plataformas móviles, donde ni siquiera ha sido probado intensivamente.

    No me malinterpreten, le deseo lo mejor a Unity y me hubiera encantado que el proyecto Ubuntu Edge hubiera funcionado este mes y haber tenido el dinero para invertir en el mismo, pero Mir y Wayland tienen dos diferencias enormes:

    1) El desarrollo de Mir es dependiente del entorno de escritorio (Unity), el cuál es prácticamente imposible de portar a otras distribuciones (sólo piensen en cuántas distros usan Unity). El desarrollo de Wayland le da una plasticidad enorme. Hay ya varios compositores en público los cuáles se pueden enriquecer entre sí sólo por ser FOSS. Tenemos en desarrollo dos gigantes en el escritorio GNU/Linux: KWin y Gnome Shell, pero también están Enlightenment (que en la versión 19 ya tiene un compositor funcional), esos compositores 3D "psicodélicos" y el anuncio de Sailfish OS para teléfonos celulares usando Wayland... ni qué hablar de Tizen.

    2) La implementación de Mir la lleva a una divergencia con el resto de las distros. Para decir esto me baso en el carácter preferencial que Ubuntu ha tenido recientemente como una distro fácil de usar y ampliamente soportada por los desarrolladores, basta ver la cantidad inmensa de PPAs que hay por ahí, además del soporte oficial de "Steam para (Ubuntu) Linux". Por otro lado, la aparición de Wayland es un momento de oportunidad para plataformas emergentes (MATE, Cinnamon...), viene algo de fragmentación, pero pasada la turbulencia el entorno parece muy interesante. Habrá que ver quién está dispuesta a soportar Mir, habrá que ver cómo las distros en dilema responden con el tiempo, pensando en Debian, Linux Mint, Xubuntu, por estar tan estrechamente relacionadas con Ubuntu.

    Más me da curiosidad que ganas de reventar a Canonical.

    ResponderEliminar