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?  That is, does any of this alternative startup stuff have
>     to go in the primary distribution?  If someone wants to use a SysV-like
>     startup system, she installs the SysV-ish startup
>     package (or one of several, whichever flavor of init system best
>     suits her needs) and is a happy camper.  But... 
>     please leave the existing rc+conf stuff alone.

IMHO, there should be two ways to start up NetBSD:

	o /etc/rc runs and does what it does now.

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

> [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, and NetBSD's simpler 
>     structure makes the vast majority of what I want to do, consume
>     less of those precious brain cells, because I have to maintain
>     less brain-state about where to look to see what's going on.

The /etc/rc and rc.conf methods to not lend themselves to automatic
package installation.



> 
>     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.  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.

> 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?

--Michael