> you missed my point:  i don't _care_ what the default is.  i just
> want _both_ to be `supported'.  that's the only way, i can see,
> to allow everyone to be happy.

What does `supported' mean?

If it means "every time core adds a new daemon to the startup sequence, add
it both to /usr/src/etc/etc.*/rc and to /usr/src/etc/init.d/" along with
"have init use /etc/rc if it sees it, otherwise /etc/init.d", that's not
necessarily much of a burden.

If it's "make sure that every third party who writes software with an install
script does BOTH /etc/init.d/ for every other system AND /etc/rc for those
NetBSD users who choose that" (a problem which is apparently major motivation
for this proposal), there's not a chance that the NetBSD core can `support'
/etc/rc -- because that's out of their hands.

If it's "accept no checkins of /etc/init.d cool features until someone does
the grunt work to figure out how to do exactly the same thing with /etc/rc",
that starts to border on unreasonable (though the simplicity of the intent
behind /etc/init.d makes that a bit unlikely).  Something tells me there
might be howls of distress if core refused a shell-script version of rogue
to be plonked into /etc/rc simply because it hadn't been written for
/etc/init.d as well, though (i.e. it's probably easier to add features to
/etc/rc that require dedicated thought to duplicate with /etc/init.d, though
how many of those are good ideas is a different question).

One nice thing about /etc/init.d is that reinstalling the standard startup
scripts won't erase all the local additions I've made (X11 libraries, xntpd,
innd, and all the other daemons).  Of course, I'll still have to make look
over the install process to make sure that neither the order nor the semantics
have gotten changed -- but at least it will be harder to simply *drop* an
important change because I was simultaneously forgetful and careless.

On the install-time choice idea:  presenting a user with the text "do you want
sysv /etc/init.d or bsd /etc/rc?" is going to be meaningless gibberish to 95%
of the potential installers (and the remaining 5% will chose based on their
own irrational prejudice rather than reason ;-).  Heck, it would have been
meaningless gibberish to *me* before I wrote a System V style init for UNOS
(including run levels, brrrrr!).  Can you write a one-line capsule summary of
the issues behind the choice that doesn't involve the phrase "superior in
every way so why are you even THINKING of choosing ..."?  (Which, by the way,
won't fit on one line once the names are filled in. :-)  If /etc/rc is the
"hacker friendly" initialization script, then the hackers can uncover it by
reading the source (or the installation docs if they stoop that low. ;-)

I use a source-available operating system because I no longer get my OS hacking
fix via my employment.   Dorking with installation and administration is not
what I'd like to hack.  The *process* of dorking with installation and
administration might be something I'd hack, except that I've already DONE
that.  From what I've seen, administering systems from 6th Edition to SVr4,
if you want to spend as little time as possible on adding packages, you want
an easily modularized administration scheme, and for all its faults,
/etc/init.d is a very straightforward and modular system.  /etc/rc may give
you the ability to design complex and subtle interactions between your
startup scripts, but for most people that's a bug, not a feature, and to
believe that automated scripts could install brand-new subsystems easily
into such a startup script is, well, WELCOME TO DOS.  HERE'S YOUR AUTOEXEC.BAT.

(Yes, someone can "design" complex and subtle interactions between /etc/init.d
startup scripts, or worse, can put them in without "designing" them.  But do
you really believe that someone who does that, despite the hint offered by
the separate scripts that you shouldn't do that, is going to correctly design
a way to add those interactions *correctly* to *your* /etc/rc?)