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?

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.

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?
* dbus probably not salvageable, also deeply integrated into every possible program; consider dbus compatibility shim D:

Sounds like a medium-sized project. Ideally should be done by someone with a big ego and no coding skills, rolling it all in C++ as one huge binary and integrating it into systemd. No, wait, that was sarcasm. But seriously, it shouldn't be as difficult of a problem to solve, other than the problem of inertia keeping the existing hacks in place and the problem of raw development effort. But these are core system processes and important. If it were my OS I'd be working on replacing these things as a priority because they're core.

Just thinking aloud. Also, hi.
DD