* starting with 2.7 @ 2005-01-02 20:03 Maciej Soltysiak 2005-01-02 20:08 ` Emmanuel Fleury ` (2 more replies) 0 siblings, 3 replies; 222+ messages in thread From: Maciej Soltysiak @ 2005-01-02 20:03 UTC (permalink / raw) To: linux-kernel Hi, I was wondering in the tram today are we close to branching off to 2.7 Do the mighty kernel developers have solid plans, ideas, etc to start experimental code Regards, Maciej ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 20:03 starting with 2.7 Maciej Soltysiak @ 2005-01-02 20:08 ` Emmanuel Fleury 2005-01-02 20:36 ` William Lee Irwin III 2005-01-06 20:02 ` John Richard Moser 2 siblings, 0 replies; 222+ messages in thread From: Emmanuel Fleury @ 2005-01-02 20:08 UTC (permalink / raw) To: Maciej Soltysiak, linux-kernel Maciej Soltysiak wrote: > Hi, > > I was wondering in the tram today are we close to branching > off to 2.7 > > Do the mighty kernel developers have solid plans, ideas, etc > to start experimental code You should read this: http://kerneltrap.org/node/3513 And this: http://kerneltrap.org/node/3522 Regards -- Emmanuel Fleury Computer Science Department, | Office: B1-201 Aalborg University, | Phone: +45 96 35 72 23 Fredriks Bajersvej 7E, | Fax: +45 98 15 98 89 9220 Aalborg East, Denmark | Email: fleury@cs.aau.dk ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 20:03 starting with 2.7 Maciej Soltysiak 2005-01-02 20:08 ` Emmanuel Fleury @ 2005-01-02 20:36 ` William Lee Irwin III 2005-01-02 21:01 ` Re[2]: " Maciej Soltysiak 2005-01-02 21:24 ` Andries Brouwer 2005-01-06 20:02 ` John Richard Moser 2 siblings, 2 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-02 20:36 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: linux-kernel On Sun, Jan 02, 2005 at 09:03:32PM +0100, Maciej Soltysiak wrote: > I was wondering in the tram today are we close to branching > off to 2.7 > Do the mighty kernel developers have solid plans, ideas, etc > to start experimental code I have a plan to never ever stop experimental code, which is to actually move on the 2.6.x.y strategy if no one else does and these kinds of complaints remain persistent and become more widespread. There is a standard. Breaking things and hoping someone cleans up later doesn't work. So it has to be stable all the time anyway, and this is one of the observations upon which the "2.6 forever" theme is based. Frozen "minimal fix trees" for the benefit of those terrified of new working code (or alternatively, the astoundingly risk-averse) are a relatively straightforward theme, which kernel maintainers should be fully able to faithfully develop. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re[2]: starting with 2.7 2005-01-02 20:36 ` William Lee Irwin III @ 2005-01-02 21:01 ` Maciej Soltysiak 2005-01-02 21:24 ` Andries Brouwer 1 sibling, 0 replies; 222+ messages in thread From: Maciej Soltysiak @ 2005-01-02 21:01 UTC (permalink / raw) To: linux-kernel Hello William, Sunday, January 2, 2005, 9:36:15 PM, you wrote: > I have a plan to never ever stop experimental code, which is to > actually move on the 2.6.x.y strategy if no one else does and these > kinds of complaints remain persistent and become more widespread. Well, personally I like the 2.6.x.y idea. > There is a standard. Breaking things and hoping someone cleans up > later doesn't work. So it has to be stable all the time anyway, and > this is one of the observations upon which the "2.6 forever" theme is > based. Hm, now that I think about it, it has an advantage. eg. No problems for other people with maintaining code for 2.4, 2.5, 2.6, ... Anyway, starting with other trees like 2.7 sends a signal to people, that something huge is going to happen. Like totally new ideas that require to change the APIs, rewrite all the drivers (I know nobody likes that, really) etc... I was asking If something like this is about to happen. Is a stockpile of things like this building up? -- Maciej ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 20:36 ` William Lee Irwin III 2005-01-02 21:01 ` Re[2]: " Maciej Soltysiak @ 2005-01-02 21:24 ` Andries Brouwer 2005-01-02 21:42 ` William Lee Irwin III 2005-01-03 15:18 ` Rik van Riel 1 sibling, 2 replies; 222+ messages in thread From: Andries Brouwer @ 2005-01-02 21:24 UTC (permalink / raw) To: William Lee Irwin III; +Cc: Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 12:36:15PM -0800, William Lee Irwin III wrote: > There is a standard. Breaking things and hoping someone cleans up > later doesn't work. So it has to be stable all the time anyway, and > this is one of the observations upon which the "2.6 forever" theme is > based. You are an optimist. I think reality is different. You change some stuff. The bad mistakes are discovered very soon. Some subtler things or some things that occur only in special configurations or under special conditions or just with very low probability may not be noticed until much later. So, your changes have a wake behind them that is wide the first few days and becomes thinner and thinner over time. Nontrivial changes may have bugs discovered after two or three years. If a kernel is set apart and called "stable", then it is not, but it will become more and more stable over time, until after two or three years only very few unknown problems are encountered. If you come with a new kernel every month, then you get the stability that the "stable" kernel has after less than a month, which is not particularly stable. Andries ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 21:24 ` Andries Brouwer @ 2005-01-02 21:42 ` William Lee Irwin III 2005-01-02 22:15 ` Adrian Bunk 2005-01-03 15:18 ` Rik van Riel 1 sibling, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-02 21:42 UTC (permalink / raw) To: Andries Brouwer; +Cc: Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 10:24:27PM +0100, Andries Brouwer wrote: > You are an optimist. I think reality is different. > You change some stuff. The bad mistakes are discovered very soon. > Some subtler things or some things that occur only in special > configurations or under special conditions or just with > very low probability may not be noticed until much later. > So, your changes have a wake behind them that is wide the first > few days and becomes thinner and thinner over time. Nontrivial > changes may have bugs discovered after two or three years. > If a kernel is set apart and called "stable", then it is not, > but it will become more and more stable over time, until after > two or three years only very few unknown problems are encountered. > If you come with a new kernel every month, then you get > the stability that the "stable" kernel has after less than a month, > which is not particularly stable. This is not optimism. This is experience. Every ``stable'' kernel I've seen is a pile of incredibly stale code where vi'ing any file in it instantly reveals numerous months or years old bugs fixed upstream. What is gained in terms of reducing the risk of regressions is more than lost by the loss of critical examination and by a long longshot. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 21:42 ` William Lee Irwin III @ 2005-01-02 22:15 ` Adrian Bunk 2005-01-02 22:49 ` Bill Davidsen ` (4 more replies) 0 siblings, 5 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-02 22:15 UTC (permalink / raw) To: William Lee Irwin III; +Cc: Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: > > This is not optimism. This is experience. Every ``stable'' kernel I've > seen is a pile of incredibly stale code where vi'ing any file in it > instantly reveals numerous months or years old bugs fixed upstream. > What is gained in terms of reducing the risk of regressions is more > than lost by the loss of critical examination and by a long longshot. The main advantage with stable kernels in the good old days (tm) when 4 and 6 were even numbers was that you knew if something didn't work, and upgrading to a new kernel inside this stable kernel series had a relatively low risk of new breakages. This meant one big migration every few years and relatively easy upgrades between stable series kernels. Nowadays in 2.6, every new 2.6 kernel has several regressions compared to the previous one, and additionally obsolete but used code like ipchains and devfs is scheduled for removal making upgrades even harder for many users. There's the point that most users should use distribution kernels, but consider e.g. that there are poor souls with new hardware not supported by the 3 years old 2.4.18 kernel in the stable part of your Debian distribution. > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:15 ` Adrian Bunk @ 2005-01-02 22:49 ` Bill Davidsen 2005-01-02 23:14 ` Jesper Juhl 2005-01-03 0:30 ` William Lee Irwin III 2005-01-02 23:14 ` Diego Calleja ` (3 subsequent siblings) 4 siblings, 2 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-02 22:49 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel Adrian Bunk wrote: > On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: > >>This is not optimism. This is experience. Every ``stable'' kernel I've >>seen is a pile of incredibly stale code where vi'ing any file in it >>instantly reveals numerous months or years old bugs fixed upstream. >>What is gained in terms of reducing the risk of regressions is more >>than lost by the loss of critical examination and by a long longshot. > > > The main advantage with stable kernels in the good old days (tm) when 4 > and 6 were even numbers was that you knew if something didn't work, and > upgrading to a new kernel inside this stable kernel series had a > relatively low risk of new breakages. This meant one big migration every > few years and relatively easy upgrades between stable series kernels. > > Nowadays in 2.6, every new 2.6 kernel has several regressions compared > to the previous one, and additionally obsolete but used code like > ipchains and devfs is scheduled for removal making upgrades even harder > for many users. And there you have my largest complaint with the new model. If 2.6 is stable, it should not have existing features removed just because someone has a new wet dream about a better but incompatible way to do things. I expect working programs to be deliberately broken in a development tree, but once existing features are removed there simply is no stable set of features. > > There's the point that most users should use distribution kernels, but > consider e.g. that there are poor souls with new hardware not supported > by the 3 years old 2.4.18 kernel in the stable part of your Debian > distribution. The stable and development kernel model worked for a decade, partly because people could build on a feature set and not have that feature just go away, leaving the choice of running without fixes or not running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?) I don't see why the definition of "stable" can't simply mean "no deletions from the feature set" and let new features come in for those who want them. Absent that 2.4 will be the last stable kernel, in the sense that features won't be deliberately broken or removed. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:49 ` Bill Davidsen @ 2005-01-02 23:14 ` Jesper Juhl 2005-01-03 0:30 ` William Lee Irwin III 1 sibling, 0 replies; 222+ messages in thread From: Jesper Juhl @ 2005-01-02 23:14 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, 2 Jan 2005, Bill Davidsen wrote: > Adrian Bunk wrote: > > On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: > > > > > This is not optimism. This is experience. Every ``stable'' kernel I've > > > seen is a pile of incredibly stale code where vi'ing any file in it > > > instantly reveals numerous months or years old bugs fixed upstream. > > > What is gained in terms of reducing the risk of regressions is more > > > than lost by the loss of critical examination and by a long longshot. > > > > > > The main advantage with stable kernels in the good old days (tm) when 4 and > > 6 were even numbers was that you knew if something didn't work, and > > upgrading to a new kernel inside this stable kernel series had a relatively > > low risk of new breakages. This meant one big migration every few years and > > relatively easy upgrades between stable series kernels. > > > > Nowadays in 2.6, every new 2.6 kernel has several regressions compared to > > the previous one, and additionally obsolete but used code like ipchains and > > devfs is scheduled for removal making upgrades even harder for many users. > > And there you have my largest complaint with the new model. If 2.6 is stable, > it should not have existing features removed just because someone has a new > wet dream about a better but incompatible way to do things. I expect working > programs to be deliberately broken in a development tree, but once existing > features are removed there simply is no stable set of features. > > > > There's the point that most users should use distribution kernels, but > > consider e.g. that there are poor souls with new hardware not supported by > > the 3 years old 2.4.18 kernel in the stable part of your Debian > > distribution. > > The stable and development kernel model worked for a decade, partly because > people could build on a feature set and not have that feature just go away, > leaving the choice of running without fixes or not running. Since we manage to > support 2.2 and 2.4 (and perhaps even 2.0?) I don't see why the definition of > "stable" can't simply mean "no deletions from the feature set" and let new > features come in for those who want them. Absent that 2.4 will be the last > stable kernel, in the sense that features won't be deliberately broken or > removed. > The new model has some good aspects to it, mainly that new fixes and features make it into the "stable" kernel a lot faster these days. But, it is not as stable/static as previous stable series. Personally I think a lot of the problems could go away if the -mm tree was utilized more. How does something like this sound? 2.6.x being stable means that : a) features are not removed b) patches applied to 2.6 have spend a minimum of time in -mm first (one -mm release minimum? -mm release frequency would probably need to go up a bit) c) interfaces do not change unless to fix a serious bug That would make it a stable series in my book. Development can still be rapid since -mm would be open to all the experimental stuff, and features could be removed in -mm etc. If *all* patches go through -mm (critical security fixes possibly being the excetion) before ending up in mainline, then -mm won't get out of sync with mainline with regard to bugfixes - main differences would be new experimental stuff and removed features. When should 2.7 open then? Well, probably when -mm has diverged so much that it becomes a pain to maintain against 2.6 mainline, then it could be renamed 2.7.0 and work could start on stabilizing all the experimental stuff in it etc. Does that sound completely insane or as something that could work? I think it's not so far from what we have now. -- Jesper Juhl ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:49 ` Bill Davidsen 2005-01-02 23:14 ` Jesper Juhl @ 2005-01-03 0:30 ` William Lee Irwin III 2005-01-03 0:45 ` Adrian Bunk 2005-01-03 15:52 ` Alan Cox 1 sibling, 2 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 0:30 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel Adrian Bunk wrote: >> The main advantage with stable kernels in the good old days (tm) when 4 >> and 6 were even numbers was that you knew if something didn't work, and >> upgrading to a new kernel inside this stable kernel series had a >> relatively low risk of new breakages. This meant one big migration every >> few years and relatively easy upgrades between stable series kernels. >> Nowadays in 2.6, every new 2.6 kernel has several regressions compared >> to the previous one, and additionally obsolete but used code like >> ipchains and devfs is scheduled for removal making upgrades even harder >> for many users. On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: > And there you have my largest complaint with the new model. If 2.6 is > stable, it should not have existing features removed just because > someone has a new wet dream about a better but incompatible way to do > things. I expect working programs to be deliberately broken in a > development tree, but once existing features are removed there simply is > no stable set of features. The presumption is that these changes are frivolous. This is false. The removals of these features are motivated by their unsoundness, and those removals resolve real problems. If they did not do so, they would not pass peer review. Adrian Bunk wrote: >> There's the point that most users should use distribution kernels, but >> consider e.g. that there are poor souls with new hardware not supported >> by the 3 years old 2.4.18 kernel in the stable part of your Debian >> distribution. On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: > The stable and development kernel model worked for a decade, partly > because people could build on a feature set and not have that feature > just go away, leaving the choice of running without fixes or not > running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?) > I don't see why the definition of "stable" can't simply mean "no > deletions from the feature set" and let new features come in for those > who want them. Absent that 2.4 will be the last stable kernel, in the > sense that features won't be deliberately broken or removed. I can't speak for anyone during the times of more ancient Linux history; however, developers' dissatisfaction with the development model has been aired numerous times in certain fora. It has not satisfactorily served developers or users. Users are locked into distro kernels for incompatible extensions, and developers are torn between multiple codebases. This fragmentation of programmer effort is trivially recognizable as counterproductive. A single focal point for programmer effort is far superior for a development model. If the standard of stability is not passed then the code is not ready to be included in any kernel. Then the distinction is lost, and each of the fragmented codebases gets a third-class effort, and a spurious expenditure of effort is wasted on porting fixes and features across numerous different codebases. Your estimate of the impact of the feature set upon applications is also somewhat exaggerated. The system call ABI has remained backward compatible for extended periods of time covering major releases. In fact, it would be my personal preference for the next major release to signify nothing more than a system call ABI change involving the purging of several older, deprecated system call conventions. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:30 ` William Lee Irwin III @ 2005-01-03 0:45 ` Adrian Bunk 2005-01-03 1:19 ` William Lee Irwin III 2005-01-03 12:52 ` Bill Davidsen 2005-01-03 15:52 ` Alan Cox 1 sibling, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 0:45 UTC (permalink / raw) To: William Lee Irwin III Cc: Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: > Adrian Bunk wrote: > >> The main advantage with stable kernels in the good old days (tm) when 4 > >> and 6 were even numbers was that you knew if something didn't work, and > >> upgrading to a new kernel inside this stable kernel series had a > >> relatively low risk of new breakages. This meant one big migration every > >> few years and relatively easy upgrades between stable series kernels. > >> Nowadays in 2.6, every new 2.6 kernel has several regressions compared > >> to the previous one, and additionally obsolete but used code like > >> ipchains and devfs is scheduled for removal making upgrades even harder > >> for many users. > > On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: > > And there you have my largest complaint with the new model. If 2.6 is > > stable, it should not have existing features removed just because > > someone has a new wet dream about a better but incompatible way to do > > things. I expect working programs to be deliberately broken in a > > development tree, but once existing features are removed there simply is > > no stable set of features. > > The presumption is that these changes are frivolous. This is false. > The removals of these features are motivated by their unsoundness, > and those removals resolve real problems. If they did not do so, they > would not pass peer review. The netfilter people plan to remove ipfwadm and ipchains before 2.6.11 . This is legacy code that makes their development sometimes a bit harder, but AFAIK ipchains in 2.6.10 doesn't suffer from any serious real problems. > Adrian Bunk wrote: > >> There's the point that most users should use distribution kernels, but > >> consider e.g. that there are poor souls with new hardware not supported > >> by the 3 years old 2.4.18 kernel in the stable part of your Debian > >> distribution. > > On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: > > The stable and development kernel model worked for a decade, partly > > because people could build on a feature set and not have that feature > > just go away, leaving the choice of running without fixes or not > > running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?) > > I don't see why the definition of "stable" can't simply mean "no > > deletions from the feature set" and let new features come in for those > > who want them. Absent that 2.4 will be the last stable kernel, in the > > sense that features won't be deliberately broken or removed. > > I can't speak for anyone during the times of more ancient Linux history; > however, developers' dissatisfaction with the development model has been > aired numerous times in certain fora. It has not satisfactorily served > developers or users. Users are locked into distro kernels for > incompatible extensions, and developers are torn between multiple > codebases. At least on Debian, ftp.kernel.org kernels work fine. > This fragmentation of programmer effort is trivially recognizable as > counterproductive. A single focal point for programmer effort is far > superior for a development model. If the standard of stability is not > passed then the code is not ready to be included in any kernel. Then > the distinction is lost, and each of the fragmented codebases gets a > third-class effort, and a spurious expenditure of effort is wasted on > porting fixes and features across numerous different codebases. >... My impression is that currently 2.4 doesn't take that much time of developers (except for Marcelo's), and that it's a quite usable and stable kernel. > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:45 ` Adrian Bunk @ 2005-01-03 1:19 ` William Lee Irwin III 2005-01-03 5:33 ` Willy Tarreau 2005-01-03 12:52 ` Bill Davidsen 1 sibling, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 1:19 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: >> The presumption is that these changes are frivolous. This is false. >> The removals of these features are motivated by their unsoundness, >> and those removals resolve real problems. If they did not do so, they >> would not pass peer review. On Mon, Jan 03, 2005 at 01:45:51AM +0100, Adrian Bunk wrote: > The netfilter people plan to remove ipfwadm and ipchains before 2.6.11 . > This is legacy code that makes their development sometimes a bit harder, > but AFAIK ipchains in 2.6.10 doesn't suffer from any serious real > problems. They're superseded by iptables and their sole uses are by the Linux- specific applications to manipulate this privileged aspect of system state. This makes a much weaker case for backward compatibility than general nonprivileged standardized system calls. On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: >> I can't speak for anyone during the times of more ancient Linux history; >> however, developers' dissatisfaction with the development model has been >> aired numerous times in certain fora. It has not satisfactorily served >> developers or users. Users are locked into distro kernels for >> incompatible extensions, and developers are torn between multiple >> codebases. On Mon, Jan 03, 2005 at 01:45:51AM +0100, Adrian Bunk wrote: > At least on Debian, ftp.kernel.org kernels work fine. This does not advance the argument. On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: >> This fragmentation of programmer effort is trivially recognizable as >> counterproductive. A single focal point for programmer effort is far >> superior for a development model. If the standard of stability is not >> passed then the code is not ready to be included in any kernel. Then >> the distinction is lost, and each of the fragmented codebases gets a >> third-class effort, and a spurious expenditure of effort is wasted on >> porting fixes and features across numerous different codebases. >>... On Mon, Jan 03, 2005 at 01:45:51AM +0100, Adrian Bunk wrote: > My impression is that currently 2.4 doesn't take that much time of > developers (except for Marcelo's), and that it's a quite usable and > stable kernel. The ``stable'' moniker and distros being based on 2.4 are horrors beyond imagination and developers are pushed to in turn push inappropriate features on 2.4.x and maintain them out-of-tree for 2.4.x -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 1:19 ` William Lee Irwin III @ 2005-01-03 5:33 ` Willy Tarreau 2005-01-03 12:33 ` William Lee Irwin III 2005-01-03 13:24 ` Diego Calleja 0 siblings, 2 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-03 5:33 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: > On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: > >> The presumption is that these changes are frivolous. This is false. > >> The removals of these features are motivated by their unsoundness, > >> and those removals resolve real problems. If they did not do so, they > >> would not pass peer review. > > On Mon, Jan 03, 2005 at 01:45:51AM +0100, Adrian Bunk wrote: > > The netfilter people plan to remove ipfwadm and ipchains before 2.6.11 . > > This is legacy code that makes their development sometimes a bit harder, > > but AFAIK ipchains in 2.6.10 doesn't suffer from any serious real > > problems. > > They're superseded by iptables and their sole uses are by the Linux- > specific applications to manipulate this privileged aspect of system > state. This makes a much weaker case for backward compatibility than > general nonprivileged standardized system calls. That's not the problem. There was a feature freeze by which everything which was considered hard to maintain or not very stable should have been removed. When 2.6 was announced, it was with a set of features. Who know, perhaps there are a few people who could replace a kernel 2.0 by a 2.6 on some firewalls. Even if they are only 2 or 3 people, there is no reason that suddenly a feature should be removed in the stable series. But it should be removed in 2.7 if it's a nightmare to maintain. If the motivation to break backwards compatibility is not enough anymore to justify development kernels, I don't know what will justify it anymore. I'm particularly fed up by some developer's attitude who seem to never go outside and see how their creations are used by people who really trust the "stable" term... until they realize that this word is used only for marketting, eg. help distro makers announce their new major release at the right moment. ipfwadm had about 2 years to be removed before 2.6, wasn't that enough ? Once the stable release is out, the developer's point of view about how is creation *might* be used is not a justification to remove it. But of course, his difficulties at maintaining the code is fairly enough for him to say "well, it was a mistake to enable this, I don't want it in the future version anymore". Why do you think that so many people are still using 2.4 (and even older versions) ? This is because they are the only ones who don't constantly change under your feet and from which you can build something reliable and guaranteed maintainable. At least, I've not seen any commercial product based on 2.6 yet ! Please, stop constantly changing the contents of the "stable" kernel. > On Mon, Jan 03, 2005 at 01:45:51AM +0100, Adrian Bunk wrote: > > My impression is that currently 2.4 doesn't take that much time of > > developers (except for Marcelo's), and that it's a quite usable and > > stable kernel. > > The ``stable'' moniker and distros being based on 2.4 are horrors > beyond imagination and developers are pushed to in turn push > inappropriate features on 2.4.x and maintain them out-of-tree for > 2.4.x I clearly don't agree with you, for a simple reason : those out-of-tree features will always be, because each distro likes to add a few features, like SquashFS, PaX, etc... And indeed, that's one of the reasons I *stay* on 2.4. It's so simple to simply upgrade the kernel, patch and recompile without spending days complaining "grrr... why did they change this ?". As soon as you have at least *ONE* patch to apply to a kernel for your distro, 2.4 is a safer bet than 2.6 if you don't want to restart everything at each minor release. The 2.4 kernel is more what I consider stable than 2.6, eventhough it's not totally. 2.0 and 2.2 *are* stable, because I'm certain that every future releases will only be bugfixes and will touch only a few lines. At the moment, the only "serious" use I've found for a 2.6 is a kexec-based bootloader for known hardware. I've already seen that maintaining it up to date is not simple, I wonder how distro people work with it... I wouldn't have to do their work right now. Regards, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 5:33 ` Willy Tarreau @ 2005-01-03 12:33 ` William Lee Irwin III 2005-01-03 21:38 ` Willy Tarreau 2005-01-03 13:24 ` Diego Calleja 1 sibling, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 12:33 UTC (permalink / raw) To: Willy Tarreau Cc: Adrian Bunk, William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: >> They're superseded by iptables and their sole uses are by the Linux- >> specific applications to manipulate this privileged aspect of system >> state. This makes a much weaker case for backward compatibility than >> general nonprivileged standardized system calls. On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > That's not the problem. There was a feature freeze by which > everything which was considered hard to maintain or not very stable > should have been removed. When 2.6 was announced, it was with a set > of features. Who know, perhaps there are a few people who could > replace a kernel 2.0 by a 2.6 on some firewalls. Even if they are > only 2 or 3 people, there is no reason that suddenly a feature should > be removed in the stable series. But it should be removed in 2.7 if > it's a nightmare to maintain. This is bizarre. iptables was made the de facto standard in 2.4.x and the alternatives have issues with functionality. The 2.0/2.2 firewalling interfaces are probably ready to go regardless. You do realize this is what you're referring to? 2 major releases is long enough. On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > If the motivation to break backwards compatibility is not enough > anymore to justify development kernels, I don't know what will > justify it anymore. I'm particularly fed up by some developer's > attitude who seem to never go outside and see how their creations are > used by people who really trust the "stable" term... until they > realize that this word is used only for marketting, Who do you think is actually banging out the code on this mailing list? Anyway, features aren't really allowed to break backward compatibility; we've effectively got 10-year lifetimes for userspace-visible interfaces. If this isn't good enough, well, tough. On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > eg. help distro makers announce their new major release at the right > moment. ipfwadm had about 2 years to be removed before 2.6, wasn't > that enough ? Once the stable release is out, the developer's point > of view about how is creation *might* be used is not a justification > to remove it. But of course, his difficulties at maintaining the code > is fairly enough for him to say "well, it was a mistake to enable > this, I don't want it in the future version anymore". There isn't really any code behind ipfwadm, just a mocked-up interface. I have little insight into what goes in in net/ to be honest. I do have a firm notion that what goes on there is similar to the rest of the kernel wrt. backward compatibility etc. On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > Why do you think that so many people are still using 2.4 (and even > older versions) ? This is because they are the only ones who don't > constantly change under your feet and from which you can build > something reliable and guaranteed maintainable. At least, I've not > seen any commercial product based on 2.6 yet ! > Please, stop constantly changing the contents of the "stable" kernel. Either this is some kind of sick joke or you've never heard of SLES9. On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: >> The ``stable'' moniker and distros being based on 2.4 are horrors >> beyond imagination and developers are pushed to in turn push >> inappropriate features on 2.4.x and maintain them out-of-tree for >> 2.4.x On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > I clearly don't agree with you, for a simple reason : those out-of-tree > features will always be, because each distro likes to add a few features, > like SquashFS, PaX, etc... And indeed, that's one of the reasons I *stay* > on 2.4. It's so simple to simply upgrade the kernel, patch and recompile > without spending days complaining "grrr... why did they change this ?". > As soon as you have at least *ONE* patch to apply to a kernel for your > distro, 2.4 is a safer bet than 2.6 if you don't want to restart everything > at each minor release. The 2.4 kernel is more what I consider stable than > 2.6, eventhough it's not totally. 2.0 and 2.2 *are* stable, because I'm > certain that every future releases will only be bugfixes and will touch > only a few lines. You have ignored my entire argument in favor of reiterating your own. One more time, since this apparently needs to be repeated in a condensed and/or simplified form. (1) the "stable" kernels are actually buggier because no one's looking (2) the creation of those feature patches for stable kernels has detracted from the efforts needed to get them actually into the kernel, and they're not going to exist for long On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > At the moment, the only "serious" use I've found for a 2.6 is a kexec-based > bootloader for known hardware. I've already seen that maintaining it up to > date is not simple, I wonder how distro people work with it... I wouldn't > have to do their work right now. People are already using it to run the databases their paychecks rely on. Whatever else you had in mind can't be anticipated. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 12:33 ` William Lee Irwin III @ 2005-01-03 21:38 ` Willy Tarreau 2005-01-03 22:09 ` William Lee Irwin III ` (3 more replies) 0 siblings, 4 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-03 21:38 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: > This is bizarre. iptables was made the de facto standard in 2.4.x and > the alternatives have issues with functionality. The 2.0/2.2 firewalling > interfaces are probably ready to go regardless. You do realize this is > what you're referring to? > > 2 major releases is long enough. if it's long enough, ipfwadm should not have entered 2.6 at all. It's not because you don't see any use to that particular feature that you can guarantee that it is not used at all. At least, a large public call to get in touch with the potentially unique user of this feature would be a start, but generally we should not remove a feature from a stable kernel. What will go next ? minix, because someone will decide that there have been many better filesystems for a long time, so that's long enough ? Revert modules to modutils because someone will think it's simpler for everyone to use a single toolset ? I have no problem removing numerous feature between major releases, even breaking APIs, but I really hate it when something which is called "stable" constantly changes. > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > > If the motivation to break backwards compatibility is not enough > > anymore to justify development kernels, I don't know what will > > justify it anymore. I'm particularly fed up by some developer's > > attitude who seem to never go outside and see how their creations are > > used by people who really trust the "stable" term... until they > > realize that this word is used only for marketting, > > Who do you think is actually banging out the code on this mailing list? Frankly, sometimes I'm really wondering. We see lots of very clever ideas, and sometimes people come up with concepts which can break existing apps, and simply justify by "this should not have been done in the first time." (eg: unexport syscall_table). But I'm certain that all these mistakes are caused by those too long development cycles. Some developpers get bored by things that irritate them, and prefer to fix the stable tree to stop what they believe is an error, instead of waiting for the next release to fix it there. > Anyway, features aren't really allowed to break backward compatibility; > we've effectively got 10-year lifetimes for userspace-visible interfaces. > If this isn't good enough, well, tough. All in all, I agree with you. The small differences lie in /proc files or oops syntax, etc... But even old syscalls are still supported and that's fine. I appreciate it when I read the packet(7) man page to find that even the interface from linux 2.0 is still supported. The problem is that nowadays, the userspace-visible code is not only in userspace anymore, but also involves modules interfaces sometimes because some commercial apps rely on modules (firewalls, virtual machines, etc...), and their userspace is nuts without those modules, so in a certain way, breaking some kernel internals within a stable release does break some apps. > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > > Why do you think that so many people are still using 2.4 (and even > > older versions) ? This is because they are the only ones who don't > > constantly change under your feet and from which you can build > > something reliable and guaranteed maintainable. At least, I've not > > seen any commercial product based on 2.6 yet ! > > Please, stop constantly changing the contents of the "stable" kernel. > > Either this is some kind of sick joke or you've never heard of SLES9. the later :-) > On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: (...) > You have ignored my entire argument in favor of reiterating your own. > > One more time, since this apparently needs to be repeated in a > condensed and/or simplified form. > > (1) the "stable" kernels are actually buggier because no one's looking I don't agree with you. "known" bugs become features of this particular release and people learn how to play with them. The MM beahaviour when one single user can crash the whole machine just accidentely playing with malloc() would be called a bug on any other decent OS. For us it's a feature we have been used to live with. It's possible that 2.6 has fewer of those known bugs, but it still has many yet-to-discover bugs (the first ones being all those 'my machine does not boot anymore' reported here and caused by those too long release cycles). > (2) the creation of those feature patches for stable kernels has > detracted from the efforts needed to get them actually into > the kernel, and they're not going to exist for long I agree with you on the first part, but not on the second one, because as a stable kernel implies it, it will still be possible to apply current patches to new releases with very few efforts. Indeed, I have already sent rediffed patches to different maintainers because they were easy to do. For a while now, on 2.4, you can easily apply jiffies64, epoll, netdev-random, preempt, lowlat, bme, squashfs, tux, etc... The list is long and demonstrantes what stable code looks like. "stable" does not mean it will not crash, but it means "it will not change much", eventhough this tends to imply the former. > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > > At the moment, the only "serious" use I've found for a 2.6 is a kexec-based > > bootloader for known hardware. I've already seen that maintaining it up to > > date is not simple, I wonder how distro people work with it... I wouldn't > > have to do their work right now. > > People are already using it to run the databases their paychecks rely on. I feel they're brave. I know several other people who went back, either because they didn't feel comfortable with upgrades these size, which sometimes did not boot because of random patches, or simply because of the scheduler which didn't let them type normally in an SSH session on a CPU-bound system, or even a proxy which performance dropped by a factor of 5 between 2.4 and 2.6. I know they don't report it, but they are not developpers. They see that 2.6 is not ready yet, and turn back to stable 2.4. > Whatever else you had in mind can't be anticipated. agreed. Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:38 ` Willy Tarreau @ 2005-01-03 22:09 ` William Lee Irwin III 2005-01-03 23:53 ` Bill Davidsen ` (2 subsequent siblings) 3 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 22:09 UTC (permalink / raw) To: Willy Tarreau Cc: Adrian Bunk, William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: >> This is bizarre. iptables was made the de facto standard in 2.4.x and >> the alternatives have issues with functionality. The 2.0/2.2 firewalling >> interfaces are probably ready to go regardless. You do realize this is >> what you're referring to? >> 2 major releases is long enough. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > if it's long enough, ipfwadm should not have entered 2.6 at all. It's > not because you don't see any use to that particular feature that you > can guarantee that it is not used at all. At least, a large public > call to get in touch with the potentially unique user of this feature > would be a start, but generally we should not remove a feature from a > stable kernel. What will go next ? minix, because someone will decide > that there have been many better filesystems for a long time, so > that's long enough ? Revert modules to modutils because someone > will think it's simpler for everyone to use a single toolset ? I have > no problem removing numerous feature between major releases, even > breaking APIs, but I really hate it when something which is called > "stable" constantly changes. Unfortunately you're never going to find a rock to build your house on. there is no rock, there is only shifting sand. On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: >> Who do you think is actually banging out the code on this mailing list? On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > Frankly, sometimes I'm really wondering. We see lots of very clever > ideas, and sometimes people come up with concepts which can break > existing apps, and simply justify by "this should not have been done > in the first time." (eg: unexport syscall_table). But I'm certain > that all these mistakes are caused by those too long development > cycles. Some developpers get bored by things that irritate them, and > prefer to fix the stable tree to stop what they believe is an error, > instead of waiting for the next release to fix it there. These things are harder and colder than "boredom" and the like can influence. What you are dredging up does not actually exist. On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: >> Anyway, features aren't really allowed to break backward compatibility; >> we've effectively got 10-year lifetimes for userspace-visible interfaces. >> If this isn't good enough, well, tough. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > All in all, I agree with you. The small differences lie in /proc files or > oops syntax, etc... But even old syscalls are still supported and that's fine. > I appreciate it when I read the packet(7) man page to find that even the > interface from linux 2.0 is still supported. Despite your appreciation the net effect is actually irrelevance or less. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > The problem is that nowadays, the userspace-visible code is not only in > userspace anymore, but also involves modules interfaces sometimes because > some commercial apps rely on modules (firewalls, virtual machines, etc...), > and their userspace is nuts without those modules, so in a certain way, > breaking some kernel internals within a stable release does break some apps. On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: >> Either this is some kind of sick joke or you've never heard of SLES9. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > the later :-) SLES9 is a 2.6.x-based distro release from SuSE. It is in widespread use by customers and customers are migrating to it en masse on account of its 2.6.x basis due to 2.6.x' superior performance and stability characteristics. No "glowing praise" is necessary. This story tells itself. On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: > (...) >> You have ignored my entire argument in favor of reiterating your own. >> One more time, since this apparently needs to be repeated in a >> condensed and/or simplified form. On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote: >> (1) the "stable" kernels are actually buggier because no one's looking On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > I don't agree with you. "known" bugs become features of this particular > release and people learn how to play with them. The MM beahaviour when one > single user can crash the whole machine just accidentely playing with malloc() > would be called a bug on any other decent OS. For us it's a feature we have > been used to live with. Patterns of userspace usage that take down boxen are not "features" and are never going to be considered valid aspects of "stable" releases. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > It's possible that 2.6 has fewer of those known bugs, but it still has many > yet-to-discover bugs (the first ones being all those 'my machine does not > boot anymore' reported here and caused by those too long release cycles). Ockham. QED. On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: >> (2) the creation of those feature patches for stable kernels has >> detracted from the efforts needed to get them actually into >> the kernel, and they're not going to exist for long On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > I agree with you on the first part, but not on the second one, because > as a stable kernel implies it, it will still be possible to apply > current patches to new releases with very few efforts. Indeed, I have > already sent rediffed > patches to different maintainers because they > were easy to do. For a while now, on 2.4, you can easily apply > jiffies64, epoll, netdev-random, preempt, lowlat, bme, squashfs, tux, > etc... The list is long and demonstrantes what stable code looks like. > "stable" does not mean it will not crash, but it means "it will not > change much", eventhough this tends to imply the former. Now the everrever-changing definition of "stable" comes into play. If you can't handle the baseline changing, freeze on a specific release. On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: >> People are already using it to run the databases their paychecks rely on. On Mon, Jan 03, 2005 at 10:38:45PM +0100, Willy Tarreau wrote: > I feel they're brave. I know several other people who went back, > either because they didn't feel comfortable with upgrades these size, > which sometimes did not boot because of random patches, or simply > because of the scheduler which didn't let them type normally in an > SSH session on a CPU-bound system, or even a proxy which performance > dropped by a factor of 5 between 2.4 and 2.6. I know they don't > report it, but they are not developpers. They see that 2.6 is not > ready yet, and turn back to stable 2.4. They are not brave. They are the most cowardly people in existence. They don't dare go on using 2.4.x because it can't handle the load, because it can't hadle the bigger and newer machines, and because it just doesn't work for them. It's not like they moved frivolously; they're more terrified of migrating than even the most horrible bugs. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:38 ` Willy Tarreau 2005-01-03 22:09 ` William Lee Irwin III @ 2005-01-03 23:53 ` Bill Davidsen 2005-01-04 5:06 ` Alexander E. Patrakov 2005-01-04 13:17 ` Horst von Brand 3 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 23:53 UTC (permalink / raw) To: Willy Tarreau Cc: William Lee Irwin III, Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, 3 Jan 2005, Willy Tarreau wrote: > On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: > > > This is bizarre. iptables was made the de facto standard in 2.4.x and > > the alternatives have issues with functionality. The 2.0/2.2 firewalling > > interfaces are probably ready to go regardless. You do realize this is > > what you're referring to? > > > > 2 major releases is long enough. > > if it's long enough, ipfwadm should not have entered 2.6 at all. That is the truth! No one would have complained if they went away in 2.5. But now people are using ipchains (it was the default Redhat firewall for a while even after iptables came out). > > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: > > > At the moment, the only "serious" use I've found for a 2.6 is a kexec-based > > > bootloader for known hardware. I've already seen that maintaining it up to > > > date is not simple, I wonder how distro people work with it... I wouldn't > > > have to do their work right now. > > > > People are already using it to run the databases their paychecks rely on. > > I feel they're brave. I know several other people who went back, either because > they didn't feel comfortable with upgrades these size, which sometimes did not > boot because of random patches, or simply because of the scheduler which didn't > let them type normally in an SSH session on a CPU-bound system, or even a > proxy which performance dropped by a factor of 5 between 2.4 and 2.6. I know > they don't report it, but they are not developpers. They see that 2.6 is not > ready yet, and turn back to stable 2.4. Actually one of the reasons I use 2.6, in many cases it resists hangs which occur in 2.4. Thank Ingo, Nick and Con for that (and others) making the scheduler far better at "plays well with others." Between the O(1) scheduler and the HT fixes, and the various large and small tweaks of everyone, 2.6 runs well on both large and small machines compared to 2.4. Yes, there are exceptions. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:38 ` Willy Tarreau 2005-01-03 22:09 ` William Lee Irwin III 2005-01-03 23:53 ` Bill Davidsen @ 2005-01-04 5:06 ` Alexander E. Patrakov 2005-01-04 5:29 ` Sean 2005-01-05 8:42 ` Andrew Morton 2005-01-04 13:17 ` Horst von Brand 3 siblings, 2 replies; 222+ messages in thread From: Alexander E. Patrakov @ 2005-01-04 5:06 UTC (permalink / raw) To: linux-kernel Willy Tarreau wrote: > I feel they're brave. I know several other people who went back, either > because they didn't feel comfortable with upgrades these size, which > sometimes did not boot because of random patches, or simply because of the > scheduler which didn't let them type normally in an SSH session on a > CPU-bound system, or even a proxy which performance dropped by a factor of > 5 between 2.4 and 2.6. I know they don't report it, but they are not > developpers. They see that 2.6 is not ready yet, and turn back to stable > 2.4. Here is one more regression report. My /home was on reiserfs some time ago (migrated to ext3 using convertfs due to this regression). I read my mail with KMail. I am also subscribed to several mailing lists. I have a separate Maildir-formatted folder for each mailing list. Some of such folders are more than a year old and contain thousands of messages. With linux-2.4, I could click on such folder and the list of messages sorted by subject will appear in KMail almost instantly. With linux-2.6, this process takes much longer. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:06 ` Alexander E. Patrakov @ 2005-01-04 5:29 ` Sean 2005-01-05 8:42 ` Andrew Morton 1 sibling, 0 replies; 222+ messages in thread From: Sean @ 2005-01-04 5:29 UTC (permalink / raw) To: Alexander E. Patrakov; +Cc: linux-kernel On Tue, January 4, 2005 12:06 am, Alexander E. Patrakov said: > Willy Tarreau wrote: > >> I feel they're brave. I know several other people who went back, either >> because they didn't feel comfortable with upgrades these size, which >> sometimes did not boot because of random patches, or simply because of >> the >> scheduler which didn't let them type normally in an SSH session on a >> CPU-bound system, or even a proxy which performance dropped by a factor >> of >> 5 between 2.4 and 2.6. I know they don't report it, but they are not >> developpers. They see that 2.6 is not ready yet, and turn back to stable >> 2.4. > > Here is one more regression report. > > My /home was on reiserfs some time ago (migrated to ext3 using convertfs > due > to this regression). I read my mail with KMail. I am also subscribed to > several mailing lists. I have a separate Maildir-formatted folder for each > mailing list. Some of such folders are more than a year old and contain > thousands of messages. With linux-2.4, I could click on such folder and > the > list of messages sorted by subject will appear in KMail almost instantly. > With linux-2.6, this process takes much longer. > Which might just indicate that the old development model under which the 2.6 kernel was developed wasn't ideal. Perhaps you wouldn't be having this problem had the new development model been in place sooner. Sean ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:06 ` Alexander E. Patrakov 2005-01-04 5:29 ` Sean @ 2005-01-05 8:42 ` Andrew Morton 2005-01-05 9:13 ` Alexander E. Patrakov 1 sibling, 1 reply; 222+ messages in thread From: Andrew Morton @ 2005-01-05 8:42 UTC (permalink / raw) To: Alexander E. Patrakov; +Cc: linux-kernel "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote: > > With linux-2.4, I could click on such folder and the > list of messages sorted by subject will appear in KMail almost instantly. > With linux-2.6, this process takes much longer. There was a bug in kmail which caused this. It must have been a quite old version. It can be worked around by mounting the reiserfs3 filessytem with the "nolargeio=1" mount option. Or by upgrading kmail. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 8:42 ` Andrew Morton @ 2005-01-05 9:13 ` Alexander E. Patrakov 0 siblings, 0 replies; 222+ messages in thread From: Alexander E. Patrakov @ 2005-01-05 9:13 UTC (permalink / raw) To: linux-kernel Andrew Morton wrote: > "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote: >> >> With linux-2.4, I could click on such folder and the >> list of messages sorted by subject will appear in KMail almost >> instantly. With linux-2.6, this process takes much longer. > > There was a bug in kmail which caused this. It must have been a quite old > version. It can be worked around by mounting the reiserfs3 filessytem > with > the "nolargeio=1" mount option. Or by upgrading kmail. Thanks for notifying me. I have already upgraded KMail, but I am probably too lazy to migrate back to reiserfs right now. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:38 ` Willy Tarreau ` (2 preceding siblings ...) 2005-01-04 5:06 ` Alexander E. Patrakov @ 2005-01-04 13:17 ` Horst von Brand 3 siblings, 0 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-04 13:17 UTC (permalink / raw) To: Willy Tarreau Cc: William Lee Irwin III, Adrian Bunk, William Lee Irwin III, Bill Davidsen, Andries Brouwer, Maciej Soltysiak, linux-kernel Willy Tarreau <willy@w.ods.org> said: > On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote: > > This is bizarre. iptables was made the de facto standard in 2.4.x and > > the alternatives have issues with functionality. The 2.0/2.2 firewalling > > interfaces are probably ready to go regardless. You do realize this is > > what you're referring to? > > 2 major releases is long enough. When iptables went in, they computed reasonable dates for the final demise of ipfwadm and ipchains compatibility. IIRC, both came out as March, 2004. > if it's long enough, ipfwadm should not have entered 2.6 at all. Backward compatibility is important. Sure, under the old development model it would have been "deprecate <feature> in 2.<2n>, axe it at the start of 2.<2n+1>, by 2.<2n+2> it is gone". > It's not > because you don't see any use to that particular feature that you can > guarantee that it is not used at all. At least, a large public call to > get in touch with the potentially unique user of this feature would be a > start, but generally we should not remove a feature from a stable > kernel. A public call won't get to that single user, or she is simply too lazy to answer. Axe it, and they scream. That is much more effective. Besides, that way she looks for help (and surely finds a kind soul helping out with migrating). Or stays put (2.4 is still alivve...). > What will go next ? minix, because someone will decide that there > have been many better filesystems for a long time, so that's long enough > ? Minix is a nice example, doesn't interfere with other work and is no great maintainance burden. I guess it'll stay. > Revert modules to modutils because someone will think it's simpler for > everyone to use a single toolset ? Nope. The change had its very good reasons. > I have no problem removing numerous > feature between major releases, What's the beef then? > even breaking APIs, AFAIR, the only public APIs broken have been for exclusive use by utilities tightly coupled to the kernel (module handling, firewall), and those during development series. If you fool around with development kernels, you are supposed to be prepared for such breakage. Normal users get insulated by their respective distributions. > but I really hate it > when something which is called "stable" constantly changes. List the offending changes for us all to contemplate, please. > > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote: [...] > > Who do you think is actually banging out the code on this mailing list? > Frankly, sometimes I'm really wondering. We see lots of very clever > ideas, and sometimes people come up with concepts which can break > existing apps, and simply justify by "this should not have been done in > the first time." (eg: unexport syscall_table). But I'm certain that all > these mistakes are caused by those too long development cycles. Some > developpers get bored by things that irritate them, and prefer to fix the > stable tree to stop what they believe is an error, instead of waiting for > the next release to fix it there. Distributions (or final users) are free to undo offending changes. [...] > The problem is that nowadays, the userspace-visible code is not only in > userspace anymore, but also involves modules interfaces sometimes because > some commercial apps rely on modules (firewalls, virtual machines, > etc...), and their userspace is nuts without those modules, so in a > certain way, breaking some kernel internals within a stable release does > break some apps. Tough luck. If it is closed source, whoever builds it is responsible for making it work. If they don't keep it working for your preferred setup, it's the price _you_ pay for closed source + bleeding edge. LKML has no way of helping you there. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 5:33 ` Willy Tarreau 2005-01-03 12:33 ` William Lee Irwin III @ 2005-01-03 13:24 ` Diego Calleja 2005-01-03 13:47 ` Adrian Bunk 2005-01-04 2:06 ` Roman Zippel 1 sibling, 2 replies; 222+ messages in thread From: Diego Calleja @ 2005-01-03 13:24 UTC (permalink / raw) To: Willy Tarreau; +Cc: wli, bunk, davidsen, aebr, solt2, linux-kernel El Mon, 3 Jan 2005 06:33:04 +0100 Willy Tarreau <willy@w.ods.org> escribió: > I clearly don't agree with you, for a simple reason : those out-of-tree > features will always be, because each distro likes to add a few features, > like SquashFS, PaX, etc... And indeed, that's one of the reasons I *stay* > on 2.4. It's so simple to simply upgrade the kernel, patch and recompile > without spending days complaining "grrr... why did they change this ?". 2.6 will stop having small issues in each release until 2.7 is forked just like 2.4 broke things until 2.5 was forked. The difference IMO is that linux development now avoids things like the unstability which the 2.4.10 changes caused and things like the fs corruption bugs we saw in 2.4 I fully agree with WLI that the 2.4 development model and the backporting-mania created more problems than it solved, because in the real world almost everybody uses what distros ship, and what distros ship isn't kernel.org but heavily modified kernels, which means that the kernel.org was not really "well-tested" or it took much longer to become "well-tested" because it wasn't really being used. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 13:24 ` Diego Calleja @ 2005-01-03 13:47 ` Adrian Bunk 2005-01-03 17:18 ` Bill Davidsen 2005-01-04 12:57 ` starting with 2.7 William Lee Irwin III 2005-01-04 2:06 ` Roman Zippel 1 sibling, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 13:47 UTC (permalink / raw) To: Diego Calleja; +Cc: Willy Tarreau, wli, davidsen, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 02:24:12PM +0100, Diego Calleja wrote: > El Mon, 3 Jan 2005 06:33:04 +0100 Willy Tarreau <willy@w.ods.org> escribió: > > > I clearly don't agree with you, for a simple reason : those out-of-tree > > features will always be, because each distro likes to add a few features, > > like SquashFS, PaX, etc... And indeed, that's one of the reasons I *stay* > > on 2.4. It's so simple to simply upgrade the kernel, patch and recompile > > without spending days complaining "grrr... why did they change this ?". > > > 2.6 will stop having small issues in each release until 2.7 is forked just > like 2.4 broke things until 2.5 was forked. The difference IMO > is that linux development now avoids things like the unstability which the > 2.4.10 changes caused and things like the fs corruption bugs we saw in 2.4 >... The 2.6.9 -> 2.6.10 patch is 28 MB, and while the changes that went into 2.4 were limited since the most invasive patches were postponed for 2.5, now _all_ patches go into 2.6 . Yes, -mm gives a bit more testing coverage, but it doesn't seem to be enough for this vast amount of changes. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 13:47 ` Adrian Bunk @ 2005-01-03 17:18 ` Bill Davidsen 2005-01-03 18:04 ` Adrian Bunk ` (4 more replies) 2005-01-04 12:57 ` starting with 2.7 William Lee Irwin III 1 sibling, 5 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 17:18 UTC (permalink / raw) To: Adrian Bunk; +Cc: Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 2499 bytes --] On Mon, 3 Jan 2005, Adrian Bunk wrote: > On Mon, Jan 03, 2005 at 02:24:12PM +0100, Diego Calleja wrote: > > El Mon, 3 Jan 2005 06:33:04 +0100 Willy Tarreau <willy@w.ods.org> escribió: > > > > > I clearly don't agree with you, for a simple reason : those out-of-tree > > > features will always be, because each distro likes to add a few features, > > > like SquashFS, PaX, etc... And indeed, that's one of the reasons I *stay* > > > on 2.4. It's so simple to simply upgrade the kernel, patch and recompile > > > without spending days complaining "grrr... why did they change this ?". > > > > > > 2.6 will stop having small issues in each release until 2.7 is forked just > > like 2.4 broke things until 2.5 was forked. The difference IMO > > is that linux development now avoids things like the unstability which the > > 2.4.10 changes caused and things like the fs corruption bugs we saw in 2.4 > >... > > The 2.6.9 -> 2.6.10 patch is 28 MB, and while the changes that went into > 2.4 were limited since the most invasive patches were postponed for 2.5, > now _all_ patches go into 2.6 . > > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > enough for this vast amount of changes. I have to say that with a few minor exceptions the introduction of new features hasn't created long term (more than a few days) of problems. And we have had that in previous stable versions as well. New features themselves may not be totally stable, but in most cases they don't break existing features, or are fixed in bk1 or bk2. What worries me is removing features deliberately, and I won't beat that dead horse again, I've said my piece. The "few minor exceptions:" SCSI command filtering - while I totally support the idea (and always have), I miss running cdrecord as a normal user. Multisession doesn't work as a normal user (at least if you follow the man page) because only root can use -msinfo. There's also some raw mode which got a permission denied, don't remember as I was trying something not doing production stuff. APM vs. ACPI - shutdown doesn't reliably power down about half of the machines I use, and all five laptops have working suspend and non-working resume. APM seems to be pretty unsupported beyond "use ACPI for that." None of these would prevent using 2.6 if there were some feature not in 2.4 which gave a reason to switch. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:18 ` Bill Davidsen @ 2005-01-03 18:04 ` Adrian Bunk 2005-01-03 18:41 ` Bill Davidsen 2005-01-03 18:36 ` Theodore Ts'o ` (3 subsequent siblings) 4 siblings, 1 reply; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 18:04 UTC (permalink / raw) To: Bill Davidsen Cc: Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 12:18:36PM -0500, Bill Davidsen wrote: >... > The "few minor exceptions:" > > SCSI command filtering - while I totally support the idea (and always > have), I miss running cdrecord as a normal user. Multisession doesn't work > as a normal user (at least if you follow the man page) because only root > can use -msinfo. There's also some raw mode which got a permission denied, > don't remember as I was trying something not doing production stuff. > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > machines I use, and all five laptops have working suspend and non-working > resume. APM seems to be pretty unsupported beyond "use ACPI for that." >... More serious were other problems like e.g. the problems XFS has (had?) with the 4kB stacks option on i386 that was introduced in 2.6 after 2.6.0 . cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:04 ` Adrian Bunk @ 2005-01-03 18:41 ` Bill Davidsen 0 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 18:41 UTC (permalink / raw) To: Adrian Bunk; +Cc: Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005, Adrian Bunk wrote: > On Mon, Jan 03, 2005 at 12:18:36PM -0500, Bill Davidsen wrote: > >... > > The "few minor exceptions:" > > > > SCSI command filtering - while I totally support the idea (and always > > have), I miss running cdrecord as a normal user. Multisession doesn't work > > as a normal user (at least if you follow the man page) because only root > > can use -msinfo. There's also some raw mode which got a permission denied, > > don't remember as I was trying something not doing production stuff. > > > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > > machines I use, and all five laptops have working suspend and non-working > > resume. APM seems to be pretty unsupported beyond "use ACPI for that." > >... > > More serious were other problems like e.g. the problems XFS has (had?) > with the 4kB stacks option on i386 that was introduced in 2.6 > after 2.6.0 . Can't speak for XFS, but the 4k stack issue was an option, and could be investigated with care. I only found one case where 4k would repeatably cause a problem, and the fix was in the -bk before I had a decent test case. I am going to try XFS in a month or so, I have a chance to bench JFS vs. XFS for an application with 40-50k files in a directory. Hope it works by then if it doesn't now, I'm told BSD works well. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:18 ` Bill Davidsen 2005-01-03 18:04 ` Adrian Bunk @ 2005-01-03 18:36 ` Theodore Ts'o 2005-01-03 18:59 ` Russell King ` (2 more replies) 2005-01-03 19:28 ` Jens Axboe ` (2 subsequent siblings) 4 siblings, 3 replies; 222+ messages in thread From: Theodore Ts'o @ 2005-01-03 18:36 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 12:18:36PM -0500, Bill Davidsen wrote: > I have to say that with a few minor exceptions the introduction of new > features hasn't created long term (more than a few days) of problems. And > we have had that in previous stable versions as well. New features > themselves may not be totally stable, but in most cases they don't break > existing features, or are fixed in bk1 or bk2. What worries me is removing > features deliberately, and I won't beat that dead horse again, I've said > my piece. Indeed. Part of the problem is that we don't get that much testing with the rc* releases, so there are a lot of problems that don't get noticed until after 2.6.x ships. This has been true for both 2.6.9 and 2.6.10. My personal practice is to never run with 2.6.x release, but wait for 2.6.x plus one or 2 days (i.e. bk1 or bk2). The problems with this approach are that (1) out-of-tree patches against official versions of the kernel (i.e., things like the mppc/mppe patch) don't necessarly apply cleanly, and (2) other more destablizing patches get folded in right after 2.6.x ships, so there is a chance bk1 or bk2 may not be stable. We could delay the destablizing changes until after rc1 ships, and ship rc1 about 2-3 days after 2.6.x is released, so that the really obvious/critical regressions can be addressed immediately. The problem with this approach though is that some people will just wait until rc1 ships before they start using a new kernel version, and we lose the testing we need to stablize the release. The real key, as always, is getting users to download and test a release. So another approach might be to shorten the time between 2.6.x and 2.6.x+1 releases, so as to recreate more testing points, without training people to wait for -bk1, -bk2, -rc1, etc. before trying out the kernel code. This is the model that we used with the 2.3.x series, where the time between releases was often quite short. That worked fairly well, but we stopped doing it when the introduction of BitKeeper eliminated the developer synch-up problem. But perhaps we've gone too far between 2.6.x releases, and should shorten the time in order to force more testing. - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:36 ` Theodore Ts'o @ 2005-01-03 18:59 ` Russell King 2005-01-03 19:07 ` William Lee Irwin III ` (2 more replies) 2005-01-03 21:13 ` Horst von Brand 2005-01-06 14:03 ` Paolo Ciarrocchi 2 siblings, 3 replies; 222+ messages in thread From: Russell King @ 2005-01-03 18:59 UTC (permalink / raw) To: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 01:36:21PM -0500, Theodore Ts'o wrote: > This is the model that we used with the > 2.3.x series, where the time between releases was often quite short. > That worked fairly well, but we stopped doing it when the introduction > of BitKeeper eliminated the developer synch-up problem. But perhaps > we've gone too far between 2.6.x releases, and should shorten the time > in order to force more testing. It is also the model we used until OLS this year - there was a 2.6 release about once a month prior to OLS. Post OLS, it's now once every three months or there abouts, which, IMO is far too long. I really liked the way pre-OLS 2.6 was working... it means I don't have to twiddle my fingers getting completely bored waiting for the next 2.6 release to happen. Can we return to that methodology please? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:59 ` Russell King @ 2005-01-03 19:07 ` William Lee Irwin III 2005-01-03 19:26 ` Randy.Dunlap 2005-01-04 0:24 ` Theodore Ts'o 2 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 19:07 UTC (permalink / raw) To: Russell King Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 01:36:21PM -0500, Theodore Ts'o wrote: >> This is the model that we used with the >> 2.3.x series, where the time between releases was often quite short. >> That worked fairly well, but we stopped doing it when the introduction >> of BitKeeper eliminated the developer synch-up problem. But perhaps >> we've gone too far between 2.6.x releases, and should shorten the time >> in order to force more testing. On Mon, Jan 03, 2005 at 06:59:27PM +0000, Russell King wrote: > It is also the model we used until OLS this year - there was a 2.6 > release about once a month prior to OLS. Post OLS, it's now once > every three months or there abouts, which, IMO is far too long. > I really liked the way pre-OLS 2.6 was working... it means I don't > have to twiddle my fingers getting completely bored waiting for the > next 2.6 release to happen. Can we return to that methodology please? Seconded. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:59 ` Russell King 2005-01-03 19:07 ` William Lee Irwin III @ 2005-01-03 19:26 ` Randy.Dunlap 2005-01-03 21:06 ` Alan Cox 2005-01-04 0:24 ` Theodore Ts'o 2 siblings, 1 reply; 222+ messages in thread From: Randy.Dunlap @ 2005-01-03 19:26 UTC (permalink / raw) To: Russell King Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Russell King wrote: > On Mon, Jan 03, 2005 at 01:36:21PM -0500, Theodore Ts'o wrote: > >>This is the model that we used with the >>2.3.x series, where the time between releases was often quite short. >>That worked fairly well, but we stopped doing it when the introduction >>of BitKeeper eliminated the developer synch-up problem. But perhaps >>we've gone too far between 2.6.x releases, and should shorten the time >>in order to force more testing. > > > It is also the model we used until OLS this year - there was a 2.6 > release about once a month prior to OLS. Post OLS, it's now once > every three months or there abouts, which, IMO is far too long. > > I really liked the way pre-OLS 2.6 was working... it means I don't > have to twiddle my fingers getting completely bored waiting for the > next 2.6 release to happen. Can we return to that methodology please? Agreed. We (whoever "we" are) have erred too much on longer cycles for stability, but it's not working out as hoped IMO. -- ~Randy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 19:26 ` Randy.Dunlap @ 2005-01-03 21:06 ` Alan Cox 0 siblings, 0 replies; 222+ messages in thread From: Alan Cox @ 2005-01-03 21:06 UTC (permalink / raw) To: Randy.Dunlap Cc: Russell King, Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, Linux Kernel Mailing List On Llu, 2005-01-03 at 19:26, Randy.Dunlap wrote: > Agreed. We (whoever "we" are) have erred too much on longer > cycles for stability, but it's not working out as hoped IMO. After 2.6.9-ac its clear that the long 2.6.9 process worked very badly. While 2.6.10 is looking much better its long period meant the allegedly "official" base kernel was a complete pile of insecure donkey turd for months. That doesn't hurt most vendor users but it does hurt those trying to do stuff on the base kernels very badly. Alan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:59 ` Russell King 2005-01-03 19:07 ` William Lee Irwin III 2005-01-03 19:26 ` Randy.Dunlap @ 2005-01-04 0:24 ` Theodore Ts'o 2005-01-04 3:12 ` Thomas Graf 2 siblings, 1 reply; 222+ messages in thread From: Theodore Ts'o @ 2005-01-04 0:24 UTC (permalink / raw) To: Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 06:59:27PM +0000, Russell King wrote: > On Mon, Jan 03, 2005 at 01:36:21PM -0500, Theodore Ts'o wrote: > > This is the model that we used with the > > 2.3.x series, where the time between releases was often quite short. > > That worked fairly well, but we stopped doing it when the introduction > > of BitKeeper eliminated the developer synch-up problem. But perhaps > > we've gone too far between 2.6.x releases, and should shorten the time > > in order to force more testing. > > It is also the model we used until OLS this year - there was a 2.6 > release about once a month prior to OLS. Post OLS, it's now once > every three months or there abouts, which, IMO is far too long. I was thinking more about every week or two (ok, two releases in a day like we used to do in the 2.3 days was probably too freequent :-), but sure, even going to a once-a-month release cycle would be better than the current 3 months between 2.6.x releases. - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 0:24 ` Theodore Ts'o @ 2005-01-04 3:12 ` Thomas Graf 2005-01-04 5:33 ` Willy Tarreau 2005-01-04 15:34 ` Horst von Brand 0 siblings, 2 replies; 222+ messages in thread From: Thomas Graf @ 2005-01-04 3:12 UTC (permalink / raw) To: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel * Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 > On Mon, Jan 03, 2005 at 06:59:27PM +0000, Russell King wrote: > > It is also the model we used until OLS this year - there was a 2.6 > > release about once a month prior to OLS. Post OLS, it's now once > > every three months or there abouts, which, IMO is far too long. > > I was thinking more about every week or two (ok, two releases in a day > like we used to do in the 2.3 days was probably too freequent :-), but > sure, even going to a once-a-month release cycle would be better than > the current 3 months between 2.6.x releases. It definitely satifies many of the impatients but it doesn't solve the stability problem. Many bugs do not show up on developer machines until just right after the release (as you pointed out already). rc releases don't work out as expected due to various reasons, i think one of them is that rc releases don't get announced on the newstickers, extra work is required to patch the kernel etc. What about doing a test release just before releasing the final version. I'm not talking about yet another 2 weeks period but rather just 2-3 days and at most 2 bk releases in between. Full tarball must be available to make it as easy as possible. I'm quite sure there are a lot of willing testers simply too lazy to take a shot at every single rc release. If things get really worse and huge fixes are required the final release could be defered in favour of another rc cycle. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 3:12 ` Thomas Graf @ 2005-01-04 5:33 ` Willy Tarreau 2005-01-04 15:21 ` Adrian Bunk 2005-01-04 23:51 ` Bill Davidsen 2005-01-04 15:34 ` Horst von Brand 1 sibling, 2 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 5:33 UTC (permalink / raw) To: Thomas Graf Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, wli, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:12:29AM +0100, Thomas Graf wrote: > * Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 > > On Mon, Jan 03, 2005 at 06:59:27PM +0000, Russell King wrote: > > > It is also the model we used until OLS this year - there was a 2.6 > > > release about once a month prior to OLS. Post OLS, it's now once > > > every three months or there abouts, which, IMO is far too long. > > > > I was thinking more about every week or two (ok, two releases in a day > > like we used to do in the 2.3 days was probably too freequent :-), but > > sure, even going to a once-a-month release cycle would be better than > > the current 3 months between 2.6.x releases. > > It definitely satifies many of the impatients but it doesn't solve the > stability problem. Many bugs do not show up on developer machines until > just right after the release (as you pointed out already). rc releases > don't work out as expected due to various reasons, i think one of them > is that rc releases don't get announced on the newstickers, extra work > is required to patch the kernel etc. The problem with -rc is that there are two types of people : - the optimists who think "good, it's already rc. I'll download it and run it as soon as it's released" - the pessimists who think "I killed my machine twice with rc, let's leave it to other brave testers". These two problems are solvable with the same solution : no rc anymore. I agree with Ted. A version every week or 2 weeks is good. People will run random versions, some will report problems, others not. After that, you know the differences between exact releases, you don't have to parse 28 MB changes. And you can also ask them to upgrade or downgrade and quickly find where the bug entered. Others will find stable versions they will want to stick to for some time, which would also improve the bugs detection. At the time of 2.1, there were many people using it because there were known stable versions (thanks to Alan, btw). I remember having run an NFS server on 2.1.131-ac13 which was fast an rock solid at this time. Today's -rc system slows down testing. I also look at 2.4 : people only test 2.4 when there is a new release. Between releases, very few people such Adrian and a few others recompile a full kernel and report problems. When you don't have much free time, you don't want to spend it testing pre-releases which you think did not change from the previous one. > What about doing a test release > just before releasing the final version. I'm not talking about yet > another 2 weeks period but rather just 2-3 days and at most 2 bk > releases in between. Full tarball must be available to make it as > easy as possible. I'm quite sure there are a lot of willing testers > simply too lazy to take a shot at every single rc release. If things > get really worse and huge fixes are required the final release could > be defered in favour of another rc cycle. if it's 2-3 days, it's reasonnable I think. It should let some people report build problems just before the real one. Regards, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:33 ` Willy Tarreau @ 2005-01-04 15:21 ` Adrian Bunk 2005-01-04 15:58 ` William Lee Irwin III 2005-01-04 23:51 ` Bill Davidsen 1 sibling, 1 reply; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 15:21 UTC (permalink / raw) To: Willy Tarreau Cc: Thomas Graf, Theodore Ts'o, Bill Davidsen, Diego Calleja, wli, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 06:33:48AM +0100, Willy Tarreau wrote: > On Tue, Jan 04, 2005 at 04:12:29AM +0100, Thomas Graf wrote: > > * Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 > > > On Mon, Jan 03, 2005 at 06:59:27PM +0000, Russell King wrote: > > > > It is also the model we used until OLS this year - there was a 2.6 > > > > release about once a month prior to OLS. Post OLS, it's now once > > > > every three months or there abouts, which, IMO is far too long. > > > > > > I was thinking more about every week or two (ok, two releases in a day > > > like we used to do in the 2.3 days was probably too freequent :-), but > > > sure, even going to a once-a-month release cycle would be better than > > > the current 3 months between 2.6.x releases. > > > > It definitely satifies many of the impatients but it doesn't solve the > > stability problem. Many bugs do not show up on developer machines until > > just right after the release (as you pointed out already). rc releases > > don't work out as expected due to various reasons, i think one of them > > is that rc releases don't get announced on the newstickers, extra work > > is required to patch the kernel etc. > > The problem with -rc is that there are two types of people : > - the optimists who think "good, it's already rc. I'll download it and > run it as soon as it's released" > - the pessimists who think "I killed my machine twice with rc, let's leave > it to other brave testers". > > These two problems are solvable with the same solution : no rc anymore. > I agree with Ted. A version every week or 2 weeks is good. People will > run random versions, some will report problems, others not. After that, > you know the differences between exact releases, you don't have to parse > 28 MB changes. And you can also ask them to upgrade or downgrade and > quickly find where the bug entered. >... This was the model for development kernels, and it's usable for development kernels. The problem is that 28 MB in 9 weeks are 3 MB of changes every week. With such a weekly model, I fear the weekly kernels would be of very varying quality and never fully stable. Up to 2.4, kernel.org kernels were usually a good choice, but with such a model the only usable kernels in production environments will be distribution kernels that will contain the mixture of at least three "stable" kernel for getting a usable kernel. > Regards, > Willy cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:21 ` Adrian Bunk @ 2005-01-04 15:58 ` William Lee Irwin III 2005-01-04 17:38 ` Bernd Eckenfels 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 15:58 UTC (permalink / raw) To: Adrian Bunk Cc: Willy Tarreau, Thomas Graf, Theodore Ts'o, Bill Davidsen, Diego Calleja, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 06:33:48AM +0100, Willy Tarreau wrote: >> These two problems are solvable with the same solution : no rc anymore. >> I agree with Ted. A version every week or 2 weeks is good. People will >> run random versions, some will report problems, others not. After that, >> you know the differences between exact releases, you don't have to parse >> 28 MB changes. And you can also ask them to upgrade or downgrade and >> quickly find where the bug entered. On Tue, Jan 04, 2005 at 04:21:36PM +0100, Adrian Bunk wrote: > This was the model for development kernels, and it's usable for > development kernels. > The problem is that 28 MB in 9 weeks are 3 MB of changes every week. > With such a weekly model, I fear the weekly kernels would be of very > varying quality and never fully stable. Up to 2.4, kernel.org kernels > were usually a good choice, but with such a model the only usable > kernels in production environments will be distribution kernels that > will contain the mixture of at least three "stable" kernel for getting a > usable kernel. You could in principle base version numbers on external influences. In a 5-point decimal system, then 2.6.x.y.z would be released daily, 2.6.x.y.0 released every 10 days, 2.6.x.0.0 released every 100 days, and 2.7.0.0.0 released after 1000 days, and so on. Similarly for patches instead of days; an 8-point decimal system could be released based on the number of patches merged. 2.6.u.v.w.x.y.z would be "released" for every patch merged, 2.6.u.v.w.x.y.0 released for every 10 patches, 2.6.u.v.w.x.0.0 released for every 100 patches, 2.6.u.v.w.0.0.0 for every 1000 patches, 2.6.u.v.0.0.0.0 released after 10000 patches, 2.6.u.0.0.0.0.0 released after 100000 patches, and 2.7.0.0.0.0.0 released after 1000000 patches. Or perhaps a natural number merely counting the number of patches merged suffices. In both decimal systems, 0 <= u, v, w, x, y, z < 10. This will ultimately be defeated by anticipatory behavior regarding magic numbers (lots of 0's) and divergent trees, though I actually sort of like the 8-point decimal system based on patches merged or otherwise counting the number of patches merged, since it would provide a method of referring to all states of the tree, enabling binary search for bugs. But I highly doubt anything of these kinds will happen, and they're largely orthogonal to the issue of users being scared of how big the tree has gotten and not being able to understand that large numbers of patches must be interpreted relative to the size of the codebase instead of in absolute terms. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:58 ` William Lee Irwin III @ 2005-01-04 17:38 ` Bernd Eckenfels 0 siblings, 0 replies; 222+ messages in thread From: Bernd Eckenfels @ 2005-01-04 17:38 UTC (permalink / raw) To: linux-kernel In article <20050104155844.GI2708@holomorphy.com> you wrote: > You could in principle base version numbers on external influences. In a > 5-point decimal system, then 2.6.x.y.z would be released daily, 2.6.x.y.0 > released every 10 days, 2.6.x.0.0 released every 100 days, and 2.7.0.0.0 > released after 1000 days, and so on. the age does, however not say anything about the intention and preparations. The version numbers are mainly to communicate intention. Otherwise you can use a timestamp. And thats why I dont think it is good to keep innovations back by not opening a 2.7 tree nor is it good to caue trouble for users by merging a lot of new features to 2.6. A lot of media and books has explained the linux numbering scheme, this is valuable knowledge, dont dump it. Bernd ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:33 ` Willy Tarreau 2005-01-04 15:21 ` Adrian Bunk @ 2005-01-04 23:51 ` Bill Davidsen 2005-01-05 0:09 ` William Lee Irwin III 1 sibling, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 23:51 UTC (permalink / raw) To: Willy Tarreau Cc: Thomas Graf, Theodore Ts'o, Adrian Bunk, Diego Calleja, wli, aebr, solt2, linux-kernel Willy Tarreau wrote: > The problem with -rc is that there are two types of people : > - the optimists who think "good, it's already rc. I'll download it and > run it as soon as it's released" > - the pessimists who think "I killed my machine twice with rc, let's leave > it to other brave testers". > > These two problems are solvable with the same solution : no rc anymore. How does that help? The 2nd group won't D/L the -bk versions either, I certainly can see the logic in that. Someone said we used to have a development and stable series and only the best tested stuff from devel made it into stable. Then spoiled it by saying that stable and -mm did that now. The problem is that akpm is wearing both hats, he tries stuff in -mm, then decides it's stable for the mainline. There's no "cooling off" period for mainline when it only gets fixes, and no 2nd set of eyes doing triage between the fix and the feature. I would really like to see: a - more frequent releases in mainline b - point releases with ONLY fixes (ie. 2.6.11.1, etc) For (a) pick a release date, say the first and 16th of every month. On that date apply the latest -bk, any known fixes to problems (see below) and call it 2.6.N+1. For (b) a fix would be defined as a failure in an existing feature which causes correct operation without side effects. NOT "works better" but only to go from "doesn't work" to "works." Strict adherence to the "if it ain't broke don't fix it" rule. I would expect the average number to be zero, and only rarely more than one. That would keep people from having to wait more than a few weeks for a new feature or enhancement, or they could go to the -bk, and would give a clearly identified fix (only if needed) which is unlikely to break anything. I expect this to be ignored or disparaged like all other suggestions that anything resembling stability is needed. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 23:51 ` Bill Davidsen @ 2005-01-05 0:09 ` William Lee Irwin III 2005-01-05 18:30 ` Bill Davidsen 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-05 0:09 UTC (permalink / raw) To: Bill Davidsen Cc: Willy Tarreau, Thomas Graf, Theodore Ts'o, Adrian Bunk, Diego Calleja, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 06:51:15PM -0500, Bill Davidsen wrote: > I expect this to be ignored or disparaged like all other suggestions > that anything resembling stability is needed. No one is claiming stability is not needed. We are only debating the best way to go about accomplishing it. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 0:09 ` William Lee Irwin III @ 2005-01-05 18:30 ` Bill Davidsen 2005-01-05 18:56 ` William Lee Irwin III 0 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-05 18:30 UTC (permalink / raw) To: William Lee Irwin III Cc: Willy Tarreau, Thomas Graf, Theodore Ts'o, Adrian Bunk, Diego Calleja, aebr, solt2, linux-kernel William Lee Irwin III wrote: > On Tue, Jan 04, 2005 at 06:51:15PM -0500, Bill Davidsen wrote: > >>I expect this to be ignored or disparaged like all other suggestions >>that anything resembling stability is needed. > > > No one is claiming stability is not needed. We are only debating the > best way to go about accomplishing it. You fooled me, most of what I hear from developers sounds like "it's working fine" to me. Linus made it this way, he wants it this way, and if Alan Cox saying it isn't working well doesn't convince him, nothing users say is going to matter. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 18:30 ` Bill Davidsen @ 2005-01-05 18:56 ` William Lee Irwin III 2005-01-05 19:08 ` Chris Friesen 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-05 18:56 UTC (permalink / raw) To: Bill Davidsen Cc: Willy Tarreau, Thomas Graf, Theodore Ts'o, Adrian Bunk, Diego Calleja, aebr, solt2, linux-kernel William Lee Irwin III wrote: >> No one is claiming stability is not needed. We are only debating the >> best way to go about accomplishing it. On Wed, Jan 05, 2005 at 01:30:39PM -0500, Bill Davidsen wrote: > You fooled me, most of what I hear from developers sounds like "it's > working fine" to me. Linus made it this way, he wants it this way, and > if Alan Cox saying it isn't working well doesn't convince him, nothing > users say is going to matter. He did? Message-Id? -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 18:56 ` William Lee Irwin III @ 2005-01-05 19:08 ` Chris Friesen 0 siblings, 0 replies; 222+ messages in thread From: Chris Friesen @ 2005-01-05 19:08 UTC (permalink / raw) To: William Lee Irwin III Cc: Bill Davidsen, Willy Tarreau, Thomas Graf, Theodore Ts'o, Adrian Bunk, Diego Calleja, aebr, solt2, linux-kernel William Lee Irwin III wrote: > On Wed, Jan 05, 2005 at 01:30:39PM -0500, Bill Davidsen wrote: > >>You fooled me, most of what I hear from developers sounds like "it's >>working fine" to me. Linus made it this way, he wants it this way, and >>if Alan Cox saying it isn't working well doesn't convince him, nothing >>users say is going to matter. > > > He did? Message-Id? What he said was, "After 2.6.9-ac its clear that the long 2.6.9 process worked very badly. While 2.6.10 is looking much better its long period meant the allegedly "official" base kernel was a complete pile of insecure donkey turd for months. That doesn't hurt most vendor users but it does hurt those trying to do stuff on the base kernels very badly." Chris ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 3:12 ` Thomas Graf 2005-01-04 5:33 ` Willy Tarreau @ 2005-01-04 15:34 ` Horst von Brand 2005-01-04 21:19 ` Theodore Ts'o 1 sibling, 1 reply; 222+ messages in thread From: Horst von Brand @ 2005-01-04 15:34 UTC (permalink / raw) To: Thomas Graf Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Thomas Graf <tgraf@suug.ch> said: > * Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 [...] > > I was thinking more about every week or two (ok, two releases in a day > > like we used to do in the 2.3 days was probably too freequent :-), but > > sure, even going to a once-a-month release cycle would be better than > > the current 3 months between 2.6.x releases. > It definitely satifies many of the impatients but it doesn't solve the > stability problem. Many bugs do not show up on developer machines until > just right after the release (as you pointed out already). rc releases > don't work out as expected due to various reasons, i think one of them > is that rc releases don't get announced on the newstickers, extra work > is required to patch the kernel etc. What about doing a test release > just before releasing the final version. I'm not talking about yet > another 2 weeks period but rather just 2-3 days and at most 2 bk > releases in between. And most users will just wait the extra 2 or 3 days before timidly dipping in. Doesn't work. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:34 ` Horst von Brand @ 2005-01-04 21:19 ` Theodore Ts'o 2005-01-04 21:43 ` Willy Tarreau 2005-01-05 0:00 ` Bill Davidsen 0 siblings, 2 replies; 222+ messages in thread From: Theodore Ts'o @ 2005-01-04 21:19 UTC (permalink / raw) To: Horst von Brand Cc: Thomas Graf, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 12:34:09PM -0300, Horst von Brand wrote: > Thomas Graf <tgraf@suug.ch> said: > > * Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 > > > I was thinking more about every week or two (ok, two releases in a day > > > like we used to do in the 2.3 days was probably too freequent :-), but > > > sure, even going to a once-a-month release cycle would be better than > > > the current 3 months between 2.6.x releases. > > > It definitely satifies many of the impatients but it doesn't solve the > > stability problem. Many bugs do not show up on developer machines until > > just right after the release (as you pointed out already). rc releases > > don't work out as expected due to various reasons, i think one of them > > is that rc releases don't get announced on the newstickers, extra work > > is required to patch the kernel etc. What about doing a test release > > just before releasing the final version. I'm not talking about yet > > another 2 weeks period but rather just 2-3 days and at most 2 bk > > releases in between. > > And most users will just wait the extra 2 or 3 days before timidly dipping > in. Doesn't work. Some will start testing right away, others will wait 2 or 3 days first. And that's fine. Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good. The problem with the -rc releases is that we try to predict in advance which releases in advance will be stable, and we don't seem to be able to do a good job of that. If we do a release every week, my guess is that at least 1 in 3 releases will turn out to be stable enough for most purposes. But we won't know until after 2 or 3 days which releases will be the good ones. In practice, that's all the -rc releases are these days anyway (there are times when a 2.6.x-rcy release is more stable than 2.6.z). The problem is that since the -rc releases are called what they are called, they don't get enough testing. - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:19 ` Theodore Ts'o @ 2005-01-04 21:43 ` Willy Tarreau 2005-01-04 23:50 ` Gene Heskett 2005-01-06 18:08 ` Paul Rolland 2005-01-05 0:00 ` Bill Davidsen 1 sibling, 2 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 21:43 UTC (permalink / raw) To: Theodore Ts'o, Horst von Brand, Thomas Graf, Bill Davidsen, Adrian Bunk, Diego Calleja, wli, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:19:10PM -0500, Theodore Ts'o wrote: > The problem with the -rc releases is that we try to predict in advance > which releases in advance will be stable, and we don't seem to be able > to do a good job of that. I really like this description, it's the most accurate description I ever read of an -rc release. I wish you could convince Linus with it. The problem with -rc is that if we try to predict, it implies that we don't expect to count much on user reports. Then why do an -rc at all if we don't expect enough testings ? > If we do a release every week, my guess is > that at least 1 in 3 releases will turn out to be stable enough for > most purposes. But we won't know until after 2 or 3 days which > releases will be the good ones. That's always been my point, and one of the reasons why *some* of Alan's kernels work well. > In practice, that's all the -rc releases are these days anyway (there > are times when a 2.6.x-rcy release is more stable than 2.6.z). The > problem is that since the -rc releases are called what they are > called, they don't get enough testing. Perfectly true. I would add that with -rc releases, people only upgrade when we tell them that they can, while with more frequent releases, they upgrade when they *need* to, and can try several versions if the first one they pick does not work. Regards, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:43 ` Willy Tarreau @ 2005-01-04 23:50 ` Gene Heskett 2005-01-05 5:37 ` Willy Tarreau 2005-01-06 18:08 ` Paul Rolland 1 sibling, 1 reply; 222+ messages in thread From: Gene Heskett @ 2005-01-04 23:50 UTC (permalink / raw) To: linux-kernel Cc: Willy Tarreau, Theodore Ts'o, Horst von Brand, Thomas Graf, Bill Davidsen, Adrian Bunk, Diego Calleja, wli, aebr, solt2 On Tuesday 04 January 2005 16:43, Willy Tarreau wrote: >On Tue, Jan 04, 2005 at 04:19:10PM -0500, Theodore Ts'o wrote: >> The problem with the -rc releases is that we try to predict in >> advance which releases in advance will be stable, and we don't >> seem to be able to do a good job of that. > >I really like this description, it's the most accurate description I > ever read of an -rc release. I wish you could convince Linus with > it. > >The problem with -rc is that if we try to predict, it implies that > we don't expect to count much on user reports. Then why do an -rc > at all if we don't expect enough testings ? > >> If we do a release every week, my guess is >> that at least 1 in 3 releases will turn out to be stable enough >> for most purposes. But we won't know until after 2 or 3 days >> which releases will be the good ones. Thats what gets me, when approaching a point release, the -rc's come at almost daily intervals. Granted, if huge bug that really hurts shows up in -rc1, then -rc2 should follow as soon as *that* bug can be addressed. Then maybe in 3 days, something else shows up as a trend in the reports, go fix that and have -rc3 after say 5 days. Then sit and watch the folks like me, who usually do build the -rc stuff just so I can attempt to do my part in heading off the 2.6.8 fiasco. -rc(x) should have a lifetime of no less than a week of the rest of us beating on it before it gets its name changed to 2.6.xx. IMO, some of the stuff has moved to final in the last days with nowhere near enough time for this old fart to beat on it. The recent string of realtime stuff from Ingo ran very well indeed here, with one glaring exception that seemed to vary from reboot to reboot to exactly the same kernel, something was happening that destroyed the amanda client amandad, several days in a row. OTOH, after running flawlessly wth 33-04 for a week, the next and subsequent reboots to that kernel will now fail amanda 100% of the time. Now I'm using -ac2, but -ac1, for the limited time I ran it, worked very well too. But that doesn't mean I will not continue to build the -mm1-***.34-* series for testing also, because I will, if only to be able to report that so and so is broken. Basicly, if we who don't mind bleeding occasionally, don't have at least 48 hours to beat on a test kernel from the time we get around to building it, then there are going to be gotcha's that get by this testing and into the linus mainline. This does not portend well for progress in general, and like Dave Jones said, leads to lots of name-of-distro-specific patches. There should be an announced feature freeze at least 15 days ahead of a release, with nothing but bigfixes allowed in from that point, and the actual release made when its satisfactorially stable for everybody. I'd suggest not less than 7 days of most of us running it in the real world as an example of stable, with the only bug reports being generated by us laid at hardwares feet during that time. Not a hell of a lot you can do about randomly bum hardware. >That's always been my point, and one of the reasons why *some* of > Alan's kernels work well. > >> In practice, that's all the -rc releases are these days anyway >> (there are times when a 2.6.x-rcy release is more stable than >> 2.6.z). The problem is that since the -rc releases are called >> what they are called, they don't get enough testing. > >Perfectly true. I would add that with -rc releases, people only > upgrade when we tell them that they can, while with more frequent > releases, they upgrade when they *need* to, and can try several > versions if the first one they pick does not work. > >Regards, >Willy > I disagree Willy, if I see an -rc candidate, even if I'm following an interesting thread, like Ingo's patches, the rc will get built and run here, precisely so I can bitch if it doesn't work. I have an idea there are more like me who are interested as much in whats *new* as in how well does it run *my* stuff, and that you may possibly be undercounting us... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 23:50 ` Gene Heskett @ 2005-01-05 5:37 ` Willy Tarreau 2005-01-05 7:04 ` Gene Heskett 0 siblings, 1 reply; 222+ messages in thread From: Willy Tarreau @ 2005-01-05 5:37 UTC (permalink / raw) To: Gene Heskett Cc: linux-kernel, Theodore Ts'o, Horst von Brand, Thomas Graf, Bill Davidsen, Adrian Bunk, Diego Calleja, wli, aebr, solt2 On Tue, Jan 04, 2005 at 06:50:20PM -0500, Gene Heskett wrote: > I disagree Willy, if I see an -rc candidate, even if I'm following an > interesting thread, like Ingo's patches, the rc will get built and > run here, precisely so I can bitch if it doesn't work. I have an > idea there are more like me who are interested as much in whats *new* > as in how well does it run *my* stuff, and that you may possibly be > undercounting us... I do this too when I have time, but basically, the number of testers is limited to a small percent of the amount of LKML readers. This is why I say it does not get tested on a large scale. Seeing that even slashdot announces new releases, I suspect that releases are tested by 10 or 100 times more users than -rc. If we spend too much time waiting for a few hundred people to test -rc, it is with great deception that we discover that obvious bugs go to the final release unnoticed, like the NFS problem on 2.6.8 which hit me on the first boot. OK, I would have seen it in -rc, but I didn't have time to test -rc this time, and nobody else did enough testing on it. Result, -rc did not serve to catch this obvious one. I agree that a very few days should be better than absolutely nothing, at least to catch build problems, but we should not wait too long. Cheers, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 5:37 ` Willy Tarreau @ 2005-01-05 7:04 ` Gene Heskett 2005-01-05 8:33 ` Alexander E. Patrakov 0 siblings, 1 reply; 222+ messages in thread From: Gene Heskett @ 2005-01-05 7:04 UTC (permalink / raw) To: linux-kernel Cc: Willy Tarreau, Theodore Ts'o, Horst von Brand, Thomas Graf, Bill Davidsen, Adrian Bunk, Diego Calleja, wli, aebr, solt2 On Wednesday 05 January 2005 00:37, Willy Tarreau wrote: >On Tue, Jan 04, 2005 at 06:50:20PM -0500, Gene Heskett wrote: >> I disagree Willy, if I see an -rc candidate, even if I'm following >> an interesting thread, like Ingo's patches, the rc will get built >> and run here, precisely so I can bitch if it doesn't work. I have >> an idea there are more like me who are interested as much in whats >> *new* as in how well does it run *my* stuff, and that you may >> possibly be undercounting us... > >I do this too when I have time, but basically, the number of testers >is limited to a small percent of the amount of LKML readers. This is >why I say it does not get tested on a large scale. Seeing that even >slashdot announces new releases, I suspect that releases are tested >by 10 or 100 times more users than -rc. If we spend too much time >waiting for a few hundred people to test -rc, it is with great > deception that we discover that obvious bugs go to the final > release unnoticed, like the NFS problem on 2.6.8 which hit me on > the first boot. OK, I would have seen it in -rc, but I didn't have > time to test -rc this time, and nobody else did enough testing on > it. Result, -rc did not serve to catch this obvious one. I agree > that a very few days should be better than absolutely nothing, at > least to catch build problems, but we should not wait too long. > FWIW Willy, I did build a couple of the rc's there (coming up on 2.6.8), now of course entropy has set in and I couldn't prove it, the space has been reclaimed, whatever. My point is that the rc's didn't bite me, only the final, and it bit hard. Again, to TPTB, give us a few days to beat on it in the rc mode, then rename whats working to final. In the meantime, I'm back to beating on Ingo's stuff for the moment. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 7:04 ` Gene Heskett @ 2005-01-05 8:33 ` Alexander E. Patrakov 0 siblings, 0 replies; 222+ messages in thread From: Alexander E. Patrakov @ 2005-01-05 8:33 UTC (permalink / raw) To: linux-kernel Gene Heskett wrote: > FWIW Willy, I did build a couple of the rc's there (coming up on > 2.6.8), now of course entropy has set in and I couldn't prove it, the > space has been reclaimed, whatever. My point is that the rc's didn't > bite me, only the final, and it bit hard. Your point is correct: I still use 2.6.8-rc3 on dsa.physics.usu.ru, and NFS works perfectly in the internal 192.168.0.x network. So testing -rc* gives nothing here. > Again, to TPTB, give us a few days to beat on it in the rc mode, then > rename whats working to final. In the meantime, I'm back to beating > on Ingo's stuff for the moment. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:43 ` Willy Tarreau 2005-01-04 23:50 ` Gene Heskett @ 2005-01-06 18:08 ` Paul Rolland 2005-01-06 21:08 ` Bill Davidsen 1 sibling, 1 reply; 222+ messages in thread From: Paul Rolland @ 2005-01-06 18:08 UTC (permalink / raw) To: 'Willy Tarreau', 'Theodore Ts'o', 'Horst von Brand', 'Thomas Graf', 'Bill Davidsen', 'Adrian Bunk', 'Diego Calleja', wli, aebr, solt2, linux-kernel Hello, > > In practice, that's all the -rc releases are these days > anyway (there > > are times when a 2.6.x-rcy release is more stable than 2.6.z). The > > problem is that since the -rc releases are called what they are > > called, they don't get enough testing. > > Perfectly true. I would add that with -rc releases, people > only upgrade when > we tell them that they can, while with more frequent > releases, they upgrade > when they *need* to, and can try several versions if the > first one they pick > does not work. > I'd like to add some personal view : After 2.4.x, we have had a fork and 2.5.x was born, clearly identified as a development tree, so no stability guaranteed... Then one day came 2.6.0, and so on... I'm sorry, but I still cannot consider 2.6.x being any stable the way 2.4.x is today. Theodore wrote : > that at least 1 in 3 releases will turn out to be stable enough for > most purposes. But we won't know until after 2 or 3 days which > releases will be the good ones. I mostly agree. When a new 2.4.x comes out, I have a confident feeling about it, and there is no reason for me to wait 2 or 3 days to know if it's stable or not. It's part of a stable branch, and there are no major changes in it. 2.6.x, I still consider as a development branch. OK, people changed the numbering from 2.5.x to 2.6.x, but the number of changes still going on didn't really change. Just have a look at the numbers : patches are even bigger now that we are in a "stable" branch (4Mo average for 2.6 patch, gzip when we had a 1Mo average for 2.5 !) Yes, it is a wonderful playground. So let's keep it a playground, let number it 2.5.x again, and play with. Or let it be a stable branch, and do something for people needing a playground. Paul PS : on my personal computer, I'm a player, so I'm running 2.6.x, but don't expect me to put that on a production server for long... No way, not yet, not as long as the decision on what *really* is 2.6.x is clear. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 18:08 ` Paul Rolland @ 2005-01-06 21:08 ` Bill Davidsen 2005-01-06 22:50 ` Gene Heskett 2005-01-07 14:34 ` Paul Rolland 0 siblings, 2 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-06 21:08 UTC (permalink / raw) To: rol Cc: 'Willy Tarreau', 'Theodore Ts'o', 'Horst von Brand', 'Thomas Graf', 'Adrian Bunk', 'Diego Calleja', wli, aebr, solt2, linux-kernel Paul Rolland wrote: > Hello, > > >>>In practice, that's all the -rc releases are these days >> >>anyway (there >> >>>are times when a 2.6.x-rcy release is more stable than 2.6.z). The >>>problem is that since the -rc releases are called what they are >>>called, they don't get enough testing. >> >>Perfectly true. I would add that with -rc releases, people >>only upgrade when >>we tell them that they can, while with more frequent >>releases, they upgrade >>when they *need* to, and can try several versions if the >>first one they pick >>does not work. >> > > > I'd like to add some personal view : After 2.4.x, we have had a fork and > 2.5.x was born, clearly identified as a development tree, so no stability > guaranteed... Then one day came 2.6.0, and so on... > I'm sorry, but I still cannot consider 2.6.x being any stable the way 2.4.x > is today. > > Theodore wrote : > >>that at least 1 in 3 releases will turn out to be stable enough for >>most purposes. But we won't know until after 2 or 3 days which >>releases will be the good ones. > > > I mostly agree. When a new 2.4.x comes out, I have a confident feeling > about it, and there is no reason for me to wait 2 or 3 days to know if > it's stable or not. It's part of a stable branch, and there are no > major changes in it. > 2.6.x, I still consider as a development branch. OK, people changed the > numbering from 2.5.x to 2.6.x, but the number of changes still going on > didn't really change. Just have a look at the numbers : patches are even > bigger now that we are in a "stable" branch (4Mo average for 2.6 patch, > gzip when we had a 1Mo average for 2.5 !) I think you are quoting MB/release where MB/month would be much closer. Part of the "new development model" is that Linus only releases a new version the Thursday after the racoons tip over his garbage can. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 21:08 ` Bill Davidsen @ 2005-01-06 22:50 ` Gene Heskett 2005-01-07 14:34 ` Paul Rolland 1 sibling, 0 replies; 222+ messages in thread From: Gene Heskett @ 2005-01-06 22:50 UTC (permalink / raw) To: linux-kernel Cc: Bill Davidsen, rol, 'Willy Tarreau', 'Theodore Ts'o', 'Horst von Brand', 'Thomas Graf', 'Adrian Bunk', 'Diego Calleja', wli, aebr, solt2 On Thursday 06 January 2005 16:08, Bill Davidsen wrote: >Paul Rolland wrote: >> Hello, >> >>>>In practice, that's all the -rc releases are these days >>> >>>anyway (there >>> >>>>are times when a 2.6.x-rcy release is more stable than 2.6.z). >>>> The problem is that since the -rc releases are called what they >>>> are called, they don't get enough testing. >>> >>>Perfectly true. I would add that with -rc releases, people >>>only upgrade when >>>we tell them that they can, while with more frequent >>>releases, they upgrade >>>when they *need* to, and can try several versions if the >>>first one they pick >>>does not work. >> >> I'd like to add some personal view : After 2.4.x, we have had a >> fork and 2.5.x was born, clearly identified as a development tree, >> so no stability guaranteed... Then one day came 2.6.0, and so >> on... >> I'm sorry, but I still cannot consider 2.6.x being any stable the >> way 2.4.x is today. >> >> Theodore wrote : >>>that at least 1 in 3 releases will turn out to be stable enough >>> for most purposes. But we won't know until after 2 or 3 days >>> which releases will be the good ones. >> >> I mostly agree. When a new 2.4.x comes out, I have a confident >> feeling about it, and there is no reason for me to wait 2 or 3 >> days to know if it's stable or not. It's part of a stable branch, >> and there are no major changes in it. >> 2.6.x, I still consider as a development branch. OK, people >> changed the numbering from 2.5.x to 2.6.x, but the number of >> changes still going on didn't really change. Just have a look at >> the numbers : patches are even bigger now that we are in a >> "stable" branch (4Mo average for 2.6 patch, gzip when we had a 1Mo >> average for 2.5 !) > >I think you are quoting MB/release where MB/month would be much > closer. Part of the "new development model" is that Linus only > releases a new version the Thursday after the racoons tip over his > garbage can. Izzat what triggers it? Maybe we should all spend our nights coon hunting. Thats an old boys game that can be lucrative at times. I know one kid back in Nebraska that stuck them in the freezer till the price got good, and when he cleaned out the freezer, bought himself new Dodge Hemihead Charger for a high school graduation present. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 21:08 ` Bill Davidsen 2005-01-06 22:50 ` Gene Heskett @ 2005-01-07 14:34 ` Paul Rolland 1 sibling, 0 replies; 222+ messages in thread From: Paul Rolland @ 2005-01-07 14:34 UTC (permalink / raw) To: 'Bill Davidsen' Cc: 'Willy Tarreau', 'Theodore Ts'o', 'Horst von Brand', 'Thomas Graf', 'Adrian Bunk', 'Diego Calleja', wli, aebr, solt2, linux-kernel Hello, > I think you are quoting MB/release where MB/month would be > much closer. Yes, I do. > Part of the "new development model" is that Linus only releases a new > version the Thursday after the racoons tip over his garbage can. :-) Let free the racoons !!! Paul ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:19 ` Theodore Ts'o 2005-01-04 21:43 ` Willy Tarreau @ 2005-01-05 0:00 ` Bill Davidsen 2005-01-05 0:33 ` Theodore Ts'o 1 sibling, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-05 0:00 UTC (permalink / raw) To: Theodore Ts'o Cc: Horst von Brand, Thomas Graf, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Theodore Ts'o wrote: > On Tue, Jan 04, 2005 at 12:34:09PM -0300, Horst von Brand wrote: > >>Thomas Graf <tgraf@suug.ch> said: >> >>>* Theodore Ts'o <20050104002452.GA8045@thunk.org> 2005-01-03 19:24 >>> >>>>I was thinking more about every week or two (ok, two releases in a day >>>>like we used to do in the 2.3 days was probably too freequent :-), but >>>>sure, even going to a once-a-month release cycle would be better than >>>>the current 3 months between 2.6.x releases. >> >>>It definitely satifies many of the impatients but it doesn't solve the >>>stability problem. Many bugs do not show up on developer machines until >>>just right after the release (as you pointed out already). rc releases >>>don't work out as expected due to various reasons, i think one of them >>>is that rc releases don't get announced on the newstickers, extra work >>>is required to patch the kernel etc. What about doing a test release >>>just before releasing the final version. I'm not talking about yet >>>another 2 weeks period but rather just 2-3 days and at most 2 bk >>>releases in between. >> >>And most users will just wait the extra 2 or 3 days before timidly dipping >>in. Doesn't work. > > > Some will start testing right away, others will wait 2 or 3 days > first. And that's fine. Not all 2.6.x kernels will be good; but if > we do releases every 1 or 2 weeks, some of them *will* be good. The > problem with the -rc releases is that we try to predict in advance > which releases in advance will be stable, and we don't seem to be able > to do a good job of that. If we do a release every week, my guess is > that at least 1 in 3 releases will turn out to be stable enough for > most purposes. But we won't know until after 2 or 3 days which > releases will be the good ones. I'm not an optimist; I assumed -rc meant "only fixes" and was worth testing to get bugs identified. And that's what I would hope could happen again. If you think -fo (fixes only) is a better term I wouldn't argue. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 0:00 ` Bill Davidsen @ 2005-01-05 0:33 ` Theodore Ts'o 2005-01-05 18:40 ` Bill Davidsen 0 siblings, 1 reply; 222+ messages in thread From: Theodore Ts'o @ 2005-01-05 0:33 UTC (permalink / raw) To: Bill Davidsen Cc: Horst von Brand, Thomas Graf, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 07:00:32PM -0500, Bill Davidsen wrote: > I'm not an optimist; I assumed -rc meant "only fixes" and was worth > testing to get bugs identified. And that's what I would hope could > happen again. If you think -fo (fixes only) is a better term I wouldn't > argue. You mean you haven't been reading Linus's changelogs that are in the -rc release announcements? - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 0:33 ` Theodore Ts'o @ 2005-01-05 18:40 ` Bill Davidsen 0 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-05 18:40 UTC (permalink / raw) To: Theodore Ts'o Cc: Horst von Brand, Thomas Graf, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Theodore Ts'o wrote: > On Tue, Jan 04, 2005 at 07:00:32PM -0500, Bill Davidsen wrote: > >>I'm not an optimist; I assumed -rc meant "only fixes" and was worth >>testing to get bugs identified. And that's what I would hope could >>happen again. If you think -fo (fixes only) is a better term I wouldn't >>argue. > > > You mean you haven't been reading Linus's changelogs that are in the > -rc release announcements? I didn't mean lately, I meant back in the days when a feature freeze meant something else. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:36 ` Theodore Ts'o 2005-01-03 18:59 ` Russell King @ 2005-01-03 21:13 ` Horst von Brand 2005-01-03 21:35 ` Jesper Juhl 2005-01-05 9:27 ` Andrew Morton 2005-01-06 14:03 ` Paolo Ciarrocchi 2 siblings, 2 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-03 21:13 UTC (permalink / raw) To: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel "Theodore Ts'o" <tytso@mit.edu> said: [...] > The real key, as always, is getting users to download and test a > release. So another approach might be to shorten the time between > 2.6.x and 2.6.x+1 releases, so as to recreate more testing points, > without training people to wait for -bk1, -bk2, -rc1, etc. before > trying out the kernel code. This is the model that we used with the > 2.3.x series, where the time between releases was often quite short. > That worked fairly well, but we stopped doing it when the introduction > of BitKeeper eliminated the developer synch-up problem. But perhaps > we've gone too far between 2.6.x releases, and should shorten the time > in order to force more testing. Is there any estimate of the number of daily-straight-from-BK users? I'm one, haven't seen any trouble (thus silent up to here). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:13 ` Horst von Brand @ 2005-01-03 21:35 ` Jesper Juhl 2005-01-04 0:02 ` Bill Davidsen 2005-01-05 9:27 ` Andrew Morton 1 sibling, 1 reply; 222+ messages in thread From: Jesper Juhl @ 2005-01-03 21:35 UTC (permalink / raw) To: Horst von Brand Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005, Horst von Brand wrote: > "Theodore Ts'o" <tytso@mit.edu> said: > > [...] > > > The real key, as always, is getting users to download and test a > > release. So another approach might be to shorten the time between > > 2.6.x and 2.6.x+1 releases, so as to recreate more testing points, > > without training people to wait for -bk1, -bk2, -rc1, etc. before > > trying out the kernel code. This is the model that we used with the > > 2.3.x series, where the time between releases was often quite short. > > That worked fairly well, but we stopped doing it when the introduction > > of BitKeeper eliminated the developer synch-up problem. But perhaps > > we've gone too far between 2.6.x releases, and should shorten the time > > in order to force more testing. > > Is there any estimate of the number of daily-straight-from-BK users? I'm > one, haven't seen any trouble (thus silent up to here). I'm another. Every morning when I turn on my machine I grab the latest -bk, build it with my usual config, install that kernel and reboot, then use that as my "kernel of the day". I do this on both my home and work box (well, the work box only does this on mondays) and I've had very little trouble so far. -- Jesper Juhl ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:35 ` Jesper Juhl @ 2005-01-04 0:02 ` Bill Davidsen 2005-01-04 3:32 ` Gene Heskett 0 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 0:02 UTC (permalink / raw) To: Jesper Juhl Cc: Horst von Brand, Theodore Ts'o, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005, Jesper Juhl wrote: > On Mon, 3 Jan 2005, Horst von Brand wrote: > > > "Theodore Ts'o" <tytso@mit.edu> said: > > > > [...] > > > > > The real key, as always, is getting users to download and test a > > > release. So another approach might be to shorten the time between > > > 2.6.x and 2.6.x+1 releases, so as to recreate more testing points, > > > without training people to wait for -bk1, -bk2, -rc1, etc. before > > > trying out the kernel code. This is the model that we used with the > > > 2.3.x series, where the time between releases was often quite short. > > > That worked fairly well, but we stopped doing it when the introduction > > > of BitKeeper eliminated the developer synch-up problem. But perhaps > > > we've gone too far between 2.6.x releases, and should shorten the time > > > in order to force more testing. > > > > Is there any estimate of the number of daily-straight-from-BK users? I'm > > one, haven't seen any trouble (thus silent up to here). > > I'm another. Every morning when I turn on my machine I grab the latest > -bk, build it with my usual config, install that kernel and reboot, then > use that as my "kernel of the day". I do this on both my home and work > box (well, the work box only does this on mondays) and I've had very > little trouble so far. Somewhere there is a pawn shop with only one big brass ball, and I know where the other two are... -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 0:02 ` Bill Davidsen @ 2005-01-04 3:32 ` Gene Heskett 0 siblings, 0 replies; 222+ messages in thread From: Gene Heskett @ 2005-01-04 3:32 UTC (permalink / raw) To: linux-kernel Cc: Bill Davidsen, Jesper Juhl, Horst von Brand, Theodore Ts'o, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2 On Monday 03 January 2005 19:02, Bill Davidsen wrote: [...] >Somewhere there is a pawn shop with only one big brass ball, and I > know where the other two are... Yeah, well, one does get used to carrying them around after a while Bill. Not quite in this context, but I have been asked how in hell I can sit so comfortably by witnesses, after just having torn some $10k piece of broadcast gear down, and then put it back together again, and it works when I'm done, something it didn't do whan I started... And thats what it does take sometimes, big (brass?) balls. And thats what keeps me lurking here and playing with new kernels all the time at age 70. Currently running 2.6.10-ac2. But, I have to agree with the general tone of this thread, we do not IMO have, as 2005 opens up, a kernel code base that runs on everything its supposed to run on, not by a long shot. And to apply the 'stable' label to this is stretching the point like a used car salesman selling a 49 nash. Don't get me wrong either, I choose to do this and generally speaking I'm having a lot of fun trying to keep up with the various new kernels. And if something doesn't work, you all hear from me fairly quick, and thats how stability is achieved, by folks like me taking the chance and getting burnt. I may not know how to fix it cause this ain't an amiga anymore, but I can be the remote hands to furnish the clues those of you who do code in your sleep can fix. Its moving way too fast in terms of new features to ever get to a 'stable' point, and I think it is now time to fork things off into a 2.7 tree, while 2.6 continues on till the individual distros don't have the huge menu of patches they are now applying to their own kernels, as everything worth doing in 2.6 has made it to the kernel.org downloadable code by the time it gets to 2.6.20 or so. And thats what I'd call stable, stable like the 2.4.20-sthg-or-other-ck6 I've been running on my firewall box for years. It 'just works' in between hardware glitches... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:13 ` Horst von Brand 2005-01-03 21:35 ` Jesper Juhl @ 2005-01-05 9:27 ` Andrew Morton 2005-01-05 10:57 ` Barry K. Nathan 1 sibling, 1 reply; 222+ messages in thread From: Andrew Morton @ 2005-01-05 9:27 UTC (permalink / raw) To: Horst von Brand Cc: tytso, davidsen, bunk, diegocg, willy, wli, aebr, solt2, linux-kernel Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > Is there any estimate of the number of daily-straight-from-BK users? fwiw, it seems that there were ~1200 downloads of 2.6.10-rc2-mm4 from kernel.org. Almost all via http - only 20 downloads appear in vsftpd.log, which seems fishy. The number of downloads via mirrors is unknown. (randomly chosen) 2.6.10-rc3-bk2 had ~750 downloads from kernel.org, only eight of them via ftp (?). bottom line: the number of testers seems to be in the 1000-2000 range. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 9:27 ` Andrew Morton @ 2005-01-05 10:57 ` Barry K. Nathan 2005-01-06 3:15 ` Ed Tomlinson 0 siblings, 1 reply; 222+ messages in thread From: Barry K. Nathan @ 2005-01-05 10:57 UTC (permalink / raw) To: Andrew Morton Cc: Horst von Brand, tytso, davidsen, bunk, diegocg, willy, wli, aebr, solt2, linux-kernel On Wed, Jan 05, 2005 at 01:27:09AM -0800, Andrew Morton wrote: > Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > > > Is there any estimate of the number of daily-straight-from-BK users? > > fwiw, it seems that there were ~1200 downloads of 2.6.10-rc2-mm4 from > kernel.org. Almost all via http - only 20 downloads appear in vsftpd.log, > which seems fishy. The number of downloads via mirrors is unknown. The front-page link to the "latest -mm patch" is http. Also, people like me who use wget and lftp probably prefer to download using http, since with those clients it ends up working like FTP but without wasting time on anonymous login (i.e. it happens to be faster). -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 10:57 ` Barry K. Nathan @ 2005-01-06 3:15 ` Ed Tomlinson 0 siblings, 0 replies; 222+ messages in thread From: Ed Tomlinson @ 2005-01-06 3:15 UTC (permalink / raw) To: Barry K. Nathan Cc: Andrew Morton, Horst von Brand, tytso, davidsen, bunk, diegocg, willy, wli, aebr, solt2, linux-kernel On Wednesday 05 January 2005 05:57, Barry K. Nathan wrote: > On Wed, Jan 05, 2005 at 01:27:09AM -0800, Andrew Morton wrote: > > Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > > > > > Is there any estimate of the number of daily-straight-from-BK users? > > > > fwiw, it seems that there were ~1200 downloads of 2.6.10-rc2-mm4 from > > kernel.org. Almost all via http - only 20 downloads appear in vsftpd.log, > > which seems fishy. The number of downloads via mirrors is unknown. > > The front-page link to the "latest -mm patch" is http. Also, people like > me who use wget and lftp probably prefer to download using http, since > with those clients it ends up working like FTP but without wasting time on > anonymous login (i.e. it happens to be faster). Or those like me who use bk pull... Maybe we should setup an 'opt in / open logging' type concept so we can know how many people test a release. It would be very interesting to see if the number of more testers (or tester days) does lead to a more stable release. Ed Tomlinson ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 18:36 ` Theodore Ts'o 2005-01-03 18:59 ` Russell King 2005-01-03 21:13 ` Horst von Brand @ 2005-01-06 14:03 ` Paolo Ciarrocchi 2005-01-06 16:34 ` Ramón Rey Vicente ` (2 more replies) 2 siblings, 3 replies; 222+ messages in thread From: Paolo Ciarrocchi @ 2005-01-06 14:03 UTC (permalink / raw) To: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005 13:36:21 -0500, Theodore Ts'o <tytso@mit.edu> wrote: > On Mon, Jan 03, 2005 at 12:18:36PM -0500, Bill Davidsen wrote: > > I have to say that with a few minor exceptions the introduction of new > > features hasn't created long term (more than a few days) of problems. And > > we have had that in previous stable versions as well. New features > > themselves may not be totally stable, but in most cases they don't break > > existing features, or are fixed in bk1 or bk2. What worries me is removing > > features deliberately, and I won't beat that dead horse again, I've said > > my piece. > > Indeed. Part of the problem is that we don't get that much testing > with the rc* releases, so there are a lot of problems that don't get > noticed until after 2.6.x ships. This has been true for both 2.6.9 > and 2.6.10. My personal practice is to never run with 2.6.x release, > but wait for 2.6.x plus one or 2 days (i.e. bk1 or bk2). The problems > with this approach are that (1) out-of-tree patches against official > versions of the kernel (i.e., things like the mppc/mppe patch) don't > necessarly apply cleanly, and (2) other more destablizing patches get > folded in right after 2.6.x ships, so there is a chance bk1 or bk2 may > not be stable. What's wrong in keeping the release management as is now plus introducing a 2.6.X.Y series of kernels ? In short: http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 Best, Paolo Ciarrocchi ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 14:03 ` Paolo Ciarrocchi @ 2005-01-06 16:34 ` Ramón Rey Vicente 2005-01-06 19:32 ` Adrian Bunk 2005-01-06 20:48 ` Bill Davidsen 2 siblings, 0 replies; 222+ messages in thread From: Ramón Rey Vicente @ 2005-01-06 16:34 UTC (permalink / raw) To: Paolo Ciarrocchi Cc: Theodore Ts'o, Bill Davidsen, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paolo Ciarrocchi wrote: | What's wrong in keeping the release management as is now plus | introducing a 2.6.X.Y series of kernels ? | | In short: | http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 I think this is the better "solution". Maybe rename -ac series? :) - -- Ramón Rey Vicente <ramon.rey en hispalinux.es> JID rreylinux@jabber.org - GPG public key id 0x9F28E377 GPG Fingerprint 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377 Planet AUGCyL - http://augcyl.org/planet/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3Wh9w4Wp058o43cRAmemAJwNj4L8cCzzYfy1P0EH/FJ4AQmmugCgvJVg 7vFYqr3noBwxH7lxKaEhFNg= =XfxG -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 14:03 ` Paolo Ciarrocchi 2005-01-06 16:34 ` Ramón Rey Vicente @ 2005-01-06 19:32 ` Adrian Bunk 2005-01-06 19:58 ` Diego Calleja 2005-01-06 22:31 ` Bill Davidsen 2005-01-06 20:48 ` Bill Davidsen 2 siblings, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-06 19:32 UTC (permalink / raw) To: Paolo Ciarrocchi Cc: Theodore Ts'o, Bill Davidsen, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Thu, Jan 06, 2005 at 03:03:26PM +0100, Paolo Ciarrocchi wrote: > > What's wrong in keeping the release management as is now plus > introducing a 2.6.X.Y series of kernels ? > > In short: > http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 Currently (2.6.10), there would have been 11 such branches. If a security vulnerability was found today, this meant backporting and applying the patch to 11 different kernel versions, the oldest one being more than one year old. With more 2.6 versions, there would be even more branches, and the oldest ones becoming more and more different from the current codebase. You could at some point start dropping the oldest branches, but this would mean a migration to a more recent branch for all users of this branch. OTOH, if you migrated relatively late at 2.4.17 to the 2.4 branch, this branch is still actively maintained today, more than 3 years later. > Best, > Paolo Ciarrocchi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 19:32 ` Adrian Bunk @ 2005-01-06 19:58 ` Diego Calleja 2005-01-06 22:31 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Diego Calleja @ 2005-01-06 19:58 UTC (permalink / raw) To: Adrian Bunk Cc: paolo.ciarrocchi, tytso, davidsen, diegocg, willy, wli, aebr, solt2, linux-kernel El Thu, 6 Jan 2005 20:32:14 +0100 Adrian Bunk <bunk@stusta.de> escribió: > If a security vulnerability was found today, this meant backporting and > applying the patch to 11 different kernel versions, the oldest one being > more than one year old. Personally I'd be happier if security issues would trigger a new release. I mean, if a security issue shows up in 2.6.10, release 2.6.11, with 2.6.11 being 2.6.10 + the patch for the security issues, and at the same time release 2.6.12-rcwhatever with all the patches that were going to be 2.6.11. Marcelo has done this at least one time in 2.4, but in 2.6 serious issues have been found and the patch has been available for weeks but the "latest stable version" in kernel.org didn't have the patch for that time. Vendors will fix it themselves true, but lots of people still use whatever it's available at kernel.org, and linux always will be that way (hopefully), so it'd be nice to get fast "official" updates to those issues. Currently, you've to patch it yourself, and for that you usually have to read it in some linux news page and extract the patch from a lkml mirror (kernel.org don't warns of any security issue at all) so lots of people don't notice that there's any security issue because currently there's no way of notifying them. However a new kernel release would have the desired effect - the user updates his kernel because he knows there's something to fix. And if nobody wants those "security-only" releases at least a special section in kernel.org would be nice, slashdot is not really a good way to get security notifications and not all people wants to subscribe to a mailing list. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 19:32 ` Adrian Bunk 2005-01-06 19:58 ` Diego Calleja @ 2005-01-06 22:31 ` Bill Davidsen 2005-01-07 8:33 ` Paolo Ciarrocchi 1 sibling, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-06 22:31 UTC (permalink / raw) To: Adrian Bunk Cc: Paolo Ciarrocchi, Theodore Ts'o, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Adrian Bunk wrote: > On Thu, Jan 06, 2005 at 03:03:26PM +0100, Paolo Ciarrocchi wrote: > >>What's wrong in keeping the release management as is now plus >>introducing a 2.6.X.Y series of kernels ? >> >>In short: >>http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 > > > Currently (2.6.10), there would have been 11 such branches. > > If a security vulnerability was found today, this meant backporting and > applying the patch to 11 different kernel versions, the oldest one being > more than one year old. > > With more 2.6 versions, there would be even more branches, and the > oldest ones becoming more and more different from the current codebase. > > You could at some point start dropping the oldest branches, but this > would mean a migration to a more recent branch for all users of this > branch. > > OTOH, if you migrated relatively late at 2.4.17 to the 2.4 branch, this > branch is still actively maintained today, more than 3 years later. I don't think that's what he meant (I hope not) and I know it's not what I had in mind. What I was suggesting is that until 2.6.11 comes out, all patches which are fixes (existing feature doesn't work, oops, security issues, or other "unusable with the problem triggered" cases) would go into 2.6.10.N, where N would be a small number unless we had another 100 day release cycle. This wouldn't be a blank check to maintain a version forever, and since the patch from 2.6.10 to 2.6.11 will be against a 2.6.10 base there will not be a lot of rediffing beyond what's needed if someone submits a patch against -mm or -bk or whatever. It's not zero work, but it's small work. When 2.6.11 came out, the 2.6.10.N effort would stop, or perhaps continue for a short time in the unlikely event that some huge security hole was found within the first week or so after 2.6.11. That seems to happen at most a few times a year. In general once 2.6.N+1 is out, 2.6.N.x is frozen. Since the mechanism is already in place to generate -bk versions against both the base and previous -bk version, I don't see any reason why both can't be available. Unless I'm missing something this would involve only a small amount of work which wouldn't be done anyway, and would provide a bugfix path which people could use with a high probability of unwanted side effects. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 22:31 ` Bill Davidsen @ 2005-01-07 8:33 ` Paolo Ciarrocchi 0 siblings, 0 replies; 222+ messages in thread From: Paolo Ciarrocchi @ 2005-01-07 8:33 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Theodore Ts'o, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Thu, 06 Jan 2005 17:31:46 -0500, Bill Davidsen <davidsen@tmr.com> wrote: > Adrian Bunk wrote: > > On Thu, Jan 06, 2005 at 03:03:26PM +0100, Paolo Ciarrocchi wrote: > > > >>What's wrong in keeping the release management as is now plus > >>introducing a 2.6.X.Y series of kernels ? > >> > >>In short: > >>http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 > > > > > > Currently (2.6.10), there would have been 11 such branches. > > > > If a security vulnerability was found today, this meant backporting and > > applying the patch to 11 different kernel versions, the oldest one being > > more than one year old. > > > > With more 2.6 versions, there would be even more branches, and the > > oldest ones becoming more and more different from the current codebase. > > > > You could at some point start dropping the oldest branches, but this > > would mean a migration to a more recent branch for all users of this > > branch. > > > > OTOH, if you migrated relatively late at 2.4.17 to the 2.4 branch, this > > branch is still actively maintained today, more than 3 years later. > > I don't think that's what he meant (I hope not) and I know it's not what > I had in mind. What I was suggesting is that until 2.6.11 comes out, all > patches which are fixes (existing feature doesn't work, oops, security > issues, or other "unusable with the problem triggered" cases) would go > into 2.6.10.N, where N would be a small number unless we had another 100 > day release cycle. Yes, that is what I meant. -- Paolo Personal home page: www.ciarrocchi.tk ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 14:03 ` Paolo Ciarrocchi 2005-01-06 16:34 ` Ramón Rey Vicente 2005-01-06 19:32 ` Adrian Bunk @ 2005-01-06 20:48 ` Bill Davidsen 2 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-06 20:48 UTC (permalink / raw) To: Paolo Ciarrocchi Cc: Theodore Ts'o, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Paolo Ciarrocchi wrote: > What's wrong in keeping the release management as is now plus > introducing a 2.6.X.Y series of kernels ? > > In short: > http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2 > > Best, > Paolo Ciarrocchi > That's essentially what I said in <41DB2BF3.2010103@tmr.com>, and the only response I got questioned my mention that Alan Cox didn't think the process was working well. I suggested a fixed and shorter release schedule as well as point releases, but point releases are the more improtant, I believe. I also said I didn't think it was going to change... -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:18 ` Bill Davidsen 2005-01-03 18:04 ` Adrian Bunk 2005-01-03 18:36 ` Theodore Ts'o @ 2005-01-03 19:28 ` Jens Axboe 2005-01-03 22:39 ` Bill Davidsen 2005-01-03 21:03 ` Horst von Brand 2005-01-04 21:04 ` Pavel Machek 4 siblings, 1 reply; 222+ messages in thread From: Jens Axboe @ 2005-01-03 19:28 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03 2005, Bill Davidsen wrote: > SCSI command filtering - while I totally support the idea (and always > have), I miss running cdrecord as a normal user. Multisession doesn't work > as a normal user (at least if you follow the man page) because only root > can use -msinfo. There's also some raw mode which got a permission denied, > don't remember as I was trying something not doing production stuff. So look at dmesg, the kernel will dump the failed command. Send the result here and we can add that command, done deal. 2.6.10 will do this by default. -- Jens Axboe ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 19:28 ` Jens Axboe @ 2005-01-03 22:39 ` Bill Davidsen 2005-01-04 7:46 ` Jens Axboe 0 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 22:39 UTC (permalink / raw) To: Jens Axboe Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Jens Axboe wrote: > On Mon, Jan 03 2005, Bill Davidsen wrote: > >>SCSI command filtering - while I totally support the idea (and always >>have), I miss running cdrecord as a normal user. Multisession doesn't work >>as a normal user (at least if you follow the man page) because only root >>can use -msinfo. There's also some raw mode which got a permission denied, >>don't remember as I was trying something not doing production stuff. > > > So look at dmesg, the kernel will dump the failed command. Send the > result here and we can add that command, done deal. 2.6.10 will do this > by default. > Is this enough? I'm building 2.6.10-bk6 on a spare machine to try this on a system with a "scsi" CD interface via USB. The commands appear to go through the same process, but I'll know in an hour or so. I was going to look these up before suggesting that they were trustworthy, but I'll take this as a offer to do that and accept! Obviously security comes first, if these are not trustworthy I won't argue for their inclusion. kjournald starting. Commit interval 5 seconds EXT3 FS on hdb1, internal journal EXT3-fs: mounted filesystem with ordered data mode. scsi: unknown opcode 0x01 scsi: unknown opcode 0x55 scsi: unknown opcode 0x1e scsi: unknown opcode 0x35 -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:39 ` Bill Davidsen @ 2005-01-04 7:46 ` Jens Axboe 2005-01-04 18:34 ` Bill Davidsen 0 siblings, 1 reply; 222+ messages in thread From: Jens Axboe @ 2005-01-04 7:46 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, Jan 03 2005, Bill Davidsen wrote: > Jens Axboe wrote: > >On Mon, Jan 03 2005, Bill Davidsen wrote: > > > >>SCSI command filtering - while I totally support the idea (and always > >>have), I miss running cdrecord as a normal user. Multisession doesn't work > >>as a normal user (at least if you follow the man page) because only root > >>can use -msinfo. There's also some raw mode which got a permission denied, > >>don't remember as I was trying something not doing production stuff. > > > > > >So look at dmesg, the kernel will dump the failed command. Send the > >result here and we can add that command, done deal. 2.6.10 will do this > >by default. > > > > Is this enough? I'm building 2.6.10-bk6 on a spare machine to try this > on a system with a "scsi" CD interface via USB. The commands appear to > go through the same process, but I'll know in an hour or so. > > I was going to look these up before suggesting that they were > trustworthy, but I'll take this as a offer to do that and accept! > Obviously security comes first, if these are not trustworthy I won't > argue for their inclusion. > > kjournald starting. Commit interval 5 seconds > EXT3 FS on hdb1, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > scsi: unknown opcode 0x01 > scsi: unknown opcode 0x55 > scsi: unknown opcode 0x1e > scsi: unknown opcode 0x35 You don't have write permissions on the device. -- Jens Axboe ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 7:46 ` Jens Axboe @ 2005-01-04 18:34 ` Bill Davidsen 0 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 18:34 UTC (permalink / raw) To: Jens Axboe Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Tue, 4 Jan 2005, Jens Axboe wrote: > On Mon, Jan 03 2005, Bill Davidsen wrote: > > Jens Axboe wrote: > > >On Mon, Jan 03 2005, Bill Davidsen wrote: > > > > > >>SCSI command filtering - while I totally support the idea (and always > > >>have), I miss running cdrecord as a normal user. Multisession doesn't work > > >>as a normal user (at least if you follow the man page) because only root > > >>can use -msinfo. There's also some raw mode which got a permission denied, > > >>don't remember as I was trying something not doing production stuff. > > > > > > > > >So look at dmesg, the kernel will dump the failed command. Send the > > >result here and we can add that command, done deal. 2.6.10 will do this > > >by default. > > > > > > > Is this enough? I'm building 2.6.10-bk6 on a spare machine to try this > > on a system with a "scsi" CD interface via USB. The commands appear to > > go through the same process, but I'll know in an hour or so. > > > > I was going to look these up before suggesting that they were > > trustworthy, but I'll take this as a offer to do that and accept! > > Obviously security comes first, if these are not trustworthy I won't > > argue for their inclusion. > > > > kjournald starting. Commit interval 5 seconds > > EXT3 FS on hdb1, internal journal > > EXT3-fs: mounted filesystem with ordered data mode. > > scsi: unknown opcode 0x01 > > scsi: unknown opcode 0x55 > > scsi: unknown opcode 0x1e > > scsi: unknown opcode 0x35 > > You don't have write permissions on the device. Nope, /dev/hdc is owned by davidsen, group disk, permissions 660. I am me and in group disk as well. And I can write single session CDs without error, it's only the use -msinfo which fails, the first burn works just fine. I think all of that but the permissions stuff was in the original post... See the man page and/or README.multi if you don't use multisession, -msinfo just returns the size of the initial session(s) already written. I can aslo write as me using growisofs, but it only works on DVD, kind of overkill for what I'm doing. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:18 ` Bill Davidsen ` (2 preceding siblings ...) 2005-01-03 19:28 ` Jens Axboe @ 2005-01-03 21:03 ` Horst von Brand 2005-01-03 23:42 ` Bill Davidsen 2005-01-04 21:04 ` Pavel Machek 4 siblings, 1 reply; 222+ messages in thread From: Horst von Brand @ 2005-01-03 21:03 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Bill Davidsen <davidsen@tmr.com> said: [...] > I have to say that with a few minor exceptions the introduction of new > features hasn't created long term (more than a few days) of problems. And > we have had that in previous stable versions as well. New features > themselves may not be totally stable, but in most cases they don't break > existing features, or are fixed in bk1 or bk2. What worries me is removing > features deliberately, and I won't beat that dead horse again, I've said > my piece. > > The "few minor exceptions:" > > SCSI command filtering - while I totally support the idea (and always > have), I miss running cdrecord as a normal user. Multisession doesn't work > as a normal user (at least if you follow the man page) because only root > can use -msinfo. There's also some raw mode which got a permission denied, > don't remember as I was trying something not doing production stuff. It had very nasty security problems. After a short discussion here, it was deemed much more important to have a secure system than a (very minor) convenience. AFAIU, the patch was backported to 2.4 (or should be ASAP). > APM vs. ACPI - shutdown doesn't reliably power down about half of the > machines I use, and all five laptops have working suspend and non-working > resume. APM seems to be pretty unsupported beyond "use ACPI for that." Many never machines just don't have APM. > None of these would prevent using 2.6 if there were some feature not in > 2.4 which gave a reason to switch. Like 2.6 works fine, 2.4 has no chance on some machines? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:03 ` Horst von Brand @ 2005-01-03 23:42 ` Bill Davidsen 2005-01-04 17:31 ` Rahul Karnik 0 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 23:42 UTC (permalink / raw) To: Horst von Brand Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005, Horst von Brand wrote: > Bill Davidsen <davidsen@tmr.com> said: > > [...] > > > I have to say that with a few minor exceptions the introduction of new > > features hasn't created long term (more than a few days) of problems. And > > we have had that in previous stable versions as well. New features > > themselves may not be totally stable, but in most cases they don't break > > existing features, or are fixed in bk1 or bk2. What worries me is removing > > features deliberately, and I won't beat that dead horse again, I've said > > my piece. > > > > The "few minor exceptions:" > > > > SCSI command filtering - while I totally support the idea (and always > > have), I miss running cdrecord as a normal user. Multisession doesn't work > > as a normal user (at least if you follow the man page) because only root > > can use -msinfo. There's also some raw mode which got a permission denied, > > don't remember as I was trying something not doing production stuff. > > It had very nasty security problems. After a short discussion here, it was > deemed much more important to have a secure system than a (very minor) > convenience. AFAIU, the patch was backported to 2.4 (or should be ASAP). As I said, I supported that, but the check is done in such a way that not even making the application setuid helps, so users can't burn multisession (and some other obscure forms of) CDs. > > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > > machines I use, and all five laptops have working suspend and non-working > > resume. APM seems to be pretty unsupported beyond "use ACPI for that." > > Many never machines just don't have APM. What's your point? I'm damn sure there are more machines with APM than 386 CPUs, AHA1540 SCSI controllers, or a lot of other supported stuff. Most machines which have APM at all have a functional power off capability, which is a desirable thing for most people. > > > None of these would prevent using 2.6 if there were some feature not in > > 2.4 which gave a reason to switch. > > Like 2.6 works fine, 2.4 has no chance on some machines? Haven't hit one of those yet, although after you get away from Intel I'm sure there are some. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 23:42 ` Bill Davidsen @ 2005-01-04 17:31 ` Rahul Karnik 2005-01-04 18:44 ` Bill Davidsen 0 siblings, 1 reply; 222+ messages in thread From: Rahul Karnik @ 2005-01-04 17:31 UTC (permalink / raw) To: Bill Davidsen Cc: Horst von Brand, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Mon, 3 Jan 2005 18:42:24 -0500 (EST), Bill Davidsen <davidsen@tmr.com> wrote: > On Mon, 3 Jan 2005, Horst von Brand wrote: > > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > > > machines I use, and all five laptops have working suspend and non-working > > > resume. APM seems to be pretty unsupported beyond "use ACPI for that." > > > > Many never machines just don't have APM. > > What's your point? I'm damn sure there are more machines with APM than 386 > CPUs, AHA1540 SCSI controllers, or a lot of other supported stuff. Most > machines which have APM at all have a functional power off capability, > which is a desirable thing for most people. The point is not that the kernel should not support APM because it is superceded by ACPI, but that your laptops do not support APM properly. Did they work correctly with APM in 2.4? If so, we have a regression; otherwise complain to the laptop vendor, they do not consider APM to be a high enough priority. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 17:31 ` Rahul Karnik @ 2005-01-04 18:44 ` Bill Davidsen 0 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 18:44 UTC (permalink / raw) To: Rahul Karnik Cc: Horst von Brand, Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Tue, 4 Jan 2005, Rahul Karnik wrote: > On Mon, 3 Jan 2005 18:42:24 -0500 (EST), Bill Davidsen <davidsen@tmr.com> wrote: > > On Mon, 3 Jan 2005, Horst von Brand wrote: > > > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > > > > machines I use, and all five laptops have working suspend and non-working > > > > resume. APM seems to be pretty unsupported beyond "use ACPI for that." > > > > > > Many never machines just don't have APM. > > > > What's your point? I'm damn sure there are more machines with APM than 386 > > CPUs, AHA1540 SCSI controllers, or a lot of other supported stuff. Most > > machines which have APM at all have a functional power off capability, > > which is a desirable thing for most people. > > The point is not that the kernel should not support APM because it is > superceded by ACPI, but that your laptops do not support APM properly. > Did they work correctly with APM in 2.4? If so, we have a regression; > otherwise complain to the laptop vendor, they do not consider APM to > be a high enough priority. > The ThinkPad, Toshiba, and both Dells work correctly for both shutdown and suspend (via the apm -s) using 2.4. I haven't tried the ACER, it's new and started life with FC2 and a 2.6 kernel. It does power down correctly, and suspend, but doesn't resume so it's not very useful. I would complain with details, but the older laptops are now out of production, so I am not going to ask someone to divert time to making things work on them. The ACER is my current ride along, I would like to suspend that. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:18 ` Bill Davidsen ` (3 preceding siblings ...) 2005-01-03 21:03 ` Horst von Brand @ 2005-01-04 21:04 ` Pavel Machek 2005-01-04 21:28 ` Bill Davidsen 4 siblings, 1 reply; 222+ messages in thread From: Pavel Machek @ 2005-01-04 21:04 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Hi! > > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > > enough for this vast amount of changes. > > I have to say that with a few minor exceptions the introduction of new > features hasn't created long term (more than a few days) of problems. And > we have had that in previous stable versions as well. New features > themselves may not be totally stable, but in most cases they don't break > existing features, or are fixed in bk1 or bk2. What worries me is removing > features deliberately, and I won't beat that dead horse again, I've said > my piece. > > The "few minor exceptions:" > > SCSI command filtering - while I totally support the idea (and always > have), I miss running cdrecord as a normal user. Multisession doesn't work > as a normal user (at least if you follow the man page) because only root > can use -msinfo. There's also some raw mode which got a permission denied, > don't remember as I was trying something not doing production stuff. > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > machines I use, and all five laptops have working suspend and non-working > resume. APM seems to be pretty unsupported beyond "use ACPI for that." Go ahead and become APM maintainer... APM needs some care. Problem is that ACPI needs driver model changes, and those affect APM too. But noone is using APM these days, so when something breaks there, it takes long to discover. So even someone testing APM at regular (like every -rc and every -mm) basis would help... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:04 ` Pavel Machek @ 2005-01-04 21:28 ` Bill Davidsen 2005-01-04 21:51 ` APM vs. ACPI, janitor wanted? [was Re: starting with 2.7] Pavel Machek 0 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 21:28 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel On Tue, 4 Jan 2005, Pavel Machek wrote: > Hi! > > > > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > > > enough for this vast amount of changes. > > > > I have to say that with a few minor exceptions the introduction of new > > features hasn't created long term (more than a few days) of problems. And > > we have had that in previous stable versions as well. New features > > themselves may not be totally stable, but in most cases they don't break > > existing features, or are fixed in bk1 or bk2. What worries me is removing > > features deliberately, and I won't beat that dead horse again, I've said > > my piece. > > > > The "few minor exceptions:" > > > > SCSI command filtering - while I totally support the idea (and always > > have), I miss running cdrecord as a normal user. Multisession doesn't work > > as a normal user (at least if you follow the man page) because only root > > can use -msinfo. There's also some raw mode which got a permission denied, > > don't remember as I was trying something not doing production stuff. > > > > APM vs. ACPI - shutdown doesn't reliably power down about half of the > > machines I use, and all five laptops have working suspend and non-working > > resume. APM seems to be pretty unsupported beyond "use ACPI for that." > > Go ahead and become APM maintainer... APM needs some care. > > Problem is that ACPI needs driver model changes, and those affect APM > too. But noone is using APM these days, so when something breaks > there, it takes long to discover. I wouldn't try it if ACPI support worked on my machines, and I really wasn't suggesting that effort should go into APM so much as refuting the notion that people could just use ACPI. I would rather see resources go into ACPI, as I would be delighted to move into the future. > > So even someone testing APM at regular (like every -rc and every -mm) > basis would help... > Pavel > -- > People were complaining that M$ turns users into beta-testers... > ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! > -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* APM vs. ACPI, janitor wanted? [was Re: starting with 2.7] 2005-01-04 21:28 ` Bill Davidsen @ 2005-01-04 21:51 ` Pavel Machek 0 siblings, 0 replies; 222+ messages in thread From: Pavel Machek @ 2005-01-04 21:51 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, wli, aebr, solt2, linux-kernel Hi! > > Go ahead and become APM maintainer... APM needs some care. > > > > Problem is that ACPI needs driver model changes, and those affect APM > > too. But noone is using APM these days, so when something breaks > > there, it takes long to discover. > > I wouldn't try it if ACPI support worked on my machines, and I really > wasn't suggesting that effort should go into APM so much as refuting the > notion that people could just use ACPI. I would rather see resources go > into ACPI, as I would be delighted to move into the future. Actually, *lot* of people are working on ACPI (like 4 full-time equivalents or something). I'd be surprised if APM got tenth of that work. So someone hacking APM one hour once a week could do quite a lot of difference. Same ammount of work on ACPI is going to be barely visible. Pavel "It is easy to become APM hero" ;-). -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 13:47 ` Adrian Bunk 2005-01-03 17:18 ` Bill Davidsen @ 2005-01-04 12:57 ` William Lee Irwin III 2005-01-04 15:08 ` Adrian Bunk 2005-01-04 20:17 ` Willy Tarreau 1 sibling, 2 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 12:57 UTC (permalink / raw) To: Adrian Bunk Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Mon, Jan 03, 2005 at 02:24:12PM +0100, Diego Calleja wrote: >> 2.6 will stop having small issues in each release until 2.7 is forked just >> like 2.4 broke things until 2.5 was forked. The difference IMO >> is that linux development now avoids things like the unstability which the >> 2.4.10 changes caused and things like the fs corruption bugs we saw in 2.4 On Mon, Jan 03, 2005 at 02:47:27PM +0100, Adrian Bunk wrote: > The 2.6.9 -> 2.6.10 patch is 28 MB, and while the changes that went into > 2.4 were limited since the most invasive patches were postponed for 2.5, > now _all_ patches go into 2.6 . > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > enough for this vast amount of changes. No amount of testing coverage will ever suffice. You're trying to empirically establish the nonexistence of something, which is only possible to repudiate, and never to verify. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 12:57 ` starting with 2.7 William Lee Irwin III @ 2005-01-04 15:08 ` Adrian Bunk 2005-01-04 15:34 ` William Lee Irwin III 2005-01-04 20:17 ` Willy Tarreau 1 sibling, 1 reply; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 15:08 UTC (permalink / raw) To: William Lee Irwin III Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:57:38AM -0800, William Lee Irwin III wrote: > On Mon, Jan 03, 2005 at 02:24:12PM +0100, Diego Calleja wrote: > >> 2.6 will stop having small issues in each release until 2.7 is forked just > >> like 2.4 broke things until 2.5 was forked. The difference IMO > >> is that linux development now avoids things like the unstability which the > >> 2.4.10 changes caused and things like the fs corruption bugs we saw in 2.4 > > On Mon, Jan 03, 2005 at 02:47:27PM +0100, Adrian Bunk wrote: > > The 2.6.9 -> 2.6.10 patch is 28 MB, and while the changes that went into > > 2.4 were limited since the most invasive patches were postponed for 2.5, > > now _all_ patches go into 2.6 . > > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > > enough for this vast amount of changes. > > No amount of testing coverage will ever suffice. You're trying to > empirically establish the nonexistence of something, which is only > possible to repudiate, and never to verify. I claim: The less and the less invasive patches go into the kernel, the less likely are breakages. "enough" shouldn't say "mathematically exactly proven that no regressions exist" but more something like the pretty small number of regressions in recent 2.4 kernels. > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:08 ` Adrian Bunk @ 2005-01-04 15:34 ` William Lee Irwin III 2005-01-04 16:53 ` Adrian Bunk 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 15:34 UTC (permalink / raw) To: Adrian Bunk Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:57:38AM -0800, William Lee Irwin III wrote: >> No amount of testing coverage will ever suffice. You're trying to >> empirically establish the nonexistence of something, which is only >> possible to repudiate, and never to verify. On Tue, Jan 04, 2005 at 04:08:10PM +0100, Adrian Bunk wrote: > I claim: > The less and the less invasive patches go into the kernel, the less > likely are breakages. > "enough" shouldn't say "mathematically exactly proven that no > regressions exist" but more something like the pretty small number of > regressions in recent 2.4 kernels. The less that happens, the less likely it is for anything to happen. You're effectively arguing that very little should happen. This cannot be, because pure bugfixing activity alone would overwhelm the limits on levels of activity you endorse. When it comes to design flaws, a single fix for such would swamp the limits on activity you've imposed for a significant portion of a year. If you want more stability and fewer regressions, look for methods of getting more peer review for patches, not fewer patches. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:34 ` William Lee Irwin III @ 2005-01-04 16:53 ` Adrian Bunk 2005-01-04 19:57 ` William Lee Irwin III 2005-01-04 21:01 ` Theodore Ts'o 0 siblings, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 16:53 UTC (permalink / raw) To: William Lee Irwin III Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 07:34:45AM -0800, William Lee Irwin III wrote: > On Tue, Jan 04, 2005 at 04:57:38AM -0800, William Lee Irwin III wrote: > >> No amount of testing coverage will ever suffice. You're trying to > >> empirically establish the nonexistence of something, which is only > >> possible to repudiate, and never to verify. > > On Tue, Jan 04, 2005 at 04:08:10PM +0100, Adrian Bunk wrote: > > I claim: > > The less and the less invasive patches go into the kernel, the less > > likely are breakages. > > "enough" shouldn't say "mathematically exactly proven that no > > regressions exist" but more something like the pretty small number of > > regressions in recent 2.4 kernels. > > The less that happens, the less likely it is for anything to happen. > You're effectively arguing that very little should happen. > > This cannot be, because pure bugfixing activity alone would overwhelm > the limits on levels of activity you endorse. When it comes to design > flaws, a single fix for such would swamp the limits on activity you've > imposed for a significant portion of a year. My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the amount of changes that were allowed into 2.4 after 2.5 forked. Looking at 2.4, this seems to be a promising model. > If you want more stability and fewer regressions, look for methods of > getting more peer review for patches, not fewer patches. This is only one source of problems, that increases with the amount of changes and decreases with the amount of review. Another source is the interaction of correct patches with other code. An example are (were?) the problems with 4kB stacks on i386 with XFS. And then there are issues that are not bugs in the code, but user errors that have to be avoided. An example is CONFIG_BLK_DEV_UB in 2.6.9, which even the Debian kernel maintainers got wrong in the first kernel packages they did put into Debian unstable. > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 16:53 ` Adrian Bunk @ 2005-01-04 19:57 ` William Lee Irwin III 2005-01-04 20:30 ` Willy Tarreau ` (2 more replies) 2005-01-04 21:01 ` Theodore Ts'o 1 sibling, 3 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 19:57 UTC (permalink / raw) To: Adrian Bunk Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 07:34:45AM -0800, William Lee Irwin III wrote: >> The less that happens, the less likely it is for anything to happen. >> You're effectively arguing that very little should happen. >> This cannot be, because pure bugfixing activity alone would overwhelm >> the limits on levels of activity you endorse. When it comes to design >> flaws, a single fix for such would swamp the limits on activity you've >> imposed for a significant portion of a year. On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the > amount of changes that were allowed into 2.4 after 2.5 forked. > Looking at 2.4, this seems to be a promising model. This must be considered relative to the size of the source code. Just because they're more changes than you can personally track does not mean they're large numbers of changes relative to the source's size. Users' timidity in these regards should be taken as little more than a sign that the scale of the kernel's source is increasing, which is a good thing, as the kernel may then benefit from economies of scale. The kernel's scale has long since increased beyond the point where an individual can effectively track its changes in realtime, and small matters of degree such as are being moaned about now are insubstantial. Similarly, counts of bugs and regressions should probably also be considered relative to the size of the kernel source. On Tue, Jan 04, 2005 at 07:34:45AM -0800, William Lee Irwin III wrote: >> If you want more stability and fewer regressions, look for methods of >> getting more peer review for patches, not fewer patches. On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > This is only one source of problems, that increases with the amount of > changes and decreases with the amount of review. > Another source is the interaction of correct patches with other code. An > example are (were?) the problems with 4kB stacks on i386 with XFS. The existences of badly-behaved filesystems and drivers were known in advance, and that's why 4KB stacks were left optional. So the example is not particularly enlightening. This is trivially countered with the source code skew that crippled numerous architectures, made numerous drivers uncompilable or unrunnable and the like over the course of the "unstable series". Had the attention of users of the stable series been present, no such phenomena would have occurred. The issues you're dredging up are pinpricks at most. The losses incurred from the fragmentation of the userbase are far more severe, dwarfing those by numerous orders of magnitude. On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > And then there are issues that are not bugs in the code, but user errors > that have to be avoided. An example is CONFIG_BLK_DEV_UB in 2.6.9, which > even the Debian kernel maintainers got wrong in the first kernel > packages they did put into Debian unstable. PEBKAC is entirely out of the scope of any program not making direct efforts at HCI. CONFIG_BLK_DEV_UB was documented for what it was, and users configuring kernels are not assumed to be naive. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 19:57 ` William Lee Irwin III @ 2005-01-04 20:30 ` Willy Tarreau 2005-01-04 20:34 ` Adrian Bunk 2005-01-04 22:01 ` Andries Brouwer 2 siblings, 0 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 20:30 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, Diego Calleja, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 11:57:25AM -0800, William Lee Irwin III wrote: > On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > > My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the > > amount of changes that were allowed into 2.4 after 2.5 forked. > > Looking at 2.4, this seems to be a promising model. > > This must be considered relative to the size of the source code. > Just because they're more changes than you can personally track does > not mean they're large numbers of changes relative to the source's size. > > Users' timidity in these regards should be taken as little more than > a sign that the scale of the kernel's source is increasing, which is a > good thing, as the kernel may then benefit from economies of scale. > > The kernel's scale has long since increased beyond the point where an > individual can effectively track its changes in realtime, and small > matters of degree such as are being moaned about now are insubstantial. > Similarly, counts of bugs and regressions should probably also be > considered relative to the size of the kernel source. William, I strongly agree with you regarding this (fortunately, it seems to happen sometimes :-)) Speaking for myself, I read and try to understand *all* the changelog of 2.4 pre releases, and even often take a look at linux.bkbits.net to see if some things have changed, that I could grab before waiting for a release, but I almost never read 2.6 changelog (except the first hundreds of lines that Linus announces with a final release), because it's far too much. I don't even know how some people still keep in touch with this amount of changes. Cheers, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 19:57 ` William Lee Irwin III 2005-01-04 20:30 ` Willy Tarreau @ 2005-01-04 20:34 ` Adrian Bunk 2005-01-04 20:55 ` William Lee Irwin III 2005-01-04 22:01 ` Andries Brouwer 2 siblings, 1 reply; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 20:34 UTC (permalink / raw) To: William Lee Irwin III Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 11:57:25AM -0800, William Lee Irwin III wrote: >... > On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > > And then there are issues that are not bugs in the code, but user errors > > that have to be avoided. An example is CONFIG_BLK_DEV_UB in 2.6.9, which > > even the Debian kernel maintainers got wrong in the first kernel > > packages they did put into Debian unstable. > > PEBKAC is entirely out of the scope of any program not making direct > efforts at HCI. CONFIG_BLK_DEV_UB was documented for what it was, and > users configuring kernels are not assumed to be naive. <-- snip --> config BLK_DEV_UB tristate "Low Performance USB Block driver" depends on USB help This driver supports certain USB attached storage devices such as flash keys. If unsure, say N. <-- snip --> Call me naive, but at least for me it wouldn't have been obvious that this option cripples the usb-storage driver. The warning that this option cripples the usb-storage driver was added after people who accidentially enabled this option ("it can't harm") in 2.6.9 swamped the USB maintainers with bug reports about problems with their storage devices. > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:34 ` Adrian Bunk @ 2005-01-04 20:55 ` William Lee Irwin III 2005-01-04 21:23 ` Bill Davidsen 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 20:55 UTC (permalink / raw) To: Adrian Bunk Cc: Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 09:34:44PM +0100, Adrian Bunk wrote: > <-- snip --> > config BLK_DEV_UB > tristate "Low Performance USB Block driver" > depends on USB > help > This driver supports certain USB attached storage devices > such as flash keys. > > If unsure, say N. > <-- snip --> > Call me naive, but at least for me it wouldn't have been obvious that > this option cripples the usb-storage driver. > The warning that this option cripples the usb-storage driver was added > after people who accidentially enabled this option ("it can't harm") > in 2.6.9 swamped the USB maintainers with bug reports about problems > with their storage devices. The "it can't harm" assumption was flawed. Minimal configs are best for a reason. Inappropriate options turned on can and always will be able to take down your box and/or render some devices inoperable. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:55 ` William Lee Irwin III @ 2005-01-04 21:23 ` Bill Davidsen 0 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-04 21:23 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, aebr, solt2, linux-kernel On Tue, 4 Jan 2005, William Lee Irwin III wrote: > On Tue, Jan 04, 2005 at 09:34:44PM +0100, Adrian Bunk wrote: > > <-- snip --> > > config BLK_DEV_UB > > tristate "Low Performance USB Block driver" > > depends on USB > > help > > This driver supports certain USB attached storage devices > > such as flash keys. > > > > If unsure, say N. > > <-- snip --> > > Call me naive, but at least for me it wouldn't have been obvious that > > this option cripples the usb-storage driver. > > The warning that this option cripples the usb-storage driver was added > > after people who accidentially enabled this option ("it can't harm") > > in 2.6.9 swamped the USB maintainers with bug reports about problems > > with their storage devices. > > The "it can't harm" assumption was flawed. Minimal configs are best for > a reason. Inappropriate options turned on can and always will be able > to take down your box and/or render some devices inoperable. And if the user actually wants to use a flash key reader on his/her system? Is it all that naive to turn on this option? What option would a knowlegible user employ? Or do such readers peruse the entire kernel source so they know that using the key reader will disable storage divices on their USB? But I did make the point that this was fixed quickly, insofar as adding "this will kill storage devices on USB" to the config constitutes a fix. If it killed the CD burner I would have caught this myself, I only use the attached disk for major backup... The idea that you would even imply that people turning this option on were naive users, or that it would be done for no good reason, seems pretty far from the truth in this case. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 19:57 ` William Lee Irwin III 2005-01-04 20:30 ` Willy Tarreau 2005-01-04 20:34 ` Adrian Bunk @ 2005-01-04 22:01 ` Andries Brouwer 2 siblings, 0 replies; 222+ messages in thread From: Andries Brouwer @ 2005-01-04 22:01 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, Diego Calleja, Willy Tarreau, davidsen, solt2, linux-kernel On Tue, Jan 04, 2005 at 11:57:25AM -0800, William Lee Irwin III wrote ... > > ... An example is CONFIG_BLK_DEV_UB in 2.6.9, which ... > > PEBKAC is entirely out of the scope of any program not making direct > efforts at HCI. CONFIG_BLK_DEV_UB was documented for what it was, and > users configuring kernels are not assumed to be naive. Hmm. Let me disagree again. The kernel configuration process is intended for the average person who configures kernels. When there are many complaints (as I recall from 2.5 times, where one needed to figure out how to get keyboard and mouse configured) then it is no good to tell the world "you are all stupid, just read the docs" - one needs to think about how the setup can be improved so that fewer people have difficulties. ----- This was part of a discussion about 2.6 vs 2.7. Every single user-visible change will cause problems for some people. Earlier we talked about fixing bugs. You sounded as if you considered fixing one particular bug a point event, while I preferred to regard it as a process of unknown duration. A problem is noticed, a fix is made, somewhat later one finds that the fix has unintended side effects and the fix is modified slightly, etc. One consequence of this is that the bug fixing process for a rare bug that affects few people may affect many. What users hope for is a situation like with TeX. It has version numbers like 3.14159, tending to pi. This conveys the intention: in principle TeX is fixed, but flaws are corrected. A kernel like 2.2 should converge to a limit, with big changes in the beginning, and only tiny changes later on. If on the other hand there is continuous development, and continuous bug fixing, there is continuous instability - I do not mean instability in the sense of kernel crashes, but instability in the sense of user-visible changes, user setups that are broken. This makes users unhappy. Andries ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 16:53 ` Adrian Bunk 2005-01-04 19:57 ` William Lee Irwin III @ 2005-01-04 21:01 ` Theodore Ts'o 2005-01-06 9:45 ` Marcelo Tosatti 1 sibling, 1 reply; 222+ messages in thread From: Theodore Ts'o @ 2005-01-04 21:01 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > > My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the > amount of changes that were allowed into 2.4 after 2.5 forked. > > Looking at 2.4, this seems to be a promising model. You have *got* to be kidding. In my book at least, 2.4 ranks as one of the less successful stable kernel series, especially as compared against 2.2 and 2.0. 2.4 was far less stable, and a vast number of patches that distributions were forced to apply in an (only partially successful) attempt to make 2.4 stable meant that there are some 2.4-based distributions where you can't even run with a stock 2.4 kernel from kernel.org. Much of the reputation that Linux had of a rock-solid OS that never crashed or locked up that we had gained during the 2.2 days was tarnished by 2.4 lockups, especially in high memory pressure situations. One of the things which many people have pointed out was that even 2.6.0 was more stable than 2.4 was for systems under high load. - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 21:01 ` Theodore Ts'o @ 2005-01-06 9:45 ` Marcelo Tosatti 2005-01-06 15:50 ` Theodore Ts'o 2005-01-06 16:59 ` William Lee Irwin III 0 siblings, 2 replies; 222+ messages in thread From: Marcelo Tosatti @ 2005-01-06 9:45 UTC (permalink / raw) To: Theodore Ts'o, Adrian Bunk, William Lee Irwin III, Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:01:17PM -0500, Theodore Ts'o wrote: > On Tue, Jan 04, 2005 at 05:53:01PM +0100, Adrian Bunk wrote: > > > > My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the > > amount of changes that were allowed into 2.4 after 2.5 forked. > > > > Looking at 2.4, this seems to be a promising model. > > You have *got* to be kidding. In my book at least, 2.4 ranks as one > of the less successful stable kernel series, especially as compared > against 2.2 and 2.0. 2.4 was far less stable, and a vast number of > patches that distributions were forced to apply in an (only partially > successful) attempt to make 2.4 stable meant that there are some > 2.4-based distributions where you can't even run with a stock 2.4 > kernel from kernel.org. You got to be kidding now? 99% of the features distributions have applied to their 2.4 based kernels are "enterprise" features such as direct IO, AIO, etc. Really I can't recall any "attempt to make 2.4 stable" from the distros, its mostly "attempt to backport nice v2.6 feature". Do you have any example? > Much of the reputation that Linux had of a > rock-solid OS that never crashed or locked up that we had gained > during the 2.2 days was tarnished by 2.4 lockups, especially in high > memory pressure situations. > > One of the things which many people have pointed out was that even > 2.6.0 was more stable than 2.4 was for systems under high load. It took sometime to happen, but instability related to "high memory pressure" has been fixed in almost all cases long ago (the only remaining issue to my knowledged is loopback device with highmemory). I hardly see complaints of "crashes under load" problems since v2.4.19/20 or so. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 9:45 ` Marcelo Tosatti @ 2005-01-06 15:50 ` Theodore Ts'o 2005-01-06 16:59 ` William Lee Irwin III 1 sibling, 0 replies; 222+ messages in thread From: Theodore Ts'o @ 2005-01-06 15:50 UTC (permalink / raw) To: Marcelo Tosatti Cc: Adrian Bunk, William Lee Irwin III, Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Thu, Jan 06, 2005 at 07:45:19AM -0200, Marcelo Tosatti wrote: > > You got to be kidding now? > > 99% of the features distributions have applied to their 2.4 based kernels > are "enterprise" features such as direct IO, AIO, etc. > > Really I can't recall any "attempt to make 2.4 stable" from the distros, > its mostly "attempt to backport nice v2.6 feature". Sorry, those were two separate points; I should have been more careful to keep the two separate. I believe 2.4 has been less successful than other stable series for two reasons. The first is the very large divergence of what the distributions (and therefore most users) were actually using from each other and from kernel.org. The second is the lack of stability, in particular with systems with HIGHMEM configured, where low memory exhuastion is the first thing I suspect when a customer tells me that a 2.4-based system with a lot of memory freezes up. - Ted ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 9:45 ` Marcelo Tosatti 2005-01-06 15:50 ` Theodore Ts'o @ 2005-01-06 16:59 ` William Lee Irwin III 2005-01-06 14:38 ` Marcelo Tosatti 1 sibling, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-06 16:59 UTC (permalink / raw) To: Marcelo Tosatti Cc: Theodore Ts'o, Adrian Bunk, Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Thu, Jan 06, 2005 at 07:45:19AM -0200, Marcelo Tosatti wrote: > You got to be kidding now? > 99% of the features distributions have applied to their 2.4 based kernels > are "enterprise" features such as direct IO, AIO, etc. > Really I can't recall any "attempt to make 2.4 stable" from the distros, > its mostly "attempt to backport nice v2.6 feature". > Do you have any example? [tytso's comments elided] > It took sometime to happen, but instability related to "high memory > pressure" has been fixed in almost all cases long ago (the only > remaining issue to my knowledged is loopback device with highmemory). > I hardly see complaints of "crashes under load" problems since > v2.4.19/20 or so. I am unfortunately holding 2.4.x' earlier history against it. While you were maintaining it, much of what we're discussing was resolved. Unfortunately, the stabilization you're talking about was essentially too late; distros had long-since wildly diverged, they had frozen on older releases, and the damage to Linux' reputation was already done. I'm also unaware of major commercial distros (e.g. Red Hat, SuSE) using 2.4.x more recent than 2.4.21 as a baseline, and it's also notable that one of the largest segments of the commercial userbase I see is using a distro kernel based on 2.4.9. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 16:59 ` William Lee Irwin III @ 2005-01-06 14:38 ` Marcelo Tosatti 0 siblings, 0 replies; 222+ messages in thread From: Marcelo Tosatti @ 2005-01-06 14:38 UTC (permalink / raw) To: William Lee Irwin III Cc: Theodore Ts'o, Adrian Bunk, Diego Calleja, Willy Tarreau, davidsen, aebr, solt2, linux-kernel On Thu, Jan 06, 2005 at 08:59:08AM -0800, William Lee Irwin III wrote: > On Thu, Jan 06, 2005 at 07:45:19AM -0200, Marcelo Tosatti wrote: > > You got to be kidding now? > > 99% of the features distributions have applied to their 2.4 based kernels > > are "enterprise" features such as direct IO, AIO, etc. > > Really I can't recall any "attempt to make 2.4 stable" from the distros, > > its mostly "attempt to backport nice v2.6 feature". > > Do you have any example? > [tytso's comments elided] > > It took sometime to happen, but instability related to "high memory > > pressure" has been fixed in almost all cases long ago (the only > > remaining issue to my knowledged is loopback device with highmemory). > > I hardly see complaints of "crashes under load" problems since > > v2.4.19/20 or so. > > I am unfortunately holding 2.4.x' earlier history against it. While you > were maintaining it, much of what we're discussing was resolved. > Unfortunately, the stabilization you're talking about was essentially > too late; distros had long-since wildly diverged, they had frozen on > older releases, and the damage to Linux' reputation was already done. > I'm also unaware of major commercial distros (e.g. Red Hat, SuSE) using > 2.4.x more recent than 2.4.21 as a baseline, and it's also notable that > one of the largest segments of the commercial userbase I see is using a > distro kernel based on 2.4.9. I agree. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 12:57 ` starting with 2.7 William Lee Irwin III 2005-01-04 15:08 ` Adrian Bunk @ 2005-01-04 20:17 ` Willy Tarreau 2005-01-05 0:02 ` Alan Cox 1 sibling, 1 reply; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 20:17 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, Diego Calleja, davidsen, aebr, solt2, linux-kernel On Tue, Jan 04, 2005 at 04:57:38AM -0800, William Lee Irwin III wrote: > On Mon, Jan 03, 2005 at 02:47:27PM +0100, Adrian Bunk wrote: > > The 2.6.9 -> 2.6.10 patch is 28 MB, and while the changes that went into > > 2.4 were limited since the most invasive patches were postponed for 2.5, > > now _all_ patches go into 2.6 . > > Yes, -mm gives a bit more testing coverage, but it doesn't seem to be > > enough for this vast amount of changes. > > No amount of testing coverage will ever suffice. You're trying to > empirically establish the nonexistence of something, which is only > possible to repudiate, and never to verify. So how do some distro makers manage to stabilize their 'enterprise' versions, stay on a 2.4.21 with hundreds of patches which overall seem to work pretty well ? The distro maker I think about has quite a big crunch of the kernel developpers, and I suspect that they do this work themselves. If they can refrain from putting new features everyday in their employer's product, why can't they do the same for the free version ? Other example: look how Alan releases kernels. He posts several updates a week, some with very few changes, some with more, but at least, people can say "this one works for me" and stick to it for a time. Indeed, I think that if 2.6.11 would stay a year in -rc version, then Alan would release tens of 2.6.10 derivatives which would then become far more stable than what the next 2.6.11 would be. Today, coverage is done by users who are confident in one product and agree to test it. The best reputation the tree gets, the more users will try it, and the more covered it will be, then the best reputation it will get, etc... Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:17 ` Willy Tarreau @ 2005-01-05 0:02 ` Alan Cox 2005-01-05 5:49 ` Willy Tarreau 0 siblings, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-05 0:02 UTC (permalink / raw) To: Willy Tarreau Cc: William Lee Irwin III, Adrian Bunk, Diego Calleja, davidsen, aebr, solt2, Linux Kernel Mailing List On Maw, 2005-01-04 at 20:17, Willy Tarreau wrote: > So how do some distro makers manage to stabilize their 'enterprise' versions, > stay on a 2.4.21 with hundreds of patches which overall seem to work pretty > well ? The distro maker I think about has quite a big crunch of the kernel > developpers, and I suspect that they do this work themselves. If they can > refrain from putting new features everyday in their employer's product, why > can't they do the same for the free version ? We employ a small army of highly qualified QA and engineering people to do that. It's very very hard work. In addition we make choices that suit our business customers but would be very bad for progress if they were the "base". To a lot of our customers progress is evil unless they can schedule it six months in advance. If the base kernel worked that way we'd not have gotten a useful OS yet. Don't confuse the deployment goals of big business and the developer goals of the community. If you stand in the middle you get stretched into strange directions and eventually (as we found with the Fedora v RHEL split) you can't do both at the same time. > one works for me" and stick to it for a time. Indeed, I think that if 2.6.11 > would stay a year in -rc version, then Alan would release tens of 2.6.10 > derivatives which would then become far more stable than what the next 2.6.11 > would be. It always depends "at what". 2.6.10 is more stable than 2.6.9-ac at SCSI and USB for example because the backports were too complex. Alan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 0:02 ` Alan Cox @ 2005-01-05 5:49 ` Willy Tarreau 0 siblings, 0 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-05 5:49 UTC (permalink / raw) To: Alan Cox Cc: William Lee Irwin III, Adrian Bunk, Diego Calleja, davidsen, aebr, solt2, Linux Kernel Mailing List Hi Alan, On Wed, Jan 05, 2005 at 12:02:01AM +0000, Alan Cox wrote: > We employ a small army of highly qualified QA and engineering people to > do that. It's very very hard work. In addition we make choices that suit > our business customers but would be very bad for progress if they were > the "base". To a lot of our customers progress is evil unless they can > schedule it six months in advance. Oh, you know, I have customers who already moan about the too high rate of updates in rhel3 because they can't keep all their machines to the same version. > If the base kernel worked that way we'd not have gotten a useful OS yet. > Don't confuse the deployment goals of big business and the developer > goals of the community. If you stand in the middle you get stretched > into strange directions and eventually (as we found with the Fedora v > RHEL split) you can't do both at the same time. Well, I know we're often tempted to include our very last work with bugfixes in an update, but I mean that if the work has already been done (internally), I wonder why it cannot be done publicly. Except of course if the people working on this are not really linked to mainline kernel development, which I could understand. > > one works for me" and stick to it for a time. Indeed, I think that if 2.6.11 > > would stay a year in -rc version, then Alan would release tens of 2.6.10 > > derivatives which would then become far more stable than what the next 2.6.11 > > would be. > > It always depends "at what". 2.6.10 is more stable than 2.6.9-ac at SCSI > and USB for example because the backports were too complex. That's not a problem, and it's even expected. In your kernel, you fix "easy" things and you publicly state that USB or SCSI will not get fixed. Then you provide people with a working 2.6 at a feature level equivalent to 2.6.9. All those who are not hit with SCSI or USB are fairly happy. Others just have to wait for the 2.6.10 updates which change SCSI and USB, and already expect that it breaks a few things given the number of changes. Your kernels provide the needed fourth digit numbering in some ways. Cheers, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 13:24 ` Diego Calleja 2005-01-03 13:47 ` Adrian Bunk @ 2005-01-04 2:06 ` Roman Zippel 2005-01-04 2:36 ` Paolo Ciarrocchi 1 sibling, 1 reply; 222+ messages in thread From: Roman Zippel @ 2005-01-04 2:06 UTC (permalink / raw) To: Diego Calleja Cc: Willy Tarreau, wli, bunk, davidsen, aebr, solt2, linux-kernel Hi, On Monday 03 January 2005 14:24, Diego Calleja wrote: > I fully agree with WLI that the 2.4 development model and the > backporting-mania created more problems than it solved, because in the real > world almost everybody uses what distros ship, and what distros ship isn't > kernel.org but heavily modified kernels, which means that the kernel.org > was not really "well-tested" or it took much longer to become "well-tested" > because it wasn't really being used. Backporting isn't the primary problem. The real problem were the huge time intervals between stable releases. A new stable release brings a huge amount of changes which got different levels of testing, which makes upgrading quite an experience. What we need are regular releases of stable kernels with a manageable amount of changes and a development tree to pull these changes from. It's a bit comparable to Debian testing/unstable. Changes go only from one tree to the other if they fulfil certain criteria. The job of the stable tree maintainer wouldn't be anymore to apply random patches sent to him, but to select instead which patches to pull from the development tree. This doesn't of course guarantees perfectly stable kernels, but it would encourage more people to run recent stable kernels and avoids the huge steps in kernel upgrades. The only problem is that I don't know of any source code management system which supports this kind of development reasonably easy... bye, Roman ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 2:06 ` Roman Zippel @ 2005-01-04 2:36 ` Paolo Ciarrocchi 0 siblings, 0 replies; 222+ messages in thread From: Paolo Ciarrocchi @ 2005-01-04 2:36 UTC (permalink / raw) To: Roman Zippel Cc: Diego Calleja, Willy Tarreau, wli, bunk, davidsen, aebr, solt2, linux-kernel On Tue, 4 Jan 2005 03:06:25 +0100, Roman Zippel <zippel@linux-m68k.org> wrote: > Hi, > > On Monday 03 January 2005 14:24, Diego Calleja wrote: > > > I fully agree with WLI that the 2.4 development model and the > > backporting-mania created more problems than it solved, because in the real > > world almost everybody uses what distros ship, and what distros ship isn't > > kernel.org but heavily modified kernels, which means that the kernel.org > > was not really "well-tested" or it took much longer to become "well-tested" > > because it wasn't really being used. > > Backporting isn't the primary problem. The real problem were the huge time > intervals between stable releases. A new stable release brings a huge amount > of changes which got different levels of testing, which makes upgrading quite > an experience. > What we need are regular releases of stable kernels with a manageable amount > of changes and a development tree to pull these changes from. It's a bit > comparable to Debian testing/unstable. Changes go only from one tree to the > other if they fulfil certain criteria. The job of the stable tree maintainer > wouldn't be anymore to apply random patches sent to him, but to select > instead which patches to pull from the development tree. > This doesn't of course guarantees perfectly stable kernels, but it would > encourage more people to run recent stable kernels and avoids the huge steps > in kernel upgrades. The only problem is that I don't know of any source code > management system which supports this kind of development reasonably easy... It really makes sense. vanilla and -mm are already a kind of stable/unstale tree though. -- Paolo ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:45 ` Adrian Bunk 2005-01-03 1:19 ` William Lee Irwin III @ 2005-01-03 12:52 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 12:52 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel Adrian Bunk wrote: > On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote: > >>Adrian Bunk wrote: >> >>>>The main advantage with stable kernels in the good old days (tm) when 4 >>>>and 6 were even numbers was that you knew if something didn't work, and >>>>upgrading to a new kernel inside this stable kernel series had a >>>>relatively low risk of new breakages. This meant one big migration every >>>>few years and relatively easy upgrades between stable series kernels. >>>>Nowadays in 2.6, every new 2.6 kernel has several regressions compared >>>>to the previous one, and additionally obsolete but used code like >>>>ipchains and devfs is scheduled for removal making upgrades even harder >>>>for many users. >> >>On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: >> >>>And there you have my largest complaint with the new model. If 2.6 is >>>stable, it should not have existing features removed just because >>>someone has a new wet dream about a better but incompatible way to do >>>things. I expect working programs to be deliberately broken in a >>>development tree, but once existing features are removed there simply is >>>no stable set of features. >> >>The presumption is that these changes are frivolous. This is false. >>The removals of these features are motivated by their unsoundness, >>and those removals resolve real problems. If they did not do so, they >>would not pass peer review. > > > The netfilter people plan to remove ipfwadm and ipchains before 2.6.11 . > > This is legacy code that makes their development sometimes a bit harder, > but AFAIK ipchains in 2.6.10 doesn't suffer from any serious real > problems. This is exactly the type of change I meant. Anyone who has put 2.6 on an older distro is probably still using ipchains. I can't imagine anyone still using ipfwadm, but why didn't it go away during the 2.5 phase, when everyone would have said that it was expected behaviour. And there have been repeated suggestions the cryptoloop go away, which was one of the reasons to go to 2.6 in the first place. I spent a year during 2.5 time convincing {company} that having laptops around without crypto was a very bad thing, and that cryptoloop was far better even if professionals could break the security, casual theves would be less likely to do so. They are NOT going to redo the setup on every laptop to use {something else}, they would ignore any future security issues in thge kenrel because they can't send out a "boot this CD" new kernel upgrade. What's next, ext2? jfs? Features should be added in a stable tree, not deleted. "sometimes a bit harder" hardly sounds like a great reason to break existing systems. > > >>Adrian Bunk wrote: >> >>>>There's the point that most users should use distribution kernels, but >>>>consider e.g. that there are poor souls with new hardware not supported >>>>by the 3 years old 2.4.18 kernel in the stable part of your Debian >>>>distribution. >> >>On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote: >> >>>The stable and development kernel model worked for a decade, partly >>>because people could build on a feature set and not have that feature >>>just go away, leaving the choice of running without fixes or not >>>running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?) >>>I don't see why the definition of "stable" can't simply mean "no >>>deletions from the feature set" and let new features come in for those >>>who want them. Absent that 2.4 will be the last stable kernel, in the >>>sense that features won't be deliberately broken or removed. >> >>I can't speak for anyone during the times of more ancient Linux history; >>however, developers' dissatisfaction with the development model has been >>aired numerous times in certain fora. It has not satisfactorily served >>developers or users. Users are locked into distro kernels for >>incompatible extensions, and developers are torn between multiple >>codebases. > > > At least on Debian, ftp.kernel.org kernels work fine. > > >>This fragmentation of programmer effort is trivially recognizable as >>counterproductive. A single focal point for programmer effort is far >>superior for a development model. If the standard of stability is not >>passed then the code is not ready to be included in any kernel. Then >>the distinction is lost, and each of the fragmented codebases gets a >>third-class effort, and a spurious expenditure of effort is wasted on >>porting fixes and features across numerous different codebases. >>... Can you give an example of some feature which had to be removed because no progress could be made while it was present? Remember that I am not advocating "no new features," nor is anyone else AFAIK, just no removed features. Developers may have had multiple streams for new stuff, but the argument that this is now cured is BS. We have (major) lines of -mm -ck, -aa and -ac, just to name the ones I've tried in the last 3-4 months, not to mention Nick Piggin patch sets which come and go in -mm, and Reiser_N patches. In other words, I don't buy that keeping features is holding people back, nor that there aren't many parallel development lines of new patches. > > > My impression is that currently 2.4 doesn't take that much time of > developers (except for Marcelo's), and that it's a quite usable and > stable kernel. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:30 ` William Lee Irwin III 2005-01-03 0:45 ` Adrian Bunk @ 2005-01-03 15:52 ` Alan Cox 2005-01-03 17:15 ` Jeff V. Merkey 1 sibling, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-03 15:52 UTC (permalink / raw) To: William Lee Irwin III Cc: Bill Davidsen, Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, Linux Kernel Mailing List It isn't a good assumption that rate of change drives rate of errors and need for testing. It is one factor but the amount of review, the modularity of the code and the effectiveness of the management and verification tools are all involved greatly. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:52 ` Alan Cox @ 2005-01-03 17:15 ` Jeff V. Merkey 0 siblings, 0 replies; 222+ messages in thread From: Jeff V. Merkey @ 2005-01-03 17:15 UTC (permalink / raw) To: Alan Cox Cc: William Lee Irwin III, Bill Davidsen, Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, Linux Kernel Mailing List Alan Cox wrote: >It isn't a good assumption that rate of change drives rate of errors and >need for testing. It is one factor but the amount of review, the >modularity of the code and the effectiveness of the management and >verification tools are all involved greatly. > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > Rate of change X 3 = Rate of testing. Seems to apply in commerical software development, provided the testing engineers are brighter than the developers (which in most cases they need to be). :-) Jeff ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:15 ` Adrian Bunk 2005-01-02 22:49 ` Bill Davidsen @ 2005-01-02 23:14 ` Diego Calleja 2005-01-02 23:21 ` Dr. David Alan Gilbert ` (2 subsequent siblings) 4 siblings, 0 replies; 222+ messages in thread From: Diego Calleja @ 2005-01-02 23:14 UTC (permalink / raw) To: Adrian Bunk; +Cc: wli, aebr, solt2, linux-kernel El Sun, 2 Jan 2005 23:15:34 +0100 Adrian Bunk <bunk@stusta.de> escribió: > The main advantage with stable kernels in the good old days (tm) when 4 > and 6 were even numbers was that you knew if something didn't work, and > upgrading to a new kernel inside this stable kernel series had a > relatively low risk of new breakages. This meant one big migration every > few years and relatively easy upgrades between stable series kernels. That's not always true, 2.4.x development has not been exactly what I'd call "stable". IIRC 2.4.15 - the 2.6 fork I think - could corrupt your filesystems and I don't remember right now if there were more, personally I've suffered of "weird" behaviours until the new VM was stabilized, and I've heard of lots of reiser and ext3 problems until both filesystems got stabilized. I've lost my filesystems 3 times with 2.4, 0 times running 2.5 since 2.5.3x (of course that could be just good luck or bad luck but...) Of course that only proves your point: that changes may cause bugs 8) but for me 2.6 has been by far the stablest release linux has ever had, with some minor issues in each release while at the same time incorporating "big" changes which is something I can accept as "desktop user". Perhaps 2.6 will become "rock stable" or "to be used only by servers not desktops" when 2.7 forks? ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:15 ` Adrian Bunk 2005-01-02 22:49 ` Bill Davidsen 2005-01-02 23:14 ` Diego Calleja @ 2005-01-02 23:21 ` Dr. David Alan Gilbert 2005-01-03 9:57 ` Reviving the concept of a stable series (was Re: starting with 2.7) L. A. Walsh 2005-01-03 0:19 ` starting with 2.7 William Lee Irwin III 2005-01-03 15:20 ` Rik van Riel 4 siblings, 1 reply; 222+ messages in thread From: Dr. David Alan Gilbert @ 2005-01-02 23:21 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel For me, as someone who very rarely actually changes any code in the kernel, I have always found the stable series useful for two reasons: 1) It encourages me to test the kernel; if I have a kernel that is generally thought to be stable then I will try it on my home machine and report problems - this lets the kernel get tested on a wide range of hardware and situations; if there is no kernel that is liable to be stable changes will get much less testing on a smaller range of hardware. 2) If I have a bug in a vendor kernel everyone just tells me to go and speak to the vendor - so at least having a stable base to go back to can let me report a bug that isn't due to any vendors patches. 3) In some cases the commercial vendors don't seem to release source to some of the kernels except to people who have bought the packages, so those vendor kernel fixes aren't 'publically' visible. I think (1) is very important - getting large numbers of people to test OSS is its greatest asset. Dave -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ ^ permalink raw reply [flat|nested] 222+ messages in thread
* Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-02 23:21 ` Dr. David Alan Gilbert @ 2005-01-03 9:57 ` L. A. Walsh 2005-01-03 12:17 ` Robert W. Fuller ` (2 more replies) 0 siblings, 3 replies; 222+ messages in thread From: L. A. Walsh @ 2005-01-03 9:57 UTC (permalink / raw) To: linux-kernel I don't know about #3 below, but #1 and #2 are certainly true. I always preferred to run a vanilla stable kernel as I did not trust the vendors' kernels because their patches were not as well eyed as the vanilla kernel. I prefer to compile a kernel for my specific machines, some of which are old and do better with a hand-configured kernel rather than a Microsoftian monolith that is compiled with all possible options as modules. I have one old laptop that sound just doesn't work on no matter what the settings -- may be failed hardware, but darned if I can't seem to easily stop the loading of sound related modules as hardware is probed by automatic hardware probing on each bootup, and the loading of sound modules by GUI dependencies on a memory constrained system. With each new kernel release, I wonder if it will be satisfactory to use for a new, base-line, stable vanilla kernel, but post release comments seem to prove otherwise. It seems that some developers have the opinion that the end-user base no longer is their problem or audience and that the distros will patch all the little boo-boo's in each unstable 2.6 release. Well, that's just plain asking for problems. Just in SuSE's previous release of 9.1, it wouldn't boot up, for update, on any system that used xfs disks. Redhat has officially dropped support for end-user distros, that leaves...who looking after end users? Debian, Mandrake? From what I've read here, stable Debian, it seems, is in the 2.4 series. I don't know what Mandrake is up to, but I don't want to have to be jumping distros because my distro maker has screwed up the kernel with one of their patches. I also wouldn't want to give up reporting kernel bugs directly to developers as I would if I am using a non-vanilla, or worse, some tainted module. However, all that being said, there would still be the choosing of someone, steady and capable, of holding on to the stable release and being it's gate-keeper. It seems like it would become quite a chore to decide what code is let into the stable version. It's also considered by many to be "less" fun, not only to "manage the stable distro", but backport code into the previous distro. Maybe no one _qualified_, wanted to manage a stable release. It takes time and possibly enough time to qualify as a full-time job. It takes a special person to find gainful employment as a vendor-neutral kernel maintainer. The alternative is to try to work 2 jobs where, in programming, each job might "like" to have 60-80 hours of attention per week. That's a demanding sacrifice as well. It may be the case that no one at the last closed door kernel developer meeting wanted to undertake the care of a stable kernel. No volunteers...no kernel. There is less "wiggle room" in the average, mature, developer's schedule with the advent of easy outsourcing to cheaper labor that doesn't come from societies that breed independence and nurture talented, more mature, or eccentric developers that love spending spare cycles working on Open Source code. Nevertheless, it would be nice to see a no-new-features, stable series spun off from these development kernels, maybe .4th number releases, like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, etc...with iteritive bug fixes to the same kernel and no new features in such a branch, it might become stable enough for users to have confidence installing them on their desktop or stable machines. It wouldn't have to be months upon months of diverging code, as jumps to a new stable base can be started upon any fairly stable development kernel, say 2.6.10 w/e100 fixed, tracing fixed, the slab bug fix, and the capabilities bugs fixed going into a 2.6.10.1 that has no new features or old features removed. Serious bug fixes after that could go into a 2.6.10.2, etc. Such point releases would be easier to manage and only be updated/maintained as long as someone was interested enough to do it. The same process would be applied to a future dev-kernel that appears to be mostly stable after some number of weeks of alpha testing. It may be the case that a given furture dev-kernel has no stable branch off of it because it either a) didn't need one, or b) was too far from stable to start one. Anyway, just a thought for having something of the old with out as much of a headache of kernels that diverge for a year or more before getting sync'ed up. -l :-) Dr. David Alan Gilbert wrote: >For me, as someone who very rarely actually changes any code in >the kernel, I have always found the stable series useful for >two reasons: > > 1) It encourages me to test the kernel; if I have a kernel > that is generally thought to be stable then I will try it on > my home machine and report problems - this lets the kernel > get tested on a wide range of hardware and situations; if there > is no kernel that is liable to be stable changes will get much > less testing on a smaller range of hardware. > > 2) If I have a bug in a vendor kernel everyone just tells > me to go and speak to the vendor - so at least having a stable > base to go back to can let me report a bug that isn't due > to any vendors patches. > > 3) In some cases the commercial vendors don't seem to release > source to some of the kernels except to people who have bought > the packages, so those vendor kernel fixes aren't 'publically' > visible. > >I think (1) is very important - getting large numbers of people >to test OSS is its greatest asset. > > ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 9:57 ` Reviving the concept of a stable series (was Re: starting with 2.7) L. A. Walsh @ 2005-01-03 12:17 ` Robert W. Fuller 2005-01-03 13:58 ` Adrian Bunk 2005-01-03 14:24 ` Horst von Brand 2005-01-03 22:20 ` Reviving the concept of a stable series (was Re: starting with 2.7) Bill Davidsen 2 siblings, 1 reply; 222+ messages in thread From: Robert W. Fuller @ 2005-01-03 12:17 UTC (permalink / raw) To: linux-kernel My 2 cents (not that anybody asked for it or I have any currency here since it's rare I get answers to my posts anyway....) 1. The distributors, such as Redhat, Mandrake, etc. ought to be actively involved in stabilizing the kernel especially if they offer kernel support services. (This isn't meant to imply that they aren't currently doing so. After all, they employ a number of people who work on the kernel.) 2. There is nothing to prevent the distributors from pooling their resources and funding a small group of developers to maintain a "stable" branch as their fulltime job. 3. If progress is to be made in the development model for Linux, then people need to be less reactionary. In other words, don't criticize changes in the development model unless you have a suggestion for progressing the model. L. A. Walsh wrote: *omitted* > However, all that being said, there would still be the choosing of > someone, steady and capable, of holding on to the stable release and > being it's gate-keeper. It seems like it would become quite a chore > to decide what code is let into the stable version. It's also > considered by many to be "less" fun, not only to "manage the > stable distro", but backport code into the previous distro. Maybe no one > _qualified_, wanted to manage a stable release. It takes time and > possibly enough time to qualify as a > full-time job. It takes a special person to find gainful > employment as a vendor-neutral kernel maintainer. The alternative is > to try to work 2 jobs where, in programming, each job might "like" > to have 60-80 hours of attention per week. That's a demanding > sacrifice as well. > > It may be the case that no one at the last closed door kernel developer > meeting wanted to undertake the care of a stable kernel. No > volunteers...no kernel. There is less "wiggle room" in the average, > mature, developer's schedule with the advent of easy outsourcing to > cheaper labor that doesn't come from societies that breed independence > and nurture talented, more mature, or eccentric developers that love > spending spare cycles working on Open Source code. > > Nevertheless, it would be nice to see a no-new-features, stable series > spun off from these development kernels, maybe .4th number releases, > like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, > etc...with iteritive bug fixes to the same kernel and no new features > in such a branch, it might become stable enough for users to have > confidence > installing them on their desktop or stable machines. *more omitted* ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 12:17 ` Robert W. Fuller @ 2005-01-03 13:58 ` Adrian Bunk 0 siblings, 0 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 13:58 UTC (permalink / raw) To: Robert W. Fuller; +Cc: linux-kernel On Mon, Jan 03, 2005 at 07:17:25AM -0500, Robert W. Fuller wrote: >... > 3. If progress is to be made in the development model for Linux, then > people need to be less reactionary. In other words, don't criticize > changes in the development model unless you have a suggestion for > progressing the model. You can compare the old development model with the new development model, and if you think the progression is a regression it's not reactionary but simply correct to ask for going back to the old model. It's a bit like at the height of the "new economy" hype: "Reactionary" people who didn't believe in the wonders of the "new economiy" but bought "old economy" stocks (or no stocks at all) lost less money. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 9:57 ` Reviving the concept of a stable series (was Re: starting with 2.7) L. A. Walsh 2005-01-03 12:17 ` Robert W. Fuller @ 2005-01-03 14:24 ` Horst von Brand 2005-01-04 4:56 ` David Lang ` (2 more replies) 2005-01-03 22:20 ` Reviving the concept of a stable series (was Re: starting with 2.7) Bill Davidsen 2 siblings, 3 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-03 14:24 UTC (permalink / raw) To: L. A. Walsh; +Cc: linux-kernel "L. A. Walsh" <law@tlinx.org> said: > I don't know about #3 below, but #1 and #2 are certainly true. > I always preferred to run a vanilla stable kernel as I did not > trust the vendors' kernels because their patches were not as well > eyed as the vanilla kernel. I prefer to compile a kernel for > my specific machines, some of which are old and do better with a > hand-configured kernel rather than a Microsoftian monolith that > is compiled with all possible options as modules. The generic kernel + modules is a nice convenience for those that don't compile their own. And the modules technology has made the need for custom-compiled kernels all but go away. It is a _huge_ step forward (yes, I do remember the large collection of Slackware boot disks for all sorts of weird setups). > I have one old laptop that sound just doesn't work on no matter > what the settings -- may be failed hardware, but darned if I can't > seem to easily stop the loading of sound related modules as hardware > is probed by automatic hardware probing on each bootup, and the loading > of sound modules by GUI dependencies on a memory constrained system. Qualifies as "need for custom-compied kernel". Or even just custom configured GUI. > With each new kernel release, I wonder if it will be satisfactory > to use for a new, base-line, stable vanilla kernel, but post release > comments seem to prove otherwise. Only TeX is guaranteed bug-free. > It seems that some developers have the opinion that the end-user base > no longer is their problem or audience and that the distros will patch > all the little boo-boo's in each unstable 2.6 release. AFAIU, the current development model is designed to _diminish_ the need of custom patching by distributions. For example, RH 9 2.4 kernels were mostly 2.6 via backports and random patches. But the patches were only maintained by RH, so it was a large duplication of effort (not even counting the other distributions). With 2.6 everybody can work on a up-to-date code base, much less need of distribution backports and patches (and associated random incompatibilities) benefits every user. > Well, that's > just plain asking for problems. Quite to the contrary. > Just in SuSE's previous release of > 9.1, it wouldn't boot up, for update, on any system that used xfs > disks. Redhat has officially dropped support for end-user distros, > that leaves...who looking after end users? Debian, Mandrake? > From what I've read here, stable Debian, it seems, is in the 2.4 series. Stable Debian is 3 years old. > I don't know what Mandrake is up to, but I don't want to have to be > jumping distros because my distro maker has screwed up the kernel with > one of their patches. You could complain to the distribution maker (so every one of their users benefits from your problem, that is the whole point of open source!), undo the patch, run a vanilla kernel. No need to skip around (doing so is probably much more work than just changing kernels). > I also wouldn't want to give up reporting > kernel bugs directly to developers as I would if I am using a non-vanilla, > or worse, some tainted module. If it is a distribution kernel, you should complain to them, they will forward your complaint to the maintainers if it warrants doing so. Only if vanilla kernel you get to swamp the maintainers directly. > However, all that being said, there would still be the choosing of > someone, steady and capable, of holding on to the stable release and > being it's gate-keeper. The people in charge decided otherwise, for sound reasons. If you don't like it, you are free to create you own fork off 2.6.10 (or something) and stabilize that. That is the wonder of open source... > It seems like it would become quite a chore > to decide what code is let into the stable version. It's also > considered by many to be "less" fun, not only to "manage the > stable distro", but backport code into the previous distro. Lots of rather pointless work. Much of it something each distribution has to do on their own (because f.ex. vanilla 2.4 is _just fixes_, no backports of cool (and required) new functionality), instead of cooperating in building a better overall kernel. > Maybe no one _qualified_, wanted to manage a stable release. > It takes time and possibly enough time to qualify as a > full-time job. It takes a special person to find gainful > employment as a vendor-neutral kernel maintainer. The alternative is > to try to work 2 jobs where, in programming, each job might "like" > to have 60-80 hours of attention per week. That's a demanding > sacrifice as well. Yep. That's why nobody (and that certainly includes you) is entitled to demand such. > It may be the case that no one at the last closed door kernel developer > meeting wanted to undertake the care of a stable kernel. Andrew Morton had been designated for the job (and he accepted). > No > volunteers...no kernel. There is less "wiggle room" in the average, > mature, developer's schedule with the advent of easy outsourcing to > cheaper labor that doesn't come from societies that breed independence > and nurture talented, more mature, or eccentric developers that love > spending spare cycles working on Open Source code. English, please? > Nevertheless, it would be nice to see a no-new-features, stable series > spun off from these development kernels, maybe .4th number releases, > like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, > etc...with iteritive bug fixes to the same kernel and no new features > in such a branch, it might become stable enough for users to have confidence > installing them on their desktop or stable machines. See above. The 2.6.9-x kernels from Red Hat/Fedora are targeted to be exactly that... > It wouldn't have to be months upon months of diverging code, as jumps > to a new stable base can be started upon any fairly stable development > kernel, say 2.6.10 w/e100 fixed, tracing fixed, the slab bug fix, and > the capabilities bugs fixed going into a 2.6.10.1 that has no new features > or old features removed. Serious bug fixes after that could go into a > 2.6.10.2, etc. Such point releases would be easier to manage and only > be updated/maintained as long as someone was interested enough to do it. That is exactly the model! Just that no vanillla 2.6.9.1 has been needed yet. > The same process would be applied to a future dev-kernel that appears to be > mostly stable after some number of weeks of alpha testing. ... conveniently forgetting that it is a experimental data point that people start using the kernel (and finding its bugs) only when it leaves "alpha" (by whatever name), so this doesn't work. > It may be > the case that a given furture dev-kernel has no stable branch off of it > because it either a) didn't need one, or b) was too far from stable to start > one. (a) makes no sense, (b) is a mess that Linux has been able to avoid thus far. > Anyway, just a thought for having something of the old with out as much > of a headache of kernels that diverge for a year or more before getting > sync'ed up. That's what you get with the new development model. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 14:24 ` Horst von Brand @ 2005-01-04 4:56 ` David Lang 2005-01-04 14:52 ` Adrian Bunk 2005-01-04 7:00 ` Eric W. Biederman 2005-01-09 0:13 ` Reviving the concept of a stable series L A Walsh 2 siblings, 1 reply; 222+ messages in thread From: David Lang @ 2005-01-04 4:56 UTC (permalink / raw) To: Horst von Brand; +Cc: L. A. Walsh, linux-kernel On Mon, 3 Jan 2005, Horst von Brand wrote: > "L. A. Walsh" <law@tlinx.org> said: > >> From what I've read here, stable Debian, it seems, is in the 2.4 series. > > Stable Debian is 3 years old. Stable Debian uses the 2.2 kernel -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-04 4:56 ` David Lang @ 2005-01-04 14:52 ` Adrian Bunk 0 siblings, 0 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 14:52 UTC (permalink / raw) To: David Lang; +Cc: Horst von Brand, L. A. Walsh, linux-kernel On Mon, Jan 03, 2005 at 08:56:55PM -0800, David Lang wrote: > On Mon, 3 Jan 2005, Horst von Brand wrote: > > >"L. A. Walsh" <law@tlinx.org> said: > > > >> From what I've read here, stable Debian, it seems, is in the 2.4 series. > > > >Stable Debian is 3 years old. > > Stable Debian uses the 2.2 kernel 2.2 is the default kernel, but kernel 2.4 is supported and 2.4.18 is shipped with Debian stable. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 14:24 ` Horst von Brand 2005-01-04 4:56 ` David Lang @ 2005-01-04 7:00 ` Eric W. Biederman 2005-01-09 0:13 ` Reviving the concept of a stable series L A Walsh 2 siblings, 0 replies; 222+ messages in thread From: Eric W. Biederman @ 2005-01-04 7:00 UTC (permalink / raw) To: Horst von Brand; +Cc: L. A. Walsh, linux-kernel Horst von Brand <vonbrand@inf.utfsm.cl> writes: > "L. A. Walsh" <law@tlinx.org> said: > > > It seems that some developers have the opinion that the end-user base > > no longer is their problem or audience and that the distros will patch > > all the little boo-boo's in each unstable 2.6 release. > > AFAIU, the current development model is designed to _diminish_ the need of > custom patching by distributions. For example, RH 9 2.4 kernels were mostly > 2.6 via backports and random patches. But the patches were only maintained > by RH, so it was a large duplication of effort (not even counting the other > distributions). With 2.6 everybody can work on a up-to-date code base, much > less need of distribution backports and patches (and associated random > incompatibilities) benefits every user. And that idea I really appreciate it. From the looks of things though it does not feel like the distros have caught on. I know at least that it has been painful working with SuSE's 2.6.ancient fork when I have perfectly good code that runs in 2.6.latest. If the distros will update their base kernel once a year or so I can seem some benefits to the new dev model. But so far I have not seen the updates and when you have to use a distro kernel is seems to be the same old same old. > > It seems like it would become quite a chore > > to decide what code is let into the stable version. It's also > > considered by many to be "less" fun, not only to "manage the > > stable distro", but backport code into the previous distro. > > Lots of rather pointless work. Much of it something each distribution has > to do on their own (because f.ex. vanilla 2.4 is _just fixes_, no backports > of cool (and required) new functionality), instead of cooperating in > building a better overall kernel. Except some features did make it into 2.4.x like native pci-express support. That is certainly more than just fixes. > > Nevertheless, it would be nice to see a no-new-features, stable series > > spun off from these development kernels, maybe .4th number releases, > > like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, > > etc...with iteritive bug fixes to the same kernel and no new features > > in such a branch, it might become stable enough for users to have confidence > > installing them on their desktop or stable machines. > > See above. The 2.6.9-x kernels from Red Hat/Fedora are targeted to be > exactly that... Ah another fork that makes support from third parties a pain. So it appears Red Hat is going the same way I have observed with SuSE. I do believe a model where we stabilize features and let them shake out independently. Is where we need to go for Linux. But we seem still to be at the teething stage and I am frustrated. Eric ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series 2005-01-03 14:24 ` Horst von Brand 2005-01-04 4:56 ` David Lang 2005-01-04 7:00 ` Eric W. Biederman @ 2005-01-09 0:13 ` L A Walsh 2005-01-10 13:44 ` Adam Sampson 2 siblings, 1 reply; 222+ messages in thread From: L A Walsh @ 2005-01-09 0:13 UTC (permalink / raw) To: linux-kernel Horst von Brand wrote: >"L. A. Walsh" <law@tlinx.org> said: > > >>I prefer to compile a kernel for >>my specific machines, some of which are old and do better with a >>hand-configured kernel rather than a Microsoftian monolith that >>is compiled with all possible options as modules. >> >> >The generic kernel + modules is a nice convenience for those that don't >compile their own. And the modules technology has made the need for >custom-compiled kernels all but go away. It is a _huge_ step forward (yes, >I do remember the large collection of Slackware boot disks for all sorts of >weird setups). > > --- It's a nice convenience for Microsoft as well. That doesn't mean I can run XP well on a machine with < 256Mb. Linux, I can, especially with a tuned kernel. The binaries in the generic kernels are still compiled for the pentium (586). While my machines are old, compiling for x686 can produce code that runs faster on x686 and above machines. >>I have one old laptop that sound just doesn't work on no matter >>what the settings -- may be failed hardware, but darned if I can't >>seem to easily stop the loading of sound related modules as hardware >>is probed by automatic hardware probing on each bootup, and the loading >>of sound modules by GUI dependencies on a memory constrained system. >> >> > >Qualifies as "need for custom-compied kernel". Or even just custom >configured GUI. > > --- Yup...and easier to maintain such, with a vanilla, non-patched kernel. >>With each new kernel release, I wonder if it will be satisfactory >>to use for a new, base-line, stable vanilla kernel, but post release >>comments seem to prove otherwise. >> >> No one is expecting bug free, but there is a concept of bug Severity and frequency of expected impact. What I would like is if there was a "stabilized released" intended to be free of major destabilizing bugs. It used to be that one wouldn't run the development series on "work" machines -- ones used to do your everyday work. There was an acknowledged risk of using development kernels -- a risk that was noticably greater than the previously defined "stable" series. The stable series were such that I would regularly upgrade my desktop and server machines to the stable kernel while reserving the development kernel to development and test machines. This approached worked well for using a forward moving stable version while leaving room to make larger and riskier (greater potential for instability) changes in a development kernel. It seems that the eventual move to transition the development kernel into a stable kernel took a great deal of time, effort and pain which was spent on fixing and stabilizing all of the features to the point that it would qualify as a "stable" kernel and even then, often, the first couple to several point releases of a stable series were sketchy. It seems like this long stablization period (code freeze) was prolonged and painful because attention wasn't given to stability and bug fixing, sufficiently during the development process. >Only TeX is guaranteed bug-free. > > > >>It seems that some developers have the opinion that the end-user base >>no longer is their problem or audience and that the distros will patch >>all the little boo-boo's in each unstable 2.6 release. >> >> > >AFAIU, the current development model is designed to _diminish_ the need of >custom patching by distributions. > That hasn't seemed to happen -- and buying an off the shelf DVD/CD pack that can't be used to upgrade nor have rescue capabilities for the release from that DVD (neither SuSE 9.1's rescue DVD nor CD could be used on a SuSE 9.1 installation with XFS). If you can't boot the system or are behind a firewall their pre-install patch process doesn't have a place to enter a proxy address for patch downloading. But that's totally an aside. Having a single unpatched kernel from the kernel source/kernel.org is of great benefit (though one still has to download the suse patches to upgrade their system). >>Well, that's >>just plain asking for problems. >> >> >Quite to the contrary. > > ---- Theory hasn't met up with reality or current practice. In theory the model you describe could work if many other things were perfect in doing their part, but this is not the case. Should != does. >You could complain to the distribution maker (so every one of their users >benefits from your problem, that is the whole point of open source!), undo >the patch, run a vanilla kernel. No need to skip around (doing so is >probably much more work than just changing kernels). > > I have complained. If you want a fix, it's like Microsoft -- they don't release a fixed DVD -- if you are lucky, your fix may be rolled into the following release, but with tons of additional features that can add a host of new problems. The turnaround time / vendor release is too long. If my machine can't be upgraded or a network card used to access the internet has a new bug, I don't want to wait 3-6 months for another $85-100+ release that is just as likely to have something else broken. That's what I get with Microsoft. I'd like the granularity of being able to only replace my kernel from a stable kernel.org version that doesn't have everything, including the kitchen sink compiled in. >> I also wouldn't want to give up reporting >>kernel bugs directly to developers as I would if I am using a non-vanilla, >>or worse, some tainted module. >> >> > >If it is a distribution kernel, you should complain to them, they will >forward your complaint to the maintainers if it warrants doing so. Only if >vanilla kernel you get to swamp the maintainers directly. > > Swamp? The bug is usually already fixed in the stable release since the distro's release kernels, usually, at least a generation or two old. >The people in charge decided otherwise, for sound reasons. If you don't >like it, you are free to create you own fork off 2.6.10 (or something) and >stabilize that. That is the wonder of open source... > > ---- People same the same about MS. No one is stopping you from going off and creating your own monolithic company to replace it. But the same factors that stop you from doing that stop a viable kernel fork -- can all the people who work on the kernel be duplicated to work on a new fork? Otherwise a fork has about an ice-cube's chance in hell of succeeding. There are only so many open-source code designers/writers out there. It's not an infinite quantity that can be simply wished into existance by someone's "blow off" comment about starting your own fork. >Lots of rather pointless work. Much of it something each distribution has >to do on their own (because f.ex. vanilla 2.4 is _just fixes_, no backports >of cool (and required) new functionality), instead of cooperating in >building a better overall kernel. > > --- How long have you been selling commerical software like Microsoft's? You have their attitude nailed. "cool and new features" are always more sexy than making sure it's sane and reliable. That's what MS has done for ages -- it wasn't through "superior technology" that they one their market -- it was through "perceptions", shaped by what was "cool" and "features". Look at the wide market for "skinning" various UI's. How much of that helps functionality or stability? Eye candy is fine, but for serious work, 4 or more shell-windows are alot more friendly. >Yep. That's why nobody (and that certainly includes you) is entitled to >demand such. > > Demand? I *asked* about the idea of _reviving_ the stable series, explain why I think it is a good idea and/or problems with the current situation and you take that as a demand? Chill, dude! >Andrew Morton had been designated for the job (and he accepted). > > Very Cool. Maybe he'd like spawn stable "stubblets" off the main tree at appropriately stable times and work on an "extra-dot" of reliability. One could think of the 4th number (2.6.10.x4th) as measurements of cycles of reliability-only releases. I admit, Linus has tried to do this with the -preXX releases, but sometimes too many changes have gone into a new dev release to easily assure things are stable -- and more importantly, too many people are steering away from heavy use of the newer kernels due to their increasingly higher chances of causing problems. >>Nevertheless, it would be nice to see a no-new-features, stable series >>spun off from these development kernels, maybe .4th number releases, >>like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, >>etc...with iteritive bug fixes to the same kernel and no new features >>in such a branch, it might become stable enough for users to have confidence >>installing them on their desktop or stable machines. >> >> >The 2.6.9-x kernels from Red Hat/Fedora are targeted to be >exactly that... > > So you agree, that kernel.org is no longer providing kernels stable enough to use on desktop and server machines directly. That's what I am lamenting. I don't like using pre-compiled kernels. I prefer to build them myself and know what goes into them and tailor them for specific hardware so they are optimized for that hardware. If I wanted lower, generic performance, from pre-compiled binaries, I can get that from Microsoft. Hell, they'll even throw in a free Unix subsystem on XP and above. Of course it runs like a generic OS and I can't just download the latest source and try out patches or compile my own custom version, but that's what we expect from Microsoft. You only get what is offered by one (or more) vendors -- often only one that offers an imperfect solution that can no longer be supported when the vendor closes up shop. >>It wouldn't have to be months upon months of diverging code, as jumps >>to a new stable base can be started upon any fairly stable development >>kernel, say 2.6.10 w/e100 fixed, tracing fixed, the slab bug fix, and >>the capabilities bugs fixed going into a 2.6.10.1 that has no new features >>or old features removed. Serious bug fixes after that could go into a >>2.6.10.2, etc. Such point releases would be easier to manage and only >>be updated/maintained as long as someone was interested enough to do it. >> >> >That is exactly the model! Just that no vanillla 2.6.9.1 has been needed >yet. > > --- No? Depends on who you ask. A security bug was just published on 2.6.10. There are some issues with some mainstream drivers and regressions from 2.6.9. You don't think an extra stability release with providing only critical, severe or security bug fixes might not be appropriate? >... conveniently forgetting that it is a experimental data point that >people start using the kernel (and finding its bugs) only when it leaves >"alpha" (by whatever name), so this doesn't work. > > Forgetting nothing: having a 2.6.10.1, .2, .3 would show a commitment to the development of a stable image that is meant to be usable "off the shelf (kernel.org & mirrors)". You can tit-for-tat my response, but it doesn't change my experience with the current kernels. Reality trumps theory but perceptions trump reality. I don't see the theory of how things "should" work has had a significant effect on perceptions though they might be having a beneficial effect in reality -- it just isn't manifesting enough to change an increased perception of decreasing stability from the days of having separate stable and development branches. I was just suggesting an alternate somewhere in the middle. If you have a better way of creating a stable series of kernels coming off kernel.org, I'm not attached to any specific method of "how". -l ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series 2005-01-09 0:13 ` Reviving the concept of a stable series L A Walsh @ 2005-01-10 13:44 ` Adam Sampson 2005-01-10 16:50 ` Horst von Brand 2005-01-10 19:24 ` Alan Cox 0 siblings, 2 replies; 222+ messages in thread From: Adam Sampson @ 2005-01-10 13:44 UTC (permalink / raw) To: L A Walsh; +Cc: linux-kernel L A Walsh <lkml@tlinx.org> writes: > If you have a better way of creating a stable series of kernels > coming off kernel.org, I'm not attached to any specific method of > "how". One option would be a "Linux Legacy" project, similar to the Fedora Legacy project that backports updates to old Red Hat/Fedora Core releases: a central service that'd collect bug fixes for released kernels that distributors could then base their kernels on. That way, we'd get the stability advantages of vendor kernels without needing to repeat the effort for each distribution. Maybe some of the distribution vendors might be interested in setting up something like this? -- Adam Sampson <azz@us-lot.org> <http://offog.org/> ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series 2005-01-10 13:44 ` Adam Sampson @ 2005-01-10 16:50 ` Horst von Brand 2005-01-10 19:24 ` Alan Cox 1 sibling, 0 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-10 16:50 UTC (permalink / raw) To: Adam Sampson; +Cc: L A Walsh, linux-kernel Adam Sampson <azz@us-lot.org> said: > L A Walsh <lkml@tlinx.org> writes: > > If you have a better way of creating a stable series of kernels > > coming off kernel.org, I'm not attached to any specific method of > > "how". > One option would be a "Linux Legacy" project, similar to the Fedora > Legacy project that backports updates to old Red Hat/Fedora Core > releases: a central service that'd collect bug fixes for released > kernels that distributors could then base their kernels on. That way, > we'd get the stability advantages of vendor kernels without needing to > repeat the effort for each distribution. Didn't happen with 2.0, 2.2, or 2.4. I'd guess it won't happen for 2.6 either. > Maybe some of the distribution vendors might be interested in setting > up something like this? I have seen absolutely no interest from distributions in leaving the current 2.6 development model. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series 2005-01-10 13:44 ` Adam Sampson 2005-01-10 16:50 ` Horst von Brand @ 2005-01-10 19:24 ` Alan Cox 2005-01-10 20:50 ` jmerkey 1 sibling, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-10 19:24 UTC (permalink / raw) To: Adam Sampson; +Cc: L A Walsh, Linux Kernel Mailing List On Llu, 2005-01-10 at 13:44, Adam Sampson wrote: > L A Walsh <lkml@tlinx.org> writes: > One option would be a "Linux Legacy" project, similar to the Fedora > Legacy project that backports updates to old Red Hat/Fedora Core > releases: a central service that'd collect bug fixes for released > kernels that distributors could then base their kernels on. That way, > we'd get the stability advantages of vendor kernels without needing to > repeat the effort for each distribution. > > Maybe some of the distribution vendors might be interested in setting > up something like this? It would be essentially unmanageable unless you picked only one specific kernel and configuration set to support. Needless to say you won't find vendors even ship the same kernel. Nor for that matter would a few backports magically give you stability. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series 2005-01-10 19:24 ` Alan Cox @ 2005-01-10 20:50 ` jmerkey 0 siblings, 0 replies; 222+ messages in thread From: jmerkey @ 2005-01-10 20:50 UTC (permalink / raw) To: Alan Cox; +Cc: Adam Sampson, L A Walsh, Linux Kernel Mailing List Alan Cox wrote: >It would be essentially unmanageable unless you picked only one specific >kernel and configuration set to support. Needless to say you won't find >vendors even ship the same kernel. > >Nor for that matter would a few >backports magically give you stability. < ---------- So True. Jeff > > ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 9:57 ` Reviving the concept of a stable series (was Re: starting with 2.7) L. A. Walsh 2005-01-03 12:17 ` Robert W. Fuller 2005-01-03 14:24 ` Horst von Brand @ 2005-01-03 22:20 ` Bill Davidsen 2005-01-04 13:08 ` William Lee Irwin III 2 siblings, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 22:20 UTC (permalink / raw) To: L. A. Walsh; +Cc: linux-kernel L. A. Walsh wrote: > I don't know about #3 below, but #1 and #2 are certainly true. > I always preferred to run a vanilla stable kernel as I did not > trust the vendors' kernels because their patches were not as well > eyed as the vanilla kernel. I prefer to compile a kernel for > my specific machines, some of which are old and do better with a > hand-configured kernel rather than a Microsoftian monolith that > is compiled with all possible options as modules. Same conclusion from another direction. If I make a patch which I know can't (or won't) be accepted into the mainline, it's easier for me to carry it forward on a mainline kernel. I'm happy to say I haven't had to do that for a while, although I will probably rehack the network code a little this summer. > Nevertheless, it would be nice to see a no-new-features, stable series > spun off from these development kernels, maybe .4th number releases, > like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2, > etc...with iteritive bug fixes to the same kernel and no new features > in such a branch, it might become stable enough for users to have > confidence > installing them on their desktop or stable machines. > > It wouldn't have to be months upon months of diverging code, as jumps > to a new stable base can be started upon any fairly stable development > kernel, say 2.6.10 w/e100 fixed, tracing fixed, the slab bug fix, and > the capabilities bugs fixed going into a 2.6.10.1 that has no new features > or old features removed. Serious bug fixes after that could go into a > 2.6.10.2, etc. Such point releases would be easier to manage and only > be updated/maintained as long as someone was interested enough to do it. > > The same process would be applied to a future dev-kernel that appears to be > mostly stable after some number of weeks of alpha testing. It may be > the case that a given furture dev-kernel has no stable branch off of it > because it either a) didn't need one, or b) was too far from stable to > start > one. If the -rc process were in place, new feature freeze until the big green bugs were fixed just before the next release, that actually might be most of a solution. No one bug akpm can accurately asses how well fixes come back from vendors, but I suspect that the kernel is moving too fast and vendors "pick one" and stabilize that, by which time the kernel.org is generations down the road. It's possible that some fixes are then rediffed against the current kernel and fed, but I have zero information on that happening or not. >> 3) In some cases the commercial vendors don't seem to release >> source to some of the kernels except to people who have bought >> the packages, so those vendor kernel fixes aren't 'publically' >> visible. That shouldn't happen, and in practice it's rare. But you may have to search a bit to find the sources... -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-03 22:20 ` Reviving the concept of a stable series (was Re: starting with 2.7) Bill Davidsen @ 2005-01-04 13:08 ` William Lee Irwin III 2005-01-04 18:20 ` Dave Jones 0 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 13:08 UTC (permalink / raw) To: Bill Davidsen; +Cc: L. A. Walsh, linux-kernel On Mon, Jan 03, 2005 at 05:20:42PM -0500, Bill Davidsen wrote: > If the -rc process were in place, new feature freeze until the big green > bugs were fixed just before the next release, that actually might be > most of a solution. > No one bug akpm can accurately asses how well fixes come back from > vendors, but I suspect that the kernel is moving too fast and vendors > "pick one" and stabilize that, by which time the kernel.org is > generations down the road. It's possible that some fixes are then > rediffed against the current kernel and fed, but I have zero information > on that happening or not. It does happen. I can't give a good estimate of how often. Someone at a distro may be able to help here, though it's unclear what this specific point is useful for. What is a useful observation is that the 2.6-style development model is not in use in these instances, which instead use the older "frozen" model. This means that using frozen models in mainline is redundant. The function and service are available elsewhere and numerous simultaneously frozen trees guarantees no forward progress during such syzygys. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-04 13:08 ` William Lee Irwin III @ 2005-01-04 18:20 ` Dave Jones 2005-01-06 15:31 ` Barry K. Nathan 2005-01-06 18:23 ` [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) Barry K. Nathan 0 siblings, 2 replies; 222+ messages in thread From: Dave Jones @ 2005-01-04 18:20 UTC (permalink / raw) To: William Lee Irwin III; +Cc: Bill Davidsen, L. A. Walsh, linux-kernel On Tue, Jan 04, 2005 at 05:08:46AM -0800, William Lee Irwin III wrote: > On Mon, Jan 03, 2005 at 05:20:42PM -0500, Bill Davidsen wrote: > > If the -rc process were in place, new feature freeze until the big green > > bugs were fixed just before the next release, that actually might be > > most of a solution. > > No one bug akpm can accurately asses how well fixes come back from > > vendors, but I suspect that the kernel is moving too fast and vendors > > "pick one" and stabilize that, by which time the kernel.org is > > generations down the road. It's possible that some fixes are then > > rediffed against the current kernel and fed, but I have zero information > > on that happening or not. > > It does happen. I can't give a good estimate of how often. Someone at a > distro may be able to help here, though it's unclear what this specific > point is useful for. Pull up a chair, this is going to be a long one. When we shipped Fedora Core 3, we drew a line in the sand, and decided that 2.6.9 was the kernel we were going to ship with. It happened to coincide nicely with the final release date, and everyone was happy. Post release, the myriad of users filled RH bugzilla diligently with their many reports of interesting failures. Upstream had now started charging ahead with what was to be 2.6.10. The delta between 2.6.9 -> 2.6.10 was around 4000 changesets. Cherry picking csets to backport to 2.6.9 at this rate of change is nigh on impossible. You /will/ miss stuff. In the absense of a 2.6.9.1, we chose to use Alan's -ac patches as a base to pick up most of the interesting meat, and then cherry pick anything else which people had noticed go past, or in some cases, after investigation into a bugreport. So now we're at our 2.6.9-ac+a few dozen 2.6.10 csets and all is happy with the world. Except for the regressions. As an example, folks upgrading from Fedora core 2, with its 2.6.8 kernel found that ACPI no longer switched off their machines for example. Much investigation went into trying to pin this down. Kudos to Len Brown and team for spending many an hour staring into bug reports on this issue, but ultimately the cause was never found. It was noted by several of our users seeing this problem that 2.6.10 no longer exhibits this flaw. Yet our 2.6.9-ac+backports+every-2.6.10-acpi-cset also was broken. It's likely Fedora will get a 2.6.10 based update before the fault is ever really found for a 2.6.9 backport. This is just one example of a regression that crept in unnoticed, and got fixed almost by accident. (If it was intentionally fixed, we'd know which patches we needed to backport 8-) For distro kernels to be the 'stable' branch, we *rely* on help from various subsystem maintainers to continue to bugfix old kernels, despite it being unsexy. I admit it's painful, and given the option, replying "just use 2.6.10-bk6" is a much easier alternative, but with thousands of changes going into tree each month, it's not feasable for a distro to ship updates on that basis without something happening to deal with regressions. As for stuff going back upstream.. You may be surprised how many bugs our 2.6.9-ac-many-backports hybrid has turned up which turned out to be just as relevant on 2.6.10 Here's the patchcount in our current trees.. Fedora Core 2: 245 Fedora Core 3: 63 Rawhide: 76 FC2 is our 2.6.9 hybrid (the fc3 kernel got backport to fc2 as an update), FC3 is a rebase to 2.6.10-ac2. rawhide (FC4-to-be) is 2.6.10-bk6. Note we still have 63 patches in FC3. Out of those, just over a dozen are 'features' that we added. The majority of the rest are real bugfixes, currently languishing in out-of-tree repositories for projects like NFS, s390, e1000 updates etc.. Note also that when FC3 first shipped, before we started backporting 2.6.10 bits, the patchcount was around 40 or so, so in the 2.6.9->2.6.10 rebase, we 'grew' around 13 patches. Each time I rebase to a new upstream, I want to get back to (or better than) the original patchcount where possible. When this doesn't happen, it means we're accumulating stuff that isn't making its way upstream fast enough. So, of those 182 patches we dropped in our 2.6.10 rebase.. Some of them were upstream backports, but some of them were patches we pushed upstream that we now get to drop on a rebase. So the push/pull ecosystem is working out pretty well in this regard Whilst I'd like to get even more of this stuff upstream, it's the job of those out-of-tree pool maintainers to push their work, not mine. Dave ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: Reviving the concept of a stable series (was Re: starting with 2.7) 2005-01-04 18:20 ` Dave Jones @ 2005-01-06 15:31 ` Barry K. Nathan 2005-01-06 18:23 ` [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) Barry K. Nathan 1 sibling, 0 replies; 222+ messages in thread From: Barry K. Nathan @ 2005-01-06 15:31 UTC (permalink / raw) To: Dave Jones, William Lee Irwin III, Bill Davidsen, L. A. Walsh, linux-kernel On Tue, Jan 04, 2005 at 01:20:17PM -0500, Dave Jones wrote: > So now we're at our 2.6.9-ac+a few dozen 2.6.10 csets > and all is happy with the world. Except for the regressions. > As an example, folks upgrading from Fedora core 2, with its > 2.6.8 kernel found that ACPI no longer switched off their > machines for example. Much investigation went into > trying to pin this down. Kudos to Len Brown and team for > spending many an hour staring into bug reports on this > issue, but ultimately the cause was never found. > It was noted by several of our users seeing this problem > that 2.6.10 no longer exhibits this flaw. Yet our > 2.6.9-ac+backports+every-2.6.10-acpi-cset also was broken. > It's likely Fedora will get a 2.6.10 based update before > the fault is ever really found for a 2.6.9 backport. I just did some experimentation on one of my boxes. For me the ACPI shutdown problem: + does not happen on mainline 2.6.9 + does not happen on 2.6.9-ac16 + does happen on 2.6.9-1.724_FC3 + does not happen on mainline 2.6.10 + does not happen on 2.6.10-1.727_FC3 Just mentioning it for whatever relevance it may have to this debate, and in case it helps find a fix. (I'll see if I can narrow things down any further.) -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 222+ messages in thread
* [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) 2005-01-04 18:20 ` Dave Jones 2005-01-06 15:31 ` Barry K. Nathan @ 2005-01-06 18:23 ` Barry K. Nathan 2005-01-06 19:07 ` Dave Jones 2005-01-06 21:19 ` Bill Davidsen 1 sibling, 2 replies; 222+ messages in thread From: Barry K. Nathan @ 2005-01-06 18:23 UTC (permalink / raw) To: Dave Jones, William Lee Irwin III, Bill Davidsen, L. A. Walsh, linux-kernel (The humor in this e-mail may be caustic, but it's **really** not intended to start a flamewar. Feel free to mentally insert one or two smileys at the end of each paragraph. If the jokes don't make sense, maybe they'll make more sense after you finish reading the entire message. Maybe these jokes are cruel, but honestly, the irony here just absolutely *kills* me and I can't help myself right now.) On Tue, Jan 04, 2005 at 01:20:17PM -0500, Dave Jones wrote: > Post release, the myriad of users filled RH bugzilla diligently > with their many reports of interesting failures. Upstream had > now started charging ahead with what was to be 2.6.10. > > The delta between 2.6.9 -> 2.6.10 was around 4000 changesets. > Cherry picking csets to backport to 2.6.9 at this rate of > change is nigh on impossible. You /will/ miss stuff. Food for thought: If upstream doesn't charge ahead, somebody else will. And that will also cause regressions, albeit ones that are even harder to see. People will think they're looking in the right direction, but will be unable to see anything, and that will just confuse everyone more. (If that doesn't make sense now, read this message all the way through, then start reading it from the beginning again.) [snip] > So now we're at our 2.6.9-ac+a few dozen 2.6.10 csets > and all is happy with the world. Except for the regressions. > As an example, folks upgrading from Fedora core 2, with its > 2.6.8 kernel found that ACPI no longer switched off their > machines for example. Much investigation went into > trying to pin this down. Kudos to Len Brown and team for > spending many an hour staring into bug reports on this > issue, but ultimately the cause was never found. Until now. (Keep reading.) > It was noted by several of our users seeing this problem > that 2.6.10 no longer exhibits this flaw. Yet our > 2.6.9-ac+backports+every-2.6.10-acpi-cset also was broken. I will not make vendor feature patches an issue in this thread. I'm not going to exploit for argumentative purposes your odd definition of the word "backport". > It's likely Fedora will get a 2.6.10 based update before > the fault is ever really found for a 2.6.9 backport. "Backport"? There you go again! > This is just one example of a regression that crept in Crept in, yes... but into where? > unnoticed, and got fixed almost by accident. (If it It wasn't fixed *almost* by accident. It *was* fixed by accident -- yours. > was intentionally fixed, we'd know which patches > we needed to backport 8-) Or which patches to avoid "backporting", as the case may be. [snip] > So, of those 182 patches we dropped in our 2.6.10 rebase.. > Some of them were upstream backports, but some of them were > patches we pushed upstream that we now get to drop on a rebase. And one of them (that I noticed, anyway) was a "backport" that you (whether accidentally or intentionally) stopped "backporting" when you rebased to 2.6.10. If the "backport" jokes don't make sense yet, consider this dilemma: If a backported patch has not been committed upstream yet, then is it really a backport? The following patch removes the ACPI shutdown bug from 2.6.9-1.724_FC3, at least in my testing on my affected system. The diff almost succeeds in speaking for itself, but to fully understand what it's saying, you will also need to grep a 2.6.10 Fedora kernel-2.6.spec file for "kexec". -Barry K. Nathan <barryn@pobox.com> --- kernel-2.6.spec.ACPI-shutdown-bug 2005-01-06 08:40:15.264970728 -0800 +++ kernel-2.6.spec.no-ACPI-shutdown-bug 2005-01-06 08:40:08.629979400 -0800 @@ -863,7 +863,7 @@ %patch1081 -p1 # Kexec in preparation for kexec-based dump -%patch1090 -p1 +#patch1090 -p1 # # Sata update ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) 2005-01-06 18:23 ` [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) Barry K. Nathan @ 2005-01-06 19:07 ` Dave Jones 2005-01-06 21:19 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Dave Jones @ 2005-01-06 19:07 UTC (permalink / raw) To: Barry K. Nathan Cc: William Lee Irwin III, Bill Davidsen, L. A. Walsh, linux-kernel On Thu, Jan 06, 2005 at 10:23:36AM -0800, Barry K. Nathan wrote: > If the "backport" jokes don't make sense yet, consider this dilemma: If > a backported patch has not been committed upstream yet, then is it > really a backport? In this case, the patch was taken from 2.6.9-mm. Whilst it's not officially 'upstream', and things do occasionally get merged there that don't move to Linus' tree, this one was chosen on the merits that it was a useful feature worthy of inclusion. Quite a few features have been beaten out this way. Ext3 reservations, 4K stacks to name two off the top of my head. All these have had exposure in Fedora testing trees which has turned up bugs no-one saw when they were in -mm. Had they not gotten that exposure, those features may have never got to where they are today. The odd part is.. this patch was included in our 2.6.8 tree without problems. It also didn't cause problems for everyone when it was in -mm (though some did see the same bug). Spooky. > The following patch removes the ACPI shutdown bug from 2.6.9-1.724_FC3, > at least in my testing on my affected system. The diff almost succeeds > in speaking for itself, but to fully understand what it's saying, you > will also need to grep a 2.6.10 Fedora kernel-2.6.spec file for "kexec". > > -Barry K. Nathan <barryn@pobox.com> > > --- kernel-2.6.spec.ACPI-shutdown-bug 2005-01-06 08:40:15.264970728 -0800 > +++ kernel-2.6.spec.no-ACPI-shutdown-bug 2005-01-06 08:40:08.629979400 -0800 > @@ -863,7 +863,7 @@ > %patch1081 -p1 > > # Kexec in preparation for kexec-based dump > -%patch1090 -p1 > +#patch1090 -p1 Thanks. Had I not already dropped this when I updated our tree to 2.6.10, this would have been useful. Dave ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) 2005-01-06 18:23 ` [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) Barry K. Nathan 2005-01-06 19:07 ` Dave Jones @ 2005-01-06 21:19 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-06 21:19 UTC (permalink / raw) To: Barry K. Nathan; +Cc: Dave Jones, William Lee Irwin III, linux-kernel Barry K. Nathan wrote: > If the "backport" jokes don't make sense yet, consider this dilemma: If > a backported patch has not been committed upstream yet, then is it > really a backport? If a patch is against a later base and is rediffed to be against an earlier base, hopefully with side effects controlled, I think it's reasonable to call it a backport. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:15 ` Adrian Bunk ` (2 preceding siblings ...) 2005-01-02 23:21 ` Dr. David Alan Gilbert @ 2005-01-03 0:19 ` William Lee Irwin III 2005-01-03 0:38 ` Adrian Bunk 2005-01-03 15:20 ` Rik van Riel 4 siblings, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 0:19 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: >> This is not optimism. This is experience. Every ``stable'' kernel I've >> seen is a pile of incredibly stale code where vi'ing any file in it >> instantly reveals numerous months or years old bugs fixed upstream. >> What is gained in terms of reducing the risk of regressions is more >> than lost by the loss of critical examination and by a long longshot. On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > The main advantage with stable kernels in the good old days (tm) when 4 > and 6 were even numbers was that you knew if something didn't work, and > upgrading to a new kernel inside this stable kernel series had a > relatively low risk of new breakages. This meant one big migration every > few years and relatively easy upgrades between stable series kernels. This never saved anyone any pain. 2.4.x was not the stable kernel you're painting it to be until 2.4.20 or later, and by the time it became so the fixes for major regressions that occurred during 2.3.x were deemphasized and ignored for anything prior to 2.6.x. On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > Nowadays in 2.6, every new 2.6 kernel has several regressions compared > to the previous one, and additionally obsolete but used code like > ipchains and devfs is scheduled for removal making upgrades even harder > for many users. My experience tells me that the number of regressions in 2.6.x compared to purportedly ``far stabler'' kernels is about the same or (gasp!) less. So the observable advantage of the ``frozen'' or ``stable'' model is less than or equal to zero. Frankly, kernel hacking is a difficult enough task (not that I personally find it so) that frivolous patches are not overwhemingly numerous. The ``barrier'' you're erecting is primarily acting as a barrier to fixes, not bugs. On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > There's the point that most users should use distribution kernels, but > consider e.g. that there are poor souls with new hardware not supported > by the 3 years old 2.4.18 kernel in the stable part of your Debian > distribution. Again, the loss of critical examination far outweighs the purported defense against regressions. The most typical result of playing the fix backporting game for extended periods of time is numerous rounds of months-long bughunts for bugs whose fixes were merged years ago upstream. When the bugs are at long last found, they are discovered to fix the problems of hundreds of users until the next such problem surfaces. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:19 ` starting with 2.7 William Lee Irwin III @ 2005-01-03 0:38 ` Adrian Bunk 2005-01-03 0:49 ` Adam Mercer ` (2 more replies) 0 siblings, 3 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 0:38 UTC (permalink / raw) To: William Lee Irwin III Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, Jan 02, 2005 at 04:19:17PM -0800, William Lee Irwin III wrote: > On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: > >> This is not optimism. This is experience. Every ``stable'' kernel I've > >> seen is a pile of incredibly stale code where vi'ing any file in it > >> instantly reveals numerous months or years old bugs fixed upstream. > >> What is gained in terms of reducing the risk of regressions is more > >> than lost by the loss of critical examination and by a long longshot. > > On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > > The main advantage with stable kernels in the good old days (tm) when 4 > > and 6 were even numbers was that you knew if something didn't work, and > > upgrading to a new kernel inside this stable kernel series had a > > relatively low risk of new breakages. This meant one big migration every > > few years and relatively easy upgrades between stable series kernels. > > This never saved anyone any pain. 2.4.x was not the stable kernel > you're painting it to be until 2.4.20 or later, and by the time it > became so the fixes for major regressions that occurred during 2.3.x > were deemphasized and ignored for anything prior to 2.6.x. I don't know which specific regressions you have in mind, but for > 95% of the users 2.4 is a pretty usable kernel. > On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > > Nowadays in 2.6, every new 2.6 kernel has several regressions compared > > to the previous one, and additionally obsolete but used code like > > ipchains and devfs is scheduled for removal making upgrades even harder > > for many users. > > My experience tells me that the number of regressions in 2.6.x compared > to purportedly ``far stabler'' kernels is about the same or (gasp!) > less. So the observable advantage of the ``frozen'' or ``stable'' model > is less than or equal to zero. > > Frankly, kernel hacking is a difficult enough task (not that I > personally find it so) that frivolous patches are not overwhemingly > numerous. The ``barrier'' you're erecting is primarily acting as a > barrier to fixes, not bugs. My point is different. Perhaps the number of fixes for bugs equals the number of new bugs in 2.6 . But it's not about the number of bugs alone. The question is the number of regressions compared to a previous kernel in this series. 2.4 -> 2.6 is a major migration. 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause problems. Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an existing setup that worked in 2.6.9 . > On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: > > There's the point that most users should use distribution kernels, but > > consider e.g. that there are poor souls with new hardware not supported > > by the 3 years old 2.4.18 kernel in the stable part of your Debian > > distribution. > > Again, the loss of critical examination far outweighs the purported > defense against regressions. The most typical result of playing the fix > backporting game for extended periods of time is numerous rounds of > months-long bughunts for bugs whose fixes were merged years ago upstream. > When the bugs are at long last found, they are discovered to fix the > problems of hundreds of users until the next such problem surfaces. The main question is, whether it might be possible to make a very short 2.7 line (< 6 months). Imagine e.g. a feature freeze for 2.6 now. Then 2.7 starts with a feature freeze for 2.7 one or two months later. During this time, all the changes that do now flood into 2.6 would go into 2.7, and then there are a few months of stabilizing 2.7 . It's quite the opposite of the current 2.6 model, but a quick 2.8 should also avoid this problem you describe. Basically, in this proposal (if it started today), what was expected to be called 2.6.11 will be called 2.7.0, and 2.6.11 will be a bugfix-only kernel (considering the amount of changes more like the current -ac than the latest -mm). > -- wli cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:38 ` Adrian Bunk @ 2005-01-03 0:49 ` Adam Mercer 2005-01-03 1:20 ` William Lee Irwin III 2005-01-03 12:13 ` Steven Rostedt 2005-01-03 1:21 ` William Lee Irwin III 2005-01-03 22:26 ` Bill Davidsen 2 siblings, 2 replies; 222+ messages in thread From: Adam Mercer @ 2005-01-03 0:49 UTC (permalink / raw) To: linux-kernel On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <bunk@stusta.de> wrote: > 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause > problems. > > Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an > existing setup that worked in 2.6.9 . IIRC 2.4.9 -> 2.4.10 broke a few setups as well. Cheers Adam ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:49 ` Adam Mercer @ 2005-01-03 1:20 ` William Lee Irwin III 2005-01-03 12:13 ` Steven Rostedt 1 sibling, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 1:20 UTC (permalink / raw) To: Adam Mercer; +Cc: linux-kernel On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <bunk@stusta.de> wrote: >> 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause >> problems. >> Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an >> existing setup that worked in 2.6.9 . On Mon, Jan 03, 2005 at 12:49:22AM +0000, Adam Mercer wrote: > IIRC 2.4.9 -> 2.4.10 broke a few setups as well. Negligible. Compare to 2.4.9 vs. 2.4.10 -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:49 ` Adam Mercer 2005-01-03 1:20 ` William Lee Irwin III @ 2005-01-03 12:13 ` Steven Rostedt 1 sibling, 0 replies; 222+ messages in thread From: Steven Rostedt @ 2005-01-03 12:13 UTC (permalink / raw) To: Adam Mercer; +Cc: LKML On Mon, 2005-01-03 at 00:49 +0000, Adam Mercer wrote: > On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <bunk@stusta.de> wrote: > > > 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause > > problems. > > > > Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an > > existing setup that worked in 2.6.9 . Yes, it broke my NVIDIA module. I had to hack it to get it to work. Yes, yes, I know NVIDIA bad and all that, but it is an example, and those that have NVIDIA cards and want 3D graphics, need to bow to the evil power that is. > > IIRC 2.4.9 -> 2.4.10 broke a few setups as well. > IIRC, there was a big argument to what was going on in the 2.4.9->2.4.10 kernel. Mainly the new VM. Alan Cox didn't want to include it because a change like that was too big for a stable release. Actually, I thought that 2.4.0 -> 2.4.14 was still unstable, and didn't migrate much on my "stable" machines, until 2.4.14. I think both approaches have their pros and cons. Maybe the problem is that 2.x -> 2.x+1 is too slow. If it was faster, then it wouldn't be a problem. The way I develop applications/libraries is that if I change an interface, it changes the second number, and if I make major changes the first is changed. Maybe keep 2.6.x just for bug fixes (like usual) and start 2.7 for updates and jump quicker to 2.8. When a major design is done, that should be 3.0. I believe that the kernel has settled with the 2.6 series to not be jumping to something different as 2.4->2.6 did any time soon. So maybe make 3.0 the next big change, and let the 2.x rise quicker. As to use the distribution kernels? People do that? The first thing I do when installing a distribution, is to download and run the latests kernel ;-) -- Steve ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:38 ` Adrian Bunk 2005-01-03 0:49 ` Adam Mercer @ 2005-01-03 1:21 ` William Lee Irwin III 2005-01-03 22:26 ` Bill Davidsen 2 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 1:21 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 01:38:58AM +0100, Adrian Bunk wrote: > Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an > existing setup that worked in 2.6.9 . c.f. the reply to Adam Mercery wrt. 2.4.9 vs. 2.4.10 -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 0:38 ` Adrian Bunk 2005-01-03 0:49 ` Adam Mercer 2005-01-03 1:21 ` William Lee Irwin III @ 2005-01-03 22:26 ` Bill Davidsen 2 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 22:26 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel Adrian Bunk wrote: > On Sun, Jan 02, 2005 at 04:19:17PM -0800, William Lee Irwin III wrote: > >>On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote: >> >>>>This is not optimism. This is experience. Every ``stable'' kernel I've >>>>seen is a pile of incredibly stale code where vi'ing any file in it >>>>instantly reveals numerous months or years old bugs fixed upstream. >>>>What is gained in terms of reducing the risk of regressions is more >>>>than lost by the loss of critical examination and by a long longshot. >> >>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: >> >>>The main advantage with stable kernels in the good old days (tm) when 4 >>>and 6 were even numbers was that you knew if something didn't work, and >>>upgrading to a new kernel inside this stable kernel series had a >>>relatively low risk of new breakages. This meant one big migration every >>>few years and relatively easy upgrades between stable series kernels. >> >>This never saved anyone any pain. 2.4.x was not the stable kernel >>you're painting it to be until 2.4.20 or later, and by the time it >>became so the fixes for major regressions that occurred during 2.3.x >>were deemphasized and ignored for anything prior to 2.6.x. > > > I don't know which specific regressions you have in mind, but for > >>95% of the users 2.4 is a pretty usable kernel. > > >>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: >> >>>Nowadays in 2.6, every new 2.6 kernel has several regressions compared >>>to the previous one, and additionally obsolete but used code like >>>ipchains and devfs is scheduled for removal making upgrades even harder >>>for many users. >> >>My experience tells me that the number of regressions in 2.6.x compared >>to purportedly ``far stabler'' kernels is about the same or (gasp!) >>less. So the observable advantage of the ``frozen'' or ``stable'' model >>is less than or equal to zero. >> >>Frankly, kernel hacking is a difficult enough task (not that I >>personally find it so) that frivolous patches are not overwhemingly >>numerous. The ``barrier'' you're erecting is primarily acting as a >>barrier to fixes, not bugs. > > > My point is different. > > Perhaps the number of fixes for bugs equals the number of new bugs > in 2.6 . > > But it's not about the number of bugs alone. The question is the number > of regressions compared to a previous kernel in this series. > > 2.4 -> 2.6 is a major migration. > > 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause > problems. > > Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an > existing setup that worked in 2.6.9 . > > >>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote: >> >>>There's the point that most users should use distribution kernels, but >>>consider e.g. that there are poor souls with new hardware not supported >>>by the 3 years old 2.4.18 kernel in the stable part of your Debian >>>distribution. >> >>Again, the loss of critical examination far outweighs the purported >>defense against regressions. The most typical result of playing the fix >>backporting game for extended periods of time is numerous rounds of >>months-long bughunts for bugs whose fixes were merged years ago upstream. >>When the bugs are at long last found, they are discovered to fix the >>problems of hundreds of users until the next such problem surfaces. > > > The main question is, whether it might be possible to make a very short > 2.7 line (< 6 months). > > Imagine e.g. a feature freeze for 2.6 now. Then 2.7 starts with a > feature freeze for 2.7 one or two months later. During this time, all > the changes that do now flood into 2.6 would go into 2.7, and then > there are a few months of stabilizing 2.7 . > > It's quite the opposite of the current 2.6 model, but a quick 2.8 should > also avoid this problem you describe. > > Basically, in this proposal (if it started today), what was expected to > be called 2.6.11 will be called 2.7.0, and 2.6.11 will be a bugfix-only > kernel (considering the amount of changes more like the current -ac than > the latest -mm). The development policy is set by majority vote on a regular basis. However, since only one vote counts and Linus prefers it the way it is, we live with it. In my opinion the stable series is -ac, Alan actually runs the kernels. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 22:15 ` Adrian Bunk ` (3 preceding siblings ...) 2005-01-03 0:19 ` starting with 2.7 William Lee Irwin III @ 2005-01-03 15:20 ` Rik van Riel 2005-01-03 15:29 ` Adrian Bunk 2005-01-03 23:06 ` Bill Davidsen 4 siblings, 2 replies; 222+ messages in thread From: Rik van Riel @ 2005-01-03 15:20 UTC (permalink / raw) To: Adrian Bunk Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Sun, 2 Jan 2005, Adrian Bunk wrote: > The main advantage with stable kernels in the good old days (tm) when 4 > Nowadays in 2.6, every new 2.6 kernel has several regressions compared > to the previous one, and additionally obsolete but used code like 2.2 before 2.2.20 also had this kind of problem, as did the 2.4 kernel before 2.4.20 or thereabouts. I'm pretty sure 2.6 is actually doing better than the early 2.0, 2.2 and 2.4 kernels... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:20 ` Rik van Riel @ 2005-01-03 15:29 ` Adrian Bunk 2005-01-03 15:37 ` William Lee Irwin III 2005-01-03 18:18 ` Wakko Warner 2005-01-03 23:06 ` Bill Davidsen 1 sibling, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 15:29 UTC (permalink / raw) To: Rik van Riel Cc: William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 10:20:40AM -0500, Rik van Riel wrote: > On Sun, 2 Jan 2005, Adrian Bunk wrote: > > >The main advantage with stable kernels in the good old days (tm) when 4 > > >Nowadays in 2.6, every new 2.6 kernel has several regressions compared > >to the previous one, and additionally obsolete but used code like > > 2.2 before 2.2.20 also had this kind of problem, as did > the 2.4 kernel before 2.4.20 or thereabouts. > > I'm pretty sure 2.6 is actually doing better than the > early 2.0, 2.2 and 2.4 kernels... My personal impression was that even the 2.6.0-test kernels were much better than the 2.4.0-test kernels. But 2.6.20 will most likely still have the stability of the early 2.6 kernels instead of a greatly increased stability as observed in 2.2.20 and 2.4.20 . cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:29 ` Adrian Bunk @ 2005-01-03 15:37 ` William Lee Irwin III 2005-01-03 17:39 ` Felipe Alfaro Solana 2005-01-03 18:18 ` Wakko Warner 1 sibling, 1 reply; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 15:37 UTC (permalink / raw) To: Adrian Bunk Cc: Rik van Riel, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 10:20:40AM -0500, Rik van Riel wrote: >> 2.2 before 2.2.20 also had this kind of problem, as did >> the 2.4 kernel before 2.4.20 or thereabouts. >> I'm pretty sure 2.6 is actually doing better than the >> early 2.0, 2.2 and 2.4 kernels... On Mon, Jan 03, 2005 at 04:29:53PM +0100, Adrian Bunk wrote: > My personal impression was that even the 2.6.0-test kernels were much > better than the 2.4.0-test kernels. > But 2.6.20 will most likely still have the stability of the early > 2.6 kernels instead of a greatly increased stability as observed in > 2.2.20 and 2.4.20 . This is speculation; there is no reason not to expect the process to converge to as great of stability or greater stability than the 2.4-style process. I specuate that it will in fact do precisely that. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:37 ` William Lee Irwin III @ 2005-01-03 17:39 ` Felipe Alfaro Solana 2005-01-03 20:59 ` Horst von Brand 2005-01-03 23:21 ` Bill Davidsen 0 siblings, 2 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-03 17:39 UTC (permalink / raw) To: William Lee Irwin III Cc: Adrian Bunk, linux-kernel, Rik van Riel, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 3 Jan 2005, at 16:37, William Lee Irwin III wrote: > On Mon, Jan 03, 2005 at 10:20:40AM -0500, Rik van Riel wrote: >>> 2.2 before 2.2.20 also had this kind of problem, as did >>> the 2.4 kernel before 2.4.20 or thereabouts. >>> I'm pretty sure 2.6 is actually doing better than the >>> early 2.0, 2.2 and 2.4 kernels... > > On Mon, Jan 03, 2005 at 04:29:53PM +0100, Adrian Bunk wrote: >> My personal impression was that even the 2.6.0-test kernels were much >> better than the 2.4.0-test kernels. >> But 2.6.20 will most likely still have the stability of the early >> 2.6 kernels instead of a greatly increased stability as observed in >> 2.2.20 and 2.4.20 . > > This is speculation; there is no reason not to expect the process to > converge to as great of stability or greater stability than the > 2.4-style process. I specuate that it will in fact do precisely that. I would like to comment in that the issue is not exclusively targeted to stability, but the ability to keep up with kernel development. For example, it was pretty common for older versions of VMWare and NVidia driver to break up whenever a new kernel version was released. I think it's a PITA for developers to rework some of the closed-source code to adopt the new changes in the Linux kernel. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:39 ` Felipe Alfaro Solana @ 2005-01-03 20:59 ` Horst von Brand 2005-01-03 21:47 ` Felipe Alfaro Solana 2005-01-04 5:44 ` Willy Tarreau 2005-01-03 23:21 ` Bill Davidsen 1 sibling, 2 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-03 20:59 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: William Lee Irwin III, Adrian Bunk, linux-kernel, Rik van Riel, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III Felipe Alfaro Solana <lkml@mac.com> said: [...] > I would like to comment in that the issue is not exclusively targeted > to stability, but the ability to keep up with kernel development. For > example, it was pretty common for older versions of VMWare and NVidia > driver to break up whenever a new kernel version was released. That is the price for closed-source drivers. > I think it's a PITA for developers to rework some of the closed-source > code to adopt the new changes in the Linux kernel. Open up the code. Most of the changes will then be done as a matter of course by others. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 20:59 ` Horst von Brand @ 2005-01-03 21:47 ` Felipe Alfaro Solana 2005-01-03 21:48 ` Rik van Riel 2005-01-03 22:01 ` Sean 2005-01-04 5:44 ` Willy Tarreau 1 sibling, 2 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-03 21:47 UTC (permalink / raw) To: Horst von Brand Cc: Adrian Bunk, linux-kernel, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 3 Jan 2005, at 21:59, Horst von Brand wrote: > Felipe Alfaro Solana <lkml@mac.com> said: > > [...] > >> I would like to comment in that the issue is not exclusively targeted >> to stability, but the ability to keep up with kernel development. For >> example, it was pretty common for older versions of VMWare and NVidia >> driver to break up whenever a new kernel version was released. > > That is the price for closed-source drivers. > >> I think it's a PITA for developers to rework some of the closed-source >> code to adopt the new changes in the Linux kernel. > > Open up the code. Most of the changes will then be done as a matter of > course by others. Unfortunately, you can't force the entire hardware industry to open up their drivers. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:47 ` Felipe Alfaro Solana @ 2005-01-03 21:48 ` Rik van Riel 2005-01-03 22:03 ` Felipe Alfaro Solana 2005-01-03 22:01 ` Sean 1 sibling, 1 reply; 222+ messages in thread From: Rik van Riel @ 2005-01-03 21:48 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, Adrian Bunk, linux-kernel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, 3 Jan 2005, Felipe Alfaro Solana wrote: > On 3 Jan 2005, at 21:59, Horst von Brand wrote: >> Open up the code. Most of the changes will then be done as a matter of >> course by others. > > Unfortunately, you can't force the entire hardware industry to open up > their drivers. That's ok. I don't have to buy that hardware. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:48 ` Rik van Riel @ 2005-01-03 22:03 ` Felipe Alfaro Solana 2005-01-03 22:10 ` Rik van Riel ` (3 more replies) 0 siblings, 4 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-03 22:03 UTC (permalink / raw) To: Rik van Riel Cc: linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 3 Jan 2005, at 22:48, Rik van Riel wrote: > On Mon, 3 Jan 2005, Felipe Alfaro Solana wrote: >> On 3 Jan 2005, at 21:59, Horst von Brand wrote: > >>> Open up the code. Most of the changes will then be done as a matter >>> of >>> course by others. >> >> Unfortunately, you can't force the entire hardware industry to open >> up their drivers. > > That's ok. I don't have to buy that hardware. Gosh! I bought an ATI video card, I bought a VMware license, etc.... I want to keep using them. Changing a "stable" kernel will continuously annoy users and vendors. I think new developments will force a 2.7 branch: when 2.6 feature set stabilizes, people will keep more time testing a stable, relatively static kernel base, finding bugs, instead of trying to keep up with changes. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:03 ` Felipe Alfaro Solana @ 2005-01-03 22:10 ` Rik van Riel 2005-01-03 22:14 ` Christoph Hellwig ` (2 subsequent siblings) 3 siblings, 0 replies; 222+ messages in thread From: Rik van Riel @ 2005-01-03 22:10 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, 3 Jan 2005, Felipe Alfaro Solana wrote: > On 3 Jan 2005, at 22:48, Rik van Riel wrote: >> On Mon, 3 Jan 2005, Felipe Alfaro Solana wrote: >>> Unfortunately, you can't force the entire hardware industry to open up >>> their drivers. >> >> That's ok. I don't have to buy that hardware. > > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > want to keep using them. That's your choice, and you (and your vendors) will have to deal with the issues. I don't see why we should hold back the development of Linux for it... > Changing a "stable" kernel will continuously annoy users and vendors. On the other hand, not having a feature users need available in a stable kernel also annoys users and vendors. During the 2.4 days this lead to every distribution needing to do a bunch of backports from the 2.5 kernel, and the availability of 2.4 kernels with every possible subset of 2.5 features - but none with all the features. Arguably, that is a much worse situation for users and vendors than a faster-changing 2.6 tree, where at least everybody is using the same tree. You can't have your cake and eat it, too. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:03 ` Felipe Alfaro Solana 2005-01-03 22:10 ` Rik van Riel @ 2005-01-03 22:14 ` Christoph Hellwig 2005-01-03 23:41 ` Felipe Alfaro Solana 2005-01-04 5:46 ` Willy Tarreau 2005-01-04 9:17 ` Bernd Petrovitsch 2005-01-04 13:27 ` Horst von Brand 3 siblings, 2 replies; 222+ messages in thread From: Christoph Hellwig @ 2005-01-03 22:14 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Rik van Riel, linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > want to keep using them. Changing a "stable" kernel will continuously > annoy users and vendors. So buy some Operating System that supports the propritary software of your choice but stop annoying us. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:14 ` Christoph Hellwig @ 2005-01-03 23:41 ` Felipe Alfaro Solana 2005-01-04 5:46 ` Willy Tarreau 1 sibling, 0 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-03 23:41 UTC (permalink / raw) To: Christoph Hellwig Cc: Adrian Bunk, Horst von Brand, linux-kernel, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 3 Jan 2005, at 23:14, Christoph Hellwig wrote: >> Gosh! I bought an ATI video card, I bought a VMware license, etc.... I >> want to keep using them. Changing a "stable" kernel will continuously >> annoy users and vendors. > > So buy some Operating System that supports the propritary software of > your choice but stop annoying us. I'm sorry if my comments annoy you. I thought this was an open list, open for discussion. I see I was wrong. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:14 ` Christoph Hellwig 2005-01-03 23:41 ` Felipe Alfaro Solana @ 2005-01-04 5:46 ` Willy Tarreau 2005-01-04 6:36 ` Al Viro 1 sibling, 1 reply; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 5:46 UTC (permalink / raw) To: Christoph Hellwig, Felipe Alfaro Solana, Rik van Riel, linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, Jan 03, 2005 at 10:14:42PM +0000, Christoph Hellwig wrote: > > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > > want to keep using them. Changing a "stable" kernel will continuously > > annoy users and vendors. > > So buy some Operating System that supports the propritary software of > your choice but stop annoying us. That's what he did. But it was not written in the notice that it could stop working at any time :-) Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:46 ` Willy Tarreau @ 2005-01-04 6:36 ` Al Viro 2005-01-04 10:23 ` Felipe Alfaro Solana 0 siblings, 1 reply; 222+ messages in thread From: Al Viro @ 2005-01-04 6:36 UTC (permalink / raw) To: Willy Tarreau Cc: Christoph Hellwig, Felipe Alfaro Solana, Rik van Riel, linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Tue, Jan 04, 2005 at 06:46:49AM +0100, Willy Tarreau wrote: > On Mon, Jan 03, 2005 at 10:14:42PM +0000, Christoph Hellwig wrote: > > > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > > > want to keep using them. Changing a "stable" kernel will continuously > > > annoy users and vendors. > > > > So buy some Operating System that supports the propritary software of > > your choice but stop annoying us. > > That's what he did. But it was not written in the notice that it could stop > working at any time :-) Do you want a long list of message-IDs going way, way back? Ones of Linus' postings saying that there never had been any promise whatsoever of in-kernel interfaces staying unchanged... For fsck sake, people, give it a rest already. 3rd-party kernel modules are and had always been responsibility of their maintainers, regardless of licensing, commercial status, etc. Exported functions and data structures can and do change; doing out-of-tree development means taking a calculated risk and being ready to follow these changes. So yes, it *had* been written. Many times. In details. With feeling. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 6:36 ` Al Viro @ 2005-01-04 10:23 ` Felipe Alfaro Solana 2005-01-04 12:36 ` Rik van Riel 2005-01-05 13:31 ` Helge Hafting 0 siblings, 2 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 10:23 UTC (permalink / raw) To: Al Viro Cc: Adrian Bunk, Willy Tarreau, William Lee Irwin III, Christoph Hellwig, linux-kernel, William Lee Irwin III, Andries Brouwer, Horst von Brand, Maciej Soltysiak, Rik van Riel On 4 Jan 2005, at 07:36, Al Viro wrote: > On Tue, Jan 04, 2005 at 06:46:49AM +0100, Willy Tarreau wrote: >> On Mon, Jan 03, 2005 at 10:14:42PM +0000, Christoph Hellwig wrote: >>>> Gosh! I bought an ATI video card, I bought a VMware license, >>>> etc.... I >>>> want to keep using them. Changing a "stable" kernel will >>>> continuously >>>> annoy users and vendors. >>> >>> So buy some Operating System that supports the propritary software of >>> your choice but stop annoying us. >> >> That's what he did. But it was not written in the notice that it >> could stop >> working at any time :-) > > Do you want a long list of message-IDs going way, way back? Ones of > Linus' > postings saying that there never had been any promise whatsoever of > in-kernel > interfaces staying unchanged... I don't pretend that kernel interfaces stay written in stone, for ages. What I would like is that, at least, those interfaces were stable enough, let's say for a few months for a stable kernel series, so I don't have to keep bothering my propietary VMWare vendor to fix the problems for me, since the new kernel interface broke VMWare. Yeah, I know I could decide not to upgrade kernels in last instance, but that's not always possible. If kernel interfaces need to be changed for whatever reason, change them in 2.7, -mm, -ac or whatever tree first, and let the community know beforehand what those changes will be, and be prepared to adapt. Meanwhile, try to leave 2.6 as stable as possible. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 10:23 ` Felipe Alfaro Solana @ 2005-01-04 12:36 ` Rik van Riel 2005-01-04 12:59 ` Felipe Alfaro Solana 2005-01-05 13:31 ` Helge Hafting 1 sibling, 1 reply; 222+ messages in thread From: Rik van Riel @ 2005-01-04 12:36 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Al Viro, Adrian Bunk, Willy Tarreau, William Lee Irwin III, Christoph Hellwig, linux-kernel, William Lee Irwin III, Andries Brouwer, Horst von Brand, Maciej Soltysiak On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > I don't pretend that kernel interfaces stay written in stone, for ages. What > I would like is that, at least, those interfaces were stable enough, let's > say for a few months for a stable kernel series, so I don't have to keep > bothering my propietary VMWare vendor to fix the problems for me, since the How much work are you willing to do to make this happen ? ;) It would be easy enough for you to take 2.6.9 and add only security fixes and critical bugfixes to it for the next 6 months - that would give your binary vendors a stable source base to work with... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 12:36 ` Rik van Riel @ 2005-01-04 12:59 ` Felipe Alfaro Solana 2005-01-04 20:09 ` Willy Tarreau 2005-01-04 20:24 ` Horst von Brand 0 siblings, 2 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 12:59 UTC (permalink / raw) To: Rik van Riel Cc: Adrian Bunk, Willy Tarreau, Al Viro, William Lee Irwin III, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak On 4 Jan 2005, at 13:36, Rik van Riel wrote: > On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > >> I don't pretend that kernel interfaces stay written in stone, for >> ages. What I would like is that, at least, those interfaces were >> stable enough, let's say for a few months for a stable kernel series, >> so I don't have to keep bothering my propietary VMWare vendor to fix >> the problems for me, since the > > How much work are you willing to do to make this happen ? ;) As much as needed :-) > It would be easy enough for you to take 2.6.9 and add only > security fixes and critical bugfixes to it for the next 6 > months - that would give your binary vendors a stable > source base to work with... I would... if it was easy enough to find some form of a security patches pool. It's usually difficult to find a site where I can download security patches for older versions of vanilla kernels. I have the feeling that this security fixes go mainstream onto the latest kernel versions, leaving users in hands of their distribution (either to upgrade to a new distribution kernel, or waiting for the distribution vendor to backport). Thus, sometimes people are forced to upgrade to a new kernel version as such security patches either don't exist for older kernel versions, are difficult to find, or need backporting (and I'm not knowledgeable enough to backport nearly half of them), and since the new kernel version introduces new features -- which sometimes do break existing propietary software -- users starts complaining. However, it's true that distributions, like Red Hat or Fedora, try at its best to keep the kernel as stable as possible. For example, FC3 seems to sport something like a 2.6.9 kernel, but sometimes those kernels are so heavily patched that some closed-source software doesn't work. I know I can choose open software and hardware vendors compatible with Linux, but sometimes I cannot. I like VMware, and I use it a lot. I'm not willing to sacrifice it, and that's the reason I think 2.6 must fork as soon as possible into 2.7. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 12:59 ` Felipe Alfaro Solana @ 2005-01-04 20:09 ` Willy Tarreau 2005-01-04 20:17 ` William Lee Irwin III ` (2 more replies) 2005-01-04 20:24 ` Horst von Brand 1 sibling, 3 replies; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 20:09 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Rik van Riel, Adrian Bunk, Al Viro, William Lee Irwin III, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak On Tue, Jan 04, 2005 at 01:59:51PM +0100, Felipe Alfaro Solana wrote: > >How much work are you willing to do to make this happen ? ;) > > As much as needed :-) It's harder than you think. If hundreds of developpers work on a version without thinking a second about separating security fixes and new features, you'll have a hard time extracting them all ! But generally (I said generally), security fixes are separated because noone knows from the start if a fix will be the best one, so they need to be able to revert it easily. More common problems involve changes to the core to support new features, or to satisfy some developper's own idea of what is good and what is bad. > >It would be easy enough for you to take 2.6.9 and add only > >security fixes and critical bugfixes to it for the next 6 > >months - that would give your binary vendors a stable > >source base to work with... > > I would... if it was easy enough to find some form of a security > patches pool. It's usually difficult to find a site where I can > download security patches for older versions of vanilla kernels. I have > the feeling that this security fixes go mainstream onto the latest > kernel versions, leaving users in hands of their distribution (either > to upgrade to a new distribution kernel, or waiting for the > distribution vendor to backport). Anyway, when you manage your own distribution, you have no other solution than reading lkml daily (better: continuously) to grab the required fixes and apply them to your local tree. If you feel that sometime you won't be able to do the backport, either you can ask on lkml, people are often willing to help, or you need to rely on other people's work (read distro kernels). > Thus, sometimes people are forced to upgrade to a new kernel version as > such security patches either don't exist for older kernel versions, are > difficult to find, or need backporting (and I'm not knowledgeable > enough to backport nearly half of them), and since the new kernel > version introduces new features -- which sometimes do break existing > propietary software -- users starts complaining. Not only proprietary software. I nearly don't use any (vmware a few times a year). Viro would tell you that the problem is on the editor's side. I have often been annoyed by opensource patches breakage. Try to use the same PaX patch for 4 months, for example, without getting rejects nor wrongly applied chunks ! Another problem is when code organisation changes. For example, in 2.4.29pre3, some xfs files have moved, which break the 2.4.28 vserver patch. Fixing it was not difficult, but it's just an example of things which could be avoided in a stable tree (and I'm sure that Christoph will flame me for saying this). > However, it's true that distributions, like Red Hat or Fedora, try at > its best to keep the kernel as stable as possible. For example, FC3 > seems to sport something like a 2.6.9 kernel, but sometimes those > kernels are so heavily patched that some closed-source software doesn't > work. Once again, my personal concern is about opensource code not being always possible to apply without lots of efforts. This problem is very old, it recently cost many efforts to several people to try to replace IDE code in 2.6. In general, it's diffcult to work aside of the kernel and follow it closely, whether you're opensource or not. > I know I can choose open software and hardware vendors compatible with > Linux, but sometimes I cannot. I like VMware, and I use it a lot. I'm > not willing to sacrifice it, and that's the reason I think 2.6 must > fork as soon as possible into 2.7. Well, it will be simpler when vmware authors will be fed up too and switch to another OS (I'm not talking about the one which you cannot use in console mode), you'll just have to follow them :-) Regards, Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:09 ` Willy Tarreau @ 2005-01-04 20:17 ` William Lee Irwin III 2005-01-05 6:20 ` Alexander E. Patrakov 2005-01-05 11:30 ` Christoph Hellwig 2 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 20:17 UTC (permalink / raw) To: Willy Tarreau Cc: Felipe Alfaro Solana, Rik van Riel, Adrian Bunk, Al Viro, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak On Tue, Jan 04, 2005 at 01:59:51PM +0100, Felipe Alfaro Solana wrote: >> I know I can choose open software and hardware vendors compatible with >> Linux, but sometimes I cannot. I like VMware, and I use it a lot. I'm >> not willing to sacrifice it, and that's the reason I think 2.6 must >> fork as soon as possible into 2.7. On Tue, Jan 04, 2005 at 09:09:12PM +0100, Willy Tarreau wrote: > Well, it will be simpler when vmware authors will be fed up too and switch > to another OS (I'm not talking about the one which you cannot use in console > mode), you'll just have to follow them :-) OpenSolaris defections already? heh -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:09 ` Willy Tarreau 2005-01-04 20:17 ` William Lee Irwin III @ 2005-01-05 6:20 ` Alexander E. Patrakov 2005-01-05 11:30 ` Christoph Hellwig 2 siblings, 0 replies; 222+ messages in thread From: Alexander E. Patrakov @ 2005-01-05 6:20 UTC (permalink / raw) To: linux-kernel Willy Tarreau wrote: > Anyway, when you manage your own distribution, you have no other solution > than reading lkml daily (better: continuously) to grab the required fixes > and apply them to your local tree. If you feel that sometime you won't be > able to do the backport, either you can ask on lkml, people are often > willing to help, or you need to rely on other people's work (read distro > kernels). I agree to rely on other people's work, but not _random_ distro kernels. The reason is that distros usually both fix bugs and test new features on their users. What's needed is an equivalent of linux-libc-headers: a vendor-neutral generally-accepted kernel usable as-is in most cases. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:09 ` Willy Tarreau 2005-01-04 20:17 ` William Lee Irwin III 2005-01-05 6:20 ` Alexander E. Patrakov @ 2005-01-05 11:30 ` Christoph Hellwig 2 siblings, 0 replies; 222+ messages in thread From: Christoph Hellwig @ 2005-01-05 11:30 UTC (permalink / raw) To: Willy Tarreau Cc: Felipe Alfaro Solana, Rik van Riel, Adrian Bunk, Al Viro, William Lee Irwin III, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak On Tue, Jan 04, 2005 at 09:09:12PM +0100, Willy Tarreau wrote: > Not only proprietary software. I nearly don't use any (vmware a few times a > year). Viro would tell you that the problem is on the editor's side. I have > often been annoyed by opensource patches breakage. Try to use the same PaX > patch for 4 months, for example, without getting rejects nor wrongly applied > chunks ! Note that even if we had a stable _driver_ interface PaX would certainly not fall under that. It pokes really deep into VM interals. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 12:59 ` Felipe Alfaro Solana 2005-01-04 20:09 ` Willy Tarreau @ 2005-01-04 20:24 ` Horst von Brand 1 sibling, 0 replies; 222+ messages in thread From: Horst von Brand @ 2005-01-04 20:24 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Rik van Riel, Adrian Bunk, Willy Tarreau, Al Viro, William Lee Irwin III, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak Felipe Alfaro Solana <lkml@mac.com> said: > On 4 Jan 2005, at 13:36, Rik van Riel wrote: > > On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > >> I don't pretend that kernel interfaces stay written in stone, for > >> ages. What I would like is that, at least, those interfaces were > >> stable enough, let's say for a few months for a stable kernel series, > >> so I don't have to keep bothering my propietary VMWare vendor to fix > >> the problems for me, since the > > > > How much work are you willing to do to make this happen ? ;) > > As much as needed :-) > > > It would be easy enough for you to take 2.6.9 and add only > > security fixes and critical bugfixes to it for the next 6 > > months - that would give your binary vendors a stable > > source base to work with... > > I would... if it was easy enough to find some form of a security > patches pool. The work Rik mentioned is exactly to select only security/critical fixes, and adapt them to the kernel you are handling. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 10:23 ` Felipe Alfaro Solana 2005-01-04 12:36 ` Rik van Riel @ 2005-01-05 13:31 ` Helge Hafting 2005-01-05 19:16 ` Bill Davidsen 2005-01-05 21:19 ` Felipe Alfaro Solana 1 sibling, 2 replies; 222+ messages in thread From: Helge Hafting @ 2005-01-05 13:31 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Al Viro, Adrian Bunk, Willy Tarreau, William Lee Irwin III, Christoph Hellwig, linux-kernel, William Lee Irwin III, Andries Brouwer, Horst von Brand, Maciej Soltysiak, Rik van Riel Felipe Alfaro Solana wrote: > > I don't pretend that kernel interfaces stay written in stone, for > ages. What I would like is that, at least, those interfaces were > stable enough, let's say for a few months for a stable kernel series, > so I don't have to keep bothering my propietary VMWare vendor to fix > the problems for me, since the new kernel interface broke VMWare. > Yeah, I know I could decide not to upgrade kernels in last instance, > but that's not always possible. You should definitely bother your proprietary vendor all the time, they will then see more clearly that they have to act fast _if_ they want to stay proprietary. > > If kernel interfaces need to be changed for whatever reason, change > them in 2.7, -mm, -ac or whatever tree first, and let the community > know beforehand what those changes will be, and be prepared to adapt. > Meanwhile, try to leave 2.6 as stable as possible. Do you follow -mm, -ac, and friends closely? Most changes do happen in -mm first. So you have time, all the way up to the next release. Use that time to bug your vendor about the imminent change. There seems to be weeks between releases now, plenty of time for a vendor to stay up-to-date. Helge Hafting ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 13:31 ` Helge Hafting @ 2005-01-05 19:16 ` Bill Davidsen 2005-01-05 21:19 ` Felipe Alfaro Solana 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-05 19:16 UTC (permalink / raw) To: Helge Hafting Cc: Felipe Alfaro Solana, Al Viro, Adrian Bunk, Willy Tarreau, William Lee Irwin III, Christoph Hellwig, linux-kernel, William Lee Irwin III, Andries Brouwer, Horst von Brand, Maciej Soltysiak, Rik van Riel Helge Hafting wrote: > Felipe Alfaro Solana wrote: > >> >> I don't pretend that kernel interfaces stay written in stone, for >> ages. What I would like is that, at least, those interfaces were >> stable enough, let's say for a few months for a stable kernel series, >> so I don't have to keep bothering my propietary VMWare vendor to fix >> the problems for me, since the new kernel interface broke VMWare. >> Yeah, I know I could decide not to upgrade kernels in last instance, >> but that's not always possible. > > > You should definitely bother your proprietary vendor all the time, they > will then > see more clearly that they have to act fast _if_ they want to stay > proprietary. > >> >> If kernel interfaces need to be changed for whatever reason, change >> them in 2.7, -mm, -ac or whatever tree first, and let the community >> know beforehand what those changes will be, and be prepared to adapt. >> Meanwhile, try to leave 2.6 as stable as possible. > > > Do you follow -mm, -ac, and friends closely? Most changes do happen in > -mm first. > So you have time, all the way up to the next release. Use that time to > bug your > vendor about the imminent change. There seems to be weeks between releases > now, plenty of time for a vendor to stay up-to-date. What "plenty of time?" There are changes between the last -bk and the next release in some cases, significant change within days of release. I can't imagine a vendor chasing -mm between releases, and I bet even Andrew couldn't say exactly what will or won't go into a release. He has goals, but the patches he gets may not be stable enough to include; he wants stability, but things may NEED to be changed in the case of a major bug or security issue. Some changes, like 4k stacks, can be seen coming, and changes for them don't prevent things from working the old way. Some have to be one thing or the other at the level of drivers and vmware, so they may not be available the instant a new release hits the spool. At least things like vmware *will* be fixed, I expect to run 2.4 on some machines indefinitely because the proprietary drivers stop there and I can't justify replacing the whole system just to get 2.6. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-05 13:31 ` Helge Hafting 2005-01-05 19:16 ` Bill Davidsen @ 2005-01-05 21:19 ` Felipe Alfaro Solana 1 sibling, 0 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-05 21:19 UTC (permalink / raw) To: Helge Hafting Cc: Adrian Bunk, Willy Tarreau, Al Viro, William Lee Irwin III, William Lee Irwin III, linux-kernel, Christoph Hellwig, Andries Brouwer, Horst von Brand, Maciej Soltysiak, Rik van Riel On 5 Jan 2005, at 14:31, Helge Hafting wrote: > Felipe Alfaro Solana wrote: > >> >> I don't pretend that kernel interfaces stay written in stone, for >> ages. What I would like is that, at least, those interfaces were >> stable enough, let's say for a few months for a stable kernel series, >> so I don't have to keep bothering my propietary VMWare vendor to fix >> the problems for me, since the new kernel interface broke VMWare. >> Yeah, I know I could decide not to upgrade kernels in last instance, >> but that's not always possible. > > You should definitely bother your proprietary vendor all the time, > they will then > see more clearly that they have to act fast _if_ they want to stay > proprietary. I do bother them, but they try at its best to fix things, and they do. They are propietary, and neither me nor anyone can force them to change their minds. >> If kernel interfaces need to be changed for whatever reason, change >> them in 2.7, -mm, -ac or whatever tree first, and let the community >> know beforehand what those changes will be, and be prepared to adapt. >> Meanwhile, try to leave 2.6 as stable as possible. > > Do you follow -mm, -ac, and friends closely? Most changes do happen > in -mm first. > So you have time, all the way up to the next release. Use that time > to bug your > vendor about the imminent change. There seems to be weeks between > releases > now, plenty of time for a vendor to stay up-to-date. I try to follow -mm releases closely, but as someone said, the ChangeLog is extremely dense for me to try to understand what's going on deeply. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:03 ` Felipe Alfaro Solana 2005-01-03 22:10 ` Rik van Riel 2005-01-03 22:14 ` Christoph Hellwig @ 2005-01-04 9:17 ` Bernd Petrovitsch 2005-01-04 13:27 ` Horst von Brand 3 siblings, 0 replies; 222+ messages in thread From: Bernd Petrovitsch @ 2005-01-04 9:17 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Rik van Riel, linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, 2005-01-03 at 23:03 +0100, Felipe Alfaro Solana wrote: [...] > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > want to keep using them. Changing a "stable" kernel will continuously > annoy users and vendors. Then avoid a "changing kernel" and do not upgrade. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 22:03 ` Felipe Alfaro Solana ` (2 preceding siblings ...) 2005-01-04 9:17 ` Bernd Petrovitsch @ 2005-01-04 13:27 ` Horst von Brand 2005-01-04 14:27 ` Felipe Alfaro Solana 3 siblings, 1 reply; 222+ messages in thread From: Horst von Brand @ 2005-01-04 13:27 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Rik van Riel, linux-kernel, Horst von Brand, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III Felipe Alfaro Solana <lkml@mac.com> said: [...] > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > want to keep using them. Changing a "stable" kernel will continuously > annoy users and vendors. If you are sooo attached to this, just keep a distribution for which vendors give you drivers. But when the vendor decides the product has to die to get you to buy the next "completely redone" (== minor fixes and updates) version, you are stranded for good. > I think new developments will force a 2.7 branch: when 2.6 feature set > stabilizes, people will keep more time testing a stable, relatively > static kernel base, finding bugs, instead of trying to keep up with > changes. And when 2.7 opens, very few developers will tend 2.6; and as 2.7 diverges from it, fewer and fewer fixes will find their way back. And so you finally get a rock-stable (== unchanging) 2.6, but hopelessly out of date and thus unfixable (if nothing else because there are no people around who remember how it worked). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 13:27 ` Horst von Brand @ 2005-01-04 14:27 ` Felipe Alfaro Solana 2005-01-04 15:31 ` Rik van Riel ` (2 more replies) 0 siblings, 3 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 14:27 UTC (permalink / raw) To: Horst von Brand Cc: linux-kernel, Adrian Bunk, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 4 Jan 2005, at 14:27, Horst von Brand wrote: > Felipe Alfaro Solana <lkml@mac.com> said: > > [...] > >> Gosh! I bought an ATI video card, I bought a VMware license, etc.... I >> want to keep using them. Changing a "stable" kernel will continuously >> annoy users and vendors. > > If you are sooo attached to this, just keep a distribution for which > vendors give you drivers. But when the vendor decides the product has > to > die to get you to buy the next "completely redone" (== minor fixes and > updates) version, you are stranded for good. > >> I think new developments will force a 2.7 branch: when 2.6 feature set >> stabilizes, people will keep more time testing a stable, relatively >> static kernel base, finding bugs, instead of trying to keep up with >> changes. > > And when 2.7 opens, very few developers will tend 2.6; and as 2.7 > diverges > from it, fewer and fewer fixes will find their way back. And so you > finally > get a rock-stable (== unchanging) 2.6, but hopelessly out of date and > thus > unfixable (if nothing else because there are no people around who > remember > how it worked). I can see no easy solution for this... If Linus decides to fork off 2.7, development efforts will go into 2.7 and fixes should get backported to 2.6. If Linus decides to stay with 2.6, new development will have to be "conservative" enough not to break things that were working. I tend to prefer forking off 2.7: more agressive features can be implemented and tested without bothering disrupting the stable 2.6 branch. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 14:27 ` Felipe Alfaro Solana @ 2005-01-04 15:31 ` Rik van Riel 2005-01-04 16:51 ` Felipe Alfaro Solana 2005-01-04 20:58 ` Horst von Brand 2005-01-04 22:04 ` Alan Cox 2 siblings, 1 reply; 222+ messages in thread From: Rik van Riel @ 2005-01-04 15:31 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, linux-kernel, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > I tend to prefer forking off 2.7: Nobody's stopping you from forking off 2.7, but please don't try telling Linus and Andrew how to do their job ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 15:31 ` Rik van Riel @ 2005-01-04 16:51 ` Felipe Alfaro Solana 0 siblings, 0 replies; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 16:51 UTC (permalink / raw) To: Rik van Riel Cc: Adrian Bunk, Horst von Brand, linux-kernel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 4 Jan 2005, at 16:31, Rik van Riel wrote: > On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > >> I tend to prefer forking off 2.7: > > Nobody's stopping you from forking off 2.7, but please don't > try telling Linus and Andrew how to do their job ;) Wouldn't even try :-) ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 14:27 ` Felipe Alfaro Solana 2005-01-04 15:31 ` Rik van Riel @ 2005-01-04 20:58 ` Horst von Brand 2005-01-04 23:07 ` Felipe Alfaro Solana 2005-01-04 22:04 ` Alan Cox 2 siblings, 1 reply; 222+ messages in thread From: Horst von Brand @ 2005-01-04 20:58 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, linux-kernel, Adrian Bunk, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III Felipe Alfaro Solana <lkml@mac.com> said: > On 4 Jan 2005, at 14:27, Horst von Brand wrote: > > Felipe Alfaro Solana <lkml@mac.com> said: [...] > >> I think new developments will force a 2.7 branch: when 2.6 feature set > >> stabilizes, people will keep more time testing a stable, relatively > >> static kernel base, finding bugs, instead of trying to keep up with > >> changes. > > And when 2.7 opens, very few developers will tend 2.6; and as 2.7 > > diverges from it, fewer and fewer fixes will find their way back. And > > so you finally get a rock-stable (== unchanging) 2.6, but hopelessly > > out of date and thus unfixable (if nothing else because there are no > > people around who remember how it worked). > I can see no easy solution for this... If Linus decides to fork off > 2.7, development efforts will go into 2.7 and fixes should get > backported to 2.6. If Linus decides to stay with 2.6, new development > will have to be "conservative" enough not to break things that were > working. Exactly. > I tend to prefer forking off 2.7: more agressive features can be > implemented and tested without bothering disrupting the stable 2.6 > branch. Have any particular features in mind? If you have some, you can fork off your own BK repository and play there (wait... that is how (currently) out-of-tree drivers are developed!). Or you could start an unofficial experimental fork. If none of the above, I guess you'd just have to wait until Our Fearless Leader decides it is time for 2.7. Just forcing a 2.7 "because that'll stabilize 2.6" is nonsense. Because then 2.6 won't stabilize any faster (probably slower). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:58 ` Horst von Brand @ 2005-01-04 23:07 ` Felipe Alfaro Solana 2005-01-04 23:18 ` Rik van Riel 0 siblings, 1 reply; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 23:07 UTC (permalink / raw) To: Horst von Brand Cc: linux-kernel, Adrian Bunk, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On 4 Jan 2005, at 21:58, Horst von Brand wrote: > Felipe Alfaro Solana <lkml@mac.com> said: >> On 4 Jan 2005, at 14:27, Horst von Brand wrote: >>> Felipe Alfaro Solana <lkml@mac.com> said: > > [...] > >>>> I think new developments will force a 2.7 branch: when 2.6 feature >>>> set >>>> stabilizes, people will keep more time testing a stable, relatively >>>> static kernel base, finding bugs, instead of trying to keep up with >>>> changes. > >>> And when 2.7 opens, very few developers will tend 2.6; and as 2.7 >>> diverges from it, fewer and fewer fixes will find their way back. And >>> so you finally get a rock-stable (== unchanging) 2.6, but hopelessly >>> out of date and thus unfixable (if nothing else because there are no >>> people around who remember how it worked). > >> I can see no easy solution for this... If Linus decides to fork off >> 2.7, development efforts will go into 2.7 and fixes should get >> backported to 2.6. If Linus decides to stay with 2.6, new development >> will have to be "conservative" enough not to break things that were >> working. > > Exactly. > >> I tend to prefer forking off 2.7: more agressive features can be >> implemented and tested without bothering disrupting the stable 2.6 >> branch. > > Have any particular features in mind? If you have some, you can fork > off > your own BK repository and play there (wait... that is how (currently) > out-of-tree drivers are developed!). Or you could start an unofficial > experimental fork. If none of the above, I guess you'd just have to > wait > until Our Fearless Leader decides it is time for 2.7. > > Just forcing a 2.7 "because that'll stabilize 2.6" is nonsense. Because > then 2.6 won't stabilize any faster (probably slower). Stabilizing, for me at least, means fixing bugs, not adding new features (unless those new features are totally necessary). Thus, I don't see how freezing the 2.6 codebase, waiting some time for bugs to get fixed and things to settle down, then forking off 2.7 could be a non-sense. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 23:07 ` Felipe Alfaro Solana @ 2005-01-04 23:18 ` Rik van Riel 0 siblings, 0 replies; 222+ messages in thread From: Rik van Riel @ 2005-01-04 23:18 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, linux-kernel, Adrian Bunk, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Wed, 5 Jan 2005, Felipe Alfaro Solana wrote: > Stabilizing, for me at least, means fixing bugs, not adding new features > (unless those new features are totally necessary). The definition of "totally necessary" is going to vary from user to user. For some people, the ability to use AGP on a system with more than 4GB RAM is necessary, leading to the recent API change. > Thus, I don't see how freezing the 2.6 codebase, waiting some time for > bugs to get fixed and things to settle down, then forking off 2.7 could > be a non-sense. Hey, that's what we do between 2.6.N and 2.6.(N+1) ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 14:27 ` Felipe Alfaro Solana 2005-01-04 15:31 ` Rik van Riel 2005-01-04 20:58 ` Horst von Brand @ 2005-01-04 22:04 ` Alan Cox 2 siblings, 0 replies; 222+ messages in thread From: Alan Cox @ 2005-01-04 22:04 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, Linux Kernel Mailing List, Adrian Bunk, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Maw, 2005-01-04 at 14:27, Felipe Alfaro Solana wrote: > >> Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > >> want to keep using them. Changing a "stable" kernel will continuously > >> annoy users and vendors. I downloaded the DRI drivers (test R300 code in CVS), qemu and Xen 8) > I can see no easy solution for this... If Linus decides to fork off > 2.7, development efforts will go into 2.7 and fixes should get > backported to 2.6. If Linus decides to stay with 2.6, new development > will have to be "conservative" enough not to break things that were > working. Its relatively easy to fix in kernel drivers for API changes during a release cycle and it helps enormously being able to do so. remap_page_range was rapidly fixed and very soon can vanish forever from the tree. Alan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 21:47 ` Felipe Alfaro Solana 2005-01-03 21:48 ` Rik van Riel @ 2005-01-03 22:01 ` Sean 1 sibling, 0 replies; 222+ messages in thread From: Sean @ 2005-01-03 22:01 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: Horst von Brand, Adrian Bunk, linux-kernel, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, January 3, 2005 4:47 pm, Felipe Alfaro Solana said: > On 3 Jan 2005, at 21:59, Horst von Brand wrote: > >> Felipe Alfaro Solana <lkml@mac.com> said: >> >> [...] >> >>> I would like to comment in that the issue is not exclusively targeted >>> to stability, but the ability to keep up with kernel development. For >>> example, it was pretty common for older versions of VMWare and NVidia >>> driver to break up whenever a new kernel version was released. >> >> That is the price for closed-source drivers. >> >>> I think it's a PITA for developers to rework some of the closed-source >>> code to adopt the new changes in the Linux kernel. >> >> Open up the code. Most of the changes will then be done as a matter of >> course by others. > > Unfortunately, you can't force the entire hardware industry to open up > their drivers. > The point is, they'll have to deal with the burrden of any extra work created as a result. It's not the responsibility of the open source developers. Smart users pick hardware that is well supported by Linux and doesn't run the risk of becoming obsolete the day the manufacturer decides they don't want to provide drivers any longer. Sean ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 20:59 ` Horst von Brand 2005-01-03 21:47 ` Felipe Alfaro Solana @ 2005-01-04 5:44 ` Willy Tarreau 2005-01-04 13:11 ` William Lee Irwin III 1 sibling, 1 reply; 222+ messages in thread From: Willy Tarreau @ 2005-01-04 5:44 UTC (permalink / raw) To: Horst von Brand Cc: Felipe Alfaro Solana, William Lee Irwin III, Adrian Bunk, linux-kernel, Rik van Riel, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, Jan 03, 2005 at 05:59:24PM -0300, Horst von Brand wrote: > Felipe Alfaro Solana <lkml@mac.com> said: > > [...] > > > I would like to comment in that the issue is not exclusively targeted > > to stability, but the ability to keep up with kernel development. For > > example, it was pretty common for older versions of VMWare and NVidia > > driver to break up whenever a new kernel version was released. > > That is the price for closed-source drivers. > > > I think it's a PITA for developers to rework some of the closed-source > > code to adopt the new changes in the Linux kernel. > > Open up the code. Most of the changes will then be done as a matter of > course by others. it will not solve the problem : if a driver or any glue logic breaks, it's because interface has changed again. When you will have 3000 open drivers, you'll have to find people to make the changes every week. The solution in the first place is to respect some code stability and not to break thinks every week. Willy ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 5:44 ` Willy Tarreau @ 2005-01-04 13:11 ` William Lee Irwin III 0 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 13:11 UTC (permalink / raw) To: Willy Tarreau Cc: Horst von Brand, Felipe Alfaro Solana, Adrian Bunk, linux-kernel, Rik van Riel, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III On Mon, Jan 03, 2005 at 05:59:24PM -0300, Horst von Brand wrote: >> Open up the code. Most of the changes will then be done as a matter of >> course by others. On Tue, Jan 04, 2005 at 06:44:58AM +0100, Willy Tarreau wrote: > it will not solve the problem : if a driver or any glue logic breaks, it's > because interface has changed again. When you will have 3000 open drivers, > you'll have to find people to make the changes every week. The solution in > the first place is to respect some code stability and not to break thinks > every week. Tihs is not entirely true. I'd like to point to remap_pfn_range() as a smoothly-executed API change. All in-tree drivers were swept. Out-of- tree open-source drivers got by with nothing more than warnings. Even binary-only drivers had no trouble with mere recompiles of glue layers. Many other API changes are also executed with similar smoothness. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 17:39 ` Felipe Alfaro Solana 2005-01-03 20:59 ` Horst von Brand @ 2005-01-03 23:21 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 23:21 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: William Lee Irwin III, Adrian Bunk, linux-kernel, Rik van Riel, Maciej Soltysiak, Andries Brouwer, William Lee Irwin III Felipe Alfaro Solana wrote: > On 3 Jan 2005, at 16:37, William Lee Irwin III wrote: > >> On Mon, Jan 03, 2005 at 10:20:40AM -0500, Rik van Riel wrote: >> >>>> 2.2 before 2.2.20 also had this kind of problem, as did >>>> the 2.4 kernel before 2.4.20 or thereabouts. >>>> I'm pretty sure 2.6 is actually doing better than the >>>> early 2.0, 2.2 and 2.4 kernels... >> >> >> On Mon, Jan 03, 2005 at 04:29:53PM +0100, Adrian Bunk wrote: >> >>> My personal impression was that even the 2.6.0-test kernels were much >>> better than the 2.4.0-test kernels. >>> But 2.6.20 will most likely still have the stability of the early >>> 2.6 kernels instead of a greatly increased stability as observed in >>> 2.2.20 and 2.4.20 . >> >> >> This is speculation; there is no reason not to expect the process to >> converge to as great of stability or greater stability than the >> 2.4-style process. I specuate that it will in fact do precisely that. > > > I would like to comment in that the issue is not exclusively targeted to > stability, but the ability to keep up with kernel development. For > example, it was pretty common for older versions of VMWare and NVidia > driver to break up whenever a new kernel version was released. > > I think it's a PITA for developers to rework some of the closed-source > code to adopt the new changes in the Linux kernel. Different can, different worms... there are a number of developers who dislike closed source drivers and software and make no effort to avoid breaking them. I'm happy to see a vendor care enough about Linux to have the driver, there are legal reasons why some source isn't open. You can't always fund using politically correct hardware. To paraphrase, "we don't always compute with the hardware we'd LIKE to have, we have to compute with the hardware we DO have." -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:29 ` Adrian Bunk 2005-01-03 15:37 ` William Lee Irwin III @ 2005-01-03 18:18 ` Wakko Warner 1 sibling, 0 replies; 222+ messages in thread From: Wakko Warner @ 2005-01-03 18:18 UTC (permalink / raw) To: Adrian Bunk; +Cc: linux-kernel Adrian Bunk wrote: > > My personal impression was that even the 2.6.0-test kernels were much > better than the 2.4.0-test kernels. > > But 2.6.20 will most likely still have the stability of the early > 2.6 kernels instead of a greatly increased stability as observed in > 2.2.20 and 2.4.20 . In my experiences, 2.6.8 and above have been quite unstable for me. I was able to crash 2.6.8.1 as a normal user over nfs (I thought that was fixed?) 2.6.9 gave me problems with USB and random lockups. 2.6.7 has been fairly stable for me, but I honestly do not see 2.6 as a stable kernel. From my past experiences, 2.4.x (low numbered) was just as stable as 2.6 has been or more so. -- Lab tests show that use of micro$oft causes cancer in lab animals ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:20 ` Rik van Riel 2005-01-03 15:29 ` Adrian Bunk @ 2005-01-03 23:06 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 23:06 UTC (permalink / raw) To: Rik van Riel Cc: Adrian Bunk, William Lee Irwin III, Andries Brouwer, Maciej Soltysiak, linux-kernel Rik van Riel wrote: > On Sun, 2 Jan 2005, Adrian Bunk wrote: > >> The main advantage with stable kernels in the good old days (tm) when 4 > > >> Nowadays in 2.6, every new 2.6 kernel has several regressions compared >> to the previous one, and additionally obsolete but used code like > > > 2.2 before 2.2.20 also had this kind of problem, as did > the 2.4 kernel before 2.4.20 or thereabouts. > > I'm pretty sure 2.6 is actually doing better than the > early 2.0, 2.2 and 2.4 kernels... > 2.6 is doing better in terms of staying up, not eating my files, etc. I'm less sure about the things being 'changed' (by design) vs. 'broken' (by unintended bug introduction). My sense is that there are people who want to remove features which are not broken nor causing huge overhead or developer effort. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 21:24 ` Andries Brouwer 2005-01-02 21:42 ` William Lee Irwin III @ 2005-01-03 15:18 ` Rik van Riel 2005-01-03 15:34 ` Adrian Bunk ` (2 more replies) 1 sibling, 3 replies; 222+ messages in thread From: Rik van Riel @ 2005-01-03 15:18 UTC (permalink / raw) To: Andries Brouwer; +Cc: William Lee Irwin III, Maciej Soltysiak, linux-kernel On Sun, 2 Jan 2005, Andries Brouwer wrote: > You change some stuff. The bad mistakes are discovered very soon. > Some subtler things or some things that occur only in special > configurations or under special conditions or just with > very low probability may not be noticed until much later. Some of these subtle bugs are only discovered a year after the distribution with some particular kernel has been deployed - at which point the kernel has moved on so far that the fix the distro does might no longer apply (even in concept) to the upstream kernel... This is especially true when you are talking about really big database servers and bugs that take weeks or months to trigger. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:18 ` Rik van Riel @ 2005-01-03 15:34 ` Adrian Bunk 2005-01-03 15:46 ` William Lee Irwin III 2005-01-03 15:59 ` Arjan van de Ven 2005-01-03 22:53 ` Bill Davidsen 2005-01-06 3:52 ` Ian Kent 2 siblings, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-03 15:34 UTC (permalink / raw) To: Rik van Riel Cc: Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: > On Sun, 2 Jan 2005, Andries Brouwer wrote: > > >You change some stuff. The bad mistakes are discovered very soon. > >Some subtler things or some things that occur only in special > >configurations or under special conditions or just with > >very low probability may not be noticed until much later. > > Some of these subtle bugs are only discovered a year > after the distribution with some particular kernel has > been deployed - at which point the kernel has moved on > so far that the fix the distro does might no longer > apply (even in concept) to the upstream kernel... > > This is especially true when you are talking about really > big database servers and bugs that take weeks or months > to trigger. If at this time 2.8 was already released, the 2.8 kernel available at this time will be roughly what 2.6 would have been under the current development model, and 2.6 will be a rock stable kernel. If it was possible to get the 2.7 cycle pretty short, this would give the advantages of the old development model without most of its' disadvantages. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:34 ` Adrian Bunk @ 2005-01-03 15:46 ` William Lee Irwin III 2005-01-03 15:59 ` Arjan van de Ven 1 sibling, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-03 15:46 UTC (permalink / raw) To: Adrian Bunk; +Cc: Rik van Riel, Andries Brouwer, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: >> This is especially true when you are talking about really >> big database servers and bugs that take weeks or months >> to trigger. On Mon, Jan 03, 2005 at 04:34:38PM +0100, Adrian Bunk wrote: > If at this time 2.8 was already released, the 2.8 kernel available at > this time will be roughly what 2.6 would have been under the current > development model, and 2.6 will be a rock stable kernel. > If it was possible to get the 2.7 cycle pretty short, this would give > the advantages of the old development model without most of its' > disadvantages. But that cannot be. Splitting the developer base is guaranteed to reduce the amount of critical examination and testing given to both series of kernel versions. Also, .com's have finite horizons and slow response times; dev kernels are almost universally beyond them. A dedicated dev kernel with a short development cycle guarantees that the entire corporate side will be left out of the development cycle. And this is not speculation; even the long dev cycles do similar, or are only given attention after their huge freezes. If they're always too late for a slow-moving dev cycle a fast-moving dev cycle is guaranteed to outrun them completely. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:34 ` Adrian Bunk 2005-01-03 15:46 ` William Lee Irwin III @ 2005-01-03 15:59 ` Arjan van de Ven 2005-01-03 23:34 ` Bill Davidsen 2005-01-04 17:47 ` Adrian Bunk 1 sibling, 2 replies; 222+ messages in thread From: Arjan van de Ven @ 2005-01-03 15:59 UTC (permalink / raw) To: Adrian Bunk Cc: Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Mon, 2005-01-03 at 16:34 +0100, Adrian Bunk wrote: > On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: > > On Sun, 2 Jan 2005, Andries Brouwer wrote: > > > > >You change some stuff. The bad mistakes are discovered very soon. > > >Some subtler things or some things that occur only in special > > >configurations or under special conditions or just with > > >very low probability may not be noticed until much later. > > > > Some of these subtle bugs are only discovered a year > > after the distribution with some particular kernel has > > been deployed - at which point the kernel has moved on > > so far that the fix the distro does might no longer > > apply (even in concept) to the upstream kernel... > > > > This is especially true when you are talking about really > > big database servers and bugs that take weeks or months > > to trigger. > > If at this time 2.8 was already released, the 2.8 kernel available at > this time will be roughly what 2.6 would have been under the current > development model, and 2.6 will be a rock stable kernel. as long as more things get fixed than new bugs introduced (and that still seems to be the case) things only improve in 2.6. The joint approach also has major advantages, even for quality: All testing happens on the same codebase. Previously, the testing focus was split between the stable and unstable branch, to the detriment of *both*. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:59 ` Arjan van de Ven @ 2005-01-03 23:34 ` Bill Davidsen 2005-01-04 7:42 ` Arjan van de Ven 2005-01-04 17:47 ` Adrian Bunk 1 sibling, 1 reply; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 23:34 UTC (permalink / raw) To: Arjan van de Ven Cc: Adrian Bunk, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel Arjan van de Ven wrote: > On Mon, 2005-01-03 at 16:34 +0100, Adrian Bunk wrote: > >>On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: >> >>>On Sun, 2 Jan 2005, Andries Brouwer wrote: >>> >>> >>>>You change some stuff. The bad mistakes are discovered very soon. >>>>Some subtler things or some things that occur only in special >>>>configurations or under special conditions or just with >>>>very low probability may not be noticed until much later. >>> >>>Some of these subtle bugs are only discovered a year >>>after the distribution with some particular kernel has >>>been deployed - at which point the kernel has moved on >>>so far that the fix the distro does might no longer >>>apply (even in concept) to the upstream kernel... >>> >>>This is especially true when you are talking about really >>>big database servers and bugs that take weeks or months >>>to trigger. >> >>If at this time 2.8 was already released, the 2.8 kernel available at >>this time will be roughly what 2.6 would have been under the current >>development model, and 2.6 will be a rock stable kernel. > > > > as long as more things get fixed than new bugs introduced (and that > still seems to be the case) things only improve in 2.6. > > The joint approach also has major advantages, even for quality: > All testing happens on the same codebase. > Previously, the testing focus was split between the stable and unstable > branch, to the detriment of *both*. You think so? I think the number of people testing the 2.4.xx-rc versions AND the 2.6.xx-bkN versions is a small (nonzero) percentage of total people trying any new release. I think people test what they plan to use, so there's less competition for testers than you suggest. People staying with 2.4 test that, people wanting or needing to move forward test 2.6. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 23:34 ` Bill Davidsen @ 2005-01-04 7:42 ` Arjan van de Ven 2005-01-04 13:14 ` William Lee Irwin III 0 siblings, 1 reply; 222+ messages in thread From: Arjan van de Ven @ 2005-01-04 7:42 UTC (permalink / raw) To: Bill Davidsen Cc: Adrian Bunk, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel > > as long as more things get fixed than new bugs introduced (and that > > still seems to be the case) things only improve in 2.6. > > > > The joint approach also has major advantages, even for quality: > > All testing happens on the same codebase. > > Previously, the testing focus was split between the stable and unstable > > branch, to the detriment of *both*. > > You think so? I think the number of people testing the 2.4.xx-rc > versions AND the 2.6.xx-bkN versions is a small (nonzero) percentage of > total people trying any new release. I think people test what they plan > to use, so there's less competition for testers than you suggest. People > staying with 2.4 test that, people wanting or needing to move forward > test 2.6. > Actually I suspect the number of people testing 2.4.xx-rc is *really* small now. My point however was more towards a 2.6 / 2.7 split, where the people who want to test newest do 2.7 while people who want to test stable test 2.6; right now those two groups test basically the same codebase. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 7:42 ` Arjan van de Ven @ 2005-01-04 13:14 ` William Lee Irwin III 0 siblings, 0 replies; 222+ messages in thread From: William Lee Irwin III @ 2005-01-04 13:14 UTC (permalink / raw) To: Arjan van de Ven Cc: Bill Davidsen, Adrian Bunk, Rik van Riel, Andries Brouwer, Maciej Soltysiak, linux-kernel At some point in the past, someone wrote: >>> The joint approach also has major advantages, even for quality: >>> All testing happens on the same codebase. >>> Previously, the testing focus was split between the stable and unstable >>> branch, to the detriment of *both*. At some point in the past, someone else wrote: >> You think so? I think the number of people testing the 2.4.xx-rc >> versions AND the 2.6.xx-bkN versions is a small (nonzero) percentage of >> total people trying any new release. I think people test what they plan >> to use, so there's less competition for testers than you suggest. People >> staying with 2.4 test that, people wanting or needing to move forward >> test 2.6. On Tue, Jan 04, 2005 at 08:42:36AM +0100, Arjan van de Ven wrote: > Actually I suspect the number of people testing 2.4.xx-rc is *really* > small now. My point however was more towards a 2.6 / 2.7 split, where > the people who want to test newest do 2.7 while people who want to test > stable test 2.6; right now those two groups test basically the same > codebase. But this is a good thing; new code should meet the prior standards of stability and correctness as should the tree at all times. Efforts to recover it once it is lost to a large degree are doomed. -- wli ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:59 ` Arjan van de Ven 2005-01-03 23:34 ` Bill Davidsen @ 2005-01-04 17:47 ` Adrian Bunk 2005-01-04 20:18 ` David Lang 1 sibling, 1 reply; 222+ messages in thread From: Adrian Bunk @ 2005-01-04 17:47 UTC (permalink / raw) To: Arjan van de Ven Cc: Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Mon, Jan 03, 2005 at 04:59:02PM +0100, Arjan van de Ven wrote: > On Mon, 2005-01-03 at 16:34 +0100, Adrian Bunk wrote: > > On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: > > > On Sun, 2 Jan 2005, Andries Brouwer wrote: > > > > > > >You change some stuff. The bad mistakes are discovered very soon. > > > >Some subtler things or some things that occur only in special > > > >configurations or under special conditions or just with > > > >very low probability may not be noticed until much later. > > > > > > Some of these subtle bugs are only discovered a year > > > after the distribution with some particular kernel has > > > been deployed - at which point the kernel has moved on > > > so far that the fix the distro does might no longer > > > apply (even in concept) to the upstream kernel... > > > > > > This is especially true when you are talking about really > > > big database servers and bugs that take weeks or months > > > to trigger. > > > > If at this time 2.8 was already released, the 2.8 kernel available at > > this time will be roughly what 2.6 would have been under the current > > development model, and 2.6 will be a rock stable kernel. > > as long as more things get fixed than new bugs introduced (and that > still seems to be the case) things only improve in 2.6. >... My main point is not the number of bugs, but the number of regressions. If you do install a new machine or do a major upgrade (e.g. 2.4 -> 2.6) you do some testing whether everything works as expected and if something doesn't work, you try to get it working or work around the problem. Inside a stable kernel series (e.g. 2.6.x -> 2.6.y) you hope that an upgrade doesn't contain regressions and goes smoothly. Even the introduction of CONFIG_BLK_DEV_UB in 2.6.9 [1] has bitten several people I know. cu Adrian [1] this is not technically a bug, but e.g. similar common problems for users in the input code were already fixed during 2.5 long before 2.6.0 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 17:47 ` Adrian Bunk @ 2005-01-04 20:18 ` David Lang 2005-01-04 23:03 ` Felipe Alfaro Solana 2005-01-06 19:35 ` Adrian Bunk 0 siblings, 2 replies; 222+ messages in thread From: David Lang @ 2005-01-04 20:18 UTC (permalink / raw) To: Adrian Bunk Cc: Arjan van de Ven, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel Sorry, I've been useing kernel.org kernels since the 2.0 days and even within a stable series I always do a full set of tests before upgrading. every single stable series has had 'paper bag' releases, and every single one has had fixes to drivers that have ended up breaking those drivers. the only way to know if a new kernel will work on your hardware is to try it. It doesn't matter if the upgrade is from 2.4.24 to 2.4.25 or 2.6.9 to 2.6.10 or even 2.4.24 to 2.6.10 anyone who assumes that just becouse the kernel is in the stable series they can blindly upgrade their production systems is just dreaming. David Lang On Tue, 4 Jan 2005, Adrian Bunk wrote: > Date: Tue, 4 Jan 2005 18:47:13 +0100 > From: Adrian Bunk <bunk@stusta.de> > To: Arjan van de Ven <arjan@infradead.org> > Cc: Rik van Riel <riel@redhat.com>, Andries Brouwer <aebr@win.tue.nl>, > William Lee Irwin III <wli@holomorphy.com>, > Maciej Soltysiak <solt2@dns.toxicfilms.tv>, linux-kernel@vger.kernel.org > Subject: Re: starting with 2.7 > > On Mon, Jan 03, 2005 at 04:59:02PM +0100, Arjan van de Ven wrote: >> On Mon, 2005-01-03 at 16:34 +0100, Adrian Bunk wrote: >>> On Mon, Jan 03, 2005 at 10:18:47AM -0500, Rik van Riel wrote: >>>> On Sun, 2 Jan 2005, Andries Brouwer wrote: >>>> >>>>> You change some stuff. The bad mistakes are discovered very soon. >>>>> Some subtler things or some things that occur only in special >>>>> configurations or under special conditions or just with >>>>> very low probability may not be noticed until much later. >>>> >>>> Some of these subtle bugs are only discovered a year >>>> after the distribution with some particular kernel has >>>> been deployed - at which point the kernel has moved on >>>> so far that the fix the distro does might no longer >>>> apply (even in concept) to the upstream kernel... >>>> >>>> This is especially true when you are talking about really >>>> big database servers and bugs that take weeks or months >>>> to trigger. >>> >>> If at this time 2.8 was already released, the 2.8 kernel available at >>> this time will be roughly what 2.6 would have been under the current >>> development model, and 2.6 will be a rock stable kernel. >> >> as long as more things get fixed than new bugs introduced (and that >> still seems to be the case) things only improve in 2.6. >> ... > > My main point is not the number of bugs, but the number of regressions. > > If you do install a new machine or do a major upgrade (e.g. 2.4 -> 2.6) > you do some testing whether everything works as expected and if > something doesn't work, you try to get it working or work around the > problem. > > Inside a stable kernel series (e.g. 2.6.x -> 2.6.y) you hope that an > upgrade doesn't contain regressions and goes smoothly. > > Even the introduction of CONFIG_BLK_DEV_UB in 2.6.9 [1] has bitten > several people I know. > > cu > Adrian > > [1] this is not technically a bug, but e.g. similar common problems > for users in the input code were already fixed during 2.5 long > before 2.6.0 > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:18 ` David Lang @ 2005-01-04 23:03 ` Felipe Alfaro Solana 2005-01-05 7:39 ` Arjan van de Ven 2005-01-06 19:35 ` Adrian Bunk 1 sibling, 1 reply; 222+ messages in thread From: Felipe Alfaro Solana @ 2005-01-04 23:03 UTC (permalink / raw) To: David Lang Cc: Adrian Bunk, Arjan van de Ven, linux-kernel, Rik van Riel, William Lee Irwin III, Maciej Soltysiak, Andries Brouwer On 4 Jan 2005, at 21:18, David Lang wrote: > Sorry, I've been useing kernel.org kernels since the 2.0 days and even > within a stable series I always do a full set of tests before > upgrading. every single stable series has had 'paper bag' releases, > and every single one has had fixes to drivers that have ended up > breaking those drivers. > > the only way to know if a new kernel will work on your hardware is to > try it. It doesn't matter if the upgrade is from 2.4.24 to 2.4.25 or > 2.6.9 to 2.6.10 or even 2.4.24 to 2.6.10 > > anyone who assumes that just becouse the kernel is in the stable > series they can blindly upgrade their production systems is just > dreaming. It's not a problem of blindly upgrading, but a problem of knowing that most of the kernel interfaces do remain stable to reduce the number of possible problems. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 23:03 ` Felipe Alfaro Solana @ 2005-01-05 7:39 ` Arjan van de Ven 0 siblings, 0 replies; 222+ messages in thread From: Arjan van de Ven @ 2005-01-05 7:39 UTC (permalink / raw) To: Felipe Alfaro Solana; +Cc: linux-kernel On Wed, 2002.6.10 or even 2.4.24 to 2.6.10 > > > > anyone who assumes that just becouse the kernel is in the stable > > series they can blindly upgrade their production systems is just > > dreaming. > r > It's not a problem of blindly upgrading, but a problem of knowing that > most of the kernel interfaces do remain stable to reduce the number of > possible problems. kernel interfaces have nothing to do with this. kernel interfaces have zero relationship with stability of the software although I do appreciate that you get in trouble if you need to link (in my opinion) license violating kernel modules into your kernel. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-04 20:18 ` David Lang 2005-01-04 23:03 ` Felipe Alfaro Solana @ 2005-01-06 19:35 ` Adrian Bunk 2005-01-06 23:33 ` Daniel Gryniewicz 2005-01-07 1:51 ` David Lang 1 sibling, 2 replies; 222+ messages in thread From: Adrian Bunk @ 2005-01-06 19:35 UTC (permalink / raw) To: David Lang Cc: Arjan van de Ven, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Tue, Jan 04, 2005 at 12:18:26PM -0800, David Lang wrote: > Sorry, I've been useing kernel.org kernels since the 2.0 days and even > within a stable series I always do a full set of tests before upgrading. > every single stable series has had 'paper bag' releases, and every single > one has had fixes to drivers that have ended up breaking those drivers. > > the only way to know if a new kernel will work on your hardware is to try > it. It doesn't matter if the upgrade is from 2.4.24 to 2.4.25 or 2.6.9 to > 2.6.10 or even 2.4.24 to 2.6.10 > > anyone who assumes that just becouse the kernel is in the stable series > they can blindly upgrade their production systems is just dreaming. I was not thinking about a "blindly upgrade". But the question is if you compile and test a kernel, is it every unlikely or relatively common to observe new problems? > David Lang cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 19:35 ` Adrian Bunk @ 2005-01-06 23:33 ` Daniel Gryniewicz 2005-01-07 1:51 ` David Lang 1 sibling, 0 replies; 222+ messages in thread From: Daniel Gryniewicz @ 2005-01-06 23:33 UTC (permalink / raw) To: Adrian Bunk Cc: David Lang, Arjan van de Ven, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Thu, 2005-01-06 at 20:35 +0100, Adrian Bunk wrote: > On Tue, Jan 04, 2005 at 12:18:26PM -0800, David Lang wrote: > But the question is if you compile and test a kernel, is it every > unlikely or relatively common to observe new problems? In my case, for -linus, never. For -mm, relatively common. This indicates to me that the process is working. (Every case I thought I'd hit of a regression was a result of some patch on top of -linus, usually -ck or -mm.) Daniel ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 19:35 ` Adrian Bunk 2005-01-06 23:33 ` Daniel Gryniewicz @ 2005-01-07 1:51 ` David Lang 2005-01-07 5:48 ` John Richard Moser 1 sibling, 1 reply; 222+ messages in thread From: David Lang @ 2005-01-07 1:51 UTC (permalink / raw) To: Adrian Bunk Cc: Arjan van de Ven, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Thu, 6 Jan 2005, Adrian Bunk wrote: >> anyone who assumes that just becouse the kernel is in the stable series >> they can blindly upgrade their production systems is just dreaming. > > I was not thinking about a "blindly upgrade". > > But the question is if you compile and test a kernel, is it every > unlikely or relatively common to observe new problems? > in my experiance the answer is very unlikely, and about as likely as I got used to during the 2.0, 2.2, and 2.4 series (the 2.4 series had some time when it was significantly worse). while I used 1.2 and 0. series kernels I didn't follow them well enough to comment on that timeframe. in every series there have been versions that didn't work, sometimes spectacularly, but in every series the later versions tend to fix far more then it breaks. I have been burned severely by development series kernels and had the same problems as everyone else with the first few 2.0, 2.2, and 2.4 series kernels, but I didn't run into the as many problems with 2.6.0 for those who are concerned about the quality of the 2.6 kernels I'd suggest that you don't judge exclusivly by the comments to the list, try them yourself. as far as removing features goes, personally I have a lot of boxes useing ipchains instead of iptables, even on 2.6 kernels and will be very unhappy if that compatability is removed, but at the same time I'm willing to hold off my screaming until Linus actually removes features. the netfilter folks can plan all they want to remove the compatability, but they can't force Linus to accept the patch that does the removal. remember that according to some people 2.6.0 wasn't supposed to support anything compiled in, everythign was going to be a module, with much of the hardware detection removed from the kernel and put into code running on initrd or similar. that didn't happenand I'm willing to lay good odds that removing a feature just becouse it's 'old' isn't very likly either. if there are problems with a feature and nobody cares about it enough to fix it then the feature may be removed, but if it affects a lot of people then it's likly that someone will step up to do the maintinance. if you want another example, look at reiserfs, Hans wants no new development done on version 3 becouse version 4 is available and is better in all ways. I believe that Hans would like to have version 3 removed and replaced with version 4 (with a utility to do the conversion between the two), but there are a lot of people who want to keep useing version 3 and as a result version 3 is maintained and updated. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 1:51 ` David Lang @ 2005-01-07 5:48 ` John Richard Moser 0 siblings, 0 replies; 222+ messages in thread From: John Richard Moser @ 2005-01-07 5:48 UTC (permalink / raw) To: David Lang Cc: Adrian Bunk, Arjan van de Ven, Rik van Riel, Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Lang wrote: | On Thu, 6 Jan 2005, Adrian Bunk wrote: | [...] | remember that according to some people 2.6.0 wasn't supposed to support | anything compiled in, everythign was going to be a module, with much of | the hardware detection removed from the kernel and put into code running | on initrd or similar. I'm told Linus refuses to do anything that would help establish and support binary drivers, even if someone else does the work for him and doesn't cause any bugs or interfere with the other systems inside the kernel. I'm not sure if this is true or not, but moving to modules-only sounds like a good first step to "Hey, let's do binary drivers to get third party support and become a real competing desktop OS" "Hey, let's do binary drivers" "Hey, let's do binary drivers" "SHUT THE HELL UP" "But hey man, binary drivers, we're already at all modules for drivers" ~ "Hey, binary drivers" "ALRIGHT FINE *grumble*" Not that I don't fully support closed-source binary drivers as a way to get hardware working until better, cleaner, open source alternatives show up, mind you. . . :) [...] | | David Lang | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3iK7hDd4aOud5P8RAibaAJ97SIihv6jFh1Pxs8X/KmmgtEEJfgCaAqby DszwpF70zEwKh15Sbj+YzqI= =j75D -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:18 ` Rik van Riel 2005-01-03 15:34 ` Adrian Bunk @ 2005-01-03 22:53 ` Bill Davidsen 2005-01-06 3:52 ` Ian Kent 2 siblings, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-03 22:53 UTC (permalink / raw) To: Rik van Riel Cc: Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel Rik van Riel wrote: > On Sun, 2 Jan 2005, Andries Brouwer wrote: > >> You change some stuff. The bad mistakes are discovered very soon. >> Some subtler things or some things that occur only in special >> configurations or under special conditions or just with >> very low probability may not be noticed until much later. > > > Some of these subtle bugs are only discovered a year > after the distribution with some particular kernel has > been deployed - at which point the kernel has moved on > so far that the fix the distro does might no longer > apply (even in concept) to the upstream kernel... > > This is especially true when you are talking about really > big database servers and bugs that take weeks or months > to trigger. > There is a reason why people pay big bucks to Redhat (and others) for a five year contract to back port the bug fixes to the original kernel and software. Barring some huge change I need, I expect to run AS3.0 for four more years for one application, "learning experiences" are not a good thing. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-03 15:18 ` Rik van Riel 2005-01-03 15:34 ` Adrian Bunk 2005-01-03 22:53 ` Bill Davidsen @ 2005-01-06 3:52 ` Ian Kent 2 siblings, 0 replies; 222+ messages in thread From: Ian Kent @ 2005-01-06 3:52 UTC (permalink / raw) To: Rik van Riel Cc: Andries Brouwer, William Lee Irwin III, Maciej Soltysiak, linux-kernel On Mon, 3 Jan 2005, Rik van Riel wrote: Oh so true. > On Sun, 2 Jan 2005, Andries Brouwer wrote: > > > You change some stuff. The bad mistakes are discovered very soon. > > Some subtler things or some things that occur only in special > > configurations or under special conditions or just with > > very low probability may not be noticed until much later. > > Some of these subtle bugs are only discovered a year Or longer and it doesn't need to be a large system. > after the distribution with some particular kernel has > been deployed - at which point the kernel has moved on > so far that the fix the distro does might no longer > apply (even in concept) to the upstream kernel... > > This is especially true when you are talking about really > big database servers and bugs that take weeks or months > to trigger. And it doesn't have to be large and complex just infrequently hit code path. This happens much more frequently than anyone wants but that's the the way it is. Ian ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-02 20:03 starting with 2.7 Maciej Soltysiak 2005-01-02 20:08 ` Emmanuel Fleury 2005-01-02 20:36 ` William Lee Irwin III @ 2005-01-06 20:02 ` John Richard Moser 2005-01-06 21:29 ` Alan Cox 2 siblings, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-06 20:02 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is gonna go on forever. I tried[1], but I guess development HAS to be in the "stable" branch and can't be shipped to a similarly managed "volatile" branch for development, since it obviously makes such a big difference to mainline kernel developers and less so to home users, third party developers, and businesses and institutions who rely on a mostly stable codebase to avoid surprise breakage. Is this a serious operating system or a running experiment? Running experiments have no place in production; if your "stable" mainline branch is going to continuously add and remove features and go through wild API and functionality changes, nobody is going to want to use it. Mozilla doesn't support IE's broken crap "because IE is a moving target." Unpredictable API changes and changes to the deep inner workings of the kernel will make the kernel "a moving target." If that's the route you take, it will become too difficult for people to develope for linux. [1] http://woct-blog.blogspot.com/2005/01/finally-new-pax.html Maciej Soltysiak wrote: | Hi, | | I was wondering in the tram today are we close to branching | off to 2.7 | | Do the mighty kernel developers have solid plans, ideas, etc | to start experimental code | | Regards, | Maciej | | | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3ZlohDd4aOud5P8RAg02AJ0VhUkRyzvfXzHS8YkQgdWru+VpyQCcCrbA 3rQr6wgKPMLXAl79OsrwdBQ= =ci1u -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 20:02 ` John Richard Moser @ 2005-01-06 21:29 ` Alan Cox 2005-01-07 0:06 ` John Richard Moser 2005-01-07 16:34 ` M. Edward Borasky 0 siblings, 2 replies; 222+ messages in thread From: Alan Cox @ 2005-01-06 21:29 UTC (permalink / raw) To: John Richard Moser; +Cc: Maciej Soltysiak, Linux Kernel Mailing List On Iau, 2005-01-06 at 20:02, John Richard Moser wrote: > experiments have no place in production; if your "stable" mainline > branch is going to continuously add and remove features and go through > wild API and functionality changes, nobody is going to want to use it. > Mozilla doesn't support IE's broken crap "because IE is a moving > target." Unpredictable API changes and changes to the deep inner IE hasn't moved in years. The inventiveness of the bad web page authors might be unbounded 8) > workings of the kernel will make the kernel "a moving target." If > that's the route you take, it will become too difficult for people to > develope for linux. Its also impossible to do development if none of the changes you make get into the kernel for stability reasons ever. Its a double edged sword. For most end users it is about distribution kernels not the base. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 21:29 ` Alan Cox @ 2005-01-07 0:06 ` John Richard Moser 2005-01-07 16:34 ` M. Edward Borasky 1 sibling, 0 replies; 222+ messages in thread From: John Richard Moser @ 2005-01-07 0:06 UTC (permalink / raw) To: Alan Cox; +Cc: Maciej Soltysiak, Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: | On Iau, 2005-01-06 at 20:02, John Richard Moser wrote: | |>experiments have no place in production; if your "stable" mainline |>branch is going to continuously add and remove features and go through |>wild API and functionality changes, nobody is going to want to use it. |>Mozilla doesn't support IE's broken crap "because IE is a moving |>target." Unpredictable API changes and changes to the deep inner | | | IE hasn't moved in years. The inventiveness of the bad web page authors | might be unbounded 8) | 8) | |>workings of the kernel will make the kernel "a moving target." If |>that's the route you take, it will become too difficult for people to |>develope for linux. | | | Its also impossible to do development if none of the changes you make | get into the kernel for stability reasons ever. Its a double edged | sword. For most end users it is about distribution kernels not the base. Well, I was thinking more that the 2.6 development process is a very clean edged process, and should be preserved specially. More to the point, I was considering the potential to move the 2.6 scheme to 2.7. The even branches would thus again become "Stable," only getting *bugfixes*. I say bugfixes because they encompass security fixes. I don't think backporting drivers would be a bad thing; but somebody has to maintain that. The odd branches would become "Volatile," continuing as 2.6 does now. This doesn't mean you break them horribly and then start cleaning up the mess; it means you continue to place invasive changes that are relatively stable, and try to clean up. This has been proven already to be an excellent development model in terms of reliablility and usability of the product. With a stable/stagnating "Stable" codebase, third party development can focus on getting real work done and not chasing API changes or altering the specs to match with core changes. For example, the compressed pagecache patch[1] and PaX[2] both have to adjust heavily to VM changes. ~ This is a lot of work, and can become detrimental to their development ([1] is pretty much dead) if it occurs unpredictably or, especially, rapidly. The "Stable" codebase is also useful for businesses which need a reliable system without the need to do 3-5 months of extensive testing every 6-8 weeks. With bugfixes only, upgrading would be basically testing in a lab for several hours, then giving the go-ahead to drop in a new kernel with 5 security fixes and 2 FS corruption fixes. The individual patches could be audited by technicians between upgrades too, since they'd be mostly just a handfull of code. With a 6-9 month release cycle, new features would still come out in a timely manner. Home users with a bleeding-edge impulse would just run the "Volatile" branch anyway; it's good enough for 2.6 stable, it's good enough for them. Businesses don't tend to have the desire to run the latest awesome O(pi/4) scheduler and decaying object based quantum rmap VM core, at least not until it's gone through lots and lots of testing. As another plus, most external development would be on the same page. Thus distributions would be able to keep their kernels mostly "up to date" without picking and chosing between sets of patches based on who's on what version. You wouldn't have to chose between translucency on 2.6.8 or supermount-ng on 2.6.10, or realtime IRQ preemption and on-access userspace triggering for antivirus scans on 2.6.12. You wouldn't have to do tons of work to hack these together either, and probably release a buggy kernel as you cross more bounds than you'd intended to. If up to 3 releases were supported, a 6 month release cycle would give 18 months of continued bug/security fixes on any given kernel before it was officially unsupported. This figure approaches 27 months as the release cycle grows towards 9 months. A new release is always ready, too. Please tell me where I'm wielding a double edged sword here. I don't honestly expect the kernel devs to change the scheme "Because I said so," but I think the arguing should stop and we should focus more on determining if there is a better way, and how to do it if so. [1] http://linuxcompressed.sf.net/ [2] http://pax.grsecurity.net/ | | | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3dJphDd4aOud5P8RAh/BAJ9PsXdmbcqs7d8I413FrhciEm3AmwCghkDg 8tzr8WTV6vYjy8+o2/Su0jg= =Hj/7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-06 21:29 ` Alan Cox 2005-01-07 0:06 ` John Richard Moser @ 2005-01-07 16:34 ` M. Edward Borasky 2005-01-07 17:25 ` John Richard Moser 1 sibling, 1 reply; 222+ messages in thread From: M. Edward Borasky @ 2005-01-07 16:34 UTC (permalink / raw) To: Linux Kernel Mailing List On Thu, 2005-01-06 at 21:29 +0000, Alan Cox wrote: > On Iau, 2005-01-06 at 20:02, John Richard Moser wrote: > > experiments have no place in production; if your "stable" mainline > > branch is going to continuously add and remove features and go through > > wild API and functionality changes, nobody is going to want to use it. > > Mozilla doesn't support IE's broken crap "because IE is a moving > > target." Unpredictable API changes and changes to the deep inner > > IE hasn't moved in years. The inventiveness of the bad web page authors > might be unbounded 8) > > > workings of the kernel will make the kernel "a moving target." If > > that's the route you take, it will become too difficult for people to > > develope for linux. > > Its also impossible to do development if none of the changes you make > get into the kernel for stability reasons ever. Its a double edged > sword. For most end users it is about distribution kernels not the base. There are two classes of "end users". There are true end users who get their Linux from a distributor, and there are the distributors. And there are two classes of distributors, for-profit and not-for-profit. Somehow the Linux kernel has managed to meet enough of the needs of enough of these folks that GNU/Linux is one of the top three desktop operating systems in the world. I'm not sure where it ranks among servers, but surely it's competitive with Windows on Intel-based servers, if not with the "native" UNIX derivatives on other hardware. I use Red Hat (mix of 8.0, 9.0 and RHEL) at work and Gentoo at home. I recently migrated all my home systems to Gentoo's version of 2.6.10, did the devfs-udev, oss-alsa, 2.4 headers-2.6 headers, and ntpl migration. As far as Gentoo is concerned, this is a stable, production environment. I had a few glitches; it's not something I'd expect someone without extensive system programming experience to pull off, even with Gentoo's well-written HowTos. As far as *I'm* concerned, it is a stable production environment. I would recommend it to my friends (knowing that I could bail them out if they messed it up :). I would recommend it to businesses (knowing that I could earn big bucks to bail them out when they messed it up. :). Given all that, what about 2.6 and 2.7? Here's where I break away from the mainstream -- big-time. I'd like to see 2.6 live forever as the "stable general purpose kernel of choice for multiple architectures" that it is today. And I'd like to see the broad "kernel community" move to a 64-bit-only microkernel-based "GNU/Whatever". There's just too many hacks, patches, band-aids, etc., in the address space on 32-bit architectures. Just about everybody *has* a 64-bit address space available, and the performance penalities that drove Linus away from microkernels have, to my knowledge, been resolved. Which microkernel? Well ... I'm sure there are people here who are more expert than I am. The one that appeals to me the most is the Dresden Real-Time Operating System/L4 line, which, in fact, can support Linux 2.4 and 2.6 on 32-bit architectures as a "bonus". 64 bit is the future -- I expect to have a 64-bit machine operating by summer, although it's not clear to me whether it will be AMD64 or PPC64 at this point, and it's not clear to me whether the OS will be Gentoo GNU/Linux or Macintosh OS X. I'm really intrigued with the thought of a G5 dual-booted; I've had a lot of fun with Windows/Linux dual-boot machines over the years. :) ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 16:34 ` M. Edward Borasky @ 2005-01-07 17:25 ` John Richard Moser 2005-01-09 2:31 ` M. Edward Borasky 0 siblings, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-07 17:25 UTC (permalink / raw) To: znmeb; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Edward Borasky wrote: | On Thu, 2005-01-06 at 21:29 +0000, Alan Cox wrote: | |>On Iau, 2005-01-06 at 20:02, John Richard Moser wrote: |> |>>experiments have no place in production; if your "stable" mainline |>>branch is going to continuously add and remove features and go through |>>wild API and functionality changes, nobody is going to want to use it. |>>Mozilla doesn't support IE's broken crap "because IE is a moving |>>target." Unpredictable API changes and changes to the deep inner |> |>IE hasn't moved in years. The inventiveness of the bad web page authors |>might be unbounded 8) |> |> |>>workings of the kernel will make the kernel "a moving target." If |>>that's the route you take, it will become too difficult for people to |>>develope for linux. |> |>Its also impossible to do development if none of the changes you make |>get into the kernel for stability reasons ever. Its a double edged |>sword. For most end users it is about distribution kernels not the base. | | | There are two classes of "end users". There are true end users who get | their Linux from a distributor, and there are the distributors. And | there are two classes of distributors, for-profit and not-for-profit. | Somehow the Linux kernel has managed to meet enough of the needs of | enough of these folks that GNU/Linux is one of the top three desktop | operating systems in the world. I'm not sure where it ranks among | servers, but surely it's competitive with Windows on Intel-based | servers, if not with the "native" UNIX derivatives on other hardware. | Uh. Businesses, institutions like schools and libraries, home users, those aren't the same. They all have needs. For example, a POS that flops and crashes every 5 hours is going to be bad for a business; a home user can do it without losing billions of dollars a year. | I use Red Hat (mix of 8.0, 9.0 and RHEL) at work and Gentoo at home. I | recently migrated all my home systems to Gentoo's version of 2.6.10, did | the devfs-udev, oss-alsa, 2.4 headers-2.6 headers, and ntpl migration. | As far as Gentoo is concerned, this is a stable, production | environment. | Bull. Shit. Try /join #hardened-gentoo and ask about how stable 2.6 is once. The hardened team has been having a hard time because 2.6 keeps changing. I was told that gentoo-dev-sources and hardened-dev-sources will become gentoo-sources and hardened-sources when they're considered stable. They're still -dev. What does this tell you? <@tseng> stable? sometimes <@tseng> production, nope. | I had a few glitches; it's not something I'd expect someone without | extensive system programming experience to pull off, even with Gentoo's | well-written HowTos. As far as *I'm* concerned, it is a stable | production environment. That's you. | I would recommend it to my friends (knowing that | I could bail them out if they messed it up :). I would recommend it to | businesses (knowing that I could earn big bucks to bail them out when | they messed it up. :). | I wouldn't recommend it to businesses, because a fuck-up means they lose money. You ever see a production server go down? You can totally wipe out a business that way. If a glitch trashes the filesystem, you might as well stop trying. Unless of course you can ship your off-site backups back on-site and restore the whole damn thing to working order within 3 days. Better hope the kernel you were using when it was working is in the backups. | Given all that, what about 2.6 and 2.7? Here's where I break away from | the mainstream -- big-time. I'd like to see 2.6 live forever as the | "stable general purpose kernel of choice for multiple architectures" | that it is today. And I'd like to see the broad "kernel community" move | to a 64-bit-only microkernel-based "GNU/Whatever". Dreamer. | | There's just too many hacks, patches, band-aids, etc., in the address | space on 32-bit architectures. Just about everybody *has* a 64-bit | address space available, and the performance penalities that drove Linus | away from microkernels have, to my knowledge, been resolved. | What? I have amd64, nobody else I know does. My aunt had one taylored to her needs, but that was from my influence. The other 2 people I know who bought new machines got an Athlon and a Sempron. Linus hates microkernels :o | Which microkernel? Well ... I'm sure there are people here who are more | expert than I am. The one that appeals to me the most is the Dresden | Real-Time Operating System/L4 line, which, in fact, can support Linux | 2.4 and 2.6 on 32-bit architectures as a "bonus". 64 bit is the future | -- I expect to have a 64-bit machine operating by summer, although it's | not clear to me whether it will be AMD64 or PPC64 at this point, and | it's not clear to me whether the OS will be Gentoo GNU/Linux or | Macintosh OS X. I'm really intrigued with the thought of a G5 | dual-booted; I've had a lot of fun with Windows/Linux dual-boot machines | over the years. :) | | | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3sXvhDd4aOud5P8RAv0DAJ4xjlbhzaNN7N6nu3jM06EEq8QtSwCeOCrh yTxloXo434xAtQvInE7PNRA= =oTE1 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 17:25 ` John Richard Moser @ 2005-01-09 2:31 ` M. Edward Borasky 2005-01-09 3:01 ` Valdis.Kletnieks 2005-01-09 3:08 ` John Richard Moser 0 siblings, 2 replies; 222+ messages in thread From: M. Edward Borasky @ 2005-01-09 2:31 UTC (permalink / raw) To: John Richard Moser; +Cc: Linux Kernel Mailing List On Fri, 2005-01-07 at 12:25 -0500, John Richard Moser wrote: > Try /join #hardened-gentoo and ask about how stable 2.6 is once. The > hardened team has been having a hard time because 2.6 keeps changing. > > I was told that gentoo-dev-sources and hardened-dev-sources will become > gentoo-sources and hardened-sources when they're considered stable. > They're still -dev. What does this tell you? > > <@tseng> stable? sometimes > <@tseng> production, nope. Well, the story I'm hearing on the Gentoo mailing lists (I don't frequent IRC) is that the next Gentoo release, which is scheduled for sometime this month (Jan 2005) will be 2.6-based, although, like all Gentoo releases, you will be able to customize it to 2.4 if that's what you want and/or need to do. There is some pushback from those who fear 2.6 isn't ready for prime time. I think 2.6 is winning and will prevail. Gentoo is admittedly an "expert's" distro and I am admittedly biased towards it. But there are simply too many things that aren't *ever* going to get done in 2.4, especially with RHEL 4 being 2.6-based. I held off on 2.6 because of a few minor glitches -- a touchy touchpad on the laptop and some difficulties with dhcpcd picking up an IP address from my cable modem were the worst ones. They're fixed now, and 2.6.10 has the best audio latency performance "out of the box" ever for a Linux kernel, and I had a three-day weekend -- case closed! Hooray for 2.6! Long Live 2.6! 2.6 or Fight! Give Me 2.6 Or Give Me Death! :) > I wouldn't recommend it to businesses, because a fuck-up means they lose > money. You ever see a production server go down? You can totally wipe > out a business that way. If a glitch trashes the filesystem, you might > as well stop trying. Unless of course you can ship your off-site > backups back on-site and restore the whole damn thing to working order > within 3 days. Better hope the kernel you were using when it was > working is in the backups. A poorly managed IT operation can wipe out a business, whether the "production server" is Windows-based, RHEL-based, Tru64-based, Solaris-based, "woody"-based or Gentoo-based. Much as I hate Windows, I work in a company with a Windows-based IT infrastructure, and I go out of my way to help them keep it safe and productive, despite my obvious Linux bias. That's part of being a good corporate citizen. Are you claiming that a 2.4-kernel-based IT infrastructure has less need for **competent** security, privacy, performance and data integrity policies, procedures and people than a 2.6-kernel-based one, all other things being equal? > | Given all that, what about 2.6 and 2.7? Here's where I break away from > | the mainstream -- big-time. I'd like to see 2.6 live forever as the > | "stable general purpose kernel of choice for multiple architectures" > | that it is today. And I'd like to see the broad "kernel community" move > | to a 64-bit-only microkernel-based "GNU/Whatever". > > Dreamer. Exactly! I am a dreamer, and proud of it! I want a nice 64-bit real-time lab/studio for algorithmic composition and synthesis of music. I want something that can address memory over a gigabyte without contorting the memory management into a bizarre scheme reminiscent of the "good old days" when one had to run big programs in little machines using (gag, retch) overlays! Are you aware how large 2^64 - 1 is? Don't they teach the old fable about grains of rice on the chessboard any more? :) Please don't make me go back to the days when Thomas Watson said there was a world-wide market for ten to twelve computers, or when Ken Olsen asked why anyone would want a computer in their home! Please don't make me use a LISP or R or whatever language that can't handle a data structure larger than 2^32 - 1! Please don't make me talk to my computer in 7-bit code on a 300-baud modem! Is this the 21st century? Am I the *only* dreamer? > Linus hates microkernels :o When Linus chose the "monolithic yet modular" approach for Linux over the microkernel approach, the state of the art in compilers and hardware was on his side. We're talking 386, GCC 1, right? It was the correct decision. I don't think he "hates" microkernels (Linus, correct me if I'm wrong :), he simply made an implementation decision to go another way. Again, I'm a dreamer. :) By the way, I never owned a 286 or 386. I went straight from 80186/DOS 5.0 to a Pentium MMX running Windows 95. I missed out on a lot of fun, eh? ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-09 2:31 ` M. Edward Borasky @ 2005-01-09 3:01 ` Valdis.Kletnieks 2005-01-09 3:08 ` John Richard Moser 1 sibling, 0 replies; 222+ messages in thread From: Valdis.Kletnieks @ 2005-01-09 3:01 UTC (permalink / raw) To: znmeb; +Cc: John Richard Moser, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1378 bytes --] On Sat, 08 Jan 2005 18:31:50 PST, "M. Edward Borasky" said: > about grains of rice on the chessboard any more? :) Please don't make me > go back to the days when Thomas Watson said there was a world-wide > market for ten to twelve computers, or when Ken Olsen asked why anyone > would want a computer in their home! Ken Olson had his head stuck someplace when he said that. However, the Thomas Watson quote *does* need some clarification. When he said that, IBM was *already* in the business of selling automated tabulating machinery with limited computational ability on board, and he was specifically talking about large multi-10s-of-millions of dollar pricetag machines (in other words, a supercomputer). He was right then, and he's right now. SGI is selling Altix systems - but I'd be surprised if they can sell more than a half-dozen or so Columbia-scale configurations. IBM will sell lots of 16-64 processor Blue Gene boxes, just like they sold lots of small SP-2 boxes, but they'll probably only sell a very few boxes at the very high end. Look at the Top500 list (www.top500.org). Currently, the leader is a Blue Gene box at 70K Rmax, and 10th place has an Rmax around 9.8K. But 20th is 7.3K and 30th is 5.5K. Lots of people are buying boxes that will land in the 10-100 range, but there's only a few places that are buying stuff that will land in the Top 10. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-09 2:31 ` M. Edward Borasky 2005-01-09 3:01 ` Valdis.Kletnieks @ 2005-01-09 3:08 ` John Richard Moser 2005-01-09 23:02 ` Alan Cox 1 sibling, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-09 3:08 UTC (permalink / raw) To: znmeb; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Edward Borasky wrote: | On Fri, 2005-01-07 at 12:25 -0500, John Richard Moser wrote: | | |>Try /join #hardened-gentoo and ask about how stable 2.6 is once. The |>hardened team has been having a hard time because 2.6 keeps changing. |> |>I was told that gentoo-dev-sources and hardened-dev-sources will become |>gentoo-sources and hardened-sources when they're considered stable. |>They're still -dev. What does this tell you? |> |><@tseng> stable? sometimes |><@tseng> production, nope. | | | Well, the story I'm hearing on the Gentoo mailing lists (I don't | frequent IRC) is that the next Gentoo release, which is scheduled for | sometime this month (Jan 2005) will be 2.6-based, although, like all | Gentoo releases, you will be able to customize it to 2.4 if that's what | you want and/or need to do. There is some pushback from those who fear | 2.6 isn't ready for prime time. I think 2.6 is winning and will prevail. | | Gentoo is admittedly an "expert's" distro and I am admittedly biased | towards it. But there are simply too many things that aren't *ever* | going to get done in 2.4, especially with RHEL 4 being 2.6-based. I held | off on 2.6 because of a few minor glitches -- a touchy touchpad on the | laptop and some difficulties with dhcpcd picking up an IP address from | my cable modem were the worst ones. They're fixed now, and 2.6.10 has | the best audio latency performance "out of the box" ever for a Linux | kernel, and I had a three-day weekend -- case closed! Hooray for 2.6! | Long Live 2.6! 2.6 or Fight! Give Me 2.6 Or Give Me Death! :) | That's fine for a home user. What about a kernel hacker, a distributor, a business, people who have to clean up after this mess. . . . | |>I wouldn't recommend it to businesses, because a fuck-up means they lose |>money. You ever see a production server go down? You can totally wipe |>out a business that way. If a glitch trashes the filesystem, you might |>as well stop trying. Unless of course you can ship your off-site |>backups back on-site and restore the whole damn thing to working order |>within 3 days. Better hope the kernel you were using when it was |>working is in the backups. | | | A poorly managed IT operation can wipe out a business, whether the | "production server" is Windows-based, RHEL-based, Tru64-based, | Solaris-based, "woody"-based or Gentoo-based. Much as I hate Windows, I | work in a company with a Windows-based IT infrastructure, and I go out | of my way to help them keep it safe and productive, despite my obvious | Linux bias. That's part of being a good corporate citizen. | true | Are you claiming that a 2.4-kernel-based IT infrastructure has less need | for **competent** security, privacy, performance and data integrity | policies, procedures and people than a 2.6-kernel-based one, all other | things being equal? | Not at all I'm claiming that an IT infrastructure that has to support 2.6 as-is will be wildly more complex and more expensive than one supporting a truly stable one with the same efficiency. It keeps changing. New features must be added that aren't amply tested (and due to the 2.6 development structure, ample testing before mainline integration is much more difficult). | |>| Given all that, what about 2.6 and 2.7? Here's where I break away from |>| the mainstream -- big-time. I'd like to see 2.6 live forever as the |>| "stable general purpose kernel of choice for multiple architectures" |>| that it is today. And I'd like to see the broad "kernel community" move |>| to a 64-bit-only microkernel-based "GNU/Whatever". |> |>Dreamer. | | | Exactly! I am a dreamer, and proud of it! I want a nice 64-bit real-time | lab/studio for algorithmic composition and synthesis of music. I want | something that can address memory over a gigabyte without contorting the | memory management into a bizarre scheme reminiscent of the "good old | days" when one had to run big programs in little machines using (gag, | retch) overlays! | | Are you aware how large 2^64 - 1 is? Don't they teach the old fable | about grains of rice on the chessboard any more? :) Please don't make me | go back to the days when Thomas Watson said there was a world-wide | market for ten to twelve computers, or when Ken Olsen asked why anyone | would want a computer in their home! Please don't make me use a LISP or | R or whatever language that can't handle a data structure larger than | 2^32 - 1! Please don't make me talk to my computer in 7-bit code on a | 300-baud modem! Is this the 21st century? Am I the *only* dreamer? | | |>Linus hates microkernels :o | | | When Linus chose the "monolithic yet modular" approach for Linux over | the microkernel approach, the state of the art in compilers and hardware | was on his side. We're talking 386, GCC 1, right? It was the correct | decision. I don't think he "hates" microkernels (Linus, correct me if | I'm wrong :), he simply made an implementation decision to go another | way. Again, I'm a dreamer. :) | | By the way, I never owned a 286 or 386. I went straight from 80186/DOS | 5.0 to a Pentium MMX running Windows 95. I missed out on a lot of fun, | eh? | Ask Linus to start making 3rd party binary module support a reality then. | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4KAxhDd4aOud5P8RAuWVAJ48W17owI6ifRJzVPUse5M8NnMW5wCggaYg sisVibORA6j/4yJEz070BoA= =i9zy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-09 3:08 ` John Richard Moser @ 2005-01-09 23:02 ` Alan Cox 2005-01-10 0:30 ` John Richard Moser 0 siblings, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-09 23:02 UTC (permalink / raw) To: John Richard Moser; +Cc: znmeb, Linux Kernel Mailing List > I'm claiming that an IT infrastructure that has to support 2.6 as-is > will be wildly more complex and more expensive than one supporting a > truly stable one with the same efficiency. It keeps changing. New > features must be added that aren't amply tested (and due to the 2.6 > development structure, ample testing before mainline integration is much > more difficult). Large IT businesses already deployed 2.6 (SuSE) and will do so more soon (Red Hat). These vendors are guaranteeing long term stable maintenance of those versions. > Ask Linus to start making 3rd party binary module support a reality then. Binary module support is pretty irrelevant. Good management of out of tree source code recompiling is a much more useful and relevant topic. 2.6 has caused an inadvertent problem there because with 2.4 it was *much* easier to grab 2.4.x and drop in a 2.4.y version of a driver. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-09 23:02 ` Alan Cox @ 2005-01-10 0:30 ` John Richard Moser 2005-01-10 1:26 ` Indrek Kruusa 2005-01-10 1:28 ` Dave Airlie 0 siblings, 2 replies; 222+ messages in thread From: John Richard Moser @ 2005-01-10 0:30 UTC (permalink / raw) To: Alan Cox; +Cc: znmeb, Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: |>I'm claiming that an IT infrastructure that has to support 2.6 as-is |>will be wildly more complex and more expensive than one supporting a |>truly stable one with the same efficiency. It keeps changing. New |>features must be added that aren't amply tested (and due to the 2.6 |>development structure, ample testing before mainline integration is much |>more difficult). | | | Large IT businesses already deployed 2.6 (SuSE) and will do so more soon | (Red Hat). These vendors are guaranteeing long term stable maintenance | of those versions. | | |>Ask Linus to start making 3rd party binary module support a reality then. | | | Binary module support is pretty irrelevant. Good management of out of | tree source code recompiling is a much more useful and relevant topic. | 2.6 has caused an inadvertent problem there because with 2.4 it was | *much* easier to grab 2.4.x and drop in a 2.4.y version of a driver. | | And what 3rd party hardware vendor wants to waste their resources by repeting smaller versions of the one-time cost of driver writing over and over to accomodate linux, when they can't even accomodate all versions due to special patches some people have? So far there's been a rediculous but visible trend of hardware vendors to hold their source closed. Why not just chase the easier targets like Windows and MacOS? I want Linux to be a popular OS. Linus I wouldn't be surprised if he doesn't care, because Linux isn't a business (though some businesses are for all intents and purposes basically Linux), so this is pretty much a moot point to be arguing. Anything having to do with the marketability of Linux is pretty much not worth arguing; genuine quality in the open source community tends to be, though only if it encompasses only contributions from the open source community. I guess this isn't worth bothering to argue anymore. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4cy2hDd4aOud5P8RAuJmAKCJ29DIvWuqPLhRvmn+IRdvroNcRgCfU1qD rcuho2zJTLnH9CMt7urYfyM= =eCh6 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 0:30 ` John Richard Moser @ 2005-01-10 1:26 ` Indrek Kruusa 2005-01-10 1:28 ` Dave Airlie 1 sibling, 0 replies; 222+ messages in thread From: Indrek Kruusa @ 2005-01-10 1:26 UTC (permalink / raw) To: John Richard Moser; +Cc: linux-kernel > > I want Linux to be a popular OS. Linus I wouldn't be surprised if he > doesn't care, because Linux isn't a business (though some businesses are > for all intents and purposes basically Linux) Of course at moment there are no signs of decreasing in Linux oriented market, but still: - absolutely everything exists due to the users - if there are no users left then the "thing" is dead. Well, for Linux it is enough to have two users, e.g. IBM and SGI and current development model (example of finest OS > simple usability) will end up just there. In the other hand, of course, we do not want usable OS as example of biggest BS(tm). So somewhere in between should be the agreement. But if there are so many voices against then we are not in between. OK, voices are not equal in their strength :) Indrek ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 0:30 ` John Richard Moser 2005-01-10 1:26 ` Indrek Kruusa @ 2005-01-10 1:28 ` Dave Airlie 2005-01-10 2:16 ` John Richard Moser ` (2 more replies) 1 sibling, 3 replies; 222+ messages in thread From: Dave Airlie @ 2005-01-10 1:28 UTC (permalink / raw) To: John Richard Moser; +Cc: Alan Cox, znmeb, Linux Kernel Mailing List > And what 3rd party hardware vendor wants to waste their resources by > repeting smaller versions of the one-time cost of driver writing over > and over to accomodate linux, when they can't even accomodate all > versions due to special patches some people have? So far there's been a > rediculous but visible trend of hardware vendors to hold their source > closed. I do wonder would open source kernel drivers to work with a closed source user space application be accepted into the mainline kernel... say for example Nvidia or VMware GPL'ed their lower layer kernel interfaces but kept their userspace (X driver and VMware) closed source which is perfectly acceptable from a license point of view.. would Linus/Andrew accept the nvidia lowlevel into the kernel, if not then it would be idealogical not licensing issues which would make the argument for having a stable module interface better :-) It would be interesting to find out .. and you are right there is little point in arguing this at this stage, closed source drivers are evil. Dave. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 1:28 ` Dave Airlie @ 2005-01-10 2:16 ` John Richard Moser 2005-01-10 4:51 ` Gene Heskett 2005-01-10 18:27 ` Alan Cox 2 siblings, 0 replies; 222+ messages in thread From: John Richard Moser @ 2005-01-10 2:16 UTC (permalink / raw) To: Dave Airlie; +Cc: Alan Cox, znmeb, Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Airlie wrote: |>And what 3rd party hardware vendor wants to waste their resources by |>repeting smaller versions of the one-time cost of driver writing over |>and over to accomodate linux, when they can't even accomodate all |>versions due to special patches some people have? So far there's been a |>rediculous but visible trend of hardware vendors to hold their source |>closed. | | | I do wonder would open source kernel drivers to work with a closed | source user space application be accepted into the mainline kernel... | say for example Nvidia or VMware GPL'ed their lower layer kernel | interfaces but kept their userspace (X driver and VMware) closed | source which is perfectly acceptable from a license point of view.. | would Linus/Andrew accept the nvidia lowlevel into the kernel, if not | then it would be idealogical not licensing issues which would make the | argument for having a stable module interface better :-) | | It would be interesting to find out .. and you are right there is | little point in arguing this at this stage, closed source drivers are | evil. | I believe closed source drivers are an acceptable evil for two cases: - - We do not have an open source alteranive yet, and so we need one to use while that's being developed - - The hardware is obscure and nobody cares enough to write a driver anyway open source drivers are better becaus I can just recompile them for new hardware. Get a PPC? Have a USB cam? Rebuild the kernel for PPC with OSS drivers. Can't do that with binaries. Can't security audit the source code of binaries either. :) | Dave. | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4eV5hDd4aOud5P8RAnZoAJ9sVMoZTK1HW0RmRtA/OGdmphYTLQCeNtNO +UvNm8WfPeUj1h90nkAjlZo= =65kw -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 1:28 ` Dave Airlie 2005-01-10 2:16 ` John Richard Moser @ 2005-01-10 4:51 ` Gene Heskett 2005-01-10 18:27 ` Alan Cox 2 siblings, 0 replies; 222+ messages in thread From: Gene Heskett @ 2005-01-10 4:51 UTC (permalink / raw) To: linux-kernel, Dave Airlie; +Cc: John Richard Moser, Alan Cox, znmeb On Sunday 09 January 2005 20:28, Dave Airlie wrote: >> And what 3rd party hardware vendor wants to waste their resources >> by repeting smaller versions of the one-time cost of driver >> writing over and over to accomodate linux, when they can't even >> accomodate all versions due to special patches some people have? >> So far there's been a rediculous but visible trend of hardware >> vendors to hold their source closed. > >I do wonder would open source kernel drivers to work with a closed >source user space application be accepted into the mainline > kernel... say for example Nvidia or VMware GPL'ed their lower layer > kernel interfaces but kept their userspace (X driver and VMware) > closed source which is perfectly acceptable from a license point of > view.. would Linus/Andrew accept the nvidia lowlevel into the > kernel, if not then it would be idealogical not licensing issues > which would make the argument for having a stable module interface > better :-) > >It would be interesting to find out .. and you are right there is >little point in arguing this at this stage, closed source drivers > are evil. > >Dave. Are we not already seeing proprietary drivers in the form of hex code lists from these people with no srcs in the patches that have gone by on this list just this past week? What makes these folks think the result won't be dissed and inspected? I know I darned sure would be doing exactly that just to make sure the stuff is at least benign before its ever allowed in the same room with a production box... >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 1:28 ` Dave Airlie 2005-01-10 2:16 ` John Richard Moser 2005-01-10 4:51 ` Gene Heskett @ 2005-01-10 18:27 ` Alan Cox 2005-01-10 20:11 ` Andi Kleen 2005-01-10 22:19 ` Dave Airlie 2 siblings, 2 replies; 222+ messages in thread From: Alan Cox @ 2005-01-10 18:27 UTC (permalink / raw) To: Dave Airlie; +Cc: John Richard Moser, znmeb, Linux Kernel Mailing List On Llu, 2005-01-10 at 01:28, Dave Airlie wrote: > I do wonder would open source kernel drivers to work with a closed > source user space application be accepted into the mainline kernel... > say for example Nvidia or VMware GPL'ed their lower layer kernel It isnt about whether they are "accepted" but whether they are derivative works. The license is quite clear on this with the specific clarification included for the syscall interface. For the most part the interfaces people need are pretty generic so the problems don't arise. We've seen that with the proposed 1Gb DMA area on x86-64 - Nvidia wanted a 4Gb one to fix their hardware needs and various other drivers want a 1Gb DMA area. That happens to also sort Nvidia's problems. >From DRI experience I'd say that a mostly user space nvidia driver would probably be almost as problematic as a binary kernel module. It would make reverse engineering a lot easier though 8) ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 18:27 ` Alan Cox @ 2005-01-10 20:11 ` Andi Kleen 2005-01-10 19:55 ` Alan Cox 2005-01-10 22:19 ` Dave Airlie 1 sibling, 1 reply; 222+ messages in thread From: Andi Kleen @ 2005-01-10 20:11 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > > We've seen that with the proposed 1Gb DMA area on x86-64 - Nvidia wanted > a 4Gb one to fix their hardware needs and various other drivers want a > 1Gb DMA area. That happens to also sort Nvidia's problems. To clarify there are other drivers who also want 4GB (e.g. the free Intel and ATI DRM drivers and also some other video drivers) I haven't seen a real request from someone who requires 1GB, but needs to use more than 96MB (16MB GFP_DMA + 64-128MB softiommu/amd iommu memory) But 1GB is not enough for the higherend 3d users, especially when you put multiple adapters into the machine. >>From DRI experience I'd say that a mostly user space nvidia driver would > probably be almost as problematic as a binary kernel module. It would > make reverse engineering a lot easier though 8) I think it would be a good idea to perhaps to move common services needed by Nvidia and others (ATI, free DRI drivers, others) into a common free library. This way we would probably break them less often and there would be less potentially buggy code in the kernel. And anything that shrinks binary only drivers and replaces them with more and more free code is probably a good thing. And doing this in baby steps is probably the only realistic option. -Andi ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 20:11 ` Andi Kleen @ 2005-01-10 19:55 ` Alan Cox 2005-01-10 21:08 ` Andi Kleen 0 siblings, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-10 19:55 UTC (permalink / raw) To: Andi Kleen; +Cc: Linux Kernel Mailing List On Llu, 2005-01-10 at 20:11, Andi Kleen wrote: > Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > I haven't seen a real request from someone who requires 1GB, but needs > to use more than 96MB (16MB GFP_DMA + 64-128MB softiommu/amd iommu memory) Some bm4400 users report this problem. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 19:55 ` Alan Cox @ 2005-01-10 21:08 ` Andi Kleen 2005-01-11 16:10 ` Alan Cox 0 siblings, 1 reply; 222+ messages in thread From: Andi Kleen @ 2005-01-10 21:08 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List On Mon, Jan 10, 2005 at 07:55:22PM +0000, Alan Cox wrote: > On Llu, 2005-01-10 at 20:11, Andi Kleen wrote: > > Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > > I haven't seen a real request from someone who requires 1GB, but needs > > to use more than 96MB (16MB GFP_DMA + 64-128MB softiommu/amd iommu memory) > > Some bm4400 users report this problem. I would assume 64-96MB is enough for a bcm4400. -Andi ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 21:08 ` Andi Kleen @ 2005-01-11 16:10 ` Alan Cox 0 siblings, 0 replies; 222+ messages in thread From: Alan Cox @ 2005-01-11 16:10 UTC (permalink / raw) To: Andi Kleen; +Cc: Linux Kernel Mailing List On Llu, 2005-01-10 at 21:08, Andi Kleen wrote: > On Mon, Jan 10, 2005 at 07:55:22PM +0000, Alan Cox wrote: > > On Llu, 2005-01-10 at 20:11, Andi Kleen wrote: > > > Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > > > I haven't seen a real request from someone who requires 1GB, but needs > > > to use more than 96MB (16MB GFP_DMA + 64-128MB softiommu/amd iommu memory) > > > > Some bm4400 users report this problem. > > I would assume 64-96MB is enough for a bcm4400. Well as I said some bcm4400 users report this problem. So whatever we have right now isn't good enough. Perhaps fragmentation is involved. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 18:27 ` Alan Cox 2005-01-10 20:11 ` Andi Kleen @ 2005-01-10 22:19 ` Dave Airlie 2005-01-11 0:54 ` Matt Mackall 2005-01-11 16:10 ` Alan Cox 1 sibling, 2 replies; 222+ messages in thread From: Dave Airlie @ 2005-01-10 22:19 UTC (permalink / raw) To: Alan Cox; +Cc: John Richard Moser, znmeb, Linux Kernel Mailing List > On Llu, 2005-01-10 at 01:28, Dave Airlie wrote: > > I do wonder would open source kernel drivers to work with a closed > > source user space application be accepted into the mainline kernel... > > say for example Nvidia or VMware GPL'ed their lower layer kernel > > It isnt about whether they are "accepted" but whether they are > derivative works. The license is quite clear on this with the specific > clarification included for the syscall interface. but if the GPL'ed their in-kernel software and submitted it to the kernel for inclusion would it be accepted given that the only user for the software would be their own userspace driver, and that userspace driver is closed source.... I think people would object like crazy but I'd love to see what would happen? Say theoretically ATI decide tomorrow: 1. GPL in kernel source code (ATI is based on the DRM so it isn't such a leap of faith as say NVIDIA doing it...) 2. clean it all up so that it follows every single kernel coding practice to the letter 3. submit it for inclusion into the kernel as a device driver, drivers/char/drm/fglrx.c Now would you include it? we can't use the no-one is using it excuse, as people are using fglrx already and many have no choice, the driver would have no userspace applications other than the binary only 2D/3D drivers they supply for X... ATI would then benefit from the kernel development process for keeping the things up-to-date with respect to interfaces etc... In this way, people who are running on ppc etc would still not have or be any closer to 3D acceleration for their graphics cards, but ATI would have followed the rules as far as the kernel is concerned.... The main reason 3D graphics drivers are the big one here as of course we can't put OpenGL into the kernel, so it requires a split kernel/userspace solution, and one is of little use without the other, if the kernel one is GPL and userspace one is closed source how do people sit with it? (uneasy?) Dave. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 22:19 ` Dave Airlie @ 2005-01-11 0:54 ` Matt Mackall 2005-01-11 16:10 ` Alan Cox 1 sibling, 0 replies; 222+ messages in thread From: Matt Mackall @ 2005-01-11 0:54 UTC (permalink / raw) To: Dave Airlie Cc: Alan Cox, John Richard Moser, znmeb, Linux Kernel Mailing List On Tue, Jan 11, 2005 at 09:19:24AM +1100, Dave Airlie wrote: > Say theoretically ATI decide tomorrow: > 1. GPL in kernel source code (ATI is based on the DRM so it isn't such > a leap of faith as say NVIDIA doing it...) > 2. clean it all up so that it follows every single kernel coding > practice to the letter > 3. submit it for inclusion into the kernel as a device driver, > drivers/char/drm/fglrx.c > > Now would you include it? we can't use the no-one is using it excuse, > as people are using fglrx already and many have no choice, the driver > would have no userspace applications other than the binary only 2D/3D > drivers they supply for X... ATI would then benefit from the kernel > development process for keeping the things up-to-date with respect to > interfaces etc... I think so, yes. We'd be able to fix kernelspace bugs in it, for starters. > In this way, people who are running on ppc etc would still not have or > be any closer to 3D acceleration for their graphics cards, but ATI > would have followed the rules as far as the kernel is concerned.... They'd certainly be closer in that userspace code is significantly easier to emulate and/or reverse engineer. > The main reason 3D graphics drivers are the big one here as of course > we can't put OpenGL into the kernel, so it requires a split > kernel/userspace solution, and one is of little use without the other, > if the kernel one is GPL and userspace one is closed source how do > people sit with it? (uneasy?) If the userspace portion is using a standard API and not just using the driver to open gaping holes in the kernel/user barrier, I see it as a step forward. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-10 22:19 ` Dave Airlie 2005-01-11 0:54 ` Matt Mackall @ 2005-01-11 16:10 ` Alan Cox 1 sibling, 0 replies; 222+ messages in thread From: Alan Cox @ 2005-01-11 16:10 UTC (permalink / raw) To: Dave Airlie; +Cc: John Richard Moser, znmeb, Linux Kernel Mailing List On Llu, 2005-01-10 at 22:19, Dave Airlie wrote: > kernel/userspace solution, and one is of little use without the other, > if the kernel one is GPL and userspace one is closed source how do > people sit with it? (uneasy?) It would achieve nothing. It would still be undebuggable. We are far better with the current R300 reverse engineering project until such a point as ATI decide that R300 isn't valuable intellectual property any more and will provide more information. In many ways DRI is already superior on the older R2xx cards - it'll play quake 3 without the computer crashing. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 @ 2005-01-04 16:07 Indrek Kruusa 0 siblings, 0 replies; 222+ messages in thread From: Indrek Kruusa @ 2005-01-04 16:07 UTC (permalink / raw) To: linux-kernel; +Cc: viro On 4 Jan 2005, at 07:36, Al Viro wrote: > On Tue, Jan 04, 2005 at 06:46:49AM +0100, Willy Tarreau wrote: > > On Mon, Jan 03, 2005 at 10:14:42PM +0000, Christoph Hellwig wrote: > > > > Gosh! I bought an ATI video card, I bought a VMware license, etc.... I > > > > want to keep using them. Changing a "stable" kernel will continuously > > > > annoy users and vendors. > > > > > > So buy some Operating System that supports the propritary software of > > > your choice but stop annoying us. > > > > That's what he did. But it was not written in the notice that it could stop > > working at any time :-) > > > Do you want a long list of message-IDs going way, way back? Ones of Linus' > postings saying that there never had been any promise whatsoever of in-kernel > interfaces staying unchanged... Eh? "you should avoid Linux - experimental project indeed!". Sad, but this is almost true already: can you name the stable version of the kernel which is in main public use? When I take a look from distros then: Mandrake 10.2 snapshot (Cooker): kernel-2.6.8.1.20mdk-1-1mdk.i586.rpm SuSe (SRPM for new 9.2): kernel-source-2.6.8-24.src.rpm Fedora (update for FC3): kernel-2.6.9-1.724_FC3.i686.rpm And inside proper .src.rpm-s are lot of stuff. So how those fixes inside 2.6.10 will reach the end-user? 2.6.[x < 10] + patch+patch+patch... It means that for end user (me) the stable kernel 2.6.10 is not just usable. And of course I will not test any vanilla kernel because my MIDI programs-devices/USB gadgets/connect+point+and+click will usually stop working by reasons which are not bug but implementation related. So what I should report to my distro provider? Please recode this program because i am keen to test newest kernel? But how then should I provide my help with kernel testing? Maybe you need to set up a pool of patches with full detailed information: - bug fixes - security related fixes - feature changes - status flag: test/stable - dependencies :) This is what is needed - how and when a 2.6.x stable kernel will have released (strategy of kernel development) is not a question at all. Vanilla kernel will never reach end-users anyway. OK, don't take it too seriously :) regards, Indrek ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 @ 2005-01-07 11:07 Nicolas Mailhot 2005-01-07 11:15 ` Christoph Hellwig 0 siblings, 1 reply; 222+ messages in thread From: Nicolas Mailhot @ 2005-01-07 11:07 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 673 bytes --] Hi all, Since 2.6 is turning into a continuous release, how about just taking the last 2.6 release every six months and backport security fixes to it for the next half year ? This seems what distributions are starting to do with 2.6 anyway, the only thing they need is some sort of agreement on the stabilization fork dates so they can share the fix pool work (and add whatever value-added enhancements they want over the result). ie stable kernel releases used to be feature-driven but major OSS projects like GNOME have shown you could/should do date-driven releases once you got to the continuous development stage. Regards, -- Nicolas Mailhot [-- Attachment #2: Ceci est une partie de message numériquement signée --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 11:07 Nicolas Mailhot @ 2005-01-07 11:15 ` Christoph Hellwig 2005-01-07 11:17 ` Christoph Hellwig 2005-01-10 21:32 ` Bill Davidsen 0 siblings, 2 replies; 222+ messages in thread From: Christoph Hellwig @ 2005-01-07 11:15 UTC (permalink / raw) To: Nicolas Mailhot; +Cc: linux-kernel, debian-kernel On Fri, Jan 07, 2005 at 12:07:33PM +0100, Nicolas Mailhot wrote: > Hi all, > > Since 2.6 is turning into a continuous release, how about just taking > the last 2.6 release every six months and backport security fixes to it > for the next half year ? Half a year is far too long because hardware is changing to fast for that. Three month sounds like a much better idea. The real problem is that this is a really time-consuming issue, so there need to be people actually commited to doing this kind of thing. Andres Salomon from the Debian Kernel maintaince team has been thinking about such a bugfix tree, but he's worried about having the time to actually get the work done - and we know what we're talking about as we're trying to keep a properly fixed 2.6.8 tree for Debian sarge. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 11:15 ` Christoph Hellwig @ 2005-01-07 11:17 ` Christoph Hellwig 2005-01-07 17:34 ` John Richard Moser 2005-01-10 21:32 ` Bill Davidsen 1 sibling, 1 reply; 222+ messages in thread From: Christoph Hellwig @ 2005-01-07 11:17 UTC (permalink / raw) To: Nicolas Mailhot, linux-kernel, debian-kernel [wrong cc list last time] On Fri, Jan 07, 2005 at 11:15:08AM +0000, Christoph Hellwig wrote: > On Fri, Jan 07, 2005 at 12:07:33PM +0100, Nicolas Mailhot wrote: > > Hi all, > > > > Since 2.6 is turning into a continuous release, how about just taking > > the last 2.6 release every six months and backport security fixes to it > > for the next half year ? > > Half a year is far too long because hardware is changing to fast for that. > Three month sounds like a much better idea. > > The real problem is that this is a really time-consuming issue, so > there need to be people actually commited to doing this kind of thing. > > Andres Salomon from the Debian Kernel maintaince team has been thinking > about such a bugfix tree, but he's worried about having the time to > actually get the work done - and we know what we're talking about as > we're trying to keep a properly fixed 2.6.8 tree for Debian sarge. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ---end quoted text--- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 11:17 ` Christoph Hellwig @ 2005-01-07 17:34 ` John Richard Moser 2005-01-08 15:45 ` Alan Cox 0 siblings, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-07 17:34 UTC (permalink / raw) Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My scheme involved a 6 month release cycle supporting kernels with bugfixes for the prior 18 months (3 releases), though if you're really committed to hardware driver backporting, I guess it can be done in the actiwve "Stable" branch. I really don't like the idea of driver backporting to maintain a supported tree because A) sometimes drivers can't work without invasive changes (reiser4); and B) somebody has to do the backporting, which means somebody may be facing an assload of extra work. The last 6 paragraphs of [1] sketch it out fine; though the whole article was pretty much geared towards discussing the Linux Kernel development model. I just want a development model that makes everyone happy. I don't want to load up maintainers with a billion hours of backporting; but I don't want to load distributors with excess work either. Other interesting variations would be to allow driver backporting for uninvasive drivers, via third party support. The maintainer would have to merge drivers into the stable kernel; but it would be up to other OSS developers (i.e. distributions most likely) to supply those backports. This would distribute the work. Oh well, what do I know? :) [1] http://woct-blog.blogspot.com/2005/01/finally-new-pax.html Christoph Hellwig wrote: | [wrong cc list last time] | | On Fri, Jan 07, 2005 at 11:15:08AM +0000, Christoph Hellwig wrote: | |>On Fri, Jan 07, 2005 at 12:07:33PM +0100, Nicolas Mailhot wrote: |> |>>Hi all, |>> |>>Since 2.6 is turning into a continuous release, how about just taking |>>the last 2.6 release every six months and backport security fixes to it |>>for the next half year ? |> |>Half a year is far too long because hardware is changing to fast for that. |>Three month sounds like a much better idea. |> |>The real problem is that this is a really time-consuming issue, so |>there need to be people actually commited to doing this kind of thing. |> |>Andres Salomon from the Debian Kernel maintaince team has been thinking |>about such a bugfix tree, but he's worried about having the time to |>actually get the work done - and we know what we're talking about as |>we're trying to keep a properly fixed 2.6.8 tree for Debian sarge. |> |>- |>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in |>the body of a message to majordomo@vger.kernel.org |>More majordomo info at http://vger.kernel.org/majordomo-info.html |>Please read the FAQ at http://www.tux.org/lkml/ | | ---end quoted text--- | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3sfMhDd4aOud5P8RAnKIAJ0YatkLwCSP9/69aavUBjI7Rxi9RgCfUfB0 X2vS+7BKGJyr2O4X3PWmpXM= =kbdb -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 17:34 ` John Richard Moser @ 2005-01-08 15:45 ` Alan Cox 2005-01-11 7:17 ` John Richard Moser 0 siblings, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-08 15:45 UTC (permalink / raw) To: John Richard Moser; +Cc: Linux Kernel Mailing List On Gwe, 2005-01-07 at 17:34, John Richard Moser wrote: > My scheme involved a 6 month release cycle supporting kernels with > bugfixes for the prior 18 months (3 releases), though if you're really > committed to hardware driver backporting, I guess it can be done in the > actiwve "Stable" branch. 18 months is as good as supporting a seperate product line. Also you forgot to provide the engineering resources for your plan and to fund them 8) > to load up maintainers with a billion hours of backporting; but I don't > want to load distributors with excess work either. Distributors get paid by their customers to do the long term backporting and careful change control for big business. We take it as given that its -our- problem not the software developers. ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-08 15:45 ` Alan Cox @ 2005-01-11 7:17 ` John Richard Moser 2005-01-11 16:10 ` Alan Cox 0 siblings, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-11 7:17 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: | On Gwe, 2005-01-07 at 17:34, John Richard Moser wrote: | |>My scheme involved a 6 month release cycle supporting kernels with |>bugfixes for the prior 18 months (3 releases), though if you're really |>committed to hardware driver backporting, I guess it can be done in the |>actiwve "Stable" branch. | | | 18 months is as good as supporting a seperate product line. Also you | forgot to provide the engineering resources for your plan and to fund | them 8) | | Hello?? The latest 2.0 version of the Linux kernel is: 2.0.40 2004-02-08 07:13 UTC F V VI Changelog You have FOUR. 2.6, 2.4, 2.2, 2.0 In my scheme it's time to let go of 2.0; support moves to 2.6, 2.4, 2.2. ~ Development goes to 2.7, in the same way the 2.6 model is done now (so that it's always usable and needs no feature freeze etc before release). ~ In 6 months, 2.2 support is dropped, support moves to 2.8, 2.4, 2.2 with development on 2.9. Support includes bugfixes (security and otherwise) only. Quick observation |>to load up maintainers with a billion hours of backporting; but I don't |>want to load distributors with excess work either. | | | Distributors get paid by their customers to do the long term backporting | and careful change control for big business. We take it as given that | its -our- problem not the software developers. | | | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB432fhDd4aOud5P8RAqJ4AKCAEBgs7uUpQ7bTN+nI4gHWAoFfTwCfQemK D5/IotiX+cunDFHCzhqKFkQ= =ZBc/ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-11 7:17 ` John Richard Moser @ 2005-01-11 16:10 ` Alan Cox 2005-01-11 17:36 ` John Richard Moser 0 siblings, 1 reply; 222+ messages in thread From: Alan Cox @ 2005-01-11 16:10 UTC (permalink / raw) To: John Richard Moser; +Cc: Linux Kernel Mailing List On Maw, 2005-01-11 at 07:17, John Richard Moser wrote: > Hello?? > > The latest 2.0 version of the Linux kernel is: 2.0.40 2004-02-08 > 07:13 UTC F V VI Changelog > > You have FOUR. 2.6, 2.4, 2.2, 2.0 2.4.29 is as different from say 2.4.9 as 2.0 is from 2.2 or 2.6.9 from 2.6.5 You have a lot more than four ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-11 16:10 ` Alan Cox @ 2005-01-11 17:36 ` John Richard Moser 2005-01-11 19:59 ` Bernd Eckenfels 0 siblings, 1 reply; 222+ messages in thread From: John Richard Moser @ 2005-01-11 17:36 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: | On Maw, 2005-01-11 at 07:17, John Richard Moser wrote: | |>Hello?? |> |>The latest 2.0 version of the Linux kernel is: 2.0.40 2004-02-08 |>07:13 UTC F V VI Changelog |> |>You have FOUR. 2.6, 2.4, 2.2, 2.0 | | | 2.4.29 is as different from say 2.4.9 as 2.0 is from 2.2 or 2.6.9 from | 2.6.5 | | You have a lot more than four | That's not good. 2.4.29 should ideally be 2.4.9 with a buttload of bug fixes. Same with 2.6.5/2.6.9. Major feature differences should ideally come with majors, i.e. 2.0->2.2->2.4->2.6 A few bugfix backports may be fine, though that's already light to fair work (depending on how many security bugs are being found and need backporting, versus how many can patch clean without porting); How do you people maintain 4 ACTIVE branches? oi, whatever. | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5A6dhDd4aOud5P8RAhAtAJ9FgTkd/AyZXuI59gyiIVAJNFM9rgCdGYss kN4m4Bc5BVeVLZbWGHIP+xg= =hDM/ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-11 17:36 ` John Richard Moser @ 2005-01-11 19:59 ` Bernd Eckenfels 0 siblings, 0 replies; 222+ messages in thread From: Bernd Eckenfels @ 2005-01-11 19:59 UTC (permalink / raw) To: linux-kernel In article <41E40E9D.9090502@comcast.net> you wrote: > A few bugfix backports may be fine, though that's already light to fair > work (depending on how many security bugs are being found and need > backporting, versus how many can patch clean without porting); How do > you people maintain 4 ACTIVE branches? Because those people are many, and as long as there are volunteers to maintain a branch, nobody can stop them from doing so. BTW: I generally agree with you, that adding features should be limited. However stuff like new drivers or subsystems which have their own lifecylce and small impact are added to stable just because the innovations are needed by the users (most often because of new hardware or generally more stability or performance) Bernd ^ permalink raw reply [flat|nested] 222+ messages in thread
* Re: starting with 2.7 2005-01-07 11:15 ` Christoph Hellwig 2005-01-07 11:17 ` Christoph Hellwig @ 2005-01-10 21:32 ` Bill Davidsen 1 sibling, 0 replies; 222+ messages in thread From: Bill Davidsen @ 2005-01-10 21:32 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Nicolas Mailhot, linux-kernel, debian-kernel Christoph Hellwig wrote: > On Fri, Jan 07, 2005 at 12:07:33PM +0100, Nicolas Mailhot wrote: > >>Hi all, >> >>Since 2.6 is turning into a continuous release, how about just taking >>the last 2.6 release every six months and backport security fixes to it >>for the next half year ? > > > Half a year is far too long because hardware is changing to fast for that. > Three month sounds like a much better idea. > > The real problem is that this is a really time-consuming issue, so > there need to be people actually commited to doing this kind of thing. > > Andres Salomon from the Debian Kernel maintaince team has been thinking > about such a bugfix tree, but he's worried about having the time to > actually get the work done - and we know what we're talking about as > we're trying to keep a properly fixed 2.6.8 tree for Debian sarge. Several of us have suggested that only security fixes and fixes for bugs which resulting in crashes, hangs, filesystem damage and the like be backported to the 2.6.N until 2.6.N+1 is released. No new drivers, schedulers (unless the old one breaks), just fixes. While this would work better with more frequent stable releases, the number of things in any given kernel which are actually broken is usually quite small, the bulk seem to be new features and "works better" patch sets. I suspect that you are doing far more than bug fixes in your tree, which is admirable, but adds a LOT of work! -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 222+ messages in thread
end of thread, other threads:[~2005-01-11 20:00 UTC | newest] Thread overview: 222+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-02 20:03 starting with 2.7 Maciej Soltysiak 2005-01-02 20:08 ` Emmanuel Fleury 2005-01-02 20:36 ` William Lee Irwin III 2005-01-02 21:01 ` Re[2]: " Maciej Soltysiak 2005-01-02 21:24 ` Andries Brouwer 2005-01-02 21:42 ` William Lee Irwin III 2005-01-02 22:15 ` Adrian Bunk 2005-01-02 22:49 ` Bill Davidsen 2005-01-02 23:14 ` Jesper Juhl 2005-01-03 0:30 ` William Lee Irwin III 2005-01-03 0:45 ` Adrian Bunk 2005-01-03 1:19 ` William Lee Irwin III 2005-01-03 5:33 ` Willy Tarreau 2005-01-03 12:33 ` William Lee Irwin III 2005-01-03 21:38 ` Willy Tarreau 2005-01-03 22:09 ` William Lee Irwin III 2005-01-03 23:53 ` Bill Davidsen 2005-01-04 5:06 ` Alexander E. Patrakov 2005-01-04 5:29 ` Sean 2005-01-05 8:42 ` Andrew Morton 2005-01-05 9:13 ` Alexander E. Patrakov 2005-01-04 13:17 ` Horst von Brand 2005-01-03 13:24 ` Diego Calleja 2005-01-03 13:47 ` Adrian Bunk 2005-01-03 17:18 ` Bill Davidsen 2005-01-03 18:04 ` Adrian Bunk 2005-01-03 18:41 ` Bill Davidsen 2005-01-03 18:36 ` Theodore Ts'o 2005-01-03 18:59 ` Russell King 2005-01-03 19:07 ` William Lee Irwin III 2005-01-03 19:26 ` Randy.Dunlap 2005-01-03 21:06 ` Alan Cox 2005-01-04 0:24 ` Theodore Ts'o 2005-01-04 3:12 ` Thomas Graf 2005-01-04 5:33 ` Willy Tarreau 2005-01-04 15:21 ` Adrian Bunk 2005-01-04 15:58 ` William Lee Irwin III 2005-01-04 17:38 ` Bernd Eckenfels 2005-01-04 23:51 ` Bill Davidsen 2005-01-05 0:09 ` William Lee Irwin III 2005-01-05 18:30 ` Bill Davidsen 2005-01-05 18:56 ` William Lee Irwin III 2005-01-05 19:08 ` Chris Friesen 2005-01-04 15:34 ` Horst von Brand 2005-01-04 21:19 ` Theodore Ts'o 2005-01-04 21:43 ` Willy Tarreau 2005-01-04 23:50 ` Gene Heskett 2005-01-05 5:37 ` Willy Tarreau 2005-01-05 7:04 ` Gene Heskett 2005-01-05 8:33 ` Alexander E. Patrakov 2005-01-06 18:08 ` Paul Rolland 2005-01-06 21:08 ` Bill Davidsen 2005-01-06 22:50 ` Gene Heskett 2005-01-07 14:34 ` Paul Rolland 2005-01-05 0:00 ` Bill Davidsen 2005-01-05 0:33 ` Theodore Ts'o 2005-01-05 18:40 ` Bill Davidsen 2005-01-03 21:13 ` Horst von Brand 2005-01-03 21:35 ` Jesper Juhl 2005-01-04 0:02 ` Bill Davidsen 2005-01-04 3:32 ` Gene Heskett 2005-01-05 9:27 ` Andrew Morton 2005-01-05 10:57 ` Barry K. Nathan 2005-01-06 3:15 ` Ed Tomlinson 2005-01-06 14:03 ` Paolo Ciarrocchi 2005-01-06 16:34 ` Ramón Rey Vicente 2005-01-06 19:32 ` Adrian Bunk 2005-01-06 19:58 ` Diego Calleja 2005-01-06 22:31 ` Bill Davidsen 2005-01-07 8:33 ` Paolo Ciarrocchi 2005-01-06 20:48 ` Bill Davidsen 2005-01-03 19:28 ` Jens Axboe 2005-01-03 22:39 ` Bill Davidsen 2005-01-04 7:46 ` Jens Axboe 2005-01-04 18:34 ` Bill Davidsen 2005-01-03 21:03 ` Horst von Brand 2005-01-03 23:42 ` Bill Davidsen 2005-01-04 17:31 ` Rahul Karnik 2005-01-04 18:44 ` Bill Davidsen 2005-01-04 21:04 ` Pavel Machek 2005-01-04 21:28 ` Bill Davidsen 2005-01-04 21:51 ` APM vs. ACPI, janitor wanted? [was Re: starting with 2.7] Pavel Machek 2005-01-04 12:57 ` starting with 2.7 William Lee Irwin III 2005-01-04 15:08 ` Adrian Bunk 2005-01-04 15:34 ` William Lee Irwin III 2005-01-04 16:53 ` Adrian Bunk 2005-01-04 19:57 ` William Lee Irwin III 2005-01-04 20:30 ` Willy Tarreau 2005-01-04 20:34 ` Adrian Bunk 2005-01-04 20:55 ` William Lee Irwin III 2005-01-04 21:23 ` Bill Davidsen 2005-01-04 22:01 ` Andries Brouwer 2005-01-04 21:01 ` Theodore Ts'o 2005-01-06 9:45 ` Marcelo Tosatti 2005-01-06 15:50 ` Theodore Ts'o 2005-01-06 16:59 ` William Lee Irwin III 2005-01-06 14:38 ` Marcelo Tosatti 2005-01-04 20:17 ` Willy Tarreau 2005-01-05 0:02 ` Alan Cox 2005-01-05 5:49 ` Willy Tarreau 2005-01-04 2:06 ` Roman Zippel 2005-01-04 2:36 ` Paolo Ciarrocchi 2005-01-03 12:52 ` Bill Davidsen 2005-01-03 15:52 ` Alan Cox 2005-01-03 17:15 ` Jeff V. Merkey 2005-01-02 23:14 ` Diego Calleja 2005-01-02 23:21 ` Dr. David Alan Gilbert 2005-01-03 9:57 ` Reviving the concept of a stable series (was Re: starting with 2.7) L. A. Walsh 2005-01-03 12:17 ` Robert W. Fuller 2005-01-03 13:58 ` Adrian Bunk 2005-01-03 14:24 ` Horst von Brand 2005-01-04 4:56 ` David Lang 2005-01-04 14:52 ` Adrian Bunk 2005-01-04 7:00 ` Eric W. Biederman 2005-01-09 0:13 ` Reviving the concept of a stable series L A Walsh 2005-01-10 13:44 ` Adam Sampson 2005-01-10 16:50 ` Horst von Brand 2005-01-10 19:24 ` Alan Cox 2005-01-10 20:50 ` jmerkey 2005-01-03 22:20 ` Reviving the concept of a stable series (was Re: starting with 2.7) Bill Davidsen 2005-01-04 13:08 ` William Lee Irwin III 2005-01-04 18:20 ` Dave Jones 2005-01-06 15:31 ` Barry K. Nathan 2005-01-06 18:23 ` [PATCH] zap the ACPI shutdown bug (was Re: Reviving the concept of a stable series) Barry K. Nathan 2005-01-06 19:07 ` Dave Jones 2005-01-06 21:19 ` Bill Davidsen 2005-01-03 0:19 ` starting with 2.7 William Lee Irwin III 2005-01-03 0:38 ` Adrian Bunk 2005-01-03 0:49 ` Adam Mercer 2005-01-03 1:20 ` William Lee Irwin III 2005-01-03 12:13 ` Steven Rostedt 2005-01-03 1:21 ` William Lee Irwin III 2005-01-03 22:26 ` Bill Davidsen 2005-01-03 15:20 ` Rik van Riel 2005-01-03 15:29 ` Adrian Bunk 2005-01-03 15:37 ` William Lee Irwin III 2005-01-03 17:39 ` Felipe Alfaro Solana 2005-01-03 20:59 ` Horst von Brand 2005-01-03 21:47 ` Felipe Alfaro Solana 2005-01-03 21:48 ` Rik van Riel 2005-01-03 22:03 ` Felipe Alfaro Solana 2005-01-03 22:10 ` Rik van Riel 2005-01-03 22:14 ` Christoph Hellwig 2005-01-03 23:41 ` Felipe Alfaro Solana 2005-01-04 5:46 ` Willy Tarreau 2005-01-04 6:36 ` Al Viro 2005-01-04 10:23 ` Felipe Alfaro Solana 2005-01-04 12:36 ` Rik van Riel 2005-01-04 12:59 ` Felipe Alfaro Solana 2005-01-04 20:09 ` Willy Tarreau 2005-01-04 20:17 ` William Lee Irwin III 2005-01-05 6:20 ` Alexander E. Patrakov 2005-01-05 11:30 ` Christoph Hellwig 2005-01-04 20:24 ` Horst von Brand 2005-01-05 13:31 ` Helge Hafting 2005-01-05 19:16 ` Bill Davidsen 2005-01-05 21:19 ` Felipe Alfaro Solana 2005-01-04 9:17 ` Bernd Petrovitsch 2005-01-04 13:27 ` Horst von Brand 2005-01-04 14:27 ` Felipe Alfaro Solana 2005-01-04 15:31 ` Rik van Riel 2005-01-04 16:51 ` Felipe Alfaro Solana 2005-01-04 20:58 ` Horst von Brand 2005-01-04 23:07 ` Felipe Alfaro Solana 2005-01-04 23:18 ` Rik van Riel 2005-01-04 22:04 ` Alan Cox 2005-01-03 22:01 ` Sean 2005-01-04 5:44 ` Willy Tarreau 2005-01-04 13:11 ` William Lee Irwin III 2005-01-03 23:21 ` Bill Davidsen 2005-01-03 18:18 ` Wakko Warner 2005-01-03 23:06 ` Bill Davidsen 2005-01-03 15:18 ` Rik van Riel 2005-01-03 15:34 ` Adrian Bunk 2005-01-03 15:46 ` William Lee Irwin III 2005-01-03 15:59 ` Arjan van de Ven 2005-01-03 23:34 ` Bill Davidsen 2005-01-04 7:42 ` Arjan van de Ven 2005-01-04 13:14 ` William Lee Irwin III 2005-01-04 17:47 ` Adrian Bunk 2005-01-04 20:18 ` David Lang 2005-01-04 23:03 ` Felipe Alfaro Solana 2005-01-05 7:39 ` Arjan van de Ven 2005-01-06 19:35 ` Adrian Bunk 2005-01-06 23:33 ` Daniel Gryniewicz 2005-01-07 1:51 ` David Lang 2005-01-07 5:48 ` John Richard Moser 2005-01-03 22:53 ` Bill Davidsen 2005-01-06 3:52 ` Ian Kent 2005-01-06 20:02 ` John Richard Moser 2005-01-06 21:29 ` Alan Cox 2005-01-07 0:06 ` John Richard Moser 2005-01-07 16:34 ` M. Edward Borasky 2005-01-07 17:25 ` John Richard Moser 2005-01-09 2:31 ` M. Edward Borasky 2005-01-09 3:01 ` Valdis.Kletnieks 2005-01-09 3:08 ` John Richard Moser 2005-01-09 23:02 ` Alan Cox 2005-01-10 0:30 ` John Richard Moser 2005-01-10 1:26 ` Indrek Kruusa 2005-01-10 1:28 ` Dave Airlie 2005-01-10 2:16 ` John Richard Moser 2005-01-10 4:51 ` Gene Heskett 2005-01-10 18:27 ` Alan Cox 2005-01-10 20:11 ` Andi Kleen 2005-01-10 19:55 ` Alan Cox 2005-01-10 21:08 ` Andi Kleen 2005-01-11 16:10 ` Alan Cox 2005-01-10 22:19 ` Dave Airlie 2005-01-11 0:54 ` Matt Mackall 2005-01-11 16:10 ` Alan Cox 2005-01-04 16:07 Indrek Kruusa 2005-01-07 11:07 Nicolas Mailhot 2005-01-07 11:15 ` Christoph Hellwig 2005-01-07 11:17 ` Christoph Hellwig 2005-01-07 17:34 ` John Richard Moser 2005-01-08 15:45 ` Alan Cox 2005-01-11 7:17 ` John Richard Moser 2005-01-11 16:10 ` Alan Cox 2005-01-11 17:36 ` John Richard Moser 2005-01-11 19:59 ` Bernd Eckenfels 2005-01-10 21:32 ` Bill Davidsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).