>> I don't see how it causes problems for humans.  If you want to modify
>> the startup of foo, you edit /etc/init.d/foo.  That seems easier to me
>> than editing one massive file.

>It's practically impossible to approach a strange machine and figure
>out what it does on startup.  The scripts in /etc/init.d, because
>they are independent, have to do quite a bit more than would be done
>in /etc/rc.local.   So each script winds up being about the size of
>/etc/netstart on NetBSD.

Hmm.  I suppose this is often the case, though not always.

>Then, you can't edit the whole startup process at once - you have to
>grep around for the daemon you're trying to control, then edit the
>file that controls it, and usually figure out the entire functioning
>of that file and then touch yet another file somewhere else to make
>the change you want.  The learning curve is obscene.

But you don't *want* to edit the whole startup process.  You want to
edit the part you're looking at.

I guess, usage will vary.  init.d is excellent when you want to,
say, look for nfs or file services - one file will do that work.
It's hard when you want to find "what starts bazd", because it
expects you to know what service bazd is associated with.

But honestly, folks, we're using Unix.  We *expect* learning curve,
and gleefully welcome it when it improves flexibility or power once
you've beaten it.

A reasonably well built set of init.d files is rarely confusing; each
covers a specific subsystem, and if you want to edit "the network stuff",
it's probably all there.  If it isn't, it's because, some of the time,
someone wants to run one part but not another.  Separating those helps
document where the boundaries go.  Is "partially up" nfs but no serial
port logins, or serial port logins but no nfs?  This is something that
init.d style stuff helps make clear.

I agree, there's a learning curve.  The real win of init.d is that, if
the sysadmin is doing a good job, you only have to learn one netstart-sized
script at a time, not the entire set of all startup activities.

It's the old modularity war.  It's harder to find all the pieces of
a multipart program, but easier to maintain and control.  This applies
to shell scripts as well as to C.

MHO, obviously.

-s