you are viewing a single comment's thread.

view the rest of the comments →

[–]solder0 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (1 child)

Kinda seems to me like most of the issues with systemd are social, rather than technical.

[–]bopomofodojo 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

Yes, they are. They always boil down to three things:

  1. I don't like Lennart Poetering, and thus systemd bad - this is a tradition at this point since the same thing happened with Bonjour and PulseAudio before everyone got with the program. For some reason, though, systemd's hate was stronger and has lasted far longer, I guess because it's his 3rd major "I'm going to make something that actually improves the Linux ecosystem" project and it's the most... integrated, I guess for lack of a better word.

  2. "Something something Unix philosophy" just fucking stop. If you're running your Linux system on a PDP-11 in 1975, sure, talk about this magical "UNIX Philosophy". However, in the real world of 2021, any software worth a damn in the last 20+ years hasn't "followed" it either, including the kernel of the operating system Systemd runs on. Computing has evolved, and no one talked about this when GIMP was big and complex ("You can do everything GIMP does with imagemagick and pipes!" Yea Kyle, if I want to spend 20 years writing scripts to do it, but I have better things to do), or any one of thousands of other programs that have evolved far past the archaic notion of tiny programs and pipes. This philosophy is still useful for some things, but it is not for system management. Shell scripts doing service management is fucking terrible, always has been, and the kludges needed for it to work barely do so. Systemd is better in every way precisely because it says "No this is a task that a full blown program should do so it can keep proper state and track running daemons, input/output, etc.". Most of these masquerade as "technical arguments", but they ultimately circle back to this philosophical decision about what software "should be".

  3. Various things that always boil down to "I don't understand how systemd works/is developed/was designed/how to use it, and therefore it's bad". Stuff like "it's bloated" (no, it's not, it's a tiny program if you turn off all the features at compile time - but most distro maintainers find these features useful and thus turn them on), "it's all one source tree" (so is FreeBSD but no one calls that "bad" for it), "My server X blocks boot or crashes or" read the damn manual and learn how to configure it so it doesn't do that thing. Like #2, most of these also masquerade as "technical arguments", but are ultimately simply a case of not understanding how the software actually works, refusing to learn new things, and then becoming upset that Systemd doesn't work they way they "think" it should (usually, the way SysV and it's myriad of cludges worked), usually because it's solving a problem and took an alternate design path that, when understood, makes perfect sense.