On 2020-01-02 at 09:03, Sam Hartman wrote: > My understanding is that systemd's implementation of tmpfiles and > sysusers works even while systemd is not pid 1. Why do we need > multiple implementations for Debian ports where systemd runs?
There are those who don't run systemd-the-daemon even as non-PID-1; I'm one of them. In my case, this is partly due to half-remembered negative-impression behavior changes seen from even non-PID-1 systemd, back when I experimented with it around the time of the default transition - but I can't remember those changes clearly enough to specify, and it's possible that even if they did exist back then they might no longer be present today. (For what it's worth, my recollection is that they were related to logind.) But it's also partly due to a philosophical objection to the way systemd implements so many things all in more-or-less one place, and to distrust that systemd-the-daemon (and/or the package) won't later grow behaviors which I find undesirable, but which are enabled by virtue of having systemd-the-daemon running at all. I don't go so far as to prohibit even libsystemd0 (never mind udev) from being installed, although I understand that some people do - but I simply do not trust systemd-the-project not to bring undesirable changes, and consequently I want to have as little running systemd code on my system as I can reasonably get away with. If it were possible to install and make use of systemd-the-suite's implementations of tmpfiles and sysusers without needing to pull in systemd-the-daemon - or, perhaps even more importantly, the *ten* other apparent daemons which I see in a quick look at systemd-the-package - I might well be OK with that. But from my understanding, it is not, and certainly they are not packaged separately in Debian. If there were no sufficient separate / independent / standalone implementations of tmpfiles or sysusers, and packages which I can't do without grew dependencies on those facilities, I'd probably (at least temporarily) grit my teeth and bear with having to have systemd-the-package and its daemons installed and active - and who knows, maybe I'd even discover that the undesirable behaviors I half-remember don't exist anymore. But as there apparently *are* such implementations, I would greatly prefer to have the option to make use of them instead. A refusal to permit these alternate implementations to be available as alternatives, for reasons other than technical limitations of one sort or another, would seem to me like an attempt to shove systemd down my throat - and would be that much more reason for me to finally give up on Debian and try alternatives, whether Devuan or Gentoo or something farther afield. In that context, I find the entire premise of "why do we need multiple implementations of this?" to be unfortunate; "need" is, IMO, the wrong standard to use for this. -- The Wanderer (who will, as usual, probably regret posting this) The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
