Why do we need d-bus?

dbus is needed for some desktops, unfortunately, the more popular ones like KDE, GNOME. Quite a few applications (firefox) will actually call dbus-launch. A lot of times the applications use it to save configuration changes (preferences).
A lot of non-Linux applications don't really need it. I run Windowmaker, only thing that calls dbus stuff is applications. I will routinely rename "dbus-launch" and a couple others so they never get started. I have not seen a problem in doing so.
There may be some desktops that don't use dbus at all like Lumina.

A for completely removing it, one would probably need to go through every port they are using, checking for DBUS and disabling it, then rebuilding all those ports.
 
mer said:
...Quite a few applications (firefox) will actually call dbus-launch...
Click to expand...
Firefox will run quite happily without Dbus if built with the option turned off.

A for completely removing it, one would probably need to go through every port they are using, checking for DBUS and disabling it, then rebuilding all those ports.
Click to expand...
You do have to rebuild all your ports, but all is takes is this in your make.conf:
Code: 
OPTIONS_UNSET= DBUS ATK_BRIDGE
And no more stinky Dbus in your system.
 
  • Like
Reactions: mer
Jose yep, I know firefox runs nicely without it, actually seems a little snappier to me. But until pkgs are built with "nodebus" as either a flavor or the default, one is stuck with it if you don't build your ports.
 
At least it seems right now, that ATK-Bridge may eventually go away with gtk-4. While the accessability stack(AT) isn't necessarily going away; it is slated to be completely rewritten to be similar to QT in that gtk exposes the API; and the programs have to ask for it. The side bonus, is that some of the dbus communication may become more efficient to maybe even go away.

https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-and-accessibility/
https://blog.gtk.org/2020/10/21/accessibility-in-gtk-4/
 
CanvisMe said:
But I can build my own qt5 locally disabling qt5-dbus, and it works fine. The problem is I cannot build it via ports due to Makefile options of other qt5 pkgs. Configuring OPTIONS_UNSET= DBUS ATK_BRIDGE seems not working for me.
Click to expand...
That's why I discourage disabling DBUS... My approach to changing options is: Don't disable defaults unless you know what you're doing, and can live with results. I do put in some effort to see if I can live with the results of messing with options. I did make my share of mistakes. Read the FreeBSD handbook, the manpages, and project web sites. Forums are quite helpful for connecting the dots for ideas you may have. It may be a harebrained idea or something surprisingly good and creative.

This is my post #500, so I'm now an Aspiring Daemon... Beat Vull to the punch! Mua ha, haa!
 
Jose said:
Firefox will run quite happily without Dbus if built with the option turned off.
Click to expand...
Yes, but it will be raised if available. I'm using your recommendation of "OPTIONS_UNSET" (build all from ports), and opening the URL "about:buildconfig" I can read "--disable-dbus", but playing for example a YT video…:
jo@freya ~> ps aux | grep dbus
[…] grep dbus
jo@freya ~> firefox &
[…]
jo@freya ~> ps aux | grep dbus
[…] /usr/local/bin/dbus-daemon --syslog-only --fork --print-pid 5 […]
[…] dbus-launch --autolaunch b63a3067558f3c5c67a188b759a0f891 […]
[…] grep dbus
I think it is something else, something, some third party lib etc. firefox uses.
 
jmos said:
Yes, but it will be raised if available. I'm using your recommendation of "OPTIONS_UNSET" (build all from ports), and opening the URL "about:buildconfig" I can read "--disable-dbus", but playing for example a YT video…:
jo@freya ~> ps aux | grep dbus
[…] grep dbus
jo@freya ~> firefox &
[…]
jo@freya ~> ps aux | grep dbus
[…] /usr/local/bin/dbus-daemon --syslog-only --fork --print-pid 5 […]
[…] dbus-launch --autolaunch b63a3067558f3c5c67a188b759a0f891 […]
[…] grep dbus
I think it is something else, something, some third party lib etc. firefox uses.
Click to expand...
Not Firefox. Currently watching Labpadre's stream:
Code: 
ps aux | grep dbus                                                             
jose  1398    0.0  0.0    11332   2596  1  S+   08:14    0:00.00 grep dbus
devel/qt5-core does not appear to have a Dbus dependency. Something else is pulling in devel/qt5-dbus even though I don't have qt5-core installed!

EDIT: It's qt5-gui
 
