Why do we need d-bus?

Zirias

Son of Beastie

Reaction score: 1,519
Messages: 2,640

Can all of these not be achieved with a suid-exec helper binary with specific groups for the authorized users?
Just for the example of shutdown, it's a pretty common requirement that you want to allow a local user to do so (if logged in and running a session), but not the same user when connected from remote.

The window manager and screen locker stuff should almost certainly be X11 messages by definition. Things like xlock / xlockmore seem to work fine. Is there a specific functionality you find is missing that can only be improved with dbus (or other)?

I imagine one valid reason for IPC is because many Wayland compositors fail to support X11 style messages. But... well Wayland is trash ;)
You could just as well argue X11 is "trash". With screen locking, problems exist for sure:

I don't use wayland (yet?), maybe it isn't a good solution, we will see. I think the basic idea isn't all that bad (remove a lot of cruft nobody uses any more, focus on the main job…)

edit: btw, talking about X11 style messages IMHO kind of underlines the need for communication :cool:
 

kpedersen

Son of Beastie

Reaction score: 2,083
Messages: 2,945

Just for the example of shutdown, it's a pretty common requirement that you want to allow a local user to do so (if logged in and running a session), but not the same user when connected from remote.
A setuid binary can also check who is logged in and at what terminal. Ultimately it would do it in exactly the same way as the service program connected to the other end of something like dbus / bonobo.
You could just as well argue X11 is "trash". With screen locking, problems exist for sure:

Just had a quick flick through these issues. The first one is due to some naff KDE theme problem, not X11 so I will jump past that. The second one says that X11 screenlockers can be blocked by other programs connecting to X11. Luckily in "modern" X11 that is impossible because X11 doesn't listen on public or TCP sockets (you probably know this but so many others don't!). No program can communicate with it but trusted ones any more than in Wayland compositors.
I think the basic idea isn't all that bad (remove a lot of cruft nobody uses any more, focus on the main job…)
Re-inventing the wheel (badly) and calling it dbus only to remove the X11 messaging system calling it cruft is absolutely incorrect quite frankly. Good luck to them. It is a train wreck that will be fun to watch from the sidelines.
 

astyle

Daemon

Reaction score: 467
Messages: 1,079

I was going to make a point about why there are so many kinds of dbus installs in ports tree. Then, I honestly couldn't make as strong a case as I thought I would, about this particular one.
Code:
~ % psearch dbus | grep -vi api | grep -vi interface | grep -vi binding
comms/libmodbus           Modbus library
devel/dbus                Message bus system for inter-application communication
devel/dbus-sharp-glib     D-Bus for .NET: GLib integration module
devel/dee                 Model to synchronize multiple instances over DBus
devel/kf5-kdbusaddons     KF5 addons to QtDBus
devel/libdbusmenu         GLib and Gtk Implementation of the DBusMenu protocol
devel/libdbusmenu-qt      Qt5 implementation of the DBusMenu protocol
devel/linux-c7-dbus-libs  Libraries for accessing D-BUS (Linux CentOS 7.9.2009)
devel/ndesk-dbus          C# implementation of D-Bus
devel/ndesk-dbus-glib     GLib main loop integration for Managed D-Bus
devel/p5-AnyEvent-DBus    Seamlessly integrate Net::DBus into AnyEvent
devel/p5-Net-DBus         Perl extension for the DBus message system
devel/py-jeepney          Low-level, pure Python DBus protocol wrapper
devel/py-python-dbusmock  Mock D-Bus objects for tests
devel/py-qt5-dbussupport  Qt event loop support for dbus-python
devel/qt5-dbus            Qt D-Bus inter-process communication module
ports-mgmt/packagekit     DBUS packaging abstraction layer
x11/appmenu-registrar     Appmenu DBusMenu registrar
Perhaps qt5-dbus is better implemented than regular dbus? Now, I don't use Linux emulation on FreeBSD, at least not the way it is now. As if I were going to use it, I would use a separate Linux desktop or hardisk/partition for purposes that I don't use on FreeBSD. However, devel/linux-c7-dbus-libs is ridiculous, that they don't use regular devel/dbus, and build the rest of Linux on FreeBSD on top of those kinds of dependencies. It's redundant. Also, this isn't just dbus, there's lots of duplicates for Linux emulation. It's like riding a bike with no hands, so the person can hold two other bikes, where those two other bikes don't need to go anywhere.

