Dbus-Broker Working On AppArmor Support, Opening The Door For Possible Ubuntu Use

[phoronix]

Phoronix: Dbus-Broker Working On AppArmor Support, Opening The Door For Possible Ubuntu Use

Dbus-Broker as a drop-in replacement for the reference D-Bus implementation while focused on better performance and reliability is out with a new version. Notable with this new Dbus-Broker 32 is the beginnings of AppArmor support that could open the door for Ubuntu Linux switching over to it in the future...

https://www.phoronix.com/news/Dbus-Broker-32-Released

[Jedibeeftrix]

Opensuse - the other major user and developer of AppArmor - started a factory list discussion in early July on switching Tumbleweed over from the the legacy method to dbus-broker.

They may be the major reason behind this change with AppArmor

[tildearrow]

Typo...

This D-Bus Message Broker is already uised by the likes of Fedora, Arch Linux, and others.

[mmstick]

For what it's worth, it's already default on Pop!_OS

[bug77]

I wonder what better reliability means in this context. Does the reference implementation lose message where DBus Broker doesn't? Where the reference implementation retries 3 times, DBus Broker retries 10 times?

[RahulSundaram]

I wonder what better reliability means in this context. Does the reference implementation lose message where DBus Broker doesn't? Where the reference implementation retries 3 times, DBus Broker retries 10 times?

https://www.fedoraproject.org/wiki/C...ed_Description describes the general benefits and https://github.com/bus1/dbus-broker/wiki/Reliability provides a comprehensive answer to your question.

[bug77]

https://www.fedoraproject.org/wiki/C...ed_Description describes the general benefits and https://github.com/bus1/dbus-broker/wiki/Reliability provides a comprehensive answer to your question.

That explains how it is reliable, not how it is more reliable than the reference implementation. But if I can dig up a similar document for the reference implementation, I guess I can compare myself. Thanks.

[RahulSundaram]

That explains how it is reliable, not how it is more reliable than the reference implementation. But if I can dig up a similar document for the reference implementation, I guess I can compare myself. Thanks.

The first link does explain that:

While D-Bus is used on reliable transports, dbus-daemon might still silently drop messages and given circumstances. This is the only possible solution dbus-daemon has, given several of its runtime guarantees. The dbus-broker project changed the architecture of the bus daemon to a degree, that it can provide many guarantees, including that no message will be silently, or unexpectedly, dropped

.

[bug77]

The first link does explain that:

.

Meh, there are always circumstances when you have to drop messages (DLQs weren't invented yesterday). It doesn't even say it won't drop them, just that it won't drop them "silently, or unexpectedly". Granted, better visibility when this happens is always welcome. Silent errors are the worst kind of errors, after all.

[RahulSundaram]

Meh, there are always circumstances when you have to drop messages (DLQs weren't invented yesterday).It doesn't even say it won't drop them, that it won't drop them "silently, or unexpectedly". Granted, better visibility when this happens is always welcome. Silent errors are the worst kind of errors, after all.

No RPC under these constraints can ever say, we will never drop messages, that would be just a false promise. Failing loudly as you noted is always just good design and gives higher level components a way forward. Especially important since D-Bus is being used for so many critical services including installer, DNS, init system and so forth and increasingly in sectors where silent failures would be a large problem. A bunch of long standing problems has been resolved with this implementation and afaik it has been a smooth transition. That looks like a pure win to me.