== How init wound up as Unix's daemon manager

If you think about it, it's at least a little bit odd that PID 1
wound up as the de facto daemon manager for Unix. While I believe
that [[the role itself is part of the init system as a whole
InitDaemonSupervision]], this is not the same thing as having
PID 1 do the job and in many ways you'd kind of expect it to be
done in another process. As with many things about Unix, I think
that this can be attributed to the historical evolution Unix has
gone through.

As I see the evolution of this, things start in V7 Unix (or maybe
earlier) when Research Unix grew some system daemons, things like
_crond_. Something had to start these, so V7 had init run _/etc/rc_
on boot as the minimal approach. Adding networking to Unix in BSD
Unix increased the number of daemons to start (and was one of several
changes that complicated the whole startup process a lot). Sun added
even more daemons with NFS and YP and so on and either created or
elaborated interdependencies among them. Finally System V came along
and made everything systematic with _rcN.d_ and so on, which was
just in time for yet more daemons.

(Modern developments have extended this even further to actively
monitoring and restarting daemons if you ask them to. System V init
could technically do this if you wanted, but people generally didn't
use _inittab_ for this.)

At no point in this process was it obvious to anyone that Unix was
going through a major sea change. It's not as if Unix went in one
step from no daemons to a whole bunch of daemons; instead there was
a slow but steady growth in both the number of daemons and [[the
complexity of system startup in general FsckHistory]], and much of
this happened on relatively resource-constrained machines where
extra processes were a bad idea. Had there been a single giant step,
maybe people would have sat down and asked themselves if PID 1 and
a pile of shell scripts were the right approach and said 'no, it
should be a separate process'. But that moment never happened;
instead Unix basically drifted into the current situation.

(Technically speaking you can argue that System V init actually does do
daemon 'management' in another process. System V init doesn't directly
start daemons; instead they're started several layers of shell scripts
away from PID 1. I call it part of PID 1 because there is no separate
process that really has this responsibility, unlike the situation in
eg Solaris SMF.)