> simple, clear and very understandable init.d scripts

At best, init scripts are 5 lines of actual functionality and 100 lines of boilerplate, and in my experience very few init scripts are at their best. With systemd, the config file contains the 5 lines that actually matter and nothing else. I'd consider the latter to be much more simple, clear, and understandable.

First example where a project maintains both - a particularly verbose service file, compared to an average init file; compare not just line counts, but complexity (variable-filled function calls, branching logic, etc, vs a set of key=value pairs)

https://github.com/varnish/Varnish-Cache/blob/master/redhat/...

https://github.com/varnish/Varnish-Cache/blob/master/redhat/...

Boilerplate of extremely varying quality, no less. A bad init.d script can ruin a whole day, and in my experience most packages not included in a base system are ticking timebombs to a problem.

I wouldn't describe them as simple at all. What init.d/rc.d scripts amount to is pushing all the pid0 init work out to every individual service and making them figure it out on their own.

Great example, another metric I like to use is to look at the history, to see how many times the file has been patched

Characterising the 16000+ LOC of shell in a Debian 7 init.d directory as simple and clear seems like describing sendmail configuration as easy.

Sendmail.. Eww.. Whenever one gets the idea of using a macro language to process the configuration files because writing the "raw" configuration format is too difficult, one should sit down and rethink things.

Those init.d scripts are different per distribution. With systemd the same thing is provided in a configuration file. Much simpler, clearer and understandable. Further, "service $FOO status" actually shows you stderr+stdout output, making it easy to debug (in case of failure).

Systemd lets you still use init.d scripts to run services. It works better with services that use .service files, but it still supports the old ones.