Dbus-Broker 28 Released

[phoronix]

Phoronix: Dbus-Broker 28 Released

With still no sign of BUS1 on the horizon for the mainline kernel or any other successor to BUS1 or KDBUS for in-kernel IPC, Dbus-Broker remains the best bet currently in 2021 for a more performant D-Bus implementation while retaining compatibility with the D-Bus reference implementation...

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

[tildearrow]

I think Broker should be the only active project:

1. KDBUS poses a security risk
2. BUS1 means reinventing the wheel and therefore having to rewrite every application

[cl333r]

I think Broker should be the only active project:

2. BUS1 means reinventing the wheel and therefore having to rewrite every application

This shouldn't be an excuse if BUS1 is a lot better. I'd for one use it if it's easier to learn and use (not to mention faster).

[LightBit]

I think Broker should be the only active project:

1. KDBUS poses a security risk
2. BUS1 means reinventing the wheel and therefore having to rewrite every application

So add BUS1 and use Broker for old applications.

[scottishduck]

I’ve always been curious about what the performance of these actually means for the end user

[uid313]

I don't know the difference between message broker, message queue, message bus, service bus, enterprise service bus, etc. 😕️

[discordian]

I’ve always been curious about what the performance of these actually means for the end user

Kinda the same like wayland vs X11. You wouldn't know, unless some singular process is exhausting globally shared resources. Dbusbroker is doing its job more reliable/isolated.

[intelfx]

I think Broker should be the only active project:

1. KDBUS poses a security risk

kdbus does not pose any security risks, where did you get that notion?

2. BUS1 means reinventing the wheel and therefore having to rewrite every application

BUS1 does not "reinvent the wheel". It implements a completely different idea of an IPC, one that was suggested by kdbus reviewers in fact.

[ssokolow]

I’ve always been curious about what the performance of these actually means for the end user

My understanding is that the value proposition for things like KDBUS and BUS1 is similar to how Rust gets marketed. It's not so much about the performance of current uses, but about enabling programmers who currently point their efforts elsewhere because there's nothing that meets requirements without being difficult enough to use that they don't feel motivated to do it as a hobby project.

(eg. Zero-copy IPC can be used for streaming decoded media between applications as long as the per-packet overheads and latency aren't crazy and, currently, you have to resort to stuff like rolling your own from shared memory. Something like KDBUS or BUS1 would be more like how, in Rust, if you send a Vec<T> from one thread to another, you're just sending a 24-byte (data pointer, capacity, length) stack object that acts as the ownership token for the on-heap memory which doesn't move, and the compiler takes care of making sure you actually follow the access-control semantics of such a paradigm without imposing runtime overhead.)

[tildearrow]

kdbus does not pose any security risks, where did you get that notion?

Bug in KDBUS = Buffer overflow = Exploit and since KDBUS runs in kernel space = Potential privilege escalation

Bug in D-Bus or dbus-broker = Buffer overflow = D-Bus runs in user space and on its own user = No privilege escalation

BUS1 does not "reinvent the wheel". It implements a completely different idea of an IPC, one that was suggested by kdbus reviewers in fact.

It does reinvent the wheel since D-Bus already exists and BUS1 is a completely unrelated thing.
On the other hand, dbus-broker keeps compatibility