dbus, what for?

LuckyCyborg · 05-03-2022, 01:10 AM

Quote:

Originally Posted by Didier Spaier

Well unless you bundle libsystemd in dbus-broker, or you put it in a "private" (for dbus-broker only) location. Anyway as I can't use libsystemd alone to make elogind happy, I have no reason to ship it in Slint (so far).

It is well known that the launcher (and only the launcher) of dbus-broker is a systemd thingy hence my experiments. So the only way would be to write from scratch an alternative launcher for dbus-broker, not dependent of systemd. This is well known, but nobody so far did it. I have neither the skills nor the time to do it, unfortunately.

With all respect, I believe that trying to package the dbus-broker-launch in a non-systemd distro is just an exercise of Quixotism.

Code:

SCOPE

       Unlike  dbus-daemon(1),  dbus-broker-launch  activates  all  services  as  systemd  units.
       Services  that  already come with a systemd-unit are activated as usual, but services that
       lack a systemd unit are activated as transient unit, with an ad-hoc unit-file generated at
       runtime. This guarantees that all services run in a well-defined environment.

       The  --scope  parameter  defines which systemd instance the launcher shall use to activate
       services. In case of system, the launcher will use the system instance of systemd. In case
       of user, the user instance is used instead.

       Furthermore,  the  selected scope also defines which configuration file is used if none is
       specified on the command-line.

       The selected scope does not have any further effect. It  is  only  needed  to  define  the
       activation  environment  for  loaded  service  definitions. If no activatable services are
       declared, the scope will have no effect at all.

http://manpages.ubuntu.com/manpages/...-launch.1.html

How the heck you run systemd units without systemd, when those units are a fundamental concept of systemd's init system?

I for one, I strongly recommend you to install and (alternatively) use a Linux which uses systemd, for understanding how systemd works - for example: openSUSE, which still has a resemblance inherited from its Slackware DNA.

And lastly but not last: why the heck you bother with dbus-broker in a non-systemd distro?

Yeah, it's faster than the stock dbus-daemon because do what systemd do: parallel execution of the (systemd) units. Then it's capable to bring up faster the services started on demand. BUT, this is a systemd thing, ran by systemd while doing systemd things.

Didier Spaier · 05-03-2022, 02:52 AM

Quote:

Originally Posted by LuckyCyborg

With all respect, I believe that trying to package the dbus-broker-launch in a non-systemd distro is just an exercise of Quixotism.

I already came to the conclusion that the only solution would be to replace dbus-broker-launch, not package it. This being said how the dbus-broker daemon could work without service files is something I don't know and if we have to write service files to make it happy... More work ahead.

So, until dbus-broker becomes a hard dependency of a must-have package I will just forget it.

adcdam · 05-03-2022, 01:45 PM

this is interesting to read also

Quote:

Hey!

The core of dbus-broker (the dbus-broker binary) has no external dependencies at all, other than a linux kernel. It is a complete bus implementation according to the dbus specification (see dbus-broker(1) man-page).

However, most of the time you expect an environment around a bus that provides many more features atop of the pure bus broker. This is why we also provide dbus-broker-launch (see dbus-broker-launch(1) man-page). This is a compatibility interface to dbus-daemon, that tries to provide an environment as close to what dbus-daemon provides.
When writing this compatibility launcher, we decided to strip all legacy features and instead built on top of what is present on a modern Fedora system. This means, this implementation requires an activation environment which includes a running systemd manager.

If all you need is a simple bus without any features on top, you can easily run dbus-broker directly without any launcher. However, if you need dbus-activation, then you need a bus controller that spawns dbus-services when they are activated. The compatibility launcher uses systemd to do this. If you want to spawn dbus-services without systemd, you need a suitable replacement. I am not aware of any replacement on Fedora, but you can of course roll your own. In this case it is up to you to implement the controller interface documented in dbus-broker(1), spawn the dbus-services, track and monitor them

and also
https://www.skarnet.org/software/skabus/

Didier Spaier · 05-03-2022, 02:15 PM

Well, skabus is a software for which only packaging stuff available is on the AUR and has S6 as a dependency... Feel free to package it, but me? thanks but no, thanks.

