[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 9p/plumber to replace D-Bus?

On 12/12/2014 2:35 AM, berenger.morel@neutralite.org wrote:

Le 12.12.2014 06:13, seeker5528 a écrit :

Personally I would prefer software X gets a poke in the arm and a
message indicating network status changed, screen orientation changed,
configuration changed here, there was an event in software Y that X is
set to react to, Z is advertising a service X can use, etc.... instead
of software X having to run around to multiple locations and check all
the time or on the odd occasion restart and take inventory of what has

Sometimes looking at what was
https://www.youtube.com/watch?v=j02b8Fuz73A makes it seem like what is
should be a little more.

Later, Seeker

This is a 35min long video. I'll watch it later. For now, I do agree with you that, X11 should not be in the middle of everything. And I think the same for every software, and this is what DBus does.

Probably should have posted a warning about the  length.

I never ran Next OS so didn't have the first hand experience, but seeing the video I thought it was pretty interesting what it was capable of then.

I was running OS/2 Warp back in that time frame which, at least on a superficial level, had some similar concept of publishing capabilities and making those capabilities available to other software on the system.

I did dust off my Warp disks 2 or 3 years ago and got it to install in a VM, but wasn't finding something I needed to make if fully usable. Saw enough though, as great as it was back in the day, it's a little awkward to try to go back to it now.

I was not clear enough when I spoke about the relation between X11 and softwares. In fact, I was only thinking the the actual only useful thing I have seen for now in general IPCs on my system: windows notifying that they need some attention. The window sends the notification, probably (never checked in code) through X11 protocol, X11 resends it to window manager. Ok, X11 is in the middle, but it is something which allows me, who does not use a mainstream DE, to have this feature too, and it is, imho, graphic-related. Now, when I change, say, GTK's theme, I should not have to restard my applications to use it. And it's what dbus allows. But, there are actually many software that do not use dbus which supports such notification system, like daemons. They simply use signals, and on a given signal, they do something. No need for centralized dbus here.

There are multiple arguments depending on what level of things you are looking at and what you are looking to create.

Not being a programmer some of the implementation things get beyond my depth and the when to use when not to use questions.

Skipping some bits.

So, you have to choose between:
_ having a daemon running everytime, and an application which needs to listen at it's socket everytime (I guess it's how dbus works? If someone have any clue about this part of internal, I would be happy to learn), but which have a more flexible way to send messages (not tied to a protocol? I'm not that sure, but I suppose it can at least support non-standard messages), which is something I do not like: if the daemon crash, for a reason or another, or is exposed to a security issue, it's all applications using it which are in danger. Plus, it's not portable. _ having a signal+socket+configuration protocol, which needs to be updated everytime an application is added to the system.

Here are some introductory things...


Not sure what to make of kdbus at this point...


There were some security questions raised and a question about how some situations that could lead to high memory usage in d-bus would be handled by kdbus that I don't know if was ever addressed anywhere.

Note that I only thought about the problem today, the solution I described probably have tons of issues, it have not been since years ;) But, if someday, I wanted to build a DE (why not... a DE for power, keyboard users, which are not only obsessed by aesthetic, but by reliability by having as less as possible SPOF... the problem is that, for something like that, the core of a DE still need to be identified*) where everything can discuss with every other things, I would go that way. Because I do not like SPOFs, and I see dbus as one of them (yes, X11 is another one, in the way interactive software are usually builts, I know, but this one is quite hard to solve because of it's age, unlike dbus which is young --I mean, age is not what makes dbus hard to solve--)

What happens when things fail is always a concern.

Back when KDE and Gnome used different IPC it didn't prevent you from using GTK/Gnome apps in KDE or KDE apps in Gnome, main functions of the programs worked, but some secondary features may not work here or there making them seem a little foreign to the apps that were native to the DE you happened to be running.
I've used different DEs/Windowmanagers at different times, RazorQT is looking good these for a light desktop.

 I settled in in Gnome in it's early days until Gnome 3 was released.
Now I primarily use Unity in Ubuntu and KDE in Debian.

My sources.list points to unstable in Debian and devel in ubuntu. I only know that I've had d-bus issues in Ubuntu and it only stands out in my mind there because some crash information is collected and placed in a file in /var/crash with a name that includes the thing that crashed and something pops up and wants to upload that information as part of a bug report.

Based on that it would seem that any issues I've had that were d-bus related happened a while ago, were fixed quickly or the resulting symptom wasn't noticeable enough or happened too intermittently for me to investigate what was going on.

Later, Seeker

Reply to: