Replace D-Bus with a much simpler system

[probonopd]

Looks like I am not the only one who finds D-Bus utterly confusing, overcomplicated, and badly documented. Also I have the growing suspicion that it is not fast.

https://www.hyperbola.info/todo/dbus-mitigation/

People have done it before:

2022-06-15 - Tobias Dausend

With the release Milky Way v0.4 all parts of D-Bus got completely removed and all included packages within our repositories were selected to be completely usable without any message-oriented middleware and framework. We don't plan to integrate any further support for the framework also in the future for upcoming versions of Hyperbola GNU/Linux-libre and HyperbolaBSD.

https://www.hyperbola.info/news/end-of-d-bus-support/

But:

What about existing applications, including those from Linux? We'd need at least some minimal runtime compatibility layer that would mimic D-Bus "legacy" interfaces for existing applications.

[rodlie]

So, you are going to replace dbus and also provide a wrapper for dbus? Because you find it confusing? Well, good luck with that one ;)

dbus is a core part of a usable desktop, think twice before dropping it.

Also, what's so confusing anyway? You have services and clients, they communicate using simple messages.

[probonopd]

Also, what's so confusing anyway?

E.g., Methods, Interfaces, Services, Destinations, Object Paths,... no conistent documentation...

As an example: https://github.com/helloSystem/Menu/issues/85#issuecomment-1289443123

[markusbkk]

I'm currently trying to pick up my own OS development again. I last worked on my OS in early 2019 and mostly stopped software development after my wife's passing in 2020.

Most of my software is inaccessible due to a raid by the German Staatsschutz (Very nice guys... Don't mention the war...) but I think I still got an older version of my concept IPC BUS stored away on my original GitHub account, and I have a pretty decent idea of how to make it work and document it.

Haven't read all of the Wiki, yet. What's your opinion on the Go programming language and gRPC? Can a binary written in Go and utilizing gRPC for its communication/documentation layer be used within the scope of helloSystem?

[probonopd]

Hi @markusbkk, thanks for chiming in.

The real challenge will probably be to maintain some minimal viable level of support for applications that are written for D-Bus, and I have no grip on how complex having such a "compat interface" would be. Ideally we would re-implement the <2% of D-Bus that are actually needed as the absolute bare minimum, e.g., for Global Menus to work in existing applications, and have noops for everything else.

If we just could drop D-Bus compatibility altogether, we could just as well use e.g., https://openwrt.org/docs/techref/ubus, https://skarnet.org/software/skabus/, https://gitlab.redox-os.org/redox-os/ipcd, or something like that. But we need to also stay compatible to the most used aspects of D-Bus that existing appliciations rely on.

About Go, all I can say is "go for it". :+1 Even though helloSystem will still be caught in C++ with Qt libraries for the foreseeable future due to the use of Qt.

I don't know gRPC but it already looks relatively complicated.

Maybe https://github.com/godbus/dbus could be used ("Complete native implementation of the D-Bus message protocol") to write a "compat" interface in an newly written IPC server.

GLib should be avoided as a dependency.

DBus-Broker, an alternative implementation of D-Bus, is out of the picture because:

DBus-Broker continues to be worked on by many of the same Red Hat developers involved with D-Bus (...) This D-Bus message bus is written against modern Linux kernel features and is designed exclusively for Linux systems.

Source: https://sysdfree.wordpress.com/2018/04/25/201/

[markusbkk]

The real challenge will probably be to maintain some minimal viable level of support for applications that are written for D-Bus, and I have no grip on how complex having such a "compat interface" would be. Ideally we would re-implement the <2% of D-Bus that are actually needed as the absolute bare minimum, e.g., for Global Menus to work in existing applications, and have noops for everything else.

Yea. I thought about this, too. I think Firefox would be the ultimate target here, since it uses DBus extensively.

About Go, all I can say is "go for it". :+1

Yea. I just saw you were writing applications in Go before, too. Small world 🐱

I don't know gRPC but it already looks relatively complicated.

It's actually fairly simple, once you've mastered protoc. It makes client/server communication Just Work™, there's a beautiful and easy to use documentation plugin, and you can even build REST endpoints (OpenAPI documentation included) with it if you so choose.

Maybe https://github.com/godbus/dbus could be used ("Complete native implementation of the D-Bus message protocol") to write a "compat" interface in an newly written IPC server.

That does indeed look fairly decent and somewhat battle tested. I like that fyne/fynedesk use this, since I have experience with their stack already.

GLib should be avoided as a dependency.

Agreed! My own internal designs recently got rid of GLib and, like a scorned ex, I'm not taking it back.

DBus-Broker, an alternative implementation of D-Bus, is out of the picture because:

DBus-Broker continues to be worked on by many of the same Red Hat developers involved with D-Bus (...) This D-Bus message bus is written against modern Linux kernel features and is designed exclusively for Linux systems.

Source: https://sysdfree.wordpress.com/2018/04/25/201/

Haven't followed BUS1 in a while, but that was to be expected. BUS1 (previously known as KDBUS/Kernel DBus) has always been about Linux IPC. To my knowledge, Lennart and the rest of the systemd team have never particularly cared for BSD.

[probonopd]

So if I understand it correctly, in the end D-Bus is "just" a Unix socket over which the "D-Bus message protocol" is spoken; and https://github.com/godbus/dbus happens to implement that protocol? So what needs to be done in order to replace dbus-launch?

Is there a way to listen in on (dump) what is communicated in the Unix socket?

Need to do something along those lines: https://forum.ivorde.com/freebsd-how-to-sniff-a-unix-socket-using-socat-utility-t15931.html

[markusbkk]

So if I understand it correctly, in the end D-Bus is "just" a Unix socket over which the "D-Bus message protocol" is spoken; and https://github.com/godbus/dbus happens to implement that protocol? So what needs to be done in order to replace dbus-launch?

Is there a way to listen in on (dump) what is communicated in the Unix socket?

Need to do something along those lines: https://forum.ivorde.com/freebsd-how-to-sniff-a-unix-socket-using-socat-utility-t15931.html

It's a daemon and there's actually two of them running at any time (one for the entire system, one for just the user session). But yes, it uses UNIX sockets under the hood.

You can monitor/dump all communication through dbus-monitor

[markusbkk]

I don't want the new bus to suffer from feature creep, but I think the way Plan9 does things might provide a nice abstraction over the "standard way" I'm implementing first:

http://doc.cat-v.org/plan_9/4th_edition/papers/plumb

[probonopd]

You can monitor/dump all communication through dbus-monitor

We need to see the raw byes, so that we can reimplement it without GLib dependencies.

[markusbkk]

You can monitor/dump all communication through dbus-monitor

We need to see the raw byes, so that we can reimplement it without GLib dependencies.

I'll look into it.

Here's just some quick information that might be helpful later:

https://github.com/freedesktop/dbus/blob/master/tools/dbus-monitor.c#L219 https://dbus.freedesktop.org/doc/api/html/group__DBusMarshal.html#details

[markusbkk]

Haven't spent much more time with this because life and other projects got somewhat in the way, but I stumbled upon varlink today.

It's not a classic bus system but allows services to talk to each other in a more direct fashion. Not sure how Linux specific it is, alas.

[probonopd]

https://github.com/helloSystem/LinuxRuntime/issues/2#issuecomment-1647733881 has a working way to allow applications running as root to communicate with the session bus of a normal user. The trick is to use TCP instead of Unix sockets, which seems to be less restrictive about which user accesses it. If anyone knows a simpler/better way, let me know.

[jsm222]

There is this https://github.com/bus1/dbus-broker/wiki but they state explicitly Linux only...