The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:44 UTC (Sat) by dlang (guest, #313)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by anselm
Parent article: The Grumpy Editor's guide to surviving the systemd debate

actually, what you dismiss as a whole pile of shell scripts doing almost the same thing is actually frequently a small amount of boilerplate that is calling the helper functions (as scripts or binaries) that provide exactly the type of extensions that you are saying need to be added

to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 5:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Except that helper functions are not really helpful at all. They don't do namespacing, SELinux or even bad old chrooting. They barely provide PID file tracking, and even that without daemon readiness protocol or anything like this.

And if you do try to add them, then scripts become even more incomprehensible. Witness, the Gentoo's BIND initscript as an example: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/n...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 19:04 UTC (Sat) by anselm (subscriber, #2796) [Link] (4 responses)

Possibly. On my Debian system, many of the shell scripts in question still are more than 100 lines long (sometimes considerably so), still contain mostly boilerplate, and still don't do various things one would reasonably wish to be done when a service is started. There are ways of reducing the amount of repetition but they do not appear to have caught on in most mainstream Linux distributions. I for one am looking forward to these scripts being replaced by systemd unit files that for the most part will fit on one screen.

Then there is the fact that these shell scripts are impossible to change and adapt to local preferences without running the risk of having to do it over and over again whenever the distribution issues an updated version, or having to prevent the distribution from installing and activating its version of the script in addition to the one the local administrator provided under a different name. Systemd solves this in a much more elegant manner by cleanly separating the distribution-provided default from any local changes.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 16, 2014 21:39 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

There's also the general point that writing configuration files as programs in a Turing-complete programming language is a gross violation of separation of policy from mechanism. I would probably lump it in with things that count as design anti-patterns.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 1:46 UTC (Mon) by neilbrown (subscriber, #359) [Link] (2 responses)

> There's also the general point that writing configuration files as programs in a Turing-complete programming language is a gross violation of separation of policy from mechanism.

Is it?
What if your policy is algorithmic in nature, or is more complex than the designers of the config file imagined?

TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.
Are they all gross violations? (I almost added PHP to the list, but that might hurt my argument....)

If your configuration language supports substitution or conditionals - or maybe even just sequencing - then you probably want to start looking at a real language, because iteration probably isn't far away.

The line between "policy" and "implementation" is very real, but it is in your mind, not in the computer. And that is where it should be enforced.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.
Are they all gross violations?

Further, at least two of these (Lua and Tcl) explicitly started as ways to write, well, Turing-complete configuration files: configury and program in the same language. Javascript didn't, but then it grew JSON, which is, well, exactly the same thing.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 2:40 UTC (Tue) by zlynx (guest, #2285) [Link]

Sort of. But serious users of JSON never stick it into a string and eval(). That way lies nightmares and security holes.

In best practice JSON is non-executable.