Do you think a manual audit of 100k lines of code will uncover multi-threading or memory issues or any other security issue? Experience has shown that for c co

Do you think a manual audit of 100k lines of code will uncover multi-threading or memory issues or any other security issue? Experience has shown that for c code for the first two, no it won't. And for any language code, manual audits won't find issues in the last category either. It may help, but it won't excise them all (or even close to all). To get them out, you need real world testing. The system that sees more real world usage, probably gets more testing. Any security analysis would want to take this into account also. My earlier point about "what do you want to get out of your systems" is that you alluded to the reliability of debian being desirable. Distro maintainers by and large switched to systemd since it saved them a ton of work. They could then spend that extra time on the rest of the activities of being a distribution. So debian could focus on being more debian-like instead of debian-like + maintaining a creaky init system. So if what you want is debian, and you see very few distros like it that also don't have systemd, think about why and if what you're asking is detrimental to the other goal of what you want. FWIW, I've maintained embedded linux distros at a couple companies, at my most previous employer we used systemd, the current one we don't. It isn't the right choice in all scenarios, but it is a lot of the time.