Later this year, on November 21, 2017, D-Bus will see its 15th birthday. An impressive age, only shy of the KDE and GNOME projects, whose collaboration inspired the creation of this independent IPC system. While still relied upon by the most recent KDE and GNOME releases, D-Bus is not free of criticism. Despite its age and mighty advocates, it never gained traction outside of its origins. On the contrary, it has long been criticized as bloated, over-engineered, and orphaned. Though, when looking into those claims, you’re often left with unsubstantiated ranting about the environment D-Bus is used in. If you rather want a glimpse into the deeper issues, the best place to look is the D-Bus bug-tracker, including the assessments of the D-Bus developers themselves. The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation. Hence, workarounds have been put in place to keep them under control.
Nevertheless, these issues still bugged us! Which is, why we rethought some of the fundamental concepts behind the shared Message Buses defined by the D-Bus Specification. We developed a new architecture that is designed particularly for the use-cases of modern D-Bus, and it allows us to solve several long standing issues with dbus-daemon(1). With this in mind, we set out to implement an alternative D-Bus Message Bus. Half a year later, we hereby announce the dbus-broker project!
Interesting that it is Linux-only, but then again BSD systems often have DBus either totally disabled, or only used for a handful of applications to satisfy GTK rather than for any actual purpose.
I would support a uselessbus more than a uselessd, and perhaps we will get that if this takes off.
Well, it’s just a matter of who’s doing the work, right? These days, the relative size of the Linux and BSD communities is completely skewed… almost all of the interesting stuff comes from the Linux side, because that’s where 99% of the developers are.
And because 99% of the developers are coding for a similar proportion of Linux-using users, they see little reason to accept the limitations of writing cross-platform code, instead of taking full advantage of their own platform.
They are not “rethinking the message bus” itself: they are explicitly not changing any part of the D-Bus spec. This project is “just” a reimplementation of the server aiming to fix long-standing issues.
They are removing unused features required by the spec, and changing a few guarantees that were counter productive. So it is doesn’t follow the D-Bus spec to the letter.
Edit: See https://github.com/bus1/dbus-broker/wiki/Deviations
Edited 2017-08-25 09:28 UTC
I just barely looked at it, and it doesn’t look like it’d be too hard to port to FreeBSD.
Most of the compilation errors were for trivial stuff, like Linux defining __BYTE_ORDER in <endian.h> and FreeBSD defining _BYTE_ORDER (note single underscore) in <sys/endian.h>. The only big thing I haven’t looked into yet is that they use epoll for a few things. While FreeBSD’s kqueue does something very similar, I would have to rewrite some code to make it fit. Oh, and they test for but don’t use the clone() syscall, which just doesn’t exist on FreeBSD (though there are workarounds for that as well).
It would also need an RC script, and a port file for the packaging system. I’m not sure if I want to maintain a dbus server, though … but if I should find the spare time to make it work, I can at least open a pull request.
Edited 2017-08-25 13:42 UTC
They also uses SO_PEERCRED socket option, which also AFAIK does not have an easy or any equivalent on BSD.
…and the Deviations page says that dbus-broker dropped support for Direct Activation, relying instead on forwarding activation requests to systemd, so that’ll need appropriate replacement.