Perché Canonical ha scelto Mir su Wayland come server di visualizzazione?

Mi piace sapere quali sono i vantaggi di Mir.

Perché non Wayland / Weston?

Una prima ovvia precisazione: Wayland è una definizione di protocollo che definisce come un'applicazione client dovrebbe parlare con un componente compositor. Tocca aree come la creazione / distruzione della superficie, l'allocazione / gestione del buffer grafico, la gestione degli eventi di input e un prototipo approssimativo per l'integrazione dei componenti della shell. Tuttavia, la nostra valutazione della definizione del protocollo ha rivelato che il protocollo Wayland non soddisfa i nostri requisiti. Innanzitutto, puntiamo a una gestione degli eventi di input più estensibile che tenga conto degli sviluppi futuri come i dispositivi di input 3D (ad esempio Leap Motion). Si noti che la gestione degli eventi di input di Wayland non soffre dei problemi di sicurezza introdotti dalla semantica della gestione degli eventi di input di X (grazie a Daniel Stone e Kristian Høgsberg per averlo sottolineato). Per quanto riguarda i casi d'uso mobili, riteniamo che la gestione dei metodi di input dovrebbe riflettersi anche nel protocollo del server di visualizzazione. Come altro esempio, consideriamo le parti di integrazione della shell del protocollo come privilegiate e preferiremmo evitare di avere qualsiasi tipo di comportamento della shell definito nel protocollo rivolto al client.

Tuttavia, riteniamo ancora che il tentativo di Wayland di standardizzare la comunicazione tra i client e il componente del server di visualizzazione sia molto ragionevole e utile, ma a causa dei nostri diversi requisiti abbiamo deciso di optare per la seguente architettura rispetto all'integrazione del protocollo:

Un nucleo interno indipendente dal protocollo che è estremamente ben definito, ben testato e portatile. Una shell esterna insieme a un firewall front-end che ci consente di trasferire il nostro server di visualizzazione su stack grafici arbitrari e collegarlo a più protocolli.

In sintesi, non abbiamo scelto Wayland / Weston come base per offrire un'esperienza utente di prossima generazione in quanto non soddisfa completamente i nostri requisiti. Inoltre, con il nostro approccio indipendente dal protocollo e dalla piattaforma, possiamo assicurarci di raggiungere il nostro obiettivo di un'esperienza utente coerente e bella su piattaforme e fattori di forma dei dispositivi. Tuttavia, il supporto di Wayland potrebbe essere aggiunto fornendo un'implementazione di frontend specifica per Wayland per il nostro server di visualizzazione o fornendo un'implementazione lato client di libwayland che alla fine parla con Mir.

C'è una discussione più dettagliata qui: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

E dall'architetto tecnico Mir:

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

Maggiori informazioni:

• 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 sulle sue domande e risposte ha risposto alcune volte. La sua ultima risposta è qui:

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

Da ciò che ho raccolto da artisti del calibro di domande e risposte di Jono e dai commenti di Popey su Linux Unplugged, i punti possono essere riassunti come segue:

1. Wayland fa troppo. Avere funzionalità perpetuamente inutilizzate nello stack del software è una cattiva progettazione del software.
2. Il team di Wayland non sarebbe abbastanza flessibile da offrire una versione sventrata di Wayland per adattarsi adeguatamente, rispettosamente.
3. Mir è Wayland, ciò che LightDM è GDM / KDM.
4. Ubuntu ha scadenze terribili che devono rispettare con i produttori di telefoni e simili. Avere il controllo su un progetto rende più facile infondere risorse extra per garantire il rispetto di queste scadenze.
5. Anche se non credo che questo motivo sia mai stato ufficialmente da canonico, e quindi è solo una speculazione da parte mia, al momento in cui è stata presa la decisione, Wayland non sembrava muoversi abbastanza rapidamente sul mercato e la tecnologia Android esistente sembrava come una base più appropriata da cui lanciare il loro prodotto.