[Grml] Re: Debian Etch and grml

[Michael Prokop]

* Marc Haber <mh+grml at zugschlus.de> [20070113 14:15]:
> On Mon, Jan 08, 2007 at 11:17:18PM +0100, Michael Prokop wrote:
> > I'm of course aware of 'We have never claimed that sid is ready to
> > be used by end-users' - but I think reality shows something else in
> > common practice.

> It's always the same problem during our release cycle: After a
> release, many people use stable. Stable gets old, while sid goes
> throught the usual heavy development phase where things sometimes go
> badly wrong. While stable gets stale, sid's breakages get less and
> less, while end users migrate from sta(b)le to sid because they want
> later software (or get misled by media reporting that apt pinning is
> going to get them the advantages of stable and sid together while in
> reality they only get the disadvantages of both combined). These
> migrations are supported by third parties saying "use sid, it's
> stable!".

ACK

But: about half a year before and >=half a year after the release,
stable might not even boot and therefore d-i won't be able to
install Debian at all. People usually don't buy hardware according
to Debian stable release cycles. ;) Therefore stable won't work for
people with brand new hardware besides a narrow time-frame of the
new release.

> Then, some late breakage occurs in sid. And thousands of end-users are
> unable to fix this breakage. Bad. Do not use Debian sid or even Debian
> testing if you are not able to fix any system breakage yourself.

ACK

But: IMO today unstable isn't the unstable you were used to get a
few years ago. A few years ago unstable was broken on a regular
base.  Nowadays unstable is even less broken than the update
(procedures) of some so called "stable distributions" (count M$
Windows as well). I suspect it's mainly because stable has its
market on the servers and unstable has its market on the
workstations (the ones without commercial support).

> >   Debian/stable is really fine for servers, but sometimes does not fit
> >   as Desktop operating system very well.

> > Why? People often want up2date software. The stuff with all the
> > "hot, rocking, bleeding edge, hot off the press" features.

> If they are technically knowledgeable, they can go ahead with Debian
> sid or Debian testing, helping development by reporting and even
> fixing bugs. If they are not technically knowledgeable, they are
> better off with a distribution geared for the Desktop such as Ubuntu
> or OpenSUSE.

People considering Debian as their main operating system often have
a reason why they chose Debian and not Ubuntu or OpenSuSE. ;)

> >  You get this with Debian unstable quite well nowadays as all of you
> >  might know. :)

> Yes, but you also get the latest breakage. Which you might not be able
> to fix if you don't know your way around a broken Linux system very
> well.

Yes, but the "latest breakage" isn't on a high level nowadays IMO.

Most problems of upgrading an unstable system can be fixed with the
two notices mentioned in section "Common Debian unstable problems"
of http://wiki.grml.org/doku.php?id=upgrading

If the user has problems with a special package and knows about
http://bugs.debian.org/$PACKAGENAME he usually finds a detailed
bugreport (often including a workaround) as well.


An important point I forgot to mention is the user-support:

A KDE developer (who uses grml as base system, hello Kevin :)) I was
talking to reminded me of the issue "support for newbies".  Upstream
developers and supporters of software usually don't provide support
for ancient software versions. If a newbie asks for help on the
upstream mailinglist a typical reaction is "please update the
software, version $NUMBER fixes $ISSUE_#1, $ISSUE_#2 and provides
the feature you are asking for", or "not sure if this also works on
x.y, using x.y+2 here". Bugreports for older software versions might
not be accepted or are answered with "please reproduce with current
version". So the next step for the user might be to upgrade his
stable system to testing (bad choice) or unstable. Now the user can
get support from upstream. (JFTR: I'm talking about end-user support
of course, not package maintainence support!) So IMO that's another
reason why unstable is so common on workstations.

> > If you have recent/up2date hardware Debian/stable might be quite a
> > problem.  Think of Xorg and its drivers and the Linux kernel. 2.6.18
> > already has knowadays(!) some problems with brand new chipsets and
> > controllers. In about half a year d-i of Etch with its 2.6.18 might
> > encounter serious problems on brand new hardware - especially on
> > laptops.

> I have heard that Debian plans to issue (unofficial) stable intaller
> releases with later kernels.

That's good, but this should have happened before Ubuntu reached the
market. ;) But unofficial usually means "nobody except developers
and people who know how they might fix the problem anyway will find
the ISOs". (Reminds me of the security-support within Debian
testing...) :(

> > Oh, and even developers (I do not mean DDs only here!) have the need
> > for recent software: compiler versions, libraries,... - stuff you
> > just might not get with Debian/stable.

> I have done development quite successfully in chroots, and developers
> are usually able to fix breakages (and thus qualify for sid).

You are talking about developer like in "debian developer" for your
chroot actions, right?  I'm talking about "plain" *software*
developers. They usually don't want to do their daily business
inside a chroot. So they are using sid on their workstation - that's
what I was talking about. :)

> > Finally just think of DD that maintain core software packages and
> > don't even use the Debian kernel. ;)

> You mean, like me?

Well, you might count yourself ;) but I was trying to point into the
direction of udev....

> >  Just think of all the developers that use unstable on their system in
> >  all day practice and have just a chroot-system of stable laying
> >  around. How many DDs do work in a Debian/stable environment really
> >  all day long?

> I used to do this until June 2003, where a change of workplace made me
> install a new workstation. I used unstable there for the first time.

But how many DDs use stable as their main platform to work with the
packages they maintain *nowadays*? I'm not aware of any official
stats but I'm sure most of them don't use stable as their main
working system.

> > I wrote grml-debootstrap so it's getting easier to install plain
> > Debian even on up2date hardware. Nowadays it's maybe not that
> > relevant as a new stable release is coming soon (though I install
> > all servers using grml-debootstrap anyway ;)).

> I use grml to install a tarball containing a Debian system on my
> servers. I rarely use the Debian installation methods.

Ok, the method itself isn't that important as you get an up2date
kernel with grml which lets you boot the system for further actions. ;)

> >  But this probably will become more important as soon as Debian etch
> >  is released and 2.6.18 is ancient enough so d-i of Debian etch maybe
> >  does not boot at all. Then you might use an up2date grml live-cd for
> >  installing a plain Debian using grml-debootstrap.

> Which is a rather interesting application.

ACK :)

> >  and grml-users on the other side don't have to run "daily" updates to
> >  be sure to be able to follow the Debian/unstable pool. They can wait
> >  ~2-3 month until a new grml release is available and be sure that the
> >  upgrade works quite well then.

> How are security issues in packages available with grml handled?

Package updates deriving from grml itself are uploaded to
grml-stable pool. Packages not originally deriving from grml itself
can be found in the Debian/unstable pool - as usual (=> debsecan).

regards,
-mika-
-- 
 http://grml.org/            # Linux for texttool-users and sysadmins
 http://wiki.grml.org/       # share your knowledge
 http://grml.supersized.org/ # the grml development weblog
 #grml @ irc.freenode.org    # meet us on irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://ml.grml.org/pipermail/grml/attachments/20070114/a54c51d4/attachment-0004.pgp>