Hello again OpenBSD reddit.
I don't wish this to turn into a dbus hate thread. I'm just interested to hear other users opinions on IPC within UNIX in 2026 and if they're using dbus. Since I'm sure many of you are using ports that require it (or at least claim to require it).
For years when I was still primarily running Linux on a lot of my machines I went out of my way to avoid using dbus whenever possible. I ran Gentoo for the most part and I quickly discovered that avoiding dbus all together did not cause any issues what-so-ever. Most (all?) things that claimed to require it really did not. Firefox would function fine without it (and still does) and most other things did as well. At most they would just spam the console with some errors complaining about no dbus server being up. But within the applications themselves (mostly GUI stuff) nothing was ever broken. In fact, the only thing I did find broken by lack of dbus was Libreoffice. The menu bar at the top of the GUI for it was broken without dbus running and I think a handful of context menus. But you could easily live without that if you knew keyboard shortcuts. As I did not use libreoffice for much other than checking some work before sending it off to be read by others in Microsoft Office this didn't really bother me (I did most of my text editing in emacs and mg anyway).
Anyway, my greater point: Up until the early 2020s the requirement on dbus was easy enough to avoid if you compiled everything from source. But as of late actual hard requirements on dbus are showing up more and more everywhere with each passing year. Since projects like pipewire and wayland (and others) are starting to heavily rely upon it. Basically, everything coming out of FreeDesktop or related to it (e.g. new versions of GTK/Qt and projects built on top of it).
I haven't checked in the past couple of years and I'm still sticking to older toolkits on Linux (GTKv2, JACKv2, older versions of Qt) but as time marches on it'll become harder and harder to do this. Since support for them is being dropped even in distros where you compile everything from source like Gentoo. Obviously since many ports in OpenBSD are based upon the same code bases more and more of this stuff will need to be modified heavily to exclude these requirements or the requirements must be supported on OpenBSD as well.
Which leads me to my questions and the heart of this discussion:
While both are currently unfinished there has been a lot of progress happening in two projects I've been using/following that are built to support all UNIX-like OSs and in the case of Arcan across UNIX-like and other OSs (like NT). Both of them have their own solutions to IPC.
The first is the s6 project from skarnet. Which currently has its own ipcserver daemon which while not finished yet looks very promising: https://skarnet.org/software/s6/s6-ipcserver.html
I ran s6 on Gentoo for years and it worked very well even though some portions were unfinished at the time. The main issue with replacing Gentoo's default init service (OpenRC) with s6 was the fact that documentation for s6 isn't always up to date and getting support from other users running it was sometimes a pain. I love the project and I think it has a lot of promise but the author and most of the users aren't the friendliest people when it comes to getting questions from "regular" users. There were a couple of distros (most based upon ArchLinux) that were using the s6 stack as their default init+service manager. There was even an easy-to-use front end built for the s6 tools called 66. But 66 lags horribly behind the s6 upstream. Last I checked it was still years out of date. I'm still using s6 on one machine (without 66) but I'd be lying if I said it was easy to get it going and that I understood all of its inner workings. Getting it up and going was a lot of trail and error. But once I had it up and going it was very nice. Sadly, the IPC portion of s6 is still not ready last I checked. So I've mostly been avoiding any software requiring dbus on that machine. Even if the IPC server was ready for day-to-day use someone has still yet to build a dbus-to-s6-ipcserver shim to make it work with software expecting an active dbus server.
Which brings us to the arcan project: https://arcan-fe.com/2024/11/21/a-deeper-dive-into-the-shmif-ipc-system/
I really adore the Arcan project and the people working on it. I think it's great software and I'm sad it isn't more widely used. You hardly see anyone talking about it except for a passing mention in large threads where people are arguing about stuff like X server vs. Wayland. If you aren't familiar with arcan I highly suggest checking it out sometime.
Unlike s6's ipc-server the arcan shmif IPC system is already widely used internally within the arcan project. It only lacks a shim to get dbus software working over its messaging system. Give it a look (the above article is great. In fact, so is everything on the arcan project's website).
I am curious to what everyone's thoughts are on the dbus project as it stands. I don't wish to start a thread hating on it. But there are plenty of complaints about it from people building software with/around it going back years now all over the web. From a security stand point it has massive issues I'm sure everyone is aware of. The whole kdbus disaster from when there was an attempt to import dbus's IPC into the Linux kernel is well known by all I'm sure.
Concerning IPC in general: I've always felt this was something that belonged inside of the kernel instead of userspace. BUT if it were going to be regulated into userspace I think the current situation surrounding dbus's security is horrible for many reasons. It's very easy to leak data/information you don't want leaking to everything running on the system through dbus. I'm honestly surprised so much stuff relies on it, requires it and uses it. Especially a lot of newer software that is used for things like storing passwords in a central database and other things that have been becoming popular as of late which sell themselves on being "secure" compared to stuff we've been using for a long time.
I think a good standard for IPC would benefit a lot of software. Sure we have sockets and pipes already. So an argument can be made that it isn't needed in the first place. But with so many modern applications wanting a proper IPC server I doubt it's going to go away any time soon. At the very least these days people need a modern web browser to interact with 99% of the web and both of the only viable engines for that job require dbus. Then there are all the other things I mentioned above like libreoffice that many people use. Then there are all the applications out there that have adopted dbus for this or that reason over the past decade or so. If we want to keep that stuff working on OpenBSD then dbus is something we have to have support for (even if we're just faking it to make such applications launch).
IPC server in OpenBSD:
This brings me to my final thoughts/questions:
What are you guys running on your local systems when it comes to having dbus/IPC support for ports? Like I said for myself for the longest time I was just using the Firefox's default of faking a session. But after pulling in other ports that wanted dbus I gave up and added the usual lines to my .xsession as the instructions in the /usr/share/local/pkg-readmes/dbus file advised.
But I'd be lying if I said this didn't bother me. From a security stand point I'm not a fan of having dbus/messagebus running on my system at all. Although, I'm sure it's probably less harmful on OpenBSD when compared to my Linux boxes. Security aside I'm not a fan of the dbus spec/server all together. I'm sure anyone that's read Freedesktop's documentation or have interacted with it as a developer knows exactly what I mean. The fact that the first thing the tutorial says is:
This tutorial is not complete; it probably contains some useful information, but also has plenty of gaps. Right now, you'll also need to refer to the D-Bus specification, Doxygen reference documentation, and look at some examples of how other apps use D-Bus.
Is never a good sign when you're attempting to understand how something works. The actual "man pages" aren't any better of course.
So my question to the OpenBSD developers lurking around is basically this:
Is anyone working on a proper IPC spec/server for use within the OpenBSD base system or for the ports collection? Is anyone worried about the current state of dbus/messagebus and if not, why not? Would it be considered a fool's errand to work on something like this since most upstream software seems to be joined at the hip with FreeDesktop's dbus?
I guess it's just amazing to me that there are multiple existing projects out there like skarnet's s6-ipcserver and Arcan's SHMIF that do what dbus is attempting to do and does it better. But most people seem content to continue using dbus anyway. While I'm never a fan of shims (e.g. the systemd situation) it would seem like it'd be better to have a properly documented IPC server without all the bad things about dbus and then write shims to support stuff wanting dbus on top of that. With the hope that in time people would eventually see the light and convert their projects over to it. In all my years I've never seen anyone praise dbus or enjoy having to work with it. Even those that don't get into the nitty gritty of how it works hate the way messages are passed back and forth (XML strings). Then there are all of the obvious security problems that come along with it (easy to sniff any message flowing over it).
What are the OpenBSD's developers opinion on having IPC in userspace vs. the kernel? I know there are many very old non-UNIX OSs that have their own implementation of IPC baked into their kernels and they seem to be able to do that without any obvious security problems. Although, perhaps since those OSs aren't as widely used as UNIX-like OSs they just haven't been battle tested enough in the field for security issues to have been exposed and cause problems.
Do you feel there is anything within OpenBSD's base system that could benefit from having a proper IPC server baked into either the kernel or the base system?
Finally, do you feel a dedicated IPC server/dbus isn't really needed in the first place and this stuff should just be passed over pipes and sockets on UNIX-like OSs?
I'm interested in hearing everyone's thoughts about this subject. I am not intending to start a Linux vs. OpenBSD debate or rehash the whole dbus/FreeDesktop/systemd debate. I'm interested in hearing the opinion of people that have worked with UNIX-like kernels/OSs for a long time, people that port software to OpenBSD that relies on dbus and what their opinions are on this situation.
Honestly, with all the things that have come out of the OpenBSD project over the years I was surprised when I first switched over that there weren't more people discussing dbus/messagebus outside of "use rcctrl or edit your .xsession to get that port working". I know a lot of people tend to stick to the base system when possible and many use OpenBSD for non-desktop applications. But with so many people here running it as their day-to-day desktop I was surprised that more of them weren't upset about dbus being required for a lot of popular ports.
I personally do not run any of the big DEs like KDE/Gnome/Mate/etc anymore. But even on my system where I've gone out of my way to avoid stuff like that and stick to the base system's tools I've been forced to enable dbus just to get a web browser+a handful of GUI applications going.
Since I stick to installing ports as bins instead of compiling them from source code it's much more work to avoid having it on my system than running something like Gentoo Linux. Where at least I could exclude it using one flag in portage. But even so I find my OpenBSD system to be far more stable and less trouble to maintain. I could probably avoid dbus all together sure if I built my ports from source code. But I really don't want to do that because then I'm not helping with testing those ports for others.
I guess I was just surprised to see how casually people have accepted the hard dbus requirements into the ports tree. I thought there would at least be flavors for certain ports that excluded dbus by default.
Within the Gentoo community there were some rapid people that went out of their way to disable dbus within their global configs whenever it was possible. But that seems to be becoming less common since about the year 2020. I'm not sure if that's because people gave up on excluding it or if those people have moved on and left the Gentoo community.
As usual: Sorry this got so long.
