{"id":115,"date":"2017-04-12T09:30:00","date_gmt":"2017-04-12T12:30:00","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2017\/04\/desenvolvedor-defende-o-mir\/"},"modified":"2026-09-08T10:43:19","modified_gmt":"2026-09-08T13:43:19","slug":"desenvolvedor-defende-o-mir","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2017\/04\/desenvolvedor-defende-o-mir\/","title":{"rendered":"Desarrollador defiende Mir"},"content":{"rendered":"

\"Mascote<\/p>\n

Nota (2026):<\/strong> Noticia de abril de 2017, mantenida como registro. El detalle que solo el tiempo revel\u00f3: cuando este texto sali\u00f3, Canonical ya hab\u00eda anunciado el fin<\/em> de Unity8 y de la convergencia \u2014 una semana antes. La secci\u00f3n Nueve a\u00f1os despu\u00e9s<\/em>, al final, cuenta lo que realmente sucedi\u00f3: Wayland gan\u00f3 el escritorio, y Mir sobrevivi\u00f3 convirti\u00e9ndose en otra cosa.<\/div>\n

Desarrollador defiende Mir \u201cWhy Mir\u201d<\/strong><\/h2>\n

El desarrollador can\u00f3nico Alan Griffiths<\/a> ha estado blogueando mucho en los \u00faltimos d\u00edas sobre el servidor Mir. Ha estado intentando que la comunidad respalde Mir e incluso que potencialmente a\u00f1ada soporte para el cliente nativo de Wayland. Su \u00faltimo post se titula \u201cWhy Mir\u201d<\/strong> con muchos a\u00fan pregunt\u00e1ndose por qu\u00e9 deber\u00edan preocuparse por Mir cuando Wayland<\/a> ha demostrado ser el camino probado y ampliamente adoptado.<\/p>\n

<\/p>\n

Griffiths habla sobre las abstracciones de Mir, el soporte de Mir para los gr\u00e1ficos de Mesa KMS\/X11 y Android HWC (aunque tambi\u00e9n son capaces con Wayland), \u201cadem\u00e1s de la prueba de concepto\u201d el soporte para Vulkan aunque a\u00fan no es p\u00fablico y Wayland respalda a Vulkan, Y Mir como servidor de visualizaci\u00f3n proporciona \u201cest\u00e1ndares v\u00e1lidos\u201d.<\/p>\n

\n

Porque el trabajo fue financiado por recursos de Canonical que fueron importantes para que Ubuntu Phone y Unity8 de escritorio hayan avanzado m\u00e1s r\u00e1pido y est\u00e9n m\u00e1s completos que otros.<\/p>\n

Cuando se inici\u00f3 Mir necesit\u00e1bamos un mecanismo de comunicaci\u00f3n cliente-servidor (y Wayland no estaba en el estado en el que est\u00e1 hoy). Hicimos algo que funcion\u00f3 suficientemente bien (libmirclient) y, dado que es solo una parte peque\u00f1a, intencionalmente aislada del conjunto, podr\u00edamos cambiarlo m\u00e1s adelante. Nunca imaginamos en qu\u00e9 \u201cgran cosa\u201d se convertir\u00eda esa decisi\u00f3n.<\/p>\n<\/blockquote>\n

Quienes quieran leer m\u00e1s pueden acceder al post Why Mir<\/a>. Pero, al monitorear extensivamente el panorama de gr\u00e1ficos de Linux, lo \u00fanico que veo como punto de venta son sus patrones sensatos para facilitar a los desarrolladores levantar nuevos shells que se integren con Mir r\u00e1pidamente, pero ya hemos visto que incorporar los compositors de Wayland se puede hacer en gran medida, se ha realizado (y sigue en curso) m\u00e1s trabajo que en el entorno de Wayland para permitir compartir m\u00e1s c\u00f3digo. Uno de los grandes problemas, sin embargo, para Mir es que el soporte del driver XMir y de Mesa no est\u00e1 en la l\u00ednea principal y, por tanto, no est\u00e1 disponible f\u00e1cilmente fuera de los paquetes de Ubuntu.<\/p>\n

Enlaces<\/h2>\n