cppcheck could detect the bug without any hard setup effort (launching it in systemd codebase, with maybe an option to activate all checks, was enough) at least 2 years before it was revealed (probably more like at least 3 or 4, I don't remember the exact value). That's a fact easy to verify.
I suspect other tools could find it too, though I have not checked.
What that implies is more speculative, but there are some kind of "either or" situations that are extremely nasty. For example either RH (and all the other distro using it) did not analyse it, or they hid it for other reasons. The most reasonable hypothesis is that they just did not analyzed it. Which put them at least 15 years behind MS in some domains that were even more critical at the time (and still today) than 15 years before.
https://www.youtube.com/watch?v=XfNt6MsLj0E&list=PLbzoR-pLrL...
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.