Для чего практически полезен D -Bus?

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

«Традиционный» способ межпроцессного взаимодействия (IPC )в системах UNIX и Linux напрямую использует сокеты, например. процесс A открывает /var/run/a.socket, а процесс B читает/записывает в него. Это хорошо работает для -тесно связанных программ, предназначенных для совместной работы.

Тем не менее, вы можете захотеть иметь связь между процессами двух программ, где программы B даже не существовало, когда программа A была написана. D -Bus пытается решить эту проблему, предоставляя протоколы для связи и обнаружения служб. Таким образом, только интерфейс b должен был существовать, когда A был написан, а процесс B реализует интерфейс b.

Таким образом, вы можете описать шину D -как "менеджера" IPC.

Исторически сложилось так, что командный -линейный интерфейс (CLI )инструменты обычно также используют диспетчер IPC, оболочку, для связи с произвольными программами с использованием каналов. Проблема с этим подходом в том, что он не обеспечивает проверку данных,стандартизированные протоколы и т. д. Таким образом, его могут использовать только опытные пользователи. Инструменты с графическим интерфейсом в целом должны делать это «невидимо». Однако все больше и больше инструментов CLI начинают использовать шину D -в значительной степени как альтернативу sudo(1). Таким образом, вы можете сделать, как непривилегированный пользователь, выполнить systemctl poweroff, и он предложит вам пройти аутентификацию (, это можно сравнить с UAC в Windows ). В зависимости от вашего поставщика polkit это может быть даже приглашение графического интерфейса. По крайней мере, теоретически этот подход является более гибким и допускает более тонкие -детализированные привилегии и работает без двоичных файлов setuid (, таких какsudo). Это можно рассматривать как функцию безопасности.

Конечно, как абстракция, он вносит некоторую сложность (по крайней мере в зависимости программ ). Однако, чем больше программ (разумно )используют его, тем меньше это бремя. Нравится ли вам D -Bus и текущее развитие, я не могу вам сказать. Но современные операционные системы, как правило, предоставляют множество важных сервисов за пределами ядра (и теперь снова перемещают исторический материал ядра из микроядра -ish )из-за более сложных требований современных вычислений. Таким образом, если вы «просто» хотите «простой» терминал, все это может считаться «раздуванием», но индустрия требует его по уважительной причине, и все больше и больше разработчиков отмечают преимущества использования шины D -. Это сегодняшняя замена старой доброй трубы в вашей оболочке (, а не системного интерфейса, на самом деле D -Bus использует pipe()и т. д. ).

API специальных возможностей GNOME полагается на него; см. напр. AT -SPI2 на FreeDesktop.org . До D -BUS, то есть до GNOME 3, API специальных возможностей опирался на CORBA (Common Object Request Broker Architecture ), которая была очень переносимой, но и более тяжелой, чем D -BUS. (Страница AT -SPI on D -Bus (архивный снимок)содержит историческую информацию об этой миграции.)

Доступность требует связи между приложениями, с одной стороны, и вспомогательными технологиями, с другой. Например, слепые пользователи компьютеров полагаются на программы чтения с экрана, которые могут отображать информацию с помощью синтетической речи или шрифта Брайля (или того и другого ). Слепые пользователи используют клавиатуру для доступа к приложениям (, например. использование TAB для переключения между компонентами пользовательского интерфейса и множеством ярлыков ); программа чтения с экрана должна знать, где находится фокус клавиатуры, а затем запросить этот компонент пользовательского интерфейса для его роли (, например. "кнопка", "меню", "флажок" и т. д. ), имя (, т.е. его метка, например. «ОК», «Отмена» ), а также состояние и свойства (, например. «отмечено» и «не отмечено» для флажков, «расширено» для расширяемых областей, «обязательно» для обязательных полей ввода, «отключено» и т. д. ). Программа чтения с экрана также должна получать push-уведомления, отображаемые в приложении.

Диаграмма на странице Знакомство с ATK, AT -SPI, GAIL и GTK+ отображает AT -SPI как уровень между прикладным уровнем и вспомогательной технологией (AT )слой.

AT -SPI также поддерживается в Qt , что упрощает разработку доступных приложений.

Параметр NO_AT_BRIDGE=1(, упомянутый в вопросе ), отключает мост, который вспомогательные технологии используют для связи с приложениями. (См. jeffcogswell/org _ally1 _bus _fix.md .)

• Я включаю hidepid , который должен сломать dbus.
• Я также меняю уникальный machine-id, который dbusгенерирует при каждой загрузке черезrc.local(devuan также генерирует его при каждой загрузке)

Кажется, все по-прежнему работает в XFCE (некоторые рабочие столы, например gnome, могут больше зависеть отdbus). Я запускаю приложения через firejail , поэтому потеря каких-либо предполагаемых преимуществ безопасности от dbusна самом деле не является проблемой.

Следующие дистрибутивы Linux нормально работают без dbusиsystemd:

• devuan(На базе Debian)
• artix(на базе Arch Linux)
• антикс(на основе Debian)

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