init vs. systemd
Chapter 2 of the “UNIX and Linux System Administration Handbook” talks about the boot process. Nothing special here, except…ever so interesting debate of init vs. systemd.
The main points from systemd opponents being making the system more complex and less modular. Modularity, as we all know, is one of the Unix’ main merits.
OTOH, general Unix evolution trend of the last decade seems to emphasize booting stage ever more in the overall OS lifecycle. Just look at all those compartmentalization, virtualization, scaling and other cloud computing hypes. All of them imply growing application for short-lived OS instances, which in turn imply more proportion of instance lifetime spent in the boot process.
In legacy systems it was not uncommon to see uptimes in the range of 1 or 2 years and several whopping years sometimes. Today, with auto-scaling distributed HA systems, VMs often get spun up for a few hours a day to handle load spikes.
Comparing these two system classes, it is easy to see the importance of boot process optimization: it has become two (sometimes three) orders of magnitude more prominent time-wise nowadays.
Not only systemd cuts time wasted in bootstrapping by fostering parallelism, it also improves on load spikes response time, and streamlines configuration management by reducing shell scripting hackage required to configure complex boot processes.
Conceptually, this part of Unix evolution corresponds well to the general global information processing trends. Those trends lean towards collaborative, cross-disciplinary information processing and interpretation. Similarly, Unix processes and services can no longer remain “strictly modular” in a modern system, if the system architect seeks to optimize the system for best performance and value for the customer. Unix services need to collaborate between each other more closely to reach that target. For that, systemd is clearly suited much better that the venerated classic init.