There are ways to make it easy to administrate without making it look
too much like System V.  We've covered them.

Now perhaps we should disengage from the flamage, regroup, present our
choices and go forward with one.

As I see it (FWIW), currently, our choices are (not mutually exclusively):

	+ Keep things as they are (okay, maybe this one is all-exclusive)

	+ Go the SysV route and have /etc/init.d/<script>s setup

	+ Have an /etc/rc_d directory (could we please drop the @!*# "_d"
	  or ".d" or whatever stuff?  It's nauseating!) with <pkg>
	  subdirectories, each of which contains {stop,start,param,setup}
	  ("setup" is a verb, not a noun, here).

	+ Have an /etc/conf.rc file which handles all the system parameters.

	+ Have an /etc/conf.init file which lists the order in which to start
	  the system stuff.

	? Should init be hacked to run /etc/rc.shutdown when it goes out of
	  multi-user mode?

Personally, I don't see much gain in altering /etc/rc and the way it
works save for putting the system parameters into a file.  I think
/etc/netstart should be moved to rc.net (cosmetics, I know) so that
it's at least obvious that it's related to rc and rc.local (which, in
fact, it is).  /etc/rc.local can always be adjusted to run a script
which looks in, say /etc/subsys, for a list of packages, and then run
the appropriate config/start scripts

As far as dependencies go, it is of note that SysV rc$RUNLEVEL.d/[SK]*
scripts only give the illusion of dependency; there really isn't any, as
if S74 networking fails, init -- or, more properly, rc$RUNLEVEL -- will
blithely march through the rest of the S* scripts as though nothing had
gone wrong, much as BSD systems blithely march through the rc script unless
something irrevocably blows up, such as rc has an error (which forces a
single-user shell), or fsck fails (which tells sh to exit non-zero which
forces a single-user shell).

As an aside, there are quite a few people out there who are equating the
subsystem ("package") administration (init.d or whatever) with subsystem
addition and removal.  In fact, the two are really only tangentially
related; I would be so impudent as to suggest that we don't discuss the
two in the same breath as it will just muddy the waters.

As a further aside, I think NetBSD has a better future if the choices
are carefully thought out.  From what I am reading, we want to make it:

(1) easy for users to deal with,
(2) easy for non-skilled/overworked administrators to deal with,
(3) rock solid,
(4) still appealing enough to convince the people working on the system
    that it is still a system with which it is still worthwhile to work,
    and that means it should probably not resemble System V.

[That last one is going to be a flaming point, I'm certain, so I'll just
 do "greywolf->protection_bits |= ASBESTOS;" right about now, but I main-
 tain my point of view:  If you want SysV, go use Linux/SCO/HP-UX/Solaris.
 One of the 'selling' points about NetBSD was that it was BSD and not
 ATT.  Yes, it's an opinion, and it's the way I'm used to, but I think
 we *all* have some things about which we feel this way.]

To more productive discussions like this!


 
    


				--*greywolf;
--
# greywolf@captech.com
# "...to raise a signal means to turn the light on; ... Responding to a
#  signal means turning the light off (and, under System V, hoping the bulb
#  won't blow when it's next turned on)..." -- Dan Bernstein