A backdoor in xz

What about kernel modules? They are usually not in /boot.

To carry on with niner's point, /boot/vmlinuz-6.7.9-amd64 may be nine megabytes, but /lib/modules/6.7.9-amd64/ is over a hundred. You could read through the kernels of Unix v6 (the Lions book), or xv6, or Minix. Even twenty years ago, the kernel was so big that the SCO mess turned up a copy of Unix malloc buried in kernel that no one had noticed, even though it should have been replaced with standard kernel functions. Should we use a tighter (less functional) kernel that's actually readable? I don't want to give up a lot of the features I use, but there's certainly no one with the headroom to completely understand 140 MB of source code.

Well, not when building it. Running it is another matter, as it pulls in a heap of pre-built binaries (firmware) with poorly-documented provenance.

--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -562,7 +562,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
                size = rc;
                rc = 0;
 
-               dev_dbg(device, "Loading firmware from %s\n", path);
+               dev_warn(device, "XXXX Loading firmware from %s\n", path); 
                if (decompress) {
                        dev_dbg(device, "f/w decompressing %s\n",
                                fw_priv->fw_name);
@@ -924,6 +924,10 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
                fw_log_firmware_info(fw, name, device);
        }
 
+       dev_warn(device, "XXXX request-firmware name=%s, ret=%d\n",   name, ret);

        *firmware_p = fw;
        return ret;
 }

Another solution is the watchdog: the service has to tell the service manager "I'm still running!" periodically, otherwise it's treated as failed. Then the main effect of the initial "I'm running!" is that the timeout before it is given by TimeoutStartSec, and the timeout after it is given by WatchdogSec, which can be shorter (allowing for services which are slow to start, like heavy Java-based servers).

One does not exclude the other. In fact many of my monitoring scripts actively check that the service in question hasn't legitimately been shut down before complaining (too) loudly.

You cannot do a "has legitimately been shut down" check without systemd. (Well, OK, of course I could use or write some other code that does this job, but why would I want to replace one mostly-coherent, widely-used presumed-safe software package with five less-widely-used and poorly-integrated ones? sysV init scripts are of no help here)

> Til they tell the service manager "I'm running!" just before failing.

Which is a bug; they should complete all checks that make them fail before reporting success. Yes, bugs are a reality.

> The only *actual* solution for that problem is monitoring. Notify-by-socket is precisely equivalent to notify-by-fork in terms of reliability.

No, there exists many cases where a fork happens and then the program fails before it would have notified the service manager it was successfully running. By the same logic, monitoring is precisely equivalent to notify-by-fork in terms of reliability; monitoring programs can fail to notice a service no longer working as well, except that they add false positives and can report that a system has failed when it's been properly shutdown or had a temporary glitch, as from system overload.

> - jobs are started in sequence. Things like Network were started before network daemons like sshd, apache, etc;

What about wireless or VPNs?

> Also, the "hey, I'm running" task is really simple: if a process has problems, it shall die.

A Java server that I have for telephony takes 2 minutes to start up. How would you detect that?

There's also a problem with double-forking. The only process that can detect the death of a double-forked server is PID 1, and in classic SysV all it did was to reap the PID. Ditto for inittab - it can't detect the death of double-forked processes.

If SysV init systems are actually more robust than systemd ones, it's because they're much simpler - your description captures that simplicity really neatly, in fact.

Though I don't actually believe that claim - I've had plenty of SysV init based systems that were massive pains in the neck to deal with, while the majority of the systemd based systems I've managed have been fairly benign and well behaved, despite doing a whole lot more. Also, the issues I have to deal with generally have nothing to do with systemd, and when they /are/ issues with the unit configuration they've been much easier to resolve than similar issues with init scripts ever were.

Oh, and writing a service targeting a SysV init environment is /far/ more of a pain than writing the same thing targeting a systemd environment - in fact, it's ridiculous how easy it is to target systemd with a basic service. No daemonising, no futzing around with logging targets, no pid files, even the kind of basic intra-service coordination you're pooh-poohing is ridiculously simple. And no mess of spaghetti shell code init script! Most of the time the unit file for a basic service is five or ten lines, and they're simple and declarative with no complex logic - infinitely easier to write and debug. Even when you need to set up complex interdependencies it's generally simple to configure and relatively easy to debug - it can be fiddly, but that's mostly inherent to the problem, rather than an artefact of systemd's implementation.

SysV init worked okay in its day, though it was always a bit of a pain. But it's long /long/ past the time when people should have recognised how much of an improvement systemd is, in pretty much every way. Eulogising the past is all well and good, but actual current performance matters a whole lot more in the real world than sepia-tinted memories of past glories.