Subject: Re: On the proposal to augment NetBSD startup (/etc/rc*/*/*...) system
To: Lou Glassy <email@example.com>
From: Michael Graff <firstname.lastname@example.org>
Date: 12/04/1999 09:02:13
Lou Glassy <email@example.com> writes:
>  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.
>  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
> 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
> 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?