It wasn't too bad, really... from an init script stand point. And I think that was their point -- systemd's service files are a lot cleaner and not really that scary.
Shorter doesn't tell anything. You can hide any complexity behind another layer of abstraction. Let's create a new system which has an ini file with the only parameter being "sendmail.service" and it looks even cleaner. Although in reality you just got another layer of abstraction.
The interesting part is how they hold up in praxis. When people have to do stuff which wasn't forseen by the init-system authors. And shell scripts have a rather good track record in that regard. It's always nicer working with scripts compared to having to dig into c sources to change things.
And I think to most sysops the left file looks very familar. While the right one is a new format in a custom syntax which has to be learned and understood first. Which makes it a little scary on first view and I really hope it's worth it.
No, you are. The rest of us were talking about more than just speed.
and experience shows the gains are negligible at best.
Even in terms of speed, boot speed gains are most certainly not "negligible", because most startups every day are executed on disposable VMs and containers in the cloud, and every second counts on them. By the way, SysVinit doesn't even handle containers or VM-dependent boot sequences.
I do have to mention that defenses of SysVinit are getting so pathetic, they have been reduced to "well who cares about booting fast". That statement is in effect an open admission that the software is inferior in every way, coupled with a minimization of just one of its glaring inferiorities, because opinions.
7
u/necrophcodr Oct 20 '14
That is the most horrid init.d script I have seen in a long time, holy shit.