Plasma Workspaces 2 будет на Wayland, а KDM нет

И не должен требовать наличия определенного DE

Ты это уже 3й раз уже повторяешь. Может ты все таки ответишь почему.

Есть DE, и это DE нужно грузить и не просто грузить а предоставить большую кучу разнообразных плюшек. И для упрощения написания и уменьшения кода DM используются библиотеки DE для загрузки которой он был написан.

Почему DM не должен использовать либы DE, если эти либы все равно находятся на дичке?

И не должен требовать наличия определенного DE, которое может быть вообще ненужно пользователю.

Если ему не нужна DE для загрузки которой был написан DM. То пусть его и не ставит. Если он пользуется другим DE то пусть и ставит другой DM.

Почему нельзя воспринимать DM как часть DE? Если пойти дальше то можно требовать чтобы различные части DE были независимы от DE: Сраная панель от гнома! Какого она тянет за собой половину гнома? Я хотел использовать ее в КДЕ, нельзя было написать без привязки к гному?

ненужно пользователю

И ради этого юзкейса разработчики DM которые также яляются и разработчиками DE должны городить кучу костылей и изобретать велосипед? И все ради пользователя которому моча в голову ударила, и он решил что будет весело скрестить несколько частей различных DE.

Как пример - LightDM с lightdm-gtk-greeter и unity-greeter

Какой изврат, тулкитофобы на марше. Это мне напоминает людей. котрые вместо исправления багов в программе и наращивания функционала делают по 100500 морд к ней на всевозможных тулкитах.

Ох-хо-хо, вот и начались вялендоархитектуропроблемы.

Чтобы показать DM greeter, нужен вяленд (вялендокомпозитор), а чтобы запустить вялендокомпозитор нужен юзер, а чтобы получить юзера, нужно показать DM greeter, для которого нужен вялендокомпозитор. Эпичненько так, чо тут ещё сказать.

И если в X-ах от этой проблемы легко избавились, просто разделив функции рендерера, WM и собственно приложения, то в вяленде такой финт ушами уже не проходит, ибо совмещение функций WM и рендерера в одном процессе ВНЕЗАПНО вошло в конфликт с парадигмой multi-user системы.

Ну что сказать - теперь будет вялендокомпозитор-DM и вялендокомпозитор юзерский (kwin/gnome-shell/etc), в каждом будет по 100500 велосипедов и функционально дублирующегося кода, вялендокомпозитор-DM будет обрабатывать логин и запускать вялендокомпозитор юзерский... Ах, да, ещё ведь надо договориться о том, в каком виде это будет делаться...

Пионерия на марше во все поля.

вялендоархитектуропроблемы

И почему с этими проблемами ты решил именно ко мне обратиться? :-)

нужен юзер, а чтобы получить юзера

Использовать специального юзера для запуска user_dm например или как сейчас запускать от рута, в чем разница?

теперь будет вялендокомпозитор-DM и вялендокомпозитор юзерский (kwin/gnome-shell/etc)

Я что то вообще не понимаю тебя. В том что вялых-копозитеров может быть куча и есть прикол вялого. Их и так будет куча. Для DM можно использовать стандартный вестон и не нужно писать новый, в чем проблема я не пойму?

Кстати ЕМНИП всеми любимый systemD грозился запилить универсальный DM. Что я кстати считаю правильным. Помнится у них возникли проблемы с тем что не совсем был продуман механизм. Может они и придумают что нибудь универсальное.

Давно говорили же, что скорее всего будет общесистемный композитор, который будет заменять виртуальные терминалы, чтобы переключение между сессиями можно было, например, сделать с анимацией.

чтобы переключение между сессиями можно было, например, сделать с анимацией.

OH SHITTTT!!!!

Я плохо разбираюсь в графической системе, но вроде был разговор что в ядре хотели заменить тот эмулятор терминала что есть сейчас на тот что будет завязан на drm, kms.

Давно говорили же, что скорее всего будет общесистемный композитор

В том что вялых-копозитеров может быть куча и есть прикол вялого. Их и так будет куча

Вы бы уж между собой договорились, что-ли?

Ох-хо-хо, вот и начались вялендоархитектуропроблемы.

Ну да, конечно, лучше по старинке всё от рута пускать. Так точно никаких проблем.

А если я хочу после старта ДМ выбрать, что мне запускать? Может я захочу gnome под вэйландом, kwin под вэйландом или X-сервер? Вот мне ДМ и запустит то, что я хочу. А как запускать ДМ, вопрос второстепенный. Лишь бы обеспечивался необходимый набор возможностей ценой минимальных затрат. И вэйланд здесь ничем не хуже иксов.

Может я захочу gnome под вэйландом, kwin под вэйландом

В X11 эту задачу x display manager как раз и решал путём Xsession.

А самое смешное, это то что вяленд так и не избавился от ключевой и единственной проблемы X11 - падения приложений при падении X-сервера: теперь все приложения будут падать вместе с вялендкомпозитором, как раньше падали вместе с X-сервером. Молодцы, что ещё сказать.

