Why do we need d-bus?

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.
 
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
 
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.
 
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.
 
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
 
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.
 
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).
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
What does freebsd recommend to use instead of dbus? I've used dbus extensively for bluetooth communication and wifi configuration and I don't see an alternative that can provide me with similar features.
 
What does freebsd recommend to use instead of dbus? I've used dbus extensively for bluetooth communication and wifi configuration and I don't see an alternative that can provide me with similar features.
I really don't know anything about bluetooth and wifi situation in freebsd and linux because I have never used them so I can't tell if they need it or not or what can be used instead also I'm not "freebsd" BUT generally things like unix sockets, named pipes, and even not using anything! most of the times we don't need any sort of IPC whatsoever !
:‌D
 
What does freebsd recommend to use instead of dbus? I've used dbus extensively for bluetooth communication and wifi configuration and I don't see an alternative that can provide me with similar features.
Wifi config works just fine for me without Dbus. Can you elaborate?
 
The interesting part, is of how many packages truely "need" dbus. I've often seen packages that needed dbus, works perfectly fine, if not better without dbus. This is from using Gentoo for over 10+ years. I can see some applications benefit from dbus, but at the same side it is easily just as much out of scope that the program should worry about. The security side of it, is more of a joke than anything else. For the most part the security is dependent on a trust system; and that's it. There's nothing preventing a program from reading any and all data/messages that is passed through; nor is there anything controlling you from communicating on any of the channels. I've encountered multiple legit programs (non-hostile) that has to do it to "trick" the system to work around a serious limitations of the system. The part those programs in example manipulated, is more the inactivity counter and power management (preventing the screensaver/monitor power).
 
Back
Top