Dbus-Broker 33 Released With Few Changes

[phoronix]

Phoronix: Dbus-Broker 33 Released With Few Changes

A half-year has passed already since Dbus-Broker 32 was released for this drop-in replacement to the reference D-Bus implementation that is focused on providing better performance and reliability. Today that's been succeeded by Dbus-Broker 33 as a relatively minor update to this software from the BUS1 project...

https://www.phoronix.com/news/Dbus-Broker-33

[uid313]

Is D-Bus just a bus for the Linux desktop?
What should non-desktop applications use for communication?

TCP seems like it has unnecessary overhead for communication between applications on the local machine.
I think pipes, anonymous pipes and named pipes maybe are just useful for 1-to-1 communication and not useful for many applications to broadcasting messages.
Maybe Unix domain sockets?

[kpedersen]

We use UNIX domain sockets and shared memory (i.e shm_open(3), mmap(2)).

Things like dbus and tooltalk just feel so retro and fragile.

[RahulSundaram]

Is D-Bus just a bus for the Linux desktop?
What should non-desktop applications use for communication?

Plenty of non desktop specific components use or provide D-Bus interfaces including systemd and embedded systems. It is not limited to desktop.

[discordian]

Is D-Bus just a bus for the Linux desktop?
What should non-desktop applications use for communication?

TCP seems like it has unnecessary overhead for communication between applications on the local machine.
I think pipes, anonymous pipes and named pipes maybe are just useful for 1-to-1 communication and not useful for many applications to broadcasting messages.
Maybe Unix domain sockets?

Well, if you take Unix sockets and add a service to start/resolve other applications by name then you basically end up with something like dbus.

DBus-broker is already pretty trimmed down, the only thing "desktop" specific is that it's a separate session per desktop.

[Vorpal]

Is D-Bus just a bus for the Linux desktop?

No, systemd also exposes an interface over it for example. But I believe it is mostly a Linux (non-Android) thing.

What should non-desktop applications use for communication?

TCP seems like it has unnecessary overhead for communication between applications on the local machine.
I think pipes, anonymous pipes and named pipes maybe are just useful for 1-to-1 communication and not useful for many applications to broadcasting messages.
Maybe Unix domain sockets?

Depends on what you are doing and what your use case is. Do you want a message bus, or is point-to-point enough? Do you care about going between computers or just on the same computer? Do you need to move a LOT of data (in which case dbus is not the right option anyway) or just small amounts? What about your latency requirements?

[oiaohm]

Is D-Bus just a bus for the Linux desktop?
What should non-desktop applications use for communication?

D-bus is not just for the desktop. D-Bus design has a controller part of it design "message bus daemon" this provides polkit integration and other things.

Why non-desktop application would use D-Bus is the for the security side you want security around the interface for third party applications to interface with and don't want to have to reinvent the wheel and don't want to have to have the security items interfacing in your applicaiton.

There are two of these to choose between dbus-broker(Linux only) and dbus-deamon. This gets very important.

TCP seems like it has unnecessary overhead for communication between applications on the local machine.
I think pipes, anonymous pipes and named pipes maybe are just useful for 1-to-1 communication and not useful for many applications to broadcasting messages.
Maybe Unix domain sockets?

Remember dbus uses Unix Domain sockets.

We use UNIX domain sockets and shared memory (i.e shm_open(3), mmap(2)).

Things like dbus and tooltalk just feel so retro and fragile.

https://en.wikipedia.org/wiki/ToolTalk

Tooltalk is superseded with no more official development superseded by dbus. So tooltalk is not just retro and fragile it superceded.

dbus is not one thing. Dbus-broker that is a Linux optimized implementation and dbus-deamon that is a cross platform generic implementation.

Dbus-broker is based on sd-bus that comes from systemd and sd-bus was made for performance. dbus-deamon uses libdbus and both are the reference implemnentation

kpedersen there is something horrible here. Performance difference is a 360% throughput increase using sd-bus over libdbus.

Redhat/IBM maintains both dbus-broker and dbus-deamon. Redhat/IBM has no financial reason to be spending developer time optimizing for dbus-deamon BSD users.

kpederson sudo is also more retro and fragile. D-bus is design to have policy applied to control what applications can and cannot access by polkit even between items running as different users so is a sudo alternative with more fine grained control.

Yes when not needing the extra security bits using Unix domain sockets and shared memory makes sense. Remember dbus is based on Unix domain sockets the security side puts at least 2 socket travels between application and service with dbus this is not free. When on BSD platforms where no one has invested the time to make optimized dbus implementation when needing security it comes can you tollerate the performance cost. On Linux with sd-bus and dbus-broker coding into your own application the secure bits you are more likely to screw it up and be slower..

