There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

What is the point of dbus?

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?

ninekeysdown ,
@ninekeysdown@lemmy.world avatar

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

ILikeBoobies ,

Dbus is a better name

smpl ,
@smpl@discuss.tchncs.de avatar

I will conveniently avoid any dbus talk, because the why is not so interesting as the how and direct you to this path /var/run/wpa_supplicant. You would probably send SCAN_RESULTS on the socket, you could also initiate a SCAN first to include the strength of stations you’re not connected to. If you want deeper access to wireless, you use netlink to communicate with the kernel (see /usr/include/linux/nl80211.h) and poke some NL80211_STA_INFOs… or the other direction (everything is a file) you just parse /proc/net/wireless without any special permissions for the current signal strength.

Oh… and btw dbus has a simple binary protocol underneath all the XML/interface fluff and uses a UNIX socket.

possiblylinux127 ,

Its so that your system can hold passengers

bus

norgur ,
@norgur@discuss.tchncs.de avatar

Get into de bus?

MonkderZweite , (edited )

Btw, why do i need to start xfce/xfwm with dbus for automount in thunar to work, instead of just running dbus as a service on the side?

fiohnah ,

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.

bizdelnick ,

Multicast.

corsicanguppy ,

Lennart said so.

troyunrau ,
@troyunrau@lemmy.ca avatar

No. DBUS has its roots in freedesktop.org and the KDE+Gnome projects. It’s basically a desktop agnostic reimplemented of KDE’s DCOP, which was itself a simplified CORBA (gnome was using ORBit at the time, if I recall correctly). DBUS was so useful that the domain spaces its been applied to soon rapidly outgrew the desktop space, and this is why it’s usually started earlier these days.

It also works on Windows.

nickwitha_k ,

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.

xia ,

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. en.m.wikipedia.org/wiki/Enterprise_service_bus

avidamoeba ,
@avidamoeba@lemmy.ca avatar

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

teawrecks ,

I’m learning a lot, so I’m not a fan of the people flaming and downvoting OP for having genuine confusion. I want us to incentivize more posts like this.

LemmyHead ,

Same here. I’ve always wondered what dbus actually was and I’m glad OP asked

cbarrick ,

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.

renzev OP ,

modular daemons

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).

aport ,

“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.

nous ,

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.

WarmApplePieShrek ,

The Linux kernel is already a central event bus of sockets, btw

troyunrau ,
@troyunrau@lemmy.ca avatar

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.

azimir ,

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.

ipsirc ,
@ipsirc@lemmy.ml avatar

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.

RedKrieg ,
@RedKrieg@lemmy.redkrieg.com avatar

Doesn’t systemd have the ability to do this as well with unix sockets?

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •