The Grumpy Editor's guide to surviving the systemd debate

I didn't think I was. I thought "engine" had a fairly well defined meaning in the software world - it is the bit on the inside that does all the work. It might be a game engine or search engine and you suggest, or a physics engine or an inference engine or a database engine or... whatever is required.

You can often think of a software system as having an engine and an interface.

No, I don't think a more primitive engine is better. I think having core functionality that meets the need is very important and systemd has a lot of that - which is good. I want a sophisticated engine, but I don't want a complicated engine.

I think 'git' provides a valuable contrast. It is in some ways a new and different thing, much like systemd. It uses some well established ideas and combines and presents them in a way that adds a lot of value. And there are people who seem to hate git too - though not as much as systemd it seems.

A key part of the design of git is that core functionality (the so-called plumbing) is directly available if you want to use it. On top of this more friendly interfaces are provided. Originally this was just shell scripts combining the core parts, though I think that over time more and more is being converted to C. This is sophisticated but not too complicated. Core functionality is well defined and directly accessible. This depends on having a rich language for combining the components: shell.

systemd has a lot of valuable core functionality too. But it is not always exposed in a way that provides direct access. The configuration language is extremely simplistic. Quite a few of the directives provided are composites of core functionality - so they set an agenda ("set combinations apply") rather than provide raw functionality.

To be more specific, there are mechanisms for interactions between different units. In upstart (if I remember correctly), such interactions involve "signals" and I think there is full low-level control of signals.
systemd designers deemed that signals were not sufficient (Which is probably correct) and provide something else. What exactly? It seems to be a combination of signals and requirements.

"Requisite" is a requirement with no signal
"Wants" is a signal with no requirement
"Requires" is a combination of the two.

There is more subtlety to the interactions - there is a "reload" signal and maybe a "restart" signal, though that might have requirement implications. There are inverse requirements (conflicts).

But the configuration language doesn't provide access to the core features - I'm not even entirely sure what all the core features are precisely. It just provides a number of directives that pre-combine these features in ways that seem to be useful.

So I do want a sophisticated engine - I want socket activation and process group monitoring and timeouts and auto-mounts and device triggers etc etc. I think all that is great stuff.
But I want direct access to all of it. I want to be in control (yes - I'll admit to being a control freak). I want to be able to access the different functions in ways that the designers never envisaged.

Things become "complicated" when you don't have direct access and so need to work around limitations and do things in no-obvious ways just to get access to the bits you want.

(I'll reply about the examples separately).