The important things about Unix init systems aren't booting the system
A while back I said something on Twitter:
Thesis: pretty much anything can boot a Unix system in a static configuration. The important things about an init system are all of the aspects of what happens after booting and outside of a single boot.
In the very beginning, booting a Unix system was considered a very simple thing; the V7 /etc/rc is remarkably short. After a while various complexities showed up and because the problem wasn't well understood, people created various complicated systems for dealing with them. The complexities haven't gone away (a modern Unix has a lot more boot steps than V7 or BSD or System V), but we understand them and how to deal with them, and these days they're essentially mechanical. One demonstration of this is that there are a profusion of init systems and systems to start daemons, and every so often someone writes a new one in a relatively short amount of time and it works fine.
What that means is that both the challenging problems and the state of the art in an init system have moved on from just booting your Unix system in a static configuration. What really matters in init systems today and what distinguishes one from another is largely how they deal with operating the system and changing the system configuration. Changing the system configuration is the easier of the two sides to talk about; it's the area of how you change what happens in the next boot. How you add things, remove things, change exactly what happens, reorder things, and so on. Init systems can make this anywhere from easy to very difficult, and mostly they fall somewhere in the middle.
An init system is also potentially involved in operating the system. This is the area of telling you what is running, how the system state is, what did and did not start properly at boot (or afterward), and starting or restarting things for you while the system is running. Some init systems barely do this; others, such as systemd, are famously deeply entangled in it (for some good reasons). An init system can make this easy, difficult, or impossible. Because this area is newer and less well developed than changing what happens during boot, there seems to be more variation in Unix init systems here.
(For a long time no one even thought about having the init system involved in restarting daemons after boot or starting new ones. We have since discovered that this is a mistake.)
The days when one init system could boot your Unix better than another init system are basically over. Everyone is competent at that and it's not a hard problem any more. What matters to system administrators about Unix init systems is everything else.
(There are some specific environments running Unix kernels and 'Unix' systems where how the init system boots the system matters a lot. Some of these environments are very numerous, for example Android, but they don't really have system administrators.)
|
|