Quoting Simon Walter (si...@gikaku.com): > On 07/27/2016 01:56 AM, Rick Moen wrote: > >Quoting Go Linux (goli...@yahoo.com): > > > >>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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