Should your application use D-bus. The questions you need to answer with any answer being no equals you need to look else where like direct unix domain sockets and shared memory.:
1) Does this IPC communication need or could benefit the security polkit provides?
2) On the platforms you will be using Dbus is the performance cost of using Dbus acceptable?

Lot of desktop usage even on BSD the answer to both is yes. There are different cases for command line service control applications where using dbus interface made sense as well.

kpedersen attempt to find one cross BSD/Linux alternative to DBus protocol for what it does that is currently maintained. Yes it a surprise there is not one. Yes you hear BSD people say we don't want dbus used but no one BSD side has made alternative and no one on the BSD side has invested the time to make a good BSD dbus implementation.

[uid313]

We use UNIX domain sockets and shared memory (i.e shm_open(3), mmap(2)).

Things like dbus and tooltalk just feel so retro and fragile.

Unix domain sockets are so low level so you would still need to use something on top of it to pass data around such as gRPC or Protobuf. To use it for broadcasting and other scenarios than 1-to-1 you would need to implement some publish-subscribe pattern over it.

Well, if you take Unix sockets and add a service to start/resolve other applications by name then you basically end up with something like dbus.

DBus-broker is already pretty trimmed down, the only thing "desktop" specific is that it's a separate session per desktop.

But is D-Bus suitable for servers, embedded devices, IoT, for headless devices without Wayland? is it suitable for Ubuntu Core and Alpine Linux?

Depends on what you are doing and what your use case is. Do you want a message bus, or is point-to-point enough? Do you care about going between computers or just on the same computer? Do you need to move a LOT of data (in which case dbus is not the right option anyway) or just small amounts? What about your latency requirements?

Well, I was thinking it seems like an interesting piece:

• To build a robust high-availability system where different components are isolated so if one component crashes it doesn't bring down the whole system and with a watchdog it could restart that component.
• Have a modular and maintainable system where a module could be rewritten and replaced at a time without have to rewrite the entire system at once.
• Be able to have a heterogeneous systems where different modules could be written in different programming languages.
• Have different teams be responsible for different modules and be able to work at the same time.

So I was thinking like a publish/subscribe pattern. Low latency would be nice. I was thinking mostly broadcast/listen for small pieces of data, but it would be nice able to handle streaming of high-bandwidth data too, but maybe that would be a different use case that would be suited to be handled via some other IPC mechanism like use something like D-Bus for IPC between components and on the side also use a Unix domain socket for high-bandwidth data IPC.

[discordian]

But is D-Bus suitable for servers, embedded devices, IoT, for headless devices without Wayland? is it suitable for Ubuntu Core and Alpine Linux?

Sure, but not sure if you are serious.. there is really nothing depending on an Desktop environment - the biggest dependency is an XML parser that's only used for config files.

It's really fine as a generic IPC, sure it will lose out for handcrafted protocols for special needs.

[oiaohm]

But is D-Bus suitable for servers, embedded devices, IoT, for headless devices without Wayland? is it suitable for Ubuntu Core and Alpine Linux?.

Ubuntu Core does have dbus and it does make sense. Using polkit and dbus you can grant different users different controls over systemd. Alpine Linux you have dbus controls over openrc.

https://github.com/home-assistant/supervisor/issues/1328

There is a lot of things that simple fail server side when you don't have dbus.

Sure, but not sure if you are serious.. there is really nothing depending on an Desktop environment - the biggest dependency is an XML parser that's only used for config files.

It's really fine as a generic IPC, sure it will lose out for handcrafted protocols for special needs.

100 percent right that d-bus it self is not dependent on desktop environment being there.

The trap is like pymysql and many other things that don't depend on having X11 or Wayland depend on being able to use dbus to acquire particular system information or fail.

D-Bus for service management interfaces and lots of small task that without dbus would require raising privilege a lot is very suitable use case on headless servers. In fact you will cause yourself hell not having it.

Now embedded devices and IoT that are in most cases not highly complex setups avoiding dbus is possible.

All rounder solution like Ubuntu Core having dbus is kind of to be expected. By the way systemd can operate with dbus some features end up disabled all rounder distributions don't bother providing this option because there are so many other items that depend on dbus that are not graphical that you are going to get caught out by.

dbus-broker is way more suitable than dbus-deamon for server rules. Dbus-broker is faster and uses less ram. BSD users are stuck with dbus-deamon.

d-bus name being "desktop bus" does not align at all with how it used or how it designed. d-bus itself has no dependany on X11 or Wayland. Polkit was first designed to be used by console not graphical this is the part of dbus that has any X11 of Wayland dependency and that optional the console version of polkit has to be installed to have polkit.

The needs d-bus is design to service turns out to be useful outside the desktop.