Quoting Simon Walter (simon@???):

> On 07/27/2016 01:56 AM, Rick Moen wrote:
> >Quoting Go Linux (golinux@???):
> >
> >>This is a must read on the politics and votes that ensured a systemd future for debian:
> >>http://forums.debian.net/viewtopic.php?f=20&t=120652
> >
> >To my astonishment and pleasure, I found this well argued, reasonable,
> >and a good effort to cast light on a complicated subject. Thanks.
>
> Yes, thank you for this. It's the kind of thread I wanted to look over.

There are places he plays a bit loose, but they're a very forgiveable
form of rhetorical excess. E.g.:

If someone characterizes systemd as an “init system,” you may safely
assume that s/he is either utterly clueless or deliberately obfuscating
the discussion.

Well, no. If someone characterises the thing as _only_ an init system,
that would be true. It's a suite (to use a polite term) that does
include an init system, but also a great many other things. In fact,
one of the subtleties that sometimes interfered with past discussions of
the damned thing is failure to recognise that implementations differed.
For example, Poettering at one point introduced a local DNS daemon[1]
implementation called systemd-resolved.service, and immediately (and
predictably) screwed it up hilariously by introducing a major cache
poisoning security vulnerability.
http://seclists.org/oss-sec/2014/q4/592

Coding your own caching DNS stub resolver when you can instead use
a real recursive server written by competent people like Unbound, or at
least Dnsmasq (small caching forwarder server w/o recursive service,
plus local authoritative names) is really stupid.

_But_, the point is, distros weren't including systemd-resolved,
choosing to omit it. And, if one had, that wouldn't imply that all
chose to. Numerous of the suite's modules can be packaged or not, and
enabled or not. E.g., as I pointed out in the mailing list post that
begins my OpenRC conversion page, Debian Project's package in Debian 8
does _not_, as commonly charged, hand off logging information to
systemd-journald. Instead, it logs to rsyslog, as per tradition.

What systemd is is an effort to re-create large portions of existing
userspace (including login, job scheduling, and networking, just to name
a few) inside a single process traditionally reserved for the sole
purpose of starting *nix userspace.

IIRC, not inside the _single process_ but rather in a forked-off forest
of other processes.

Author 'dasein' (who I would guess to be Lukaso Dasein[1]) also said:
'There was never a systemd debate [...]' and 'The GR was not a mandate
for systemd [...]'.

These sections are spot-on, and that was also part of what I was trying to
get at. There not only was no debate and no mandate, but also no actual
policy decision or plan -- just a bunch of bumbling stepwise
occurrences with no plan or policy worth mentioning. It actually would
be slightly reassuring if there _had_ been a conspiracy, but no. As
usual, it was just a bunch of people looking only to their own immediate
agendas, bureaucracy acting on inertia, and people turning away from
issues in pique and saying 'Go away.'



[1] Docs say 'caching DNS stub resolver and LLMNR resolver and
responder'. LLMNR is a cruddy little mostly-Windows protocol, and
Poettering loves those, which is why he also did ZeroConf. LLMNR is a
kludge to permit local hosts with no DNS presence to have names known to
each other by transmitting NetBIOS names over IPv4, which Microsoft's
NetBT implementation already did, but extends that to work on IPv6.

[2] https://diasp.org/u/lukaso666 Now, _there_ is attitude-projection
worthy of respect. The gentleman appears to live somewhere around Kraków.