# Why do we need d-bus?



## delphinoob (Feb 14, 2021)

I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it?

I have personally never went out of my way to enable it programs like chrome or firefox always start the session anyways, someone told me it's a security concern, is that true?

edit: when i say the 'freebsd' desktop i mean a desktop without linuxisms


----------



## delphinoob (Feb 14, 2021)

I see it is called a Linuxism by those here but is still a staple of any bsd desktop. why?
from what i can see the only os that makes it easy to make dbus fuck off from chrome and ff is gentoo


----------



## ShelLuser (Feb 14, 2021)

It's not exactly hard to look it up IMO, this could be a good read: https://en.wikipedia.org/wiki/D-Bus

Also, you speak of "BSD desktop", something like that doesn't exist. By default FreeBSD doesn't use a desktop but the command line. However... X environments such as KDE rely on D-Bus. Why? Well, see the link or go ask them  In the end it has little to do with (Free)BSD but more so with the X desktop environments which rely on it.


----------



## Deleted member 66267 (Feb 14, 2021)

delphinoob said:


> I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it?


Because most of the applications, graphical or even cli, make use of it. If you want to use them, you need it. Done.


----------



## Jose (Feb 14, 2021)

failure said:


> Because most of the applications, graphical or even cli, make use of it. If you want to use them, you need it. Done.


I've never run into a cli program that needed dbus. You got an example?


----------



## George (Feb 14, 2021)

Yaah, dbus does inter-process communication. It's an alternative to the classic ways to do this (pipes, sockets, shared memory..).

Each time you launch a gtk3 based GUI programm, dbus processes will spawn. It's probably the same with qt5.
Dbus cannot be turned off in gtk3, even if it's not needed (I think there is a PR somewhere trying to fix this.). Anyways,
since dbus is used in gtk3 and qt5, many desktop systems will have dbus processes spawning. An exception is a super leightweight window manager, e.g. openbox. But even in openbox, once you start a GUI programm, chances are high that dbus is launched as well...


----------



## PMc (Feb 14, 2021)

delphinoob said:


> I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it?


Me neither - given that the internals stay obscure.


ShelLuser said:


> It's not exactly hard to look it up IMO, this could be a good read: https://en.wikipedia.org/wiki/D-Bus


This does mostly talk about theoretical concepts - it does not explain how the thing would actually achieve that (and therefore compromise the system).

So, what we know is: we are forced to compile that d-bus into application. And, since some couple of months, we are also forced to install it.

We also know: it does not run any processes.

The question then is: how does it achieve what it is explained to achieve? Which kind of IPC does it use, and how does that work? And can it be monitored? (Because, if two entities want to talk to each other on my system, I would like to know about that. Thats why I am running a defined system and not a linux madhouse.)


Elazar said:


> Each time you launch a gtk3 based GUI programm, dbus processes will spawn.


That's interesting. I've never seen any of these. How would it spawn processes the superuser cannot see?
Now, assuming that this is just not possible, and therefore the thing is not running any processes here, and still everything works, with some logical thinking I might conclude: it is not really necessary.

Furthermore, if some entities would want to start talking to each other, this is not only a security concern, it also most often means they are trying to develop some kind of AI, that is, try to know better what I want than I know what I want - resulting in the usual bad effects, that is, the system behaving in some way that was not explicitely configured and where we do not know why it does so.


----------



## sidetone (Feb 14, 2021)

I compiled Firefox without dbus, and it ran a whole lot faster than with dbus. 

It's only purpose, as far as I can see, is keeping bloatware connected in run time, to do absolutely nothing.


----------



## PMc (Feb 14, 2021)

sidetone said:


> I compiled Firefox without dbus, and it ran a whole lot faster than with dbus.
> 
> It's only purpose, as far as I can see, is keeping bloatware connected in run time, to do absolutely nothing.


Well, it's trendy... 
I also learned, you do no longer configure your modelines for the screen. Instead, the monitor now _talks_ to the application. All these things start _talking_ to each other, without you taking notice. And they start to decide on things and do things without you considering. That's the point of it - because 1984 is quite a while back, and you are only supposed to unconditionally love Big Brother and know that others know what's best for you, or more specifically: *do not think*.


----------



## sidetone (Feb 14, 2021)

In my /etc/make.conf I have:

```
OPTIONS_UNSET= DBUS
```
When I compile programs, it gets rid of it, unless it's hard set without options. However, when I use packages, I get stuck with dbus.

Seriously, I don't understand why people keep introducing bloat into programs, usually upstream. Like they have a cluttered state of mind.


----------



## shkhln (Feb 14, 2021)

D-Bus is usually used for things like telling a DE panel to display a tray icon and similarly peripheral stuff. (There is some overlap with X11 there.)


----------



## kpedersen (Feb 14, 2021)

delphinoob said:


> I see it is called a Linuxism by those here but is still a staple of any bsd desktop.


We have very few BSD specific desktops and because we share the general FOSS ones dbus just gets dragged in by a number of their "development ideas".

I personally prefer X11 handling communication between programs for GUI and UNIX sockets for CLI. If someone is using a crippled display system like some of these permanently half-complete Wayland compositors are, then perhaps dbus is useful to make up for other lacking systems.

Luckily almost nothing using dbus works properly anyway (mounting, shutdown, network, notifications) so you can generally leave it off. Some of our ports are patched so that they handle dbus not running correctly or they fake it running.

Long story short, it is basically old fashioned clutter like ToolTalk. There are always better ways.


----------



## wolffnx (Feb 14, 2021)

Never see a application launching dbus itself, but like many users says here ,there are applications that need it
for example, `lilyterm` writen in gkt2 and is not way to get out dbus in that application


----------



## tingo (Feb 14, 2021)

Canonical info about d-bus is here https://www.freedesktop.org/wiki/Software/dbus/


----------



## Jose (Feb 14, 2021)

sidetone said:


> In my /etc/make.conf I have:
> 
> ```
> OPTIONS_UNSET= DBUS
> ```


I just spent some time figuring out why I was still getting DBUS even though I have that in my make.conf. The culprit turned out to be audio/volumeicon, which depends on x11-toolkits/gtk30, which will drag in accessibility/at-spi2-atk. The solution might be to add `OPTIONS_UNSET=ATK_BRIDGE` to make.conf. I'll try that and report back.

I thought of a daemon that requires Dbus: Avahi. This is why I use MDNSresponder instead. I still can't think of a command line utility that needs it.


----------



## PMc (Feb 14, 2021)

Jose said:


> I just spent some time figuring out why I was still getting DBUS even though I have that in my make.conf. The culprit turned out to be audio/volumeicon, which depends on x11-toolkits/gtk30, which will drag in accessibility/at-spi2-atk.


Yes, that's one of them. The other is qt5. I didn't find an easy way to get rid of it there.



Jose said:


> I thought of a daemon that requires Dbus: Avahi.


Uh? That goes somewhere into the rendezvous/bonjour stuff, doesn't it?


----------



## drhowarddrfine (Feb 14, 2021)

Sometimes worrying about it isn't worth the time.


----------



## rorgoroth (Feb 14, 2021)

Years ago on my Gentoo desktop I turned off dbus and did a rebuild, could not tell any difference for a few days... until I tried opening like 20 images in gimp (which is a common thing for me to do back then) from the file manager and got 20 instances of gimp - needless to say I reversed my decision and ended up doing another rebuild


----------



## kpedersen (Feb 14, 2021)

rorgoroth said:


> and got 20 instances of gimp


Heh, in many ways I am the opposite. I went to process a number of images by avoiding opening a wildcard * in gimp and instead creating a for each loop in a shell script to run gimp on each image, expecting it to block, I crop the image, save and close and the next one appears. Didn't quite work like that, it never blocked, instead opened up 3(?) instances and then opened up the remaining images in the first instance. Can't win!


----------



## Matlib (Feb 14, 2021)

Gimp used to work without dbus back in the day, so it should be possible to reverse that code sabotage.

Many Gnome3 applications like Epiphany or Evolution crash outright with SIGSEGV if they cannot find dbus.


----------



## Jose (Feb 15, 2021)

PMc said:


> Uh? That goes somewhere into the rendezvous/bonjour stuff, doesn't it?


Yeah, it's the Redhat mDNS responder. I replaced it with net/mDNSResponder and I haven't missed Avahi or Dbus.

Edit: I forgot. Setting `OPTIONS_UNSET=ATK_BRIDGE` and reinstalling x11-toolkits/gtk30 solved it for me.


----------



## delphinoob (Feb 15, 2021)

It is a good thing I hate gnome 3 and programs that force gtk3 on me, and now I see my annoyance and hatred of d-bus is now justified. 

I want it gone. But too bad, I just moved my desktop to openbsd since the freebsd installer doesn't want to work on my new laptop.

Maybe I wil linstall freebsd on a surrogate disk and stick it in my laptop

even more off topic, i dont get these multi quotes, they dont put anything in my reply/post box so i ant see where the quote is going to go


----------



## delphinoob (Feb 15, 2021)

Is there some flag I can set to get programs to build with gtk2 instead in my make.conf? fuck gtk3, honestly. 




PMc said:


> Yes, that's one of them. The other is qt5. I didn't find an easy way to get rid of it there.
> 
> 
> Uh? That goes somewhere into the rendezvous/bonjour stuff, doesn't it?


Another service I want gone from mysystem anyways.

[_Mod: Watch your language_]


----------



## sidetone (Feb 15, 2021)

delphinoob said:


> Is there some flag I can set to get programs to build with gtk2 instead in my make.conf?





PMc said:


> The other is qt5. I didn't find an easy way to get rid of it there.





delphinoob said:


> Another service I want gone from my system anyways.


Maybe,

```
OPTIONS_UNSET+= GTK3 QT5
OPTIONS_SET+= GTK2
```
It may not get rid of it entirely. The plus is to use that option, if it doesn't force that option to break. The SET part can possibly be without a +. UNSET likely needs a +.


----------



## Deleted member 66267 (Feb 15, 2021)

Jose said:


> I've never run into a cli program that needed dbus. You got an example?


No. Vaguely recall from memory.


----------



## kpedersen (Feb 15, 2021)

Jose I *think* transmission bittorrent client uses it for the console interface (transmission-remote-cli).

I remember many years back switching from transmission to rtorrent because something stopped working and I am going to make a wild guess that it was probably dbus.


----------



## obsigna (Feb 15, 2021)

Jose said:


> ... I still can't think of a command line utility that needs it.


dbus-launch(1)


----------



## wolffnx (Feb 15, 2021)

delphinoob said:


> Is there some flag I can set to get programs to build with gtk2 instead in my make.conf? fuck gtk3, honestly.
> 
> 
> 
> ...


I wish..some applications remove the gtk2 support and change to gtk3, me too, I hate gtk3
but I dont want to make offtopic


----------



## jamie (Feb 15, 2021)

obsigna said:


> dbus-launch(1)





kpedersen said:


> Jose I *think* transmission bittorrent client uses it for the console interface (transmission-remote-cli).
> 
> I remember many years back switching from transmission to rtorrent because something stopped working and I am going to make a wild guess that it was probably dbus.


Nahhh, not transmission-remote. I think the qt/gtk gui ports need it (I don't use them) but transmission-remote uses its own rpc


----------



## Deleted member 66267 (Feb 17, 2021)

obsigna said:


> dbus-launch(1)


Not it. I recall I encountered a package pulled dbus as dependency on a system even doesn't have X11 installed.


----------



## Deleted member 30996 (Feb 18, 2021)

sidetone said:


> Seriously, I don't understand why people keep introducing bloat into programs, usually upstream. Like they have a cluttered state of mind.



Respectfully, I have never understood why people make such a big deal of it or hal.

I build all my 3rd party programs from ports using ports-mgmt/portmaster starting with things not needing X to run. Then x11/xorg, x11-wm/fluxbox on up.

ports-mgmt/portmaster is the first thing I build using `make install clean` then from that point on I let it build everything. If it deems it necessary to pull a dependency in I go with what it thinks need pulled in during the build. I enable both in /etc/rc.conf early on so when they are installed they're ready to go when needed.

I have a minimal number of 3rd party programs installed and the same ones on every machine, give or take a game or something, and ended up with Packages: 561 on this box and close to that on every machine I build.

I had these processes showing ATM I copied and pasted them to text editor:


```
43402 root          1  52    0    14M  1104K select   2   0:00   0.00% dbus-launch
59551 jitte           1 22    0    14M   1104K select  1   0:00    0.00% dbus-launch
60081 jitte           1 20    0     12M  1632K select  0    0:01  0.00% dbus-daemon
98510 messagebus    1  20    0     13M  1648K select     2    0:00     0.00% dbus-daemon
```

`top` shows this load on a AMD Phenom II x 3 N830 Triple Core @ 2.1GHz with 4GB RAM:

54 processes:  2 running, 52 sleeping
CPU: 3.5% user, 0.0% nice, 1.0% system, 0.3% interrupt, 95.2% idle
Mem: 805M Active, 1929M Inact, 95M Laundry, 733M Wired, 370M Buf, 127M Free
Swap: 3852M Total, 109M Used, 3743M Free, 2% Inuse

That's running my media player for tunes, file manager, terminal emulator, text editor www/firefox-esr with a few tabs open, etc. and what is normal desktop use for me unless working with images. I don't see that as or experience a load on my boxen and it's happy happy joy joy for me.


----------



## PMc (Feb 18, 2021)

Trihexagonal said:


> Respectfully, I have never understood why people make such a big deal of it or hal.


Security?

Imagine, you were the boss of some shop with a couple of employees. Would you like it to have an employee hanging around where you don't know why he was engaged, what would be his specific tasks and what he were actually doing?
That's about the same with a machine you are running, and a couple of daemons engaged to work on that machine.


----------



## Snurg (Feb 18, 2021)

Yes, the lack of information what dbus is being used for is not suitable to make people trust.
xorg was not created with security in mind. Was dbus?
And dbus also needs to be configured correctly, to avoid it being used for privilege escalation.

BTW, you need dbus even for samba...


----------



## Deleted member 30996 (Feb 18, 2021)

PMc said:


> Security?
> 
> Imagine, you were the boss of some shop with a couple of employees. Would you like it to have an employee hanging around where you don't know why he was engaged, what would be his specific tasks and what he were actually doing?
> That's about the same with a machine you are running, and a couple of daemons engaged to work on that machine.



I would say not nearly the same with my machines. I am very security oriented beyond the browser extensions I use. Here are some things I do that aren't all included in my Tutorial but free to be known, used with it and what I consider good practice:

/etc/rc.conf

syslogd_flags="-c -ss"
sendmail_enable="NO"
tcp_drop_synfin="YES"
sshd_enable="NO"
telnet_enable="NO"
cupsd_enable="NO"
samba_enable="NO"
inetd_enable="NO"
rlogin_enable="NO"
portmap_enable="NO"
winbindd_enable="NO"
lpd_enable="NO"
nfs_server_enable="NO"
nfs_client_enable="NO"
webcamd_enable="NO"

My ruleset is set to block and has been posted before. Here it is again:

etc/pf.conf

### Macro name for external interface
ext_if = "bge0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Reassemble fragmented packets
scrub in on $ext_if all fragment reassemble

### Default deny everything
block log all

### Pass loopback
set skip on lo0

### Block spooks
antispoof for lo0
antispoof for $ext_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

### Block all IPv6
block in quick inet6 all
block out quick inet6 all

### Block to and from port 0
block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp

### Keep and modulate state of outbound tcp, udp and icmp traffic
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

From the terminal:
jitte@jigoku:/ $ who
jitte ttyv0 Jan 28 23:24
jitte pts/0 Jan 28 23:25 ( : 0 )
jitte@jigoku:/ $

(I fixed that last line from a smiley emoji it made here.)

I run security/rkhunter to check for rootkits and file changes but stopped bothering with things like security/aide long ago. security/bcrypt and USB sticks what I place my trust in for password security. There may be more but haven't had enough coffee to think of.

There are no Instant Messenger apps of any kind on my machine. I do everything from my usr account and `su` to become root, which some see as bad practice but all I have ever used and am comfortable working as. When I work as root it is only work done needed as root and then I log out back into my usr account.

No browsers are open during that time and I may pull the Ethernet wire from the laptop if I enter the password and work. No wi-fi or bluetooth allowed in my house unless I invoke Kali to see with eyes of the Goddess.

If there are Daemons in my boxen talking to somebody they're only chatting with the Daemons in my mind through my fingertips as I type. I know some apps phone home but I brush aside the Dragons warned of that dwell in the depths of about:config. I'm boring anyway and not very interesting, for the most part.

If you have concerns that this and selectively allowing JS to run online don't cover and I'm missing something please do tell. I'd rather hear it from you than surprise by exploit from my Finnish Fans afar that tell bedtime stories of the Demon to frighten children.

Boo!


----------



## Jose (Feb 20, 2021)

failure said:


> Not it. I recall I encountered a package pulled dbus as dependency on a system even doesn't have X11 installed.


It might've been net/avahi. You'd run into this if you were trying to set up a Freebsd machine for Timemachine backups.


----------



## fernandel (Feb 20, 2021)

On my system x11/libX11, x11/libSM, x11/libICE need devel/dbus and there are no options to disabled.


----------



## PMc (Feb 20, 2021)

fernandel said:


> On my system x11/libX11, x11/libSM, x11/libICE need devel/dbus and there are no options to disabled.


On my system they don't. 
But these do:

```
devel/dbus-glib
devel/qt5-dbus
multimedia/audacious-plugins
net/glib-networking
security/gcr
www/qt5-webengine
x11-toolkits/qt5-gui
accessibility/at-spi2-atk
accessibility/at-spi2-core
```


----------



## msplsh (Jul 16, 2021)

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.


----------



## rigoletto@ (Jul 16, 2021)

As some folks said D-Bus is a IPC (Inter-Process Communication) but a kind of _hacky_ one. IPCs are fundamental when using microkernels (you can get a lot of technical information about the MacOS Mach IPC); given the natural simplicity and isolation of these kernels a lot communication between "applications" happen through the IPC according to a given security police instead of (freely) "directly".

However, it may have use in other applications too. x11-wm/bspwm, x11-wm/i3, x11-wm/leftwm are some WMs with simple built-in IPC (or sort of IPC)  to pass commands directly to the WM (quite handy in some circumstances).

In regards to D-Bus, this is the typical Linux (more like general weekend hobbyist open-source) development, where it isn't secure (or at least doens't improve security at all) nor it is actually usefull (hard to use it from the user point of view, or more like useless). In other words, more of a source of problems or a solution that bring more problems than the problem it is trying to solve (improve security).

*[EDIT]*

Just to make it clear serious IPCs are pretty hard to design/implement properly. Surely not a weekend hobbyist job unless he/she is an experienced IPC developer.


----------



## Jose (Jul 17, 2021)

drhowarddrfine said:


> Sometimes worrying about it isn't worth the time.


And sometimes it is.








						Privilege escalation with polkit: How to get root on Linux with a seven-year-old bug | The GitHub Blog
					

polkit is a system service installed by default on many Linux distributions. It’s used by systemd, so any Linux distribution that uses systemd also uses polkit.




					github.blog


----------



## msplsh (Jul 17, 2021)

This is not a dbus security flaw, which is why it's labeled polkit.


----------



## Jose (Jul 17, 2021)

msplsh said:


> This is not a dbus security flaw, which is why it's labeled polkit.


Reading TFA helps.


> The vulnerability​
> Why does killing the dbus-send command cause an authentication bypass? The vulnerability is in step four of the sequence of events listed above. What happens if polkit asks dbus-daemon for the UID of connection :1.96, but connection :1.96 no longer exists? dbus-daemon handles that situation correctly and returns an error. But it turns out that polkit does not handle that error correctly. In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0. In other words, it immediately authorizes the request because it thinks the request has come from a root process.


----------



## msplsh (Jul 17, 2021)

"But it turns out that polkit does not handle that error correctly"


----------



## twllnbrck (Jul 18, 2021)

https://venam.nixers.net/blog/unix/2020/07/06/dbus-polkit.html


----------



## Jose (Jul 18, 2021)

twllnbrck said:


> https://venam.nixers.net/blog/unix/2020/07/06/dbus-polkit.html


I'm not entirely certain what I'm supposed to glean from that article, but here are some gems from a quick scan.


> While D-Bus does offer 1-to-1 and 1-to-many IPC, it’s more of a byproduct of its original purpose than a mean of efficient process to process data transfer — it isn’t meant to be fast.


The accidental IPC! I really wanna use it now.


> Its design is heavily influenced by Service Oriented Architectures (SOA), Enterprise Service Buses (ESB), and microkernel architectures.
> A bus permits abstracting communication between software, replacing all direct contact, and only allowing them to happen on the bus instead.
> Additionally, the SOA allows software to expose objects that have methods that can be called remotely, and also allows other software to subscribe/publish events happening in remote objects residing in other software.
> Moreover, D-Bus provides an easy plug-and-play, a loose coupling, where any software could detach itself from the bus and allow another process to be plugged, containing objects that implement the same features the previous process implemented.
> ...


How very enterprise! I wonder if it has AbstractFactoryFactories.


----------



## CanvisMe (Jul 20, 2021)

So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's `USE_QT = dbus` option in some qt pkg Makefile.


----------



## astyle (Jul 20, 2021)

Why do people choose 112th anniversary of Chicago's massacre (google that yourselves, I'm not posting links for this one) to post to the forums?

Anyway, DBUS is an implementation of IPC (as pointed out earlier in this thread. So, CanvisMe , I would discourage disabling dbus. It takes a lot of expertise to know about alternative solutions that actually work, and can be used as a drop-in replacement. IPC is vitally important to proper functioning of desktops in FreeBSD. If you don't like DBUS, you'd need to be comfortable with getting down and dirty with the source code of the desktops themselves.


----------



## CanvisMe (Jul 20, 2021)

astyle said:


> Why do people choose 112th anniversary of Chicago's massacre (google that yourselves, I'm not posting links for this one) to post to the forums?
> 
> Anyway, DBUS is an implementation of IPC (as pointed out earlier in this thread. So, CanvisMe , I would discourage disabling dbus. It takes a lot of expertise to know about alternative solutions that actually work, and can be used as a drop-in replacement. IPC is vitally important to proper functioning of desktops in FreeBSD. If you don't like DBUS, you'd need to be comfortable with getting down and dirty with the source code of the desktops themselves.


I'm sorry for that, and I'll take your advice, thanks


----------



## Jose (Jul 20, 2021)

CanvisMe said:


> So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's `USE_QT = dbus` option in some qt pkg Makefile.


Look upthread:








						Why do we need d-bus?
					

I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it?  I have personally never went out of my way to enable it programs like chrome or firefox always start the session anyways, someone told me it's a security concern, is that true?  edit...




					forums.FreeBSD.org


----------



## astyle (Jul 20, 2021)

CanvisMe said:


> I'm sorry for that, and I'll take your advice, thanks


I was just venting about the date I noticed earlier in the thread, nothing to do with your posts, CanvisMe ...


----------



## mer (Jul 20, 2021)

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.


----------



## Jose (Jul 20, 2021)

mer said:


> ...Quite a few applications (firefox) will actually call dbus-launch...


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.


You do have to rebuild all your ports, but all is takes is this in your make.conf:

```
OPTIONS_UNSET= DBUS ATK_BRIDGE
```
And no more stinky Dbus in your system.


----------



## mer (Jul 20, 2021)

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.


----------



## sidetone (Jul 20, 2021)

CanvisMe said:


> So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's `USE_QT = dbus` option in some qt pkg Makefile.


Look into the files at /usr/ports/Mk/Uses/ for qt and dbus related options for building ports.


----------



## ct85711 (Jul 20, 2021)

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/


----------



## bsduck (Jul 20, 2021)

mer said:


> There may be some desktops that don't use dbus at all like Lumina.


It is supposed to work without it, but for some reason x11/lumina-core depends on devel/qt5-dbus.


----------



## msplsh (Jul 21, 2021)

It's because devel/qt5 has a runtime dependency on it.


----------



## astyle (Jul 21, 2021)

msplsh said:


> It's because devel/qt5 has a runtime dependency on it.


I didn't know that... but now that has me thinking - is QT6 going to be any better (as in having an alternative IPC mechanism as an option)? We're all kind of stuck with QT 5.15.2 until then, though.


----------



## CanvisMe (Jul 21, 2021)

msplsh said:


> It's because devel/qt5 has a runtime dependency on it.


Qt5 can be built locally disabling qt5-dbus, and it works fine. Though it's not convenient.


----------



## astyle (Jul 21, 2021)

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.


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!


----------



## jmos (Jul 21, 2021)

Jose said:


> Firefox will run quite happily without Dbus if built with the option turned off.


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.


----------



## Jose (Jul 21, 2021)

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


Not Firefox. Currently watching Labpadre's stream:

```
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


----------



## BSD-Kitsune (Jul 28, 2021)

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.


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



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.


----------



## sidetone (Jul 28, 2021)

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.


----------



## mer (Jul 28, 2021)

BSD-Kitsune said:


> There's UNIX ways to solve this though.


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.


----------



## hardworkingnewbie (Jul 28, 2021)

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_


----------



## mer (Jul 28, 2021)

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.


----------



## msplsh (Jul 28, 2021)

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.


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 (Jul 28, 2021)

mer said:


> ...Like every other bit of software ever created, a lot of times performance is tied to how something is used...


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.


----------



## mer (Jul 28, 2021)

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.


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.


----------



## Jose (Jul 28, 2021)

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.


Blame the victim. A Microsoft favorite.


----------



## Crivens (Jul 28, 2021)

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


----------



## kpedersen (Jul 28, 2021)

I can find *many* Docker T-shirts on Google images but can't seem to find any dbus T-shirts.

Hope this helps the debate!


----------



## astyle (Jul 28, 2021)

kpedersen said:


> I can find *many* Docker T-shirts on Google images but can't seem to find any dbus T-shirts.
> 
> Hope this helps the debate!


You can always ask a screenprinter to make one just for you


----------



## BSD-Kitsune (Jul 28, 2021)

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.



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.



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.



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.



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.



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?



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.


----------



## sidetone (Jul 28, 2021)

BSD-Kitsune there's reluctance to fix these things in ports. They want to keep everything fully compatible with full desktops.

In my theory, it's worth seeing that there are a few subsystems, that everything or most works on top of, and proving it can be done. I also wouldn't be surprised if code becomes better, and it's found that 50% or almost 75% of code isn't needed, while adding minimal improvements to get full functionality for everything. I can't fully explain it, except where I found redundancy, and pointed it out, to show hours worth of compiling was unnecessary then they were like oh! I still find unnecessary dependencies, but there's more reluctance now, because it's not as obvious of half days of additional compile time. There are a few major different belief modes on this. My dream is to see a forked ports tree, which would work directly on top of FreeBSD. Then, look at it like, what actual tangible feature is desired, than including every dependency that offers excess redundancy.

Apple has 1 subsystem for each feature, which isn't common in OS'es. It has Bonjour, and not different implementations of Avahi and friends. It has its own implementation of each function it needs, and not so many to do 1 task.
...

I came across resources like this recently, then thought about this thread: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html

I don't know if Inter-Client Communication Conventions Manual (ICCCM) is an alternative or if it performs enough of the same function as dbus. If it is, I wouldn't be surprised if someone will insist it isn't because it isn't a Linuxism without explaining a basic difference. I was going to read into ICCCM anyway, which I will eventually do.

Actually, some programs work without dbus, and even run faster without it. That alone, tells me, I can do without it, and don't need whatever so-called feature it provides.


----------



## astyle (Jul 28, 2021)

BSD-Kitsune said:


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


To be honest, this thread is an interesting read for me. I had no idea about dbus being that important to usability of UNIX desktop. For me, it was always a 'Set and forget' feature.  The "OH MY GOD, WHY IS IT LIKE THIS??" debates - yeah, it shows that  people can be stubborn about the strangest things. Yeah, you need IPC. Yeah, people are gonna disagree about details of implementation. I just cherry-pick the details of implementation, and sometimes, I can make sense of it, and realize "Yeah, nice and workable design. Yeah, some things are not gonna work as expected because of that design". Yeah, it can be frustrating if your favorite piece of software is now refusing to work correctly. But for me - that comes with the turf.


----------



## msplsh (Jul 28, 2021)

BSD-Kitsune said:


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


Dropping support for things that require/use DBus is a sure fire way for nobody to use FreeBSD.  OpenBSD and NetBSD are right there for people who don't want GUIs.


----------



## sidetone (Jul 29, 2021)

msplsh said:


> Dropping support for things that require/use DBus is a sure fire way for nobody to use FreeBSD.


There are enough users including desktop users who don't want a system with lots of things like dbus. For me, I can tolerate dbus. If it goes, that would be good for me. Better yet, Avahi being replaced completely by another Zeroconf implementation, or Alsa or Pulseaudio being completely replaced by a few implementations including Portaudio.

The ones who want these things, it would lose them, and it wouldn't be good to do that. Ports needs a fork, with subsystems and libraries that aren't dbus and Linuxisms. That's a dream, but this way, everyone can be happy.

For now, dbus can be so that, it's not a hard dependency for anything, as it's made an option, so those who don't want it can turn it off and build it.


----------



## Jose (Jul 29, 2021)

sidetone said:


> Apple has 1 subsystem for each feature, which isn't common in OS'es. It has Bonjour, and not different implementations of Avahi and friends...





sidetone said:


> Better yet, Avahi being replaced completely by another Zeroconf implementation...


Apple's single mDNS implementation is open source and there's a port for it, net/mDNSResponder. This however did not suit Mr. Poettering, for some reason. Maybe because it does not need Dbus. In any case, he's the big fish in the tiny Linux desktop pond. Unfortunately our pond is even smaller, and it's therefore unlikely we'll be able to sway the open source desktop.

No way we can wag that dog, to engage in an unfortunate mixed metaphor. Best I can do is wage a losing guerilla war by turning off Poettering-ware whenever possible, and living without whatever makes it mandatory.

Maybe adding a Dbus option to the x11-toolkits/qt5-gui port is a good project for tonight.


----------



## sidetone (Jul 29, 2021)

Jose said:


> Apple's single mDNS implementation is open source and there's a port for it, net/mDNSResponder.


Thread what-is-zeroconf?.79651


Jose said:


> This however did not suit Mr. Poettering, for some reason. Maybe because it does not need Dbus. In any case, he's the big fish in the tiny Linux desktop pond. Unfortunately our pond is even smaller, and it's therefore unlikely we'll be able to sway the open source desktop.





Jose said:


> No way we can wag that dog, to engage in an unfortunate mixed metaphor. Best I can do is wage a losing guerilla war by turning off Poettering-ware whenever possible, and living without whatever makes it mandatory.
> 
> Maybe adding a Dbus option to the x11-toolkits/qt5-gui port is a good project for tonight.


It doesn't need to be some type of war. A _[port tree]_ fork would be easier to maintain, because less overhead from dependencies by 3 fold for some cases. The motto of it would be, don't use a Poettering implementation if a BSD-like implementation exists. Then, let them later say, "oh! this one is so much better, than the one I'm using!" If they happily want to reintroduce bloat, let them on another project or on their own.

Making it an option or turning things like that off is good for now.


----------



## Jose (Jul 29, 2021)

sidetone said:


> Thread what-is-zeroconf?.79651


Thanks! You saved me a bunch of time. I was wondering what all the various mDNS ports were.


sidetone said:


> It doesn't need to be some type of war. A fork would be easier to maintain, because less overhead from dependencies by 3 fold for some cases. Then, let them later say, "oh! this one is so much better, than the one I'm using!"


I'm not sure what you mean. Your own page lists 3 live alternatives to Avahi. Why is another fork needed?


----------



## shkhln (Jul 29, 2021)

Jose said:


> Maybe because it does not need Dbus.


Keep in mind, D-Bus itself was authored by Havoc Pennington and as such it doesn't qualify as Lennartware.


----------



## sidetone (Jul 29, 2021)

Jose said:


> I'm not sure what you mean. Your own page lists 3 live alternatives to Avahi. Why is another fork needed?


A fork of a ports tree, not of a Zeroconf implementation. If enough suitable implementations already exist, another fork isn't needed and would add another problem of choice when there's not a good enough reason for it.


----------



## Jose (Jul 29, 2021)

shkhln said:


> Keep in mind, D-Bus itself was authored by Havoc Pennington and as such it doesn't qualify as Lennartware.


Yep. In my mind, Pennington is an earlier and less successful version of Poettering. He had Microsoft envy instead of Poettering's Apple envy. Pennington is a former Redhat employee as well. Dunno if he overlapped with Poettering.


----------



## sidetone (Jul 29, 2021)

It may not even be dbus in itself so much. It slowed down my applications. A significant amount of that is it intertwined with other weighted dependencies. Dbus on its own would slow down my applications anyway, but perhaps more because of the dependencies that it gets loaded down with by association. Turning it off, when I can doesn't cause problems for me.

It was pointed out that dbus has problems. It seems like not as much problems as other Linux-type suites that pull in so much.


----------



## shkhln (Jul 29, 2021)

Well, I like Typesafe Config quite a bit, so less successful sounds about right.



Jose said:


> He had Microsoft envy instead of Poettering's Apple envy.


None of these (common IPC standard; config store with an API) are inherently bad ideas — it's mostly (lack of) implementation quality that sets freedesktop projects apart. That said, I didn't look at the D-Bus source code at all nor do I want to.


----------



## Beastie7 (Jul 29, 2021)

IdeasPage - FreeBSD Wiki
		


See Solaris Doors IPC (_fast sockets_)

Now get to work!

Personally, I'd love an SMF implementation with BSD semantics in FreeBSD. It's really smart software.


----------



## astyle (Jul 29, 2021)

sidetone said:


> Ports needs a fork, with subsystems and libraries that aren't dbus and Linuxisms. That's a dream, but this way, everyone can be happy.


Isn't that why we have Poudriere? Lots of people have their own Poudriere repos, where they can set their own options. Heck, you can play "Poudriere golf", where you show off your own spin of FreeBSD repos that is free from dbus and whatever that sound system is called - oh, just remembered - PulseAudio!


----------



## sidetone (Jul 29, 2021)

It needs to be a shared repository, where the better settings help everyone get rid of Avahi, and where contributions help everyone that agrees that there's too much redundancy of dependencies that do the same thing. A standardized repository, that has shared improvements. The current repository there's a lot of reluctance for improvements. And so that, every single person doesn't have to rebuild everything, while they can rebuild and improve parts of it, and that benefits everyone who uses it. "Use Poudriere" I keep getting this same response, when I would have to have a side Makefile, and maintain that all on my computer to only benefit me, only for it to get erased on the next ports tree update. When a few people on here are saying why is dbus a hard dependency. I can change this on my own computer. It needs to be set for everyone. This has traction, so will get done. And one of the big reasons a ports fork is needed, because there's reluctance to fix things, that I can fix on my own computer. When, I used to make an improvement on my computer, and it was used, and actually made things a lot better. I got discouraged with improving this ports tree, because it seems stale as it wasn't before or because of reluctance to improve things. There needs to be a whole portstree without ALSA, Pulseaudio, Avahi, so it there's no chance of it getting tangled up with other ports, and so these things can be actually fixed with a clear picture on a sort of cleaner slate, that doesn't worry about breaking some Gnome so-called feature.

All of Avahi, Pulseaudio, Alsa and other Linuxisms would be wiped out of it, when a BSD implementation exists. The rest of the desktop wouldn't be focused on Gnome or KDE. In my vision, Gnome wouldn't be in a ports-tree fork. Only some applications, and they would run on what everything else is running on. Everything is bloated only to make it work on Gnome. It would use a trimmed common gtk, with the differences being for gtk2 and gtk3. Additional dependencies would be out.

You're missing the picture. The response of "use Podriere" doesn't fix the actual ports tree to reduce Potterisms. Fix the ports tree makes more sense, but anything that doesn't have a maintainer sits there, or they insist on running it the Linux way. I may become a maintainer of a few ports one day. No one else should have 3 additional sound systems on their computer, unless it's for cross platform portability, unless they absolutely want to run Linux. A whole ports system needs to be standardized, without having a whole set of excessive Linuxisms unless there's no other implementation, which for many Linuxisms there's better implementations.

Why spend weeks at a time fixing a ports tree only on my computer, to benefit no one else, when these diffs, don't go anywhere, when the regular ports tree insists on keeping Linuxisms. The only way a system is going to be cleaned up is to start it by leaving out Linuxisms when better implementations exist. Can't do it on a system that is reluctant.

One day, perhaps I may make a shared repo, with a different standard, perhaps on Github or host my own website and pass it off to shared users.

I could spend a month to make, then compile a whole portstree for myself for something that only suits me, then I'll have to redo a lot of that and the compiling again, after the next year or 6 months. And I would have to spend a whole lot of time, putting in my own diffs, after updating the portstree each time. Sure, I'll spend that much time for something that doesn't benefit anyone, not even me, because the purpose would be, if I or anyone else did spend that much time, it should benefit more people. And the load would be shared, thus, everyone even the ones who do it spend a whole lot less time compiling even the whole thing on their own. The purpose would be to make it better, spending a month, for something that I would have to adjust for every portstree update, defeats the purpose of making something better by making it even more complicated, because I would show that something is better, but only I would be fixing it again in a way, that's excessively complicated for what, to maintain a reluctance and dance around that, why don't they just use Linux. Or Maybe I should just get a Mac, so I don't have to explain how using 1 implementation is better than having 20 that do the same thing.

The ports tree is functional, but it can't be made much better, the way it needs to be, because of reluctance for making everything work with every Gnome bloat.


----------



## ralphbsz (Jul 29, 2021)

BSD-Kitsune said:


> There's UNIX ways to solve this though.
> ...
> For Sys V UNIX, there's STREAMS, ...
> ...


... and someone mentioned sockets as an alternative to D-Bus.

The deep misunderstanding here is that there is a huge difference between Streams/STREAMS, sockets, and D-Bus.

Streams/STREAMS (yes, the capitalization matters) is a genius kernel mechanism, originally invented by Dennis Ritchie and his team, then part of some Bell Labs Research Unix version (that came out after the Bell Labs / BSD split), and finally productized in SysV. The research version was called Streams, and the product version was called STREAMS; Dennis was highly critical of the product version. It was not a simple mechanism to allow two processes to talk to each other. Instead it was a software "discipline" or "design pattern" that allowed kernel modules and user processes to implement complex layered protocols (for example SNA on top of TCP on top of IP on top of SLIP on top of a line discipline on top of serial ports. For some reason (which I don't know in detail) it was never ported into BSD; my suspicion is that it was "not invented here" syndrome. Streams is completely content agnostic; one could use it to help implement something like D-Bus, but all the high level concepts would need to be added from scratch. It's like saying "a network is the same as two cans and a string": No, to build a functioning network at the application level you need to define protocols such as IP, DNS, DHCP, TCP, HTTP, and state the HTML semantics, in addition to having a low-level transport mechanism.

Sockets (domain or otherwise) are even lower level. They are intellectually just the two tin cans and a string: two parties, one sends bytes, the other gets it.

D-Bus is a much different beast. To begin with, it's not a point-to-point link, but a bus, with many senders and receivers. It has the capability to run virtual buses over it, it can support the publish/subscribe pattern with multiple listeners, and it assigns interestingly complex naming and semantic meaning to messages: They are not just unstructured streams of bytes.

For a modern desktop environment, you need something like D-Bus. And you need to build that something on top of a low-level communications mechanism, such as sockets or streams. A lot of the arguments against the existing implementation that's used in FOSS DEs is that it is associated with things and people (such as Linux or Lennart) that some people consider "evil"; that is a very weak argument to evaluate technology.


----------



## hardworkingnewbie (Jul 29, 2021)

Dbus has nothing to do with Lennart Poettering at all. It's not one of his babies. kdbus was though, and it was burnt to shreds by Linus Torvalds, because his stance was "you want that in the kernel claiming you cannot get that speed in userland. But having looked at the userland thing, it's programmed so poorly that you just should clean that up instead of trying to get something like that into the kernel."

Sometimes it's nice to have a look in the Wikipedia for better understanding.

This picture below is a set of programs communicating to each other using the standard ways, meaning either sockets or TCP/IP, so in short without something like Dbus:






And this picture below is the same set of programs with Dbus instead:




The difference is quite clear. The advantage for programmers is that they don't have to wrap their head around any longer at how to talk to different programs, because the message bus has a clearly defined language set. So learning that language is enough to talk correctly to all programs hooked up at that bus.


----------



## kpedersen (Jul 29, 2021)

Do programs really need to talk to one another that much?

Just look at Gnome 3. Everything fails to communicate anyway. The automounter fails to communicate with the UI. The gvfs stuff fails to communicate with the UI. I am actually inclined to believe nothing communicates correctly. This isn't a modern desktop, it is a fragile mess.

KISS is important. If we don't keep to it, it always breaks in the end. The FOSS community is not reflective enough. We react and keep hacking away. If we really took a step back and had a think why we really need one big system bus for every program to send random messages to one another we might find it is over engineering.

For some use-cases, such as clustering, grids, etc. Then perhaps a central bus is required. But not for a basic desktop environment that *still* can't compete with the Windows 95 shell in terms of complexity and functionality.


----------



## astyle (Jul 29, 2021)

FWIW, GNOME4 is out on the streets, but not in FreeBSD ports. The way I see it, that's because it's hard enough to keep up with KDE.

sidetone : you can have your own repo of Poudriere templates, and a blog on how to do it. If you have enough people replicating your efforts, you can try making a case for helping you get the word out. There's quite a few FreeBSD-based projects that you can use as lab rats for that. If you can make it work, then come back with a shining accomplishment to your name. That's the FOSS playbook for adjusting the main repos to work the way you want them to.


----------



## BSD-Kitsune (Jul 29, 2021)

hardworkingnewbie said:


> The difference is quite clear. The advantage for programmers is that they don't have to wrap their head around any longer at how to talk to different programs, because the message bus has a clearly defined language set. So learning that language is enough to talk correctly to all programs hooked up at that bus.



Dbus has far more to it than just IPC. It's a privileged daemon, object model, and more. It aims to replace RPC as well, and my argument is that SunRPC already serves a good purpose there. We don't need to follow the suit of GNU/Linux, and to me that absolutely means throwing GNOME, KDE, etc in the bin. In any case, even if you install all that and dbus etc. You're still stuck with an inferior experience and less supported platform to run these on. PC-BSD/Project Trident was trash because it didn't manage to overcome that inertia needed to break away into it's own thing.



ralphbsz said:


> ... and someone mentioned sockets as an alternative to D-Bus.
> 
> The deep misunderstanding here is that there is a huge difference between Streams/STREAMS, sockets, and D-Bus.
> 
> ...



I'm well aware that STREAMS doesn't specifically specify the protocol. but that's the beauty of it. The programmer may choose the best protocol for IPC.if your argument is for interoperability, as it stands and appears to be, then all someone needs to do is document a standard protocol and get a majority of people to agree to use it.

As I said above, I simply think that object modeling and UNIX/unix-like are fundamentally incompatible. If you want object/capability type stuff in an OS, UNIX is not for you, Plan9 is not for you.

My arguments are that dbus is specifically designed for GNU/Linux and to leverage specific technologies that are indigenous there. When those APIs and technologies are not present, such as cgroups, namespaces, etc. We are left with an inferior experience, and a daemon that isn't secure and is capable of things like activating other daemons and doing more things we probably should be questioning.

Therefore outside of that context it's irrelevant for us and we should throw it in the bin. If you disagree, I mean, get your Apple fix elsewhere I say. Apple's trash has message buses and more.if you want that level of interoperability.

For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you  have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.

Tooltalk was what IID used for some of that. Tooltalk can use STREAMS for higher level communication as well.

At risk of sounding like a broken record, if something doesn't happen, then the BSDs pthe


----------



## kpedersen (Jul 29, 2021)

BSD-Kitsune said:


> For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you  have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.


I am glad that others notice this. These older desktops often have more features than existing ones but with a fraction of memory usage and dependencies.

I suppose the problem is man power. Writing any desktop environment takes a lot of time for a small group. And those that are able to do it, often are technical or familiar enough to get by with a simple window manager and terminal.

That said, if ~10 of us got together and each did a few programs in the DE (almost like a game jam), I am fairly sure that good things could come from it in a weekend.

I even found a very competent terminal emulator using no dependencies other than FLTK the other day. In some ways, almost everything in a DE has already been made as "demo apps" for simple UI toolkits. All that it would really need is cleanup.

I could even see an entire DE as a single static executable. They are not complex things. GUI is easy, just time consuming.


----------



## Jose (Jul 29, 2021)

ralphbsz said:


> D-Bus is a much different beast. To begin with, it's not a point-to-point link, but a bus, with many senders and receivers. It has the capability to run virtual buses over it, it can support the publish/subscribe pattern with multiple listeners, and it assigns interestingly complex naming and semantic meaning to messages: They are not just unstructured streams of bytes.


And this is exactly the problem. You came looking for a tool and you got handed a methodology. You just wanted to send simple messages between two apps, and you're going blind reading about security models and XML schemas. This in a nutshell is why things like Unix sockets win and things like Dbus lose.


ralphbsz said:


> For a modern desktop environment, you need something like D-Bus. And you need to build that something on top of a low-level communications mechanism, such as sockets or streams.


And yet here I am writing this in a desktop environment with no Dbus in sight. I must be doing it wrong.


----------



## astyle (Jul 29, 2021)

kpedersen said:


> I am glad that others notice this. These older desktops often have more features than existing ones but with a fraction of memory usage and dependencies.
> 
> I suppose the problem is man power. Writing any desktop environment takes a lot of time for a small group. And those that are able to do it, often are technical or familiar enough to get by with a simple window manager and terminal.
> 
> ...


[RANT] Yeah, can you make CDE look like KDE just by replacing the graphical elements with some lookalikes? I want my kio-slaves working properly, and to be able to copy-paste the errors straight from Konsole into Konqueror so that I can do my research on errors a bit better. Oh, and do it all in Wayland, while you're at it. [/RANT]


----------



## hardworkingnewbie (Jul 29, 2021)

BSD-Kitsune said:


> For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you  have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.


I guess we should come back discussing that point when your idea about "modern DE" is not from the last millenium, and roughly 30 years old.


----------



## msplsh (Jul 29, 2021)

Jose said:


> And this is exactly the problem. You came looking for a tool and you got handed a methodology. You just wanted to send simple messages between two apps, and you're going blind reading about security models and XML schemas. This in a nutshell is why things like Unix sockets win and things like Dbus lose.


This thread is about how the user would like to tell the programmer how to "send messages between apps" despite not knowing a thing about it except there has to be a message broker that they can SEE in the process list and control if it starts up.  If the user could be like "there are too many UNIX sockets here, how can I block them from opening?" they would do it.


----------



## ct85711 (Jul 29, 2021)

I will say, a dbus setup is no way needed for a modern DE, take a look at windows, Mac OS, or even Android.  Dbus is a linux thing, but software that is designed to work on other OS, quietly fails and does it in another fashion for OS that don't have dbus.  Sure you could have dbus on windows, even qt will compile the dbus client portion; but you still need the server end that handles the back-end portion of dbus to work.

For me, the biggest issue dbus has is more of everything is trying to use it when it isn't needed.  Does PulseAudio really need dbus?  Generally, you don't restrict sound playback in only specific users; so why bother?  Config? Few programs will look at some other program's configs unless they are designed to work together.  A browser doesn't really need to use dbus, since it is a user level program; there is better ways to restrict than using dbus. Configs again, look above. Anything else a browser, could easily use a simple api command to access the applicable resource it needs ( like sound, webcam, mic, and others).

Even the assistive technology, shouldn't be using dbus as much as it is.  Anything that wants to provide to that, should just merely listen and have the assistive technology stuff should publish a simple statement of the direct communication that apps are to communicate to, not push entire webpages, books and everything else onto a bus system.


----------



## kpedersen (Jul 29, 2021)

astyle said:


> [RANT] Yeah, can you make CDE look like KDE just by replacing the graphical elements with some lookalikes? I want my kio-slaves working properly, and to be able to copy-paste the errors straight from Konsole into Konqueror so that I can do my research on errors a bit better. Oh, and do it all in Wayland, while you're at it. [/RANT]


Why can you not copy and paste from dtterm into your web browser of choice? Middle click works as usual. You can also use the Windows-style copy / paste metaphor in CDE too. Copy and paste is not a new technology... 

As for kio. There are many alternatives. Many of which are much more widespread rather than limiting yourself to the relatively few KDE applications.

If you want to use a Linux-centric display system, more than you want to use a competent desktop environment, certainly be my guest just note that your needs are fairly niche (and possibly wrangling the wrong OS). Also, *if* Wayland reaches even 25% usage, there will be many Xlib abstraction libraries. And finally, Xwayland will outlive Wayland itself. Just use that.

Some vague stats because OSS communities don't really like telemetry.

https://linux-hardware.org/?view=os_display_server <- Wayland is ~10% on Linux (very bad uptake after 12 years)
https://bsd-hardware.info/?view=os_display_server <- Wayland is non-existent on FreeBSD


----------



## astyle (Jul 29, 2021)

msplsh said:


> user would like to tell the programmer how to "send messages between apps" despite not knowing a thing about it except there has to be a message broker


yeah, the user gets wind of programmers not liking the design of the IPC mechanism in use, and chimes in. I personally don't care about what IPC is in use, be it UNIX sockets or dbus or whatever. But if I read up on the Internet about how the poor design is actually what's getting in the way of using the DE... I would want to switch my DE to something that works, and is reasonably snappy on my machine. 

kpedersen : I am a Wayland user on FreeBSD... full-time at that. I use Plasma-Wayland.


----------



## kpedersen (Jul 29, 2021)

astyle said:


> kpedersen : I am a Wayland user on FreeBSD... full-time at that. I use Plasma-Wayland.


And things like LibreOffice, Blender, Gimp? Those programs are all Wayland?

You basically are using X11 for the majority of your tasks. This is basically how the state of Wayland is going to remain for the foreseeable future. You have merely swapped out Xorg for Xwayland.

And CDE works great on Xwayland (and Xweston).


----------



## Beastie7 (Jul 29, 2021)

Linux is the gift that just keeps on giving. Imagine having thousands of self contained, Linux/systemd/Wayland operating systems. It's like GNU/Linux fragmentation; but over level 9000.

Each sold separately(tm). It Just works(tm).

Developers are going to love it.


----------



## Jose (Jul 29, 2021)

msplsh said:


> This thread is about how the user would like to tell the programmer how to "send messages between apps" despite not knowing a thing about it except there has to be a message broker that they can SEE in the process list and control if it starts up.


Whut? Why is this a requirement? Is this what "modern" means? Grepping ps output to make sure some Linux crapware hasn't crashed again?


----------



## astyle (Jul 29, 2021)

kpedersen said:


> And things like LibreOffice, Blender, Gimp? Those programs are all Wayland?


All run fine, they don't care about being stuffed into a Wayland window. I would know, I tried.


----------



## kpedersen (Jul 29, 2021)

astyle said:


> All run fine, they don't care about being stuffed into a Wayland window. I would know, I tried.


Yeah. They are basically using Xwayland. So all still very much an X11 technology stack.

Not that that is a bad thing. Xorg codebase is a little gross. I would like to see a modern X server. If Xwayland (or more specifically something like Xweston) is it; I am fine with that. Either way CDE and Motif are fairly safe. Once xlib gets rewired to something (like wl_roots?) and the X server itself can be ditched then things might change. However I don't think that will even be in our kids lifetime (and probably won't happen with Wayland either).


----------



## msplsh (Jul 29, 2021)

Jose said:


> Whut? Why is this a requirement? Is this what "modern" means? Grepping ps output to make sure some Linux crapware hasn't crashed again?


It's a requirement because you are NOT the one implementing the software that uses it.  Modern means not banging sticks and rocks using named pipes for IPC and re-implementing object serialization.

I mean, seriously, this is a bunch of whining over nothing.  Don't like it, don't use it.  Move on with your life.  Turn it off if you want to, who cares, it's your machine.  Just don't go crying when you can't do something "simple" like drag and drop or handle URLs.  *Nobody is actually making programming decisions about which IPC to use between differing pieces of software here.*



astyle said:


> But if I read up on the Internet about how the poor design is actually what's getting in the way of using the DE... I would want to switch my DE to something that works, and is reasonably snappy on my machine.



Or you could just... use it... and not take somebody else's word for it (who probably crippled it anyway because they hated DBus).  It could be like the user that complained to me about an app not updating during the day.  Turns out, they turned cellular data off for the app.  Oh yeah, it's the app's fault...


----------



## drhowarddrfine (Jul 29, 2021)

hardworkingnewbie said:


> your idea about "modern DE" is not from the last millenium, and roughly 30 years old.


I have not been following this thread but age is never an indicator of quality.


----------



## Jose (Jul 30, 2021)

msplsh said:


> It's a requirement because you are NOT the one implementing the software that uses it.


Why is who implements it important?


msplsh said:


> Modern means not banging sticks and rocks using named pipes for IPC and re-implementing object serialization.


Named pipes is a Windows (and OS/2!) thing. I'm pretty sure no one here has advocated them as an alternative to Dbus. I'm also pretty sure they have nothing to do with sticks or rocks.


----------



## Jose (Jul 30, 2021)

ralphbsz said:


> ...A lot of the arguments against the existing implementation that's used in FOSS DEs is that it is associated with things and people (such as Linux or Lennart) that some people consider "evil"; that is a very weak argument to evaluate technology.


Sorry about the multiple quotes, but I forgot this earlier. You might want to read upthread:


hardworkingnewbie said:


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


Linus is a far more talented programmer than I'll ever be. Sure, he can be crude sometimes, but this analysis is enough that I don't need to suffer through the code myself. I believe him.


----------



## astyle (Jul 30, 2021)

Jose said:


> Sorry about the multiple quotes, but I forgot this earlier. You might want to read upthread:
> 
> Linus is a far more talented programmer than I'll ever be. Sure, he can be crude sometimes, but this analysis is enough that I don't need to suffer through the code myself. I believe him.


If everything I like in my DE just so happens to have been written by a programmer that I just happen to be a fan of - that's just a nice tidbit of info to know.  My priority would be still having rock-solid stuff that just works. FWIW, Russian for 'Software' is 'программное обеспечение'. A nice (and very apt) pun translation of those two words would be 'implementation that frees you from worries'.


----------



## Beastie7 (Jul 30, 2021)

The best thing we could do here is simply not use all of this crap; or purge it from the tree. Personally, I see no reason to even bother with any Red Hat/GTK suckware. Most major applications have migrated to Qt-land anyway, and KDE hosts probably a major portion of that. Sure, it's in C but the community/documentation/quality kills kittens.



Jose said:


> Linus is a far more talented programmer than I'll ever be. Sure, he can be crude sometimes, but this analysis is enough that I don't need to suffer through the code myself. I believe him.



Linus has a big mouth + 1 billion dollars. I don't think he's as talented as the mockingbird tells us he is. I don't think he's crafted anything worthy of praise since Git either.


----------



## sidetone (Jul 30, 2021)

Beastie7 said:


> The best thing we could do here is simply not use all of this crap; or purge it from the tree.


That's not going to happen. There's reluctance, which is fine, I wish there were a way those with opposing views on it can be satisfied with the tree.


Beastie7 said:


> Personally, I see no reason to even bother with any Red Hat/GTK suckware.


Gtk, trimmed down, and implemented differently in a minimal way, that's not reliant on the latest upstreams would be fine. Gtk2 may work well this way. As long as upstream doesn't demand the exact versions for Gtk applications.

My thumbs up wasn't to your whole comment. I'm not concerned about what Linus does. The Linux kernel is an achievement, early on there were breaking achievements, and some things he says makes sense. I don't care for the loud parts of the personality. I admire the Minix kernel more, but Minux doesn't offer the features of FreeBSD.


----------



## ralphbsz (Jul 30, 2021)

Jose said:


> Named pipes is a Windows (and OS/2!) thing.


They are actually much older; I remember using them in the late 80s or early 90s. Together with shared memory.



> I'm pretty sure no one here has advocated them as an alternative to Dbus. I'm also pretty sure they have nothing to do with sticks or rocks.


A few pages up, BSD-Kitsune and mer advocated using Streams/STREAMS and domain sockets. Named pipes are fundamentally a way to have a socket that is persistent and always found at the same place. What they ignore is the semantic gap.


----------



## Beastie7 (Jul 30, 2021)

sidetone said:


> That's not going to happen. There's reluctance, which is fine, I wish there were a way those with opposing views on it can be satisfied with the tree.



Then we really shouldn't be complaining about or questioning D-Bus at all. It's an upstream standard we do not control.

helloSystem is our only hope away from this type of influence.


----------



## hardworkingnewbie (Jul 30, 2021)

ct85711 said:


> I will say, a dbus setup is no way needed for a modern DE, take a look at windows, Mac OS, or even Android.  Dbus is a linux thing, but software that is designed to work on other OS, quietly fails and does it in another fashion for OS that don't have dbus.  Sure you could have dbus on windows, even qt will compile the dbus client portion; but you still need the server end that handles the back-end portion of dbus to work.


Both Windows and MacOS have similar mechanisms at place since ages, because they need such a thing. For Windows it is being COM and for MacOS Apple Events. These technologies are all really, really old. So it was bound to happen that a *NIX based DE sooner or later will have the need for a such thing as well.


----------



## msplsh (Jul 30, 2021)

Jose said:


> Why is who implements it important?


Uhh, because when you write a program, you get to decide how you're going to implement it and what libraries to use?



Jose said:


> Named pipes is a Windows (and OS/2!) thing. I'm pretty sure no one here has advocated them as an alternative to Dbus. I'm also pretty sure they have nothing to do with sticks or rocks.



Not sure if you're being willfully obtuse or not.  Named pipes are not "modern" and Windows having them does not make them modern.  Windows was at one time POSIX compliant.  What they have to do with sticks and rocks is that they are both not "modern" tools for building things in their respective domains.

"Modern" would mean not marshaling data yourself through a socket or a pipe.  Not building a message queue.  Not building an event dispatch mechanism for an event loop.


----------



## sidetone (Jul 30, 2021)

Jose said:


> Why is who implements it important?





msplsh said:


> Uhh, because when you write a program, you get to decide how you're going to implement it and what libraries to use?


My interpretation of that is, they get a lot of say. The one who is able to implement it, is the one who gets the say. It may not be the best say. I would put it like, why should their importance on the implementation be that heavy, rather than doing it a better way. Of course, they implemented it, and are capable, while I'm not. Some things I wish I could implement, and I can't, so I have to go with what they do.

One could say, Pottering implements things the wrong way. Why should his implementations be so prevalent? Because I can't implement it. I've implemented improvements in the ports tree before, where things worked a lot better afterwards. But on other subjects I can do well, I know how to make things better, and see them work well.

I can also say, why don't they take hints from the community and do it better? Or make it as efficient as a math problem? My guess is, RedHat or another major Linux distribution want to make money on having a customer support version/service and an opensource version. They're companies there to make money. The community doesn't have the crowd with ability to make enough implementations or improve upon them much more. I've improved implementations on the ports tree, and I wish I could learn C, but even then, there's only so much 1 person could do.


----------



## msplsh (Jul 30, 2021)

There's two different complaints here: libdbus is kinda junky and why do apps use DBus because the version we have to use on FreeBSD is junky.

Apparently the Linux people have redone DBus _twice_: Once for SystemD in userspace in 2013 (which apparently works quite well) and once for dbus-broker in kernelspace in 2017 (Fedora uses this as of 2019 and also seems to work well).  Linux has more users than FreeBSD, so if they solved their junky DBus problem with a Linux-only solution, then they have mostly extracted themselves from the problem and have taken the manpower to solve issues in libdbus that would affect FreeBSD with them.  This explains why libdbus remains junk: The problem was solved in a place FreeBSD can not go.

There's a lot of apps that use DBus, so the most practical plan would be to fix the most pressing issues plaguing libdbus for people using apps that need DBus.  DBus isn't going away, so if it makes it into the Linux kernel, I would think the need for FreeBSD to have a decent implementation will grow.  Would seem like a Foundation project.

Most of the other ideas in this thread appear to only to solve the problem of "I don't like trying to install some app and then discovering it pulls in DBus" such as:

* Use some other IPC:  Untenable and unreasonable.  "Some other IPC" requires reprogramming all apps that use DBus.
* Remove all the DBus apps from ports:  Also unreasonable for people who use those apps.
* Turn DBus off in make.conf: Reasonable, just don't plan on using packages.  There may be ports that will not operate without DBus and can not respect this, however.


----------



## hardworkingnewbie (Jul 30, 2021)

sidetone said:


> I can also say, why don't they take hints from the community and do it better? Or make it as efficient as a math problem? My guess is, RedHat or another major Linux distribution want to make money on having a customer support version/service and an opensource version. They're companies there to make money. The community doesn't have the crowd with ability to make enough implementations or improve upon them much more. I've improved implementations on the ports tree, and I wish I could learn C, but even then, there's only so much 1 person could do.


Well talking about Poettering what many people seem to forget when talking about systemd is that it was by far means not the first time someone dumped it and created something different.

Ubuntu had upstart back then. Apple under MacOS created something called launchd. Solaris has SMF. And so on and on...


----------



## zirias@ (Jul 30, 2021)

I didn't bother to read the whole thread now (sorry for that), just answering the initial question:

On a "desktop" machine, there's a need for many components/processes to communicate with each other (window manager and other GUI components, network management, removable media, services allowing local users some limited administrative actions like shutdown or reboot, screen savers and lockers, ... probably some more).

Now, Unix systems traditionally provide means for IPC (inter-process communication) like pipes, sockets, shared memory, etc. But these are "primitives", and the two ends of the communication need to know each other. To allow _many_ processes to communicate with each other, and to decouple them (so they don't need knowledge about their communication partner), at the very least, a common protocol is needed. On the technical side, a few architectural concepts exist to enable this kind of communication. One of them is a "message bus/broker" – a central instance that accepts messages and forwards them to other clients who "subscribed" for them. Of course, this is implemented on top of the primitives already offered by the operating system. The result is that any peer only needs to know the central broker.

d-bus is an implementation of that message-bus idea. I never looked into d-bus specifically, so I can't say whether it is a _good_ implementation of the concept…


----------



## Jose (Jul 30, 2021)

msplsh said:


> Named pipes are not "modern" and Windows having them does not make them modern.


They seem to be supported on "modern" Windows:








						Named Pipes - Win32 apps
					

A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients.



					docs.microsoft.com
				





msplsh said:


> Windows was at one time POSIX compliant.  What they have to do with sticks and rocks is that they are both not "modern" tools for building things in their respective domains.


POSIX is not "modern" enough for you either? Should Freebsd abandon POSIX compliance so it can satisfy your definition of "modern"?


msplsh said:


> "Modern" would mean not marshaling data yourself through a socket or a pipe.  Not building a message queue.  Not building an event dispatch mechanism for an event loop.


Why? Cause you lack the skills to do so? So "modern" programmers are incompetent?


----------



## Jose (Jul 30, 2021)

Zirias said:


> On a "desktop" machine, there's a need for many components/processes to communicate with each other (window manager and other GUI components, network management, removable media, services allowing local users some limited administrative actions like shutdown or reboot, screen savers and lockers, ... probably some more).


What is Windows' message bus? Apple's?


----------



## astyle (Jul 30, 2021)

FWIW, pipes were introduced to POSIX in 1988. Named pipes are a pre-1993 standard. Latest POSIX standards are from 2017, and IEEE's page clearly says that "System configuration and resource availability" is outside POSIX scope.


----------



## astyle (Jul 30, 2021)

Jose said:


> Why? Cause you lack the skills to do so? So "modern" programmers are incompetent?


Someone whose expertise is frankly is web programming would know stuff like XSS, session cookies, HTML5, security certs, and headless browsers. They'd be up to date on that topic. Someone whose expertise is frankly databases - they'd know how to create a usable query, how to connect to a database server with one client or another, how to figure out the schema of the tables, the benefits of having a real RDBMS vs using flat files, and how to stay up to date on that. Both would qualify as "Modern Programmers", if they are up to date in their respective areas of expertise. Both would qualify as "Competent Programmers" if they have at least some degree of familiarity with a versioning system like Git, and with chores that programmers have to do like testing the code, making sure it works for the customer, and other stuff I'm not even thinking of right now.

But asking a DBA to analyze a web design - that's asking for trouble. A DBA has enough on his plate making sure the database works, and is up to snuff. They may have no sense of UI design, or what it takes to produce a good UI in a browser. If you lack the resources to hire someone to put a pretty web interface on a database - then the DBA will be tasked with that chore. The results may be workable, but not eye candy that you can proudly display.

The point of my post is that it's OK to not have the expertise to evaluate the design of dBUS.  It's just that screaming that 'dBUS has to be changed at the source, look, I'm doing fine without it!' ends up being just noise that gets ignored. This thread is a good place to learn a little about dBUS, but probably not for getting emotional, judgemental, and personal.


----------



## msplsh (Jul 30, 2021)

I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back:
You can support old standards and new ones at the same time.  Everything has limitations.  "Modern" design takes ideas from the past and improves on them.  Improved ideas can be implemented badly.  Simple primitives does not mean perfect or even easy to use. Just because you can develop a sophisticated IPC mechanism from primitives doesn't mean this is a good use of developer time.  Finally: Bespoke IPC is not useful for interoperability since only your programs would be using it.


----------



## msplsh (Jul 30, 2021)

Jose said:


> What is Windows' message bus? Apple's?


Similar technologies on these platforms are COM, DDE, WCF, NSNotification, XPC.


----------



## BSD-Kitsune (Jul 30, 2021)

A lot of arguing over what is and isn't "modern". Let me specifically put in my .02 on that. I don't consider "Modern" to be about eye-candy, such as text rendering, or transparency, or superficial things like "snapping". 

No, what separates modern from not-modern, and this is no slight against the people who prefer these styles, just a statement of objectivity from this viewpoint (I used to use i3!) is the following to me:

1. Window controls that include a drop-down menu, easily understandable widgets and elements (i.e. does a widget either have a self-explanatory visual or does it have a label that says what it does) and ways to resize and drag the window with the mouse by clicking a border, topbar, or some other part of the window that isn't the actual content of the window, as opposed to more primitive/older tiling, reparenting and nonreparenting window managers. 

2. Does the desktop have an easily usable menu that can launch programs, either by clicking on the desktop or on the menu itself? 

3. Does the desktop have a way to minimize or get windows out of the way, such as via a taskbar, iconifier, dock etc?

Those are the hallmarks. Not age, not eye candy. 



hardworkingnewbie said:


> I guess we should come back discussing that point when your idea about "modern DE" is not from the last millenium, and roughly 30 years old.



See above. IMHO, Windows 2000's UI is no less modern than Windows 10's or macOS's, and avoids many of the flaws of those. I should be able to render a basic desktop with a bottom bargain bin GPU. 



msplsh said:


> It's a requirement because you are NOT the one implementing the software that uses it.  Modern means not banging sticks and rocks using named pipes for IPC and re-implementing object serialization.
> 
> I mean, seriously, this is a bunch of whining over nothing.  Don't like it, don't use it.  Move on with your life.  Turn it off if you want to, who cares, it's your machine.  Just don't go crying when you can't do something "simple" like drag and drop or handle URLs.  *Nobody is actually making programming decisions about which IPC to use between differing pieces of software here.*



Sorry to be captain obvious here, but C and UNIX were not designed with objects in mind. If you want that, use IBM i, macOS, or Haiku or something built either in a modern OOP language with actual bindings for those things at the very core level of the OS, or that is designed for object-based programming (as IBM i is)

I'm not gonna argue it's against the UNIX philosophy, but there's a reason people hate stuff like GObject, and disliked Bonobo and DCOP and other stuff that came before dbus. Object models do not belong on UNIX in that manner. 

STREAMS is not sticks and rocks. It is point-to-point, but you'll notice it allows for stacks. What does that mean? you can share sockets, drivers, and such between different streams, using a mutex or other means of serializing access between them. 



msplsh said:


> I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back:
> You can support old standards and new ones at the same time.  Everything has limitations.  "Modern" design takes ideas from the past and improves on them.  Improved ideas can be implemented badly.  Simple primitives does not mean perfect or even easy to use. Just because you can develop a sophisticated IPC mechanism from primitives doesn't mean this is a good use of developer time.  Finally: Bespoke IPC is not useful for interoperability since only your programs would be using it.



Jose is being sarcastic, but not unprofessional. He has his points, and while he's being flippant, you're the only one squawking about how he's in bad faith. If you smelt it, maybe you dealt it, as the saying goes. 

But I agree with you. Bespoke IPC is not useful. My argument is FreeBSD, or maybe the BSDs as a whole, should crowd around an alternative to dbus. Clearly, there's security issues, let's not mince words or deny it. Clearly, it's not designed with us in mind. Clearly, it's a bodged together project on non-Linux platforms. Ok, so we've identified the issue. Maybe someone (not myself, because of my position and the fact I'm hated by several openbsd devs for speaking like Theo, which amuses me to no end) should start a dialogue, come up with a reasonable standard. I would propose STREAMS plus a message protocol, and make sure our STREAMS implementation is thread-safe by way of ensuring serialization at every step of the way. For as much as Ritchie hated it, having things like this in kernel DOES have advantages, especially with less context switching.


----------



## astyle (Jul 30, 2021)

BSD-Kitsune said:


> i3


Intel processor or a Desktop Environment?


----------



## BSD-Kitsune (Jul 30, 2021)

i3wm-- obviously. I was saying that I've used it. I just made the statement that tiling wms are inherently more primitive -- that doesn't make them bad however. Just "older" technology-wise.


----------



## msplsh (Jul 31, 2021)

BSD-Kitsune said:


> Sorry to be captain obvious here, but C and UNIX were not designed with objects in mind.



Yet somehow a company built a very successful desktop and mobile OS on top of it that uses objects everywhere (Apple).  You rattled off a bunch of things people "hate" but that have eventually succumbed to the pressure consolidate around a single standard that is now DBus.



BSD-Kitsune said:


> But I agree with you. Bespoke IPC is not useful ... crowd around an alternative to dbus.



1. That's seemingly contradictory
2. Who's going to do it?
3. Once you have it, why would anyone implement it? Particularly if you're anti-objects, why would people working on projects that use DBus to send objects use it?  Why would people working on projects that DON'T send objects use something that's "supposed to replace DBus" when they could use older IPC methods?

DBus is not going away and UNIX software is going to target Linux first and FreeBSD if it's easy.  If DBus works on Linux just fine and it's terrible on FreeBSD, then it's up to the FreeBSD community to fix DBus.  We're not in the drivers seat on this one.


----------



## BSD-Kitsune (Jul 31, 2021)

I didn't cave to anything so I don't understand why you think that I am against a unified standard. I'm not, but I'm against one that has GNU/Linux at the forefront. Clearly you have different priorities. 

As far as macOS goes, significant portions of it were written in objective C and are probably now written in Swift. XNU isn't UNIX, neither is macOS. The open group certifications don't mean anything to me when the entire design philosophy is descended from Mach, not UNIX. No what constitutes Unix in my book is based on lineage and continued usage of the same conventions that were established. Apple has chosen to break with all those and on top of that is neglectful of its open source counterpart Darwin.


----------



## Jose (Jul 31, 2021)

msplsh said:


> I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back...


"Modern" is a word deployed to shut down technical debate. Once something is deemed "modern" it is beyond criticism, and once something is found to be not "modern" it's not worth talking about any more.

What's new is not necessarily good and what's old is not necessarily bad. This much should be obvious, but apparently it still has to be said.



msplsh said:


> Similar technologies on these platforms are COM, DDE, WCF, NSNotification, XPC.


None of those are message buses.



BSD-Kitsune said:


> But I agree with you. Bespoke IPC is not useful. My argument is FreeBSD, or maybe the BSDs as a whole, should crowd around an alternative to dbus.


And yet the two most popular computer desktops of our day do not have a message bus. They're simply not necessary. Heck, Dbus support is at most optional in all the desktop software I want to use. Saddle yourself with that unnecessary Redhat Linux crapware if you like, but don't try to convince me it's indispensable.


----------



## BSD-Kitsune (Jul 31, 2021)

Jose I think we're on the same side here. What I'm advocating for is a sane alternative. Something that is designed with the constraints in mind and can offer a little bit of what people might be looking for without having to deal with that stupid object model crap that is constantly shut down our throats in the forms of gobject, dbus, etc.

I've stated my piece here but I don't want to start having people pick fights with me just over minor details when we all have the same goal: no dbus, no polkit, no Linux shovelware.


----------



## Jose (Jul 31, 2021)

BSD-Kitsune said:


> I've stated my piece here but I don't want to start having people pick fights with me just over minor details when we all have the same goal: no dbus, no polkit, no Linux shovelware.


I didn't mean to pick a fight. I'm actually a fan of OOP, but I agree that it's not for everyone.

I don't think that's the biggest problem with Dbus. I'm not sure something like Dbus is actually needed for a desktop. I'm not allergic to message buses, I use and like Kafka at my day job, but I'm not convinced that it's the best design for desktop app intercommunication. I can see the arguments for it, but the fact is some pretty good desktops get along fine without it, and the one implementation we do have is pretty bad.


----------



## astyle (Jul 31, 2021)

Jose said:


> "Modern" is a word deployed to shut down technical debate. Once something is deemed "modern" it is beyond criticism, and once something is found to be not "modern" it's not worth talking about any more.


Andrew Tanenbaum noted in several of his books that concepts do get recycled. A direct quote from his Modern Operating Systems, Second Edition:


> Early computers had hardwired instruction sets. The instructions were executed directly by the hardware and could not be changed. Then came microprogramming, in which an underlying interpreter carried out instructions in the software. Hardware execution became obsolete. Then RISC computers were invented, and microprogramming (i.e., interpreted execution) became obsolete, because direct execution was faster. Now we are seeing a resurgence of interpretation in the form of Java applets that are sent over the Internet and are interpreted upon arrival. Execution speed is not always crucial because network delays are so great they tend to dominate. But that could change, too, some day.


Things sure did change, with YT. So it's kind of pointless to bash things as "modern" or "not modern". There probably are alternatives to dBUS available. If dBUS was really not needed, then it would not have the critical mass of popularity that is needed to keep it under maintenance and in use (even if some people quibble with implementation details).


----------



## msplsh (Jul 31, 2021)

Goalpost moving on what UNIX is, redefining words, "it doesn't have bus in the name so it can't be achieving the same goals."  Ok, whatever, I tried to make this grounded in reality, I'm out.


----------



## zirias@ (Jul 31, 2021)

Jose said:


> What is Windows' message bus? Apple's?


As I said, a message bus is _one_ architectural pattern to solve this. There are others of course. Windows uses COM and its descendants heavily. This kind of serves the purpose in allowing cross-process access to objects, decoupling is done by using interfaces only.

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

IMHO, the message bus architecture is superior to something based on "remote objects". You get the publisher/subscriber mechanism for free, you can easily add queueing, etc...

I have no idea what Apple is doing, I really don't care about their software. Surely, they do _something_ for common communication between many components/processes.


----------



## sidetone (Jul 31, 2021)

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.

```
~ % 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.


----------



## zirias@ (Jul 31, 2021)

BSD-Kitsune said:


> C and UNIX were not designed with objects in mind.


Objects doesn't necessarily mean OOP. You might want to count the usage of the word "object" in the C language standard documents.



sidetone said:


> Perhaps qt5-dbus is better implemented than regular dbus?


This is just Qt's adapter to easily use d-bus. There's only one d-bus.

linux-c7-dbus-libs are also client libraries for using d-bus. A Linux binary can't use a FreeBSD library, the libraries have to be built for Linux as well. So, there's nothing redundant here.


----------



## sidetone (Jul 31, 2021)

I thought they used elf on them. Maybe that was for binaries [, perhaps not relating to libraries]. Even if they could, the actual content, aside from the type of file, must be different enough or different versions.


----------



## zirias@ (Jul 31, 2021)

ELF is the binary format. Yes, that's used on both systems. Just the format doesn't make a FreeBSD library compatible with a Linux binary. The FreeBSD kernel exposes a completely different ABI (syscalls) to Linux processes. Trying to use a FreeBSD library from a Linux binary would already fail for that reason, cause it would expect (and not find) the FreeBSD ABI.


----------



## kpedersen (Jul 31, 2021)

Zirias said:


> For a bit of history, KDE used something very similar, CORBA, in the past.


Same with GNOME. Good memories of:


```
waiting for bonobo activation server
...
retrying
...
bobobo activation failed
```

bobobo was as pointless as dbus is used today. These are GUI programs written by kids. Not rocket science.


----------



## zirias@ (Jul 31, 2021)

kpedersen I don't think d-bus is "pointless". Sure, it doesn't _have_ to be a message bus (see above), but there's definitely a need for many peers to communicate without tight coupling in a "desktop" system. I personally think a message bus is well suited to satisfy this need. But, as I said, I can't say anything about the quality of d-bus. I never used it myself (from the programmer's perspective).

*edit:* Maybe I misunderstood your wording? Did you mean bonobo is "pointless" _because_ d-bus is used now? 

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

```
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"'
```


----------



## kpedersen (Jul 31, 2021)

Zirias said:


> but there's definitely a need for many peers to communicate without tight coupling in a "desktop" system.
> 
> *edit:* Maybe I misunderstood your wording? Did you mean bonobo is "pointless" _because_ d-bus is used now?


Well I suppose bonobo *is* pointless now we have dbus but mainly I don't feel that there is such a need for peers to communicate.

Can you suggest any use-cases? The only ones I can (copy/paste, window automation) is handled by X11's Atom message system. For example, why should my calculator app be able to send messages to my file manager? Has anything been done that you can't live without?

As far as my experiences have been, all the broken-ness in the FreeBSD ports of Xfce, KDE and Gnome stem from failed IPC. We should do what the OpenBSD guys do and rip it out of most of the ports and replace it with fake stubs.


----------



## zirias@ (Jul 31, 2021)

kpedersen said:


> Can you suggest any use-cases?


I have a few generic ones in my first post to this thread: https://forums.freebsd.org/threads/why-do-we-need-d-bus.78868/post-525052


----------



## kpedersen (Jul 31, 2021)

Zirias said:


> I have a few generic ones in my first post to this thread: https://forums.freebsd.org/threads/why-do-we-need-d-bus.78868/post-525052



Can all of these not be achieved with a suid-exec helper binary with specific groups for the authorized users? Xfce4 used to do this and it honestly worked better than the sudo fallback and then that Polkit crud that it moved to. It really does seem that `chmod +s` is easier than trying to write a safe / stable message bus.

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


----------



## zirias@ (Jul 31, 2021)

kpedersen said:


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



kpedersen said:


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





						XScreenSaver: On Toolkit Dialogs
					

XScreenSaver is a collection of free screen savers      for X11, Linux, macOS, iOS and Android.




					www.jwz.org
				











						Why screen lockers on X11 cannot be secure
					

Today we released Plasma 5.2 and this new release comes with two fixes for security vulnerabilities in our screen locker implementation. As I found, exploited, reported and fixed these vulnerabilit…



					blog.martin-graesslin.com
				




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


----------



## kpedersen (Jul 31, 2021)

Zirias said:


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


Zirias said:


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


Zirias said:


> 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 (Jul 31, 2021)

sidetone said:


> 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.
> 
> ```
> ~ % psearch dbus | grep -vi api | grep -vi interface | grep -vi binding
> ...


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.


----------



## sidetone (Jul 31, 2021)

astyle said:


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


astyle said:


> Oh, and this:
> I have done it on an actual bicyle... Rode 3 miles to drop them off at the shop.


That's for a reason though.


----------



## garry (Jul 31, 2021)

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 (Aug 1, 2021)

Zirias said:


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



Zirias said:


> *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:
> 
> ```
> DestroyFunc Shutdown
> ...


Are you saying that that is better than this?

```
doas shutdown -p
doas reboot
```


----------



## sidetone (Aug 1, 2021)

Jose said:


> Are you saying that[,] that is better than this?
> 
> ```
> doas shutdown -p
> ...


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 (Aug 1, 2021)

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 (Aug 1, 2021)

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 (Aug 2, 2021)

ct85711 said:


> 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 (Sep 11, 2021)

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






						dpaste: D8MSMH49H
					






					dpaste.com
				




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 (Oct 1, 2021)

BSD-Kitsune said:


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


BSD-Kitsune said:


> 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 (Oct 1, 2021)

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


----------



## mrbeastie0x19 (Oct 1, 2021)

Beastie7 said:


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


----------



## Beastie7 (Oct 1, 2021)

mrbeastie0x19 said:


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



Damnit


----------



## astyle (Oct 1, 2021)

Beastie7 said:


> Damnit


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 (Oct 1, 2021)

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 (Oct 17, 2021)

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.


----------



## TahaFiroz (Dec 13, 2021)

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.


----------



## baaz (Dec 13, 2021)

TahaFiroz said:


> 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


----------



## Jose (Dec 13, 2021)

TahaFiroz said:


> 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?


----------



## Alain De Vos (Dec 13, 2021)

I have 1100 packages dependent on dbus installed ...


----------



## baaz (Dec 14, 2021)

Alain De Vos said:


> I have 1100 packages dependent on dbus installed ...


that's the problem


----------



## Alain De Vos (Dec 14, 2021)

I consider devel/gvfs an annoyance.


----------



## grahamperrin@ (Dec 14, 2021)

Alain De Vos said:


> I consider devel/gvfs an annoyance.



It's generally useful, however there's this annoyance: FreeBSD bug 254024 – devel/gvfs: gvfsd-trash latches to zfs volumes


----------



## ct85711 (Dec 14, 2021)

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


----------



## kpedersen (Dec 14, 2021)

Alain De Vos said:


> I consider devel/gvfs an annoyance.


Indeed. Even PCManFM drags it in for something as trivial as the recycle bin functionality. For a light file manager use-case, the author made an error here. For our virtual desktop system I ripped it out and patched in my own solution. Purposely not following the freedesktop specifications.


----------



## jbo (Dec 14, 2021)

I'm running a FreeBSD desktop for several months now. I have DBUS disabled on my package builds and other than this little hiccup I have yet to encounter any problems/disadvantages:









						Solved - Thunar not saving preferences
					

I wanted to give x11-fm/thunar a try.  While the basic stuff seems to work, editing preferences (Edit -> Preferences) seems to have no effect. When I re-open the preferences window, prior changes such as the default view, date format and so on are all reverted to the default values. It doesn't...




					forums.freebsd.org
				




But I guess this is also highly subjective & depending on your "workloads" or "workflows". I know there are several people here that want to have "the full KDE" experience - that's something I'm simply not after so I can't speak for those situations.


----------



## Zare (Dec 14, 2021)

We used to run hald/dbus combo on FreeBSD 10+ years ago to achieve input on X11. It was the only way.
freedesktop.org is not Linuxisms. freedesktop.org is XDG.

I ran Windowmaker+compton+gnome2-session combo as a lightweight but fully featured in terms of desktop integration and composition, back in late 2000s on my company allocated laptops that were like single core 2.0GHz 4GB ram machines with some cheapass mobile nvidia.

Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.


----------



## Jose (Dec 14, 2021)

Zare said:


> Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.


Just because it doesn't peg the CPU doesn't mean it doesn't slow things down, and my main concern is security anyway.


----------



## Zare (Dec 14, 2021)

Certainly if one does "without dbus" whole desktop build and it's operational, the board and the community will benefit from that kind of a procedure.

Regarding your main concern





						D-bus Project : Security vulnerabilities
					

Security vulnerabilities related to D-bus Project : List of vulnerabilities 			related to any product of this vendor. Cvss scores, vulnerability details and links to full CVE details and references



					www.cvedetails.com
				




The most serious vulnerability was discovered 10 years ago and it allowed information disclosure and denial of service. A local exploit without any privilege escalation consequence. 

I believe that this discussion is moot. It was an official handbook procedure to enable dbus in rc.conf for FreeBSD for several consecutive releases in order to have operational X11 desktop. 

What is the security status of all the installed non-dbus applications? Have they gone under such a scrutiny that dbus seen in last 15 years as integral component of *nix desktop? Has that scrutiny resulted in less than impressive (from hacking standpoint) CVE log? What spawns in your processes during your entire runtime, has everything been CVE checked in such a manner that dbus is left as the Pedro and the most suspicious component?

Again I'm not trying to demotivate anyone but show my viewpoint. You need to find a sweet spot between security and functionality. You need to take a good look at things and set aside those that do not concern you.


----------



## baaz (Dec 14, 2021)

Zare said:


> freedesktop.org is not Linuxisms. freedesktop.org is XDG.


I consider "free"desktop the exact meaning of linuxisms 
it's a project started by redhat , and redhat is the purest form of linuxism and THE thing that twisted linux to what we see now  and if you want to say that "free"desktop is only "standards" , no look at thir Wikipedia page and the projects that they host(hosting is a kind of supporting right?)
 and I don't know if they count as linuxisms but things like 
*SYSTEMD *and *GNOME *stand out
 and for the second sentence, what's the point? XDG is the pervious name of "free"desktop
again if it was only about the standards out of all there is I don't want redhat to tell what are them and "Promote" them


Zare said:


> Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.


actually it dose with a extra deamon not running and millions of lines of code not being executed around the thousands of pakages it really improves the speed of everything. also it's not about only the speed it's about having a extra and totally unnecessary out . with bloat you have a extra surface for attack a extra chance of a crash and  a extra chance of unexpected behavior and etc


----------



## shkhln (Dec 14, 2021)

Let's see:

has a lot of code;
slows everything down;
bad for security;
has unnecessary IPC stuff;
everything depends on it;
maintained by Red Hat.
When did this turn out into an Xorg bashing thread?


----------



## kpedersen (Dec 15, 2021)

Zare said:


> freedesktop.org is not Linuxisms. freedesktop.org is XDG.


Not Linuxisms exactly but these days they attract the same kinds of weird decisions. Something about "graphics" and "desktop experience" seems to attract heaviness and bloat bad software.

Granted, they have a lot of pressure on them from many different angles but why do I need to get involved with that? Just go against the standards and get on with my life


----------



## Zare (Dec 15, 2021)

baaz said:


> actually it dose with a extra deamon not running and millions of lines of code not being executed around the thousands of pakages it really improves the speed of everything. also it's not about only the speed it's about having a extra and totally unnecessary out . with bloat you have a extra surface for attack a extra chance of a crash and  a extra chance of unexpected behavior and etc



This is generalization. Like I said I don't care about d-bus but it was in official FreeBSD procedure 10 years ago.
Why those "millions of lines of code" did not affect our desktop experience then. You also run a full kernel with "billions of lines of code" but the majority of code paths you will never ever execute. 

FWIW if dbus were brokerless none would even bother.


----------



## kpedersen (Dec 15, 2021)

Zare said:


> This is generalization. Like I said I don't care about d-bus but it was in official FreeBSD procedure 10 years ago.


Kind of. It was more because Xorg kept flapping about trying to decide on hald or other bad ideas.
Many of us just added:


```
Option "AutoAddDevices" "false"
```

To their xorg.conf and kept hald and dbus junk off the machines until this *bug* was fixed a release or two later.


----------



## Zare (Dec 15, 2021)

kpedersen said:


> Kind of. It was more because Xorg kept flapping about trying to decide on hald or other bad ideas.
> Many of us just added:
> 
> 
> ...



AFAIR that option did not work for laptop usage, you'd need to restart the server if you plugged in external mouse or keyb.

For release or two we used to use this thing. Again I don't care about it but I don't see is as red herring either.

As far as I'm concerned dbus is not an unsafe piece or software, or a resource hog, or a wallgarden component or Linux specific in any way.

What people are simply wrong about is the security component. There is 10 times more chance you're going to find an malformed input exploit in some x11-fm obscure piece of software than in dbus.

Since I don't care either way I do not wish to pursue this discussion apart from saying that no-one here has conviced me that a security tight desktop should come without dbus.


----------



## Alain De Vos (Dec 15, 2021)

Another thing which can be annoying is file-access-monitoring like fam,gamin,gam-server


----------



## Jose (Dec 15, 2021)

Zare said:


> Regarding your main concern
> 
> 
> 
> ...


It's a bad design implemented to work around the Unix permissions model. No Dbus bug here, and still results in a privilege escalation:








						Privilege escalation with polkit: How to get root on Linux with a seven-year-old bug | The GitHub Blog
					

polkit is a system service installed by default on many Linux distributions. It’s used by systemd, so any Linux distribution that uses systemd also uses polkit.




					github.blog
				




Back to performance, you might want to read upthread:








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




					forums.freebsd.org


----------



## kpedersen (Dec 16, 2021)

Zare said:


> AFAIR that option did not work for laptop usage, you'd need to restart the server if you plugged in external mouse or keyb.


Fair enough; though I do use a laptop daily and it still worked well enough for me. Admittedly i do not ever plug in an external mouse or keyboard. *My* laptop comes with both inbuilt 



Zare said:


> malformed input exploit in some x11-fm obscure piece of software





Zare said:


> no-one here has conviced me that a security tight desktop should come without dbus.


Exactly right. A security tight desktop should probably come without *any* GUI capabilities and especially not a graphical file manager. So dbus has limited use at that point anyway.


----------



## eternal_noob (Dec 16, 2021)

kpedersen said:


> A security tight desktop should probably come without *any* GUI capabilities and especially not a graphical file manager.


You only have real security if the computer in question doesn't have a connection to the internet.


----------



## Alain De Vos (Dec 16, 2021)

I'm running tons alot of services on address 127.0.0.1 without nat.
But in fact my only connection to the dangerous external world is when i use firefox.


----------



## kpedersen (Dec 16, 2021)

eternal_noob said:


> You only have real security if the computer in question doesn't have a connection to the internet.


Very true. In many ways I do keep GUI and internet access mutually exclusive. In particular I would never connect Windows to the raw network. It always sits on an isolated network with something like a Raspberry Pi running a SOCKS5 proxy for Firefox to view web pages. It solves so many issues. Projects such as PiHole are even developed to capture that niche for "normal" security conscientious users.

I just wish I could keep web browsers offline. They are the biggest scum!


----------



## Jose (Dec 16, 2021)

kpedersen said:


> I just wish I could keep web browsers offline. They are the biggest scum!


----------



## mefizto (Dec 16, 2021)

Hi kpedersen,



kpedersen said:


> It always sits on an isolated network . . .



Could you please explain how did you isolate the networks?

Kindest regards,

M


----------



## kpedersen (Dec 17, 2021)

mefizto said:


> Could you please explain how did you isolate the networks?


Pretty much by simply not connecting them to the wider world.


```
Isolated PC ------------------- Raspberry Pi ================== Main internet
                            |
Isolated Laptop -------------
```

The Raspberry Pi is not set to route packets, there is no NAT. It is impossible for data to come in or out between networks. Instead it runs a SOCKS5h proxy, HTTP Proxy and SSH for application layer routing. The best thing is that this contains the brokenness of even Windows software because unless you specifically tell them, they can't implicitly know about these proxies and so cannot perform their inbuilt malware related tasks like "auto updates".

* I actually use an old Thinkpad but a Raspberry Pi is probably less wasteful of energy.


----------



## mefizto (Dec 17, 2021)

Hi kpedersen,

thank you very much for your answer.  If I understand correctly, even if one connected another computer/network between the "Raspberry Pi" and the "Main internet" running a firewall, that should prevent any connectivity between the networks, correct?

I am asking because I have only a single public internet address and need Windows 10 machine to connect to Internet from time to time.

Kindest regards,

M


----------



## Alain De Vos (Dec 17, 2021)

atril does not compile with option dbus unset


----------



## kpedersen (Dec 17, 2021)

mefizto said:


> even if one connected another computer/network between the "Raspberry Pi" and the "Main internet" running a firewall, that should prevent any connectivity between the networks, correct?


Yes, that should be fine. The rest of the world / network "looking in" will only see the Raspberry Pi and packets coming and going from it. They won't even know the Windows PC behind it exists. Likewise the Windows PC and the software running on it won't even know it is connected to the internet. Only SOCKS/proxy enabled software can be instructed to communicate with the Pi.

It isn't really a "professional" solution. However Windows isn't really a "professional" operating system.


----------



## mefizto (Dec 17, 2021)

Hi kpedersen,


kpedersen said:


> Yes, that should be fine. The rest of the world / network "looking in" will only see the Raspberry Pi and packets coming and going from it. They won't even know the Windows PC behind it exists. Likewise the Windows PC and the software running on it won't even know it is connected to the internet. Only SOCKS/proxy enabled software can be instructed to communicate with the Pi.


Thank you once again for confirming.


kpedersen said:


> It isn't really a "professional" solution. However Windows isn't really a "professional" operating system.


Well, professionals have access to hardware (firewalls), which I cannot afford; perhaps more public addresses to isolate the networks at the Internet interface, etc.

But, unless you can suggest an improvement reachable by non-professionals, I will try to implement this.  As it appears impossible to buy Raspberry Pi at this time, I - like you - will re-purpose an older laptop.

Kindest regards,

M


----------



## ralphbsz (Dec 17, 2021)

kpedersen said:


> ... Instead it runs a SOCKS5h proxy, HTTP Proxy and ...


Which means that a web browser on the "Isolated PC" can download and execute malware. Unless you make sure the web browser on that PC is completely feature- and stateless. And that malware can communicate freely with the outside world, using the http protocol.

A few years ago, someone published something (was it an RFC?) for running TCP/IP over http. I think was meant as a joke (like the old "TCP/IP over carrier pigeon" RFC), but people have now demonstrated running real malware that communicates solely via http.

You want isolated? Cut the cable. And station a marine with a machine gun at the entrance to your computer room.


----------



## kpedersen (Dec 18, 2021)

ralphbsz said:


> Which means that a web browser on the "Isolated PC" can download and execute malware.


Yep, like I mentioned (only half-joking); I really wish a web browser was useful offline . Firefox is probably the most trustworthy of the scummy bunch but they are still very clearly eroding privacy with all their "services".

However my main concern when running Windows is keeping the operating system as a whole offline. I.e to interrupt telemetry, consumer updates and any other issues. The start menu or lock screen has absolutely no business going online to update the visual adverts it displays.

I would always recommend running browsers in a VM (or Jail if Windows was perhaps more useful), however then you might as well simply not choose to run Windows in the first place!


----------



## grahamperrin@ (Dec 25, 2021)

Jose said:


> I've never run into a cli program that needed dbus. You got an example?



Not a CLI, but an unusual example of usage _might_ be jack. 

<https://www.freshports.org/audio/jack/#requiredlib>

<https://www.freshports.org/audio/jack/#message> – one of two ways to start.


----------



## A. D. Sharpe Sr. (Mar 19, 2022)

msplsh said:


> There's two different complaints here: libdbus is kinda junky and why do apps use DBus because the version we have to use on FreeBSD is junky.
> 
> Apparently the Linux people have redone DBus _twice_: Once for SystemD in userspace in 2013 (which apparently works quite well) and once for dbus-broker in kernelspace in 2017 (Fedora uses this as of 2019 and also seems to work well).  Linux has more users than FreeBSD, so if they solved their junky DBus problem with a Linux-only solution, then they have mostly extracted themselves from the problem and have taken the manpower to solve issues in libdbus that would affect FreeBSD with them.  This explains why libdbus remains junk: The problem was solved in a place FreeBSD can not go.
> 
> ...


This is probably the best comment I've seen on this thread. It has me wondering "what exactly would it take in order to actually FIX the FreeBSD DBus problem?" Because we're using a port, right? Maybe its time for us to actually have a native solution. I mean, of course ours it broken -if it's a port that apparently hasn't been developed as a real solution for FreeBSD.


----------



## zirias@ (Mar 19, 2022)

Disclaimer: I still didn't look into dbus implementation, but it's installed on some of my systems as a dependency and so far, it "just worked". So sure, there might be quality issues and I was just lucky so far not to run into them.



A. D. Sharpe Sr. said:


> This is probably the best comment I've seen on this thread. It has me wondering "what exactly would it take in order to actually FIX the FreeBSD DBus problem?" Because we're using a port, right? Maybe its time for us to actually have a native solution. I mean, of course ours it broken -if it's a port that apparently hasn't been developed as a real solution for FreeBSD.


I really really think this is the wrong way to go. I've seen this reflex (let's put stuff in the kernel -- yep, addressing the post you quoted here) far too often. A main driver seems to be "performance". A long time ago, Linux had a web-server in-kernel. 

This is just plain nuts. There are IPC primitives offered by the system, some of them are standardized by POSIX. *These* should perform as well as possible. (I remember L4, the microkernel designed at University of Karlsruhe, took this to an extreme, optimizing IPC with custom x86 assembler code, even with special-case paths using CPU registers where possible, etc..). Higher level protocols should _never_ make it into the kernel. Why? Security and stability. Code should never be executed with privileges it doesn't really require. Ok, sure, there's room for compromise. Your classic "monolithic" kernel will probably implement things like IP, TCP, filesystems, etc, and the reason will be performance. But you have to draw a line _somewhere_. To me, this line must be drawn at anything that's clearly "application layer". And I'd say a message bus system designed for desktop needs clearly fits there.


----------



## hardworkingnewbie (Mar 19, 2022)

msplsh said:


> Apparently the Linux people have redone DBus _twice_: Once for SystemD in userspace in 2013 (which apparently works quite well) and once for dbus-broker in kernelspace in 2017 (Fedora uses this as of 2019 and also seems to work well).  Linux has more users than FreeBSD, so if they solved their junky DBus problem with a Linux-only solution, then they have mostly extracted themselves from the problem and have taken the manpower to solve issues in libdbus that would affect FreeBSD with them.  This explains why libdbus remains junk: The problem was solved in a place FreeBSD can not go.


For god's sake, please check your so called "facts" before making such false statements.

SystemD is *not *providing Dbus services, it _uses _them. Dbus-broker runs in *userland*, not _kernelspace_!

There was once made an effort by the systemd guys called kdbus to integrate dbus into kernel space. When it was handed over for integration, Linus Torvalds ran a profiler on userland dbus and came to the conclusion that it was just a piece of badly written, slow garbage - to quote him "pure shit user space code". And instead of creating a kernel component in the hope to make dbus quicker, they should instead improve userland dbus because that's not what a kernel is there for. Just performing quicker if it could be also done in user spaceis not reason enough to accept something into the kernel. To quote again: "We don't merge kernel code just because user space was written by a retarded monkey on crack."

So dbus-broker is the result of kdbus not being merged into the Linux kernel: a new userland implementation of dbus, which is being optimized for speed and should overcome the problems of the old implementation. Furthermore dbus-broker does use extensively kernel features which are only available under Linux right now. Since its authors are coming from the systemd crew, they don't care much about portability.


----------



## zirias@ (Mar 19, 2022)

hardworkingnewbie said:


> When it was handed over for integration, Linus Torvalds ran a profiler on userland dbus and came to the conclusion that it was just a piece of badly written, slow garbage - to quote him "pure shit user space code". And instead of creating a kernel component in the hope to make dbus quicker, they should instead improve userland dbus because that's not what a kernel is there for.


Oh thanks. It renders my previous response kind of pointless. But it's good to hear there's some sanity left in Linux world. Takeaway: mistrusting Linux shouldn't go with trusting any posting on FreeBSD forums


----------



## A. D. Sharpe Sr. (Mar 19, 2022)

Zirias said:


> Disclaimer: I still didn't look into dbus implementation, but it's installed on some of my systems as a dependency and so far, it "just worked". So sure, there might be quality issues and I was just lucky so far not to run into them.
> 
> 
> I really really think this is the wrong way to go. I've seen this reflex (let's put stuff in the kernel -- yep, addressing the post you quoted here) far too often. A main driver seems to be "performance". A long time ago, Linux had a web-server in-kernel.
> ...


I think you have misunderstood my meaning. My point is that our port should be scrapped & a native DBUS implementation should be written -NOT that DBUS should be in the kernel. I DO agree with an earlier comment that the System V STREAMS & the Solaris IPC implementations should be seriously considered for being added to the kernel (and maybe a BSD-specific implementation of DBUS could be built on top of them). But there is no way that DBUS should be done in the kernel.


----------



## A. D. Sharpe Sr. (Mar 19, 2022)

hardworkingnewbie said:


> For god's sake, please check your so called "facts" before making such false statements.
> 
> SystemD is *not *providing Dbus services, it _uses _them. Dbus-broker runs in *userland*, not _kernelspace_!
> 
> ...


This pretty much confirms my understanding that we need to write an implementation of DBUS that does for us what dbus-broker does for Linux.


----------



## ralphbsz (Mar 19, 2022)

A. D. Sharpe Sr. said:


> I DO agree with an earlier comment that the System V STREAMS & the Solaris IPC implementations should be seriously considered for being added to the kernel (and maybe a BSD-specific implementation of DBUS could be built on top of them).


Perhaps. But only if we identify a good use for them. And only if manpower for it can be found, without disrupting more urgent problems.

As a general rule, a lot of functionality that 20 years ago was put into kernels is moving into userspace today. Why? Because it's faster: user/kernel transitions are expensive, and the bulk of the code runs in userspace anyway. That includes locking, RDMA, zerocopy networking, and storage IO. So before FreeBSD seriously commits to adding queuing mechanisms to the kernel, it should consider alternatives.


----------



## A. D. Sharpe Sr. (Mar 19, 2022)

ralphbsz said:


> Perhaps. But only if we identify a good use for them. And only if manpower for it can be found, without disrupting more urgent problems.
> 
> As a general rule, a lot of functionality that 20 years ago was put into kernels is moving into userspace today. Why? Because it's faster: user/kernel transitions are expensive, and the bulk of the code runs in userspace anyway. That includes locking, RDMA, zerocopy networking, and storage IO. So before FreeBSD seriously commits to adding queuing mechanisms to the kernel, it should consider alternatives.


Even in microkernels (where most things are pushed into userspace), IPC is typically a part of the kernel itself.


----------



## msplsh (Mar 20, 2022)

hardworkingnewbie said:


> For god's sake, please check your so called "facts" before making such false statements.


I apologize for mortifyingly offending you by making an error while making a point that didn't depend on it.


----------



## shkhln (Mar 20, 2022)

A. D. Sharpe Sr. said:


> a native DBUS implementation should be written


Here you go: devel/dbus.


----------



## Vull (Mar 20, 2022)

A. D. Sharpe Sr. said:


> This pretty much confirms my understanding that we need to write an implementation of DBUS that does for us what dbus-broker does for Linux.


How soon can you start?


----------



## zirias@ (Mar 21, 2022)

A. D. Sharpe Sr. said:


> I think you have misunderstood my meaning. My point is that our port should be scrapped & a native DBUS implementation should be written -NOT that DBUS should be in the kernel.


As I said, regarding putting stuff into the kernel, I was referring to the post you quoted. But maybe I didn't make one point clear enough: If in-kernel is off the table (and thankfully everyone seems to agree on that), what's the point of having a custom implementation? Something like d-bus can be implemented portably, just needing POSIX IPC mechanisms. If there are issues with the current code, they should be fixed, but not in a FreeBSD-specific solution.


----------



## msplsh (Mar 21, 2022)

Zirias said:


> If there are issues with the current code, they should be fixed, but not in a FreeBSD-specific solution.


Nobody is doing it because it's not a problem for the majority of users because they use a different implementation.


----------



## ct85711 (Mar 21, 2022)

The fun part is, there's been several write ups on what can be done that can be done to improve dbus; but they all hit one part.  The project has in it's mind that it can't just change how it is because it would break API/ABI.  The fun part is; half the changes can easily be done without changing the API/ABI; because that only covers the public interface level.  Internally, the API/ABI does not prevent any of the changes.  Second, there is already a agreed convention when you intend to break API/ABI (AKA change the major version).  The other part is also commonly used, is depreciating methods/functions and slow shift everything over.  While that isn't in the C/C++ language directly, there are numerous workarounds to document that.


----------



## Jose (Mar 21, 2022)

ct85711 said:


> The fun part is, there's been several write ups on what can be done that can be done to improve dbus; but they all hit one part.  The project has in it's mind that it can't just change how it is because it would break API/ABI.  The fun part is; half the changes can easily be done without changing the API/ABI; because that only covers the public interface level.  Internally, the API/ABI does not prevent any of the changes.  Second, there is already a agreed convention when you intend to break API/ABI (AKA change the major version).  The other part is also commonly used, is depreciating methods/functions and slow shift everything over.  While that isn't in the C/C++ language directly, there are numerous workarounds to document that.


The problem is, the API is crap too. It's based on defining interfaces using XML files:


			D-Bus API Design Guidelines
		


Mercifully the XML hype has dissipated and no one uses it in anger anymore*. XML turned out to be hard for both computers and humans to use, and brought along some lovely security fails too. You would have to come up with an  equivalent interface definition scheme and convince GNOME, KDE, etc., to use it.

Furthermore, D-Bus specifies a complex wire message format:


			D-Bus Specification
		


This sort of approach unnecessarily constrains the types of payloads you can send over the bus. Kafka brokers, for example, work with opaque arrays of bytes:





						Apache Kafka
					

Apache Kafka: A Distributed Streaming Platform.




					kafka.apache.org
				




This frees you to use whatever message format works for you. Marshaling and unmarshaling arbitrary payloads is a problem that has been solved and solved well multiple times at this point:





						Apache Avro
					






					avro.apache.org
				











						Protocol Buffers  |  Google Developers
					

Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data.




					developers.google.com
				





			https://msgpack.org/index.html
		









						GitHub - capnproto/capnproto: Cap'n Proto serialization/RPC system - core tools and C++ library
					

Cap'n Proto serialization/RPC system - core tools and C++ library - GitHub - capnproto/capnproto: Cap'n Proto serialization/RPC system - core tools and C++ library




					github.com
				




Lastly, this approach of having a single daemon do multiple things shows why the Unix philosophy is so wise. It would be better have a separate IPC protocol, message broker, and serialization format. The last one is a solved problem, as I've pointed out above. For the message broker, I'd leverage Fifolog to write something similar to Kafka. I have no ideas for the GUI IPC interface specification. I'm not a front-end type. I just don't know the space well enough to not embarrass myself.

* XMPP is a notable exception. They use XML to great effect.


----------



## drhowarddrfine (Mar 21, 2022)

I never had any issues with XML. Interestingly, so many web frameworks and languages use XML without calling it XML now. React, Angular, etc.


----------



## ct85711 (Mar 21, 2022)

The API being crap or not isn't the point (and I agree the API needs to be replaced); the point is that you can not hide behind it because you don't want to acknowledge the issues and/or that it is "too hard".  Programming as a whole is a ever evolving process, so trying to hide your head in the dirt doesn't stop the process.


----------



## grahamperrin@ (May 28, 2022)

chessguy64 said:


> … I noticed some failed calls to dbus as well, that could have been a factor as well. Not sure how well dbus works with FreeBSD.



As far as I know, it works well enough.

I'm too lazy to re-digest any part of this topic  but a recent comment in IRC <https://matrix.to/#/!KYWCpFvqYdeGYJ...Ow?via=libera.chat&via=matrix.org&via=kde.org> was helpful:



> Graham Perrin: we don't have any network-manager compatibly dbus interfaces



– that was, in response to a commit that mentioned _Plasma Networkmanager_:









						KDE: Update to KDE Plasma 5.23.3, Bugfix Release for November · freebsd/freebsd-ports@47122d5
					

Tuesday, 9 November 2021. Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.23.3.  Plasma 5.23 was released in October 2021 with many feature refinements and new modules to complete t...




					github.com
				




(I guess, the three bullet points were copied from <https://kde.org/announcements/plasma/5/5.23.3/#main>.)


----------



## Crivens (May 28, 2022)

I am working with dbus at $DAYJOB, and FreeBSD seems to be faster than linux for some workloads. It has it's place.


----------



## Jose (May 28, 2022)

I read somewhere about the Linux-only replacement for Dbus, complete with a hard Systemd dependency, but I can't find it now. I did find this, though:


			FGA: The Desktop Bus Death Rattle


----------



## jbo (May 28, 2022)

Jose said:


> I read somewhere about the Linux-only replacement for Dbus, complete with a hard Systemd dependency, but I can't find it


Sounds like Linux is trying hard to combine the worst aspects of Windows and the worst aspects of MacOS into one system


----------

