Yeah. And there is nothing good about it.

> Sysvinit runs shell scripts and has known race conditions

Bugs can be everywhere. But the smaller the paramount part the better.

> You must also reboot to upgrade sysvinit

You don't

> Yeah. And there is nothing good about it.

I beg to differ, and I think a lot of people will disagree with you. Regardless, your snarky remark fails to state any problems with the Linux kernel, or identify what you consider a "good" kernel.

The whole point of the article is that you don't need to upgrade sysvinit or another minimal /sbin/init like those found in the BSDs.

[1] https://www.ksplice.com/

So if not systemd, what? Debian's discussion of whether to adopt systemd or not basically devolved into a false dichotomy between systemd and upstart. And except among grumpy old luddites, keeping legacy sysvinit is not an attractive option. So despite all its flaws, is systemd still the best option?

No.

After which he proceeds to explain how to solve points 1, 2, and 3 by moving most tasks out of PID 1.

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.

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.

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.

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...

This is not needed anymore. Check systemd's manual for 'systemd daemon-reexec'

What's more, supporting upgrades this way means you need to support every previous state file format, and the more state and features there are the harder this is to do. (Seriously, it was a pain in the butt to keep track of.) systemd is developed primarily by and for Red Hat who avoid this problem by not supporting upgrades to a new distro release from within the running system - but most other major distros do and will likely be bitten hard by the issue.

Without support for this you can't even reboot cleanly after upgrading init or any of the libraries it uses, because init will keep old deleted executable open and make it impossible to remount root as read-only (an obscure quirk of Unix filesystems that basically only init developers need to know). You don't just need to reboot to upgrade init, you need to boot into a special upgrade environment that doesn't use the system's init, and Fedora does. That's why Fedora needs daemon-reexec - otherwise they wouldn't even be able to apply security updates to glibc without rebooting first. Compare this with kernel upgrades, which can be installed immediately and simply don't take effect until the next reboot.

Lennart Poettering on how this is done in systemd:

https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...

The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. (From kill(2))

In practice, you will find that:

    kill(1, SIGKILL)                        = 0

    someapp &

    [job 1 backgrounded]

    kill %1

    (job 1 is killed - yep, you can use kill for jobs)

Probably because you know the features of your shell and enjoy productivity.

    zx2c4@thinkpad ~ $ sudo strace -p 1
    Process 1 attached
    select(11, [10], NULL, NULL, {1, 122329}) = 0 (Timeout)
    stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    select(11, [10], NULL, NULL, {5, 0})    = 0 (Timeout)
    stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    select(11, [10], NULL, NULL, {5, 0}^CProcess 1 detached
    <detached ...>