Почему дистрибутивы Linux не отказываются от D-Bus

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

DBus как протокол всех устраивает.

Кроме разработчиков Android. И это проблема.

Из этих утверждений вытекает естественное подозрение, что именно у разработчиков Android что-то не так…

Наоборот же. Андроид – единственный успешный Линукс для обычного пользователя.

Ну так успешный не значит хороший.

Успешность – следствие принятия правильных решений и проработанных технологий. В Android не просто так не используются X11, Wayland, D-Bus, systemd, glib и прочее.

Какие преимущества у Binder перед d-bus, кроме того, что его написал швятой Гугл?

Binder написала Be Inc. которой уже нет. Гугл уже потом взял.

Потому что почти никто кроме авторов binder до конца не понимает, как оно работает в отрыве от андроидных java библиотек.

Гугл нанял всю команду, и они переписали реализацию с нуля вроде бы.

dbus это просто протокол поверх стандартных unix сокетов. В binder помимо этого ещё есть какое-то кастомное управление ресурсами (в какой момент что закрыть когда процесс упадёт), поэтому требует дополнительной модификации ядра.

Но у kernel dev есть предположение, что многое из binder можно реализовать не хуже без патча существующими средствами, просто авторам было проще написать жирный патч. А анализ «можно ли минимизировать kernel интерфейс binder» без потери его свойств – никто не проводил.

А за пределами мобилок существует лютое количество эмбеднутого говна, слепленого из говна, палок, содомии и глухой ненависти.

Но ты его увидишь только когда оно тебя убьёт.

https://github.com/maandree/bus

«Вот когда убьют, тогда и приходите» (c) классика жанра от оборотней в погонах

Нет, это следствие бабла и влияния у гугла. Конечному пользователю плевать на x11, systemd, glib и прочее. Он и слов таких не знает.

DBus замусоривает линуксовые системы гномерскими зависимостями

это какими например?

Depends: dbus-bin (= 1.14.10-4), dbus-session-bus-common (>= 1.14.10-4), libapparmor1 (>= 2.8.94), libaudit1 (>= 1:2.2.1), libc6 (>= 2.34), libcap-ng0 (>= 0.7.9), libdbus-1-3 (= 1.14.10-4), libexpat1 (>= 2.1~beta3), libselinux1 (>=
         3.1~), libsystemd0

Потому что андроид это не «линукс» в виде «Дистрибутив GNU/Linux», а embedded os based on Linux kernel.

Разница в подходе - колоссальная, хотя казалось бы.

«линукс» в виде «Дистрибутив GNU/Linux»

Сейчас G там скорее означает GNOME, а не GNU.

даже если посмотреть на исключительно сам dbus, то - meson, куча glib, systemd и всякой гномовской мелочи в опциях сборки, инстанс естественно на gitlab, и т.п. и т.п.

А если посмотреть на цветущую и пахнущую вокруг этого экосистему, то там один сплошной гном.

А если посмотреть на цветущую и пахнущую вокруг этого экосистему, то там один сплошной гном.

Прямо как в анекдоте «А откуда у вас доктор такие картинки?».

куча glib, systemd и всякой гномовской мелочи в опциях сборки

в опциях

Успешность – следствие принятия правильных решений и проработанных технологий.

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

Интересно, что они в своей Фуксии используют для этого. Она там ещё не загнулась?

Фуксия в качестве десктопа всё.

Почему ты так считаешь?

https://dbus.freedesktop.org/doc/diagram.png схема приложения соединяются сокетами и есть ещё прокладка которая врядли ускоряет два раза сообщение пересылает и точно не упрощает коммутацию приложений с учётом что ещё валидацию utf8 проводит, мне ошибок в libc хватает, а это даже на примерах у меня сегфолтилось.

Ты разговариваешь как разработчик. Тебя волнуют только твои проблемы и не волнуют проблемы пользователей. Поэтому ты не видишь другие функции, которые тебе как разработчику не нужны.

задача которое решает dbus - копирование из одного userspace в другой userspace.. почему вы думаете что Binder дает меньше копирования?!

как раз таки через dbus дали возможность стандартизировать интерфейсы и не ломать протокол…

dbus - это еще и автостарт сервиса в другой сессии по требованию, давайте ваш вариант.

Потому что к D-Bus уже очень много чего прибито, например systemd

не прибили - а выбрали самое удобное, ваши варианты? Я могу кастомным сервисом к systemd шине приконнектиться и получать сигналы при старте/завершении пользовательской сессии (и получить всю доп инфу) например… как мне это сделать по другому?

Тебя волнуют только твои проблемы и не волнуют проблемы пользователей

ну озвучьте хотябы чтоли эти мифические проблемы пользователей…

ваши варианты?

Тот же Binder. Он ещё с нулевых годов существует. Но нет, у гномеров острое чувство NIH.

Кроме разработчиков Android. И это проблема.

Чья проблема? Разработчиков Android? Ну так проблемы индейцев, как говорится…

не знаю, автостарт сервиса наверно только для гнома и может кде, и есть куча инструментов для этого начиная с сустемд, кончая Х-сессией, вайлянд-сессии не знаю.

задача которое решает dbus - копирование из одного userspace в другой userspace.. почему вы думаете что Binder дает меньше копирования?!

