The link you posted has what I think is the right one:
The problem is that probably this code is not needed at all.
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.
The Wikipedia article on IPC https://en.wikipedia.org/wiki/Inter-process_communication is really incomplete.
Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project.
It would seem that modern computing is all about building abstractions on top of abstractions, to solve 'problems' nobody ever had. Nobody ever seems to consider the costs of such complexity (in terms of maintenance, understanding the system as a whole, attack vectors, etc.)
By all means, if you need a super complex system with tons of features like D-bus, great! But I am pretty confident that Mousepad (Xfce text editor) doesn't need D-bus just to open a text file in a new tab of an existing window.
Is that sarcasm, or you don't know what dbus is used for?
I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD.
"D-Bus is a message bus system, a simple way for applications to talk to one another."
With shared memory (IPC) or sockets (RPC), applications can talk to each other.
Yes, D-Bus gives you an API interface for this (though I personally can't stand it); which apparently comes with tremendous overhead, if the linked article is to be believed.
Yes, with raw memory/sockets, you have to do the queue work yourself. But that's CS101 stuff; you shouldn't touch IPC if you can't implement a simple shared queue.
For most use cases, D-Bus is like using a jackhammer to nail in drywall.
"In addition to interprocess communication ... it makes it simple and reliable to code a "single instance" application or daemon"
Again, very easy with shared memory and a semaphore. If your attempt to open the semaphore fails, you create it and become the daemon. When the daemon closes, you delete the semaphore. When a second instance opens and connects to the semaphonre, and then shared memory, then it writes the command-line arguments into the queue, and the daemon handles it. Voila, "single instance" application or daemon.
"and to launch applications and daemons on demand when their services are needed"
And this would be a more complex use case that would be harder to solve. It's also a much less common use case. I don't really feel it's directly related to basic IPC, it's D-Bus trying to solve multiple problems at the same time.
I'd rather follow the Unix way and split that into a separate component, perhaps built on top of the IPC protocol.
The whole idea is the "standard" part, not merely the "talk to each other part".
I don't mind that "each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects", as that's the whole point.
All D-bus gets you is an official version of the header I spoke of. Along with so much overhead that you can't use it for any kind of media streaming, apparently. And now they want kdbus; and I definitely don't want their code in my BSD kernel.
This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."
It came out of the initial freedesktop project to improve interaction between KDE and Gnome.
KDE already had system called DCOP for internal use (allowed for instance Konqueror to be web browser, file manager and multi-pane FTP/SFTP client all at once).
But as with much of KDE it was created using C++. And Gnome is made using C.
So DBUS is something like a reimplementation of DCOP in C.
And the rest is history...