On Friday 02 September 2005 14:58, Wouter Verhelst wrote:
> On Fri, Sep 02, 2005 at 11:45:47AM +0200, cobaco (aka Bart Cornelis)
wrote:
> > On Thursday 01 September 2005 18:26, Andrew Suffield wrote:
> > > On Thu, Sep 01, 2005 at 02:03:27PM +0200, cobaco (aka Bart Cornelis)
> > Given that changing the default does not keep our users from setting up
> > runlevels exactly how they like. I don't see how differing from the LSB
> > gains anything.
>
> I don't see how it gains us anything to move away from what we've been
> doing for ages.
if noting else it'll stop people from asking the same question (way aren't
Debian's runlevels conform the LSB) again and again. It' s popped up
regurarly without a resolution.
> > On the other hand it does make sure that a lot of non-distro specific
> > documentation matches the default situation on Debian also.
>
> What's the use of non-distro specific documentation about system
> administration anyway? If you install a Debian system, you should have
> Debian-specific documentation.
Debian uses the same init system as pretty much all other distro's, there's
lots of documentation explaining that system assuming the LSB runlevels.
> Of course, that doesn't mean all documentation has to be
> distro-specific; but if you document things that are likely to be
> different across distributions, then it makes no sense _at all_ to try
> and create documentation that is distribution-agnostic. And system
> administration is _very_ likely to be different across distributions.
> > -> I can see a dubious[1] advantage to our developers as it means less
> > work -> I _don't_ see any advantage to our users for sticking with the
> > current default while I do see a clear disadvantage as mentioned above
>
> I am not convinced that changing to predefined default runlevels is
> going to gain us anything:
> * If, as you say, they're meant to be defaults (and just that), then it
> shouldn't matter whether they're kept as is or changed. In any case,
> packages should not assume that the runlevels are as they are thought
> to be by looking at the LSB spec. This, then, would make one wonder
> why they're there at all -- there's no obvious gain for packages.
Run levels are usefull for users not packages, so naturally changing things
has no obvious gain for packages.
What good is it to the user to have several exactly identical runlevels? All
that tells me is "here's a system that's potentially usefull _if_ you as
user spend lot's of time configuring it"
The LSB way of setting up runlevels may not be the best possible, but it is
definately more usefull then the current Debian one (which doesn't do
anything at all).
> * We won't be able to change them on already running systems
> automatically: there are so many initscripts that it's very likely at
> least one will have been changed. As a result, you can't just go ahead
> and change their symlinks.
I'd wager that most normal users (as opposed to developers) have never
changed an initscript. Most init scripts are also written so you can
control them through files in /etc/default/ making it so you don't need to
change them
-> I'd actually consider it a lot more likely that most systems's
initscripts are exactly as shipped
It's not the advanced users that are changing there runlevel setup and init
scripts for who this non-conformance to the LSB matters,
It's the non-power-users that get confused and are unlikely to know that
Debian differs the LSB (and thus pretty much all init system documentation
on the web), thus making a lot of documentation and 'fix problem
X'-recipies found through google be non-working
- It shouldn't be to hard to convert a system over to LSB-runlevels if the
runlevels and initscripts haven't been changed.
- If any init-scripts /runlevels have been changed then the setup on that
system is non-default, and it's likely a fair assumption that it's setup
exactly how the sysadmin wants. Which means we don't have to (and
shouldn't) mess with it at all
This really is no different then any other default config change in Debian
were we change the config file if it hasn't been changed. In this case it's
not an actual file, but it's still default configuration.
> Since you don't know what the repercussions
> will be if you change /some/ symlinks, but not all of them, you can't
> just go ahead and change those. So if we ever implement it this way,
> we'll end up in a situation where the documentation will have to say
> things like "If you installed the system as Debian 3.2 or later, then
> you'll see <foo>. If you installed it before that time, you /might/
> see <foo>, but it's also very likely you'll see <bar>." Not only is
> that very ugly, it's also very confusing.
It's documentation referring to the default state, if you've changed the
default state that documentation can't be relied on anyway, If you haven't
changed the default state conversion shouldn't be a problem (we make
changes in that case for other configuration, I don't see how this is any
different)
-> non-issue
> * It doesn't help users either.
at the very least it makes more documentaton and troubleshooting tips apply
which is a plus.
> One assumption one can make is that if you don't want something (say,
> KDM), you don't install it. This (reasonable) assumption is true on
> Debian; it is not true on RedHat or others. Worse; if you want X (but
> don't want XDM), you can't even uninstall it even if you would like to do
> that. Also, you'll have to be taught how to disable something in a config
> file that you may or may not have heard about, and which also has the
> potential to break your entire system if you do it wrongly.
how's this relevant to Debian-default runlevels differing from LSB-default
runlevels? If anything this tells you exactly why Debian shouldnt differ
from the standard unless we have a real good reason.
> Debian has always been about 'doing it the right thing'. I don't think
> that having ugly defaults is 'the right thing'.
the LSB default is not any uglier then the current Debian one, on the
contrary: In debian the distinction between runlevels 2-5 is completely
useless (and thus confusing: why do we have these 4 runlevels if they're
the same anyhow, that just makes it more complicated).
> Having the rest of the world jump into a pit shouldn't mean that we
> should, too.
and inertia shouldn't keep differences from standards around unless there's
a real good reason.
> > > Debian is not an LSB system.
> true at the moment, LSB-compliance for the init scripts is on the TODO
> > list for etch though,
> What TODO list? Not mine at least.
The one on wiki.debian.net summarizing the threads on devel
> > and having Debian being LSB-compliance would be a boon for
> > getting corporate support for Debian (e.g. it's an explicite goal for
> > the DCC)
>
> If LSB compliance requires us to implement braindead and ugly things,
> then fuck the LSB.
it's definately not more braindead then the Debian default (which doesn't
help our users do anything, at least the LSB one may be helpfull at times).
> Defaults don't need to be useful. They need to be (a) generic and (b)
> working. That's what ours do.
How does having 4 exactly identical runlevels help our users do anything?
Making a distinction between 4 things that are exactly the same isn't
exactly my definition of 'working' even if it doesn't break anything
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgpV8HTRUbw2d.pgp
Description: PGP signature