> Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight:
What about those that can't debug when a shell script breaks?
Your answer is going to be that they have no business administering a server where a shell script is an integral part of the system working.
Conversely, someone that can't debug when a system can't start that uses systemd has no business administering a server where systemd is an integral part of the system working. If your system uses systemd, then you're going to need to learn a new tool. Get used to it.
If they can't debug it, they can find someone who can, and that skillset is, I can guarantee you, going to be far more widely available than Systemd debugging fu.
On which point, specifically: when Debian breaks during initrd execution, the system is dumped to a shell, "dash", a POSIX-compliant shell. It doesn't have all the niceties of bash, but it's usable.
When a Red Hat system breaks during initrd execution, the system shell doesn't handle terminal IO. You literally can't even fucking talk to the damned thing. It's a scripting-only shell.
The kicker: the RHEL initrd shell is larger than dash.
Guess which of these two systems is easier to troubleshoot / debug / rescue in a pinch?
You haven't seen how this epic engineering artifact of wheel reinvention is exploding in your face. See http://lwn.net/Articles/506842/ Now try debug it with rd.debug and you will have debug info printed for debug info printing functions.
> What about those that can't debug when a shell script breaks?
Are they more able to debug when a systemd setup breaks? If not, it seems like a moot point to bring up. They're hosed either way.
Although I do have to say, I like the systemd model. The use of sockets to do process activation and thus doing away with almost all of the need for dependency management is pretty cool. I haven't used it enough to pass judgement, but the concept has the potential to be a good deal simpler than the init hackery we have now.
How is it a moot point? If you are equally unable to debug it either way then dredmorbius' original argument about the failure point being a bad time to learn to debug is completely meaningless. The point is that either way you're going to have to learn how to fix problems before they happen but dredmorbius is complaining because ey just happens to already know how to debug one form.
What about those that can't debug when a shell script breaks?
Your answer is going to be that they have no business administering a server where a shell script is an integral part of the system working.
Conversely, someone that can't debug when a system can't start that uses systemd has no business administering a server where systemd is an integral part of the system working. If your system uses systemd, then you're going to need to learn a new tool. Get used to it.