Why I dislike systemd

Except that rc.subr is shell scripting alone. It's literally a shell script that gets sourced into another shell script (in this case, your initscript), which is - again - ordinary shell behavior. Yeah, you have to learn a couple of shell functions and variables, but that's not really that big of a deal for someone with even cursory knowledge of shell scripting.

The bigger point, though, is that if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts. Even if you decide that shell scripts are the spawn of the devil and ought to be burned on the stake (which, honestly, isn't all that unreasonable of a decision), it's quite possible to implement the same functionality using Ruby or Python or Perl or C or Go or Rust or Erlang or Lisp or PHP or COBOL or MIPS assembly or whatever-the-hell-else you feel like writing init "scripts" in (with some exceptions; FreeBSD and NetBSD, for example, apparently launch initscripts with 'sh' instead of following the OpenBSD and GNU/Linux approach of calling initscripts as executables).

The biggest point, though, is that because of this, if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can have that without having to learn at minimum two languages (one to write your initscripts and one to do all the rest of your day-to-day administration tasks). You just learn shell and you're done. With systemd, you still have to learn shell scripting for even systemd-related tasks (let alone non-systemd-related tasks) plus a new DSL that looks like INI but isn't quite INI. I guess that's tolerable coming from, say, the Windows world (where you're learning DOS batch language and PowerShell and VBScript and INI and Lord-knows-what-else), but that's double what a seasoned Unix admin requires in a non-systemd environment, which is pretty significant.

Interesting read, thanks!

However I would not characterize that as "Poettering completely misunderstanding a perfectly valid use of su".

It seems a quite complex issue about a workflow that is only half-working even without systemd. A systemd patch has been committed that fixes the most blatant error, but of course it doesn't solve all problems since most of them existed before systemd.

:-) Thanks, I totally missed that.

> Just like "quiet", which is totally meant to affect userspace programs.

What userspace programs interpret the quiet parameter?

Genuine question. AFAIK, quiet does (or should do) nothing other than disable some of the kernel logging.

> Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.

Yes, and it would have been very useful if the systemd team had offered to implement such a feature, instead of silently pretending to have it.

That thing was news to everyone. Except Kay Sievers, apparently, who chose to share the big news with the world when closing the bug report.

> The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.

By what non-broken programs? There's no reason to even assume procfs will always be there, let alone that the kernel will expose its boot parameters through it. AFAIK, quiet doesn't affect anything but the kernel's logging.

With obvious exceptions (e.g kernel debugging tools and the like), that shouldn't happen.

> It worked perfectly on every system until the kernel bug triggered the feedback loop.

No no. It worked perfectly because the systemd team never bothered to see what happens when the kernel actually tries to use the debug flag, too (i.e. when an assertion actually fires). It should be obvious to anyone who's been programming for more than an year or so that, when you start parsing arguments that aren't yours (which is bad enough in the first place!) you should at least ensure that you don't break the program that uses it.

Yes, the rate limit for /dev/kmsg was increased when it turned out there was a potential to incapacitate the system by flooding the kernel with data from userspace. For what it's worth, if a program did that on Windows, every half-assed heuristic detection engine would have promptly flagged it as malware.

> It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.

How the hell is "I'm passing an argument to the kernel and a program from userspace decides to interpret it" expected behaviour? If I pass rw, too, should I now expect mount to mount every system as read-write?

> Except that rc.subr is shell scripting alone.

Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it.

My point is that either one has to get some domain-specific knowledge or they have to reverse engineer some code. Given that I believe that the second one is a bad choice (people will rely on the implementation rather than on the intended interface) if you have to get some domain-specific knowledge it does not matter if you're using posix sh syntax or a INI-style one.

> your only goal is to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts

Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration. It was one of the many goals. Sure, it could have been done with posix sh syntax, nobody disputes that, but since backward compatibility was being dealt in other ways (using LSB header), switching to a INI-style format seems a good choice if one wants to enforce a declarative-only style.

And if someone claims that init script are needlessy complex and redundant it is because that's the situation of most distributions before the switch to systemd. Switching to OpenRC would probably have fixed that aspect, but systemd solves many more problems that distributors faced and OpenRC did not address, faring more positively in a costs/benefits analysis.