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