А ведь могли бы сделать красивую архитектуру - системный менеджер буферов, который выдает буферы приложениям по и клиентам по запросу, при этом можно всегда реконнектнуться к приложению, в т.ч. и с нескольки «терминалов». Вся работа ведётся через shared memory, рендереры просто цепляются к серверу буферов и тот им отдаёт ссылки на буферы, после чего они как хотят так и рендерят, сетевая прозрачность реализуется тривиальнейшим способом.

Неет, будут городить 100500 велосипедов и идти по тем же граблям...

В X11 эту задачу x display manager как раз и решал путём Xsession.

Ну так иксы почти во всех дистрах от рута при этом запускались, даже при запущенной от юзера сессии. А при вяленном, надеюсь, сделают понижение привилегий и запуск уже от юзера. А то, что ДМ будет пускаться в отдельной вэйланд-сессии плюс к безопасности. Даже если пользовательскую сессию взломают, перехватывать пароли при логине будет сложнее, т.к. надо будет взламывать ещё и ДМ сессию. А ресурсы, кушаемые отдельным вэйландом на фоне того же QML по идее будут незаметны.

А ведь могли бы сделать красивую архитектуру

Боюсь что моей квалификации не хватит, даже чтобы обсуждать архитектуру графического сервера, но насколько я понял, вэйланд как раз подобным образом и работает. Выдаёт клиенту буфер, куда он отрисовывает картинку, после чего он совмещает буфера в рамках своего дисплея. А вот при реконекте к упавшему серверу по твоей схеме не ясны вопросы безопасности. Как узнать какие данные какому приложению отдавать. Плюс как узнать у какого приложения был фокус, где оно располагалось, буфер обмена и прочие штуки. Часть из них можно спросить у пользователя (например заставить выбрать активное окно и его расположение), но если совсем безконтрольно позволить приложениям восстанавливать соединения туда, куда они захотят, это может быть небезопасно.

