I am really not liking this newly interventionist moderation regime. It's not just that I disagree with many of the individual decisions (though I do). It's that it's thoroughly capricious, and that makes HN a really unpleasant place to be.
In all seriousness, Poettering is at least trying to replace complexities with simplicities. He thinks unified config files are simpler than ad-hoc shell scripts for init systems. He thinks a sound system that handles all audio in a uniform way is simpler than having a bunch of different APIs that implement a different and incompatible part of the audio stack.
Nobody is trying to make things more complex, or if they are, it's usually a joke like brainfuck.
He thinks unified config files are simpler than ad-hoc shell scripts for init systems.
That's a gross misrepresentation of the problem. Shell-based rc does not have to be "ad-hoc" if there is a sane process management framework in place. In such cases, the scripts can be extremely terse. [1] [2] In essence, the scripts become mere "callbacks" and have their primary purpose to provide the start command line, optionally with some form of chain loading to compose execution state. One can go further and write a small, special-purpose LL(1) command language for chain loading of programs, e.g. execline. The unit file format, conversely, cannot be composed, the options must be treated as static entries, and implicit state is carried, sometimes making service writers resort to horrifically subverting the systemd model just to escape. [3]
I'm not trying to represent the problem nor do I want to discuss the merits of systemd. I am just talking about what Poettering is trying to do and why he says systemd is better. Whether he's actually achieving it is of no relevance to his stated intentions.