>Actually, I'd argue for a more radical step in the opposite direction.
>I think /etc should only contain configuration files, and that means
>few or no shell scripts.  A lot of what shows up in /etc is not
>intended to be modified for specific machines (witness /etc/rc.local
>vs. /etc/rc), needs to be updated for new operating system revisions,
>etc..

>It evades me why people in the System V world decided that each
>package should have its own startup/shutdown script in /etc.  Why does
>all that hair belong in /etc, instead of in the executables for the
>packages themselves?

Probably because shell scripts are much better for modification than
executables, and are really outside the problem set of the executeables.
inetd's job is to handle incoming net connections, not to decide whether
or not there's a net.

Given that, I think the problem is one of hierarchies; there's no clear
place for machine-local configuration that has to be there as soon as
/ is mounted.  I like /etc for this.  The init.d/rc.d thing is frequently
quite nice to maintain, if only because it makes merging in changes easy.

Of course, I actually use most of my machines in several different ways,
and would like to have run levels.  It may be that the SysV perversion
has infected me, but honestly, the rc.d thing strikes me as quite
elegant.  For a reasonably low cost, incurred only during setup and
teardown, you get a widely configurable and customizeable interface
with a lot less intelligence than a single boot script would need to have.

-s
(need to have to do the same things, of course.)