Does anybody know why dbus exists? I've been wracking my brain trying to come up with a usecase for dbus that isn't already covered by Unix sockets.
You want to remotely control a daemon? Use sockets. You want the daemon to respond to the client? Sockets. Want to exchange information in json? plaintext? binary data? Sockets can do it. Want to restrict access to a socket? Go ahead, change the socket's permissions. Want to prevent unauthorized programs from pretending to be someone they're not? Change the permissions of the directory containing the socket. Want network transparency? That's why we have abstract sockets.
Plenty of well-established software uses sockets. Music player daemon uses sockets. BSPWM uses sockets. Tmux uses sockets. Pipewire uses sockets. Dhcpcd uses sockets. Heck, dbus itself relies on sockets!
For developers, using sockets is easy. I once wrote a program that interfaced with BSPWM, and it was a breeze. Dbus, on the other hand, not so much. I tried writing a Python script that would contact Network Manager and check the WiFi signal strength. Right off the bat I'm using some obscure undocumented package for interfacing with dbus. What is an introspection? What is a proxy object? What is an interface? Why do I need 60 lines of (Python!) code for a seemingly trivial operation?
So why do some developers decide to use dbus when they could just use unix sockets and save a lot of hassle for themselves and others?
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".
This makes no sense because dbus uses unix domain sockets.
It sounds like you don't actually understand what dbus is.
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.
but you still have to understand the methods available in every 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.
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
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.