Dbus is available on most systems now. I don't know what's the reason for the authors, but in practice with UNIX socket, you have issues like "which instance owns the socket", "how are the requests distributed", "how does an instance know the current handler died", "how to serialise and version the remote requests", etc. Dbus solves a lot of that without (effectively) designing your own custom underspecified version of half of dbus.
> but in practice with UNIX socket, you have issues like "which instance owns the socket", "how are the requests distributed", "how does an instance know the current handler died"
While bus-based publish-subscribe paradigm may have some merit in desktop setting, for direct control the client-server is much more straightforward, and in this case these answers are easy. Each instance owns one socket, if there are multiple instances and not a default one, a client needs to know which to connect to (as they are generally not interchangable), and even if they are, a client can just enumerate sockets and open the first alive.
> "how to serialise and version the remote requests"
These issues are irrelevant for connection-oriented and reliable unix sockets.
> Dbus solves a lot of that without (effectively) designing your own custom underspecified version of half of dbus.
Not really. Connection-oriented client-server solution is just much simpler that dbus and offers some advantages like implicit state associated with connection. Dbus makes things much more complicated and then solves some of these complications.
"These issues are irrelevant for connection-oriented and reliable unix sockets."
This comment is really confusing to me. It's not irrelevant, you need to serialize the messages somehow. And if you ever decide you want to add some new messages, then you have to deal with versioning. It's not simple. What you have described is just a cut down implementation of D-Bus. And you are leaving some other things out:
- race-free name resolution, the solution you described has a lot of race conditions
- message ordering, the best way to do this reliably across 3 or more processes is to use a bus-based method
- security, auditing, rate limiting, i.e. how does a system admin manage your service. This is all solved with D-Bus
I've seen lots of complaining about D-Bus over the years about how it's "too complex" but everything in it is there for a reason, and I've never seen anyone actually able to make a simpler design that works as well. If you implement all the stuff I just talked about then your solution will be about as complex as D-Bus. So in terms of message buses I actually think it is quite simple compared to other things like ActiveMQ. Please stop implementing ad-hoc protocols over a socket unless you have a really good reason to do that, it drives me nuts to see that stuff getting deployed and people going through the motions fixing the same bugs over and over. At the very least you could use protocol buffers, or use ASN.1, or re-use the D-Bus wire format, or do anything besides rolling your own.
to avoid Firefox from starting dbus, which is a Linuxism ported to BSD just to allow people to execute some applications. That works fine for me.
So since this is removed and Firefox is the only app that I use which needs dbus, I wonder if I will be required to use yet another useless (ie: not needed by OpenBSD) process just to use Firefox.
It's weird watching the Linux development community go from the position that Windows apps tightly coupling to Windows was bad because it made those programs more of a pain to run under Linux (most of the time requiring Wine) to deciding that sticking with cross-UNIX platforms was just no longer worth their time because Linux "won" the UNIX wars.
DBus (the software, rather than the protocol) isn't required on Linux anymore than it is on OpenBSD. It's required by the Plasma and GNOME desktop environments, most KDE and GNOME applications, and any other desktop environments or applications that want to use it.
It's also cross-platform, and runs natively on OpenBSD, NetBSD, and FreeBSD. It does not leverage a compatibility layer, and depending on it is in no way comparable to requiring an emulation layer like WINE.
Don't compare Linux and Windows, thats in bad faith. Developers just want to accomplish the best software they can, its all done in the open, but that doesn't mean they have to design software for other systems with different capabilities.
I would be really interested to know why people seem to think D-Bus is a "Linuxism". It's a pretty small daemon with an Apache-style license and upstream support for BSD. The only thing I've heard are comments like this where people find that D-Bus is required to run some GTK or Qt application, and those toolkits are viewed as being "Linuxisms", so people put it in that bucket transitively. Is there another reason I missed here?
Sway itself may not use dbus, I think that's right, but a desktop workflow built around sway for day-to-day use will typically utilize DBus for e.g., pipewire, a notification daemon, xdg-desktop-portal (screen sharing) at the least. But you are right of course that these are not sway and you don't need to use them. A typical user would need to be motivated to actively avoid it.
Sway does not use d-bus. It listens on a unix socket (different from the wayland socket) for control messages.
Gnome/Kde compositors don't use d-bus either, they instead use wayland extensions for control (since both the compositors and clients have to implement wayland already anyway, this is easier than using d-bus).
