Yes.  The actions should be supported by all scripts.  They may do
   nothing or they may do something.  At least that way when you want
   to do something like "for i in /etc/init.d/*; do $i querylog; done"
   you don't get a bunch of crap from scripts which don't support that
   particular switch.  I think things like the cachefs.daemon script
   on Solaris7 are bad examples (that particular script has been written
   in such a way that it does start but not stop).  The S99dtlogin is
   another bad example because it supports a bunch of switches which
   are otherwise unused elsewhere (reset/update_printers/get_server_pid).
   There should be some semblance of orthogonal design across all the
   scripts.

this is ludicrous!  these scripts are modular *individual* beings.
if you attempt to force a defined set of `operations' on them, you
will cripple them.  it does not allow for expansion.  personally,
if i call a script with an unsupported argument, i *want* it to fail
for me!
   
   Well, Solaris has /etc/rc[012356S].d so nerh.  Each of the run levels
   is also different in terms of what is started, etc.  You don't want to
   go the extra step and create a "RUNLEVEL" tag in your scripts, do you ?
   *poke*

i'd hand you a shovel, but you seem to have found an entire squadron
of excavation machines ....
   
   To me it sounds like you're saying "faststart" should be our default startup
   method, here, which I think is wrong.

you meantion on icb this is because 'we' expect this argument to be
`start' and changing that expectation is bad...  i find that i have
to agree with this point.  damn.  luke, can we do this elsewise for
startup somehow???
   
   Well, I'd go for sitting on less fences, if that makes sense :)  Personally,
   I like the idea of supporting /etc/rc as well as the init directory thing,
   but do we need to have multiple init directory based things ?  I mean, it's
   not like we're trying to turn NetBSD into Linux, is it ?

the point is that, by default, NetBSD will have /etc/rc as it does
today, additionally have all the funky scripts for after-boot-time
usage.  beyond this, people will have the *choice* to use any
method of startup they want -- but they'll have to make that
choice themselves, away from the default.

while i'll never use, the sysv option, i can not see any harm in
supporting its existence as non-default.