Desarrollador defiende Mir “Why Mir”
El desarrollador canónico Alan Griffiths ha estado blogueando mucho en los últimos días sobre el servidor Mir. Ha estado intentando que la comunidad respalde Mir e incluso que potencialmente añada soporte para el cliente nativo de Wayland. Su último post se titula “Why Mir” con muchos aún preguntándose por qué deberían preocuparse por Mir cuando Wayland ha demostrado ser el camino probado y ampliamente adoptado.
Griffiths habla sobre las abstracciones de Mir, el soporte de Mir para los gráficos de Mesa KMS/X11 y Android HWC (aunque también son capaces con Wayland), “además de la prueba de concepto” el soporte para Vulkan aunque aún no es público y Wayland respalda a Vulkan, Y Mir como servidor de visualización proporciona “estándares válidos”.
Porque el trabajo fue financiado por recursos de Canonical que fueron importantes para que Ubuntu Phone y Unity8 de escritorio hayan avanzado más rápido y estén más completos que otros.
Cuando se inició Mir necesitábamos un mecanismo de comunicación cliente-servidor (y Wayland no estaba en el estado en el que está hoy). Hicimos algo que funcionó suficientemente bien (libmirclient) y, dado que es solo una parte pequeña, intencionalmente aislada del conjunto, podríamos cambiarlo más adelante. Nunca imaginamos en qué “gran cosa” se convertiría esa decisión.
Quienes quieran leer más pueden acceder al post Why Mir. Pero, al monitorear extensivamente el panorama de gráficos de Linux, lo único que veo como punto de venta son sus patrones sensatos para facilitar a los desarrolladores levantar nuevos shells que se integren con Mir rápidamente, pero ya hemos visto que incorporar los compositors de Wayland se puede hacer en gran medida, se ha realizado (y sigue en curso) más trabajo que en el entorno de Wayland para permitir compartir más código. Uno de los grandes problemas, sin embargo, para Mir es que el soporte del driver XMir y de Mesa no está en la línea principal y, por tanto, no está disponible fácilmente fuera de los paquetes de Ubuntu.
Enlaces
- http://www.phoronix.com/scan.php?page=news_item&px=Mir-Why-Mir
- http://voices.canonical.com/alan.griffiths/2017/04/12/why-mir/
Nueve años después: lo que realmente sucedió
El texto de arriba es de una semana después del velatorio
La ironía que da sentido a esta entrada solo se hace visible con el calendario a mano. En 5 de abril de 2017, Mark Shuttleworth anunció que Canonical pondría fin a Unity, a la convergencia y al esfuerzo de Ubuntu Phone — y que Ubuntu 18.04 LTS volvería a GNOME. La entrada “Why Mir”, de Alan Griffiths, es del 12 de abril.
Es decir: el desarrollador estaba defendiendo la razón de existir del proyecto una semana después de que la empresa desistiera de la apuesta que lo justificaba. No se trata de leer esto como tozudez: es la diferencia entre la decisión de negocio y la convicción técnica de quien escribió el código.
Wayland ganó, y no por poco
La previsión implícita en el texto original se confirmó por completo. Wayland es hoy el estándar del escritorio Linux: GNOME lo adopta por defecto desde Fedora 25, KDE Plasma 6 hizo lo mismo, y las grandes distribuciones ya han eliminado o están eliminando la sesión X11.
Los problemas que la entrada de 2017 señalaba en Mir —controlador no integrado en el árbol principal de Mesa, XMir fuera de mainline, disponibilidad restringida a los paquetes de Ubuntu— eran exactamente los correctos. Sin estar en upstream, un servidor gráfico no sobrevive.
Pero Mir no murió — se convirtió en otra cosa
Y aquí está la parte que casi nadie siguió. En lugar de cerrar el proyecto junto con Unity8, Canonical lo reposicionó por completo. Mir dejó de ser un servidor gráfico competidor de Wayland y se convirtió en una biblioteca para construir compositores Wayland.
Es una inversión total de rol: el protocolo que la publicación original trataba como rival pasó a ser el protocolo que Mir habla. Hoy es un conjunto de bibliotecas para quien quiere escribir un shell gráfico sin empezar desde cero — con entrada táctil, ratón y tableta, múltiples monitores y comunicación cliente-servidor ya resueltas.
Donde vive en 2026:
- Ubuntu Frame — el producto de quiosco y señalización digital de Canonical, mantenido por el mismo equipo de Mir. Si alguna vez ha visto un terminal de autoservicio funcionando con Linux, puede que haya sido esto.
- Dispositivos embebidos e IoT — el nicho hacia el que Canonical redirigió el esfuerzo en 2017.
- Miriway — un compositor Wayland basado en Mir, para quien quiere usarlo como escritorio.
- Y un detalle sabroso: a partir de la versión 2.26 Mir empezó a reescribir el frontend Wayland en Rust, trabajo que continuó en la 2.27. El proyecto que perdió la batalla del escritorio en 2017 está entre los que adoptaron el lenguaje que el kernel solo aceptó de lleno en 2026.
Alan Griffiths, autor del “Why Mir”, siguió en el proyecto todos esos años.
La lección que quedó
El caso de Mir es el ejemplo más didáctico de una regla del software libre: técnicamente mejor no gana; integrado en el upstream gana. Mir tenía argumentos técnicos reales: abstracción limpia, patrones sensatos, soporte para múltiples back-ends. Perdió porque el driver no estaba en el Mesa de la distribución del vecino, y porque la empresa que lo financiaba cambió de opinión.
Y hay una segunda lección, más optimista: el código bueno rara vez se desperdicia. Mir no se convirtió en un repositorio archivado, sino en infraestructura de otra cosa, en un mercado donde nadie esperaba encontrarlo.
Para el contexto completo de esta transición: Wayland será el nuevo X, de este mismo período, y Linux cumple 35 años, que cuenta cómo llegó el escritorio hasta aquí.