I agree that runlevels are problamatic. However, they do offer a
bit of nice functionality.

Last time I proposed my scheme for fixing up /etc/rc it was pretty
similar to the current proposal, with one key difference. My
equivalant of rcorder would generate a shell script that you could
give arguments to in order to have it start or shut down certain
branches of the dependency graph. You could also create nodes in
the dependency graph that did not do anything themselves, but had
other things depend on them.

So given a graph such as this:

    mount filesystems
	|
    bring up network interfaces
	|		|
    DNS server	  applications
		    |	     |
		database   httpd

You could ask the script to start everything, just start everything
up to any node (just mount the filesystems and bring up networking,
for example), stop a node and all its dependencies (say, the "empty"
applications node, which would stop the database and the httpd that
depend on it), and so on.

I think that this gives you the run-level-like ability to turn on
and off large chunks of the system, while keeping everything in
userland and avoiding many of the pitfalls and inconveniences of
runlevels.

The only other complaint I have about the proposal is that I don't
think that the individual init.d files should check /etc/rc.conf
to see if they should start something or not. When I manually type
`/etc/init.d/named start', I expect named to start regardless of
what's in /etc/rc.conf. If I want to enable named for testing, say,
but don't want it to come up when I boot, it's inconvenient to edit
/etc/rc.conf to change the setting to YES, start named, and edit
/etc/rc.conf again to turn it off.

cjs
--
Curt Sampson  <cjs@cynic.net>   917 532 4208   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org