msplsh said:
Having written programs to send things over unix sockets FreeBSD and also over more structured RPC/IPC methods on macOS/iOS, it's probably a nice thing to have a higher level mechanism to do these sorts of things for programmers on FreeBSD, and I'm glad they have all standardized on it.

That being said I do try and turn it off via build options for things that seemingly don't need it since I'm rarely using FreeBSD with X. This just seems like a packaging complaint.
Click to expand...
There's UNIX ways to solve this though.

dbus is part of a larger trend of Freedesktop crap to make UNIX and C into something it was never designed to be: A Windows and C++ competitor. GObject, in glib/gtk, is basicallly OOP-on-C for the GNOME guys.

dbus has problems because it has known security issues (polkit depends on dbus), it's not tested or audited for non-GNU/Linux platforms (it has primary support for things like cgroups, linux-style socket activation etc.), it's another network-capable daemon that many of us don't need, and it is both an IPC model and an object model.

For Sys V UNIX, there's STREAMS, a kernel API that overlays sockets, terminal devices, pipes and other things and allows you to create a stack with ioctls and other syscalls that can communicate multi-directionally. It is not object-modeled, but the BSDs don't really support it, the APIs for it in the extant BSDs are for basic sys-v compat layering, and thus get converted to conventional sockets quickly. For RPC, we've had SunRPC. Not the most secure, but standard, performant etc. We don't need this Freedesktop BS, is my view, and the BSDs should start looking to be self-sufficient, or in my case, if the BSDs continue being client-states of the GNU/Linux projects and don't show aspiration, I'll have to probably retreat back to Windows. I don't have a choice, I hate Apple, and I personally will never run GNU/Linux outside of a work setting for reasons I cannot and will not discuss here. But that's where I draw the line, and people know I'm an opinionated trashtalker at times.

Jose said:
devel/qt5-core does not appear to have a Dbus dependency. Something else is pulling in devel/qt5-dbus even though I don't have qt5-core installed!

EDIT: It's qt5-gui
Click to expand...

We should absolutely have SOMEONE patch that out. Even if it breaks some functionality, it's worth it. Falkon doesn't require dbus if you build it via LFS, it shouldn't here. Other QT apps would be nice to have, fwiw.

I would do it, but I don't like qmake and the other qt stuff, and I have better things to be doing on systems that don't bite me as hard when I stick my hands blindly into the guts.
 
In principle, you're right that qt5-dbus doesn't belong with it. qt5-dbus should at least be made an option here, so it can be compiled without it.

Everything pulls in a little of something, and that little by little it adds up. I bet this gives the impression that every dependency is needed, when I doubt that it is.
 
  • Like
Reactions: mer
BSD-Kitsune said:
There's UNIX ways to solve this though.
Click to expand...
Yep. Unix Domain sockets have been around for a long time.
RPC: remember CORBA?
People have been wrapping classes and libraries and frameworks around these fundamental things for a long time, mostly to hide the details and make them "easier" for people to use. My experience has been you spend more time understanding the library and working around things it doesn't do correctly and you wind up doing the base level calls anyway.
That's not saying libraries and wrappers are a bad thing; just they can have problems too.
One has to understand what they need, what they want and what they get.
 
Dbus is there because it solves a real problem: providing a standardized message bus for inter process communication. And it is still relevant until today because nobody bothered since then to make a better tool as well good enough to replace it. So it is here to stay for a long, long time obviously.

Aside that Dbus was considered to be of slow performance under Linux in 2014/2015. This is why back then the most "gifted" programmers ever, Lennart Poettering and his systemd-team, implemented a kernel version of it called kdbus. The promise and goal of kdbus was to run much, much faster than its user space counter part. And they were brave enough to hand it over to Linus Torvalds for merge into the kernel 4.1.
So Linus first went through the hell of compiling dbus more or less by himself, and after that did profiling on dbus, then looked at kdbus. The profiilng result was basically that dbus is slow because of many, many dependencies in user space and being poorly written. The result was a tasty roast of the whole kdbus effort - and since 2017 it's development has stopped. It never became part of the kernel as well.

I mean personally I am not surprised about such stuff being slow - we are living in a time where many developers simply don't care about writing efficient and low ressource code and longer, because most computers nowadays are so much ridiculously overpowered that it still runs "fast enough" for them so they are not forced by constraints to write better code. Unfortunately these premium programmers nowadays are in charge for writing our desktop apps and its supporting infrastructure. It's the same "I don't give a shit" attitude, which made the ressource hog Electron so popular for trivial tasks. Want to have a clip board manager in Electron? We got you covered. And much, much worse stuff as well... It would be very much different, if these developers would have to develop stuff for embedded systems.

