El servidor gráfico ya no importa

Hay un punto de vista sobre el debate Wayland vs Mir que hasta cierto punto contradice el artículo anterior, pero que me gustaría contar porque es igualmente válido (y también por la manía de intentar buscarle tres pies al gato). Ese punto de vista consiste en que, en realidad, tanto Wayland como Mir son relativamente irrelevantes, y no importa quien gane o quien pierda.

Se fundamenta en que la característica principal de estos servidores gráficos de nueva generación es que, en realidad, no hacen prácticamente nada comparado con lo que solían hacer sus antecesores. En los 80 y 90, el servidor X dibujaba los caracteres de las fuentes en la pantalla directamente. En el 2000, el servidor X ofrecía una serie de operaciones de renderizado elementales, y las aplicaciones las utilizaban para dibujar ellas mismas las fuentes. Con Wayland y Mir, el servidor gráfico simplemente ofrece un buffer de memoria, las aplicaciones dibujan en él lo que les de la gana y notifican al servidor cuando terminan. No es muy complicado, por eso es que los toolkits y las aplicaciones han sido portados con relativa facilidad.

Eso por el lado de los clientes. Por el lado de la interacción con las tarjetas gráficas, hemos pasado de un servidor X que ejecutaba drivers 2D, configuraba el modo del monitor, leía el bus PCI directamente e incluso tenía un emulador de BIOS, todo ello en espacio de usuario; a un mundo donde los drivers están en el kernel y se ocupan de todas esas cosas por si mismos. La parte compleja de la aceleración 3D se abstrae en Mesa.

En otras palabras, se han adelgazado considerablemente los servidores gráficos, tanto por el lado de las aplicaciones clientes como por el lado de la interacción con el hardware gráfico. Wayland y Mir son simple pegamento de ambas partes que se ocupa de coordinar el acceso de las aplicaciones a un recurso común (la imagen final que se ve en pantalla). De hecho, una de las cosas más complejas para Wayland y Mir van a ser cosas no directamente relacionadas con gráficos, como la estandarización de la coordinación entre aplicaciones (ej: que la barra de tareas sepa qué ventanas están en un escritorio virtual y cuáles en otro).

La mejor prueba de que los servidores gráficos se han vuelto irrelevantes es que estemos teniendo la discusión Wayland vs Mir: es relativamente sencillo crear un servidor gráfico alternativo, ya que casi todas las piezas del puzzle ya están ahí, sólo hay que unirlas. De hecho, tanto Wayland como Mir no son demasiado grandes. Es decir, no sería un terremoto que alguien apareciera con un tercer servidor gráfico, ya que el coste de oportunidad es mucho menor. Y lo bueno de todo esto es que, como la mayor parte del stack gráfico está fuera del servidor, la mayor parte del trabajo es común y beneficia a ambos servidores.

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

Concurso de aplicaciones para Tizen

El otro decía que Tizen es una de las pruebas de que los fabricantes quieren intentar fabricarse alternativas a Android a largo plazo, de no ser así nadie se gastaría un sólo dólar en mantenerlo vivo. Como complemento, hoy se ha sabido que la Linux Foundation ha anunciado el concurso Tizen App Challenge con el que premiarán a las mejores aplicaciones. Total de fondos del concurso: 4 milloncejos de nada. Además, parece que están moviéndose por conferencias e incluso escribiendo libros. Si uno echa un ojo a la documentación parece que el proyecto ha montado incluso un entorno nativo propio bastante completo, que curiosamente se parece mucho al de Bada, incluso el navegador web de la documentación es el mismo. Lo dicho, mucho dinero.

Canonical encuentra su oportunidad

El intento de Mark Shuttleworth de crear su propio campo de distorsión de la realidad Jobsiano tiene sus consecuencias negativas, como por ejemplo, Mir. Pero también tiene su lado positivo; este blog ha aplaudido los intentos de Canonical de innovar de verdad, como el HUD o Ubuntu TV:

"Incluso si fracasa estrepitosamente y Ubuntu TV desaparece, el mero hecho de haber intentado anticiparse marca una diferencia fundamental con la que ha sido la tradición linuxera en la informática de consumo, que consistía en llegar mal y tarde a las novedades tecnológicas, y lloriquear porque las multinacionales privativas acaparaban todo"

El mayor esfuerzo de Canonical en los últimos tiempos se centra en Ubuntu Phone. Shuttleworth no se resigna a usar Ubuntu en el PC y la TV y Android en su casa, quiere un entorno digital integrado, y hace bien. Sin embargo, durante un tiempo parecía que el destino de Ubuntu Phone iba a ser el mismo de Ubuntu TV: muchas presentaciones, vídeos y enlaces en la página web para fabricantes de hardware interesados, pero poco interés de dichos fabricantes en la práctica.

