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 at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.
I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...
There's only the optionality because of the pushback though.
One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.