What is the point in dbus?
I have been dealing recently with attempting to set up a media control keybind which can pause whatever media is currently playing in whatever program (mpv, browser, etc.) and I discovered the "mpris" protocol not so long after. It seemed simple enough; players register and then can be controlled over dbus. However, this was not as simple as it seemed. Because DBus requires a session bus to be launched in the context of a user, I had to launch the dbus process. Easy task? No! Initially, I added the dbus-launcher to my .xinitrc like many other startup commands, like starting nm-applet and mpd. Did it work? Of course not, nothing can be that simple. DBus's libraries require that you export certain environment variables (which are filled to the brim with XML garbage put there by some soydev) or it will abort applications which attempt to use DBus. Why? So that the location of the DBus session bus can be relocated. Why would it need to be relocated? I have no idea. We are just expected to accept that this is the case. So, I added the required variables, but it still didn't work, because of some unfathemable reason which I still don't understand. In the end, I had to replace my nice clean
exec dwm
call with the indescribably awful:
exec dbus-launch --exit-with-x11 --no-daemon dwm
Even with this, DBus woult still randomly exit at times, leaving me to deal with a torrent of "org.freedesktop.DBusNoReplyError"s in my terminals. In the end, I ended up writing a script that would respawn dbus automatically when it crashed (not if - when it crashed). I don't know if this is just on my end, but DBus has been really awful for me this whole time, and yet it is only needed for one single application - perhaps two at the most.
All so that I could press Mod+P and have my media pause. I will spare you the story of the rest of the time spent debugging Chromium not picking up the session bus and environment variables getting reset for some daemons so as to spare you from damnation to a depressed state, but I hope that you get the picture that DBus caused me a large amount of pain.
And so, this made me think about DBus iteslf. Why does it need to exist? We already have domain sockets, named pipes, FIFOs, temporary files and network connections, so why do we need yet another IPC system? The Arch Wiki claims that DBus "provides an easy way for inter-process communication. It consists of a daemon, which can be run both system-wide and for each user session, and a set of libraries to allow applications to use D-Bus". This seems to suggest that DBus is just a JQuery-style "ease-of-use" band-aid that was added to the UNIX space to make the jobs of the FreeDesktop developers slightly easier.
I've written quite a bit of software for UNIX-like stuff in my time and I have never come across a need for IPC which is not fullfilled by the standard UNIX IPC tools. To add insult to injury, you literally communicate with DBus through a UNIX domain socket which is placed in your run directory. Surely, this is just re-inventing the wheel, right?
DBus, at least to me, seems to be a ploy created by the FreeDesktop people to put even more Windows-ish garbage into the UNIX space. We don't need DBus. DBus is bloated and randomly spikes to 100% CPU usage on my laptop. When I kill it, the browser, with all my tabs, instantly crashes. All of this could have easily been replaced with nice, file-based IPC endpoints which software interfaces with in a natural fashion. Adding several layers of "brokers", daemons and worker processes just to handle IPC is not the UNIX way. I should not be able to completely ruin my system by killing any process other than init and (maybe) elogind. What if DBus crashes? Well, good luck getting your system back, because elogind communicates with clients through this. Seriously, try running:
sudo killall dbus-daemon
at a TTY and watch your screen freeze up. This is ridiculous. Because one process exits, the entire system is barely usable. Thank goodness for the SysRq key.
DBus and the FreeDesktop suite of software encourage this awful centralised model of a system where literally everything has to be channeled through or included in this one package (remind you of a certain init system?). This is shown off perfectly in this Reddit post. The user wishes to remove DBus, but is unable to open .desktop files without it. From my experience, .desktop files are just INI files which are placed in an XDG directory to give rich application launching facilities. Why does it need DBus to parse? At most, you might need a library (maybe call it "libdesktop" or "liblaunch"). Instead, we have to communicate over a socket which further communicates through a daemon over yet another socket to parse an INI file and launch a program. This should be maybe just over 20 lines of C (even less Go). Instead, there are likely thousands of lines of code involved. And all for "easy inter-process communication"
Let's take "mpris" for one moment and re-design it to use UNIX domain sockets. For each player which wishes to register, you create a socket in a specific directory (maybe XDG_CACHE_HOME or something). Each of these sockets can then be used to interface with the players at hand. Commands can be taken and responses given in plain text and without any XML nonsense. Just using the standard UNIX "open" and "close" syscalls is so much simpler than understanding all of this crap. The documentation literally compares DBus to a "message-based" network socket. So why can't we just use network sockets? This is not simple - it is over-complicated, messy, difficult to use and most of all it just sucks.
So why, then, you may ask are we still using DBus? Well, the aforementioned Reddit thread sums up the attitude towards it perfectly with the following quote: "Yes, DBus sucks. But, the fact the DBus sucks and that it uses a negligeble amount of resources for the average user are not mutually exclusive". In other words, DBus has the same chronic illness as Windows where the rot goes very deep but not deep enough to annoy apparently anybody other than me and two other people on earth. Most people would rather have their stupid XML endpoints and dbus-brokers taking up megabytes of RAM. DBus sucks, but not for the user. The suckiness is only really exposed once you try to write software or scripts for it.
At least in a single-user environment, I see absolutely no reason why DBus should even exist. Of course, I am perfectly willing to be enlightened if somebody disagrees. Thank you for attending my Ted Talk.
If you or someone you know has been affected by DBus or its allies at the FreeDesktop foundation, help is available in this summarising thread
Topic: What is the point in dbus? (Read 4129 times)
previous topic - next topic