To quote Linus Torvalds post:
I am still expecting to merge it, mainly for a rather simple
reason: I trust my submaintainers, and Greg in particular. So when a
major submaintainer wants to merge something, that pulls a *lot* of
weight with me.

That said, I have to admit to being particularly disappointed with the
performance argument for merging it. Having looked at the dbus
performance, and come to the conclusion that the reason dbus performs
abysmally badly is just pure shit user space code, I am not AT ALL
impressed by the performance argument. We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards, and yes, that also means that it tends to
perform better, but no, "user space code is shit" is not a valid
reason for pushing things into the kernel.

So quite frankly, the "better performance" argument is bogus in my opinion.

That still leaves other arguments, but it does weaken the case for
kdbus quite a bit.

Because go out and read pretty much any argument for kdbus, and the
*first* argument is always performance. The articles never say "..
because the user-space dbus code is crap", though.

Linus
 
Note: The following is all my opinion, based solely on my use cases. I do not use a "Desktop Environment" I run startx and use a Window Manager.

dbus has it's uses.
But if one does not need it, one can rightly feel a bit peeved about it coming in as a dependency.

Look at where dbus is primarily used (Note: primarily, not all):
Desktop environments

How is it used?
A major use is "configuration": storage of preferences, getting "theme" information.
Another common use is allowing a non privileged user the ability to do privileged operations: shutdown/reboot the system, mount devices.

So is it useful? Sure.
Does everyone need to run it? No.
Performance: Like every other bit of software ever created, a lot of times performance is tied to how something is used. Saying a Yugo is a piece of crap because it can't run with an F1 car is ridiculous because you are not using the Yugo as it's intended. A Yugo makes a fine flowerpot :)

Since I don't run a DE that needs dbus, applications that are built with dbus enabled (firefox) spend time on starting that try to do dbus things, then they wait because dbus isn't running/doing anything, then they time out and continue on. Simply renaming /usr/local/bin/dbus-launch and dbus-daemon the applications start up quicker and feel a little snappier using because they aren't doing the dbus interactions. Whatever functionality they are doing, I don't miss.

The bigger question really revolves around Ports/Packages:
Should there be a way to build a set of "DBUS Disabled" packages? Like a "no dbus" flavor for every port that may use it?

In my mind the answer is "Yes, but...". Yes because a lot of people would like it, "but" because it's a lot of work and touches a whole lot of ports. Would the port maintainers like this? Probably, but they aren't going to do it without help.

Disabling dbus will change the functionality of some things, if a user decides they can live without it, don't judge them for disabling it.
At the same time, don't judge the folks that like it, like what it provides and want to use it.

dbus has had security issues in the past, maybe internal, maybe related to polkit. I don't know if there is any information one can get from dbus that could be pushed to daily/dailysecurity logs/emails, but if so that would help folks understand what it's doing.

Final thought:
use it, don't use, whatever fits your needs. Have technical discussions about it, not religious ones. If it bothers you enough one way or the other, see if you can help the port maintainers.

If you got this far, thanks and my apologies for getting a bit wordy. Time for more coffee.
 
BSD-Kitsune said:
We don't need this Freedesktop BS, is my view, and the BSDs should start looking to be self-sufficient, or in my case, if the BSDs continue being client-states of the GNU/Linux projects and don't show aspiration, I'll have to probably retreat back to Windows. I don't have a choice, I hate Apple, and I personally will never run GNU/Linux outside of a work setting for reasons I cannot and will not discuss here. But that's where I draw the line, and people know I'm an opinionated trashtalker at times.
Click to expand...
There's not enough free labor around to do what you suggest here. Anti-Linux and "linuxism" hate isn't going to solve any problems. We can't even get pf features synced between two BSDs. Yeah it's annoying to figure out how to stop DBus from sneaking in but people want DBus features and if you don't like how it's implemented... uh, good luck debating upstream maintainers about which IPC to use.

Flipping switches on packages, setting build options, and submitting patches for broken option switches are the most anybody on this forum are probably capable of when it comes to reducing non-essential DBus usage.

It's amusing that going back to windows is a pragmatic choice but all other options are aesthetic choices.
 
Jose said:
So there's no crap software out there? Do tell me more.

Relativism comes to programming. It was bound to happen. All shall have prizes.
Click to expand...
Really? You're going to go there?

Huge difference between judging performance and judging something to be a piece of crap.