tmux можно к общему сокету присоеденить, и в одну сессию разным юзарям ходить, mpd от разных пользователей работает да и от разных компьютеров через сокет работает, ssh X позволяет работать от разных пользователей и с разных машин Х-совую программу при пробросе сокета Х-сов.
Зачем чинить то что не ломалось? (сломать что до этого работало и долго чинить это как называется)
dbus это лишняя прослойка которая ничего не добавляет, не упрощает, а вот усложняет, да и с безопасностью не всё так просто, для сокетов ты выставляешь права как на файл, а в dbus попробуй ограничить прослушивание событий.
и причем тут Binder?

при старте/завершении пользовательской сессии

можно задействовать PAM, можно X-сы, можно сервисы ос, можно задействовать сигналы unix, D-Bus не всегда используется рассчитывать на него это ваш выбор

Ты бы ещё ICCCM вспомнил…
«Inter-Client Communication Conventions Manual, ICCCM) — стандарт X Window System, обеспечивающий интероперабельность X-клиентов в пределах одного и того же X-сервера. Впервые представлен Массачусетским технологическим институтом в 1988 году.»

можно X-сы

а, ну да…

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

Самый успешный это общение через сокеты самый технологичный, самый быстрый (может ещё в тестах fifo на мелких сообщениях обгоняет, mmap не такой безопасный и не переносимый), D-Bus и Binder это плесень на теле сокетов.

хммм с вашими шумами в голове спорить не буду, но на полях замечу, что все текущие реализации dbus работают через сокет

vitus@vitus-home:~$ ps aux | grep -i dbus | grep -i path
vitus       2062  0.0  0.0   9384  4712 ?        S    фев23   0:53 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/1000/at-spi/bus_0
vitus@vitus-home:~$ file /run/user/1000/at-spi/bus_0
/run/user/1000/at-spi/bus_0: socket

об этом я выше и говорил, dbus это усложняющая нашлёпка

Да мы поняли уже, что ты нихера не понимаешь в том, что тут несёшь, успокойся.

Отличный аргумент в пользу D-bus. Я как то сильно затрудняюсь вспомнить хоть что нибудь, что в андроиде реализовано хорошо.

Искренне прошу прощения, что несколько оффтоп, но вот вы весь тред говорите, что dbus не нужен, так что вопрос к вам. Как реализовать API по типу MPRIS без «прослоек» между сокетами и конечными приложениями, с сохранением всех фич?

Просто лично я не представляю, было бы чудесно, ежели кто-либо разъяснил :)

есть mpd прекрасно работает и управляется без MPRIS и есть ли в MPRIS команды создания плейлиста и выбора через какое устройство играть

mpd прекрасно работает и управляется без MPRIS

Рад за mpd, но я поставил несколько иной вопрос :)

создания плейлиста

Задачи протокола MPRIS куда более простые — организовать простое управление любым плеером из любой DE или хоть из консоли. Это удобно, что не надо для каждого приложения настраивать глобальный хоткей, достаточно стандартного для DE.

выбора через какое устройство играть

Это задача аудиосервера (PulseAudio, Pipewire, etc)

Просто лично я не представляю, было бы чудесно, ежели кто-либо разъяснил :)

а что тут в принципе можно не представить? Подключаешься к сокету, шлешь туда сообщения, читаешь ответы. ssh-agent так работает например, простенький текстовый протокол. Реализован много где, от gpg и pam до putty и keepassxc.

любой DE

мой DE xfce не поддерживает MPRIS зато поддерживает mpd да и в conky об MPRIS не слышали в отличие от отображения mpd трека

хоть из консоли

я в случае чайника-кофейника, в консоли спокойно набираю, а можно по окончании компиляции запустить

sleep 5m;mpc pause;beep;mpc play

Это задача аудиосервера (PulseAudio, Pipewire, etc)

не даром из плеера гнома регулятор выкинули, я же могу с любого плеера сказать играй по http каналу через сеть на телевизоре в другой комнате, и регулировать громкость.
Клиенты к сокету mpd стоят на телефонах, периодически с дочерью идут войны за любимые треки.
Зачем мне юзать ограниченный d-bus, если гибкий удобный сокет mpd в моём распоряжении.

мой DE xfce не поддерживает MPRIS зато поддерживает mpd да и в conky об MPRIS не слышали в отличие от отображения mpd трека

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

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

Хорошо, не представлял, что у mpd настолько широкие возможности, буду знать, спасибо! (без сарказма)

Я, увы и ах, на данный момент пользуюсь cmus. Он, как и большинство аудио- и видеоплееров, в т.ч. браузеров, позволяет управлять им по протоколу MPRIS, общение по которому идёт через D-Bus. Этот протокол также интегрирован с KDE Connect, так что с мобилки я могу поставить на паузу, промотать трек, порегулировать громкость, поменять вывод (основано на аудио-серверах) плеера. Меня вполне это устраивает, как и многих людей, так что точно не «не нужно» :)

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

Ну они совсем в крайность ушли :) Полезно иметь уровень громкости внутри аудиоплеера, как минимум ради ReplayGain.

Зачем мне юзать ограниченный d-bus, если гибкий удобный сокет mpd в моём распоряжении.

Сокет mpd поддерживает только mpd, может быть, ещё полтора плеера. MPRIS же почти везде :)

а что тут в принципе можно не представить?

Я не могу представить централизованное управление несколькими плеерами из нескольких мест при помощи чистых сокетов без строгой иерархии :)