At 07:46 PM 12/27/00 -0500, Lord Isildur wrote:
>I still think the rc.d stuff is needless complexity and just bowing down
>to the pressure of trendy fashion in the linux and sysV worlds.

A bit of history perhaps, perhaps just one person's view...

I was in the systems group at Sun when System V was born. I make no 
apologies for that but chuckle at the way things turned out sometimes :-)

rc.d was introduced primarily (and this from the Requirements Documents 
that AT&T had generated) to facilitate the easy installation of third party 
software to a running platform. All "commercial" operating systems up to 
that date provided mechanisms whereby the OS vendor defined interfaces for 
third parties to use when they wished to install initialization (aka boot 
scripts) without compromising the integrity of the system over all.

The mechanism at the time of using sed(1) on /etc/rc was error prone and 
damn difficult to manage. rc.local wasn't much better and people began 
adding rc.frame and rc.greenhills kinds of hacks. Creating a directory 
init.d that had the mechanisms installed in it and then the rc.1, 2, etc 
that had hard links defining the invocation order for those scripts. 
Frankly I think it had advantages but the cost was too high and should have 
been scrapped. Unfortunately the "curse" of the open software movement is 
that we get to revisit these mistakes again and again and again and never 
get out of the cycle (talk to me about "transport independent" RPC sometime)

--Chuck