As someone who designs systems as part of his job, “it violates Linux philosophy” is a perfectly valid reason to hate something as critical and low level as an init system.
I think “hate” is a strong word, mind, but following consistent design patterns and constraining scope matters. The problem is that it’s one of those things that doesn’t tend to matter until shit hits the fan.
The scope creep exponentially raises the efforts needed to properly test, troubleshoot, secure, and just generally work with the project code. The unique design creates rough edges for integrations with other pre-existing systems and tools, while also raising the effort needed for troubleshooting when something goes wrong.
There’s also the whole “Chesterton’s Fence” aspect to a lot of it, where the project runner’s overall attitude has been dismissive of existing conventions and separation of functionality.
There’s a lot of perfectly valid reasons to dislike it. That said, I think full on hate is extreme for an aspect of the overall Linux “system” and “user experience” that most users never interact with. Like having an opinion on the order your BIOS handles things in.
Which part of the “Linux philosophy” does systemd “violate”.
The scope creep exponentially raises the efforts needed to properly test, troubleshoot, secure, and just generally work with the project code.
I keep seeing these words, “scope creep”, in this thread, and I don’t think most people understand what they mean.
The scope of systemd is an init and service manager, and any basic service required for a minimal, coherent system to work. If you think that it goes too far, then we should be talking about the Linux kernel and all the stuff it has that could run on userland and doesn’t, or coreutils, which essentially is the shell equivalent to systemd without the integration.
As someone who designs systems as part of his job, “it violates Linux philosophy” is a perfectly valid reason to hate something as critical and low level as an init system.
I think “hate” is a strong word, mind, but following consistent design patterns and constraining scope matters. The problem is that it’s one of those things that doesn’t tend to matter until shit hits the fan.
The scope creep exponentially raises the efforts needed to properly test, troubleshoot, secure, and just generally work with the project code. The unique design creates rough edges for integrations with other pre-existing systems and tools, while also raising the effort needed for troubleshooting when something goes wrong.
There’s also the whole “Chesterton’s Fence” aspect to a lot of it, where the project runner’s overall attitude has been dismissive of existing conventions and separation of functionality.
There’s a lot of perfectly valid reasons to dislike it. That said, I think full on hate is extreme for an aspect of the overall Linux “system” and “user experience” that most users never interact with. Like having an opinion on the order your BIOS handles things in.
Which part of the “Linux philosophy” does systemd “violate”.
I keep seeing these words, “scope creep”, in this thread, and I don’t think most people understand what they mean.
The scope of systemd is an init and service manager, and any basic service required for a minimal, coherent system to work. If you think that it goes too far, then we should be talking about the Linux kernel and all the stuff it has that could run on userland and doesn’t, or coreutils, which essentially is the shell equivalent to systemd without the integration.
Which could apply to GNOME or KDE given they do more than just desktop environments.
You are allowed to build minimal systemd, which didn’t change that much in many years, no scope creep, consistent, simple.