Ubuntu 23.10 Looks Like It Will Switch To Using Dbus-Broker

[phoronix]

Phoronix: Ubuntu 23.10 Looks Like It Will Switch To Using Dbus-Broker

While distributions like Fedora Linux have been using Dbus-Broker for years already as their high performance D-Bus compatible implementation to, for Ubuntu 23.10 later this year is finally where it looks like Ubuntu will be transitioning to this better alternative to dbus-daemon...

https://www.phoronix.com/news/Ubuntu-23.10-Dbus-Broker-Plan

[elbar]

Some programs have properties. GNOME has in their gsettings shit. And to tell that something crucial in it is missing and open some issue on their GitLab shit is big no for me... It shouldn't be windows huge registry, but also Canonical think that vanilla GNOME is big mess. And although there are a lot of extensions. why should I care in my spare time to make a one for free of human mankind?

[jacob]

That would be good.

[anarki2]

Some programs have properties. GNOME has in their gsettings shit. And to tell that something crucial in it is missing and open some issue on their GitLab shit is big no for me... It shouldn't be windows huge registry, but also Canonical think that vanilla GNOME is big mess. And although there are a lot of extensions. why should I care in my spare time to make a one for free of human mankind?

DBus is not a configuration management utility.

[kiffmet]

elbar DBUS provides interprocess communication. It has nothing to do with storing settings and properties.

[dreamcat4]

there was a very simple user use case that i wanted to do a while ago. But was not actually known to be supported (on ubuntu with the original dbus daemon). It surprised my because it seemed like a pretty reasonable user use case:

* multiple monitors / display system
* to have toast notifications appear on more than only 1 monitor

Problem:

none of the toast notification servers seemed to support multiple monitors. Perhaps this was due to (being on xorg) that the whole screen spans all of the monitors. And it does not really distinguish. Anyhow:

Since the toast server softwares (multiples of them) didn't support just repeating the same notification displayed onto another 2+ screen(s). I thought: hey! but i could run 2 instances of duplicate toast servers (the same one, or in fact entirely different ones). And if they can both receive the same DBUS toast messages. Then that will work. Right?

Wrong. Because in DBus land you can only have 1 process listening at a given dbus address endpoint. So whichever dbus server launched earliest, it grabs that entpoint address (to receive on). And any subsequent ones are denied access.

Looking further into the matter, i discovered that (at the time) the DE i was using (budgie) some part of budgie was pro actively grabbing the endpoint before i could ever have the opportunity (after login, realize because toast dbus endpoint needs a user level session).... before i could then launch my own after market 3rd party toast notification server.

So what to do eh? Well aparrently it was supposed to be a feature that could be security controlled via apparmor. Great! So i can write an apparmor profile to deny the budgie DE from being permitted to grab the single universal dbus endpoint? Thus letting me run my own toast server(s) and do the other needed trickery. Right?

Well wrong, because it turned out that feature was never got working, it required some kernel patches that (supposedly) would make it then work. But it never worked. For whatever reasons. So there I am. The user use case to my knowledge still isn't solved to this day. Althuogh i was so frustrated by the whole carry on that i never wanted to return, go back and check.

On KDE / xorg now and will be upgrading my ubuntu to 23.04 soon. But still pretty dissapointed that this simple user use case was just so... well it seemed to fly right under everybody's radar. Like it wasn't a reasonable feature to want or include. (not in a particular specific software - but in all of them!)

And not just the toast servers themselves for the multiple displays thing... but also that there isn't enough flexibility in these dbus endpoints? For example to clone or duplicate an endpoint. With appropriate system level configurations. So that more than 1 consumer can attach / listen in. Or to actively block a process from grabbing a reserved endpoint on a first come first served basis? Seems a bit of a gap in the feature set there IMHO. Not sure what those guys were considering there. Come to think of it... who came up with this whole DBUS system anyways? To write the specs and the reference implementation and all that.

[ssokolow]

none of the toast notification servers seemed to support multiple monitors. Perhaps this was due to (being on xorg) that the whole screen spans all of the monitors. And it does not really distinguish.

It's not due to being on X11. It's just a feature they didn't implement. All modern desktops have a single desktop surface shared by all monitors and it's the application's job to query the rectangles for the monitors if it wants to. (Assuming you're not on Wayland, where there's no standard API for querying that information for security reasons and anything that needs it has to either be part of the compositor or communicate with it via a proprietary API.)

In fact, for as long as I've been using it (early 2000s), X11 was the only desktop to support a different system. (Initially nicknamed and later officially dubbed "Zaphod mode" after Zaphod Beeblebrox's two heads, where the desktops are so independent that, while you can move your mouse back and forth, applications were trapped on the monitor they were started on unless they had explicit support for moving themselves, because it was more akin to a soft KVM for two independent GPUs than a true multi-monitor desktop.)

