Does anybody know why dbus exists? I’ve been wracking my brain trying to come up with a usecase for dbus that isn’t already covered by Unix sockets.
You want to remotely control a daemon? Use sockets. You want the daemon to respond to the client? Sockets. Want to exchange information in json? plaintext? binary data? Sockets can do it. Want to restrict access to a socket? Go ahead, change the socket’s permissions. Want to prevent unauthorized programs from pretending to be someone they’re not? Change the permissions of the directory containing the socket. Want network transparency? That’s why we have abstract sockets.
Plenty of well-established software uses sockets. Music player daemon uses sockets. BSPWM uses sockets. Tmux uses sockets. Pipewire uses sockets. Dhcpcd uses sockets. Heck, dbus itself relies on sockets!
For developers, using sockets is easy. I once wrote a program that interfaced with BSPWM, and it was a breeze. Dbus, on the other hand, not so much. I tried writing a Python script that would contact Network Manager and check the WiFi signal strength. Right off the bat I’m using some obscure undocumented package for interfacing with dbus. What is an introspection? What is a proxy object? What is an interface? Why do I need 60 lines of (Python!) code for a seemingly trivial operation?
So why do some developers decide to use dbus when they could just use unix sockets and save a lot of hassle for themselves and others?
You must log in or register to comment.
With pipes/sockets, each program has to coordinate the establishment of the connection with the other program. This is especially problematic if you want to have modular daemons, e.g. to support drop-in replacements with alternative implementations, or if you have multiple programs that you need to communicate with (each with a potentially different protocol).
To solve this problem, you want to standardize the connection establishment and message delivery, which is what dbus does.
With dbus, you just write your message to the bus. Dbus will handle delivering the message to the right program. It can even start the receiving daemon if it is not yet running.
It’s a bit similar to the role of an intermediate representation in compilers.
modular daemons
A message bus won’t magically remove the need for developers to sit down together and agree on how some API would work. And not having a message bus also doesn’t magically prevent you from allowing for alternative implementations. Pipewire is an alternative implementation of pulseaudio, and neither of those rely on dbus (pulse can optionally use dbus, but not for its core features). When using dbus, developers have to agree on which path the service owns and which methods it exposes. When using unix sockets, they have to agree where the socket lives and what data format it uses. It’s all the same.
It can even start the receiving daemon if it is not yet running.
We have a tool for that, it’s called an init system. Init systems offer a large degree of control over daemons (centralized logging? making sure things are started in the correct order? letting the user disable and enable different daemons?). Dbus’ autostart mechanism is a poor substitute. Want to run daemons per-user instead of as root? Many init systems let you do that too (I know systemd and runit do).
It can even start the receiving daemon if it is not yet running.
We have a tool for that, it’s called an init system.
The init system is for trusted system services that can talk directly to hardware. Unless you are working on a single-user system with no security concerns of any kind, you might consider using init to launch persistent user land or GUI processes.
DBus is for establishing a standard publish/subscribe communication protocol between user applications, and in particular, GUI applications. And because it is standard, app developers using different GUI frameworks (Gtk, Qt, WxWidgets, FLTK, SDL2) can all publish/subscribe to each other using a common protocol.
It would be certainly be possible to establish a standard place in the /tmp directory and a standard naming scheme for sockets and temporary files so that applications can obtain a view of other running applications and request to receive message from other applications using ordinary filesystem APIs, but DBus does this without needing the /tmp directory. A few simple C APIs replace the need for naming and creating your temporary files and sockets.
Let’s say you want to write a GUI for connecting to networks.
In the backend, you have NetworkManager, systemd-networkd, ConnMann, netctl, dhcpcd, …
Dbus could be a good way to expose a common API surface for clients.
/thread
But it’s not. Why is it better to have a different degree distribution?
Want to exchange information in json? plaintext? binary data? Sockets can do it.
This is exactly why you need something like dbus. If you just have a socket, you know nothing about how the data is structured, what the communication protocol is, etc. dbus defines all this.
In either case you still need to read the documentation of whatever daemon you’re trying to interface with to understand how it actually works. Dbus just adds the extra overhead of also needing to understand how dbus itself works. Meanwhile sockets can be explained in sixteen words: “It’s like a TCP server, but listening on a path instead of an ip and port”.
It’s much easier to understand how dbus works once than to understand how every daemon you connect to works every time you interface with a new daemon.
but you still have to understand the methods available in every daemon
Yeah that’s the case with programming… well anything. This at least gives you a way to automatically receive all of that data from any app without excessive prior knowledge. With a small amount of info you can filter for specific events and create all kinds of robust functionality. That’s the power of a set protocol - it is to make things widely compatible with one another by only depending on the dbus protocol and app name. Otherwise you may need to depend on some shared objects which makes deployment and maintenance a total clusterfuck.
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
You got downvoted for speaking the truth. You can’t talk to a dbus app without understanding how it communicates. You can’t talk to a sockets app without understanding how it communicates.
Sometimes you want loose coupling.
Dbus attempts to provide a standardized system for inter process communication (IPC) without the complexity of managing individual connections between each and every process that needs to share certain types of data.
Yes, of course, the sockets are the answer to everything (and BTW, d-bus uses sockets as well, e.g.
/run/dbus/system_bus_socketon my current system), but the problem is no standard for the communication over these sockets (or where is the socket located). For example, X11 developed one system of communicating over their socket, but it was used just by few X11 programs, and everybody else had their other system of communication. And even if an app found some socket, there was absolutely no standard how exactly should programs communicate over it. How to send more than just plain ASCII strings? Each program had to write their own serialization/deserialization code, their own format for marshalling binary data, etc. Now there is just one standard for those protocols, and even libraries with the standard (and well tested) code for it.There’s still no standard on how to use dbus so I don’t get your point
Multicast.
What’s the point of sockets?
dbus can also start a program. For example when one notification was generated and no notification daemon is running, then dbus launch one to handle the request.
I’m a firm believer that the vast majority of things we needed for software were implemented by the 2000s.
Usually, people who don’t understand what they’re doing will overcomplicate things to cover-up their misunderstandings. I think choosing a technology before you have a use-case is one of these examples.
It would not be created if existing plumbing covered all use cases.
Don’t assume you know better and that developers are simply reinventing the wheel.
Reinventing the wheel? Making new systems which create more problems than they solve? Adding abstractions which actually make things more complex?
Nah, those things have never happened in software
There is a lot of ‘reinventing the wheel’ in software, and I did not claim otherwise.
When new abstractions are beneficial, other programs take advantage of them and the whole ecosystem moves forward. When they are not, nobody cares and they are ignored and die. In that respect, open source software development is very much like evolution.
Judging by apps using it, looks like this abstraction is indeed useful.
I just came across this - https://fedoramagazine.org/d-bus-overview/ - and I think it explains it pretty well.
What is the point of a steak when you can drink tea? Mmm…
