>> The learning curve [for /etc/init.d-style startup] is obscene.
> But you don't *want* to edit the whole startup process.  You want to
> edit the part you're looking at.

I _do_ want to edit the whole process at one point: when a new OS
arrives.  They _always_ need sanitizing, often extensive.  Indeed, I
see no real reason to split /etc/rc into two pieces (/etc/rc and
/etc/rc.local); both of them invariably need hacking on.

> 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.

Heh.  Except that "file services" is too broad.  How many of your
startup scripts affect the filesystem?  One mounts local disk, another
starts your NFS client code, a third (or perhaps that same second one)
mounts NFS filesystems.  A third mounts /proc and /kern and maybe a few
others.  A fourth starts AFS.  A fifth fires up AppleShare, making the
network Mac server visible under UNIX.

Right.  File services are all in one place.

NOT!

> 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.

Scattered across multiple files, though.

One file ifconfigs the interfaces.  Another starts up the router
daemon.  A third fires up NFS.  A fourth starts inetd.  A fifth for
AFS.  A sixth for that d*mn license manager that doesn't know how to
run from inetd.  A seventh...I think you get the point. :-)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu