* Marc Haber mh+grml@zugschlus.de [20070116 13:15]:
On Sun, Jan 14, 2007 at 01:37:02PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070113 14:15]:
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.
If we continue with installer releases like we currently do. I think we need to offer backported installers, or at least a stable installer with a current kernel (and of course less support).
ACK
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.
Fortunately, a lot of newbies use older hardware for Linux.
True for workstations, but IMO not true for notebooks.
Yes, but the "latest breakage" isn't on a high level nowadays IMO.
It can be on very low levels during some stages of the release process, such as right after a stable release when everybody puts the lastest developments into unstable.
Yes, but that's something that can be communicated to newbies too (or they experience it on their own and hopefully learn from that ;)).
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
These are the most trivial problems that are trivially fixed.
Jepp, but they are the most common ones too.
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.
How does the user do this when she cannot log in to her primary computer?
*I* for example have never ever experienced something like that. Of course that's a worst case where more experienced users have to help the newbie to fix such a breakage.
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.
While this is for example understandable for exim 3, which has been obsoleted upstream by exim 4 some five years ago, this is ridiculous for some KDE apps which do not get upstream support because it is four weeks old.
Just think of the big KDE version steps between woody (2.2.2) and sarge (3.3.2).
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.
The next step for the user might be to use VMware or a chroot to reproduce the bug with a current version there. Or to try a backport of the unstable package to stable.
I wouldn't call a user that uses VMware on Linux or has a running and working chroot system a newbie, sorry. :)
Btw, these methods are _great_ to learn about Debian and Unix in general and help in accumulating the skills necessary to run Debian testing or unstable.
FullACK
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.
Yes, but that's a misled reason. Upgrading a productive system to an unreleased development version just because joe random developer does not care about what he released four weeks ago is a bad idea.
I don't mean a time frame of just four weeks, again - just think of KDE in woody vs. KDE in sarge.
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".
Not communicating clearly enough is a classical problem within Debian.
While Ubuntu does bad things to Debian (for example by keeping peopleh holding key positions in Debian from doing their work), it also does some good things, for example taking the most clueless of newbies away.
ACK
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.
Why? If set up properly, you wouldn't even notice. In the chroot, you can do anything you see fit without endangering your primary vehicle of work.
ACK, but I just think that it's not common practice. (Feel free to correct me. ;))
But, plain software developers usually have debugging and bug fixing skills, so I am inclined to call them "qualified for unstable".
Jepp, that's why they usually use unstable. ;)
[...]
Packages not originally deriving from grml itself can be found in the Debian/unstable pool - as usual (=> debsecan).
This is not good. Reasons: There are no security advisories for Debian unstable, and a security-fixed package version might depend on other libraries. So, grml users are basically forced to track Debian unstable and get unstable's breakage. Which, unfortunately, kind of proves my point that grml's stability is only guaranteed in a short time frame after a grml release.
'debsecan --suite sid' works fine for me.
regards, -mika-