 |
| “dbus is not mostly about IPC.” (comment) | ||
| recommended by 1 user | 2014 | hp on: DBus, FreeDesktop, and lots of madness | linux | original thread | | ||
| hp on Nov 23, 2014 | on: DBus, FreeDesktop, and lots of madness | view on HN | ||
| One user recommended this comment. What they said: |
|
bitwize Apr 28, 2015 | on: “DBus is seriously screwed up” | context
To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place: https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8649459 D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion. It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code. Oh, and it also does multicast, which no other commonly used Unix IPC can do. People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services. |
| Also recommended by people who recommended this: | ||
| 1. | “In creating dbus, I talked to a bunch of developers at KDE” (comment) | |
| recommended by 1 user | 2014 | hp on: DBus, FreeDesktop, and lots of madness | original thread | | ||
This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser.
dbus is not mostly about IPC.
Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process.
Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability.
Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces.
The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon.
Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.