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

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

[Hans Bull]

TBE. Rusty zealots shitting all over the thread.

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

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

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

[EphemeralEft]

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.

[jacob]

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.

Being in the kernel would have benefits, for example MAC systems like SElinux and Apparmor would naturally cover it.

[jacob]

In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.

In 2023 I don't think Rust is exactly lacking in the being taken seriously department.

[Rallos Zek]

When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.

In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.

[npwx]

The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
Not today I'm affraid.

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.