In case I'm not clear:

Of course there is crap software.
Of course there is crap software that performs really well at being crappy.

But a lot of times complaints about software not performing should be looking at how the software is being used.
One can have the absolute best and most performant software in the world but if someone tries to use it in a
different way than intended, the performance becomes crap.

Send me the address I can send your prize to.
 
mer said:
But a lot of times complaints about software not performing should be looking at how the software is being used.
One can have the absolute best and most performant software in the world but if someone tries to use it in a
different way than intended, the performance becomes crap.
Click to expand...
Blame the victim. A Microsoft favorite.
 
Do you have something better to do than personal attacks?
I think this thread is comming close to its end. Last orders?
 
mer said:
Yep. Unix Domain sockets have been around for a long time.
RPC: remember CORBA?
People have been wrapping classes and libraries and frameworks around these fundamental things for a long time, mostly to hide the details and make them "easier" for people to use. My experience has been you spend more time understanding the library and working around things it doesn't do correctly and you wind up doing the base level calls anyway.
That's not saying libraries and wrappers are a bad thing; just they can have problems too.
One has to understand what they need, what they want and what they get.
Click to expand...

Domain sockets aren't the same thing as STREAMS. I'm not gonna sit here and try to convince people it's a better option, but it hooks into SunRPC on Solaris and HP-UX, it has a long history of use, and as it functions in the kernel, it solves basically everything that kdbus and dbus set out to do in a UNIX manner. that's all. :)

sidetone said:
In principle, you're right that qt5-dbus doesn't belong with it. qt5-dbus should at least be made an option here, so it can be compiled without it.

Everything pulls in a little of something, and that little by little it adds up. I bet this gives the impression that every dependency is needed, when I doubt that it is.
Click to expand...

I think that it speaks volumes about how much software in the ports tree is ported with care. Read: not a lot of it. A lot of it is haphazard and careless. Remember Tomahawk? Never got that building on FreeBSD despite being in ports :(.

hardworkingnewbie said:
Dbus is there because it solves a real problem: providing a standardized message bus for inter process communication. And it is still relevant until today because nobody bothered since then to make a better tool as well good enough to replace it. So it is here to stay for a long, long time obviously.
Click to expand...

STREAMS has been around for over a decade prior. it's also well-documented enough that anyone could implement it in the kernel and keep it updated (illumos also has a FOSS-licensed version in its kernel that could be used or studied for reimplementation in BSD world.) The answer is that the BSDs have an allergy to good things that originated in System V land, seemingly, and GNU/Linux constantly is looking to reinvent the wheel and force it on those seen as clients of it.

msplsh said:
There's not enough free labor around to do what you suggest here. Anti-Linux and "linuxism" hate isn't going to solve any problems. We can't even get pf features synced between two BSDs. Yeah it's annoying to figure out how to stop DBus from sneaking in but people want DBus features and if you don't like how it's implemented... uh, good luck debating upstream maintainers about which IPC to use.
Click to expand...

The answer is simple IMHO -- maintain what we can, discard what we can't and perhaps it's time for the Ports tree to be pared down where the quality of ported software can go up. Otherwise, FreeBSD will continue to have shovelware ports.

msplsh said:
It's amusing that going back to windows is a pragmatic choice but all other options are aesthetic choices.
Click to expand...

The design philosophy of Windows and other proprietary OSes is the other face of the coin that is the BSDs, illumos and other fully integrated OS releases of its kind. One is free, the other is proprietary. Everything in a Windows base install is made by MS and supported by MS directly. Same story with the BSDs and illumos. GNU/Linux is a patchwork that ranging from distro, is "fine/okay" (such as the old CentOS, RHEL, SuSE etc. where there's actual care in putting together packages) to "OH MY GODS WHY IS IT LIKE THIS???" for bleeding edge/rolling release distros like Arch and Gentoo (at least Gentoo's community isn't full of toxic teens, though.)

Crivens said:
Do you have something better to do than personal attacks?
I think this thread is comming close to its end. Last orders?
Click to expand...

I'm not sure whom this is directed towards, but I'd say that it's better to ask the people involved in the mudslinging to leave the thread/delete his/her posts rather than locking the thread as some sort of collective punishment. Have I been civil? I believe so, as have others, even msplsh has, despite him seemingly vehemently opposing my instances. One of us is fine being a client to Apple or GNU/Linux, while the other craves the era of self-sufficiency and productiveness that he feels has left the BSDs.
 
You must log in or register to reply here.
Back
Top