Skip to content

Comment on What's wrong with systemdparent

Comments

Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use.

Come come, no need to pretend to be dense on this topic. Address the argument, rather than engage in rhetorical bluster.

You know, and I know, and everyone knows because it's public knowledge, that systemd is an incredibly tightly bound bundle of highly opinionated tooling, regardless of how many process IDs it uses. You know, and I know, and everyone knows because the maintainers say so[1], that no piece of systemd can be replaced, and indeed they further astonishingly assert that certain bits of systemd logic literally cannot be reimplemented by anyone else or removed.[1]

You know, and I know, that systemd is attempting to gain creeping control over an ever-growing pool of functionality normally handled by logically separated tools, frequently without regard to merit (e.g., stashing core dumps in a binary log; the 'debug flag' debacle[2]).

So if we know all of these things, then why do you pretend otherwise, and unleash vitriolic insults against people based on your straw-man specious reasoning? And if you can answer that, can you then tell me, why is this not just standard practice amongst the systemd advocates, but rhetorically uniform therein?

[1] https://plus.google.com/+LennartPoetteringTheOneAndOnly/post... [2] https://lkml.org/lkml/2014/4/2/420

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.