Subject: Re: Proposed rc.d/rc.conf[.d] changes....
To: Perry E. Metzger <>
From: Andrew Brown <>
List: tech-userlevel
Date: 05/09/2000 12:34:19
>I'm one of the people that pushed for rc.d, because I needed it. I
>have had to hack in rc.d's under OSes for years to deal with the needs
>of automated management of hundreds of machines. I wrote rcorder
>because I thought the System V rc.d mechanism was braindead in the way
>it ordered things. That alone should tell you we aren't trying to
>follow System V in some blind way. I do not accept runlevels or
>support them, and I suspect few enough people do that they'll never be
>in NetBSD.

(jumping in again :)

i don't believe that run-levels themselves are all bad.  the concept
(the abstraction of different states) is nice, but every
implementation i've seen so far sucks.  that's probably why most
people don't like them.

two cases: red-hat and their run level configurator.  drag and drop
mayhem on the run levels, no clear explanation what *anything* is, and
just to make it interesting, they completely overconvoluted a very bad
design.  imagine a soda can with seventeen pull-tabs on it, some of
which lead nowhere, a few will dispense the contents, most of them
will dump the contents on the user and two of them are connected via
quantum tunnelling such that if you pull one, the other one goes back
on.  huh?  exactly!

and now solaris: i just did a "shutdown -is" to take the machine to
single user mode.  um...what are all those web servers doing still
running?  oops, i just typed "kill 1" instead of "kill 100".
didn't do anything.

nice ideas.  bad implementations.  on the other hand...anyone who
wanted something like "run-levels" in netbsd could just fling together
a few scripts that shut down and started up services...

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."