[ On , April 24, 2000 at 11:50:58 (-0400), Perry E. Metzger wrote: ]
> Subject: Re: run levels (was Re: The new rc.d stuff...)
>
> I've never seen run levels used the way you mention it. Never. Period.
> Zippo. I've never even heard of it anecdotally from anyone
> else. Unless you can give me a concrete example of a place that
> actually uses them, I am disinclined to belive in them.

I personally learned to use run levels this way from other systems I'd
seen (AT&T production systems) which used run levels this way and as a
result I implemented several systems to control backups, databases,
network access, batch mail and usenet news processing, and so on.  In
all cases the most important factor in choosing run-levels was always
that the state of several base system facilities needed to be changed in
sync with the application.

Yes all of these things could be done by a separate state machine
implemented in a script or some other program that called out to the
appropriate /etc/init.d scripts or even directly implemented what they
did.  However it really does make things simpler if the entire control
mechanism is integrated into one scheme.  Long term system maintenance
is far less error prone that way.

However I am wondering just how many of these systems that you do have
experience with are in fact true general purpose machines as I was
alluding to.  Very few systems remain in the world (at least in ratio
with the total number of systems running similar operating systems)
which have as many, sometimes conflicting, requirements imposed upon
them as those I was referring to.  (That's not to say that they are so
rare that it's not necessary to consider their needs, of course!)

I'm also wondering just exactly how the batch scripts you describe were
designed and implemented and what system support requirements they had
to meet.  I can imagine dozens of scenarios that would account for your
not having seen run levels used to implement system state changes even
when they were available across all potential platforms and even if you
had experience with many large and small shops.

> Even if you can give me an example or two, it isn't very meaningful.
> I'm sure *someone* out there is using them -- everything you put in a
> system will be used by *someone* given enough users -- but given the
> breadth of my experience I'm inclined to believe they're just odd, and
> could do what they want to do with run levels in another way.

Believe what you want -- I obviously can't change your mind for you if
you're not going to be open to alternatives.

> You can claim, of course, that I'm just imposing my tastes on the
> world and that I'm not omniscient. That's true. However, NetBSD is
> very much a meritocracy of taste. We don't add everything -- we add
> things very much based on our sense of aesthetics and
> quality. Therefore, subjective judgments are sometimes needed, and
> I'd say in this case, the general consensus is that runlevels are lame.

I've no doubt that within this group that many, and perhaps even the
majority, of people will agree with you.  However outside of what
direction this implies the most vocal users desire NetBSD to take, this
is completely meaningless.

If you look carefully you'll note that I did not say that run levels
were a feature that was absolutely necessary for me to find in NetBSD,
nor did I claim that run levels were the ultimate solution to every
system management problem.  In fact you'll probably even notice that I
prefer to describe a more general purpose state machine instead of any
particular implementation such as SysV "run levels".  Such a state
machine will solve some relatively important, if not entirely common,
problems very well; and they do not generally get in the way on systems
that do not face these problems provided that the default system
configuration is well specified and documented.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>