* Marc Haber <[EMAIL PROTECTED]> [20070116 13:15]: > On Sun, Jan 14, 2007 at 01:37:02PM +0100, Michael Prokop wrote: > > * Marc Haber <[EMAIL PROTECTED]> [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- -- 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
pgpDSyFCDTqWD.pgp
Description: PGP signature
_______________________________________________ Grml mailing list - [email protected] http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
