For those of us that are more interested in FreeBSD due to the whole Systemd 'controversy', look at the other HN link about the 'FreeBSD: the next 10 years' presentation. They clearly state that FreeBSD is in the same position and it seems that they are not hostile towards the concept of Systemd. Personally I hope that FreeBSD will choose a solution that does not involve QR codes (not mandatory).
Opponents of systemd aren't opposed to smarter dependency tracking at boot time. We're opposed to vendor lock-in (making desktop environments and regular GUI applications dependent upon it), an intentional and strong lack of portability (especially important given the former), pushing software into production servers before it is stable and mature, the backroom politics involved in this displacing other competing technologies (OpenRC, upstart, etc), the move to corruptible binary log files, the assimilation and/or replacement of countless other services that already have more mature and stable implementations (consoled, hostnamed, journald, localed, logind, networkd, resolved, shutdownd, timedated, timesyncd, udev, etc), the PID 1 requirement, coupling itself tighter with the kernel (cgroups changes just for it, kdbus, etc), the aggressive and hostile attitudes of the lead developers (Poettering and Sievers in particular), the complete lack of choice being provided from nearly all major distros, Debian dismissing their heritage as a rock-solid, stable, conservative distro, on and on.
Further, rc.d really isn't anywhere near as bad as SysVinit. See an example of an rc.d script here: https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-ho... (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)
Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams,
because that is a universal interface.
Systemd is an application that more properly belongs on Microsoft Windows and MacOS, because of their own tendency towards centralization and control. But I'm not surprised that many popular Linux distros have chosen to adopt systemd, as they suffer from a bad case of Windows and Apple envy.
You don't need to convince me systemd is doing it wrong! I'm in the process of switching to FreeBSD because I don't want the default system to contain something that hasn't been well tested. (Yes, it's a stupid thing, but I've been toying with switching for other reasons and this kind of made me do it :) I've also drunk the jails kool-aid for my next project.)
The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components.
I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable."
So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
> They clearly state that FreeBSD is in the same position....
He also talked about using XML (blech!) for configs, and seemed to be implying that launchd was more what he was talking about (see [slide 33][1]).
I am not especially worried though, as it was just a presentation from [one guy][2] who is not a current member of the [core team][3] or [the FreeBSD foundation][4] and is probably not wholly representative of the entire FreeBSD project.