Например, браузер взломали, он по свежим уязвимостям уронил вэйланд, после чего, притворившись, например, Virtual machine manager`ом, запросил рутовый пароль, пользователь его ввёл и всё, рут в кармане.

Плюс к вышесказанному, вэйланд ещё много чем занимается. Кто-то из разработчиков иксов в срачах про мир говорил, что вывод графики, это меньшая из обязанностей графического сервера.

Тут давеча Mir девелопер как раз говорил что клиентские буфера главное что им не подошло в вяленом.

Ну так иксы почти во всех дистрах от рута при этом запускались

От рута они пускались в основном потому, что несли в себе драйверы.

Mir девелопер

А можно поподробнее, а то я как-то упустил критику вэйланда со стороны мира, от которой в дальнейшем не отказывались.

А по остальным пунктам есть что?

От рута они пускались в основном потому, что несли в себе драйверы.

Ну ДМ в любом раскладе надо от рута запускать, чтобы он мог от имени любого пользователя сессии запускать, или городить костыли с повышением привилегий и их дальнейшим понижением. А дальше можно было бы стартовать Х-ы от пользователя, но с этим возникает гора проблем, в том числе отсутствующий KMS в пропиетарщине.

Ну ДМ в любом раскладе надо от рута запускать

В случае вяленда тоже.

https://plus.google.com/u/0/113883146362955330174/posts/PXc93m8nKwk

Ну там особо критики нет, просто объясняют как они дошли до жизни такой.

А дальше можно было бы стартовать Х-ы от пользователя

«X-ы» можно вообще от nobody стартовать, внезапно.

А по остальным пунктам есть что?

Ну вот когда вы договоритесь насчет количество композиторов, стратегии запуска DM, стратегии инициализации пользовательской сессии и самое главное насчет стандартов на всё это, вот тогда и будут вопросы. А пока что вяленд выглядит как унылое дерьмо даже на фоне динозавра X11,

В случае вяленда тоже.

Естественно. Просто в изначальном посте это как недостаток выставлялось.

«X-ы» можно вообще от nobody стартовать, внезапно.

А вэйланда нельзя?

Архитектура вейланда как раз и предполагает возможность использования вложенных композиторов. Например рисовалка трея (х11 стайл) — композитор, запущенный в композиторе de, запущенном в композиторе сессий.

количество композиторов

Много, вестон референсный дизайн.

стратегии запуска DM, стратегии инициализации пользовательской сессии

Почему они должны отличаться от текущих в иксах? В Иксах вон уже 100 лет как хотят от рута отвязать, и до сих пор все плохо.

стандартов на всё это

А сейчас есть стандарт? Или просто одна реализация?

А пока что вяленд выглядит как унылое дерьмо даже на фоне динозавра X11,

Смотря в чьих глазах, в твоих да, в глазах разработчиков иксов и вялого(в принципе одни и теже люди) нет.

Перед тем как писать мне пойми что на вялый и иксы мне пофиг. Ты выдернул меня из контеста беседы с shatsky и начал доказывать что вялый тебе не нравится. Мне как пользователю все равно что там будет что вялый, что мир, что иксы. Что станет апстримом на то и перейду. Мне со стороны кажется что люди просто привыкли к старым написанным 1000 лет назад костылям и готовы спорить то хрипа лищь бы не отказываться от старых костылей. Правда я могу допустить тот вариант что отказываться приходится не в сторону прямого решения а в сторону таких же костылей.

Мне например нравится идея разработчиков системд, возложить функции загрузки ДЕ на систему инициализации(процессы ведь схожи). Может это решение и позволит избавиться от такого костыля как DM? А логин менеджер был бы модулем к системд. Только давай без ненависти к леннарту, если не нравится ситемд подставь в место нее любую другую систему инициализации.

В Иксах вон уже 100 лет как хотят от рута отвязать, и до сих пор все плохо

X-серверу root не нужен. Xvfb, Xrdp, Xpra и 100500 реализаций X-серверов под винду.

А сейчас есть стандарт? Или просто одна реализация?

Сейчас есть как минимум фактический стандарт (Xsession).

Мне например нравится идея разработчиков системд, возложить функции загрузки ДЕ на систему инициализации

А мне нет. Потому, что юзерская сессия и жизненный цикл системы пересекаются только у одминов локалхоста. Поттеринг на тебя плохо влияет - он «тактично умалчивает», что «сессия» может быть не только локальной.

Много, вестон референсный дизайн.

Судя по всему, ты путаешь «много реализаций» и «много экземпляров».

количество композиторов

Много, вестон референсный дизайн.

Неважно, сколько композиторов лежит на складе. Важно то, сколько могут работать одновременно.

пойми что на вялый и иксы мне пофиг

...и работаешь ты в венде?

Правда я могу допустить тот вариант что отказываться приходится не в сторону прямого решения а в сторону таких же костылей.

Других. Более коротких и разной длины.

X-серверу root не нужен

А почему же он тогда в дистрибъютивах до сих пор запускается от рута.

А мне нет. Потому, что юзерская сессия и жизненный цикл системы пересекаются только у одминов локалхоста. Поттеринг на тебя плохо влияет - он «тактично умалчивает», что «сессия» может быть не только локальной.

А подробней? В чем моя логика не верна? А на сервере зачем запускать иксы и ДЕ? Насчет локалхоста ты прав, я не админ и поэтому сужу по нему.

Судя по всему, ты путаешь «много реализаций» и «много экземпляров».

Да путал. Выше вроде писали что можно, но я не знаю.

...и работаешь ты в венде?

Запустил вот я например фирефокс, открыл в нем тубе8.ком и давай работать. Какая мне разница что там под фирефоксом иксы или вялый.

Я не об этом спрашивал.

X-серверу root не нужен.

Нужен для работы UMS-видеодров. И по факту Х-ы везде запущены от рута.

А мне нет. Потому, что юзерская сессия и жизненный цикл системы пересекаются только у одминов локалхоста. Поттеринг на тебя плохо влияет - он «тактично умалчивает», что «сессия» может быть не только локальной.

И какие проблемы здесь у вэйланда, и тем более системд, который проблемы multi-seat`а призван решить? Каждому пользователю, что локальному, что удалённому запускаем свой экземпляр композитора, с привилегиями самого пользователя. Пользовательская сессия закончилась, закончился и композитор пользователя. Все пользователи изолированы друг от друга.

Тогда я не понял тебя.

И ради этого юзкейса разработчики DM которые также яляются и разработчиками DE должны городить кучу костылей и изобретать велосипед?
Какой изврат, тулкитофобы на марше. Это мне напоминает людей. котрые вместо исправления багов в программе и наращивания функционала делают по 100500 морд к ней на всевозможных тулкитах.

Ядро DM с его фичами намного сложнее его UI. Если проводить аналогию с браузерами, то его можно сравнивать с движком рендеринга, но не с тулкитонезависимой частью конкретного браузера. Это и поддержка мультисита, и биометрии, и многие другие вещи. Использование DE-специфичных DM по умолчанию в крупных дистрибутивах приводит к дублированию работы по реализации поддержки подобных возможностей и к тому, что в разных DM появляются разные наборы фич, которые нельзя использовать одновременно. Например, Fedora озаботилась поддержкой мультисита через logind-systemd - в результате сейчас его умеет только GDM, потому что он у них по умолчанию.

И все ради пользователя которому моча в голову ударила, и он решил что будет весело скрестить несколько частей различных DE.

Избавься от стереотипа «одна система, одно DE, один пользователь».

Если ему не нужна DE для загрузки которой был написан DM. То пусть его и не ставит. Если он пользуется другим DE то пусть и ставит другой DM.

Ни одному из моих пользователей не нужен Gnome, нужны KDE, LXDE и мультисит. Ради поддержки последнего приходится использовать GDM (см. выше) и держать большую часть гнома. Это много лишних пакетов, а значит - потенциальных проблем с зависимостями.