Comment Re:You'll end up with an empty repository (Score 1) 151
Claimed by whom?
The people at Debian who chose to adopt systemd with less than the usual amount of debate, and at other distributions as well. I thought you participated in these discussions at the time? Guess not.
sysvinit has been responsible for a number of unbootable environments over the years personally speaking, while I've always been able to log into a systemd system
sysvinit has never stopped me from booting, but systemd has. In fact I got into a situation where in order to troubleshoot booting, I would have had to use a debugger. That's when I noped out forever.
Pick something. Just not sysvinit. The latter hasn't been appropriate since the 1990s, it's ridiculous we continued using it as long as we did.
sysvinit with startpar and the LSB-derived daemon management boilerplate is more than adequate. If you want to use another init system, feel free, but there is absolutely no justification for deprecating sysvinit. You do not need sleep commands, you need to read the headers of some init scripts and see that they contain dependency information, then use dependency chaining to ensure that scripts fire in the correct order. It's really not different from filling out the appropriate fields of a unit file.