Why do we need d-bus?

Zirias

Daemon

Reaction score: 1,421
Messages: 2,479

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,010
Messages: 2,880

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

Aspiring Daemon

Reaction score: 376
Messages: 858

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: 858
Messages: 1,756

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: 104
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: 903
Messages: 1,108

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: 858
Messages: 1,756

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: 71

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: 952
Messages: 2,205

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

Aspiring Daemon

Reaction score: 376
Messages: 858

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: 76
Messages: 181

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