Por que a Canonical escolheu Mir em vez de Wayland como servidor de exibição?

Eu gosto de saber quais são as vantagens do Mir.

Por que não Wayland / Weston?

Um esclarecimento óbvio primeiro: Wayland é uma definição de protocolo que define como um aplicativo cliente deve conversar com um componente do compositor. Ele toca em áreas como criação / destruição de superfície, alocação / gerenciamento de buffer gráfico, manipulação de eventos de entrada e um protótipo aproximado para a integração de componentes do shell. No entanto, nossa avaliação da definição do protocolo revelou que o protocolo de Wayland não atende aos nossos requisitos. Primeiro, estamos buscando um tratamento de evento de entrada mais extensível que leve em consideração desenvolvimentos futuros como dispositivos de entrada 3D (por exemplo, Leap Motion). Observe, porém, que a manipulação de eventos de entrada de Wayland não sofre com os problemas de segurança introduzidos pela semântica de manipulação de eventos de entrada de X (obrigado Daniel Stone e Kristian Høgsberg por apontar isso). Com relação aos casos de uso móveis, achamos que o manuseio dos métodos de entrada também deve ser refletido no protocolo do servidor de exibição. Como outro exemplo, consideramos as partes de integração de shell do protocolo como privilegiadas e preferimos evitar qualquer tipo de comportamento de shell definido no protocolo voltado para o cliente.

No entanto, ainda achamos que a tentativa de Wayland de padronizar a comunicação entre os clientes e o componente do servidor de exibição é muito sensata e útil, mas, devido aos nossos diferentes requisitos, decidimos adotar a seguinte arquitetura por integração de protocolo:

Um núcleo interno independente de protocolo que é extremamente bem definido, bem testado e portátil. Um shell externo, juntamente com um firewall de front-end que nos permite portar nosso servidor de exibição para pilhas gráficas arbitrárias e vinculá-lo a vários protocolos.

Em resumo, não escolhemos Wayland / Weston como nossa base para fornecer uma experiência de usuário de última geração, pois ela não preenche completamente nossos requisitos. Além disso, com nossa abordagem independente de protocolo e plataforma, podemos garantir que alcançamos nossa meta de uma experiência consistente e bonita para o usuário entre plataformas e fatores de forma do dispositivo. No entanto, o suporte ao Wayland pode ser adicionado fornecendo uma implementação de front-end específica do Wayland para o servidor de exibição ou fornecendo uma implementação do libwayland do lado do cliente que, em última análise, fale com o Mir.

Há uma discussão mais detalhada aqui: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

E do arquiteto técnico Mir:

http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/

Mais Informações:

• http://blog.cooperteam.net/2013/03//artistic-differences.html
• http://blog.cooperteam.net/2013/03/mir-and-you.html
• http://blog.cooperteam.net/2013/03/for-posterity.html

Jono Bacon em suas perguntas e respostas já respondeu isso algumas vezes. Sua última resposta está aqui:

http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s

Pelo que eu recolhi dos gostos das perguntas e respostas de Jono e dos comentários de Popey no Linux Unplugged, os pontos podem ser resumidos da seguinte forma:

1. Wayland faz demais. Ter recursos perpetuamente não utilizados em sua pilha de software é um design de software ruim.
2. A equipe de Wayland não seria flexível o suficiente para oferecer uma versão estripada de Wayland para acomodar adequadamente, respeitosamente.
3. Mir é para Wayland, o que LightDM é para GDM / KDM.
4. O Ubuntu tem prazos muito difíceis que eles precisam cumprir com os fabricantes de telefones e similares. O controle de um projeto facilita a infusão de recursos extras para garantir que esses prazos sejam cumpridos.
5. Embora eu não ache que esse motivo tenha sido oficialmente canônico e, portanto, seja apenas especulação da minha parte, no momento em que a decisão foi tomada, Wayland não parecia estar se movendo rápido o suficiente para comercializar, e a tecnologia Android existente parecia como uma base mais apropriada para lançar seu produto.