Pay specially attention to "Making C Less Dangerous", "STACKLEAK: A Long Way to the Linux Kernel Mainline", "Sub-system Update: Kernel Self-Protection Project", "Year in Review: Android Kernel Security", "Sub-system Update: Linux Integrity Status Update", "Security Module Stacks that Don't Fall Over ".
If you want to systemd to adhere to really high standards then you're a hypocrite if you don't apply the same standards to every subcomponent of a non-systemd system, be it upstart, logrotated, cron, chrony or whatever else.
But it seems to me that you actually don't apply the same standards to the alternatives, they've all been hit with some vunerabilities, they all have bugs, they all have at least some terrible code, some lack maintenance or are just outdated. I wouldn't start throwing rocks from a glass house.
Oh and let's not forget that based on a pure empirical observation of the Linux ecosystem we can see that it is a better choice. And no, noone has been forced to use it(, neither was anyone forced to use Pulseaudio).
Obviously, since djb's daemon tools isn't used by default, which is exactly the sort of software that would be used by people who would rely on such functionality.
> It has high standards
One of SystemD's core contributers was banned from contributing to Linus' tree because his code was sub-standard.
> based on a pure empirical observation
...we should then also be able to see the Microsoft Windows operating system is a better choice.
And how many contributors of other projects have even tried to contribute to the kernel. 1 isn't a sample size you can make assumptions based on.
> ...we should then also be able to see the Microsoft Windows operating system is a better choice.
In certain cases it'd be delusional not to admit that.