You do not have to use all resources that are under the systemd umbrella. That's just BS, sorry. And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts? Guys, pick your fights reasonably.
Agreed. But you still need to know what to enable/disable, so more complexity is the outcome. > And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts? Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code. > Guys, pick your fights reasonably. I don't see what is not reasonable here a…
There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.
And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.
So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.
OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.