> ... BSD-style rc files, which are tiny and very readable ...
As someone who has an on-going project to replace 157 rc.d scripts from FreeBSD 9/10, I can report that the generalizations about the Mewburn rc.d system that are often made, in order to contrast it with the egregious mess that one can find in the System V rc clone on Linux operating systems, are not in fact strictly accurate.
Yes, most of the rc.d scripts are small. Yes, the Mewburn rc.d system did almost 16 years ago what people are erroneously characterizing as novel to systemd: namely taking all of the common management code out of the individual service definitions, leaving just a few parameterizations in some cases. Yes, there is a definite common coding style that is a breath of fresh air when coming from the Linux world.
But no, the scripts are not universally tiny. One problematic example currently of interest is /etc/rc.d/bluetooth, weighing in at over 360 lines. Others include the subsystems that are split across multiple scripts, such as /etc/rc.d/atm1, /etc/rc.d/atm2, and /etc/rc.d/atm3.
Nor are they universally consistent, /etc/rc.d/serial being an example of one with quite different configuration semantics to the key=value-in-rc.conf{,.local} norm.
And whilst one might rail against the problems of having a common script for SuSE Linux, Debian Linux, and RedHat Linux, all of which have different sets of init.d script helper tools (resulting in "portable" init.d scripts ending up being a case "$distribution" in...esac statement for pretty much every step), one can equally point to the fact that OpenBSD's rc.d system (https://news.ycombinator.com/item?id=8506460) has entirely different function and parameter names to the NetBSD one (as adopted by FreeBSD/PC-BSD and DragonFly BSD) as well as different rules about rc.conf and different variable naming conventions.
Be very careful about attempting to claim some kind of moral high ground on interoperability and standards. (-:
Also be very careful about notions that the Linux world sees the Bourne Again shell as the only shell, some rather silly statements by some people who should know better notwithstanding. The adoption of the (Debian-modified) Almquist shell as /bin/sh by Debian and Ubuntu, and its significant effect on bootstrap speed, is quite famous. And my experience is that the Z Shell is quite popular, for starters.
I don't bite. You're affirming many of the claims while listing a few inconsistent counterexamples. This does not invalidate the original claims though, as, relative to the virtually complete lack of standardization in writing SysV rc scripts (LSB notwithstanding), it is in significantly stronger shape. There are indeed disparities in rc.conf and rc.subr between the BSDs, though probably not any more or even less so than disparities in LSB initscript frameworks.
Really though, the primary reason to cite rc.d is to debunk the pants-on-head claim of shell script-based rc being intrinsically spaghetti and voodoo.
It's not a few. It's somewhere between a quarter and a third of the corpus. "few" is merely the level of outright extreme cases, like "/etc/rc.d/msgs stop" not doing what one might think at all.