Re: runlevels remodeled
On Fri, 12 Aug 2005, Javier Fernández-Sanguino Peña wrote:
On Fri, Aug 12, 2005 at 09:52:38AM -0500, John Hasler wrote:
Timo Aaltonen writes:
Is there will to change the current policy regarding runlevels in Debian?
I'd propose to use the recommendation made by LSB:
Please check the archives. This has been discussed many times. It is
clear that there is going to be no change.
The last sentence is not true. For some of the compelling reasons as to
why this should change please review the last time we discussed this 
(when I brought the issue up in my TODO stuff for etch ).
Hmm, just proves that I can't do a proper search ;) Somehow I've missed
those threads, but have read them now.
To break my proposal into two separate pieces, we have:
1) moving unnecessary stuff out of rcS.d
Seems to have gotten support from developers. Some disagreement whether
NFS-mounts should or should not be done here. I'd say that without network
you get no mounts, either ;) Those special installations that have /usr as
a NFS-mount shouldn't need anything from there. Besides, automount is
banned here so it's not an option.
Should there be a separate discussion as to what to move away?
2) define more out-of-the-box runlevels
This has been discussed before as pointed out. Some say that current
situation is a feature, and others would like to see Debian take a similar
scheme as other distributions. I think it is a moot point to say that
having more multi-user runlevels confuses users, because ordinary users
should never run into a situation where those are really needed. For
sysadmins the change is a needed one. DIY-philosophy should actually be
left to those who really want to customize their runlevels 2-5 =) Then
those who like the proposal and those who have to bear with mixed
environments can have their's left as default.
Here's my short summary of some situations where those different runlevels
1 single-user, no network, only rootfs (or all local fs's?) mounted
2 multi-user, no network services exported, no NFS
-more secure service-wise than 3
-RH has network here, although they claim that 2 is not used
3 full multi-user
-direct boot without X is useful if X breaks the console for some reason,
more comfortable to work with than 1
4 as 3 but reserved for local use
5 full multi-user + X
-goes hand in hand with 3
I don't understand why the next-gen init would have problems with a setup
like this.. If it uses dependencies, supporting a scheme like this
shouldn't be a problem, no?
As with anything in Debian, it really depends on how much muscle is put
_______________/Timo Aaltonen <http://users.tkk.fi/~tjaalton>
Work: HUT/CC, GSM +358-50-5918781 (work) / +358-40-5549618 (personal)