Subject: Re: run levels and initialization (was Re: /etc/default)
To: None <firstname.lastname@example.org>
From: Terry Moore <email@example.com>
Date: 07/31/1995 01:09:54
> > [To work by a strained analogy: SysV's start up sequence reminds
> > me a bit of sendmail -- infinitely flexible, and therefore
> > tricky to ensure correctness.]
> Both are state machines. If you're not comfortable with state machines,
> or don't have some internal frame of reference for them, things can get
> pretty tricky to understand. I don't particularly like sendmail, but I
> sure do appreciate the elegance of the use of a state machine.
I'm not complaining about the state machines; I design silicon for
a living. I use sendmail, write sendmail.cf scripts, and I
am sort of attached to it. Actually, I was fuzzily referring to sendmail's
somewhat checkered history, security wise. It seems to be commonly
accepted that sendmail is too complex to be trusted (in the "nobody
can use it to break into my system" sense of trusting it). The books
and articles I've read on Unix security such as Cheswick and Bellovin
are unanimous on this: e.g., "sendmail is a security risk".
It's not a security risk because it's a state machine; it's a security
risk because it's quite complicated.
I was trying (awkwardly) to raise the same objection about the rc?.d
system: it's too complicated. I said the analogy was strained;
the weakness/complexity is in the use of numbers, which have no
inherent meaning at all. It may be easy enough for the person who
put together a set of rc?.d scripts to figure out what is going on;
but it is a lot harder to approach an arbitrary system and determine
what run level 3 really means.
Also, I'm not sure that using digits to set the sequence of script
execution is really good design. One is trying to establish a
partial ordering on script execution. I would rather see the
relationships stated explicitly rather than implicitly. [Again,
just to raise a red herring, this is the approach taken by hard
real-time systems: the programmer states the real requirement
(complete this task by time T) and then the system uses a
traditional priority based scheduler (using priority numbers
dynamically adjusted) to get the job done. Can one solve
hard real-time problems using just the priority numbers? Yes;
but it is hard to prove that you have, and it is harder to
Enough said. In my experience, adding a package to a system is the
easy part. Much more difficult is configuring all the users'