> I would disagree that the current scripts are inferior. People in our
> field are far to quick to dismiss the value of simplicity. systemd has
> several more features, I'll certainly admit that. The older / current
> method was great though. You'd think there was other lower hanging fruit
> that required attention.
I don't think systemV init scripts are really simpler. They just push the complexity into other parts of the system.
Since they can't represent dependency information, you either have to have a slow boot time or parallelize things by hand. I have had to manually parallelize sysV scripts before, and it's not fun. The system should know what depends on what.
Since sysV init scripts only happen at boot time, or when someone changes the runlevel, you have to have a separate mechanism to handle the addition of hardware at runtime. Sometimes adding that hardware requires starting a daemon-- for example, when it's bluetooth hardware.
SystemD also subsumes portreserve and xinetd. In theory systemD could also handle restarting daemons, although I don't know if that has been implemented yet.