> Но зачем? dbus это гномовский аналог dcop из KDE 2/3, и по-идее, если у вас не GNOME...
> ...Что она даёт?

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

Такая штука как dbus не видна ни пользователю, ни системному администратору, потому что сделана она не для них. Это для программистов.
Пусть есть 3 приложения (разные процессы).
Приложение 1 необходимо воспользоваться функционалом приложения 2
Приложение 3 должно отреагировать когда приложение 1 закончило выполнение конкретной функции, из приложения 2.
И пусть приложение 3 находится на соседнем компьютере в сети.

Взаимодействие между приложением 1 и 2 могут быть разными:
1) Приложение 2 хранит все свои функции в библиотеке (shared object) и приложение 1 их вызывает.
2) Приложение 2 умеет обмениваться данными через потоки и конвееры (unix pipes)
3) У нас есть системная шина для межпроцессного взаимодействия, где можно подписаться, отправлять и получать данные (IPC)
В случае, приложения 3 нам нужно либо:
1) Иметь высокоуровневое API на приложении 3 которое примет запрос от приложения 1 по сети
2) Иметь системную шину удалённого вызова процедур (RPC)

Так вот D-bus - это протокол реализующий межпроцессное взаимодействие и удалённый вызов процедур (IPC/RPC) имеющий реализацию для разных ОС. На оффтопике за это отвечают DCOM/COM+ и MSRPC, если так понятнее.

Зачем нужны эти технологии, почему люди их используют?
1) Писать библиотеки или специальное API для внешних проектов - значит следить за неизменностью API и ABI
2) При использовании конвееров приложения должны договариваться о формате данных внутри потока и сохранять этот формат с обновлением версий. Тут также возникают проблемы с безопасностью в виду проблем с ACL.
IPC/RPC призван это устандартизировать и перевести в ООП-модель и также разграничить права.
Кроме того это вообще спор между монолитным и микросервисным приложением. Понятно, что монолитное приложение быстрее, но его иногда не получается горизонтально масштабировать, поэтому существуют микросервисы и шины данных.

И вот тут мы переходим от теории к практике
1) Исторически ядро Linux построено на религиозной максиме о превозобладающей во всех случаях производительности в случае монолитности, поэтому ядро не стандартизирует IPC/RPC на своей стороне
2) В виду того, что на pipeline можно сделать мини-IPC и он стандартизирован Столлманом в POSIX они используются чаще.
3) Использование конвееров для приложений, которые не умеют сами открывать потоки и работать с сокетами вынуждает использовать конвееры stdin/stdout превращает Linux в операционную систему где всё крутится вокруг оболочки (bash и другие)
4) А в случае использования разделяемых библиотек... Из-за сложных взаимосвязей версий библиотек и отсутствия тотальной стандартизации межпроцессного взаимодействия на уровне ОС разработчик приложения зачастую не может быть уверен заработает ли его приложение в конкретной версии конкретной ОС. Поэтому требуется особая прослоечная сущность - меинтейнер дистрибутива, который соберёт всё вместе воедино и будет отлаливать баги, которые сам привнёс при портировании кода внутрь своего дистрибутива.

Ирония в том, что незнание и непонимание сообществом IPC/RPC даже на мало-мальски базовом уровне - это та сила что с одной стороны сдерживает линукс на десктопе, а с другой стороны загоняет его на сервере в докер, потому что сложным огромным многосерверным приложением нужен IPC/RPC в отсутствии оного можно написать кучу вебсервисов засунуть в докер и подключить их к RabbitMQ, например.