Linked by Thom Holwerda on Wed 23rd Aug 2017 22:59 UTC
General Development

David Hermann writes:

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!

E-mail Print r 2   7 Comment(s)
Order by: Score:
Comment by FlyingJester
by FlyingJester on Wed 23rd Aug 2017 23:05 UTC
Member since:

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.

Reply Score: 2

RE: Comment by FlyingJester
by Delgarde on Thu 24th Aug 2017 20:29 UTC in reply to "Comment by FlyingJester"
Delgarde Member since:

Interesting that it is Linux-only

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.

Reply Score: 4

Comment by moltonel
by moltonel on Thu 24th Aug 2017 09:16 UTC
Member since:

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.

Reply Score: 4

RE: Comment by moltonel
by Carewolf on Fri 25th Aug 2017 09:28 UTC in reply to "Comment by moltonel"
Carewolf Member since:

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

Edited 2017-08-25 09:28 UTC

Reply Score: 2

by dnebdal on Fri 25th Aug 2017 13:41 UTC
Member since:

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

Reply Score: 3

by jesm on Fri 25th Aug 2017 21:35 UTC in reply to "BSD"
jesm Member since:

They also uses SO_PEERCRED socket option, which also AFAIK does not have an easy or any equivalent on BSD.

Reply Score: 1

RE[2]: BSD
by ssokolow on Sat 26th Aug 2017 03:40 UTC in reply to "RE: BSD"
ssokolow Member since:

...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.

Reply Score: 2