On Fri, Feb 24, 2006 at 02:50:34PM +0100, Michelle Konzack wrote: > Hello Tarvin, > > Am 2006-02-19 18:02:20, schrieb Digby Tarvin: > > Debian by default does not make good use (IMHO) of the runlevel mechanism. > > Oh yes, it does.
Actually I was expressing my opinion (that is what IMHO means), so you can't really correct me and say that my opinion is something else... Of course you are free to say what your opinion is... > Debian give you the freedom to configure your rcX.d HOW YOU WANT! Of course - that is what I indicated in the posting. The earlier statement referred to the default configuration (which is a characteristic of Depian), not the flexibility of the mechanism which - which is common go most Linux distros and Unix derivatives in general. I believed the default configuration (all multi user levels th e same) doesn't make good use of a facility that can define different service profiles. Nothing would be lost in defaulting to the traditional runlevel choices, if the default runlevel was the one which is equivelent to all of 2-5 currently. And it would provide extra functionality for those that don't want to define their own initially. > > It bundles all multi-user stuff into runlevel 2 and then leaves 3-5 > undefined > > It is defined like the rc2.d. Which definition are you referring to? Martin Krafft's "The Debian System" lists runlevel's 3-5 as 'unused'. Other documents list them as the same as 2. I know that Sarge installs with them all the same as 2 - but I havn't seen a 'definition' that would lead me to assume that this can safely be relied on, even if it was in any way useful.. > > The traditional usage I was familiar with was > > 2 - multi-user, no network > > No Network is stupid by default. That is rather a sweeping statement to make without any supporting justification. (and nobody said it had to be the default runlevel) I wasn't actually saying that it was what I wanted, merely the 'standard' used by other more traditional flavours of Unix. In any case, having it as a choice seemed better than having no choice at all as the default configuration. For what it is worth, I think it makes a lot of sense on a laptop which is sometimes booted in an environment where there is no network. Why sit around while your battery is used to start up NFS servers and SSH daemons that will never be used, and waiting for DNS lookups timeout, because you want to edit a file on a train? What I personally would prefer is a runlevel that includes X but no other networking for mobile non-networked use, a runlevel that is appropriate for use behind a firewall (XDMCP support, telnet etc) and one that is suitable for direct Internet connections (just SSHD, firewall and client services). > > Anyway, the infrastructure is there, and you can fix it if you > > want. I am sure there was a good reason for the change, but I > > sure as hell can't think what it would have been... > > Debian does not force users. - With Debian you have the > choice or use another Distribution if you do not agree... > > This is 100% freedom. I am 100% aware of this, but it has nothing to do with appropriatness or otherwise of the default configuration provided. The number of options on any Unix derived systems are vast, and appropriate defaults should aim to provide as much functionality as possible to the widest ranger of users as far as can be done without unreasonably compromising security - so that individual requirements can be satisfied with as few customizations required as possible. As far as I can see, the change to the default runlevel configuration in Debian removes functionality from the default configuration with no identifiable gain. > > (maybe to simplify package management for packages that involve > > additions to system startup - so they wouldn't need to ask > > about with runlevel things get added to??) > > Provide a patch! - The BTS is open for it. That last statement was speculation about a possible reason for the change to default runlevels in Debian - not a request or suggestion for a change. Or were you referring to something else? Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
