Rainer Weikusat <rainerweikusat@???> wrote:

> The abstract definition of 'runlevel' is (as far as I'm aware of it):
> "Set of processes supposed to be running".

That's what I understand it to be.

> Considering this, one can
> safely conclude that whatever 'Dennys' did, he certainly didn't to
> that. A somewhat educated guess could be "he implemented something even
> more uselessly specialized than the already overcomplicated convention
> of having 4 distinct 'sets of processes which are supposed to be
> running' during normal system operation plus maintenance, shutdown and
> reboot modes".

Indeed.
I think this is one of those things where one can (to borrow from politics) suggest "it (SysVInit style run levels) is the worst option apart from all the others" - often used to describe our democratic process.

Personally I don't see any major problem with the current system of runlevels. I agree it's not perfect, but it works and is understandable ! For the most common setups, it's fairly easy to automate which services should be running, and I have to wonder how many system actually use more than 1 (or at a pinch, 2) runlevel - I don't think any of mine use more than 1 plus single user, though I could see "graphical desktop" and "text console only" as viable alternate states for some applications. If you want a non-standard state - it's easy to manually enable or disable (start or stop) a service - either by directly executing /etc/init.d/${service} or the distro specific wrappers (eg "invoke_rc.d" or "service").

The alternative he offers seems to be to have no system of "in this state, these services should be running", so the equivalent to "telinit n" is "stop service x; stop service y; start service z; start service q" - with a suggestion that you can throw a load of commands into a script to stop/start the ones you want to go to a particular state.
That, to me, seems to be putting much the same as a runlevel into a script - only in a less maintainable manner. Eg, with SysVInit style runlevels, if we add a service that's to run in levels 3,4, 5 then we add "S" links in rc[345].d and "K" links in rc[!345].d. Instead, every script used for changing system state must be checked and edited if needed which IMO seems to be a harder job - especially if it's to be automated during package install/removal.

I suppose you could easily have a number of directories (lets call them, for example /etc/rcn.d) and into each one put a load of scripts that either enable or disable a service. Then to put the system into a particular state, you have a script that executes each script in the chosen directory which itself either enables or disables the service. Hmm, sounds vaguely familiar !