On 12/12/2014 2:35 AM, berenger.mo...@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
changed.
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...
http://en.wikipedia.org/wiki/D-Bus
https://techbase.kde.org/Development/Tutorials/D-Bus/Introduction
Not sure what to make of kdbus at this point...
http://lwn.net/Articles/619068/
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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548bfd8c.5050...@comcast.net