Todo este tiempo me ha intrigado esta falta de interés en Ubuntu Phone. Es falso que en materia de sistemas operativos portáctiles está todo el pescado vendido, puede estarlo para los grandes jugadores, pero hay sitio de sobra para minorías: los smartphones no han superado las ventas de teléfonos móviles "tradicionales" hasta prácticamente ahora, estamos aun en los inicios del sector. Recuerden que en los 90 nacieron cosas como BeOS, a pesar de que las dificultades para ser una alternativa en aquel entonces eran mucho mayores que las de hoy.

Además, es bien sabido que hay fabricantes de portáctiles que, conscientes que el hardware hoy en día es el mismo para todos y que lo que diferencia a una plataforma es el software, andan buscando disimuladamente una plataforma que les permita librarse de las garras de Google y de la competencia de los grandes jugadores de Android (o la amenaza de competencia de los pequeños, respectivamente). No es casualidad que tanto fabricantes de móviles como fabricantes de componentes muestren interés por Firefox OS, por ejemplo. O que Tizen, a pesar de su fracaso e irrelevancia, siga recibiendo financiación de alguien y no haya desaparecido.

De ahí que durante mucho tiempo me hiciera la pregunta: ¿Por qué ningún fabricante de teléfonos hace la prueba con Ubuntu Phone? Es más, puestos a intentar montar una alternativa seria, ¿por qué nadie intenta comprar Canonical?

Al final, lo inevitable tenía que suceder, y hace unas semanas Ubuntu anunció un Ubuntu Carrier Advisory Group con varias operadoras interesadas en probar suerte con Ubuntu Phone. Si, seguramente se trata de esas multinacionales de telecomunicaciones fustradas por no poder controlar ni los teléfonos de sus clientes ni los sitios web que visitan, pero al menos Canonical tiene una buena oportunidad de construir una alternativa, y de poder introducir libertad de elección y software libre en un mundillo que lo necesita. A mi, por ejemplo, me da la oportunidad de instalar Ubuntu Phone en el Nexus4, en lugar de limitarme a meras personalizaciones de Android. Ya es hora de que los portáctiles empiecen a plataformizarse, como hicieron los PCs.

Las novedades de Linux 3.10

Ya se ha anunciado la versión 3.10 del kernel Linux. Esta versión incluye soporte para bcache, que permite usar discos SSDs como cache de discos duros tradicionales; una mejora del formato de Btrfs que reduce el tamaño del árbol dedicado a mantener la información sobre extents un 30-35%; soporte para checksums de metadatos en XFS; multitarea sin temporizador; mejoras de escalabilidad y rendimiento en SySV IPC y los sistemas de bloqueos rwsem y mutex; soporte del sistema de virtualización KVM en la arquitectura MIPS, soporte de la arquitectura ARM big.LITTLE que mezcla CPUs de diferentes tipos; y snapshots de trazas en la funcionalidad de trazado. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.  

 · Multitarea sin temporizador: En la prehistoria de la computación, los ordenadores sólo podían tener una tarea ejecutándose, para iniciar otra había que esperar a que terminase la primera. Pero la gente quería poder arrancar varias tareas sin esperar a que terminase la primera, e incluso cambiar entre tareas, y así fue como nació la multitarea. Al principio la multitarea fue "colaborativa", un proceso se ejecutaba hasta que decidía, voluntariamente, dar paso a otras tareas. Pero era posible implementar la multitarea mejor: el hardware podía incluir un temporizador que se despertase a intervalos regulares; este temporizador podría parar cualquier tarea y ejecutar una rutina del sistema operativo que decidiera qué tarea debía ejecutarse a continuación. Esto se llama multitarea apropiativa, y es lo que hacen los sistemas operativos modernos.

Pero la multitarea apropiativa tiene algunos efectos secundarios en el hardware moderno. Las CPUs de portátiles y teléfonos requieren inactividad para entrar en modos de consumo reducido. Como la multitarea apropiativa activa el temporizador a menudo -1000 veces por segundo en Linux normalmente-, la CPU no podía entrar en esos modos de consumo reducido tanto como quisiera. En 2.6.21, publicado en Abril de 2007, Linux resolvió este problema: el temporizador se activaría 1000 veces por segundo cuando el sistema estuviese ejecutando tareas, pero lo pararía cuando el sistema no estuviese haciendo nada. Pero esto no es suficiente. Hay actividades, como el cálculo científico intensivo, o los usuarios de los parches de tiempo real, cuya latencia y rendimiento sufre daños por el hecho de tener que ser pausados 1000 veces por segundo.

Esta versión de Linux añade soporte para no activar el temporizador incluso cuando se están ejecutando tareas. Con algunas notas: en esta versión aun se sigue activando el temporizador una vez por segundo; el modo sin temporizador sólo se activa cuando hay una sola tarea, cuando hay varias se vuelve al modo normal; y se debe mantener una CPU funcionando normalmente con temporizador para que el resto pueda funcionar sin temporizadores. Para más detalles, este artículo de LWN y la documentación.

 · Bcache, un cache para acelerar el rendimiento utilizando discos SSD como cache: Desde que los dispositivos SSD se volvieron populares, mucha gente los ha utilizado como caché para los discos mecánicos tradicionales. Bcache es una implementación de esta funcionalidad, permitiendo usar SSDs como caché de otros dispositivos de bloque. Para más detalles ver la documentación, visitar el wiki o leer este artículo de LWN.

 · Btrfs: árbol de extents más pequeño y eficiente: Btrfs ha incorporado a su formato de disco un nuevo tipo de clave para la gestión de extents  que usa el espacio más eficientemente, reduciendo el tamaño de las referencias de extents de 51 a 33 bytes. En la práctica, esto implica una reducción del tamaño del b-tree de extents en un 30-35%, lo cual significa menos operaciones de copy-on-write, más referencias de extents en memoria y mayor eficiencia en las operaciones de metadatos.

Este cambio de formato no es automático, debe ser activado en tiempo de mkfs

o con btrfstune -x.

 · Checksums de metadatos en XFS: En esta versión, XFS tiene una implementación experimental de checksums CRC32c de metadatos. Estos checksums son parte de un proyecto más ambicioso que pretende implementar lo que los desarrolladores de XFS llaman "metadatos auto-descriptivos", que tiene como objeto resolver el problema de la escalabilidad de la verificación del sistema de archivos (fsck necesita demasiado tiempo para verificar sistemas de archivos de varios petabytes). Esto requiere un cambio de formato que añadirá a cada objeto de metadatos de XFS cierta información que permitirá determinar si el metadato está intacto y puede ser ignorado para propósitos de análisis forense.

Esta característica es experimental y requiere el uso de una versión experimental de xfsprogs. Para más información, puedes leer la documentación sobre metadatos auto-descriptivos.

 · Mejoras de escalabilidad de SysV IPC: La escalabilidad de los semáforos IPC de Linux era lamentable. En esta versión se han añadido varias mejoras de escalabilidad al código, como consecuencia algunos microbenchmarks muestran mejoras mayores del 10x en algunos casos.

 · Mejoras de escalabilidad del sistema de bloqueo rwsem: rwsem es un sistema de bloqueo utilizado en muchas partes del kernel que tenía problemas de escalabilidad por una serialización FIFO estricta de los usuarios del bloqueo. En Linux 3.9, se añadió una mejora llamada "robo oportunista del bloqueo", pero sólo en la ruta de código lenta. En esta versión se ha añadido un cambio similar en la ruta de código rápida, mejorando el rendimiento de pgbench con dos digitos en algunos casos.

 · Mejoras de escalabilidad del sistema de bloqueo mutex: El sistema de bloqueo mutex, utilizado ampliamente en el kernel, ha mejorado su rendimiento gracias al menor uso de operaciones atómicas y algunos cambios en el encolamiento que reducen la contención en líneas de caché de la CPU.

 · Optimización de TCP: Tail Loss probe: Esta versión añade el algoritmo TCP Tail loss probe. Su objetivo es reducir la latencia de transacciones cortas. Lo logra convirtiendo timeouts de retransmisión (RTOs) que ocurren al final de una transacción en una recuperación rápida. Más detalles sobre el algoritmo aquí.

 · Soporte de la arquitectura ARM big.LITTE: La arquitectura big.LITTLE es una solución SMP que, en lugar de añadir varios procesadores similares, avanza hacia un nuevo concepto uniendo dos sistemas SMP: uno compuesto de procesadores grandes y rápidos y otro de procesadores pequeños y energéticamente eficientes. Artículo LWN recomendado.

 · Soporte de KVM para MIPS: Otra arquitectura Linux ha añadido soporte para el sistema de virtualización KVM. En este caso se trata de MIPS. Se soportan los chips a partir del MIPS32R2.

 · tracing: snapshots de trazas, trazas de pila: El sistema de trazado/tracing ha incorporado la capacidad de tener varios buffers de traceo, lo cual permite crear snapshots del buffer de trazado principal. Estos snapshots pueden ser activados manualmente o con sondas en funciones. Es también posible obtener un volcado de pila cuando se llame a una determinada función.

Y eso es todo. La lista completa de cambios en inglés, aquí.