On 4 Dec 1999, Michael Graff wrote:

> Lou Glassy <glassy@caesar.cs.montana.edu> writes:
> 
> > [4] Random idea:  How about if proponents of SysV-ish startup script
> >     structures just build this as a package, put it in the package
> >     tree?  [...]

> IMHO, there should be two ways to start up NetBSD:
> 
> 	o /etc/rc runs and does what it does now.

Ok.  

> 	o /etc/rc drives the startup using /etc/init.d/foo scripts.

Maybe not-so-ok.  I'll come back to this in a moment.

> > [5] Random idea: (my i'm on a roll.)  I use SysV-ish systems and 
> >     NetBSD at work, every day.  The start/stop thing in 
> >     /etc/init.d/foo start [etc] is nice, but the simplicity of 
> >     the BSDish rc.conf setup that NetBSD is even nicer.  I am 
> >     starting to run out of brain cells, [...]
> 
> The /etc/rc and rc.conf methods to not lend themselves to automatic
> package installation.

Yes, but I'm not advocating that rc+rc.conf be put under the existing
package system.  I think a new "SysV Init" setup could be packaged...

> >     But, like I said, start+stop is nice.  How about making a script,
> >     or program, or package, that has some wondrous kickstarter in
> >     it, ...
> 
> Because that is a roll-your-own, noone-else-uses-that,
> users-need-to-learn-new-stuff path.  

Having a single-program kickstarter/stopper is not one anyone else
does right now.  But I'm just throwing that idea out for people to 
chew/nibble on.  As for:

>                                      I can't see why using it would be
> a win, and in fact, not following what several other vendors (and
> unfortunately linux is a vendor now, ala red hat at least) do is a
> serious mistake.

Owie.  This smells like a new version of the "Ten million lemmings
can't be wrong" claim.  Here's what I mean.  If the goal of NetBSD
is to not follow & repeat the egregious hacks other OS's use, and instead
is to really do something *better*, then following what other vendors
do is not "necessarily" A Good Idea.  (I'm probably going to regret
saying this, but.... Another example:  suppose Linux and Sun both 
go to a binary "registry" way of storing system config
and /etc/rc-like information, and suppose too that these 
"registries" pervade every single program on the system.  
An OS developer could justify this with the claim 
that "THIS IS STANDARD PRACTICE", because, after
all, Microsoft does something like this.  But I would counter that
design choice with the observation that Microsoft has seldom been
known for doing things right (in general), and that a registry-model
makes *many* system config tasks *harder* (in specific).

Circling back to this option of 
> 	o /etc/rc drives the startup using /etc/init.d/foo scripts.

it seems to me this could be done as an add-on package (optional).
Indeed it could be done in many different ways - the boot script
structure for the three Linuxes I've used - Slackware, RedHat, Debian - 
all put things in different places, and start things in different
orders.  Solaris, DUX, Irix, also have variations in location and 
order of starting/stopping services.  Maybe if the goal here is 
To Please Everybody, we need to come up with a way to "emulate"
the startup/management scripts for eight different SysV-like FooNixes.  
But as far as what should go into a NetBSD distribution *itself*, I think
the existing rc + rc.conf arrangement is pretty close to what 
(at least) traditional BSD users/admins want.

> > If NetBSD's startup system evolves towards an init-script/runlevel
> > setup, well, that just means I will have to hack my own installs
> > of NetBSD backwards to the current state, which I am actually very
> > content with...
> 
> If/when we go down the rc.d/init.d path, I suspect the first cut at
> least would be driven by a replacement /etc/rc.  So, if you don't want
> to use that method, don't replace /etc/rc.  :)
> 
> One thing the init.d method doesn't fix, however, is the problem of
> options.  Or is there a /etc/config.d associated with these things?

I didn't see mention of a config.d, but maybe I wasn't reading closely
enough.

> --Michael

Thanks for your thoughts.  I'm still not convinced that SysV-like init
scripts are The Way To Go, despite the roar of crowds, but you're 
making me think, and that's a win.  :-)

-lou