It's missing the point, the reason a lot of people use FreeBSD is because the base system has the essentials about once, and not duplicated 50,000 times. Then, it's like people want to defeat the purpose of having an operating system that's designed well at its base. If there's going to be Linux emulation, shouldn't it be something like Alpine that a lot of people say is good? Then again, the ones using Alpine Linux aren't porting their emulation.
Why am I under the impression that all those packages are just different libs for providing a API to access the dBUS in the first place? Kind of like having different web browsers accessing web pages.

Oh, and this:
It's like riding a bike with no hands, so the person can hold two other bikes, where those two other bikes don't need to go anywhere.
I have done it on an actual bicyle... Rode 3 miles to drop them off at the shop. :p
 

sidetone

Daemon

Reaction score: 908
Messages: 1,857

Why am I under the impression that all those packages are just different libs for providing a API to access the dBUS in the first place? Kind of like having different web browsers accessing web pages.
I hoped they were API related. The more obvious ones were omitted in my psearch command.
Oh, and this:
I have done it on an actual bicyle... Rode 3 miles to drop them off at the shop. :p
That's for a reason though.
 

garry

Active Member

Reaction score: 106
Messages: 118

I've been in engineering meetings in our (previous job) German headquarters and I can tell you that those German engineers were very intense in the argumentation. The debate was intense and hot. After all the president of the company was sitting there to hear the technical merits and make a decision. There was pounding on the table, and yet it was completely rational. No one was accused of "hate" for holding the contrary opinion on some policy or software engineering issue. They were asked to give their reasons (I had some strong opinions and voiced mine too).

The word "hate" has been used in this discussion several times. That particular insult has crept in from Linux where technical arguments that expose flaws in That Which Has Been Ordained are trigger-warning labeled as "hate" speech and everyone knows to stop talking about it. You all have noticed this.

Well, I'm noticing that argument here. Those who recommend that dbus be avoided, or re-implemented, in our systems are said to hate the modern. When I sniff the merest scent of that inverted hate speech I know that the poster should be ignored. Some of the great technical content here has been diluted by this brain-washing technique.
 

Jose

Daemon

Reaction score: 982
Messages: 1,183

For a bit of history, KDE used something very similar, CORBA, in the past. They later decided to drop it and introduced DCOP instead, which was already a message bus/broker architecture (and was then dropped in favor of d-bus, to support a common standard).
CORBA and other remote-objects frameworks like SOAP, EJB, etc. were what was considered "modern" back in the late '90s and early Aughts. They were an unmitigated disaster, and I know of no one who uses them today. You'd certainly get laughed at if you proposed using them nowadays. Yet, they were "modern" and the way things were going to be written henceforth just a short 15 years ago. The desktop on Linux is enough of a backwards place that this bad idea has not been abandoned. So there you have it folks, Dbus is fossilized software industry hype from the turn of the millennium.

edit2: One thing I like about d-bus (although maybe slightly off-topic here) is that it comes with command-line tools, so you can use it from scripting as well. This enabled me to have "shutdown" and "reboot" menu entries using consolekit in my FVWM menu with these commands:
Code:
DestroyFunc Shutdown
AddToFunc Shutdown
+ I PipeRead 'dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop >/dev/null 2>&1; echo "Quit"'

DestroyFunc Reboot
AddToFunc Reboot
+ I PipeRead 'dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart >/dev/null 2>&1; echo "Quit"'
Are you saying that that is better than this?
Code:
doas shutdown -p
doas reboot
 

sidetone

Daemon

Reaction score: 908
Messages: 1,857

Are you saying that[,] that is better than this?
Code:
doas shutdown -p
doas reboot
I also use doas reboot. Maybe that complex dbus command is so that programs can finish or be told to finish processes before the computer shuts down. Those commands are still excessive.
 

ct85711

Member

Reaction score: 48
Messages: 76

