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
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: [email protected]
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
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
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
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
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
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
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
El Sun, 2 Jan 2005 23:15:34 +0100 Adrian Bunk <[email protected]> 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?
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 |_______/
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
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
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
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
On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <[email protected]> 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
On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <[email protected]> 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
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
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
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
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.
>
>
On Mon, 2005-01-03 at 00:49 +0000, Adam Mercer wrote:
> On Mon, 3 Jan 2005 01:38:58 +0100, Adrian Bunk <[email protected]> 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
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*
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
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
El Mon, 3 Jan 2005 06:33:04 +0100 Willy Tarreau <[email protected]> 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.
On Mon, Jan 03, 2005 at 02:24:12PM +0100, Diego Calleja wrote:
> El Mon, 3 Jan 2005 06:33:04 +0100 Willy Tarreau <[email protected]> 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
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
"L. A. Walsh" <[email protected]> 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
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
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
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
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
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
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
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*.
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.
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 [email protected]
>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
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.
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 <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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
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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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
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
Felipe Alfaro Solana <[email protected]> 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
Bill Davidsen <[email protected]> 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
"Theodore Ts'o" <[email protected]> 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
On Mon, 3 Jan 2005, Horst von Brand wrote:
> "Theodore Ts'o" <[email protected]> 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
On 3 Jan 2005, at 21:59, Horst von Brand wrote:
> Felipe Alfaro Solana <[email protected]> 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.
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
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
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 <[email protected]> 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
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.
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
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
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
> 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.
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Mon, 3 Jan 2005, Horst von Brand wrote:
> Bill Davidsen <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
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
On Mon, 3 Jan 2005, Jesper Juhl wrote:
> On Mon, 3 Jan 2005, Horst von Brand wrote:
>
> > "Theodore Ts'o" <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
On Tue, 4 Jan 2005 03:06:25 +0100, Roman Zippel <[email protected]> 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
* Theodore Ts'o <[email protected]> 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.
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.
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
On Mon, 3 Jan 2005, Horst von Brand wrote:
> "L. A. Walsh" <[email protected]> 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
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
On Tue, Jan 04, 2005 at 04:12:29AM +0100, Thomas Graf wrote:
> * Theodore Ts'o <[email protected]> 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
On Mon, Jan 03, 2005 at 05:59:24PM -0300, Horst von Brand wrote:
> Felipe Alfaro Solana <[email protected]> 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
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
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.
Horst von Brand <[email protected]> writes:
> "L. A. Walsh" <[email protected]> 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
> > 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.
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
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
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.
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
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.
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
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
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
Willy Tarreau <[email protected]> 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
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
Felipe Alfaro Solana <[email protected]> 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
On 4 Jan 2005, at 14:27, Horst von Brand wrote:
> Felipe Alfaro Solana <[email protected]> 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.
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" <[email protected]> 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
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
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 <[email protected]> 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
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
Thomas Graf <[email protected]> said:
> * Theodore Ts'o <[email protected]> 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
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
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
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
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 :-)
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
On Mon, 3 Jan 2005 18:42:24 -0500 (EST), Bill Davidsen <[email protected]> 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.
In article <[email protected]> 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
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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 4 Jan 2005, Rahul Karnik wrote:
> On Mon, 3 Jan 2005 18:42:24 -0500 (EST), Bill Davidsen <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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
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
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
Felipe Alfaro Solana <[email protected]> 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
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 <[email protected]>
> To: Arjan van de Ven <[email protected]>
> Cc: Rik van Riel <[email protected]>, Andries Brouwer <[email protected]>,
> William Lee Irwin III <[email protected]>,
> Maciej Soltysiak <[email protected]>, [email protected]
> 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 [email protected]
> 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
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
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
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
Felipe Alfaro Solana <[email protected]> said:
> On 4 Jan 2005, at 14:27, Horst von Brand wrote:
> > Felipe Alfaro Solana <[email protected]> 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
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
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!
On Tue, Jan 04, 2005 at 12:34:09PM -0300, Horst von Brand wrote:
> Thomas Graf <[email protected]> said:
> > * Theodore Ts'o <[email protected]> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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
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!
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.
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
On 4 Jan 2005, at 21:58, Horst von Brand wrote:
> Felipe Alfaro Solana <[email protected]> said:
>> On 4 Jan 2005, at 14:27, Horst von Brand wrote:
>>> Felipe Alfaro Solana <[email protected]> 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.
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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.
Theodore Ts'o wrote:
> On Tue, Jan 04, 2005 at 12:34:09PM -0300, Horst von Brand wrote:
>
>>Thomas Graf <[email protected]> said:
>>
>>>* Theodore Ts'o <[email protected]> 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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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
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
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
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
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
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
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.
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.
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
"Alexander E. Patrakov" <[email protected]> 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.
Andrew Morton wrote:
> "Alexander E. Patrakov" <[email protected]> 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
Horst von Brand <[email protected]> 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.
On Wed, Jan 05, 2005 at 01:27:09AM -0800, Andrew Morton wrote:
> Horst von Brand <[email protected]> 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 <[email protected]>
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.
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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.
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 <[email protected]> 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
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
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.
On Mon, 3 Jan 2005 13:36:21 -0500, Theodore Ts'o <[email protected]> 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
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 <[email protected]>
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
-----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 [email protected] - 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-----
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
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.
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.
(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 <[email protected]>
--- 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
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 <[email protected]>
>
> --- 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
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
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
-----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 [email protected]
| 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-----
El Thu, 6 Jan 2005 20:32:14 +0100 Adrian Bunk <[email protected]> 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.
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 <[email protected]>, 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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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.
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.
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
-----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-----
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
-----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-----
On Thu, 06 Jan 2005 17:31:46 -0500, Bill Davidsen <[email protected]> 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: http://www.ciarrocchi.tk
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
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.
[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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
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
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. :)
-----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 [email protected]
| 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-----
-----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 [email protected]
|>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 [email protected]
| 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-----
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.
Horst von Brand wrote:
>"L. A. Walsh" <[email protected]> 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
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?
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 (http://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.
-----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-----
> 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.
-----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-----
>
> 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
> 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.
-----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-----
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 [email protected]
>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.
L A Walsh <[email protected]> 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 <[email protected]> <http://offog.org/>
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)
Alan Cox <[email protected]> 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
On Llu, 2005-01-10 at 13:44, Adam Sampson wrote:
> L A Walsh <[email protected]> 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.
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
>
>
On Llu, 2005-01-10 at 20:11, Andi Kleen wrote:
> Alan Cox <[email protected]> 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.
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 <[email protected]> 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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
> 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.
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.
-----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-----
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 <[email protected]> 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.
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.
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
-----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-----
In article <[email protected]> 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