dbus can also start a program. For example when one notification was generated and no notification daemon is running, then dbus launch one to handle the request.
Every 10 years, a new abstraction layer will be added to the system. I wonder how an average linux desktop would look like under the hood in 100 years.
There is a lot of ‘reinventing the wheel’ in software, and I did not claim otherwise.
When new abstractions are beneficial, other programs take advantage of them and the whole ecosystem moves forward. When they are not, nobody cares and they are ignored and die. In that respect, open source software development is very much like evolution.
Judging by apps using it, looks like this abstraction is indeed useful.
Look into history of object brokering in object oriented environments. I was around when KDE went from CORBA to DCOP to DBUS, but not involved in the decisions. Basically: object sharing between processes with security, type translation, and a few other things. In the Microsoft world, this was called “component object model” if my memory is correct.
Based on the various other descriptions of the DBUS features, I kept thinking “this sounds like a message passing model with a bit of CORBA hiding in there”. It’s got a bit of SLP and AMQP/MQTT to it, just on a local machine instead of a distributed network. It’s solving a lot of problems with service discovery, message passing structure, and separating transmission layer details from service API design. Raw sockets/pipes can always be used to pass data (it’s how DBUS does it!), but there’s additional problems of where to send the data and how to ensure data formatting that sockets/pipes do not have the capability of solving by design since they’re simple and foundational to how interprocess communication works in the kernel.
Dbus attempts to provide a standardized system for inter process communication (IPC) without the complexity of managing individual connections between each and every process that needs to share certain types of data.
But the implemenation has it’s fair share of issues and the attempted reimplementation even more so, because it wants to leverage everything important to Systemd instead.
While complex tuis are definitely not my cup of tea (I prefer cli tools to be simple, otherwise I would probably use a proper gui), I’m really happy that I’m not the only one wishing for a way to access lemmy from the terminal.
I love LMDE. Longtime fan of Mint, and recently changed all my ‘GUI’ machines over to LMDE. I tried pure Debian with Cinnamon, but it wasn’t the same. Mint makes it nicer, and I believe Debian is going to be their main base sooner than later, the way Ubuntu is going.
Sockets are just streams of bytes - no defined structure to them at all. Dbus is about defining a common interface that everything can talk. That means when writing a program you don’t need to learn how every program you want to talk to talks over its own socket - just can just use a dbus library and query what is available on the system.
At least that is the idea - IMO its implementation has a lot to be desired but a central event bus IMO is a good idea. Just needs to be easy to integrate with which I think is what dbus fails at.
A great example is music player software - rather than every music player software creating its own socket and each having its own API to basically all do the same operations. So anything that want to just play/pause some music would need to understand all the differences between all the various different music applications. Instead with a central event bus system each music app could integrate with that and each application that wants to talk to a music app would just need to talk to the event bus and not need to understand every single music app out there.
Wouldn’t this also be possible with plain sockets tho? To continue with your example of music players, the current standard is MPRIS, which uses dbus. But in an alternate universe, the people behind MPRIS could just have decided that music players shall create sockets at /run/user/1000/mpris/[player name] that all speak the same standardized protocol. If a player wanted to add functionality beyond MPRIS, it could accept nonstandard requests on its socket, or create a new socket altogether for extended control.
I just don’t see how this would require any more coordination between developers than the current solution. And I don’t see how dbus can save you from having to “understanding every single […] app out there”. If anything, it adds the overhead of learning how dbus itself works, on top of how a specific app’s dbus interface works.
Wouldn’t this also be possible with plain sockets tho?
You keep using this phrase. Given time and money anything is possible. Technically we don’t need to use http - every server could implement their own standard using raw sockets. You then could download a simple client library for every site!
With a well defined dbus interface your application can talk to any number of applications that implement that interface. Even those you didn’t know about it at time of development. It provides a structure for ipc other than “go fetch libblah” and also “libblarg” and “libfloob” and read all of their docs and implement each one separately.
Anything is possible with sockets… and that is a meaningless statement. It is like saying you can build anything with bricks. Technically true, but missing all the important details of how.
In an alternative universe we could have done so many things differently to solve the same problems. But we don’t live there and in our universe dbus was the attempt to solve that problem among others. And yes you can create a standardization for music players easily enough - but what about notifications, and everything else? DBus tries to be a generic interface anything can talk over at a logical level - rather that just being the basic way two process can physically send bytes between each other.
Thank you, that’s so kind! I’ll probably try to tackle the comments first as they come quite messy from the api, then I’ll probably give the images a go.
To be honest, I’m hoping this project doesn’t get out of my league too quickly as a have almost no experience with working with apis.
Want to exchange information in json? plaintext? binary data? Sockets can do it.
This is exactly why you need something like dbus. If you just have a socket, you know nothing about how the data is structured, what the communication protocol is, etc. dbus defines all this.
In either case you still need to read the documentation of whatever daemon you’re trying to interface with to understand how it actually works. Dbus just adds the extra overhead of also needing to understand how dbus itself works. Meanwhile sockets can be explained in sixteen words: “It’s like a TCP server, but listening on a path instead of an ip and port”.
It’s much easier to understand how dbus works once than to understand how every daemon you connect to works every time you interface with a new daemon.
Yeah that’s the case with programming… well anything. This at least gives you a way to automatically receive all of that data from any app without excessive prior knowledge. With a small amount of info you can filter for specific events and create all kinds of robust functionality. That’s the power of a set protocol - it is to make things widely compatible with one another by only depending on the dbus protocol and app name. Otherwise you may need to depend on some shared objects which makes deployment and maintenance a total clusterfuck.
You got downvoted for speaking the truth. You can’t talk to a dbus app without understanding how it communicates. You can’t talk to a sockets app without understanding how it communicates.
With pipes/sockets, each program has to coordinate the establishment of the connection with the other program. This is especially problematic if you want to have modular daemons, e.g. to support drop-in replacements with alternative implementations, or if you have multiple programs that you need to communicate with (each with a potentially different protocol).
To solve this problem, you want to standardize the connection establishment and message delivery, which is what dbus does.
With dbus, you just write your message to the bus. Dbus will handle delivering the message to the right program. It can even start the receiving daemon if it is not yet running.
It’s a bit similar to the role of an intermediate representation in compilers.
A message bus won’t magically remove the need for developers to sit down together and agree on how some API would work. And not having a message bus also doesn’t magically prevent you from allowing for alternative implementations. Pipewire is an alternative implementation of pulseaudio, and neither of those rely on dbus (pulse can optionally use dbus, but not for its core features). When using dbus, developers have to agree on which path the service owns and which methods it exposes. When using unix sockets, they have to agree where the socket lives and what data format it uses. It’s all the same.
It can even start the receiving daemon if it is not yet running.
We have a tool for that, it’s called an init system. Init systems offer a large degree of control over daemons (centralized logging? making sure things are started in the correct order? letting the user disable and enable different daemons?). Dbus’ autostart mechanism is a poor substitute. Want to run daemons per-user instead of as root? Many init systems let you do that too (I know systemd and runit do).
It can even start the receiving daemon if it is not yet running.
We have a tool for that, it’s called an init system.
The init system is for trusted system services that can talk directly to hardware. Unless you are working on a single-user system with no security concerns of any kind, you might consider using init to launch persistent user land or GUI processes.
DBus is for establishing a standard publish/subscribe communication protocol between user applications, and in particular, GUI applications. And because it is standard, app developers using different GUI frameworks (Gtk, Qt, WxWidgets, FLTK, SDL2) can all publish/subscribe to each other using a common protocol.
It would be certainly be possible to establish a standard place in the /tmp directory and a standard naming scheme for sockets and temporary files so that applications can obtain a view of other running applications and request to receive message from other applications using ordinary filesystem APIs, but DBus does this without needing the /tmp directory. A few simple C APIs replace the need for naming and creating your temporary files and sockets.
…systemd very much does use the init system to launch userland and GUI processes. That’s how GNOME works.
Dbus is for interprocess communication. The fact that its primary use case is communication between desktop applications is hardly relevant to its design. I don’t see how GUI frameworks are at all relevant, or how it would be possible to create an interprocess communication mechanism that only worked with one GUI framework without some heroic levels of abstraction violation (which I would not put past Qt, but that’s another story).
I don’t see why having an entire dbus daemon running in the background is better than having a cluttered /tmp or /run directory.
“Bro just use sockets lol” completely misses the point. When you decide you want message based IPC, you need to then design and implement:
Message formatting
Service addressing
Data marshalling
Subscriptions and publishing
Method calling, marshalling of arguments and responses
Broadcast and 1:1 messaging
And before you know it you’ve reimplemented dbus, but your solution is undocumented, full of bugs, has no library, no introspection, no debugging tools, can only be used from one language, and in general is most likely pure and complete garbage.
Well said. There are so many details to making code work that can so often be avoided by using the right tooling. OP said it was harder to get started, which implies they did not handle the details and have code not actually robust to all kinds of edge cases. Maybe they don’t need it but they probably do.
They’re Unix sockets, dude, they’re file paths in /run
Data marshalling
Still have to do that with dbus, also that’s the same thing as message formatting
Pubsub
Again, sockets. One application binds and many can connect (how often do you really need more than one application to respond to a method call? That’s a valid reason to use dbus in lieu of sockets, but how often do you need it?)
Method calling, marshalling of arguments and responses
They’re called “unix doors”, and that’s the third time you’ve said marshalling. As for that, language agnostic data marshalling is kind of a solved problem. I’m personally a fan of msgpack but JSON works too if you want to maximize compatibility. Or XML if you really want to piss off the people who interact with your API.
Broadcast and 1:1 messaging
Sockets and doors can only do 1:1, and that’s true enough, but it occurs to me that 99% of use cases don’t need that and thus don’t need dbus. dbus can still be used for those cases, but less load on dbus daemon = less load on system. Also you said that already with pubsub.
As for that blob at the bottom, again, who said anything about there not being a language agnostic library? It’d be a lot of work to make one, sure, but that doesn’t mean it’s impossible. Besides, most of the work has been done for you in the form of language agnostic marshalling libraries which as you said are like 50% of the problem. The rest is just syscalls and minor protocol standardization (how to reference FDs passed through the door in the msgpack data etc.)
And what I’ve just described isn’t a reimplementation of dbus without any of the good parts, it’s a reimplementation of dbus on top of the kernel instead of on top of a daemon that doesn’t need to be there.
This reminds me of QT’s signal/slot system. I.e. instead of calling functions directly, you just emit a signal and then any number of functions may have the receiving slot enabled.
Lot’s of similar systems in other frameworks too I’m sure.
It occurs to me that sendmsg() is already kind of a standard, and the problem of drop in replacements could be solved by just making the replacement bind to the same file path and emulate the same protocol, and the problem of automatically starting the daemon could be handled by a systemd socket (or even inetd if you wanna go old school). The only advantage that I can see dbus really having over Unix sockets is allowing multiple programs to respond to the same message, which is a definite advantage but AFAIK not many things take advantage of that.
Programs still have to be written to accommodate the specific protocol that the program on the other end speaks, and dbus paths could translate pretty directly to subdirectories of /run. All adding dbus in the middle does is add a daemon where there doesn’t need to be one and force the programs to talk to each other through that rather than directly to each other
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.