The systemd fallacy

And this is the problem. You're guilty of the very thing you're accusing the author of.

Some of those shell scripts are very simple and can be easily replaced with a configuration type file. Most are not. They do a ton of stuff, like create lock files, pid files, check for dependencies, check for existing processes, etc etc and couldn't be properly replaced by a configuration block.

Using shell script gives you unbelievable flexibility in how you start a daemon that can never be replaced by a configuration script.

So what happens? All that complex stuff stays in that script you can't understand and now you've added an additional layer of complexity that wasn't necessary.

Every additional layer adds a point of failure and in my humble opinion, isn't worth the additional user-friendliness.

There's no need to start your article by being a douchebag. You could just make your point.

Also, I don't think you really got it right here. His point is that lots of functionality has moved from shell scripts to C. Yes, you have an ini-style configuration file. That's not the same as a shell script.

postfix took the simple-flat-config-file model whereas exim provides a much richer language. Some years ago I attempted to do something slightly odd for SQL auth in both, and found that postfix only let me use SASL, and SASL didn't have a driver for what I wanted, and therefore in order to make it do what I wanted I needed to write a C-based SASL driver to execute the SQL I wanted. In exim it was 3 or 4 lines of config.

Similarly, if I hit something systemd can't do I now have to write C to add a config file, rather than write a couple of lines of shell.

that is what the author means.

I could certainly see an advantage to providing an ini-based approach as well for people who regard current LSB conmpliant init scripts as "shell scripts that made no sense to me" - and for people like me who -do- love them, but would be quite happy with a simple way to configure simple things.

But please don't try and take that power away from me when I need it.

I don't know why the author made the bizarre suggestion that anybody would start tinkering with the source of systemd itself in order to configure services, and it would be impolite to speculate. Suffice to say that nobody does this.

Certainly you can take advantage of more systemd features by modifying the source of the service to explicitly support them; however, this is not something users/sysadmins should ever need to do themselves.

Note that old-style SysV init scripts weren't really editable in most cases. They were supposed to stick to a rigid set of standards (which they often didn't, causing lots of bugs), and edits made to them might be silently reverted during an upgrade. For this reason, most distros recommend /etc/sysconfig/* files for persistent configuration of init scripts, which systemd also uses (or editing the textual foo.service file).

Two minutes of downtime per server is also irrelevant to its two month uptime, especially when you have clusters of servers so your service doesn't experience downtime at all.