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.

Because this

potentially has a much larger average degree distribution than this

Easy... decoupling. You hit the pause button on your keyboard, it does not need to "know" (in code or compile time or at runtime) what your music player is, and it can still pause it. Similarly, you can write a new media player, and not have to convince 1000 different projects to support or implement your custom api. https://en.m.wikipedia.org/wiki/Enterprise_service_bus

Sockets are effectively point-to-point communication. Dbus is a bus. Your question is similar to "what is the point of I2, or an ATA bus when directly wiring ICs gets the job done". Both have different strengths and weaknesses.

Some heavy schooling happening in this thread. Glad to see it. Learning is a good thing. 🙌

My serious answer, not an argument: Use d-feet to inspect what's available on the system and session buses. That'll show the benefit of introspection and a common serialization mechanism.

About the security comments: Some access control mechanisms aren't just allow/deny, and many need more than socket permissions. Those benefit from DBus policies, and PolicyKit integration helps for more complex needs. You can always DIY it, that's Linux/FOSS life, but these are great tools to have in your toolbox. I'll avoid credential passing via sockets whenever I can and have something else do it.

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.

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.

DBUS is pretty nice for complex interactions.

I don't know but I'm interested in the answer.

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.

https://en.m.wikipedia.org/wiki/D-Bus

It would not be created if existing plumbing covered all use cases.

Don't assume you know better and that developers are simply reinventing the wheel.

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.

Yes, of course, the sockets are the answer to everything (and BTW, d-bus uses sockets as well, e.g. /run/dbus/system_bus_socket on my current system), but the problem is no standard for the communication over these sockets (or where is the socket located). For example, X11 developed one system of communicating over their socket, but it was used just by few X11 programs, and everybody else had their other system of communication. And even if an app found some socket, there was absolutely no standard how exactly should programs communicate over it. How to send more than just plain ASCII strings? Each program had to write their own serialization/deserialization code, their own format for marshalling binary data, etc. Now there is just one standard for those protocols, and even libraries with the standard (and well tested) code for it.

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.

Its so that your system can hold passengers

Multicast.

What's the point of sockets?

I'm a firm believer that the vast majority of things we needed for software were implemented by the 2000s.

Usually, people who don't understand what they're doing will overcomplicate things to cover-up their misunderstandings. I think choosing a technology before you have a use-case is one of these examples.

I just came across this - https://fedoramagazine.org/d-bus-overview/ - and I think it explains it pretty well.

Lennart said so.