And not just the toast servers themselves for the multiple displays thing... but also that there isn't enough flexibility in these dbus endpoints? For example to clone or duplicate an endpoint. With appropriate system level configurations. So that more than 1 consumer can attach / listen in.

D-Bus is designed as a remote procedure call system... like the innards of a program, but split across multiple processes. It'd cause chaos to have more than one registrant for an endpoint without writing a proxy to mediate.

As someone who's written programs that use the org.freedesktop.Notifications API, I can point out a few examples:

• Having multiple recipients without some kind of mediation would result in race conditions galore unless you came up with a system like "other listeners can listen, but only the first claimant (and it has to be the first because there's no guarantee additional ones will show up) can respond.
• D-Bus functions are function calls... just remote ones. They have return values and, in the case of notification servers, those return values are often notification handle IDs that are used for things like updating or manually hiding notifications. In a multi-daemon situation, where the daemons aren't obligated to use the same sequence of IDs, you either have only one daemon responding as it should because first responder gets it (again, race conditions) or you have applications crashing when they make D-Bus calls because they expected a scalar value like an integer and received some kind of array type.
• Applications call org.freedesktop.Notifications.GetCapabilities to determine how to formulate their notifications. Having more than one recipient would mean that you'd be trusting that all your notification daemons are compatible with the optional features returned by whichever one wins the race to respond.
• Applications call org.freedesktop.Notifications.Inhibit and org.freedesktop.Notifications.UnInhibit
  and there's a replaces_id parameter for org.freedesktop.Notifications.Notify.

Imagine if you're browsing a website and your login session is going on the fritz because request randomly get sent to one of two servers which weren't coded to share the same session store.

If you want to run two daemons, what needs to happen is to have some kind of proxy which claims org.freedesktop.Notifications, launches the other daemons on their own private buses, and then has logic to manage things. (eg. an internal lookup table that allow it to map the IDs other applications see into the two or more IDs required by the daemons it's mediating.)

Come to think of it... who came up with this whole DBUS system anyways? To write the specs and the reference implementation and all that.

KDE and GNOME got together on Freedesktop.org to cook up a replacement for KDE 3's DCOP and GNOME 3's use of CORBA that both could agree on.

[uxmkt]

Given that nothing more has come from the failed KDBUS effort or the BUS1 in-kernel IPC solution, Dbus-Broker is the best option currently available for this communication interface/bus between processes on Linux systems.

It probably isn't that black-and-white. Surely kdbus/dbus1 wasn't for nothing, if only to come to the conclusion that dbus-broker is a sensible way forward for the present.

[Termy]

Your news make it sound like AppArmor is already supported, but that is still not the case - once it is, i will finally also switch over

[Weasel]

D-Bus is designed as a remote procedure call system... like the innards of a program, but split across multiple processes. It'd cause chaos to have more than one registrant for an endpoint without writing a proxy to mediate.

As someone who's written programs that use the org.freedesktop.Notifications API, I can point out a few examples:

• Having multiple recipients without some kind of mediation would result in race conditions galore unless you came up with a system like "other listeners can listen, but only the first claimant (and it has to be the first because there's no guarantee additional ones will show up) can respond.
• D-Bus functions are function calls... just remote ones. They have return values and, in the case of notification servers, those return values are often notification handle IDs that are used for things like updating or manually hiding notifications. In a multi-daemon situation, where the daemons aren't obligated to use the same sequence of IDs, you either have only one daemon responding as it should because first responder gets it (again, race conditions) or you have applications crashing when they make D-Bus calls because they expected a scalar value like an integer and received some kind of array type.
• Applications call org.freedesktop.Notifications.GetCapabilities to determine how to formulate their notifications. Having more than one recipient would mean that you'd be trusting that all your notification daemons are compatible with the optional features returned by whichever one wins the race to respond.
• Applications call org.freedesktop.Notifications.Inhibit and org.freedesktop.Notifications.UnInhibit
  and there's a replaces_id parameter for org.freedesktop.Notifications.Notify.

Imagine if you're browsing a website and your login session is going on the fritz because request randomly get sent to one of two servers which weren't coded to share the same session store.

If you want to run two daemons, what needs to happen is to have some kind of proxy which claims org.freedesktop.Notifications, launches the other daemons on their own private buses, and then has logic to manage things. (eg. an internal lookup table that allow it to map the IDs other applications see into the two or more IDs required by the daemons it's mediating.)

Sounds like over-engineered garbage just like I'd expect out of anything from Red Hat. Not to mention it adds several layers and multiplies the amount of IPC done. But thanks for explanation, didn't know it was this bad.