Agreed -- I remember some of the alternative ways to solve the same problems, such as CORBA and various custom protocols, but they were painful to use...

Now, early DBus was a bit lacking in that respect as well, but with GDBus (GLib's DBus implementation) it's become as straightforward as IPC can be, even in plain C; I've seen quite a few people new to the technology that were able to get up to speed with it quickly.

It'll be interesting to see how people are taking DBus and pushing the boundaries of what it can be used for, such as kdbus.

Thank you hp!

Interesting perspective. I thought I read somewhere that ZeroMQ was championing becoming apart of the Kernel. I work in the embedded space and not knowing much about DBUS other than it's some fancy IPC and ZeroMQ, we went with ZeroMQ just because we saw a clear path for what we needed get done. Granted all our IPC communication was between our own apps. but after reading your post I keep wondering what REAL problems does DBUS solve besides having a standard messaging format? Could someone explain why a simple messaging format couldn't be deployed on top of something like ZeroMQ?

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.

dbus handles a lot of cases where you have an unprivileged process like a GUI widget communicating information to a root process like a network manager. Because it's centralized and everything flows through the dbus process, a lot of it is about policy enforcement— ie, these methods can be called by this user or group, these other ones by this other group, etc.

Examples of the configuration which controls this kind of thing:

https://github.com/mungerd/vncbox/blob/master/data/dbus-conf... http://git.kernel.org/cgit/network/connman/connman.git/tree/...