Le 03/03/2020 à 23:37, tekHedd a écrit :
On Tue, Feb 25, 2020, at 3:28 AM, Didier Kryn wrote:
Le 25/02/2020 à 09:05, Steve Litt a écrit :
On Mon, 24 Feb 2020 12:21:16 +0000
Daniel Abrecht via Dng <dng@lists.dyne.org> wrote:
...
Without dbus, applications & daemons could do similar things using
unix sockets. ...
Yep, socket, signals, fifos, inotify, netlink, semaphores,
shared-memory, what else?
It's probably possible to build some well thought middleware with
these, but Dbus isn't that one.
^^ This has been in the back of my mind for some time. In the last few years,
we have been inspired to collect a fairly complete set of requirements for what
polkit, dbus (and init :) need to do, and what they don't. In great detail.
Requirements are great, because once you have them you can do a much better job
of designing software.
Surely it is time to boil down the dbus/polkit requirements and and start over.
Preferably with sane limitations on scope and configuration mechanisms. I mean,
I'm just thinking out loud here something that I've been thinking for about 6
months.
As it stands now, these systems can serve as a good proof of concept from which
to harvest requirements. This is not a *fun* project. Speaking as a programmer,
sysadm, and end user, I would gladly never touch dbus again, and I've gone out
of my way to avoid using or installing it since my initial contact and my life
has been better for it. But I mean, basic publish-subscribe message
functionality doesn't /have/ to be a nightmare does it? Surely this was not a
requirement? :) Polkit doesn't /have/ to be a total pain to configure? Surely
ease of configuration should have been a top-level requirement for polkit, and
a clean programming api and sensible message naming should have been first-pass
requirements for dbus?
Except that making it a nightmare may be a requirement for people
who make their buisness out of complexity, as Steve already explained
several times (~:
Re this thread, clearly a multi-user system with a GUI does need polkit and /some/ sort
of dbus mechanism (which I will henceforth refer to as the "dbus mechanism" as
if it were some sort of doomsday device). But it doesn't have to be polkit as currently
shipping. And clearly The DBus Mechanism just needs a do-over. Both of these things can
be very useful even if done badly, as demonstrated by their current incarnation.
I'm not sure Polkit is necessary. In practice the multi-user
concept applies to servers while Dbus, Polkit and the like belong to
Freedesktop and are forced in by dependencies only when it come to
installing DE's, that is mostly on single user machines. But I admit
such a tool is usefull, provided it is KISS.
So, I would consider rewriting polkit and dbus from scratch.
Also, who has time to rewrite polkit and dbus from scratch?
* polkit might be salvageable?
Plokit would have to provide some benefit with respect to sudo,
because its functionning and configuration are far more complicated.
* dbus probably not salvageable, also deeply integrated into every possible
program; consider dbus compatibility shim D:
By definition, a shim preserves the API, and I consider the problem
of Dbus is precisely its API.
Just thinking aloud. Also, hi.
You're not the only one on this list (~:
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
