|
|
Log in / Subscribe / Register

The Grumpy Editor's guide to surviving the systemd debate

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:24 UTC (Sat) by anselm (subscriber, #2796)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by neilbrown
Parent article: The Grumpy Editor's guide to surviving the systemd debate

My preferences is generally towards having a simple engine

“Simple” is generally a good idea, but there is such a thing as “too simple”. The sysvinit “engine” is really too simple for what it needs to do, which is why it is not particularly good at what it is doing, so people need to tack on important functionality by way of shell scripts. Note: If your engine uses a hundred shell scripts which are all substantially the same, this might tell you that perhaps some functionality could be usefully added to your engine such that your configuration does not need to be quite that complex. Also for the longest time even the complex configuration of sysvinit needed considerable ad-hoc human expertise to manage; in the history of sysvinit over the last 30 years or so, the automatic management of dependencies between services hasn't been around all that long, and that is one area where a little more complexity in the engine would really have been quite helpful.

Also, if one considers not just sysvinit but the whole “basic plumbing” that systemd replaces (including such beauties as the distribution-specific boot scripts or inetd/xinetd), then any claim of simplicity goes right out the window. The individual components on their own may be pretty simple but their totality isn't (and distribution-specific design choices figure into it, too, so if you have figured out how distribution X does its thing, that may or may not apply to distribution Y), and in spite of all the complexity they don't really form a coherent system that works well together. Systemd is a lot more advanced in that respect.

Which is not to say that systemd is the epitome of internal simplicity – but the systemd developers do care about things like code reuse, and facts like that all the configuration files use the same format (and presumably share the same parser) do suggest that systemd isn't the most complex piece of software in existence, either. It is probably a lot simpler internally than, say, the Linux kernel, or for that matter the sum total of sysvinit and friends.


to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:44 UTC (Sat) by dlang (guest, #313) [Link] (6 responses)

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

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds