>>What do people think about an /etc/init.d/ file, either with or
>>without run levels?

>runlevels? Just Say No. 

Why?

>Partitioning all subsystems into two, or three, distinct steps (as
>runlevels do) is not, and never will be, sufficient for all
>interdependencies.

Nor is that what it's supposed to do.  You don't go from runlevel 1, to 2,
to 3 - you stop being at 1 and go to 3.  There is no sequence, implied or
otherwise.

>I think CS theory is useful here.  The dependencies
>between modules are a directed, hopefully acyclic, graph. (With down
>and fully up, it's even a lattice.)   Runlevels are totally ordered.
>Therefore they're not a strong enough mechanism for representing
>*all* the dependencies between modules; and so (IMHO) they're not
>the right tool to manage those dependencies.

I think you're reading too much into the numbering.  The runlevel numbering
I saw was:
	1 single user
	2 multi user
	3 networked multi user
	4 unused
	5 firmware
	6 reboot

I wouldn't consider firmware "more up" than networked multiuser.

It is a problem that the startup scripts are ordered; you can do some
dependancy work in them, but it would be nice if there were a better
way.

But runlevels are not ordered, nor intended to be.  They're just distinct
states a system may be in, including information about how to leave those
states or enter them.

>I think adding a mechanism to run shutdown scripts at a sensible point
>during shutdown, before init kills user-level processes, sounds like a
>good idea.  That should also address one well-made point that came up
>in the last iteration: namely, starting up and shutting down database
>systems.

Right; and this is a good example of what runlevels are meant to do.  If
your system can be "up" or "up with the database running", it is good to
have a mechanism that will shut down correctly either way.

>To emphasise the point: yes, by all means, clean up and modularize the
>startup process. And add a clean mechanism for running a script when
>going from multi-user to single-user.  But runlevels?
>I thought we buried that one last time!

Not really.  I've seen instinctive fear of SysV, but no real complaints
directed at the way runlevels work.  (Your letter, for instance, seems to
be primarily complaining about an assumed attribute of the runlevel design
that isn't really part of it.)

-s