Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion?
I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article.
But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things.
There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD.
The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful.
But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.
Those don't cover the technical aspects, although to be fair, something like 70-90% of the systemd "debate" is about non-technical issues, like "the Unix philosophy" or "change for change's sake"--just read the comments here!
Well no, I've never written a central architectural critique of systemd, only scattered criticisms across comments. I will nonetheless be remedying that soon.
Indeed, that bug report is an interesting example. I can see both sides failing.
1. It was not a good bug report. 'Do not parse "debug" command line parameter' is not a bug. The actual bug is "assertion in systemd-journald" which is a clear regression, but independent of kernel parameters. According to comments 17 and 22, it was promptly fixed.
2. According to projects process, discussions about design are to be done on the mailinglist and not in the bug tracker. Most commenters violate this.
3. No systemd dev explained why they parse the debug parameter.
4. Sievers closed the bug report without explicitly acknowledging the assertion problem.
5. The kernel devs (especially Linus) are too hot headed and misread this. Systemd caused and fixed (!) the assertion problem.
You're quoting a troll as reference for "anyone with a clue". Further, you're referencing that the systemd Debian maintainer quit on the harassment in the systemd discussion because he wanted systemd _in Debian_.
Linus called out on some behaviour. That is not him saying that people should stop developing. It's him saying stop this behaviour.
As shown in the LKML and Debian debates, the systemd infestation
was firmly opposed by nearly everyone outside the 'vested interest'
RedHat filter bubble. And still is.
Some high profile names would be Eric S. Raymond
or Patrick Volkerding (creator of Slackware).
http://ewontfix.com/14/ is one of the classic posts here, but it deserves a good rebuttal, not the straw-man one included. (The starting point I'd make is, if init were really as simple as purported, why isn't it built-in to the kernel? Why not simply skip all the kernel code to reparent children to init, and have children die immediately instead of becoming zombies if their parent has exited? Why not remove all the code to panic if pid 1 dies, and make it just a process like any other?)
There is stunningly little content in that link. There's a lot of broad points absolutely devoid of serious examples of how they are problems under systemd.
You can't just go "attack surface" and have said anything useful, nor can you point at volume of code if that code is actually needed. All criticisms of systemd usually depend on people completely ignoring the very serious problems you can't solve with sysvinit and which do make actual, practical systems less secure (i.e. cgroup process isolation is amazing, and a lack of real service management is a huge problem and any service management is going to be running as root period. Yet there's been a real claim that service management is "what your sysadmin does". Why even bother with computing then?)
That's really a shame. Systemd is almost comically bad.