> Suppose you had a real configuration file (not a script in a
> Turing-complete language) specifying the order of system startup tasks
> (not necessarily by the order of the lines that appear in the file).
> The package utility could have primitives for editing the file.  This
> would be easier to understand, wouldn't involve symlinks, wouldn't
> involve an extra directory, and wouldn't make life any harder on
> third-party software than the System V approach.

Hmmm. But what happens after the system is up and everything is
started and the admin wants to disable say NTP, or some other
reasonably isolated service.  Unless your startup mechanism allows for
the admin to manually invoke one module's shutdown or startup hook, he
has to go grovel the ps output - or as more often happens - write his
own version of start/stop scripts for such packages.

I don't think anyone would argue that the multiple start scripts are a
huge win over rc+rc.local - just for system start up.  Its everthing
else - shutdown, adding new modules, and being able to stop individual
services if needed that count.

> I ask once more: what's so special about symlinks in directories that
> makes life better?

Nothing.  Except that its a trivially easy way of making use of
individual start/stop scripts for controlled system startup.

> 	* It's acceptable to design a subsystem such that you need a
> 	  script to start it up and shut it down.

How do you stop/restart sendmail? 
Do you reboot?
Do you ps | grep; kill xyz? Every time?

Or do you have a script to simplify the above?  If yes, then you just
proved the case for the start/stop scripts.

> For large sites it's necessary that the system be simple and
> well-documented, both in terms of how the system works and in terms of
> how easy it is to do the tasks that need to be performed.  I think the
> startup systems of BSD and SVR4 both fail miserably by this measure,
> and I'd prefer if people not lock themselves into an either-or
> mentality when considering solution so this problem.

This is perhaps a valid point.  However, I think we can safely assume
that the commercial *nix vendors _are_ all locked into the SVR4 way.
So any new solution you introduce is never going to be widely used.
While that's cool for a research/toy system, it is not if you have any
plans of obtaining a decent user base.

--sjg