>No newbie sysadmin should touch init scripts because they can't handle it.

There's a lot of things newbie sysadmins are going to be bad at. I wouldn't expect them to come in and architect an infrastructure that will be handling millions of events per second, either. Nor would I expect them to be able to perform a deep dive and become performance engineers.

But sysvinit doesn't have to be the answer. I'm an Illumos guy. The SMF implementation is excellent, moves away from init scripts, and still doesn't throw the baby out with the bathwater like systemd does.

If I was interested in giving up control for the sake of reducing complexity, I'd go back to being a Windows sysadmin so I can click next on wizards and run dcpromo all day.

Without taking a position on the larger issue, with init scripts, another sysadmin could always figure out what the junior sysadmin did.

Jr: "I edited some init file."

Sr: "Which one?"

Jr: "I forget."

Sr: "Oh." sorts /etc directory by time "Oh, I see what you changed. That is wrong because of $REASON. You should do $CORRECT_THING instead."

Jr: "Okay, thanks for letting me know."

Sr: "We were all new guys once."

You can do that with systemd too -- service files are still just ordinary files; they're just "10 lines of info that matters" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate" :P

More like "10 lines of info that matters + I don't know/no reason to look at that" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate"

Saying that systemd service files are complicated because you need to take systemd's internals into account is like saying sysv init scripts are complicated because you need to look at the source code to "cat" and "grep"; ie, no :P