Since grml is based on Debian "unstable" I guess Etch will not affect it. Is this true? Or, will many packages will move from "experimental" to "unstable"?
My translation of Debian's strata are
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml) experimental --> might be buggy, package version conflicts abound
* Oxymorons abound: "Software packages uploaded to unstable are normally stable versions" :-) http://en.wikipedia.org/wiki/Debian
M
* Mark 27e3kk302@sneakemail.com [20070105 00:58]:
Since grml is based on Debian "unstable" I guess Etch will not affect it. Is this true?
Yes, correct.
Or, will many packages will move from "experimental" to "unstable"?
Should not be that much as Etch has been frozen and Unstable is a moving target again. ;)
My translation of Debian's strata are
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml) experimental --> might be buggy, package version conflicts abound
- Oxymorons abound: "Software packages uploaded to unstable are
normally stable versions" :-) http://en.wikipedia.org/wiki/Debian
See my mail in thread 'mixing of distributions grml - unstable - testing - sarge for notebook' to the grml mailinglist:
http://lists.mur.at/pipermail/grml/2006-October/000994.html
regards, -mika-
On Thu, Jan 04, 2007 at 04:42:16PM -0700, Mark wrote:
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml)
As a DD, I have to violently disagree with these three "translations".
Greetings Marc
Mark 27e3kk302@sneakemail.com:
As a DD, I have to violently disagree with these three "translations".
...which is one reason we use grml. Choice is good.
Choice is good. Agreed. Yet, choice does not increase the truth of your claims.
Regards, Frank
Incoming from Frank Terbeck:
Mark 27e3kk302@sneakemail.com:
DD(?):
As a DD, I have to violently disagree with these three "translations".
...which is one reason we use grml. Choice is good.
Choice is good. Agreed. Yet, choice does not increase the truth of your claims.
I agree. I thought the "buggy" characterization was reversed. Stable's the least buggy. It may be old, but that's good if you're demanding stability, which is what Debian's always been about. It's not buggy. It's had years of bug reports from thousands of users folded back into it since it was considered (at that time) testing.
I look at things like grml as terrific features on top of Debian and free software. grml's on the frontlines in the war on bugs. They're just a little bit more careful than Sid people about when they stick their heads up. They're also confident that even "unstable" Debian/Linux/FS is way usable, and can perform some pretty awesome tricks. I think that's pretty cool.
To the DD who took exception here, feh, he's just a kid who doesn't know what he's talking about. Educate him (the kid, not the DD :-).
On Fri, Jan 05, 2007 at 06:34:12PM -0700, s. keeling wrote:
I look at things like grml as terrific features on top of Debian and free software. grml's on the frontlines in the war on bugs. They're just a little bit more careful than Sid people about when they stick their heads up. They're also confident that even "unstable" Debian/Linux/FS is way usable, and can perform some pretty awesome tricks. I think that's pretty cool.
We have never claimed that sid is ready to be used by end-users. sid is a development platform and might be dangerous. We expect people running sid to be able to fix major issues that might be present themselves, there is no support. There are times (usually shortly after a release) where even I don't dare updating my sid systems.
I mainly still see grml as a live CD that is a _very_ good tool during system analysis, debugging, recovery and installation. I doubt, however, that such systems are a good solution to install on a hard disk and actually use.
Greetings Marc
* Marc Haber mh+grml@zugschlus.de [20070106 11:15]:
On Fri, Jan 05, 2007 at 06:34:12PM -0700, s. keeling wrote:
I look at things like grml as terrific features on top of Debian and free software. grml's on the frontlines in the war on bugs. They're just a little bit more careful than Sid people about when they stick their heads up. They're also confident that even "unstable" Debian/Linux/FS is way usable, and can perform some pretty awesome tricks. I think that's pretty cool.
We have never claimed that sid is ready to be used by end-users. sid is a development platform and might be dangerous. We expect people running sid to be able to fix major issues that might be present themselves, there is no support. There are times (usually shortly after a release) where even I don't dare updating my sid systems.
I'd like to add some more words. All of the following is definitely "just IMHO" and I hope that I could find the right wording. Feel free to correct me if you think I'm writing non-sense. :)
I do not agree with:
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml)
as well, I already wrote some more notes regarding stable/testing/unstable/grml in another mail:
http://lists.mur.at/pipermail/grml/2006-October/000994.html
But I do not fully acknowledge Marc's opion as well, sorry. ;)
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. 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. They want to be able to install software presented in the news, magazines, blogs,... or just the new version of already present software with the rocking new feature as fast and easy as possible. You get this with Debian unstable quite well nowadays as all of you might know. :)
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.
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 had to learn this on my own as well: once in a discussion at Security Treff Graz with several developers and once experiencing in reallife on my own when maintaining grml-robocup for the Robocup team at Technical University Graz/Austria.
And AFAICS there are companies out there that are aware of those facts. ;) For the business market think of for example Open/OS Corporate Linux (open-os.com). Talking about the end-user market think of Canonical and their Ubuntu (trying to reach the server market as well now...). There's a reason why so many people seem to use Ubuntu on their systems, I see this at university at many laptops in reallife. Those people often don't really care what's behind the Patch-Distribution Ubuntu but see the positive aspects: get up2date software with Debian's brilliant package management.
Finally just think of DD that maintain core software packages and don't even use the Debian kernel. ;) 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 mainly still see grml as a live CD that is a _very_ good tool during system analysis, debugging, recovery and installation. I doubt, however, that such systems are a good solution to install on a hard disk and actually use.
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 ;)). 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.
Some words to grml on harddisk: first of all it's just very easy to get a working Linux installation using grml2hd - just press a few times "OK" and a few minutes later you have a working system. ;)
When using grml on harddisk you get the features of Debian/unstable I meantioned above *plus* a system adjusted and pre-configured for texttool-friends *plus* all the nice and useful helper-scripts (grml-scripts, grml-vpn, grml-crypt, grml-network,...) *plus* "point-releases". grml provides an upgrade-path with each of its releases:
http://wiki.grml.org/doku.php?id=upgrading
I'm the one who is running daily updates and report all the problems I can find (including patches if possible) to the Debian BTS. This way Debian gets some quality-assurance (at least for the packages used at grml) 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.
I hope this clarifies the situation a bit. :)
regards, -mika-
Incoming from Michael Prokop:
- Marc Haber mh+grml@zugschlus.de [20070106 11:15]:
On Fri, Jan 05, 2007 at 06:34:12PM -0700, s. keeling wrote:
I look at things like grml as terrific features on top of Debian and free software. grml's on the frontlines in the war on bugs. They're just a little bit more careful than Sid people about when they stick their heads up. They're also confident that even "unstable" Debian/Linux/FS is way usable, and can perform some pretty awesome tricks. I think that's pretty cool.
We have never claimed that sid is ready to be used by end-users. sid is a development platform and might be dangerous. We expect people running sid to be able to fix major issues that might be present themselves, there is no support. There are times (usually shortly after a release) where even I don't dare updating my sid systems.
I'd like to add some more words. All of the following is definitely "just IMHO" and I hope that I could find the right wording. Feel free to correct me if you think I'm writing non-sense. :)
Great post Mika.
I do not agree with:
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml)
Nor do I. The Debian model is to produce stable with as few extant bugs possible. This is for the server market. Testing is just the next candidate for stable, once the release team signs off on it. That's also the best place for a newbie to be. Helping to test testing helps Debian produce sable.
For those more adventurous or less sensitive to potential bugs, unstable is available. Unstable is expected to be buggy; that's where new features and fixes are implemented. That said, Debian's unstable is more stable than many distros' stable release.
I mainly still see grml as a live CD that is a _very_ good tool during system analysis, debugging, recovery and installation. I doubt, however, that such systems are a good solution to install on a hard disk and actually use.
I wrote grml-debootstrap so it's getting easier to install plain Debian even on up2date hardware. Nowadays it's maybe not that
From a user's point of view, grml presents *the* best Linux packaging
system managing *the* best Linux software. Users don't care whether anyone thinks it's wise whether they use it. Users just want everything to work. Grml makes Sid usable for newbies (within reason :-).
Some words to grml on harddisk: first of all it's just very easy to get a working Linux installation using grml2hd - just press a few times "OK" and a few minutes later you have a working system. ;)
When using grml on harddisk you get the features of Debian/unstable I meantioned above *plus* a system adjusted and pre-configured for texttool-friends *plus* all the nice and useful helper-scripts (grml-scripts, grml-vpn, grml-crypt, grml-network,...) *plus* "point-releases". grml provides an upgrade-path with each of its releases:
That just *so* rocks! Even grml-small can be booting into X Window in a couple of minutes, regardless of where the root fs is.
Grml might have started out a text tool distro for experienced admins. Now, however, it's a Swiss Army Toolbox making potentially anything possible.
Oh yeah, and it's running up to date software too, with all the latest bugs no one's managed to find yet. Have fun! :-)
On Mon, Jan 08, 2007 at 06:01:31PM -0700, s. keeling wrote:
Incoming from Michael Prokop:
I do not agree with:
stable --> ancient and full of bugs, but patched testing --> less ancient, less bugs unstable --> current and basically stable* (grml)
Nor do I. The Debian model is to produce stable with as few extant bugs possible. This is for the server market. Testing is just the next candidate for stable, once the release team signs off on it.
Right, agred.
That's also the best place for a newbie to be.
I disagree with that. Testing might be broken once upon a time, and when you're not able to fix this you don not belong on Testing.
Stable is the best place for a newbie to be. There is no Debian distributions for not knowledgeable newbies who want to have the latest software.
Helping to test testing helps Debian produce sable.
Yes, but bug reports from newbies are seldomly useful. Which is no offense to the newbie; isolating and reporting bugs is a form of art.
For those more adventurous or less sensitive to potential bugs, unstable is available. Unstable is expected to be buggy; that's where new features and fixes are implemented.
Testing is expected to be buggy as well.
That said, Debian's unstable is more stable than many distros' stable release.
Disagreed here. Especially in the period right after a stable release, unstable's breakages can be horrible.
Greetings Marc
* Marc Haber mh+grml@zugschlus.de [20070113 14:15]:
On Mon, Jan 08, 2007 at 06:01:31PM -0700, s. keeling wrote:
[Debian Testing]
That's also the best place for a newbie to be.
I disagree with that. Testing might be broken once upon a time, and when you're not able to fix this you don not belong on Testing.
Especially as Debian testing does not get real security-support. :( That's not really relevant for workstations for me, but straight before a new stable release is available that's an important point - at least for me.
Stable is the best place for a newbie to be.
"If it works" (the "brand new hardware problem") and if the newbie does not need support from upstream (see my other mail for more details).
Helping to test testing helps Debian produce sable.
Yes, but bug reports from newbies are seldomly useful. Which is no offense to the newbie; isolating and reporting bugs is a form of art.
Yes, at least regarding bug reports for package maintainers. ;) But newbies can often locate problems in software because they lack developer's "business blindness" (Betriebsblindheit). At least isolating bugs is usually possible even with newbies, especially if they have support on their side (instant messaging, irc,...).
That said, Debian's unstable is more stable than many distros' stable release.
Disagreed here. Especially in the period right after a stable release, unstable's breakages can be horrible.
The package freeze for Debian etch took place a few weeks ago. The unstable pool is "moving [nearly] as usual" and I don't notice any serious problems - and don't really expect to find any when etch is out. :)
regards, -mika-
On Sun, Jan 14, 2007 at 02:03:57PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070113 14:15]:
On Mon, Jan 08, 2007 at 06:01:31PM -0700, s. keeling wrote:
[Debian Testing]
That's also the best place for a newbie to be.
I disagree with that. Testing might be broken once upon a time, and when you're not able to fix this you don not belong on Testing.
Especially as Debian testing does not get real security-support. :( That's not really relevant for workstations for me, but straight before a new stable release is available that's an important point - at least for me.
There is some kind of Security Support for Debian testing, by means of the testing security team. Unfortunately, they're missing a lot of the transparency I'd like to see from a security team, but that's nothing new for Debian. I plan to blog about this in the near future once I find the time.
Unfortunately, even stable security support has been somewhat deteriorating since the sarge release, I hate to say. Especially in the past few months, in more than one case a security fix has reached testing by means of a normal unstable maintainer upload and normal testing migration before the stable security team issued the fix for stable. In theory, stable security could be much faster than a maintainer upload since the stable security team has access to embargoed vulnerability reports, which the normal maintainer does not have. This is all quite disappointing :-(
Stable is the best place for a newbie to be.
"If it works" (the "brand new hardware problem")
Yes, Debian needs to address this.
and if the newbie does not need support from upstream (see my other mail for more details).
This is an issue, yes.
Helping to test testing helps Debian produce sable.
Yes, but bug reports from newbies are seldomly useful. Which is no offense to the newbie; isolating and reporting bugs is a form of art.
Yes, at least regarding bug reports for package maintainers. ;) But newbies can often locate problems in software because they lack developer's "business blindness" (Betriebsblindheit). At least isolating bugs is usually possible even with newbies, especially if they have support on their side (instant messaging, irc,...).
If you have a quick means of communications, things can work, but debugging via E-Mail with a newbie is a useless waste of time.
That said, Debian's unstable is more stable than many distros' stable release.
Disagreed here. Especially in the period right after a stable release, unstable's breakages can be horrible.
The package freeze for Debian etch took place a few weeks ago. The unstable pool is "moving [nearly] as usual"
NACK. We did not have any library transitions for months, and new upstream versions are being withheld.
and I don't notice any serious problems - and don't really expect to find any when etch is out. :)
I remember the PAM breakage where login to an unstable system became impossible. Without grml, I would have been in serious trouble back then.
Greetings Marc
* Marc Haber mh+grml@zugschlus.de [20070116 12:57]:
On Sun, Jan 14, 2007 at 02:03:57PM +0100, Michael Prokop wrote:
Especially as Debian testing does not get real security-support. :( That's not really relevant for workstations for me, but straight before a new stable release is available that's an important point - at least for me.
There is some kind of Security Support for Debian testing, by means of the testing security team. Unfortunately, they're missing a lot of the transparency I'd like to see from a security team, but that's nothing new for Debian. I plan to blog about this in the near future once I find the time.
Security support for testing is (AFAIK) nothing else than "we move packages from unstable to testing faster than usual". For me that's not real security-support as you can't activate just the security-testing pool but have to make use of the full testing-pool for upgrades. :-/
Unfortunately, even stable security support has been somewhat deteriorating since the sarge release, I hate to say. Especially in the past few months, in more than one case a security fix has reached testing by means of a normal unstable maintainer upload and normal testing migration before the stable security team issued the fix for stable. In theory, stable security could be much faster than a maintainer upload since the stable security team has access to embargoed vulnerability reports, which the normal maintainer does not have. This is all quite disappointing :-(
ACK
Yes, at least regarding bug reports for package maintainers. ;) But newbies can often locate problems in software because they lack developer's "business blindness" (Betriebsblindheit). At least isolating bugs is usually possible even with newbies, especially if they have support on their side (instant messaging, irc,...).
If you have a quick means of communications, things can work, but debugging via E-Mail with a newbie is a useless waste of time.
That's what I wanted to say. :)
The package freeze for Debian etch took place a few weeks ago. The unstable pool is "moving [nearly] as usual"
NACK. We did not have any library transitions for months, and new upstream versions are being withheld.
Hm, which ones are this for example?
and I don't notice any serious problems - and don't really expect to find any when etch is out. :)
I remember the PAM breakage where login to an unstable system became impossible. Without grml, I would have been in serious trouble back then.
Hehe. :) But usually the "I'm just a workstation user" users don't have to run daily upgrades and such problems should be visible through apt-listbugs then (except if you decided to take the time frame where the broken package was just uploaded of course ;)).
regards, -mika-
On Tue, Jan 16, 2007 at 01:06:46PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070116 12:57]:
On Sun, Jan 14, 2007 at 02:03:57PM +0100, Michael Prokop wrote:
Especially as Debian testing does not get real security-support. :( That's not really relevant for workstations for me, but straight before a new stable release is available that's an important point - at least for me.
There is some kind of Security Support for Debian testing, by means of the testing security team. Unfortunately, they're missing a lot of the transparency I'd like to see from a security team, but that's nothing new for Debian. I plan to blog about this in the near future once I find the time.
Security support for testing is (AFAIK) nothing else than "we move packages from unstable to testing faster than usual". For me that's not real security-support as you can't activate just the security-testing pool but have to make use of the full testing-pool for upgrades. :-/
As far as I am informed, there is a testing-security pool which just has never been used to push in a security update. I suspect that this will happen once a security update must be done for a package that cannot migrate normally from unstable to testing because of library deps.
Actually, it is one of the major "beefs" I have with testing-security that this mechanism has not yet been in use. I'd like to see it at least once before I rely on it.
NACK. We did not have any library transitions for months, and new upstream versions are being withheld.
Hm, which ones are this for example?
Newer kernels, for example, and exim4. Just look into experimental.
Greetings Marc
* Marc Haber mh+grml@zugschlus.de [20070116 14:15]:
On Tue, Jan 16, 2007 at 01:06:46PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070116 12:57]:
[...]
NACK. We did not have any library transitions for months, and new upstream versions are being withheld.
Hm, which ones are this for example?
Newer kernels,
Ok, does not really affect grml as we have our own kernels. :)
for example, and exim4. Just look into experimental.
I'm a happy postfix user and grml ships postfix so this does not affect us as well. ;)
regards, -mika-
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!".
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.
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. I don't know how good a job grml does do as a desktop running off a hard disk installation, since grml is a rescue system for me and I only use it running off CD or USB stick to fix other distributions that are installed on the hard disk.
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.
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.
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).
facts. ;) For the business market think of for example Open/OS Corporate Linux (open-os.com). Talking about the end-user market think of Canonical and their Ubuntu (trying to reach the server market as well now...). There's a reason why so many people seem to use Ubuntu on their systems, I see this at university at many laptops in reallife. Those people often don't really care what's behind the Patch-Distribution Ubuntu but see the positive aspects: get up2date software with Debian's brilliant package management.
Debian's package management is not _that_ much better than RPM on rpm-based distributions. It's the development model that is better and works better. Which is left behind by Ubuntu.
Finally just think of DD that maintain core software packages and don't even use the Debian kernel. ;)
You mean, like me?
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.
I mainly still see grml as a live CD that is a _very_ good tool during system analysis, debugging, recovery and installation. I doubt, however, that such systems are a good solution to install on a hard disk and actually use.
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.
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.
I'm the one who is running daily updates and report all the problems I can find (including patches if possible) to the Debian BTS. This way Debian gets some quality-assurance (at least for the packages used at grml)
... which Debian certainly appreciates.
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?
Greetings Marc
* Marc Haber mh+grml@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-
On Sun, Jan 14, 2007 at 01:37:02PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@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.
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).
AFAIK, the unstable installer can be used to install stable as well, which might be a way to have stable (with a backported kernel) for these people.
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.
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).
I disagree here. There is bad breakage in unstable.
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. ;)
So they are deliberately choosing a distribution that might not suit their needs best.
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.
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.
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.
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?
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.
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.
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.
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 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.
(Reminds me of the security-support within Debian testing...) :(
Yes, that's an entirely different story.
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.
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.
But, plain software developers usually have debugging and bug fixing skills, so I am inclined to call them "qualified for unstable".
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....
I see.
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.
Sure. But they're developers. They're supposed to work with development versions of Debian.
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. ;)
Indeed. And grml is a fabulous tool for doing so since its hooks into the startup process are so versatile that I am frequently using grml to install Debian on machines I have never physically seen.
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.
This is good.
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.
Greetings Marc
* 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-
On Tue, Jan 16, 2007 at 01:50:59PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070116 13:15]:
Fortunately, a lot of newbies use older hardware for Linux.
True for workstations, but IMO not true for notebooks.
Using Linux on a notebook is "hohe Schule". Not a good idea for a newbie.
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.
I have.
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).
We agree that the sarge release did take _TOO_ much time.
Greetings Marc
* Marc Haber mh+grml@zugschlus.de [20070116 15:09]:
On Tue, Jan 16, 2007 at 01:50:59PM +0100, Michael Prokop wrote:
- Marc Haber mh+grml@zugschlus.de [20070116 13:15]:
Fortunately, a lot of newbies use older hardware for Linux.
True for workstations, but IMO not true for notebooks.
Using Linux on a notebook is "hohe Schule". Not a good idea for a newbie.
Yupp, but notebooks are getting much more common as they aren't that expensive anymore (compared to just a few years ago). That's a trend distributions have to be aware of if they want to stay in the enduser market IMO.
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).
We agree that the sarge release did take _TOO_ much time.
Sure, but that's something a user cannot control.
regards, -mika-
s. keeling wrote:
To the DD who took exception here, feh, he's just a kid who doesn't know what he's talking about. Educate him (the kid, not the DD :-).
I totally disagree with your last paragraph. Marc Haber is right and not a kid. He knows exactly what he is talking about - especially concerning debian.
I agree with the statement that choice is good and everything has its advantages or disadvantages depending in the case it is used for. Talking about debian I think the debian policy and their description of stable, testing, unstable and experimental is right. You personally may disagree, but stable (in my eyes) is rock solid. You can use it on a variety of platforms and it works. Testing and unstable can be very unstable but don't need to.
Using grml the world may look somewhat different to the debian world as grml is for texttool users and geeks. It's been tested very hard, uses only one platform (i386 at the moment) and has a reduced number of packages (no KDE, gnome etc.) and therefore it is easier to maintain stable and uptodate.
eModul
* eModul emodul@gmx.net [20070106 21:55]:
s. keeling wrote:
To the DD who took exception here, feh, he's just a kid who doesn't know what he's talking about. Educate him (the kid, not the DD :-).
^^^^^^^^^^^^^^^^^^^
I totally disagree with your last paragraph. Marc Haber is right and not a kid. He knows exactly what he is talking about - especially concerning debian.
[...]
AFAICS s. keeling explicitly does *not* mean Marc Haber with "he's just a kid".
regards, -mika-
Incoming from Michael Prokop:
- eModul emodul@gmx.net [20070106 21:55]:
s. keeling wrote:
To the DD who took exception here, feh, he's just a kid who doesn't know what he's talking about. Educate him (the kid, not the DD :-).
^^^^^^^^^^^^^^^^^^^I totally disagree with your last paragraph. Marc Haber is right and not a kid. He knows exactly what he is talking about - especially concerning debian.
[...]
AFAICS s. keeling explicitly does *not* mean Marc Haber with "he's just a kid".
Ah, thanks Mika. Now I see what happened. I was wondering what it was I'd done. Poor wording on my part, sorry.
s. keeling wrote:
Incoming from Michael Prokop:
[...]
AFAICS s. keeling explicitly does *not* mean Marc Haber with "he's just a kid".
Ah, thanks Mika. Now I see what happened. I was wondering what it was I'd done. Poor wording on my part, sorry.
Ouch, I didn't realise how you meant it. Thanks for the clarification. Now it makes sense.
greets
eModul
Mark 27e3kk302@sneakemail.com:
...which is one reason we use grml. Choice is good.
Choice is good. Agreed. Yet, choice does not increase the truth of your claims.
Choice dissolves flame-wars over Truth. I go my deluded way.
If that way works for you, it is fine. But you cannot expect a claim, as provocative as yours, to go unanswered. Especially not, because others might pick it up and consider it to be correct, because nobody objected.
Regards, Frank
Teilnehmer (6)
-
eModul -
Frank Terbeck -
Marc Haber -
Mark -
Michael Prokop -
s. keeling