Dbus is harder to replace, since the complexity addicts at Redhat and KDE decreed it to be The Default Linux IPC, but realistically, most programmers who think they need could do with a solution 10% as complex and 10x as fast. (dbus-broker is a step in the right direction, but not radical enough.)
Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.
For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz.
I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great.
And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
It's like saying your init should basically be another entire operating system instead of just a service orchestrator; by reducing the API surface area, we not only increase security and decrease footprint, we also end up with composability and replaceable layers because other components might even be simpler but with the same API.
By defining this as a huge, complex problem that needs to be solved, the solution area naturally has to be much larger and encompass a far greater API and provide a lot more capabilities instead of the minimum capabilities to accomplish the far more limited goal.
Growing the problem domain and thus the solution is always a huge temptation but ultimately results in the opposite of modularization and good system design.
I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality.
On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me.
But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.
- which user/privilege level is the caller running as?
the kernel already knows this. Which file-based operation doesn't know the privilege level of the caller?
- highly and quickly reactive (or what we used to call "event driven")
inotify/fsnotify?
- impose authentication and access controls
built-in to the filesystem, or use SO_PEERCRED on sockets?
- and there's no pre-defined schema
What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema?
AFAIK, the only thing that files cannot do by default is data broadcast: if you have multiple readers on a file or socket, only one of them will receive the data written. For that, you would need to keep track of the number of readers and give each (passive) listener its own connection.
If all you're doing is reading/writing kernel stuff, then those will be sufficient. But if you're building a user-space service or daemon that will read/write to/from other user-space processes, then /proc and /sys don't help. If you want to use files you will have to agree and standardize on a format. For example, use YAML? ok, but which properties are mandatory, which are optional? What will their hierarchy look like? Even what is (are) the file name(s)? How do you handle adding/removing properties, maintaining backward compatibilty?
> inotify/fsnotify?
You can get a lot done with inotify and fsnotify, but there's a lot of overhead involved too. It is also somewhat fragile, some might say "hacky". It's certainly not something I would want to build on top of for a production important service. If you want a reliable Pub-Sub, (so for example, your new application1 wants to subscribe to a number of different types of events/notifications about network changes from Network Manager) you have to hope that NetworkManager is writing that to files, find out which files it is, register a watch on them, read them when they change, parse the data (and have to agree on a data format or "schema" with NetworkManager), and do your thing. Now want to send something back to Network Manager based on what you read? Gotta write to a file, and hope that NetworkManager is already coded to watch that file with inotify/fsnotify, and already agrees with the data format (or "schema"). When you control both sides it's not hard, but when both sides are completely independent with their own goals/priorities and preferences, it can get hairy. These are largely problems that go away with something like D-Bus.
JSON would be nice for the easy users, but you do wany to exchsnge binary data over IPC, so that would maybe be a bit too simpld. I don't have any strong preferences when it comes to binary serialization/rpc protocols, though.
It's putting Unix sockets in /var/run with the correct permissions.