Dbus-Broker 34 Released For High Performance D-Bus Message Broker

[jacob]

I don’t understand why this isn’t the default for all distros that use SystemD. IIRC DBus-Broker requires Linux (so I can appreciate not wanting to add that restriction) but so does SystemD, so that restriction is already there.

Yes I'm also not sure why some distros still use the old dbus daemon when dbus-broker is simply better.

[fallingcats]

I don’t understand why this isn’t the default for all distros that use SystemD. IIRC DBus-Broker requires Linux (so I can appreciate not wanting to add that restriction) but so does SystemD, so that restriction is already there.

FYI the correct capitalization is "systemd", see the spelling section here: https://www.freedesktop.org/wiki/Software/systemd/

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÿstëmd. But then again, Système D is not an acceptable spelling and something completely different (though kinda fitting).

[LuukD]

Nobody ever made a compelling case why this would need to be in the kernel. Also, IIRC, Linus never rejected it, it was always the network developers.

In accessibility (AT-SPI2) it is common to query remote objects of an application of interest: acquire proxy, ask about its siblings, get a parent object, get their siblings, etc.
screen-reader -> dbus-broker -> application -> dbus-broker -> screen-reader, and sometimes this includes a roundtrip to `registryd` which keeps track of accessible apps.

I hypothesized that the number of context switches could be reduced by having DBus implemented in-kernel, allowing for less 'hops'.
For instance, web-pages may consist of hundreds if not thousands of objects. You either fetch them on demand, which may introduces a noticable lag or you try to be smart and fetch beforehand but not all at once.

What accessibility needs is a bus that is always there and preferably provides the service with the least latency possible. I don't know it that qualifies as 'necessary'.
It may also be that AT-SPI3 will address these issues in part, but the idea of having DBus in kernel seems appealing to me, if for performance and reliability pov.

[Hans Bull]

TBE. Rusty zealots shitting all over the thread.

[jokeyrhyme]

There is a Rust implementation of a D-Bus broker, but don't think it's at feature parity to any of the C implementations: https://github.com/dbus2/busd

From: https://github.com/dbus2

> busd: A D-Bus daemon/broker, that aims to be a drop-in replacement for the reference implementation of D-Bus, dbus-daemon and dbus-broker. busd is not yet ready for production use.