> It's practically impossible to approach a strange machine and figure
 > out what it does on startup.   

presuming you have a set of symlinks that are alphanumerically setup (like
the rc?.d way), all you have to do is 'ls -1' /etc/rc3.d and you can 
immediately see the order that services startup.  For example:

[root@mickey:2 rc3.d] ls
S000inet       S05settime     S24afs         S46timed       S77httpd
S001route      S08startlmf    S25preserve    S49snmpd       S80crashdc
S002inet_usr   S10syslog      S26security    S55inetd       S90postgres
S003savecore   S11gateway     S27sia         S57cron        S93kerberos
S004paging     S13rwho        S30rmtmpfiles  S60motd        S94mmeserver
S005recpasswd  S15named       S36presto      S61clcdev.mc   S95xdm
S006enlogin    S18nis         S37atm_otto    S63write
S006streams    S19nfs         S39amd         S65mdqs
S01quota       S20nfsmount    S40sendmail    S67bootpd
S04uucp        S21audit       S45xntpd       S75acct

You can see that this sets up net services, sets up the static routes,
mounts a remote /usr, checks for crash dumps, sets up paging, something
with the passwd file  (actually is a recover from a crash in the midst of a
vipw), etc, etc.  This isn't much difficult than groping through the rc
files, and probably easier.  (at least imho).

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

to me, these few seconds of time and bytes of disk space aren't a big deal,
and the payoff of having something really easy to administrate on a grand
scale of lots of machines makes it definately worthwhile
 
 > 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.

perhaps if you have a seperate config file for each module, this is the case,
but if you have one thing, you really just have to do something like:

grep ifconfig /etc/init.d/*
(find out it's in inet)
look at the script to see what variables you need to tweak, tweak them in
	/etc/rc.config

This isn't much different then:

look around in /etc for the right script that does ifconfigs
(discover it's in /etc/netstart)
parse the netstart script, looking for ifconfig's, setup an /etc/hostname*
	for the proper interface.

I don't see this sort of thing being an obscene learning curve.  There's three
places you look for everything, /etc/rc.config, /etc/init.d and /etc/rc3.d.
(personally I'd like to see /etc/rc3.d and /sbin/init.d, but either would be
fine).  It's no different then groping through /etc.

I come from a primarily SunOS/Alpha environment, and find that setting
things up on the alphas (which use this method) is infinately easier than
the SunOS method, where I usually have to rcp over a bunch of rc.local's,
and apply a context diff patch to each of them, looking around for possible
problems that the diff's may have done, and copying them all back out.  It's 
a lot easier to just edit a script that does the right thing and rdist that
script everywhere.  Any subtle system differences can be handled by a
quick prel script that gropes over /etc/rc.config at worst, which usually
doesn't end up happening, because each machine generally always does the
same thing.

This is a considerablly larger effort if you're only running one machine, but
if you're running 500 it makes your life a lot easier...

-Todd

--
Todd Kover                 //  --o-- If, after having been exposed to someone's
kovert@umiacs.umd.edu    \X/         presence, you feel as though you've lost
http://www.umiacs.umd.edu/~kovert    a quart of plasma, avoid that presence.
		     "Beware the fury of a patient man."