On Sun, 2 Apr 2000, Simon Raahauge DeSantis wrote:

# On Sat, Apr 01, 2000 at 09:58:06PM -0800, Greywolf wrote:
# > On Fri, 31 Mar 2000, Simon Raahauge DeSantis wrote:
# > 
# [snip]
# > # Airport (such a neat gadget)). NetBSD is dependable. NetBSD is beautiful.
# > # There are no gross hacks. There are no idiotic 'features'...
# > 
# > ...modulo the proposed split of /etc/rc.conf...
# 
# I haven't kept up on -CURRENT, so I don't know this. But I would be very
# unhappy with any sort of rc.d change. Having a centralized rc config is the
# way to go. It scales well enough with rc.local (and I could very quickly
# setup rc.local.conf or get things from rc.conf to use in rc.local if I
# wanted to). This seems to me to be in the (Net)BSD spirit: simple,
# effective, flexible. I haven't used Linux very much or any other OS with
# rc.d but from my understanding it's a framework to do exactly what we do now
# with a few shell scripts. Runlevels seem idiotic.

okay, allow me to interject here.  Eventually, it seems, we will have
runlevels.  Regardless of who wants a feature or not, it will eventually
get shoved down the collective throats of the user community.

Now, if we can do a skeletal runlevel implementation (i.e. we handle things
as we do now:  We have a single-user runlevel and multi-user runlevel with
the other levels to be filled in as needed), it probably won't be so bad.
If we can do it *right*.  IF.  BIG - I say, BIG IF, there.

The thing that offends my visual senses is seeing the Init: changing
state messages, but I think that if it's sufficiently ADJUSTABLE!, then
we can even make them more eye-pleasing (i reserve the right to have
my init report:

	Single-user mode.  Go away
).

I'll continue in a minute.

# We have single-user and
# regular/multi-user. If I need for whatever reason some services running in
# single-user (like networking to get at backups) I can very easily start it
# by hand. This is easier than trying to understand grotty run levels.

I agree to a point.  The point of the skeletal implementation is that you
can then roll your own run-level to get a configuration to the above.
single-user with networking is not necessarily as rare as you might think.
I go there frequently.


# Anyone
# who would be doing such a thing would have the expertise to do so by hand
# and it would be so rare that it's just fine to do so.

No, and yes - see above.

# If for some bizzare
# reason your requirements are different it's not so hard to roll your own
# script (which you would probably do anyway to deal with your particular
# setup, like if you needed some sort of half-multiuser mode we're already
# talking some custom work).

Ah, you said what I did.

# I liken this to the package system. I've done a
# few things with the Debian package manager. It's easy, yes. But I like the
# NetBSD system better. It gives me more freedom in how I do things. It's less
# intrusive. It's just like everything else. It's not special. No special
# syntax (I'm mostly referring to runlevels here).

IF we do runlevels, and we do them right, we don't have signals going to
init - we have init listening on a loopback unix-domain socket (i.e. it
rejects all calls from anywhere besides 127.0.0.1, although if we wanted
to really get ugly, we could permit it to accept calls from a defined
network or other set of systems, thus allowing remote administration
of init.  Yes, this is getting gross, here, but it might be a desired
feature.)

Now, I don't necessarily embrace what's happened to rc.d.  It stinks of
System V, and I don't think this is the right direction to take on this.
But I need to choose my battles, as I don't have a whole lot of energy
to spend on this sort of thing.

The battle I choose in this case is a strong one against the fragmentation
of rc.conf.  Loud and Clear:  I DON'T WANT TO FIND MYSELF RUNNING SOMETHING
THAT SMELLS LIKE IRIX.  It's GROSS.  It's NOT well thought-out for the systems
administrator.  I don't WANT some stupid script deciding how it's going to
mangle my configuration.  Okay, fine, drop it into rc.d, great, fine.  But
to have everything split out into different config files?  Man, that's
FRUSTRATING, to say the least.

If there are any other dissenters out there, I rather suggest you make
your voices heard!  If there are other assenters out there, I'm really
interested in the reasons why splitting rc.conf is a good thing.

I can see a case for making an OVERRIDE somewhere (provided there's a
NOTICE at boot time, i.e., in /etc/rc.conf the line
	nfsd=NO		nfsd_flags="-tun 4"

and in /etc/rc.d/nfsd.conf
	nfsd=YES	nfsd_flags="-tun 8"

would produce, at config eval time:

...
Starting nfs daemons: mountd nfsd@* nfsiod rpc.statd rpc.lockd amd.
*NOTICE: nfsd=YES in /etc/rc.d/nfsd.conf overrides nfsd=NO in /etc/rc.conf
@NOTICE: nfsd_flags in /etc/rc.d/nfsd.conf overrides settings in /etc/rc.conf
Creating runtime link editor directory cache.
Checking quotas: done.
Preserving editor files
Updating motd.
...
).

But please don't splinter rc.conf.

				--*greywolf;
--
BSD: The choice of hundreds worldwide.