Subject: Re: /etc/default
To: None <current-users@NetBSD.ORG>
From: Peter Seebach <email@example.com>
Date: 07/27/1995 20:50:16
I suspect they were never implemented because BSD has a strong rep as
a "hacker OS" - put in features only if you're the inventor, or there's
a *VERY* compelling reason. I guess, one of the strengths of Unix has
always been that you put in features most people never need. Show of hands:
How many people *use* the '-k' option of sort(1)? I've never needed it -
not in >10 years of hacking and scripting. Not *once*. I've used it,
twice, to see what it did.
But if you need it, it's a very good thing to have the tool there, waiting
to be used. I've yet to see any argument against the run-level idea except
"I never use it; either the system is up, or it's single-user, or it's
down". Personally, I would *love* to have more states; I want to be able
to put the system in multi-user LAN-only mode, so it doesn't choke on
DNS requests outside the local domain when Kibo breaks the Internet. I
want to have a remote-login-only state where all the gettys are off,
when I'm mucking with the serial driver. I want to be able to *bring
services down*, not kill them arbitrarily. What if a daemon or program
wants to save non-trivial state information before exiting? A way
to safely bring it down is worth having, and worth making automated.
I shouldn't have to know which processes are part of nfs to shut it
down, any more than I should need to remember whether it's '-n 4' or just
'-4' to bring up four nfsiods. Sure, I *do* remember - but I shouldn't
have to type it. And if there's some tricky magic to bringing something
up, I shouldn't need to type it all the time.
The run level and start/stop script thing is a major piece of the modularity
a live system sometimes needs. I would easily use 10+ runlevels if I had
them. Not because I'd use any of them all that often, but because
'init 8' is a lot shorter than 'skill -9 nfsiod mountd nfsd telnetd inetd...'