zeebra · 05-04-2022, 10:11 AM

Quote:

Originally Posted by Didier Spaier

"what do the user misses without dbus"

Anything that requires inter process communication

I'm really struggling to come up with an example right now. But let's say in theory, one program starts playing a video, it can signal to other programs to pause their video, so you only play 1 video.

Or perhaps a better example. You have a VoIP program, and someone calls, but your playing music or watching video. When you answer the call, it will be annoying because the music or video is playing. But VoIP could with dbus signal everyone else to mute or pause or something similar when receiving a call from grandmother, or from whoever.

ttk · 05-04-2022, 11:10 PM

The one that often annoyed me was when the browser told my DE to pop up notifications at me, interrupting my work (when I even used a DE .. guess that was 2008'ish).

blancamolinos · 05-07-2022, 02:23 PM

QUOTE=hitest;6350312]Fascinating topic, thanks for starting this, Didier. DBUS is a requirement in the BSDs too.[/QUOTE]

Well, that depends on the window manager in question. For example in OpenBSD the cwm does not need dbus. And dbus is not included in a OpenBSD full install (with Xenoxara).

marav · 05-07-2022, 02:30 PM

https://zeromq.org/

Didier Spaier · 05-07-2022, 03:05 PM

Quote:

Originally Posted by marav

https://zeromq.org/

To the question "zeromq, for what? the current answer seems to be "to exchange cryptocurrencies peer-to-peer". Thanks, but no, thanks. Hint: see under "Required by" in https://archlinux.org/packages/community/x86_64/zeromq/

zeebra · 05-09-2022, 11:48 AM

It's an interesting question from a security perspective as well. Dbus is somewhat of a gaping hole in any MAC(mandatory access control) policy. It basically sets up a bunch of Unix sockets with bind and stream/listen, and a bunch of programs use these, but you don't really know what for and there isn't a way to control what dbus can and cannot do through these sockets (no fine grained control).
You can ofcourse just deny the ability of dbus to bind and/or listen on the socket, or any program to listen to dbus sockets, but that would probably lead to issues.
It does however say dbus is "SELinux aware", which basically mean you can pass instructions to Dbus to do this or that with policies, but it leaves the control with dbus, so you can't control dbus policies with SELinux..

Dbus is pretty much just pure software IPC and doesn't use system calls to do those things, which is from what I understand there was some effort in the past to implement dbus in the Kernel, which was ultimately rejected due to design issues with the proposal or some such.

Since we are in times where there is a somewhat near prospect of moving from Xorg to Wayland, and because there have also been proposals to implement a "security module" in Wayland due to various privelege escalation scenarios and properly seperating priveleges in Wayland, that would work much the same way as LSM's. It's interesting to speculate that the best place to source a dbus replacement that could be implemented in the Kernel would be from Wayland developers.

elcore · 05-09-2022, 12:05 PM

Quote:

Originally Posted by zeebra

I understand there was some effort in the past to implement dbus in the Kernel, which was ultimately rejected due to design issues with the proposal or some such.

Yes, kdbus was rejected and for good reason.
IIRC it was something like; the devs CBA to take care of it, so let's attempt to shove it into kernel and let the kernel devs deal with it.
I'd suggest you read the mailing list archive for more accurate description.

Richard Cranium · 05-09-2022, 09:54 PM

Quote:

Originally Posted by zeebra

Anything that requires inter process communication

I'm really struggling to come up with an example right now. But let's say in theory, one program starts playing a video, it can signal to other programs to pause their video, so you only play 1 video.

Or perhaps a better example. You have a VoIP program, and someone calls, but your playing music or watching video. When you answer the call, it will be annoying because the music or video is playing. But VoIP could with dbus signal everyone else to mute or pause or something similar when receiving a call from grandmother, or from whoever.

I've written a JavaFX application that uses DBus to register for Bluetooth BLE information for a heart rate monitor so that said application could show me a graph of how close I am to a heart attack while working out on a rather old Nordic Track cross-country ski machine. (If you think DBus sucks ass, take a close look at the Bluetooth specs and the Bluetooth Low Energy (BLE) spec.)

DBus is a variant of local CORBA in that you can write a service that advertises that you provide an implementation to some interface and/or your service can examine the bus to see if anything out there implements an interface that you'd like to use. It isn't perfect but it also isn't complete shit. (Well, if you hate XML, you'll think it's shit; I don't hate XML.)

EDIT: @zeebra points out quite valid security issues around DBus! At some point, you start to wonder if your computer is a tool of yours or a zombie controlled by someone else.

zeebra · 05-10-2022, 04:14 AM

Quote:

Originally Posted by Richard Cranium

EDIT: @zeebra points out quite valid security issues around DBus! At some point, you start to wonder if your computer is a tool of yours or a zombie controlled by someone else.

Well, to be fair, dbus is not alone in that, even if you use Wayland rather than Xorg. It's not that I strongly dislike join efforts for desktops, but some of those freedesktop g* projects used by KDE are rather hideous in their implementation, from what I can gather as an amateur.

And then you have myself uninstalling Samba, since I never use any share disks or Windows stuff, and because Samba has frequent security fixes. However, that leads me into a situation where I'm unable to use Dolphin, and I think also Konqueror fails. That's just to say that Samba is a dependency of Dolphin, which quite frankly is very annoying and in theory (as far as I can understand) entirely unecessary. I'm somewhat tempted to file a bug report with KDE over the issue.

Anyways, one of the major things that made me happy in the past in regards to KDE development is that they made their desktop more modular, especially with KDE5. Having followed KDE and many of their projects somewhat close, I know they had projects for various formats as well (mobile, tablet, netbook etc). And one annoyance I had was dependencies in KDE, while my expectation for further development would be that KDE would make everything even more modular. This would also solve the "issue" of having similar components on multiple formats. My thought was/is that you would pretty much be able to scale KDE from a simple window manager to a full desktop environment and that troublesome dependency issues would vanish as a result. However, I'm not so optimistic about it anymore, but I still think KDE is the best desktop environment around, independent of platform.

Well, anyways, KDE is not perfect, and while Samba might be the worst example, there are many similar dependency issues with KDE.

One of my personal concerns is however with the awful design of Firefox and it still being the best browser available, and while KDE/Wayland is easier to deal with, I'm still anticipating something like Openbox or Blackbox for Wayland to be able to set up a simple display and contain Firefox (work still in progress). It sure would beat having to contain both Firefox and KDE in Wayland. And having looked into the prospect (but not remember much) of a Wayland security module (that may or may not become an LSM), it does seem like it would be the best place to also replace dbus with say a Kernel module AND Wayland integration/module/whatever.

But well, I'm not an expert, it just seems logical to me, and my main problem is not with xorg, wayland, kde or dbus, but with Firefox. And yes, it is a real monster (they should rename it Firedragon or Firetitan), but it is also seemingly the only viable browser to browse the modern web with. Unless ofcourse you want something like inotify in your web browser, or be beholden to rotten global megacorporations like Google.

But well, I digress.

elcore · 05-10-2022, 04:32 AM

Quote:

Originally Posted by zeebra

rotten global megacorporations like Google.

Ah, the sponsor of KDE and also a developer of the most bloated KDE dependency - qtwebengine.
Wonder if Slackware project has seen any funding from shipping that thing, probably not.

zeebra · 05-10-2022, 05:00 AM

Quote:

Originally Posted by elcore

Ah, the sponsor of KDE and also a developer of the most bloated KDE dependency - qtwebengine.
Wonder if Slackware project has seen any funding from shipping that thing, probably not.

A sponsor of KDE, not the. And qtwebengine is actually a QT project, a fork from chromium engine and removing crappy components. It's actually a pretty decent way to have access to a de-googled chromium engine in GNU/Linux. I see Alienbob does something similar with Chrome, but I'm wondering if qtwebengine isn't just a far better way to do the same.

And I don't agree with making it a dependency of things unless strictly necessary, but it did make Konqueror a whole lot better as a web browser. qtwebengine/konqueror actually has potential to be a viable lightweight geek browser in GNU/Linux, if only the Konqueror developers were willing to make some changes/development and new directions for Konqueror.

qtwebengine is not as bad as you think, I think.