That's largely how things get secure. Though pre-emptive security through code audits and library rewriting (the OpenBSD approach) also helps.
Init scripts have had those years. Systemd has not.
It's quite a nifty case to make, that we can't use a new init system because we haven't used the new init system for a long time already to find the bugs.
In this case, adoption means moving systemd from being optional to default. Debian has had systemd in use for quite a while now with current statistics at 7.5% of all installation (accordingly to popcon http://qa.debian.org/popcon.php?package=systemd).
So 7.5% of Debian systems have it installed, but only about 0.3% (plus however many of that 7.5% that are setting init=systemd in GRUB) are using it.
That's not the case I was making. Rather it was oofabz's apparent criticism of sysvinit's security profile based on the fact that bugs were found and removed individually. That's not a particularly valid criticism.
There are more valid ways of establishing software quality based on bug estimation (defects found, estimated undiscovered defects remaining). The rate with which init scripts are changed (the fact that they can be modified, possibly erroneously, by individual systems admins is another consideration). A system that's been specifically designed to be resistant to coding and use errors (again: OpenBSD) is better. Some init script systems are better than others, and I've found the Debian scripts to be simpler, cleaner, and more robust than Red Hat's (which use multiple levels of includes and indirection).
In the case of systemd, I've found the touted benefits ("faster booting" -- ORLY? I prefer not having to boot/reboot systems), complexity, novelty, and track-record of the primary developer to be quite troubling. Technology is a complexity management system. Much of the problem in the GNOME project comes from failing to manage complexity appropriately (oversimplifying a complex space, creating complex tools with more levels of indirection (gconf and related utilities). It's a train wreck I saw going off the rails over a decade ago. I've got similar fears for systemd.
Yes, booting is more complex, some systems (especially cloud deployments) may benefit from expedited startups, dynamic management of devices and services can be a benefit. But off of that in PID 1? And don't even get me started on the logging aspects.
I'll be sitting this one out as long as I can.
how does one estimate the latter? (Actually curious if this is a known thing)
The methods aren't too dissimilar to how population ecologists estimate the population of a wild animal population (you tag individuals and note the rate at which you're repeated re-tagging the same ones), the estimated total falls out via statistics.
It's not a method that's applied frequently even within organizations (I've worked in and with QA numerous times), and my copy of Cem Kaner's Testing Computer Software doesn't seem to address the matter. Boehm's Software Engineering Economics discusses software reliability modelling at page 181 (Chapter 10: Performance Models and Cost-Effectiveness Models).
IEEE has "An efficient defect estimation method for software defect curves" which looks like it should cover the area, membership or purchase required:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124539...
"Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort", James Cusick, Wolters Kluwer
http://arxiv.org/pdf/0711.1669.pdf
BUG COUNT ESTIMATION: http://www.testdesigners.com/bugnets/bugcountestimation.html
References Capers-Jones, leading authority in the field.
Many methods start with an assumption that software coding is essentially a progress of inserting bugs into code at a known rate (and there are studies which have established such rates with fairly high levels of confidence). So debugging and QA are then a bug removal function. Knowing what your bug insertion rate was allows you to estimate how many of those bugs you've removed.
That's the theory.
That's what we know about this company from an old (2007) article:
> “When we rolled into Baghdad, we did it using open
> source,” General Justice continued. “It may come as a
> surprise to many of you, but the U.S. Army is “the” single
> largest install base for Red Hat Linux. I'm their largest customer.” [1]
It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government.
If politics was a problem the most practical way would be to just fork systemd because it has friendly license and is feature rich.
I also would say that every critical system components are control by different ententes. BUT don't like systemD you can use any of a dozen options.
The Interface Stability Promise [1] by systemd team is just a promise, nothing more. I wonder if Red Hat will keep it if it decides that it no longer serves their bottom line.
[1] http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...