Чому компанія Canonical обрала Mir over Wayland в якості сервера відображення?

Мені подобається знати, у чому переваги Міру.

Чому б не Вейленд / Вестон?

Спочатку очевидне уточнення: Wayland - це визначення протоколу, яке визначає, як клієнтська програма повинна спілкуватися з компонентом композитора. Він торкається таких областей, як створення / руйнування поверхні, розподіл / управління графічним буфером, обробка подій вхідних даних та приблизний прототип інтеграції компонентів оболонки. Однак наша оцінка визначення протоколу виявила, що протокол Wayland не відповідає нашим вимогам. По-перше, ми прагнемо до більш розширюваної обробки вхідних подій, яка враховує майбутні розробки, такі як пристрої введення 3D (наприклад, Leap Motion). Зауважте, хоча, що вхідні події Wayland не потерпають від проблем безпеки, введених семантикою обробки подій X (вдячні Даніелу Стоун та Крістіану Хегсбергу за те, що вони це вказали). Що стосується випадків мобільного використання, ми вважаємо, що обробка методів введення має відображатися і в протоколі сервера відображення. Як інший приклад, ми розглядаємо частини інтеграції оболонки протоколу як привілейовані, і ми краще уникати будь-яких типів поведінки оболонки, визначених у протоколі клієнта.

Однак ми все ще вважаємо, що спроба Вейленда стандартизувати зв'язок між клієнтами та компонентом сервера дисплея є дуже розумною та корисною, але завдяки різним вимогам ми вирішили перейти до наступної архітектури wrt до інтеграції протоколів:

Протокольно-агностичний внутрішній стрижень, який надзвичайно чітко визначений, добре перевірений і портативний. Зовнішня оболонка разом із фронтендом-брандмауером, що дозволяє нам перенести наш сервер відображення до довільних стеків графіки та прив’язати його до декількох протоколів.

Підсумовуючи це, ми не вибрали Wayland / Weston як нашу основу для надання користувачеві нового класу, оскільки це не повністю відповідає нашим вимогам. Більше цього, завдяки нашому підході до протокольного та платформового підходу ми можемо переконатися, що ми досягнемо своєї мети послідовного та красивого досвіду роботи користувачів на платформах та факторах форми пристрою. Однак підтримка Wayland може бути додана або шляхом надання конкретної для Wayland реалізації інтерфейсу для нашого сервера дисплеїв, або шляхом надання клієнтської реалізації libwayland, яка врешті-решт спілкується з Mir.

Тут є більш детальна дискусія: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

І від Мірського технічного архітектора:

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

Більше інформації:

• 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

Джоно Бекон на свої питання "Q" відповів на це кілька разів. Його остання відповідь тут:

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

З того, що я зібрав із подібних запитань Jono's Q&A та коментарів Попея щодо Linux Unplugged, моменти можна підсумувати так:

1. Вейленд робить занадто багато. Постійно невикористані функції у вашому стеку програмного забезпечення є поганим дизайном програмного забезпечення.
2. Команда Wayland не буде достатньо гнучкою, щоб запропонувати витягнуту версію Wayland, щоб вмістити її адекватно, з повагою.
3. Mir - це Wayland, що LightDM - це GDM / KDM.
4. Ubuntu має дуже важкі терміни, що їм потрібно зустрітися з виробниками телефонів тощо. Контроль над проектом полегшує використання додаткових ресурсів, щоб гарантувати дотримання цих строків.
5. Хоча я не думаю, що ця причина ніколи офіційно не виходила з канонічної, і тому це лише спекуляція з мого боку, в той час, коли було прийнято рішення, Wayland не здавався, що він рухається досить швидко на ринок, і існуюча технологія Android здавалася як більш підходяща база для запуску свого продукту.