Dbus has no part in telling programs to terminate; as that is specifically systemd/init and the kernel that sends the signals directly to the application (dbus also gets the same signal(s) sent to). Just as if the application doesn't shutdown on it's own, it then sends the signal to kill (can't be ignored). The reason why dbus has no part,is that this is all done directly in the kernel directly and gets to everything, even stuff that isn't listening to dbus (ie terminal applications, vim, nano, and several more).
 

shkhln

Daemon

Reaction score: 964
Messages: 2,217

SOAP is unfortunately still widely used, enough that you can easily find actively maintained client implementations for relatively young programming languages such as Scala or Rust.
 

astyle

Daemon

Reaction score: 467
Messages: 1,079

Dbus has no part in telling programs to terminate; as that is specifically systemd/init and the kernel that sends the signals directly to the application (dbus also gets the same signal(s) sent to). Just as if the application doesn't shutdown on it's own, it then sends the signal to kill (can't be ignored). The reason why dbus has no part,is that this is all done directly in the kernel directly and gets to everything, even stuff that isn't listening to dbus (ie terminal applications, vim, nano, and several more).
dBUS is for desktops, not for kernel IPC... Going by that logic, dBUS is what would support copy-paste, child windows, launching programs, closing a window... dBUS would still have to capture the event of window closing, and correlate that to killing the process.
 

BSD-Kitsune

Active Member

Reaction score: 77
Messages: 185

FYI, i got QT5 to build, I THINK, without dbus:


For qt5-gui

If someone wants to try and upstream it either as its own port or as a patch against it, go ahead. Take the credit.
 

sidetone

Daemon

Reaction score: 908
Messages: 1,857

FYI, i got QT5 to build, I THINK, without dbus:
There's a lot of ports that work without dbus. Theoretically, most to all of them.
For qt5-gui
Thread x11-toolkit-qt5-gui-no-dbus.82055. Here, BSD-Kitsune started on trying x11-toolkits/qt5-gui without dbus. I started working on removing dbus as a hardset dependency, and making it into an option.

but I was only able to halfway adjust the Makefile for this purpose. There's two lines left for dbus to turn it into options to complete this. - I completed replacing the two final lines by using an if-then statement.
 

Beastie7

Aspiring Daemon

Reaction score: 590
Messages: 709

What about System V STREAMS or Solaris Doors IPC? Could that be used in place of D-Bus?
 

mrbeastie0x19

Member

Reaction score: 51
Messages: 88

What about System V STREAMS or Solaris Doors IPC? Could that be used in place of D-Bus?
Any way of doing IPC can be used, but if applications themselves all agree to communicate via dbus you are going to have an issue convincing upstream to replace it. For an integrated desktop system where you want components to share information a 'platform agnostic' messaging system like dbus does make a great deal of sense (as an example when Firefox detects it is offline it can use a network manager to reconnect), as long as apps communicate with dbus all you have to do is adapt dbus to the underlying OS it runs on and not change any of the behaviour of those apps, you separate the interface and the implementation. Unfortunately dbus is absolutely crap. So now classic Linux has an ecosystem where apps are dependent on some God awful daemon that cannot be avoided.

*To specifically answer your question, yes in theory since any IPC can be used, but no in practice because upstream uses dbus and communicating with other apps that use dbus is essential.
 

astyle

Daemon

Reaction score: 467
Messages: 1,079

Come on, I never had a problem with dBUS... the ports do a pretty good job pulling it in as a dep, and I don't even notice it's there. I do agree with the general sentiment that it's not a good idea to have such a tightly coupled dependency on dBUS (which makes dBUS difficult to just swap out for something else), but compiled/installed properly, dBUS doesn't get in the way, at least not in my case.
 

sidetone

Daemon

Reaction score: 908
Messages: 1,857

How about a drop in replacement. Where the only part of the DBUS replacement that needs to change to match upstream is where the program connects to the API. The rest will be BSD or portable centric.
 

BSD-Kitsune

Active Member

Reaction score: 77
Messages: 185

dbus is not secure on anything that's not GNU/Linux, that's the fundamental issue here for me. It's not about License. It's not about the fact it's linked with systemd and udev, two projects I don't care for. It's also slows down things, is a pain to configure etc.

No, it's because dbus basically is designed to work on GNU/Linux. It will work elsewhere, but it runs often with extreme privileges and trust that should not be granted to daemons that can perform socket activation, config modifications, process start/stop, and other such privileged actions.

I don't think a "Drop-in" replacement will really be possible, but its possible to build an alternative. We start by implementing the well-documented STREAMS API. Then we write a standard for communication, use SunRPC for the RPC side of it, and whatever we can reasonably agree on for the rest. This would be sharable between FreeBSD and illumos.

Then we implement a backend -- this could be helped if we wrote a guide on migrating code. Really, though, I'm not of the belief we need something as extensive as D-bus, my .02

Thank you Sidetone for helping in my absence. I've been sick.
 
Top