Why do we need d-bus?

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.
 
[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
 
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. :p
 
kpedersen : I am a Wayland user on FreeBSD... full-time at that. I use Plasma-Wayland. :p
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).
 
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.
 
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?
 
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).
 
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.

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...
 
It's a requirement because you are NOT the one implementing the software that uses it.
Why is who implements it important?
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.
 
...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:
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.
 
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'.
 
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.

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

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.
 
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?
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.
 
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.
 
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...
 
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…
 
Named pipes are not "modern" and Windows having them does not make them modern.
They seem to be supported on "modern" Windows:
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"?
"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?
 
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?
 
Back
Top