Dbus-Broker 25 Released With More Fixes

[phoronix]

Phoronix: Dbus-Broker 25 Released With More Fixes

The BUS1 kernel code for providing an in-kernel, capability-based IPC mechanism hasn't seen much (or any?) activity in well over a year but at least the Dbus-Broker project continues ahead. Dbus-Broker continues ahead as this D-Bus compatible implementation focused on correctness while being optimized for performance...

http://www.phoronix.com/scan.php?page=news_item&px=Dbus-Broker-25-Released

[uid313]

Is this D-Bus thing a good thing?
Is it like Binder on Android?
Which one is better, D-Bus or Binder?
Also does Windows, macOS, iOS or BSD have anything similar?
Is this like 9P in Plan 9 from Bell Labs?
Is D-Bus better or worse than 9P?
Is this better than using named pipes or Unix domain sockets?

[ssokolow]

Is this D-Bus thing a good thing?
Is it like Binder on Android?
Which one is better, D-Bus or Binder?
Also does Windows, macOS, iOS or BSD have anything similar?
Is this like 9P in Plan 9 from Bell Labs?
Is D-Bus better or worse than 9P?
Is this better than using named pipes or Unix domain sockets?

D-Bus is the de facto standard RPC framework for the Linux desktop (it lets applications expose functions to be called by other applications). It's the successor to KDE using DCOP and GNOME using CORBA. It serves a similar role to Binder, yes.

D-Bus and Binder have different strengths and weaknesses, so you can't strictly say one is better.

BSDs also use D-Bus, because it's a userland thing that KDE and GNOME and various other things depend on. (As I said, it's a common successor to components that used to be part of KDE and GNOME.) It can even theoretically run on Windows, though I'm not sure how supported that option is in practice.

I believe the closest MacOS equivalent would be Mach Ports and I don't know enough about Windows's architecture to point to a specific piece of jargon and say "that's the equivalent"... but I suspect it'd have something to do with COM. From what little I know, COM seems to be pretty central to any sort of inter-component communication on Windows.

I don't know much about Plan 9 but I think they'd serve equivalent roles as the big name in high-level IPC, though they wouldn't function in similar ways.

From a cursory glance, 9P appears to be more network-transparent but lower-level.

...and yes, it's generally much better than using named pipes or Unix domain sockets. (If you've got the Qt developer tools installed, check out qdbusviewer. D-Bus is introspectable, so an application can browse the available APIs and both sides of a message exchange can query and validate the signatures of the function arguments.)

It's like the difference between writing raw text into a file (pipes and domain sockets) and using language bindings for a library.

It also supports broadcast signals and subscriptions, so you can do things like connecting to your media player and listening to "song changed" events.

[discordian]

Is this better than using named pipes or Unix domain sockets?

There are roughly 2 components in regards to DBus (the standard): IPC and launching services.

DBus-broker delegates the launching to systemd, so thats already a good thing compared to reference Dbus implementation, and a non-issue.

Further, communication is already done over Unix domain sockets, DBus(-broker) just gives you a common system-wide interface to set those connections up. Some restrictions apply when using features like broadcasts (not a feature of unix sockets) where some overhead is necessary.

All together, DBus-broker is a rather lightweight pay-for-what-you-use framework on top of Unix domain sockets.

if you look for alternatives, you should look at varlink which is even less overhead (systemd actually moved several IPC connection from DBus to varlink, not at least to drop circular dependencies as Dbus(-broker) is started by systemd).

[uid313]

…

Thank you! 🙏

…

Thank you! 🙏

[JPFSanders]

.

.

Thank you both!

[stalkerg]

>if you look for alternatives, you should look at varlink which is even less overhead (systemd actually moved several IPC connection from DBus to varlink, not at least to drop circular dependencies as Dbus(-broker) is started by systemd).

I have dbus but I have no systemd

[discordian]

>if you look for alternatives, you should look at varlink which is even less overhead (systemd actually moved several IPC connection from DBus to varlink, not at least to drop circular dependencies as Dbus(-broker) is started by systemd).

I have dbus but I have no systemd

Then you don't have dbus-broker either. But yay to you, we are all really glad you came out of your 1930' woodshack to share this really important on-topic information.

[stalkerg]

> Then you don't have dbus-broker either.

I have, I still working on dbus-broker-luncher but the broker itself working.

> But yay to you, we are all really glad you came out of your 1930' woodshack to share this really important on-topic information.

Sorry, I am sitting in a skyscraper in Tokyo... and I can talking anything that I suppose important.