Мартин в своем блоге Mir in Kubuntu с ноткой неприятия пишет о своём видение будущих проблем. Нельзя сказать на 100% что он прав, местами он реально ошибается. В общем, мне такому спецу мало что можно сказать и возразить, но его предвзятость видна сразу.
Дальше своих реплик не вставляю и текст идёт от лица Мартина, который является профессиональным разработчиком, который, как и любой другой, имеет право на свою точку зрения.
Как вы могли видеть в блоге Джонатана Notes from Breakout sessions at Mataro Sessions II, мы уже успели обсудить тему Mir в Kubuntu на Mataro Sessions II. Эту тему я предпочёл бы не обсуждать вообще. Но динамика в мире свободного программного обеспечения заставляет нас обсудить этот вопрос.
Очевидно, что наш downstream должен знать, почему мы, upstream, не считаем поддержку Mir правильным ходом.
Это освещает ту огромную проблему, созданную Mir от Canonical. Я не могу просто сказать: "Canonical отстой". Я должен предоставить технические аргументы, почему мы не будем работать над интеграцией с Mir.
Я потратил время на выявление различий между дисплейными серверами, их плюсы и минусы. Получив аргументы, решил поделиться ими в блоге.
Дискуссия началась во время презентации о X11 и Wayland нашими коллегами из Blue Systems. Я решил вначале объяснить X11, так как никто не поймёт необходимость в Wayland без понимания работы X11.
Я не хотел задевать Mir, но нить дискуссии металась и вопросы так или иначе касались плюсов и минусов Wayland против Mir. Кто-то после произнёс напыщенную речь об Ubuntu и Canonical. Спустя пару недель, мы уже обсуждали "Mir в Kubuntu" более подробно, пытаясь найти ответы на многие вопросы, которые тащат нас вниз.
Введение.
Крушение планов и потеря мотивации.
Прежде чем вдаваться в детали, я хочу прояснить одну вещь: Canonical имеют право разрабатывать то, что они хотят. Меня не тревожит что это. Новый ли дисплейный сервер, собственное ядро или оболочка. Это деньги Марка или Canonical и они могут инвестировать их туда, куда сочтут нужным. Меня даже не волнует будет ли это закрытое ПО. Всё отлично!
Вот что точно не отлично, это когда Canonical мутит воду в свободном мире программного обеспечения своими ложными техническими аргументами и делает смелые заявления о своём ПО, которое не соответствует действительности.
Это не приемлемо! Это было печально слышать, теряя доверие к Canonical. Теперь сложнее восстановить это самое доверие. Canonical должна быть рада, что это мир свободного ПО, а не обычный корпоративный мир. Некоторые высказывания Canonical в корпоративном мире подняли бы по тревоге юридический отдел.
Это коснулось и меня, что заставило задуматься, а часть ли я свободной экосистемы программного обеспечения. Вместо того, чтобы работать вместе, мы имеем ситуацию, когда части экосистемы стали конкурентами и порочат друг друга и всю систему. Очень печальная ситуация.
Конечно, есть серьёзные причины для разработки Mir. К сожалению, аргументы не были представлены до сих пор. Я совершенно уверен, что знаю причины по которым они отсутствуют. Если бы аргументы были представлены сразу - это всё бы упростило для других проектов и команд. Не было бы обид и разочарований, когда впервые анонсировали разработку Mir.
Не нужно было бы что-либо обсуждать, потому что многие вопросы отпали сами собой. Но Canonical решила вместо реальных технических аргументов выдвинуть ложные.
Не готова.
Нужно помнить, что на данный момент Mir не готов. С времени его анонса, у нас нарисовались 4 пути развития:
- Продолжать план Wayland и игнорировать Mir.
- Переключиться на Mir и игнорировать Wayland.
- Поддерживать Mir и Wayland.
- Подождать когда Mir будет готов.
Если на временную шкалу разработки Plasma Workspaces 2 наложить шкалу Mir, то я не вижу перекрытий. Мы хотим поддержать Wayland до той поры пока Mir будет готов. Ждать готовности Mir плохая идея. Это отбросит нас назад. Всё вместе означает так же, что второй выбор "Переключиться на Mir и игнорировать Wayland" совсем не вариант и реальными путями остаются поддержать оба проекта Mir и Wayland или только Wayland.
На данный момент кодовая база не готова разрешить вопрос "поддержать Mir в дополнение к Wayland" это правильный подход или нет? Последний раз проверяя кодовую базу, я удалил несколько заглушек, чтобы оценить масштаб трагедии и, честно говоря, всё выглядит печально для Mir.
Wayland против Mir.
Возможные плюсы Mir над Wayland.
Различия между Mir и Wayland довольно минимальны. Одним из отличий является то, что Mir использует выделение памяти под буфер на стороне сервера (server allocated buffers), тогда как Wayland использует клиентскую сторону (client side buffer allocation).
Я не могу судить, является это преимуществом или недостатком. Но в этом вопросе я больше доверяю Kristian и команде Wayland.
Другим отличием является использование Mir'ом методологии "Разработка через тестирование (test-driven development, TDD)". Для меня выбор методологии программирования не является техническим аргументом. Я предпочитаю использовать рабочую систему без юнит-тестов, чем систему с юнит-тестами, но не работающую. KWin так же не использует TDD. Если я хотел считать TDD лучшим, то должен бы поставить под сомнение свою собственную методологию разработки.
Вот, собственно, все плюсы что я нашёл для Mir.
Под недостатки я отведу целый раздел с подпунктами.
Привязанный к дистрибутиву.
Mir - это привязанное к одному дистрибутиву решение. Никто из других дистрибутивов не проявил к нему никакого интереса, даже если Mir станет рабочим вариантом. К сожалению, у меня нет возможности заглянуть в будущее, но я могу использовать прошлое и настоящее, чтобы получать идеи для будущего.
Прошлое говорит мне, что есть у Canonical свои решения, не доступные в других дистрибутивах. Я не слышал ни об одном дистрибутиве с Unity, но слышал даже, что не возможно упаковать Unity в "не Ubuntu".
Вполне вероятно, что Mir пойдет этой же дорожкой. Он создан для Unity и если нет дистрибутива "не Убунту" с пакетом Unity, то не будет и пакета Mir. Такие вещи могут повлиять на возможное итоговое решение!
Я не знаю ни одного разработчика kde-workspace, использующего Kubuntu. Я не представляю, как кто-либо мог в Kubuntu быть в состоянии просматривать код или даже мантейнить его.
Это означает, что все принятые правки должны быть в секциях ifdef, которые никто не будет компилить и запускать. Это отличный способ начать деградировать.
Более того, наша Continuous Integration (CI) система, работающая на OpenSUSE, не сможет обнаружить возможные поломки. Конечно, Kubuntu разработчики могут сами создавать патчи и применять их к основному проекту, но я очень рекомендовал бы не делать этого. Исходный код KWin очень изменчив. Мы в команде считаем, что патчи к проекту - это зло. Мы не сможем помочь в будущем пользователям таких дистрибутивов.
Архитектура.
Архитектура Mir сосредоточена вокруг Unity. Реально трудно понять архитектуру Mir из спецификации, так как она полна модных словечек, которых я не понимаю.
Из всего что я видел, можно понять, что Unity Next - это комбинация оконного менеджера (window manager) и оболочки рабочего стола (desktop shell), работающие поверх Mir. Как именно всё будет работать на практике, я не знаю.
В любом случае, это не соответствует нашему дизайну, где оболочка и оконный менеджер разделены и мы не знаем, будет ли Mir поддерживать это.
Мы так же не знаем, позволит Mir использование другой оболочки, кроме Unity Next, учитывая что это его основная цель.
Wayland с другой стороны рассчитан на более чем одной реализации его композиционного менеджера окон (или compositor, композитор). Использование KWin, как Session Compositor, указано даже как в вики как пример.
Лицензия.
Wayland лицензирован, как и X, под MIT лицензией. Я думаю, что это хороший выбор, и я рад, что разработчики Wayland решили так же. Mir лицензирован под GPLv3-only c Contributor License Agreement (CLA). Я считаю, что это не очень подходит для такой части стека и делает рискованным для KDE Plasma.
Я не считаю, что нужно зависеть от ПО под GPLv3-only любой основной части нашего стека проекта KDE.
Это окажет серьёзную угрозу в будущем с GPLv4, которая не совместима с GPLv3. Ещё я не люблю CLA.
С точки зрения лицензирования, Mir не приемлем.
Нет протокола и специфично для Unity.
Одним из наиболее важных аспектов для нас является способность протокола к расширению. Это также было особенностью X и мы использовали наши собственные расширения к ICCCM и EWMH для реализации дополнительных возможностей.
Mir не имеет реального протокола. "Внутреннее ядро" описывается как "независящий от протокола" (protocol-agnostic). Наша архитектура другая и нам нужен протокол между оболочкой (desktop shell) и compositor'ом. Если Mir не предоставляет протокол, то мы должны использовать свой протокол. И он существует и называется Wayland. Так что? Если мы будем поддерживать Mir, нам нужен протокол Wayland? Это какая-то бессмыслица для меня. Если нам нужно запустить Wayland поверх Mir только для того, чтобы получить нужные нам возможности, зачем нам запускать Mir вообще?
Но есть хуже вещи. Протокол между сервером Mir и клиентами Mir не стабилен. Уверяю вас, он не раз будет сломан. Это огромная проблема, я даже назвал бы - системная ошибка (showstopper). Canonical'у хорошо - они контролируют полный стек и могут подкрутить свои битики, используя протокол типа QMir.
Для нас всё выглядит сложнее. Учитывая, что протокол может измениться в любое время и что всё создано под Unity, мы должны быть готовы, что старая версия библиотеки со стороны сервера не может разговаривать с библиотеками клиентской части. Мы должны будем постоянно отслеживать эту нестабильную и ломаемую базу.
Я знаю, что это звучит слишком пессимистично, но есть один случай, когда Canonical позднее ввела изменения в цикл выпуска релиза и это сломало работу приложений Kubuntu. С учётом этого печального опыта, я не стал бы надеяться, что Canonical больше не будут что-либо менять за один день до выхода Kubuntu.
KWin не будет нормально работать над Mir'ом.
Я надеюсь, что это всё ясно показывает, что Mir для KDE Plasma не вариант. Нет никаких преимуществ, которые делают Mir лучше, чем Wayland. Наоборот, есть препятствия, которые означают, что нам не по пути с Mir, даже в дополнении к Wayland.
Нестабильный протокол и выбор лицензирования - это всё неприемлемо.
Что это всё значит для Kubuntu.
Вопросительные знаки.
Переключение интереса Canonical на Mir создало для Kubuntu массу вопросов. На один из них я ответил: "Upstream не заинтересован в поддержке Mir и не принимает патчи для его поддержки".
Как графический стек Kubuntu будет работать, когда KDE не поддержит Mir, а Canonical переключается на Mir?
На этот вопрос нельзя ответить прямо сейчас и это плохо.
Исправления стека.
Ubuntu всегда обладала худшим графическим стеком в мире свободного программного обеспечения. Я вижу это по трекеру ошибок. Качество стека Mesa в Ubuntu тоже плохое.
Ubuntu для Мира придётся пропатчить стек Mesa ещё сильнее. Это то, что я хочу видеть меньше всего.
Mesa так же должна поддерживать Wayland. Но будет ли Canonical делать это? Если нет, то Kubuntu должна обладать своим стеком Mesa?
Что если изменения от Canonical настолько велики, что стандартный стек Mesa не будет работать c Ubuntu стеком?
Переключение сессий.
Одно из преимуществ свободного ПО в том, что можно выбрать рабочую среду при входе в систему. Это похоже будет не возможно в Mir'е. Unity будет запущена с системным compositor'ом Mir и LightDM будет "вложен снизу".
Нам понадобится либо X Server или системный compositor Wayland.
Из менеджера входа в систему нельзя будет начать сессию, под другим системным compositor'ом.
Запуск Unity и KDE Plasma (или Gnome, Xfce и тд) сессии в одно и тоже время будет невозможен.
Системный compositor.
Как глубоко в системе будет зарыт системный compositor?
Можно ли будет отключить системный compositor Мир и заменить на X или Wayland?
Что делать если пакеты начнут конфликтовать?
Будет ли возможность установить Kubuntu и Ubuntu на одной системе?
Будет ли Canonical заниматься и беспокоится этим вопросом?
Пакеты.
Пока Canonical пакует X, Wayland, Mesa. Но как насчёт будущего? Оставят ли X, будут ли делать пакет Wayland? Если нет, то где взять? Debian не стабилен, но может быть заморожен. Удастся ли использовать Debian пакеты для X и Wayland в Убунту стеке? Будут ли они отвечать требованиям KDE Plasma? Если Canonical не будет обеспечивать пакеты Wayland и они пропадут из universe, то Mesa в main не сможет зависеть от них. Как получить Mesa с поддержкой Wayland?
Будущее покажет.
На эти вопросы нельзя ответить прямо сейчас. Нужно подождать пока Mir будет интегрирован в стек Ubuntu. Тогда разработчики Kubuntu увидят как сильно стек сломался. Я не оптимистичен в прогнозах для ответвлений Убунту, когда переход на Mir закончится. Я не думаю, что Canonical интересны ответвления Убунту, сделанные сообществом вне стен компании. Я вижу небольшие изменения в этом направление, хотя, может быть, я слишком пессимистичен и время покажет.
Это снова я и мои осторожные комментарии.
- Прошу отписаться в комментариях о вашем мнении.
- Мартин приводит как аргумент блог Notes from Breakout sessions at Mataro Sessions II и что там видим? Рабочие моменты от разработчиков Kubuntu, которые создают рабочее настроение без всякой паники Мартина. Трудно понять, что такое видит в будущем разработчик КДЕ, чего не видят разработчики Kubuntu.
- Мартин в блоге сильно напирает на милую его сердцу мысль, которую он сам себе нарисовал, что Mir и Unity Next это такой неразрывный моток, который не размотать и не понять.
Хотя в спецификации, которую якобы читал Мартин ясно написано, что Mir специально отделён и не связан с Unity Next неразрывными нитями. И тут же Мартин делает странный намёк, типа никто не проявил интереса к Миру. Блин, да он ещё разрабатывается! Его выход будет в 2014 году и не факт, что не перенесут для шлифовки еще дальше в будущее. Потом ещё пару лет, чтобы к нему присмотрелись. Мартин хочет уже сейчас Mir в SUSE?
- Мартина волнует вопрос о Wayland в Ubuntu и проблема Mesa + Wayland. Но библиотеки Wayland уже давно в Ubuntu 13.04! Зависимость от Wayland началась с libegl1-mesa и с программ Empathy и Totem. Если вы удалите libwayland0, то удалятся и эти два приложения. Маловероятно, что в будущем можно так просто вырвать libwayland из системы и кто-то будет это делать в Canonical.
- Мартин не видит плюсы и явно с сарказмом приплетает плюсом пародию на Марка про потрясающий (awesome), но с живостью расписывает минусы. У него Wayland такой замечательный и хороший, но если вспомнить слова Линуса Торвальдса про я верю в рабочий код, то достаточно вспомнить, что Mir уже работает и на Андроид платформе и на обычной десктопной. Уже сейчас разработчики Ubuntu выкладывают видео или планшета с процессором ARM, где Mir и Unity показывают начальные результаты. А вчера выложили видео, где ноутбук с процессором x86 обрабатывает Mir + Unity 8.
У проекта KDE Plasma Active (проект KDE, предоставляющий модульную UX платформу для устройств различных форм-факторов типа планшеты, смартфоны, трансформеры) было время вырваться вперёд и в 2014 году всё станет окончательно ясно - Ubuntu + Mir или KDE + Wayland.
- Очень сильно видна предвзятость в техническом вопросе о размещении буферов на серверной стороне (как делает Мир) или клиентской (так делает Wayland). Мартин корит Canonical о недостаточном техническом раскрытии деталей в спецификации и сам же наступает на эти же грабли ... Я не могу судить, является это преимуществом или недостатком. Но в этом вопросе я больше доверяю Kristian и команде Wayland. Класс! Я просто доверяю мнению любимого проекта и всё ... давайте дальше.
Мнение Мартина ценно, но для меня очень важно, что не менее крутые разрабы занимаются тем, что у Мартина вызывает пессимизм.
История рассудит - кто был прав, а кто ошибался. Пишите свои мысли - страсть как интересно! За перевод сильно не бить, я старался. 
Дополнительные материалы:
Unity 8 уже работает через Mir.
Mir и Android GPU.
Небольшой FAQ от Kevin, который поможет разобраться в Mir и Ubuntu Touch.
Зачем Canonical создала Мир? 5 причин от Кристофера Роджерса.
Wayland, Mir, X - разные проекты.
Немає коментарів:
Дописати коментар