This may come a bit late now, since the "new development model" was
put through late this summer.
But anyway i'm going to come with som thoughts about it.
I think that 2.6 should be frozen from now on, just security related
stuff should be merged.
This would strengthen Linux's reputation as a stable and secure
system, not a unstable and a system just used for fun.
A 2.7 should be created where all new experimental stuff is merged
into it, and where people could begin to think new again.
New thoughts are good in all ways, it is for sure very much code in
the current kernels that should be revised, rewritten and maybe marked
as deprecated.
:)
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
This may come a bit late now, since the "new development model" was
put through late this summer.
But anyway i'm going to come with som thoughts about it.
I think that 2.6 should be frozen from now on, just security related
stuff should be merged.
This would strengthen Linux's reputation as a stable and secure
system, not a unstable and a system just used for fun.
A 2.7 should be created where all new experimental stuff is merged
into it, and where people could begin to think new again.
New thoughts are good in all ways, it is for sure very much code in
the current kernels that should be revised, rewritten and maybe marked
as deprecated.
:)
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/23/2004 06:52 AM, Espen Fjellv?r Olsen wrote:
> A 2.7 should be created where all new experimental stuff is merged
> into it, and where people could begin to think new again.
> New thoughts are good in all ways, it is for sure very much code in
> the current kernels that should be revised, rewritten and maybe marked
> as deprecated.
I absolutly agree. There is still too much experimental going on in a
stable series that goes to a .10 release ...
But well, 2.4 was usable after .10, so lets not rush to fast :)
lg, clemens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBeYXQjBz/yQjBxz8RAkHWAKCFQv9/2i+0nrmKHiYnjNp5dVmUKACg4x/9
M82d/+D8TYb6XBKamu/kcGM=
=qbBB
-----END PGP SIGNATURE-----
On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
> This may come a bit late now, since the "new development model" was
> put through late this summer.
> But anyway i'm going to come with som thoughts about it.
> I think that 2.6 should be frozen from now on, just security related
> stuff should be merged.
> This would strengthen Linux's reputation as a stable and secure
> system, not a unstable and a system just used for fun.
> A 2.7 should be created where all new experimental stuff is merged
> into it, and where people could begin to think new again.
> New thoughts are good in all ways, it is for sure very much code in
> the current kernels that should be revised, rewritten and maybe marked
> as deprecated.
> :)
We should write code, not blow release nomenclature smoke.
-- wli
On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
> I think that 2.6 should be frozen from now on, just security related
> stuff should be merged.
> This would strengthen Linux's reputation as a stable and secure
> system, not a unstable and a system just used for fun.
Linux already got its reputation of a stable system from its production
kernels, 2.0, 2.2 and 2.4 which are largely used in sensible environments.
2.6 is stable enough for most desktop usage and for end-users distros to
ship it by default. This will encourage many more people to test it, send
reports back and finally stabilize it so that one day it can finally be
used in production environments. At first I was a bit angry that it had
been declared "stable" a bit too early, but now, judging by the amount of
people who use it only because their distros ship with it, I realise that
indeed, it should have been declared "stable" earlier so that all the bug
fixes you see now would be fixed by now.
> A 2.7 should be created where all new experimental stuff is merged
> into it, and where people could begin to think new again.
This could be true if the release cycle was shorter. But once 2.7 comes
out, many developpers will only focus on their development and not on
stabilizing 2.6 as much as today.
Willy
On Fri, 2004-10-22 at 23:52 +0200, Espen Fjellv?r Olsen wrote:
> I think that 2.6 should be frozen from now on, just security related
> stuff should be merged.
> This would strengthen Linux's reputation as a stable and secure
> system, not a unstable and a system just used for fun.
My $0.02:
Part of the reasoning behind the new development model is that if you
want a stable kernel, there are many vendors who will give you one. The
new dev model is partially driven by vendors and developers desire to
get their features into mainline quicker. There is an inherent
stability cost associated with this, but the price is only paid by users
who want stability AND the latest kernel.org kernel. The big players
all seem to agree that the new development model better suits users and
their own needs. The distros are in a better position to determine what
constitutes a stable kernel anyway, they have millions of users to test
on. Let the vendors AND the kernel hackers do what they are each best
at.
We need to continue the rapid pace of development because although Linux
rules in the small to mid server arena there are other areas where MS
and Apple are clearly ahead. If you want to make an omelette you have
to break some eggs...
Lee
On Fri, 22 Oct 2004 15:45:40 -0700, William Lee Irwin III
<[email protected]> wrote:
>
> We should write code, not blow release nomenclature smoke.
>
>
> -- wli
>
I'm sorry i cant contribute with any code, i'm not skilled enough to
do such a job, yet.
The only way i can contribute is to do testing, a release need
testing, testing and testing :)
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
On Fri, Oct 22, 2004 at 06:58:24PM -0400, Lee Revell wrote:
> My $0.02:
> Part of the reasoning behind the new development model is that if you
> want a stable kernel, there are many vendors who will give you one. The
> new dev model is partially driven by vendors and developers desire to
> get their features into mainline quicker. There is an inherent
> stability cost associated with this, but the price is only paid by users
> who want stability AND the latest kernel.org kernel. The big players
> all seem to agree that the new development model better suits users and
> their own needs. The distros are in a better position to determine what
> constitutes a stable kernel anyway, they have millions of users to test
> on. Let the vendors AND the kernel hackers do what they are each best
> at.
I don't entirely follow these sorts of discussion, but this vaguely
disagrees with what I've heard in some nitpicky way. I believe it goes
something along the lines of absorbing more distro content on the
grounds that some of the larger variances of distro kernels have been
detrimental in the past or some such.
On Fri, Oct 22, 2004 at 06:58:24PM -0400, Lee Revell wrote:
> We need to continue the rapid pace of development because although Linux
> rules in the small to mid server arena there are other areas where MS
> and Apple are clearly ahead. If you want to make an omelette you have
> to break some eggs...
This is clearly economics and HCI; I'll refrain from comment myself but
hope someone knowledgable there chimes in, as this likely needs
qualification.
-- wli
On Sat, 2004-10-23 at 00:50 +0200, Espen Fjellv?r Olsen wrote:
> I'm sorry i cant contribute with any code, i'm not skilled enough to
> do such a job, yet.
> The only way i can contribute is to do testing, a release need
> testing, testing and testing :)
>
This is how testers become coders. Eventually you will find a problem
and figure out the answer before anyone responds to your bug report ;-)
--
Lee Revell <[email protected]>
On Sat, Oct 23, 2004 at 12:57:03AM +0200, Willy Tarreau wrote:
> On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
>...
> > A 2.7 should be created where all new experimental stuff is merged
> > into it, and where people could begin to think new again.
>
> This could be true if the release cycle was shorter. But once 2.7 comes
> out, many developpers will only focus on their development and not on
> stabilizing 2.6 as much as today.
2.6.9 -> 2.6.10-rc1:
- 4 days
- > 15 MB patches
It's a bit optimistic to call this amount of change "stabilizing".
2.6 is corrently more a development kernel than a stable kernel.
The last bug I observed personally was the problem with suspending when
using CONFIG_REGPARM=y together with Roland's waitid patch which was
added in 2.6.9-rc2. If I'd used 2.6.9 with the same .config as 2.6.8.1,
this was simple one more bug...
IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
(or someone else) should maintain a 2.6 tree with less changes (like
Marcelo did and does with 2.4).
> 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 Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
>> I think that 2.6 should be frozen from now on, just security related
>> stuff should be merged.
>> This would strengthen Linux's reputation as a stable and secure
>> system, not a unstable and a system just used for fun.
On Sat, Oct 23, 2004 at 12:57:03AM +0200, Willy Tarreau wrote:
> Linux already got its reputation of a stable system from its production
> kernels, 2.0, 2.2 and 2.4 which are largely used in sensible environments.
> 2.6 is stable enough for most desktop usage and for end-users distros to
> ship it by default. This will encourage many more people to test it, send
> reports back and finally stabilize it so that one day it can finally be
> used in production environments. At first I was a bit angry that it had
> been declared "stable" a bit too early, but now, judging by the amount of
> people who use it only because their distros ship with it, I realise that
> indeed, it should have been declared "stable" earlier so that all the bug
> fixes you see now would be fixed by now.
The freezes from kernels past led to gross redundancy. Distros all
froze at different points in time with numerous patches atop the
then-mainline release. The mainline freeze was meaningless because
the distros were all completely divorced from it, resulting in numerous
simultaneously frozen trees with no outlet for forward progress.
On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
>> A 2.7 should be created where all new experimental stuff is merged
>> into it, and where people could begin to think new again.
On Sat, Oct 23, 2004 at 12:57:03AM +0200, Willy Tarreau wrote:
> This could be true if the release cycle was shorter. But once 2.7 comes
> out, many developpers will only focus on their development and not on
> stabilizing 2.6 as much as today.
We aren't just stabilizing 2.6. We're moving it forward. Part of moving
forward is preventing backportmania depravity. Backporting is the root
of all evil.
-- wli
On Fri, 2004-10-22 at 17:09 -0700, William Lee Irwin III wrote:
> Backporting is the root of all evil.
LOL. This is very close to a favorite mantra of mine: Backwards
compatibility is the root of all evil.
Lee
On Fri, 2004-10-22 at 17:58, Lee Revell wrote:
> Part of the reasoning behind the new development model is that if you
> want a stable kernel, there are many vendors who will give you one.
Precisely what I was thinking:
Features pass a utility/sanity/style check to get into main line,
and vendors provide the polished/tuned package.
> If you want to make an omelette you have
> to break some eggs...
2.6.9 left a few shells on the floor ;-)
--
Paul Fulghum
[email protected]
On Fri, 22 Oct 2004 15:45:40 -0700, William Lee Irwin III wrote:
>> We should write code, not blow release nomenclature smoke.
On Sat, Oct 23, 2004 at 12:50:44AM +0200, Espen Fjellv?r Olsen wrote:
> I'm sorry i cant contribute with any code, i'm not skilled enough to
> do such a job, yet.
> The only way i can contribute is to do testing, a release need
> testing, testing and testing :)
Isn't this just what motivates what's in the next release? If the
patches weren't tested, why were they merged? Accidents can't be
anticipated. How long are you going to wait for one to happen?
Why expect one not to happen if you wait on the same code longer?
-- wli
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
> On Sat, Oct 23, 2004 at 12:57:03AM +0200, Willy Tarreau wrote:
> > On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
> >...
> > > A 2.7 should be created where all new experimental stuff is merged
> > > into it, and where people could begin to think new again.
> >
> > This could be true if the release cycle was shorter. But once 2.7 comes
> > out, many developpers will only focus on their development and not on
> > stabilizing 2.6 as much as today.
>
> 2.6.9 -> 2.6.10-rc1:
> - 4 days
> - > 15 MB patches
>
> It's a bit optimistic to call this amount of change "stabilizing".
>
> 2.6 is corrently more a development kernel than a stable kernel.
>
> The last bug I observed personally was the problem with suspending when
> using CONFIG_REGPARM=y together with Roland's waitid patch which was
> added in 2.6.9-rc2. If I'd used 2.6.9 with the same .config as 2.6.8.1,
> this was simple one more bug...
>
> IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
> (or someone else) should maintain a 2.6 tree with less changes (like
> Marcelo did and does with 2.4).
I don't ever want to plug anything I've written, but please see the
current issue of Linux Journal with an article explaining how this is
all working, why we are doing this, and how the hell we can keep sane
this way. I've also got slides on my website from the talk I've given
about this topic at OLS, OSCON, and SUCON about this topic.
In about a month or so, I'll be able to put the linux journal article up
on the web for everyone to see, need to let the publication restriction
expire first...
thanks,
greg k-h
Hi Adrian,
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
> 2.6.9 -> 2.6.10-rc1:
> - 4 days
> - > 15 MB patches
I firmly agree, and that's one of the reasons I still don't use 2.6. This
could be avoided with a shorter release cycle with far less new features
for each version (a bit like openbsd does), because about every maintainer
would have a valid base to work on for the next release or the one after,
and would not try to push unstable code in the "stable" kernel. Today, lots
of people are certain that 2.8 (or 3.0) won't be out before 3 or 4 years. So
if they want their code released soon, they push it hard in the current
mainline :-(
> It's a bit optimistic to call this amount of change "stabilizing".
What really frightens me is that judging from the changelogs, it really
looks like cleanups, bug fixes and sometimes core changes... This gives
a terrible idea of previous release code !
> 2.6 is corrently more a development kernel than a stable kernel.
That's how I present it to friends and customers too ;-) To others, I simply
say that it's the new stable kernel, and I observe how it works for them :-)
> The last bug I observed personally was the problem with suspending when
> using CONFIG_REGPARM=y together with Roland's waitid patch which was
> added in 2.6.9-rc2. If I'd used 2.6.9 with the same .config as 2.6.8.1,
> this was simple one more bug...
Each time I try a new release, I barely find it extremely slow and unstable,
and I don't know where to start from to report broken things... Unfortunately
I don't have enough time to spend on bug reports these days so I stick to a
stable 2.4.
> IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
> (or someone else) should maintain a 2.6 tree with less changes (like
> Marcelo did and does with 2.4).
Yes, but not until the core is stabilized. Otherwise, ever changing features
and exports will discourage driver maintainers from backporting fixes.
Willy
Am Saturday, 23. October 2004 00:58 schrieb Lee Revell:
> On Fri, 2004-10-22 at 23:52 +0200, Espen Fjellv?r Olsen wrote:
> > I think that 2.6 should be frozen from now on, just security related
> > stuff should be merged.
> > This would strengthen Linux's reputation as a stable and secure
> > system, not a unstable and a system just used for fun.
>
> My $0.02:
>
> Part of the reasoning behind the new development model is that if you
> want a stable kernel, there are many vendors who will give you one. The
I don't trust them :)
> new dev model is partially driven by vendors and developers desire to
> get their features into mainline quicker. There is an inherent
> stability cost associated with this, but the price is only paid by users
> who want stability AND the latest kernel.org kernel. The big players
> all seem to agree that the new development model better suits users and
> their own needs. The distros are in a better position to determine what
> constitutes a stable kernel anyway, they have millions of users to test
> on. Let the vendors AND the kernel hackers do what they are each best
> at.
Vendors are interested in making money, kernel hackers are interested in
bringing the kernel forward, Admins are interested in keeping their Servers
up.
It looks like we need a Community driven Enterprise Kernel.
We decided to start testing with 2.6.10 and use it if there are no Problems.
Maybe there are other Admins doing the same and we can start our own
Enterprise Kernel.
Sombody interested in such a Project?
Boris
On Sat, 2004-10-23 at 00:12, Clemens Schwaighofer wrote:
[...]
> But well, 2.4 was usable after .10, so lets not rush to fast :)
Especially 2.4.11
SCNR,
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
>> 2.6.9 -> 2.6.10-rc1:
>> - 4 days
>> - > 15 MB patches
On Sat, Oct 23, 2004 at 07:52:12AM +0200, Willy Tarreau wrote:
> I firmly agree, and that's one of the reasons I still don't use 2.6. This
> could be avoided with a shorter release cycle with far less new features
> for each version (a bit like openbsd does), because about every maintainer
> would have a valid base to work on for the next release or the one after,
> and would not try to push unstable code in the "stable" kernel. Today, lots
> of people are certain that 2.8 (or 3.0) won't be out before 3 or 4 years. So
> if they want their code released soon, they push it hard in the current
> mainline :-(
The kernel is a big program. Your sense of scale is off.
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
>> It's a bit optimistic to call this amount of change "stabilizing".
On Sat, Oct 23, 2004 at 07:52:12AM +0200, Willy Tarreau wrote:
> What really frightens me is that judging from the changelogs, it really
> looks like cleanups, bug fixes and sometimes core changes... This gives
> a terrible idea of previous release code !
If you're expecting something different, perhaps your expectations are
off. Cleanups matter because they make maintenance easier. Core changes
happen because (gasp!) sometimes the core too has bugs or other issues.
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
>> 2.6 is corrently more a development kernel than a stable kernel.
On Sat, Oct 23, 2004 at 07:52:12AM +0200, Willy Tarreau wrote:
> That's how I present it to friends and customers too ;-) To others, I simply
> say that it's the new stable kernel, and I observe how it works for them :-)
I could show you what kinds of changes go in a development kernel as
opposed to what's going on in 2.6, but I have other things to do.
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
>> The last bug I observed personally was the problem with suspending when
>> using CONFIG_REGPARM=y together with Roland's waitid patch which was
>> added in 2.6.9-rc2. If I'd used 2.6.9 with the same .config as 2.6.8.1,
>> this was simple one more bug...
On Sat, Oct 23, 2004 at 07:52:12AM +0200, Willy Tarreau wrote:
> Each time I try a new release, I barely find it extremely slow and unstable,
> and I don't know where to start from to report broken things... Unfortunately
> I don't have enough time to spend on bug reports these days so I stick to a
> stable 2.4.
"Extremely slow and unstable" is so vague it can't be acted upon. How
do you expect anyone to provide a useful response to that kind of
problem description?
On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
>> IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
>> (or someone else) should maintain a 2.6 tree with less changes (like
>> Marcelo did and does with 2.4).
On Sat, Oct 23, 2004 at 07:52:12AM +0200, Willy Tarreau wrote:
> Yes, but not until the core is stabilized. Otherwise, ever changing
> features and exports will discourage driver maintainers from
> backporting fixes.
Your notion of the core being stabilized must be intractably strict.
There are, for instance, no changes comparable to converting the block
layer to use bio, or removing the global irq lock.
-- wli
On Sat, 23 Oct 2004 21:58:11 +0200, Kronos <[email protected]> wrote:
> Suppose that Linus or Andrew starts a new tree to develop some new and
> and very big and intrusive feature. Once it's done the tree will be
> merged back with 2.6 (should be easy with bk) or will become 2.8?
> Just Curious.
>
> Luca
Well, if such changes are going into 2.6, it's just as good to put
them into Andrews -mm tree, imho.
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
Adrian Bunk <[email protected]> ha scritto:
> IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
> (or someone else) should maintain a 2.6 tree with less changes
Suppose that Linus or Andrew starts a new tree to develop some new and
and very big and intrusive feature. Once it's done the tree will be
merged back with 2.6 (should be easy with bk) or will become 2.8?
Just Curious.
Luca
--
Home: http://kronoz.cjb.net
"L'abilita` politica e` l'abilita` di prevedere quello che
accadra` domani, la prossima settimana, il prossimo mese e
l'anno prossimo. E di essere cosi` abili, piu` tardi,
da spiegare perche' non e` accaduto."
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/23/2004 09:55 PM, Bernd Petrovitsch wrote:
> On Sat, 2004-10-23 at 00:12, Clemens Schwaighofer wrote:
> [...]
>
>>But well, 2.4 was usable after .10, so lets not rush to fast :)
>
>
> Especially 2.4.11
yup, that was the rocks :)
lg, clemens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBexvAjBz/yQjBxz8RArc8AJ4yc9DUJlsU/RyDGKOLVAlFHxvrOwCZAe6R
tkBToFVDu8BC5FJPlIjhlSQ=
=y6Ys
-----END PGP SIGNATURE-----
William Lee Irwin III wrote:
> We aren't just stabilizing 2.6. We're moving it forward. Part of moving
> forward is preventing backportmania depravity. Backporting is the root
> of all evil.
Damn! And I thought it was closed source software...
Let me just put forward my single criterion for stable vs. not, and that
is that if I am running a stable kernel and upgrade to a new version to
gain a feature or security fix my existing programs don't break. That
means to me that if Reiser4 goes in, Reiser3 doesn't exit. If something
more please to theoretical cryptographers than cryptoloop comes out,
cryptoloop doesn't go away. Etc, these are just examples.
It doesn't bother me (and I believe most users of kernel.org releases)
when a new features comes in, until it breaks something even though I
don't use the new feature. It's when there is an incompatible change,
like the rewrite of modules, that I think a development kernel is needed.
I don't see the need for a development kernel, and it is desirable to be
able to run kernel.org kernels. I would like to hope that other people
agree that stable need not mean static, as long as changes don't
deliberately break existing apps.
I note that BSD has another serious fork and that people are actually
moving to Linux after installing SP2 and finding it disfunctional with
non-MS software. Nice to see people looking at Linux as the stable
choice. I would like to hope that continues.
--
-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:
>> We aren't just stabilizing 2.6. We're moving it forward. Part of moving
>> forward is preventing backportmania depravity. Backporting is the root
>> of all evil.
On Mon, Oct 25, 2004 at 05:15:05PM -0400, Bill Davidsen wrote:
> Damn! And I thought it was closed source software...
> Let me just put forward my single criterion for stable vs. not, and that
> is that if I am running a stable kernel and upgrade to a new version to
> gain a feature or security fix my existing programs don't break. That
> means to me that if Reiser4 goes in, Reiser3 doesn't exit. If something
> more please to theoretical cryptographers than cryptoloop comes out,
> cryptoloop doesn't go away. Etc, these are just examples.
I don't see the kind of thing you're saying should not happen happening.
This does not seem pertinent to -rc vs. other names.
On Mon, Oct 25, 2004 at 05:15:05PM -0400, Bill Davidsen wrote:
> It doesn't bother me (and I believe most users of kernel.org releases)
> when a new features comes in, until it breaks something even though I
> don't use the new feature. It's when there is an incompatible change,
> like the rewrite of modules, that I think a development kernel is needed.
I don't have much of anything to say about modules apart from
"I didn't do it".
On Mon, Oct 25, 2004 at 05:15:05PM -0400, Bill Davidsen wrote:
> I don't see the need for a development kernel, and it is desirable to be
> able to run kernel.org kernels. I would like to hope that other people
> agree that stable need not mean static, as long as changes don't
> deliberately break existing apps.
If we're chucking out crap, there's generally a massive amount of
notice. The only time I've ever been personally burned is kernel rarpd
removal, which did give a major release's worth of notice, but was a
case where I did not find the userspace replacement satisfactory. I'm
still not entirely happy with the userspace rarpd, but get by as it's
been improved since the initial changeover. I suspect there will be
some similar cases coming involving early userspace and so on where
bootloader size limitations vs. new methods burn me regardless of notice.
On Mon, Oct 25, 2004 at 05:15:05PM -0400, Bill Davidsen wrote:
> I note that BSD has another serious fork and that people are actually
> moving to Linux after installing SP2 and finding it disfunctional with
> non-MS software. Nice to see people looking at Linux as the stable
> choice. I would like to hope that continues.
This doesn't really mean much to me. I'm more specifically concerned
with Linux' internals as opposed to e.g. mass-market phenomena or the
various trends going on amongst end users.
-- wli
Bill Davidsen wrote:
> I don't see the need for a development kernel, and it is desirable to be
> able to run kernel.org kernels.
Problem is, kernel.org 'release' kernels are quite buggy. For example 2.6.9
has a long list of bugs:
- superio parports don't work
- TCP networking using TSO gives memory allocation failures
- s390 has a serious security bug (sacf)
- ppp hangup is broken with some peers
- exec leaks POSIX timer memory and loses signals
- auditing can deadlock
- O_DIRECT and mmap IO can't be used together
- procfs shows the wrong parent PID in some cases
- i8042 fails to initialize with some boards using legacy USB
- kswapd still goes into a frenzy now and then
Sure, the next release will (may?) fix these bugs, but it will definitely
add a whole set of new ones.
--Chuck Ebbert 26-Oct-04 01:36:21
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Oct 22, 2004 at 10:04:39PM -0700, Greg KH wrote:
> On Sat, Oct 23, 2004 at 03:40:04AM +0200, Adrian Bunk wrote:
> > On Sat, Oct 23, 2004 at 12:57:03AM +0200, Willy Tarreau wrote:
> > > On Fri, Oct 22, 2004 at 11:52:50PM +0200, Espen Fjellv?r Olsen wrote:
> > >...
> > > > A 2.7 should be created where all new experimental stuff is merged
> > > > into it, and where people could begin to think new again.
> > >
> > > This could be true if the release cycle was shorter. But once 2.7 comes
> > > out, many developpers will only focus on their development and not on
> > > stabilizing 2.6 as much as today.
> >
> > 2.6.9 -> 2.6.10-rc1:
> > - 4 days
> > - > 15 MB patches
> >
> > It's a bit optimistic to call this amount of change "stabilizing".
> >
> > 2.6 is corrently more a development kernel than a stable kernel.
> >
> > The last bug I observed personally was the problem with suspending when
> > using CONFIG_REGPARM=y together with Roland's waitid patch which was
> > added in 2.6.9-rc2. If I'd used 2.6.9 with the same .config as 2.6.8.1,
> > this was simple one more bug...
> >
> > IMHO Andrew+Linus should open a short-living 2.7 tree soon and Andrew
> > (or someone else) should maintain a 2.6 tree with less changes (like
> > Marcelo did and does with 2.4).
>
> I don't ever want to plug anything I've written, but please see the
> current issue of Linux Journal with an article explaining how this is
> all working, why we are doing this, and how the hell we can keep sane
> this way. I've also got slides on my website from the talk I've given
> about this topic at OLS, OSCON, and SUCON about this topic.
>...
I looked at your slides, but to be honest, I'm still not convinced.
The Andrew+Linus model with -mm works pretty well.
Why shouldn't it also work in 2.7 removing all the past problems with
overly long release cycles between two stable series?
If it could be achieved to release 2.8 half a year after 2.7 was
started, this should be short enough for distributions etc. for not
having to backport too much while giving the benefits of putting the
patch pressure away from 2.6 making it more stable.
> thanks,
>
> greg k-h
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 SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBfaNkmfzqmE8StAARAmAvAJ9kav1shMitTz201gO+hyo4UCt3ygCfRQ70
weQeqRyMgS/r8befY8qa5Uk=
=tm91
-----END PGP SIGNATURE-----
On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> Bill Davidsen wrote:
>
> > I don't see the need for a development kernel, and it is desirable to be
> > able to run kernel.org kernels.
>
> Problem is, kernel.org 'release' kernels are quite buggy. For example 2.6.9
> has a long list of bugs:
>
> - superio parports don't work
> - TCP networking using TSO gives memory allocation failures
> - s390 has a serious security bug (sacf)
> - ppp hangup is broken with some peers
> - exec leaks POSIX timer memory and loses signals
> - auditing can deadlock
> - O_DIRECT and mmap IO can't be used together
> - procfs shows the wrong parent PID in some cases
> - i8042 fails to initialize with some boards using legacy USB
> - kswapd still goes into a frenzy now and then
>
> Sure, the next release will (may?) fix these bugs, but it will definitely
> add a whole set of new ones.
To my mind this just points out the need for a bug fix branch. e.g. a
branch containing just bug/security fixes against the current stable
kernel. It might also be worth keeping the branch active for the n-1
stable kernel too.
Ed
PS. we could call this the Bug/Security or bs kernels.
> On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > Bill Davidsen wrote:
> >
> > > I don't see the need for a development kernel, and it is
> desirable
> > > to be
> > > able to run kernel.org kernels.
> >
> > Problem is, kernel.org 'release' kernels are quite buggy. For
> > example 2.6.9 has a long list of bugs:
> >
> > Sure, the next release will (may?) fix these bugs, but it will
> > definitely add a whole set of new ones.
>
> To my mind this just points out the need for a bug fix
> branch. e.g. a
> branch containing just bug/security fixes against the current
> stable kernel. It might also be worth keeping the branch
> active for the n-1 stable kernel too.
To my mind, we only need to make clear that a stable kernel is a stable
kernel.
Not a kernel for experiments.
To my mind, stock 2.6 kernels are nice for nerds trying patches and
willing to recompile their kernel once a day. They are not suitable for
servers. Several times on testing machines, switching from a 2.6 to the
next one has caused bugs on PCI, acpi, networking and so on.
The direction is lost. How many patchsets for vanilla kernel exist?
Someone has decided that linux must go on desktops as well and
developing new magnificent features for desktop users is causing serious
problems to the ones who use linux at work on production servers.
2.4 tree is still the best solution for production.
2.6 tree is great for gentoo users who like gcc consuming all CPU
(maxumum respect to gentoo but I prefer debian)
Massimo Cetra
On Tue, 26 Oct 2004 13:09:59 +0200, Massimo Cetra <[email protected]> wrote:
> > On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > > Bill Davidsen wrote:
> > >
> > > > I don't see the need for a development kernel, and it is
> > desirable
> > > > to be
> > > > able to run kernel.org kernels.
> > >
> > > Problem is, kernel.org 'release' kernels are quite buggy. For
> > > example 2.6.9 has a long list of bugs:
> > >
> > > Sure, the next release will (may?) fix these bugs, but it will
> > > definitely add a whole set of new ones.
> >
>
> > To my mind this just points out the need for a bug fix
> > branch. e.g. a
> > branch containing just bug/security fixes against the current
> > stable kernel. It might also be worth keeping the branch
> > active for the n-1 stable kernel too.
>
> To my mind, we only need to make clear that a stable kernel is a stable
> kernel.
> Not a kernel for experiments.
2.6 is not an experimental kernel. Not at all.
> To my mind, stock 2.6 kernels are nice for nerds trying patches and
> willing to recompile their kernel once a day. They are not suitable for
> servers. Several times on testing machines, switching from a 2.6 to the
> next one has caused bugs on PCI, acpi, networking and so on.
I don't understand what you mean here.
Did you report these problems to lkml ?
It's the firts time I heard about this kind of problems.
> The direction is lost. How many patchsets for vanilla kernel exist?
It was the same for 2.4. And that's not _BAD_, is _GOOD_.
> Someone has decided that linux must go on desktops as well and
> developing new magnificent features for desktop users is causing serious
> problems to the ones who use linux at work on production servers.
Who ?
> 2.4 tree is still the best solution for production.
> 2.6 tree is great for gentoo users who like gcc consuming all CPU
> (maxumum respect to gentoo but I prefer debian)
I'm sorry, but you sound like a troll...
--
Paolo
On Tue, Oct 26, 2004 at 06:44:46AM -0400, Ed Tomlinson wrote:
> To my mind this just points out the need for a bug fix branch. e.g. a
> branch containing just bug/security fixes against the current stable
> kernel. It might also be worth keeping the branch active for the n-1
> stable kernel too.
>
> Ed
>
> PS. we could call this the Bug/Security or bs kernels.
The current kernel version number scheme already has a provision for
a security/bug fix branch: 2.6.9.1, 2.6.9.2, etc.
-Barry K. Nathan <[email protected]>
On Tue, Oct 26, 2004 at 01:40:16AM -0400, Chuck Ebbert wrote:
> Problem is, kernel.org 'release' kernels are quite buggy. For
> example 2.6.9 has a long list of bugs:
> - superio parports don't work
> - TCP networking using TSO gives memory allocation failures
> - s390 has a serious security bug (sacf)
> - ppp hangup is broken with some peers
> - exec leaks POSIX timer memory and loses signals
> - auditing can deadlock
> - O_DIRECT and mmap IO can't be used together
> - procfs shows the wrong parent PID in some cases
> - i8042 fails to initialize with some boards using legacy USB
> - kswapd still goes into a frenzy now and then
> Sure, the next release will (may?) fix these bugs, but it will definitely
> add a whole set of new ones.
And which of these are new in 2.6.9? The bug list shrinks in newer
releases. The fact there are sometimes new ones is an unavoidable
fact of life. Trying to slow down development won't prevent it.
-- wli
On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
>> Sure, the next release will (may?) fix these bugs, but it will
>> definitely add a whole set of new ones.
On Tue, Oct 26, 2004 at 06:44:46AM -0400, Ed Tomlinson wrote:
> To my mind this just points out the need for a bug fix branch. e.g. a
> branch containing just bug/security fixes against the current stable
> kernel. It might also be worth keeping the branch active for the n-1
> stable kernel too.
> PS. we could call this the Bug/Security or bs kernels.
This has been very explicitly encouraged numerous times and no one has
taken up the task. Someone actually doing something about this for once
may be helpful to quell the worries of people such as we're hearing from.
-- wli
The only reason that i brought this up again was that, as written
before, the kernel contains very much bad code. Very much could be
redone to gain both speed and security, imho.
I don't think such a brainstorm is going to happen within a 2.6 "stable" tree.
We need a 2.7 tree for this, then people might want to experiment with
rewrinting old code.
But im not an expert on the Linux kernel, i have no idea really.
I just startet to using 2.5/2.6 at some of the last 2.5 kernels.
That was a whole new world, you could really feel the improvments over 2.4.
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
On Tuesday 26 October 2004 06:44, Ed Tomlinson wrote:
>On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
>> Bill Davidsen wrote:
>> > I don't see the need for a development kernel, and it is
>> > desirable to be able to run kernel.org kernels.
>>
>> Problem is, kernel.org 'release' kernels are quite buggy. For
>> example 2.6.9 has a long list of bugs:
>>
>> - superio parports don't work
>> - TCP networking using TSO gives memory allocation failures
>> - s390 has a serious security bug (sacf)
>> - ppp hangup is broken with some peers
>> - exec leaks POSIX timer memory and loses signals
>> - auditing can deadlock
>> - O_DIRECT and mmap IO can't be used together
>> - procfs shows the wrong parent PID in some cases
>> - i8042 fails to initialize with some boards using legacy USB
>> - kswapd still goes into a frenzy now and then
>>
Then the question is begged, is there a common location where patches
for these known bugs can be downloaded, diffed against the current
stable kernel? If not, there really should be. As in the kernel.org
stable directory should have a subdir in the 2.6.9 directory called
'bugfixes', with any patches that specifically fix known bugs that
have been developed since the release placed there. No new features,
just the bugfix patches. That would allow those of us who take the
chance and bleed, to bleed a bit less.
>> Sure, the next release will (may?) fix these bugs, but it will
>> definitely add a whole set of new ones.
>
>To my mind this just points out the need for a bug fix branch.
> e.g. a branch containing just bug/security fixes against the
> current stable kernel. It might also be worth keeping the branch
> active for the n-1 stable kernel too.
>
>Ed
>
>PS. we could call this the Bug/Security or bs kernels.
Chuckle. Nice play on words there, but I really do like this idea.
Just one suggestion. When the snapshot to start the next patch series
in the deveopment tree is done, take it from the latest, all bugfix
patches applied, .bs kernel.
>-
>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.28% 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 Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
>> To my mind this just points out the need for a bug fix branch.
>> e.g. a branch containing just bug/security fixes against the current
>> stable kernel. It might also be worth keeping the branch active for
>> the n-1 stable kernel too.
On Tue, Oct 26, 2004 at 01:09:59PM +0200, Massimo Cetra wrote:
> To my mind, we only need to make clear that a stable kernel is a stable
> kernel.
> Not a kernel for experiments.
> To my mind, stock 2.6 kernels are nice for nerds trying patches and
> willing to recompile their kernel once a day. They are not suitable for
> servers. Several times on testing machines, switching from a 2.6 to the
> next one has caused bugs on PCI, acpi, networking and so on.
This is bunk. I'm running 2.6 on a number of machines I rely upon
heavily as servers etc. on the open net as well as the usual dedicated
kernel hacking machines. The uptimes of the relied-upon systems are
measured in months, at times approaching a year. When it's time for a
reboot, I upgrade to the latest available 2.6.x-mm every time. This is
not just stable, it's running to hardware/power failure territory.
You seem to be under the mistaken assumption that change is frivolous
and the result of masturbatory abuse of the kernel as a toy. This is
very clearly not the case. Linux kernel programmers write their patches
because there is a need for the change, and Linux kernel maintainers
merge patches because they understand the need for the change is great
enough.
This process very successfully converges. More bugs are fixed than are
introduced every release by a large margin. If you don't understand why
regressions are inevitable, you don't understand that humans are
imperfect. And not even your beloved 2.4 is immune to regressions.
On Tue, Oct 26, 2004 at 01:09:59PM +0200, Massimo Cetra wrote:
> The direction is lost. How many patchsets for vanilla kernel exist?
> Someone has decided that linux must go on desktops as well and
> developing new magnificent features for desktop users is causing serious
> problems to the ones who use linux at work on production servers.
> 2.4 tree is still the best solution for production.
> 2.6 tree is great for gentoo users who like gcc consuming all CPU
> (maxumum respect to gentoo but I prefer debian)
What does the number of patchsets have to do with anything? What's the
obsession with featurework? Why do you assume it's frivolous?
Deficiencies can arise in forms beyond bugs. Addressing those is one of
the things the new development model was designed to cover. They are
nowhere near as problematic as you suggest. For instance, anon_vma was
merged almost entirely without incident, thanks to the efforts of Hugh
Dickins.
The fact is, you're not complaining about those features anyway. PCI,
etc. normal driver and networking layer turnover, and networking is
largely a different universe from the rest of the kernel. These areas
are actually relatively conservatively maintained in comparison to what
you're pointing at, so complaining about the new development model
causing regressions in them is absurd (as in reductio ad asburdum).
-- wli
On Tue, 26 Oct 2004 at 07:28:41 -0700 William Lee Irwin III wrote:
> On Tue, Oct 26, 2004 at 06:44:46AM -0400, Ed Tomlinson wrote:
>> To my mind this just points out the need for a bug fix branch. e.g. a
>> branch containing just bug/security fixes against the current stable
>> kernel. It might also be worth keeping the branch active for the n-1
>> stable kernel too.
>> PS. we could call this the Bug/Security or bs kernels.
>
> This has been very explicitly encouraged numerous times and no one has
> taken up the task. Someone actually doing something about this for once
> may be helpful to quell the worries of people such as we're hearing from.
I'm running a kernel I call 2.6.9.1 right now, but I have no clue how to
distribute it. How do you get an account on kernel.org?
Directory of t:\in\269\2691
24-10-04 21:45 <DIR> .
25-10-04 13:48 <DIR> ..
24-10-04 21:59 2,647 000-MANIFEST
24-10-04 21:50 1,146 3c59x_pci_disable_device.patch
23-10-04 19:11 1,046 ac3_compiler.h_assembly.patch
23-10-04 19:47 1,295 ac3_config_via_velocity.patch
23-10-04 19:37 1,056 ac3_cpia_fixes.patch
24-10-04 22:28 2,652 ac3_i8042.patch
23-10-04 19:47 571 ac3_i8xx_tco_timer.patch
23-10-04 19:47 907 ac3_moxa_wakeup.patch
23-10-04 23:05 1,942 ac3_ppp_hangup.patch
23-10-04 19:43 964 ac3_skbuff_tso.patch
23-10-04 19:43 946 ac3_smbfs_request.patch
23-10-04 19:42 17,977 ac3_vm_io.patch
23-10-04 14:18 961 compat_ioctl_tiocsbrk.patch
24-10-04 19:44 329 decnet_connrefused.patch
23-10-04 21:08 2,218 delay_rq_lock.patch
23-10-04 13:20 491 dm_duplicate_kfree.patch
24-10-04 20:34 5,667 exec_timers_and_signals.patch
23-10-04 20:23 718 hvsi_oops.patch
23-10-04 13:53 1,552 i2c_amd_kconfig.patch
24-10-04 19:59 1,164 ide_no_chs.patch
23-10-04 21:22 483 init_poison.patch
23-10-04 13:42 1,190 ioapic_init_section.patch
24-10-04 21:48 1,670 ioapic_on_nvidia_boards.patch
23-10-04 13:43 855 log_buf_shift.patch
23-10-04 21:54 737 maxtor_ide_probe.patch
19-10-04 22:10 820 memset_signal_ppc64.patch
23-10-04 22:51 873 netif_rx_ni_preempt_safe.patch
23-10-04 14:08 1,203 o_direct_mmapped_io.patch
23-10-04 22:27 4,181 parport_superio.patch
23-10-04 13:28 662 pcdp_swap_args.patch
23-10-04 22:48 910 pci_dev_put.patch
23-10-04 13:32 1,593 percpu_alignment.patch
23-10-04 20:38 786 proc_wrong_parent.patch
23-10-04 14:09 1,542 quoted_env_vars_3.patch
23-10-04 22:24 608 return_enfile_not_emfile.patch
23-10-04 22:26 1,453 s390_sacf_exception.patch
23-10-04 14:20 1,519 suspend_time_adjust.patch
23-10-04 13:50 636 tcp_output_skbuff_fix.patch
23-10-04 13:51 3,375 unbalanced_tasks_v3.patch
23-10-04 13:56 957 usr_courier_pnp_id.patch
24-10-04 21:48 2,051 vga_console_font.patch
23-10-04 22:28 950 vm_dirty_ratio_clamp.patch
24-10-04 19:34 822 vm_pages_scanned_active_list.patch
23-10-04 13:37 840 x86_64_syscall32_initdata.patch
44 File(s) 76,965 bytes
--Chuck Ebbert 26-Oct-04 11:52:08
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Espen Fjellv?r Olsen wrote:
| This may come a bit late now, since the "new development model" was
| put through late this summer.
| But anyway i'm going to come with som thoughts about it.
|
| I think that 2.6 should be frozen from now on, just security related
| stuff should be merged.
| This would strengthen Linux's reputation as a stable and secure
| system, not a unstable and a system just used for fun.
| A 2.7 should be created where all new experimental stuff is merged
| into it, and where people could begin to think new again.
| New thoughts are good in all ways, it is for sure very much code in
| the current kernels that should be revised, rewritten and maybe marked
| as deprecated.
|
| :)
I agree fully.
I've been quite worried and annoyed. While I do think the newest
releases and the changes in 2.6.9 and .10 are damn cool, and i want
them, I also won't let go of PaX. PaX stopped at 2.6.7 because of
internal VM changes; the kernel's unstable state is making it an undue
amount of work for the PaX team to update PaX for the newest kernels.
If all the time is spent porting it up to the new VM changes, then there
is no time for bugfixes and improvements.
PaX is a core component of GrSecurity as well; as long as the PaX
project is halted at 2.6.7, GrSec can't pass 2.6.7. How many other
projects are going to sit at 2.6.7, or are going to spend too much time
up-porting and not enough time bugfixing and enhancing?
I do not propose freezing *now* if it's not convenient; I say you pick
what you want to finish up (maybe some of the Montavista stuff; I'd
personally like voluntary pre-empt and friends at least), get that in,
and slate any new developments for a 2.6.7 branch to be forked off
whenever is appropriate.
|
| --
| Mvh / Best regards
| Espen Fjellv?r Olsen
| [email protected]
| Norway
| -
| 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.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfnTdhDd4aOud5P8RAlsMAJ9ppwugKHeXm9pjDePNyRuQ9mTvZACfXwNR
Tj930yU5hMJFrbj27ez3lWQ=
=XEVU
-----END PGP SIGNATURE-----
Mon, 25 Oct 2004 @ 17:15 -0400, Bill Davidsen said:
> I note that BSD has another serious fork
Which one is that?
> and that people are actually moving to Linux after installing SP2 and
> finding it disfunctional with non-MS software.
SP2?
--
shannon "AT" widomaker.com -- ["Meddle not in the affairs of Wizards, for
thou art crunchy, and taste good with ketchup." -- unknown]
On Tue, 26 Oct 2004 at 08:03:13 -0700 William Lee Irwin III wrote:
> I'm running 2.6 on a number of machines I rely upon
> heavily as servers etc. on the open net as well as the usual dedicated
> kernel hacking machines. The uptimes of the relied-upon systems are
> measured in months, at times approaching a year.
"It works for me" doesn't cut it in the OS world.
> More bugs are fixed than are introduced every release by a large margin.
Irrelevant.
> And not even your beloved 2.4 is immune to regressions.
We're not talking about regression, i.e. reappearance of old bugs.
> What does the number of patchsets have to do with anything?
Large changes produce bugs -- that's a fact of life.
It's not that the changes aren't needed, it's just the the previous 2.6 release
is kind of like a baby abandoned on a doorstep -- nobody has the time to fix
those last few bugs. Even if someone were to step up to the plate and try to
create a stable 2.6 series, I'd bet the lead developers wouldn't even spend time
working on it.
--Chuck Ebbert 26-Oct-04 12:31:08
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Richard Moser wrote:
|
|
[...]
| project is halted at 2.6.7, GrSec can't pass 2.6.7. How many other
| projects are going to sit at 2.6.7, or are going to spend too much time
| up-porting and not enough time bugfixing and enhancing?
[...]
| and slate any new developments for a 2.6.7 branch to be forked off
| whenever is appropriate.
Yeah, I'm like, asleep, and stupid. PaX/GrSec are stuck at 2.6.7,
others may be stuck at 2.6.x or may be progressing poorly just trying to
keep up. Slate new developments for a 2.7 branch to be forked. You get
the idea.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfn7lhDd4aOud5P8RAsRCAJ9XI7SHxnUPQHlToJD90ml8fTqrXwCeMifz
ukgT9hdWcDjejeaPRR1pc40=
=nVRb
-----END PGP SIGNATURE-----
On 26 Oct 2004, Charles Shannon Hendrix wrote:
> > I note that BSD has another serious fork
I assume he means DragonFly BSD. Looks promising so far.
I still prefer Linux for most things personally though. :)
http://www.dragonflybsd.org/
--
Mark Nipper e-contacts:
4475 Carter Creek Parkway [email protected]
Apartment 724 http://nipsy.bitgnome.net/
Bryan, Texas, 77802-4481 AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193 MSN: [email protected]
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GG/IT d- s++:+ a- C++$ UBL++++$ P--->+++ L+++$ !E---
W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--)
Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**)
------END GEEK CODE BLOCK------
---begin random quote of the moment---
"I do not know whether I was then a man dreaming I was a
butterfly, or whether I am now a butterfly dreaming I am a man."
-- Chang Tzu
----end random quote of the moment----
The fact is, these days nobody wants to be a stable-release maintainer
anymore. It's boring.
I don't agree that the new development is "better" in the sense of keeping
stability and quality, but I can't blame Andrew for that. Let people do
whatever they like to do, and they'll do a better job.
So unless someone steps up and does it, there is no point in arguing. Of
course, s/he won't be an "official maintainer" as endorsed/appointed by
Linus like previous releases, but that might be better as it's more like
"people choose XXX" instead of "Linus forces XXX onto people"? :)
Hua
On Tue, 26 Oct 2004 at 08:03:13 -0700 William Lee Irwin III wrote:
>> I'm running 2.6 on a number of machines I rely upon
>> heavily as servers etc. on the open net as well as the usual dedicated
>> kernel hacking machines. The uptimes of the relied-upon systems are
>> measured in months, at times approaching a year.
On Tue, Oct 26, 2004 at 12:32:19PM -0400, Chuck Ebbert wrote:
> "It works for me" doesn't cut it in the OS world.
It's an existence proof spanning a wide swath of architectures. If
you are not seeing similar results, send bugreports.
On Tue, 26 Oct 2004 at 08:03:13 -0700 William Lee Irwin III wrote:
>> More bugs are fixed than are introduced every release by a large margin.
On Tue, Oct 26, 2004 at 12:32:19PM -0400, Chuck Ebbert wrote:
> Irrelevant.
Incorrect. Insert infinite descent argument here.
On Tue, 26 Oct 2004 at 08:03:13 -0700 William Lee Irwin III wrote:
>> And not even your beloved 2.4 is immune to regressions.
On Tue, Oct 26, 2004 at 12:32:19PM -0400, Chuck Ebbert wrote:
> We're not talking about regression, i.e. reappearance of old bugs.
That's not an important distinction.
On Tue, 26 Oct 2004 at 08:03:13 -0700 William Lee Irwin III wrote:
>> What does the number of patchsets have to do with anything?
On Tue, Oct 26, 2004 at 12:32:19PM -0400, Chuck Ebbert wrote:
> Large changes produce bugs -- that's a fact of life.
If the patchsets had anything to do with mainline, they would have
been merged anyway.
On Tue, Oct 26, 2004 at 12:32:19PM -0400, Chuck Ebbert wrote:
> It's not that the changes aren't needed, it's just the the previous
> 2.6 release is kind of like a baby abandoned on a doorstep -- nobody
> has the time to fix those last few bugs. Even if someone were to
> step up to the plate and try to create a stable 2.6 series, I'd bet
> the lead developers wouldn't even spend time working on it.
Then you don't understand Linux' releases. Point releases are in fact
updated and maintained. Those updates are given the name of the next
point release. The fact you are so timid or misguided that the scale of
the kernel terrifies you is not kernel developers' problem.
-- wli
On Tue, 26 Oct 2004 12:01:33 -0400
John Richard Moser <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Espen Fjellv?r Olsen wrote:
> | This may come a bit late now, since the "new development model" was
> | put through late this summer.
> | But anyway i'm going to come with som thoughts about it.
> |
> | I think that 2.6 should be frozen from now on, just security related
> | stuff should be merged.
> | This would strengthen Linux's reputation as a stable and secure
> | system, not a unstable and a system just used for fun.
> | A 2.7 should be created where all new experimental stuff is merged
> | into it, and where people could begin to think new again.
> | New thoughts are good in all ways, it is for sure very much code in
> | the current kernels that should be revised, rewritten and maybe marked
> | as deprecated.
> |
> | :)
>
> I agree fully.
>
> I've been quite worried and annoyed. While I do think the newest
> releases and the changes in 2.6.9 and .10 are damn cool, and i want
> them, I also won't let go of PaX. PaX stopped at 2.6.7 because of
> internal VM changes; the kernel's unstable state is making it an undue
> amount of work for the PaX team to update PaX for the newest kernels.
> If all the time is spent porting it up to the new VM changes, then there
> is no time for bugfixes and improvements.
>
> PaX is a core component of GrSecurity as well; as long as the PaX
> project is halted at 2.6.7, GrSec can't pass 2.6.7. How many other
> projects are going to sit at 2.6.7, or are going to spend too much time
> up-porting and not enough time bugfixing and enhancing?
>
The Linux development model is not setup to be convenient for out of tree
kernel development. This is intentional, if the project is out of tree no
kernel developer is going to see it or fix it. Submit it and get it reviewed
and into the process or quit complaining and make and maintain your
own "stable" tree.
> I do not propose freezing *now* if it's not convenient; I say you pick
> what you want to finish up (maybe some of the Montavista stuff; I'd
> personally like voluntary pre-empt and friends at least), get that in,
> and slate any new developments for a 2.6.7 branch to be forked off
> whenever is appropriate.
Everyone's list of what they want added to 2.6 is different. So the
kernel work continues and is the union of everyone's good ideas (and
a few bad ones).
On Tue, 26 Oct 2004 at 07:28:41 -0700 William Lee Irwin III wrote:
>> This has been very explicitly encouraged numerous times and no one has
>> taken up the task. Someone actually doing something about this for once
>> may be helpful to quell the worries of people such as we're hearing from.
On Tue, Oct 26, 2004 at 11:54:48AM -0400, Chuck Ebbert wrote:
> I'm running a kernel I call 2.6.9.1 right now, but I have no clue how to
> distribute it. How do you get an account on kernel.org?
It probably makes more sense to get some kind of track record for
releasing the things, not that it's my call.
-- wli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen Hemminger wrote:
| On Tue, 26 Oct 2004 12:01:33 -0400
[...]
|
|
| The Linux development model is not setup to be convenient for out of tree
| kernel development. This is intentional, if the project is out of tree no
| kernel developer is going to see it or fix it. Submit it and get it
reviewed
| and into the process or quit complaining and make and maintain your
| own "stable" tree.
"The Linux development model is intentionally crafted to impede progress."
That's all you had to say.
Progress has to occur outside mainline before it can be submitted. By
impeding such progress, you potentially prevent things from keeping
current enough to reach a stable point and be ready for mainline
inclusion. Overall, you're slowing down development and making it more
difficult.
[...]
|
| Everyone's list of what they want added to 2.6 is different. So the
| kernel work continues and is the union of everyone's good ideas (and
| a few bad ones).
Actually, a few minutes after this, I belted out a cheap and unrefined,
fairly hackish proposal[1] for a similar but slightly altered model.
Commentary on it and refinement may be nice. Maybe I'm just trying to
make everybody happy, and it's not possible?
[1] http://lkml.org/lkml/2004/10/26/171
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfpmkhDd4aOud5P8RAmO4AJ4oxPajdqf6+xt3KUejxLRxZStASgCfded/
FmuWzyk865VsQr2uuIG/a1I=
=HYDL
-----END PGP SIGNATURE-----
El Tue, 26 Oct 2004 09:58:41 -0700 "Hua Zhong" <[email protected]> escribi?:
> The fact is, these days nobody wants to be a stable-release maintainer
> anymore. It's boring.
I doubt it. People like Alan Cox or Marcello have done it in the past, and I
bet many others could do it. Not everybody uses the latest -mm available in
their machines.
Paolo Ciarrocchi <[email protected]> disait derni?rement que :
>> To my mind, we only need to make clear that a stable kernel is a stable
>> kernel.
>> Not a kernel for experiments.
>
> 2.6 is not an experimental kernel. Not at all.
clearly do I agree.
>> To my mind, stock 2.6 kernels are nice for nerds trying patches and
>> willing to recompile their kernel once a day. They are not suitable for
>> servers. Several times on testing machines, switching from a 2.6 to the
>> next one has caused bugs on PCI, acpi, networking and so on.
>
> I don't understand what you mean here.
> Did you report these problems to lkml ?
> It's the firts time I heard about this kind of problems.
I will just add this:
we, young students from all horizons here at the ENS Cachan, run a huge network
(~900 hosts), with 4 important servers, all running 2.6. And my conclusion, as
I cannot speak for my fellow colleagues but think most would agree, is that
these servers behave *a* *lot* *better* since we switch. We had problems first
but they were mostly due to the switch to Debian testing distribution (from
old Woody).
Also we have a 4-way (bi-Xeon with HT) running 2.6.7, playing proxy squid to
serve our entire network, up since 131 days, with no problems; and the 2.6.x
switch was more a blessing than a pain in the butt, since 2.4.x just let him
play more and more in system time.... Thanks to sched domains and _real_ HT
scheduling support.
And these are production servers, no more no less.
>> The direction is lost. How many patchsets for vanilla kernel exist?
>
> It was the same for 2.4. And that's not _BAD_, is _GOOD_.
yup -mm, -ac existed in 2.4 series.
and do not forget that -mm series are a stage for patches aiming mainline,
not a special patchset among others.
>> Someone has decided that linux must go on desktops as well and
>> developing new magnificent features for desktop users is causing serious
>> problems to the ones who use linux at work on production servers.
>
> Who ?
Users decided, I guess :)
>> 2.4 tree is still the best solution for production.
I do not think so, I think it depends on the hardware you bear.
>> 2.6 tree is great for gentoo users who like gcc consuming all CPU
>> (maxumum respect to gentoo but I prefer debian)
huh ? what's the point ????
Our 2.6 servers run Debian testing with a little trouble.
Best regards, and hurray for Linux 2.6 series !!
Mathieu
--
"One of the great things about books is sometimes there are some fantastic
pictures."
George W. Bush
January 3, 2000
Quoted in U.S. News & World Report.
Diego Calleja wrote:
> El Tue, 26 Oct 2004 09:58:41 -0700 "Hua Zhong" <[email protected]> escribi?:
>>The fact is, these days nobody wants to be a stable-release maintainer
>>anymore. It's boring.
>
> I doubt it. People like Alan Cox or Marcello have done it in the past,
...and probably suffer emotional scars from the process.
Taming the patch stream must be like drinking from a fire hose
while herding angry, computer literate cats.
Wearing, but not boring.
In the words of Flipper: *squeeee* eh eh eh eh *squeeeee*
Translation:
"Maintaining a kernel source tree is more vexatious than a tuna net."
--
Paul Fulghum
[email protected]
Hi all,
despite I know you are all bored with the " I know how to improve the
process" email but I want to share with you this idea .-)
Both Andrew and Linus are doing an impressive job so I really don't
think we need to change the way they are working.
What I'm suggesting is start offering 2.6.X:Y kernel, you did for 2.6.8.1 so...
The .Y patchset contains only important security fix (all stuff you
think are important) and is weekly uploaded to kernel.org
Doing that, people:
- can stop running "personal version of vanilla kernel
- don't need to wait till next Linus' release in order to have a
security bug fixed
We, of course, need a maintainer for it,
maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
for a long time), maybe Alan (that is already applying these kind of
fixes to his tree), maybe someone else... ?
Sounds reasonable ?
--
Paolo
On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
> despite I know you are all bored with the " I know how to improve the
> process" email but I want to share with you this idea .-)
> Both Andrew and Linus are doing an impressive job so I really don't
> think we need to change the way they are working.
> What I'm suggesting is start offering 2.6.X:Y kernel, you did for
> 2.6.8.1 so...
> The .Y patchset contains only important security fix (all stuff you
> think are important) and is weekly uploaded to kernel.org
> Doing that, people:
> - can stop running "personal version of vanilla kernel
> - don't need to wait till next Linus' release in order to have a
> security bug fixed
> We, of course, need a maintainer for it,
> maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> for a long time), maybe Alan (that is already applying these kind of
> fixes to his tree), maybe someone else... ?
> Sounds reasonable ?
Not normally the first thing I'd volunteer for. I probably won't at
all unless demand comes down from on high.
-- wli
On Tue, 26 Oct 2004 13:22:24 -0700, William Lee Irwin III
<[email protected]> wrote:
> On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
>
>
> > despite I know you are all bored with the " I know how to improve the
> > process" email but I want to share with you this idea .-)
> > Both Andrew and Linus are doing an impressive job so I really don't
> > think we need to change the way they are working.
> > What I'm suggesting is start offering 2.6.X:Y kernel, you did for
> > 2.6.8.1 so...
> > The .Y patchset contains only important security fix (all stuff you
> > think are important) and is weekly uploaded to kernel.org
> > Doing that, people:
> > - can stop running "personal version of vanilla kernel
> > - don't need to wait till next Linus' release in order to have a
> > security bug fixed
> > We, of course, need a maintainer for it,
> > maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> > for a long time), maybe Alan (that is already applying these kind of
> > fixes to his tree), maybe someone else... ?
> > Sounds reasonable ?
>
> Not normally the first thing I'd volunteer for. I probably won't at
> all unless demand comes down from on high.
Well, I wrote your name because you are a great developer but I
understand you prefer doing something else ;)
What about just the *idea* ?
--
Paolo
On Tue, 26 Oct 2004 13:22:24 -0700, William Lee Irwin III wrote:
>> Not normally the first thing I'd volunteer for. I probably won't at
>> all unless demand comes down from on high.
On Tue, Oct 26, 2004 at 10:26:40PM +0200, Paolo Ciarrocchi wrote:
> Well, I wrote your name because you are a great developer but I
> understand you prefer doing something else ;)
> What about just the *idea* ?
The idea is fine.
-- wli
On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
> The .Y patchset contains only important security fix (all stuff you
> think are important) and is weekly uploaded to kernel.org
>
> Doing that, people:
> - can stop running "personal version of vanilla kernel
> - don't need to wait till next Linus' release in order to have a
> security bug fixed
>
> We, of course, need a maintainer for it,
> maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> for a long time), maybe Alan (that is already applying these kind of
> fixes to his tree), maybe someone else... ?
2.6-ac seems to be filling this role right now.
Dave
On Tue, 26 Oct 2004 16:36:44 -0400, Dave Jones <[email protected]> wrote:
> On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
>
> > The .Y patchset contains only important security fix (all stuff you
> > think are important) and is weekly uploaded to kernel.org
> >
> > Doing that, people:
> > - can stop running "personal version of vanilla kernel
> > - don't need to wait till next Linus' release in order to have a
> > security bug fixed
> >
> > We, of course, need a maintainer for it,
> > maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> > for a long time), maybe Alan (that is already applying these kind of
> > fixes to his tree), maybe someone else... ?
>
> 2.6-ac seems to be filling this role right now.
>
Correct.
But as I user I tend to look at kernel.org and download "The latest
stable version of the Linux kernel is".
If the goal of -ac is to only include those fixes, why can't we rename
it in something more "intuitive" for the final users ?
Do you see what I mean ?
--
Paolo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paolo Ciarrocchi wrote:
| Hi all,
| despite I know you are all bored with the " I know how to improve the
| process" email but I want to share with you this idea .-)
|
| Both Andrew and Linus are doing an impressive job so I really don't
| think we need to change the way they are working.
|
| What I'm suggesting is start offering 2.6.X:Y kernel, you did for
2.6.8.1 so...
|
| The .Y patchset contains only important security fix (all stuff you
| think are important) and is weekly uploaded to kernel.org
|
Eww.
2.6.10 got an -rc about 4 days after 2.6.9 went stable. This would be a
bit too rapid for my tastes; I don't like ideas that potentially load
maintainers.
[...]
| We, of course, need a maintainer for it,
Yes, a little too much to maintain though isn't it? Maintainers to
continuously upkeep revisions that come out every few weeks potentially?
~ Remember it's got to be able to withstand the test of time for quite a
while; why are people still maintaining 2.2?
| maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
| for a long time), maybe Alan (that is already applying these kind of
| fixes to his tree), maybe someone else... ?
|
Common courteousy, don't volunteer people. :)
| Sounds reasonable ?
|
Sounds too fast. I don't predict having a maintainer for each minor
release of the kernel (which is what you're saying here essentially), so
there'd be a need for one or a handfull of maintainers to spend loads of
time backporting fixes to a quickly mounting set of kernels.
I had <shameless plug> suggested an hour or two ago a scheme where the
current development model be based off, but periodic releases be made
"stable," basing on approximately 6 months between releases </shameless
plug>. I think it's a bit more sane to say that a maintainer may mount
up 4 kernels in 2 years to backport bugfixes into, if nobody else steps
up to the plate to help.
Of course, eventually official support has to be dropped in either
scheme, because the same problem is faced: We can't expect people to
maintain a continuously mounting number of kernel revisions once the
workload becomes sufficiently high. A balance must be made between
dropping support for a non-volitile code base, and maintaining a support
period sufficiently long.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfrg7hDd4aOud5P8RAo5eAJ4/lbCRuNfVM9iNoNaEOBX5wdqTlwCfWUK7
XM9z2dgXmkMWg28xZzlWeMI=
=edrQ
-----END PGP SIGNATURE-----
On Tue, 26 Oct 2004 16:48:59 -0400, John Richard Moser
<[email protected]> wrote:
[...]
>
> | We, of course, need a maintainer for it,
>
> Yes, a little too much to maintain though isn't it? Maintainers to
> continuously upkeep revisions that come out every few weeks potentially?
> ~ Remember it's got to be able to withstand the test of time for quite a
> while; why are people still maintaining 2.2?
>
> | maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> | for a long time), maybe Alan (that is already applying these kind of
> | fixes to his tree), maybe someone else... ?
> |
>
> Common courteousy, don't volunteer people. :)
Just wrote name a few "famous" and "great" kernel hackers :)
> | Sounds reasonable ?
> |
>
> Sounds too fast. I don't predict having a maintainer for each minor
> release of the kernel (which is what you're saying here essentially), so
> there'd be a need for one or a handfull of maintainers to spend loads of
> time backporting fixes to a quickly mounting set of kernels.
Yes, one maintainer.
But I'm not sure that each minor release of ther kernel needs a .Y version.
> I had <shameless plug> suggested an hour or two ago a scheme where the
> current development model be based off, but periodic releases be made
> "stable," basing on approximately 6 months between releases </shameless
> plug>. I think it's a bit more sane to say that a maintainer may mount
> up 4 kernels in 2 years to backport bugfixes into, if nobody else steps
> up to the plate to help.
>
> Of course, eventually official support has to be dropped in either
> scheme, because the same problem is faced: We can't expect people to
> maintain a continuously mounting number of kernel revisions once the
> workload becomes sufficiently high. A balance must be made between
> dropping support for a non-volitile code base, and maintaining a support
> period sufficiently long.
Not sure I get your point.
Again,
-ac is almost what I'm suggesting but I'd prefer to change it's name
and formalize it publishing the .Y patchset to kernel,org with a name
useful for the users.
Time to sleep now,
I'll flight to Germany tomorrow so I'll be offline till Tuesday.
But hey, you don't need me anymore ;-)
--
Paolo
On Tuesday 26 October 2004 07:09, Massimo Cetra wrote:
> > On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > > Bill Davidsen wrote:
> > >
> > > > I don't see the need for a development kernel, and it is
> > desirable
> > > > to be
> > > > able to run kernel.org kernels.
> > >
> > > Problem is, kernel.org 'release' kernels are quite buggy. For
> > > example 2.6.9 has a long list of bugs:
> > >
> > > Sure, the next release will (may?) fix these bugs, but it will
> > > definitely add a whole set of new ones.
> >
>
> > To my mind this just points out the need for a bug fix
> > branch. e.g. a
> > branch containing just bug/security fixes against the current
> > stable kernel. It might also be worth keeping the branch
> > active for the n-1 stable kernel too.
>
> To my mind, we only need to make clear that a stable kernel is a stable
> kernel.
> Not a kernel for experiments.
>
> To my mind, stock 2.6 kernels are nice for nerds trying patches and
> willing to recompile their kernel once a day. They are not suitable for
> servers. Several times on testing machines, switching from a 2.6 to the
> next one has caused bugs on PCI, acpi, networking and so on.
>
> The direction is lost. How many patchsets for vanilla kernel exist?
>
> Someone has decided that linux must go on desktops as well and
> developing new magnificent features for desktop users is causing serious
> problems to the ones who use linux at work on production servers.
>
> 2.4 tree is still the best solution for production.
> 2.6 tree is great for gentoo users who like gcc consuming all CPU
> (maxumum respect to gentoo but I prefer debian)
The issue is that Linus _has_ changed the development model. What we have
now is more flexable and much more responsive to changes. This does
lead to stable releases that are not quite a stable as some of the previous
stable series... This is why I suggest a fix/security branch. The idea being
that after a month or so of fixes etc it will be a very stable kernel and it will
not have slowed down development.
Ed
On Tue, 26 Oct 2004 at 10:37:06 -0700 William Lee Irwin III wrote:
>> "It works for me" doesn't cut it in the OS world.
>
> It's an existence proof spanning a wide swath of architectures. If
> you are not seeing similar results, send bugreports.
I don't neeed to send in bug reports, there are plenty on l-k
right now:
- LVM is currently broken in 2.6.9-mm1
- the RTC and NMI code have a race condition between them
- NFS mount won't accept a FQDN over 50 bytes (patch was
sent and utterly ignored, then recently reposted)
- cdrom driver thinks non-mt. rainier drives are capable
> Point releases are in fact updated and maintained. Those updates
> are given the name of the next point release.
Are you saying people who encounter bugs in 2.6.9 should wait for
2.6.10? ...and when they find bugs in _that_ release they should keep
waiting? In other words, Zeno was right after all?
--Chuck Ebbert 26-Oct-04 17:23:57
On Tuesday 26 October 2004 07:00 pm, Chuck Ebbert wrote:
> ? Are you saying people who encounter bugs in 2.6.9 should wait for
> 2.6.10? ?...and when they find bugs in _that_ release they should keep
> waiting?
Hmm, what people do when they find a bug in 2.4.27 release? Wait for 2.4.28?
Oh, horror!
--
Dmitry
On Tuesday 26 October 2004 07:00 pm, Chuck Ebbert wrote:
>> ? Are you saying people who encounter bugs in 2.6.9 should wait for
>> 2.6.10? ?...and when they find bugs in _that_ release they should keep
>> waiting?
On Tue, Oct 26, 2004 at 07:24:24PM -0500, Dmitry Torokhov wrote:
> Hmm, what people do when they find a bug in 2.4.27 release? Wait for
> 2.4.28? Oh, horror!
Apply a patch for the bugfix once it comes out. This is not news.
-- wli
On Tue, 26 Oct 2004 at 10:37:06 -0700 William Lee Irwin III wrote:
>> It's an existence proof spanning a wide swath of architectures. If
>> you are not seeing similar results, send bugreports.
On Tue, Oct 26, 2004 at 08:00:09PM -0400, Chuck Ebbert wrote:
> I don't neeed to send in bug reports, there are plenty on l-k
> right now:
> - LVM is currently broken in 2.6.9-mm1
> - the RTC and NMI code have a race condition between them
> - NFS mount won't accept a FQDN over 50 bytes (patch was
> sent and utterly ignored, then recently reposted)
> - cdrom driver thinks non-mt. rainier drives are capable
None of the bugs you cite were recently introduced.
On Tue, 26 Oct 2004 at 10:37:06 -0700 William Lee Irwin III wrote:
>> Point releases are in fact updated and maintained. Those updates
>> are given the name of the next point release.
On Tue, Oct 26, 2004 at 08:00:09PM -0400, Chuck Ebbert wrote:
> Are you saying people who encounter bugs in 2.6.9 should wait for
> 2.6.10? ...and when they find bugs in _that_ release they should keep
> waiting? In other words, Zeno was right after all?
Bad idea to try this kind of argument with someone from a domain such as
holomorphy.com. Zeno's mischaracterization of limit arguments was
erroneous and furthermore is irrelevant to discrete models of phenomena,
which don't have indefinite divisibility. In fact, these quantities of
bugs correspond to natural numbers, which yield to infinite descent
arguments, and satisfy descending chain conditions of various kinds.
These are of the form "every descending chain stabilizes", a fortuitous
choice of wording on Artin's part. =)
Upgrade to the later release to get fixes for a given release. This is
not difficult to understand. No point release is "orphaned". The results
of maintaining a point release are the subsequent point releases.
You may also have to face the fact of life that you may actually have to
apply a patch to fix a bug if there's no release to move to yet.
-- wli
On Tuesday 26 October 2004 23:44, Paolo Ciarrocchi wrote:
> If the goal of -ac is to only include those fixes, why can't we rename
> it in something more "intuitive" for the final users ?
> Do you see what I mean ?
"Final users" are those like me, who so far are quite satisfied[1] with the
distribution kernel. Advanced users will be aware of the existence of
other than kernel.org versions of the kernel, and will hopefully be able
to pick one suited to their particular fuzzy feelings.
During 2.4 development (IIRC) it was somewhat fairly generic knowledge
amongst those who had progressed marginally beyond booting linux, to
compiling some kernel from sources, what -ac postfix meant. Why that
sort of community knowledge osmosis wouldn't be possible or active today
also, I do not know. Perhaps people are just in general afraid of change.
[1] As in, the Fedora Core 2 kernel did not immediately give me such awful
performance that it made me get a kernel.org kernel to get back the magnitude
or so performance loss of the typical Redhat9 kernel. Benchmarks purely
subjective of course, sorry. :-/
On Tue, 26 Oct 2004 at 22:44:21 +0200 Paolo Ciarrocchi wrote:
>
>> 2.6-ac seems to be filling this role right now.
>>
>
> If the goal of -ac is to only include those fixes, why can't we rename
> it in something more "intuitive" for the final users ?
> Do you see what I mean ?
AFAICT -ac is not supposed to be a complete collection of bugfixes.
2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)
--Chuck Ebbert 26-Oct-04 20:33:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 26 Oct 2004, William Lee Irwin III wrote:
>>> It's an existence proof spanning a wide swath of architectures. If
>>> you are not seeing similar results, send bugreports.
>>
>> I don't neeed to send in bug reports, there are plenty on l-k
>> right now:
>> - LVM is currently broken in 2.6.9-mm1
>> - the RTC and NMI code have a race condition between them
>> - NFS mount won't accept a FQDN over 50 bytes (patch was
>> sent and utterly ignored, then recently reposted)
>> - cdrom driver thinks non-mt. rainier drives are capable
>
> None of the bugs you cite were recently introduced.
Is it relevant?
They exist, they must be fixed. If there is relevancy in this issue, the matter
is "why do we care more about recently introduced bugs (that can be avoided by
using a not-so-recent kernel) instead of caring about those well-known
long-dated bugs?".
Mind Booster Noori
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFBfwvCmNlq8m+oD34RAo55AJ9cOHkhxYnA21anwlWkDj34V51KNACg48Pt
yqOQ1GX/Xgszr6yNft/2BL4=
=VeDx
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 26 Oct 2004, Chuck Ebbert wrote:
>>> "It works for me" doesn't cut it in the OS world.
>>
>> It's an existence proof spanning a wide swath of architectures. If
>> you are not seeing similar results, send bugreports.
>
> I don't neeed to send in bug reports, there are plenty on l-k
> right now:
If there are bugs not yet reported, you should report them. The number of
yet-to-be-fixed bugs shouldn't make you not to report the others...
Mind Booster Noori
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFBfwxCmNlq8m+oD34RAl9jAJ9FWzkM96WUJks443s258iyhY0vgACfRyvh
rQ+cm7HPeHKvtzqAOv7Ulso=
=e9Uc
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 26 Oct 2004, Ed Tomlinson wrote:
>> 2.4 tree is still the best solution for production.
>> 2.6 tree is great for gentoo users who like gcc consuming all CPU
>> (maxumum respect to gentoo but I prefer debian)
>
> The issue is that Linus _has_ changed the development model. What we have
> now is more flexable and much more responsive to changes. This does
> lead to stable releases that are not quite a stable as some of the previous
> stable series... This is why I suggest a fix/security branch. The idea being
> that after a month or so of fixes etc it will be a very stable kernel and it will
> not have slowed down development.
The sole existence of this discussion prooves that there's already the need of
a new step. But why trying to re-invent the wheel? Yes, relating to 2.6 we need
already a "very stable kernel" and a "not-slowed down development kernel". When
it happened in 2.4 2.5 was created. Isn't all this just the indication that we
need a 2.6 development like 2.4 is, and we need 2.7 to be created?
Mind Booster Noori
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFBfxBtmNlq8m+oD34RAtIwAKDjVsTaY8v5EB8jfYqGywlziU3WfACfZ6dH
XlhH9UPCngBYZ8R1mrHusSs=
=PxeH
-----END PGP SIGNATURE-----
On Tue, 26 Oct 2004, William Lee Irwin III wrote:
>> None of the bugs you cite were recently introduced.
On Wed, Oct 27, 2004 at 03:45:21AM +0100, Marcos D. Marado Torres wrote:
> Is it relevant? They exist, they must be fixed. If there is relevancy
> in this issue, the matter is "why do we care more about recently
> introduced bugs (that can be avoided by using a not-so-recent kernel)
> instead of caring about those well-known long-dated bugs?".
It is highly relevant. The argument against the development process
is on the basis of regressions introduced in subsequent versions.
When I point this out, the examples of "regressions" are invalidated,
because they are in fact not introduced or reintroduced by new releases,
and therefore not regressions at all.
Your "point", as it were, is different and incorrect on different
grounds. Waiting to fix all known bugs to issue a release will fail to
make forward progress of any kind, at the very least from "WONTFIX"
bugs, and more commonly from bugs so hard they require extended periods
of time to make progress in fixing, e.g. my current sun4d woes.
Perhaps the myth of utopias where all bugs are trivially fixable must
be dispelled. I'm not a specialist in communicating with laymen, so
my take on it is this:
Not all bugs are trivially fixable. The longstanding bugs you're
complaining about are not getting fixed because they are so hard
to fix the entire kernel programmer population of the Linux
community can't solve them in a timely fashion. They are being
worked on. We can't stop the world because of this because the
kernel is so big there are hundreds or more of these unsolved bugs
in the kernel at any given time and many of them last for years.
So we have to continue doing other things while these bugs are open.
-- wli
On Tue, 26 Oct 2004, Ed Tomlinson wrote:
> The issue is that Linus _has_ changed the development model. What we have
> now is more flexable and much more responsive to changes. This does
> lead to stable releases that are not quite a stable as some of the previous
> stable series...
I can't remember a single stable kernel series that was as
stable as the 2.6 kernel. In 1.2, 2.0, 2.2 and 2.4 there were
huge problems dealing with the rate of change that's required
to fix everybody's problems.
You have to realise that you have to choose between changing
things quickly, or leaving people's bugs unfixed. When you
have millions of users, you cannot both fix everybody's problems
and keep a low rate of change.
The traditional approach has been opening up a development
kernel branch, but this means lots of fixes and new features
are not present in the stable kernel, and need to be backported
by the various distributions.
All in all, I think the 2.6 kernel is doing significantly better
than any of the stable kernel series I've seen before.
> This is why I suggest a fix/security branch. The idea being that after
> a month or so of fixes etc it will be a very stable kernel and it will
> not have slowed down development.
This is a good idea, though it is a very fine line between a
fix and a feature. There needs to be a very clear policy on
which kind of patches are acceptable and which aren't.
--
"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 Wed, 27 Oct 2004, Marcos D. Marado Torres wrote:
> When it happened in 2.4 2.5 was created. Isn't all this just the
> indication that we need a 2.6 development like 2.4 is, and we need 2.7
> to be created?
While a 2.7 series might provide developers with an "outlet"
for their creativity, it does not give users the availability
of the features they need.
Most features are developed because a user needs them now,
so having the users wait until 2.8 is not acceptable. Making
the distributions backport the needed features into 2.6 leads
to lots of duplicate effort and some code fragmentation.
I like the way 2.6 is currently being handled.
--
"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 Wed, Oct 27, 2004 at 12:29:10AM -0400, Rik van Riel wrote:
> On Wed, 27 Oct 2004, Marcos D. Marado Torres wrote:
>
> > When it happened in 2.4 2.5 was created. Isn't all this just the
> > indication that we need a 2.6 development like 2.4 is, and we need 2.7
> > to be created?
>
> While a 2.7 series might provide developers with an "outlet"
> for their creativity, it does not give users the availability
> of the features they need.
Rik, "new features" are what causes the kernel to be in permanent development
mode. It happened to all of us that a new feature broke compatability with a
patch or even caused a side effect. Users don't "need" new features, they
*want* them. This is what makes them upgrade to the new release in a fast
release model. If 2.4 had been released sooner, USB would never have made
it in 2.2, and 2.2 users would have switched faster. I know people who still
use 2.2 only on their dev systems because they don't need any upgrade.
If you think that new features is something absolutely necessary, then we
could have a permanent 4-digit kernel version. The third one would indicate
new features, and the fourth one only bug fixes. One could be running
2.6.9.5 with 2.6.9 features and a few fixes. But I thought that was was the
2nd and 3rd digits already were for (the 2nd one is called "PATCHLEVEL").
> Most features are developed because a user needs them now,
> so having the users wait until 2.8 is not acceptable.
yes it would be acceptable if 2.8 was expected only half a year from now.
> Making
> the distributions backport the needed features into 2.6 leads
> to lots of duplicate effort and some code fragmentation.
I agree, and it also causes incompatibility between systems. I recently
sadly discovered that RHEL 3.0 was not "Linux" anymore, but "RHEL". With
all the 2.6 backports into 2.4, you cannot make it boot on a true 2.4
anymore. Very sad indeed.
Cheers,
Willy
On Wed, Oct 27, 2004 at 12:29:10AM -0400, Rik van Riel wrote:
>> While a 2.7 series might provide developers with an "outlet"
>> for their creativity, it does not give users the availability
>> of the features they need.
On Wed, Oct 27, 2004 at 07:13:42AM +0200, Willy Tarreau wrote:
> Rik, "new features" are what causes the kernel to be in permanent development
> mode. It happened to all of us that a new feature broke compatability with a
> patch or even caused a side effect. Users don't "need" new features, they
> *want* them. This is what makes them upgrade to the new release in a fast
> release model. If 2.4 had been released sooner, USB would never have made
> it in 2.2, and 2.2 users would have switched faster. I know people who still
> use 2.2 only on their dev systems because they don't need any upgrade.
The new features you're complaining about are astoundingly not the
causes of any of the bugs cited as critical issues in this thread.
It also appears that you have forgotten early 2.4 at the very least...
-- wli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcos D. Marado Torres wrote:
| On Tue, 26 Oct 2004, Ed Tomlinson wrote:
|
|>>> 2.4 tree is still the best solution for production.
|>>> 2.6 tree is great for gentoo users who like gcc consuming all CPU
|>>> (maxumum respect to gentoo but I prefer debian)
|>>
|>>
|>> The issue is that Linus _has_ changed the development model. What we
|>> have
|>> now is more flexable and much more responsive to changes. This does
|>> lead to stable releases that are not quite a stable as some of the
|>> previous
|>> stable series... This is why I suggest a fix/security branch. The
|>> idea being
|>> that after a month or so of fixes etc it will be a very stable kernel
|>> and it will
|>> not have slowed down development.
|
|
| The sole existence of this discussion prooves that there's already the
| need of
| a new step. But why trying to re-invent the wheel? Yes, relating to 2.6
| we need
| already a "very stable kernel" and a "not-slowed down development
| kernel". When
| it happened in 2.4 2.5 was created. Isn't all this just the indication
| that we
| need a 2.6 development like 2.4 is, and we need 2.7 to be created?
|
Another shameless plug for me:
http://lkml.org/lkml/2004/10/26/171
Short version to save you reading of my spam:
Let's make 2.7 what 2.6 is now (a relatively stable kernel that gets
relatively stable feature enhancements continuously), rather than what
2.5 was (a hell of a lot of patches and then a hell of a lot of
debugging), and make 2.6 more restrictive than 2.4 in that it should be
strictly bugfixes (including security bugs) and no backported drivers or
features.
I read a page about open source software development once, I don't
remember if it was an article or a book or what; but it said something
I've held to heart for a while: Open source projects tend to follow the
poorly designed development model of alternating between a "stable" and
an "unstable" branch, when it's possible to simply perpetually add
stablized, debugged features straight to mainline after they've been
developed independently on the side.
It is apparent that what we have here is exactly what the author
suggested in place of the stable/unstable cycle; it is also apparent
that this is a naiive model not because it becomes difficult to avoid
bugs, but because it becomes difficult to actually develope on the side
with all of the changes happening to mainline. By combining both
models, a balance is met.
This same model can be implemented as a meta-model (or something) if the
external projects chose on their own which versions to freeze at. This
creates a problem, however, as patches for these projects become
distributed across ranges of versions. Consider having a development
driver for 2.6.7 for an ADSL card; a development driver for 2.6.5 for a
network card; and a development DRM driver for 2.6.10 for a particular
video card. The unfortunate soul having all three of these pieces of
hardware is quite SOL.
On the other hand, there are those who simply get fed up chasing the
volatile codebase of mainline, ad simply wait for it to stabalize.
Unless you throw them their bone, they won't get any work done; this is
not only their problem, but their users' as well.
| Mind Booster Noori
|
| -- /* *************************************************************** */
| Marcos Daniel Marado Torres AKA Mind Booster Noori
| http://student.dei.uc.pt/~marado - [email protected]
| () Join the ASCII ribbon campaign against html email, Microsoft
| /\ attachments and Software patents. They endanger the World.
| Sign a petition against patents: http://petition.eurolinux.org
| /* *************************************************************** */
-
On Tue, Oct 26, 2004 at 10:23:21PM -0700, William Lee Irwin III wrote:
<...>
> It also appears that you have forgotten early 2.4 at the very least...
Oh yes I remember... I was very interested because of netfilter and ramfs
but couldn't use it because of its awful stability. That was when I started
complaining about linux development model, where new features were more
important than bug fixes, which resulted in no usable kernel before 2.4.18.
Cheers,
Willy
On Tue, Oct 26, 2004 at 10:23:21PM -0700, William Lee Irwin III wrote:
>> It also appears that you have forgotten early 2.4 at the very least...
On Wed, Oct 27, 2004 at 08:04:33AM +0200, Willy Tarreau wrote:
> Oh yes I remember... I was very interested because of netfilter and ramfs
> but couldn't use it because of its awful stability. That was when I started
> complaining about linux development model, where new features were more
> important than bug fixes, which resulted in no usable kernel before 2.4.18.
2.6.x has taken a rather different path from 2.4.x
-- wli
At some point in the past, my attribution was mercilessly stripped from:
> > 2.6.x has taken a rather different path from 2.4.x
On Wed, Oct 27, 2004 at 08:50:35AM +0200, Massimo Cetra wrote:
> However, results are similar.
> 2.6 seems to work better than 2.4 in "early stage of stable branch" but
> It's quite impossible to set up a production server on 2.6.x, optimize
> it and keeping the same performance with 2.6.(x+2).
Bull. It's already been done, numerous times.
On Wed, Oct 27, 2004 at 08:50:35AM +0200, Massimo Cetra wrote:
> Iosched has a lot of flavours, with performance worse than 2.4 (at least
> for databases).
> Swap is a misterious thing and It needs a degree in swappiness to
> understand how it works and how it changes.
Your complaint is a mysterious thing and needs a degree in mind-reading
to understand what you're trying to claim and how it's changed from the
last post.
In other words, rephrase this in some remotely scientific manner so
it's unambiguous and comprehensible.
On Wed, Oct 27, 2004 at 08:50:35AM +0200, Massimo Cetra wrote:
> I see a lot of efforts in making a top-performance kernel but these
> efforts are not compatible with a stable-tree.
> Stable means not only that the kernel does not hangs, but that features
> remains (almost) the same for a reasonable amount of time.
Backward compatibility remains a strict requirement as always, and
removals of features are still only allowed during major release cycles
e.g. between 2.4 and 2.6, after having given notice during 2.2.
-- wli
> On Wed, Oct 27, 2004 at 08:04:33AM +0200, Willy Tarreau wrote:
> > Oh yes I remember... I was very interested because of netfilter and
> > ramfs but couldn't use it because of its awful stability. That was
> > when I started complaining about linux development model, where new
> > features were more important than bug fixes, which resulted in no
> > usable kernel before 2.4.18.
>
> 2.6.x has taken a rather different path from 2.4.x
However, results are similar.
2.6 seems to work better than 2.4 in "early stage of stable branch" but
It's quite impossible to set up a production server on 2.6.x, optimize
it and keeping the same performance with 2.6.(x+2).
Iosched has a lot of flavours, with performance worse than 2.4 (at least
for databases).
Swap is a misterious thing and It needs a degree in swappiness to
understand how it works and how it changes.
I see a lot of efforts in making a top-performance kernel but these
efforts are not compatible with a stable-tree.
Stable means not only that the kernel does not hangs, but that features
remains (almost) the same for a reasonable amount of time.
Max
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Willy Tarreau wrote:
| On Wed, Oct 27, 2004 at 12:29:10AM -0400, Rik van Riel wrote:
|
|>On Wed, 27 Oct 2004, Marcos D. Marado Torres wrote:
|>
|>
|>>When it happened in 2.4 2.5 was created. Isn't all this just the
|>>indication that we need a 2.6 development like 2.4 is, and we need 2.7
|>>to be created?
|>
|>While a 2.7 series might provide developers with an "outlet"
|>for their creativity, it does not give users the availability
|>of the features they need.
|
|
| Rik, "new features" are what causes the kernel to be in permanent
development
| mode. It happened to all of us that a new feature broke compatability
with a
| patch or even caused a side effect. Users don't "need" new features, they
| *want* them.
Strong point.
[...]
|
| If you think that new features is something absolutely necessary, then we
| could have a permanent 4-digit kernel version.
Undue work. The current high-speed development model could be reused as
2.7's development model. Since it's good enough to use on the stable
tree, it can be said that 2.7 will always be stable, and so it can be
released often. Also, distributions/users can cling to 2.7 and use it
freely without worrying that it's an explosive dev kernel that will eat
their hard drives.
[...]
|
|
|>Most features are developed because a user needs them now,
|>so having the users wait until 2.8 is not acceptable.
|
|
| yes it would be acceptable if 2.8 was expected only half a year from now.
Half year release cycle, as I said in my proposal[1], using a volatile
but usable tree (as 2.6 is now) instead of a flat out unstable tree (as
2.5 was) for the odd majors. I think we can endure another 3 months of
the kernel acting up like this, and then freeze it January 31 and branch
it to 2.7 with the same behavior as it has now WRT patching and new
features; of course, that's not my call.
[1] http://lkml.org/lkml/2004/10/26/171
What's important here is to keep the current development model in
spirit. It's obviously working if you can call a very volatile tree
"stable," so we shouldn't revert completely to stone-age methods; but
having a defined release cycle is easy if the development trees are
handled as 2.6 is now.
|
|
|>Making
|>the distributions backport the needed features into 2.6 leads
|>to lots of duplicate effort and some code fragmentation.
|
|
| I agree, and it also causes incompatibility between systems. I recently
| sadly discovered that RHEL 3.0 was not "Linux" anymore, but "RHEL". With
| all the 2.6 backports into 2.4, you cannot make it boot on a true 2.4
| anymore. Very sad indeed.
|
Dude, lots of crap won't boot 2.4. Try booting Reiser4 on 2.4 (there's
no reiser4 for 2.4).
| Cheers,
| Willy
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBf6TKhDd4aOud5P8RAhVCAJwMugUdGgYnezh3/ONjNQWIppuetwCfUppX
pQfKCRw3rwFXOeJO2NtFdmg=
=VgEV
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Lee Irwin III wrote:
| On Wed, Oct 27, 2004 at 12:29:10AM -0400, Rik van Riel wrote:
|
|>>While a 2.7 series might provide developers with an "outlet"
|>>for their creativity, it does not give users the availability
|>>of the features they need.
|
|
| On Wed, Oct 27, 2004 at 07:13:42AM +0200, Willy Tarreau wrote:
|
|>Rik, "new features" are what causes the kernel to be in permanent
development
|>mode. It happened to all of us that a new feature broke compatability
with a
|>patch or even caused a side effect. Users don't "need" new features, they
|>*want* them. This is what makes them upgrade to the new release in a fast
|>release model. If 2.4 had been released sooner, USB would never have made
|>it in 2.2, and 2.2 users would have switched faster. I know people who
still
|>use 2.2 only on their dev systems because they don't need any upgrade.
|
|
| The new features you're complaining about are astoundingly not the
| causes of any of the bugs cited as critical issues in this thread.
|
I for one don't give a damn. Bugs and how fast this development model
fix them aren't a concern to me; although I'd never slow down the bug
fixing process. My concern is getting a real stable tree for various
maintainers to base on, so that various patches for drivers, security
enhancements, and other things aren't scattered across versions and
impossible to patch together even when they're noninvasive to eachother.
Have you stopped to consider that the features that are critical to me
are also holding me back from upgrading to the newer kernels?
Ironically, these are security features, and the newer kernels have
newer security fixes aside from new schedulers and other toys I could
really enjoy having around.
| It also appears that you have forgotten early 2.4 at the very least...
|
|
| -- wli
| -
| 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.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBf6cPhDd4aOud5P8RAhWIAJ4u8W+KobiYoGKhsXEqw5TL+zUIggCaAueL
AWGds1692rVAhFb/+KHiyvM=
=jB3R
-----END PGP SIGNATURE-----
On Wed, Oct 27, 2004 at 09:48:01AM -0400, John Richard Moser wrote:
>
> I for one don't give a damn. Bugs and how fast this development model
> fix them aren't a concern to me; although I'd never slow down the bug
> fixing process. My concern is getting a real stable tree for various
> maintainers to base on, so that various patches for drivers, security
> enhancements, and other things aren't scattered across versions and
> impossible to patch together even when they're noninvasive to eachother.
>
> Have you stopped to consider that the features that are critical to me
> are also holding me back from upgrading to the newer kernels?
> Ironically, these are security features, and the newer kernels have
> newer security fixes aside from new schedulers and other toys I could
> really enjoy having around.
So instead of kvetching, why don't you
(a) Create your own stable series by snapshotting some 2.6.x tree
every six months, and then maintain a set of bug-fix only patches
against that 2.6.x tree? Then convince the security people to port to
that particular 2.6.x-jrm tree?
(b) Convince the security folks to try to get their patches into the
mm- tree, for eventual inclusion into 2.6.
(c) Some combination of the two.
Either would probably be more likely to fulfill your needs than just
whining about it.
- Ted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Theodore Ts'o wrote:
| On Wed, Oct 27, 2004 at 09:48:01AM -0400, John Richard Moser wrote:
|
|>I for one don't give a damn. Bugs and how fast this development model
|>fix them aren't a concern to me; although I'd never slow down the bug
|>fixing process. My concern is getting a real stable tree for various
|>maintainers to base on, so that various patches for drivers, security
|>enhancements, and other things aren't scattered across versions and
|>impossible to patch together even when they're noninvasive to eachother.
|>
|>Have you stopped to consider that the features that are critical to me
|>are also holding me back from upgrading to the newer kernels?
|>Ironically, these are security features, and the newer kernels have
|>newer security fixes aside from new schedulers and other toys I could
|>really enjoy having around.
|
|
| So instead of kvetching, why don't you
|
| (a) Create your own stable series by snapshotting some 2.6.x tree
| every six months, and then maintain a set of bug-fix only patches
| against that 2.6.x tree? Then convince the security people to port to
| that particular 2.6.x-jrm tree?
|
- - Convince the security people
- -- PaX, GrSecurity (2.6.7)
- -- LIDS (2.6.8.1) (not my problem)
- -- RSBAC (The author works his ass off, 2.6.6-9)
- - Convince VM hacker projects
- -- linuxcompressed is dead anyway; but they'd have a hard time keeping
~ up; there's been VM changes a few times already ne?
- - Convince filesystem and driver projects. No particular examples,
~ although I could see things happening that would affect them (another
~ reason why we need a fully upwards-compatible driver ABI)
| (b) Convince the security folks to try to get their patches into the
| mm- tree, for eventual inclusion into 2.6.
|
I've tried that. They don't want to. I don't blame them.
What I *am* aiming for is getting a few security enhancements included
in mainline for several Linux distributions, starting with Debian and
Ubuntu. This will predictibly create a blockage at 2.6.7 (where
PaX/GRSec are, since those are a major part of the scheme); they won't
be able to upgrade past there without losing a major protection, and the
authors will likely continue to simply sit around and wait for 2.6 to
stop changing so damn much.
| (c) Some combination of the two.
|
| Either would probably be more likely to fulfill your needs than just
| whining about it.
|
| - Ted
| -
| 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.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBf8AshDd4aOud5P8RAjwtAJ4je6e8ubxmnMJexVY0Db6JSNRPLwCeMvNY
HjEB1Ve+ZSdToiwPOsMJWnM=
=DJkR
-----END PGP SIGNATURE-----
On Mer, 2004-10-27 at 03:17, Chuck Ebbert wrote:
> > If the goal of -ac is to only include those fixes, why can't we rename
> > it in something more "intuitive" for the final users ?
> > Do you see what I mean ?
>
> AFAICT -ac is not supposed to be a complete collection of bugfixes.
> 2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)
The goal of -ac is to contain the stuff I personally consider important.
A lot of the smaller bugfixes individually are fine but a 'complete set
of bugfixes' turns into a large change set and then needs an entire
validation and release cycle of its own.
Each 2.6.10rc change I merged is on the basis of reward >> risk.
I don't care if its 2.6.9-ac or 2.6.9.4 personally but it's for Linus to
decide if he wants to do that and who he wants to make keeper of the
2.6.x.y tree if anyone.
Alan
On Maw, 2004-10-26 at 06:40, Chuck Ebbert wrote:
> - superio parports don't work
> - TCP networking using TSO gives memory allocation failures
> - s390 has a serious security bug (sacf)
> - ppp hangup is broken with some peers
> - exec leaks POSIX timer memory and loses signals
You missed the remote DoS attack 8(
> - i8042 fails to initialize with some boards using legacy USB
This is really a BIOS issue and its not a new 2.6.9 bug its a long
standing and messy story.
On Maw, 2004-10-26 at 20:33, Paul Fulghum wrote:
> ...and probably suffer emotional scars from the process.
> Taming the patch stream must be like drinking from a fire hose
> while herding angry, computer literate cats.
> Wearing, but not boring.
For 2.2 certainly and I suspect for 2.4 it's also like that. The
2.6.x.[1-n] is more like distribution maintenance its about careful
analysis and minimal changes.
On Maw, 2004-10-26 at 17:58, Hua Zhong wrote:
> The fact is, these days nobody wants to be a stable-release maintainer
> anymore. It's boring.
That depends what kind of an engineer you are. Just as there are people
who love standards body work and compliance testing/debugging there are
people who care about stable trees.
On Tue, 2004-10-26 at 09:58 -0700, Hua Zhong wrote:
> The fact is, these days nobody wants to be a stable-release maintainer
> anymore. It's boring.
I wouldn't mind doing some sort of bugfix kernel series it if people
think it'd be useful... but that's a big if.... the hard part of any
such tree is finding people who help testing, and yet the customers of
such a tree are those who only want proven stable stuff ;)
--
On Wed, Oct 27, 2004 at 10:57:45AM -0400, Theodore Ts'o wrote:
> So instead of kvetching, why don't you
> (a) Create your own stable series by snapshotting some 2.6.x tree
> every six months, and then maintain a set of bug-fix only patches
> against that 2.6.x tree? Then convince the security people to port to
> that particular 2.6.x-jrm tree?
> (b) Convince the security folks to try to get their patches into the
> mm- tree, for eventual inclusion into 2.6.
> (c) Some combination of the two.
> Either would probably be more likely to fulfill your needs than just
> whining about it.
Well, it's a bit worse than that, as the whining isn't really logically
self-consistent. Getting a few of these people in touch with reality so
they can actually move on to doing something productive looks like a
prerequisite to any kind of action on their parts.
But agreed on the principle of action being superior to complaining.
-- wli
On Wed, 27 Oct 2004 at 16:27 +0100 Alan Cox wrote:
> You missed the remote DoS attack 8(
Where?
>> - i8042 fails to initialize with some boards using legacy USB
>
> This is really a BIOS issue and its not a new 2.6.9 bug its a long
> standing and messy story.
And the patch in -ac fixes it but there is a cleaner one around
that does it more properly, right?
--Chuck Ebbert 27-Oct-04 15:35:39
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Oct 2004, John Richard Moser wrote:
> What I *am* aiming for is getting a few security enhancements included
> in mainline for several Linux distributions, starting with Debian and
> Ubuntu. This will predictibly create a blockage at 2.6.7 (where
> PaX/GRSec are, since those are a major part of the scheme); they won't
> be able to upgrade past there without losing a major protection, and the
> authors will likely continue to simply sit around and wait for 2.6 to
> stop changing so damn much.
Well, if your target is Debian and Ubunto for starts, then you're discussing
this in the wrong mailing list.
BTW, on Debian/unstable:
root@Atlantis:/usr/src/linux# apt-cache search kernel-image | grep 2.6.8
kernel-image-2.6.8-1-386 - Linux kernel image for version 2.6.8 on 386.
kernel-image-2.6.8-1-686 - Linux kernel image for version 2.6.8 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.6.8-1-686-smp - Linux kernel image for version 2.6.8 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.6.8-1-k7 - Linux kernel image for version 2.6.8 on AMD K7.
kernel-image-2.6.8-1-k7-smp - Linux kernel image for version 2.6.8 on AMD K7 SMP.
kernel-image-2.6.8-9-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems
kernel-image-2.6.8-9-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems
kernel-image-2.6.8-9-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems
kernel-image-2.6.8-9-em64t-p4 - Linux kernel image for version 2.6.8 on Intel EM64T systems
kernel-image-2.6.8-9-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems
kernel-tree-2.6.8 - Linux kernel tree for building prepackaged Debian kernel images
root@Atlantis:/usr/src/linux#
If you think the blockage is going to happen in 2.6.7, think twice.
Mind Booster Noori
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFBf/sVmNlq8m+oD34RAlbAAKCSDhKthrmCDC55xa03ZOPvN8iRhwCgtEyD
l9vq0gBflZHARKQIQ+OSq/c=
=eXD0
-----END PGP SIGNATURE-----
On Wed, 27 Oct 2004 at 16:05 +0100 Alan Cos wrote:
> Each 2.6.10rc change I merged is on the basis of reward >> risk.
I'm inclined to even accept very small patches that aren't really
bugfixes, like initmem poisoning and the signal delivery patch
that removes unconditional writes to dr7.
But some of the larger ones scare me, especially when they need
modification to apply cleanly. Even if the mods are clear, there
can be new logic elsewhere that breaks a backported patch.
--Chuck Ebbert 27-Oct-04 15:49:15
On Wed, 27 Oct 2004, John Richard Moser wrote:
> That's where the stuff I want put in is.
Nobody's stopping you from doing what you want to have done.
--
"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 Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
> When I said "nobody", I really meant "top kernel developers". I have not
> seen anyone step up and say "I'll volunteer to maintain a 2.6 stable
> release" hence the comment.
I'll do it if Linus wants
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcos D. Marado Torres wrote:
| On Wed, 27 Oct 2004, John Richard Moser wrote:
|
|>> What I *am* aiming for is getting a few security enhancements included
|>> in mainline for several Linux distributions, starting with Debian and
|>> Ubuntu. This will predictibly create a blockage at 2.6.7 (where
|>> PaX/GRSec are, since those are a major part of the scheme); they won't
|>> be able to upgrade past there without losing a major protection, and the
|>> authors will likely continue to simply sit around and wait for 2.6 to
|>> stop changing so damn much.
|
|
| Well, if your target is Debian and Ubunto for starts, then you're
| discussing
| this in the wrong mailing list.
| BTW, on Debian/unstable:
[...]
| If you think the blockage is going to happen in 2.6.7, think twice.
|
That's where the stuff I want put in is.
http://lwn.net/Articles/106214/
http://d-sbd.alioth.debian.org/
http://pax.grsecurity.net/
http://grsecurity.net/
http://en.wikipedia.org/wiki/PaX
PaX sits currently at 2.6.7 (and grsec is tied to PaX quite deeply, so
it sits there as well), so there's no using that for now past 2.6.7.
I've heard rumors of it getting some up-porting after a new component is
properly done (recall my assertions about having to chose between
chasing mainline and doing real work), but it's up to the PaX Team if
they want to do that or if they're just going to wait for a fork 2.6/2.7.
| Mind Booster Noori
|
| -- /* *************************************************************** */
| Marcos Daniel Marado Torres AKA Mind Booster Noori
| http://student.dei.uc.pt/~marado - [email protected]
| () Join the ASCII ribbon campaign against html email, Microsoft
| /\ attachments and Software patents. They endanger the World.
| Sign a petition against patents: http://petition.eurolinux.org
| /* *************************************************************** */
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBgA5YhDd4aOud5P8RAlDjAJ9yGRcCPbIaTDhGcWX8eZEBncph1wCfTHAD
ZPHADIODR3WP4DrRWV2YwlQ=
=V8OU
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Oct 2004, Arjan van de Ven wrote:
> I wouldn't mind doing some sort of bugfix kernel series it if people
> think it'd be useful... but that's a big if.... the hard part of any
> such tree is finding people who help testing, and yet the customers of
> such a tree are those who only want proven stable stuff ;)
You're going to have testers/users for sure, specially if you're relases appear
in kernel.org... That won't be your problem.
Mind Booster Noori
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFBf/a4mNlq8m+oD34RAlSDAKDP5gtubpS6lH+ziMEzsCfjr+X4pwCeO37A
F4Uw354WqtakT9fPJSIX0D4=
=Gsrs
-----END PGP SIGNATURE-----
Alan Cox wrote:
> On Mer, 2004-10-27 at 03:17, Chuck Ebbert wrote:
>
>>>If the goal of -ac is to only include those fixes, why can't we rename
>>>it in something more "intuitive" for the final users ?
>>>Do you see what I mean ?
>>
>> AFAICT -ac is not supposed to be a complete collection of bugfixes.
>> 2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)
>
>
> The goal of -ac is to contain the stuff I personally consider important.
> A lot of the smaller bugfixes individually are fine but a 'complete set
> of bugfixes' turns into a large change set and then needs an entire
> validation and release cycle of its own.
>
> Each 2.6.10rc change I merged is on the basis of reward >> risk.
Not to give you a swelled head, but at the moment -ac looks more stable
than anything else widely available.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Mer, 2004-10-27 at 20:50, Chuck Ebbert wrote:
> On Wed, 27 Oct 2004 at 16:27 +0100 Alan Cox wrote:
> > You missed the remote DoS attack 8(
> Where?
Posted to netdev along with fixes. See 2.6.9-ac1 or later
> >> - i8042 fails to initialize with some boards using legacy USB
> >
> > This is really a BIOS issue and its not a new 2.6.9 bug its a long
> > standing and messy story.
>
> And the patch in -ac fixes it but there is a cleaner one around
> that does it more properly, right?
The -ac fix handles one corner case. The right fix appears to be to
always disable USB legacy. But for a small fix its mighty risky.
Hey, you all hear the man!
Now stop complaining and give him a title. :-)
> -----Original Message-----
> From: Alan Cox [mailto:[email protected]]
> Sent: Wednesday, October 27, 2004 2:39 PM
> To: [email protected]
> Cc: 'John Richard Moser'; 'Espen Fjellv?r Olsen'; 'Linux
> Kernel Mailing List'
> Subject: RE: My thoughts on the "new development model"
>
> On Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
> > When I said "nobody", I really meant "top kernel developers".
> > I have not seen anyone step up and say "I'll volunteer to
> > maintain a 2.6 stable release" hence the comment.
>
> I'll do it if Linus wants
>
> On Maw, 2004-10-26 at 17:58, Hua Zhong wrote:
> > The fact is, these days nobody wants to be a stable-release
> >maintainer anymore. It's boring.
>
> That depends what kind of an engineer you are. Just as there
> are people who love standards body work and compliance
> testing/debugging there are people who care about stable trees.
Absolutely agreed. There are folks around me who can do one thing much
better than the other.
When I said "nobody", I really meant "top kernel developers". I have not
seen anyone step up and say "I'll volunteer to maintain a 2.6 stable
release" hence the comment.
This is actually not a problem caused by the new development model per se.
The same thing might have happened with 2.4. You know what I'm talking
about. Most talented people just like new challenges instead of maintaining
old code.
However, there are some things that make this situation worse by the new
model.
1. No official stable releases and thus no official maintainers. 2.6 is no
longer a stable release. 2.6.x might be. And Linus doesn't seem to plan to
endorse anyone for this job. Previously, Linus could appoint someone and
even if he is not really well-known, people would eventually accept him, but
now it's not the case anymore. More importantly, if there is no official
stable releases, whom do other people send bug fixes to? From both user and
developer perspective, this is very hard to work out.
2. The new version scheme. Now a stable release has to be 2.6.x. So instead
of being a 2.6 maintainer, you might be called a 2.6.x maintainer. One extra
number, less importance and recognicion, and less motivation for volunteers
to show up (especially for relatively new people). Just common psychology.
:)
These are just my observations. As far as I can see only two things will
help:
1. Appoint an official 2.6 maintainer. Be it someone Linus appoints, or
someone like Alan Cox who volunteers. :-)
2. This maintainer will not be stuck at only one 2.6.x version. Instead, he
maintains 2.6.x for a while until it is stable enough, and then move up to
2.6.y (y>x), and start the stabilization again.
Hua
On Wednesday 27 October 2004 04:40 pm, Alan Cox wrote:
> On Mer, 2004-10-27 at 20:50, Chuck Ebbert wrote:
> > On Wed, 27 Oct 2004 at 16:27 +0100 Alan Cox wrote:
> > > You missed the remote DoS attack 8(
> > Where?
>
> Posted to netdev along with fixes. See 2.6.9-ac1 or later
>
> > >> - i8042 fails to initialize with some boards using legacy USB
> > >
> > > This is really a BIOS issue and its not a new 2.6.9 bug its a long
> > > standing and messy story.
> >
> > And the patch in -ac fixes it but there is a cleaner one around
> > that does it more properly, right?
>
> The -ac fix handles one corner case. The right fix appears to be to
> always disable USB legacy. But for a small fix its mighty risky.
>
I really wonder why is it risky? 99% of the time USB is loaded eventually
and does handoff anyway. What is the problem doing it earlier? Ones who
indeed use USB in legacy mode will have to boot with "no-handoff". I think
if you look at the numbers people using USB in legacy mode is a fraction
of a percent.
Plus, now we suggest disabling legacy emulation in BIOS which is problematic
if one wants to use USB keyboard in boot loader... Automatic handoff will
help here.
--
Dmitry
John Richard Moser <[email protected]> writes:
[ .. lots of stuff .. ]
> Let's make 2.7 what 2.6 is now (a relatively stable kernel that gets
> relatively stable feature enhancements continuously), rather than what
> 2.5 was (a hell of a lot of patches and then a hell of a lot of
> debugging), and make 2.6 more restrictive than 2.4 in that it should be
> strictly bugfixes (including security bugs) and no backported drivers or
> features.
There seems to be a lot of strange notions on this concept of 'stable'.
The only thing that makes a kernel 'stable' is time. Not endless
bugfixes. Just time. The idea of stable software is software that not
going to give you any suprises, software that you can trust.
That's NOT the same as bug free software. For a start, there's no such
thing. For another, many bugs are perfectly acceptable in a production
environment as long as they're not impacting. (The linux kernel is a
very large piece of work. Few installations would use even 20% of the
total kernel functionality).
If you want a stable kernel version, pick one (almost any one will
do). Test the hell of out it with your application(s). If it fails,
fix the bug, or pick a different version. rinse, repeat.
Now you've got a kernel that tests clean with your app. DON'T
CHANGE IT!!
Ta-Dah! You've got a stable kernel.
Now why would you change it? The only possible reasons
are that your testing was terrible and you missed a bug,
in which case you can go back to step 1, or that you
want a new feature. In which case you can go back to
step 1.
That wasn't too hard, was it. Even better, you didn't see
anything in there about 2.6 v 2.7 or other such fluff.
Michael.
On Thu, Oct 28, 2004 at 04:46:58PM +1000, [email protected] wrote:
> That's NOT the same as bug free software. For a start, there's no such
> thing. For another, many bugs are perfectly acceptable in a production
> environment as long as they're not impacting. (The linux kernel is a
> very large piece of work. Few installations would use even 20% of the
> total kernel functionality).
I'd expect vastly less than 1%, starting from the arch count, and then
making some conservative guesses about drivers. Drivers probably
actually take it down to far, far less than 1%.
-- wli
> That's NOT the same as bug free software. For a start, there's no such
> thing.
Speaking of which, here's something I have wondered: is anyone out there
trying to prove the correctness of core functions in the kernel? I was
thinking this would be a fine activity for all those eager college students
out there, or perhaps a graduate student project, a la the Stanford Checker
project.
While I can't imagine the main developers doing such a thing, I think it'd be
useful and might uncover some hard to find bugs.
I'd also suspect that they might be good candidates for proving, as there's
not so much reason to have side effect riddled code, as one might for GUI
programs.
--
A psychosis is a psychosis, but a Manwich is a meal
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
> There seems to be a lot of strange notions on this concept of
> 'stable'. The only thing that makes a kernel 'stable' is
> time. Not endless bugfixes. Just time. The idea of stable
> software is software that not going to give you any suprises,
> software that you can trust.
>
> That's NOT the same as bug free software. For a start,
> there's no such thing. For another, many bugs are perfectly
> acceptable in a production environment as long as they're not
> impacting. (The linux kernel is a very large piece of work.
> Few installations would use even 20% of the total kernel
> functionality).
>
Yes, perfectly right.
You would agree (for example) that this:
> On Wed, 27 Oct 2004, Danny Brow wrote:
>
> Ok, thank you for the feedback, glad you fixed your problem.
> Now I guess we just need for someone to find out why
> LEGACY_PTYS breaks
> ssh (and other apps?) with kernels >= 2.6.9, but I'm afraid
> thats beyond
Does not reflect the behaviour of a stable kernel.
Yes, of course, there's the workaround. But I don't think this bug is
not impacting.
I repeat once again. To me something is going in the wrong direction.
Massimo
On Iau, 2004-10-28 at 03:59, Dmitry Torokhov wrote:
> I really wonder why is it risky? 99% of the time USB is loaded eventually
> and does handoff anyway. What is the problem doing it earlier? Ones who
> indeed use USB in legacy mode will have to boot with "no-handoff". I think
> if you look at the numbers people using USB in legacy mode is a fraction
> of a percent.
The code to do the mode switches is non trivial, has to handle errata
and the like. If you compile in USB rather than having it modular then
it'll work out fine too which is another reason not to add a hack to -ac
when there is a safer fix 8)
On Thu, 28 Oct 2004 at 00:13:44 -0700 William Lee Irwin III wrote:
> On Thu, Oct 28, 2004 at 04:46:58PM +1000, [email protected] wrote:
>> [...] many bugs are perfectly acceptable in a production
>> environment as long as they're not impacting. (The linux kernel is a
>> very large piece of work. Few installations would use even 20% of the
>> total kernel functionality).
>
> I'd expect vastly less than 1%, starting from the arch count, and then
> making some conservative guesses about drivers. Drivers probably
> actually take it down to far, far less than 1%.
Sure, but pretty much each installation uses a different 1%.
If there's a bug in there it's bound to hit someone; that's
what makes OS writing so difficult. (And that's why "It works
for me" is not really a useful statement about the overall quality
of an operating system.)
--Chuck Ebbert 28-Oct-04 09:00:36
On Thu, 2004-10-28 at 09:04 -0400, Chuck Ebbert wrote:
> > I'd expect vastly less than 1%, starting from the arch count, and then
> > making some conservative guesses about drivers. Drivers probably
> > actually take it down to far, far less than 1%.
>
>
> Sure, but pretty much each installation uses a different 1%.
this is where the 80/20 rule holds:
80% of the people use the same 20 drivers ;)
so it's not as extreme as your words suggest (ok I cut a bunch out); but linux has so many users that even the few percent of users that has a less common setup leads to bugreport. And unlike some other OS'es, we all get to see all those reports...
On Thu, 28 Oct 2004 at 00:13:44 -0700 William Lee Irwin III wrote:
>> I'd expect vastly less than 1%, starting from the arch count, and then
>> making some conservative guesses about drivers. Drivers probably
>> actually take it down to far, far less than 1%.
On Thu, Oct 28, 2004 at 09:04:41AM -0400, Chuck Ebbert wrote:
> Sure, but pretty much each installation uses a different 1%.
> If there's a bug in there it's bound to hit someone; that's
> what makes OS writing so difficult. (And that's why "It works
> for me" is not really a useful statement about the overall quality
> of an operating system.)
99.99% of users use one arch, i386.
99.99% of users use one disk driver, IDE.
The intersection of these users is probably well over 99.999% of all
users.
Then probably a small list of secondary drivers varies. Statistically,
users with anything but the crappiest x86 s**tboxen and a tiny subset
of all drivers (arjan's 20) are hopelessly outnumbered.
-- wli
On Thu, Oct 28, 2004 at 08:03:29AM -0700, William Lee Irwin III wrote:
> 99.99% of users use one arch, i386.
> 99.99% of users use one disk driver, IDE.
> The intersection of these users is probably well over 99.999% of all
> users.
Union.
-- wli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[email protected] wrote:
| John Richard Moser <[email protected]> writes:
| [ .. lots of stuff .. ]
|
|>Let's make 2.7 what 2.6 is now (a relatively stable kernel that gets
|>relatively stable feature enhancements continuously), rather than what
|>2.5 was (a hell of a lot of patches and then a hell of a lot of
|>debugging), and make 2.6 more restrictive than 2.4 in that it should be
|>strictly bugfixes (including security bugs) and no backported drivers or
|>features.
|
|
| There seems to be a lot of strange notions on this concept of 'stable'.
| The only thing that makes a kernel 'stable' is time. Not endless
| bugfixes. Just time. The idea of stable software is software that not
| going to give you any suprises, software that you can trust.
|
Right. Bugfixing the "Stable" branch ONLY will make sure it does not
surprise you with sudden new features (which may surprise you by. . .
breaking your own patches!).
| That's NOT the same as bug free software. For a start, there's no such
| thing.
5-50 per KLOC.
| For another, many bugs are perfectly acceptable in a production
| environment as long as they're not impacting. (The linux kernel is a
| very large piece of work. Few installations would use even 20% of the
| total kernel functionality).
|
| If you want a stable kernel version, pick one (almost any one will
| do). Test the hell of out it with your application(s). If it fails,
| fix the bug, or pick a different version. rinse, repeat.
|
| Now you've got a kernel that tests clean with your app. DON'T
| CHANGE IT!!
|
| Ta-Dah! You've got a stable kernel.
|
That if I keep my realtime patches or my security enhancements or my new
drivers or my new filesystems on and don't continuously upgrade will
cause me to stagnate and be left behind and ignored.
I've already heard rumors (very few, and they've been squashed) of
GrSecurity being abandoned. The authors of both PaX and Gr are both
active, they're just spinning on 2.6.7.
Do you see the scenario occuring here? Their project is obviously
inferior in many peoples' minds because it's not the latest
hot-off-the-LKML 2.6 kernel. Indeed, many security fixes in (soon to
be) 2.6.10 aren't in 2.6.7, which could provide known ways to easily
slip straight past PaX and Gr (I haven't done my research, but this is
not a hollow scenario).
| Now why would you change it? The only possible reasons
| are that your testing was terrible and you missed a bug,
| in which case you can go back to step 1, or that you
| want a new feature. In which case you can go back to
| step 1.
|
| That wasn't too hard, was it. Even better, you didn't see
| anything in there about 2.6 v 2.7 or other such fluff.
|
| Michael.
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBgRrxhDd4aOud5P8RArUKAJ97tfBLjXCGYQx1DiR0Iul0mwa2FgCfXZMS
vi6YYB8ik6IWO441jZPX5oI=
=YvZq
-----END PGP SIGNATURE-----
On Thu, Oct 28, 2004 at 12:14:42PM -0400, John Richard Moser wrote:
> I've already heard rumors (very few, and they've been squashed) of
> GrSecurity being abandoned. The authors of both PaX and Gr are both
> active, they're just spinning on 2.6.7.
>
> Do you see the scenario occuring here? Their project is obviously
> inferior in many peoples' minds because it's not the latest
> hot-off-the-LKML 2.6 kernel. Indeed, many security fixes in (soon to
> be) 2.6.10 aren't in 2.6.7, which could provide known ways to easily
> slip straight past PaX and Gr (I haven't done my research, but this is
> not a hollow scenario).
So the security people who are doing the security patches have two
choices.
(a) Keep up with the mainline kernel, and try to get their changes
merged into the mainline kernel.
(b) Backport the security patches into 2.6.7, or convince/pay someone
to do this work for them.
Well, I suppose the incessant whining on LKML might be considered an
ineffective way of trying to do (b), but fundamentally, it doesn't
address the this important question: Why should the mainline kernel
folks be asked to do extra work because the security people don't
want/care to get their code clean enough to be merged into mainline?
If they choose not to work towards merging their changes with
mainline, then they have to pay the price of an external patch, which
is constantly keeping up with a changing mainline, or creating their
own set of patch backports.
I'll note by the way that the distributions have chosen the latter for
their stable Enterprise kernels; so this is an honorable and viable
choice, although they do have paying customers to allow them to pay
the costs of doing the backporting, testing, and qualifying the
patches to their stable snapshot for Red Hat's RHEL and SuSE's SLES.
The difference seems to be that you don't want to pay for a supported
distribution's stable kernel, and you don't want to do the work
yourself. Instead you want to whine on LKML. Is that a fair summary
of the state of affairs?
- Ted
On Iau, 2004-10-28 at 16:03, William Lee Irwin III wrote:
> 99.99% of users use one arch, i386.
x86_64 has had more of an impact than that.
> 99.99% of users use one disk driver, IDE.
Floppy, usb-storage.
There is a very sharp peak if you look at actual statistical data.
On Iau, 2004-10-28 at 16:03, William Lee Irwin III wrote:
>> 99.99% of users use one arch, i386.
On Thu, Oct 28, 2004 at 06:33:04PM +0100, Alan Cox wrote:
> x86_64 has had more of an impact than that.
On Iau, 2004-10-28 at 16:03, William Lee Irwin III wrote:
>> 99.99% of users use one disk driver, IDE.
On Thu, Oct 28, 2004 at 06:33:04PM +0100, Alan Cox wrote:
> Floppy, usb-storage.
> There is a very sharp peak if you look at actual statistical data.
Okay, so my info is stale, but the peakedness point I suppose holds
(not that it hadn't been made before).
-- wli
John Richard Moser <[email protected]> writes:
> [email protected] wrote:
[...]
> | There seems to be a lot of strange notions on this concept of 'stable'.
> | The only thing that makes a kernel 'stable' is time. Not endless
> | bugfixes. Just time. The idea of stable software is software that not
> | going to give you any suprises, software that you can trust.
> |
>
> Right. Bugfixing the "Stable" branch ONLY will make sure it does not
> surprise you with sudden new features (which may surprise you by. . .
> breaking your own patches!).
You've missed the point. 'Bugfixing' introduces code changes, and new
bugs. Having made 'bugfix', you now need to go back and re-do much,
if not all of your testing to ensure that you haven't introduced a brand
new bug. At a simple level, to 'bugfix' means to remove 1 known bug
and introduce a random number of unknown bugs. (Could be zero with reasonable
probability; could be 50 with low probabilty. The point is that you don't
know).
This isn't helping to reduce your 'suprise' rate.
[...]
> | Now you've got a kernel that tests clean with your app. DON'T
> | CHANGE IT!!
> |
> | Ta-Dah! You've got a stable kernel.
> |
>
> That if I keep my realtime patches or my security enhancements or my new
> drivers or my new filesystems on and don't continuously upgrade will
> cause me to stagnate and be left behind and ignored.
Ahh. Now I get it. You don't want a stable kernel at all. You
just want to pick and chose which new features you get.
In what way is 'security enchancements', or 'new drivers', or 'new
filesystems' not the very feature enchancements you're complaining
about in 2.6?
Michael.
On Thu, 28 Oct 2004 at 08:03:29 -0700 William Lee Irwin III wrote:
> 99.99% of users use one arch, i386.
You oversimplify. For example, I have:
1 uniprocessor IOAPIC (i440FX)
1 SMP IOAPIC (flat mode) (i440GX)
2 XT-PIC noapic (i440BX, VIA KT133)
> 99.99% of users use one disk driver, IDE.
And again:
1 VIA VT82C686
1 HPT370A
1 PDC20267
1 PDC20268
1 PIIX3
2 PIIX4
So even in my 'simple' i386 environment there is a lot of variety in
just those two things.
> The intersection of these users is probably well over 99.999% of all
> users.
If Linux had a billion users, how many would have something different?
--Chuck Ebbert 28-Oct-04 19:04:08
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[email protected] wrote:
| John Richard Moser <[email protected]> writes:
|
|>[email protected] wrote:
|
| [...]
|
|>| There seems to be a lot of strange notions on this concept of 'stable'.
|>| The only thing that makes a kernel 'stable' is time. Not endless
|>| bugfixes. Just time. The idea of stable software is software that not
|>| going to give you any suprises, software that you can trust.
|>|
|>
|>Right. Bugfixing the "Stable" branch ONLY will make sure it does not
|>surprise you with sudden new features (which may surprise you by. . .
|>breaking your own patches!).
|
|
| You've missed the point. 'Bugfixing' introduces code changes, and new
| bugs.
introduces a minimal amount of new code in most cases, makes up-porting
through the bugfixes a 5 minute job.
[...]
|
|>| Now you've got a kernel that tests clean with your app. DON'T
|>| CHANGE IT!!
|>|
|>| Ta-Dah! You've got a stable kernel.
|>|
|>
|>That if I keep my realtime patches or my security enhancements or my new
|>drivers or my new filesystems on and don't continuously upgrade will
|>cause me to stagnate and be left behind and ignored.
|
|
| Ahh. Now I get it. You don't want a stable kernel at all. You
| just want to pick and chose which new features you get.
|
| In what way is 'security enchancements', or 'new drivers', or 'new
| filesystems' not the very feature enchancements you're complaining
| about in 2.6?
|
You try maintaining a feature patched kernel using things not in
mainline and you'll see. Try grsecurity and reiser4. You'll quickly
find Reiser4 to be at 2.6.8.1-2.6.9 (it's in 2.6.9 mainline right?), and
grsecurity at 2.6.7.
Now here's a real trick. Try pulling it back out of 2.6.10-rcX, and
into 2.6.7. You'll have to grab the fs/reiser4 directory, plus muddle
out what changes happened in VFS relating to reiser4, plus try to fix
whatever you just made explode.
Now as you'll notice, I've created a very shabby issue here; obviously
if I'm using 2.6.7+grsecurity, I'm not concerned with reiser4, as it
wasn't stable until 2.6.8. What about if I'm implementing added
security using grsecurity/pax among others? In fact, what if I'm a
distribution maintainer doing this? New installs may use Reiser4; I'm
about to break them terminally. PR for said distribution falls through
the floor, nobody uses it.
This may seem moot, but let's take a step back and say that 2.6 was
frozen at 2.6.7, and 2.6.10 is just 2.6.7 + bug fixes. 2.7 is in this
scenario taking on new features, but sanely, as 2.6 is now. Some
adventurous users will use 2.7 and reiser4, others will use just 2.6.
Now I'll just patch grsec into 2.6, do whatever polish is needed if the
authors haven't taken the 5 minutes to keep up with mainline, rebuild
the base pie/ssp, set up pax flags so ~20 packages don't die from PaX,
and distribute. PR goes up; and in 6 months a new stable kernel is
forked anyway, a few weeks later there's a new grsec, my distro upgrades.
As you can probably tell by now, my goals are very defined. I have a
narrow focus here, which is why I really did lose interest in arguing
this a while back; but you're all so persistant to argue with me. Even
so, my intentions are and have been to create a solution that's
simultaneously identical to and the antithesis of the current solution,
so that everyone (including me) can shut up and be happy. The effects
are largely psychological and a simple display of macromanagment; and
all opposition has been visually simple obsessive resistance to change.
Unless you want to stop bickering about this and start working out a
clear definition of a better model, stop arguing with me. It does no
good in either direction, as we can't change the model anyway until
we've developed a *better* one; so efforts should be focused there
rather than at the self-answering argument of whether or not it should
be done.
| Michael.
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBgYiMhDd4aOud5P8RAnyvAJ0VK9ayhrO7Gv5NOX4WXN7ZPjNCywCfVWhO
L/0b1kQ8CT4ktlxyKWxS+o8=
=CI/N
-----END PGP SIGNATURE-----
On Thu, 28 Oct 2004 at 08:03:29 -0700 William Lee Irwin III wrote:
>> 99.99% of users use one arch, i386.
On Thu, Oct 28, 2004 at 07:33:22PM -0400, Chuck Ebbert wrote:
> You oversimplify. For example, I have:
[...]
On Thu, 28 Oct 2004 at 08:03:29 -0700 William Lee Irwin III wrote:
>> 99.99% of users use one disk driver, IDE.
On Thu, Oct 28, 2004 at 07:33:22PM -0400, Chuck Ebbert wrote:
> And again:
[...]
> So even in my 'simple' i386 environment there is a lot of variety in
> just those two things.
Alan already pointed out the inaccuracies in my statement.
The point is that the distribution is so sharply peaked on such a tiny
subset of the kernel, it's rather predictable what proportion of users
will be affected by a given bug according to what it's in. So, you can
in principle rank the areas of the kernel in need of verification by
this probability distribution, and carry out audits etc. that way. Even
your "variety" of drivers and architectures adds up to a truly tiny
fraction of the kernel. Worse yet, I was already counting the whole of
drivers/ide/, arch/i386/, and include/asm-i386/ in my accounting, so
you're actually describing a narrower subset of the kernel than I was.
On Thu, 28 Oct 2004 at 08:03:29 -0700 William Lee Irwin III wrote:
>> The intersection of these users is probably well over 99.999% of all
>> users.
Union...
On Thu, Oct 28, 2004 at 07:33:22PM -0400, Chuck Ebbert wrote:
> If Linux had a billion users, how many would have something different?
These arguments are all proportions, but there's actually a rather large
chance that increasing the number of users would all happen by means of
more widely distributing some already-extremely-common hardware. That is,
there would be almost no additional users of the marginalized systems
(even in absolute terms), and the distribution across drivers etc.
would become even more sharply peaked on the same code than it is now.
-- wli
William Lee Irwin III wrote:
> On Thu, 28 Oct 2004 at 00:13:44 -0700 William Lee Irwin III wrote:
>
>>>I'd expect vastly less than 1%, starting from the arch count, and then
>>>making some conservative guesses about drivers. Drivers probably
>>>actually take it down to far, far less than 1%.
>
>
> On Thu, Oct 28, 2004 at 09:04:41AM -0400, Chuck Ebbert wrote:
>
>> Sure, but pretty much each installation uses a different 1%.
>> If there's a bug in there it's bound to hit someone; that's
>>what makes OS writing so difficult. (And that's why "It works
>>for me" is not really a useful statement about the overall quality
>>of an operating system.)
>
>
> 99.99% of users use one arch, i386.
> 99.99% of users use one disk driver, IDE.
> The intersection of these users is probably well over 99.999% of all
> users.
>
> Then probably a small list of secondary drivers varies. Statistically,
> users with anything but the crappiest x86 s**tboxen and a tiny subset
> of all drivers (arjan's 20) are hopelessly outnumbered.
Sorry, i386 is really a pool of Pentium, Athlon, and Opteron chips, with
a witches brew of HT, 64bit extensions to 32 bit chips, and the like.
Connected by a constantly changing set of Intel, SiS, VIA and other
shipsets, and getting storage from IDE and SATA drives.
Not to mention using a vast array of CD and DVD drives and several major
flavors of USB methods with minor variations of each, and driving their
consoles with at least a half-dozen popular video chipsets with drivers
of various shades of openness.
You don't even reach 99.99% with small-endian, there are more assorted
RISC chips in use than that. I guess you're safe with twos complement
arithmetic, although I cringed at Linus' recent "find a power of two"
code which depends on it. Diversity, thy name is Linux!
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
William Lee Irwin III wrote:
>> users with anything but the crappiest x86 s**tboxen and a tiny subset
>> of all drivers (arjan's 20) are hopelessly outnumbered.
On Fri, Oct 29, 2004 at 09:19:39AM -0400, Bill Davidsen wrote:
> Sorry, i386 is really a pool of Pentium, Athlon, and Opteron chips, with
> a witches brew of HT, 64bit extensions to 32 bit chips, and the like.
> Connected by a constantly changing set of Intel, SiS, VIA and other
> shipsets, and getting storage from IDE and SATA drives.
> Not to mention using a vast array of CD and DVD drives and several major
> flavors of USB methods with minor variations of each, and driving their
> consoles with at least a half-dozen popular video chipsets with drivers
> of various shades of openness.
> You don't even reach 99.99% with small-endian, there are more assorted
> RISC chips in use than that. I guess you're safe with twos complement
> arithmetic, although I cringed at Linus' recent "find a power of two"
> code which depends on it. Diversity, thy name is Linux!
Feel free to compile real statistics on in-the-field Linux code use.
I'll go with my handwavy assessment until I see such.
-- wli
On Thu, Oct 28, 2004 at 03:28:18AM -0400, Hacksaw wrote:
> > That's NOT the same as bug free software. For a start, there's no such
> > thing.
>
> Speaking of which, here's something I have wondered: is anyone out there
> trying to prove the correctness of core functions in the kernel? I was
> thinking this would be a fine activity for all those eager college students
> out there, or perhaps a graduate student project, a la the Stanford Checker
> project.
>
> While I can't imagine the main developers doing such a thing, I think it'd be
> useful and might uncover some hard to find bugs.
>
> I'd also suspect that they might be good candidates for proving, as there's
> not so much reason to have side effect riddled code, as one might for GUI
> programs.
Did you ever try to prove the correctness of some piece of code in an
imperative programming language? That's definitely not only "a graduate
student project".
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, 26 Oct 2004, Ed Tomlinson wrote:
> On Tuesday 26 October 2004 07:09, Massimo Cetra wrote:
> > > On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > > > Bill Davidsen wrote:
> > > >
> > > > > I don't see the need for a development kernel, and it is
> > > desirable
> > > > > to be
> > > > > able to run kernel.org kernels.
> > > >
> > > > Problem is, kernel.org 'release' kernels are quite buggy. For
> > > > example 2.6.9 has a long list of bugs:
> > > >
> > > > Sure, the next release will (may?) fix these bugs, but it will
> > > > definitely add a whole set of new ones.
> > >
> >
> > > To my mind this just points out the need for a bug fix
> > > branch. e.g. a
> > > branch containing just bug/security fixes against the current
> > > stable kernel. It might also be worth keeping the branch
> > > active for the n-1 stable kernel too.
> >
> > To my mind, we only need to make clear that a stable kernel is a stable
> > kernel.
> > Not a kernel for experiments.
> >
> > To my mind, stock 2.6 kernels are nice for nerds trying patches and
> > willing to recompile their kernel once a day. They are not suitable for
> > servers. Several times on testing machines, switching from a 2.6 to the
> > next one has caused bugs on PCI, acpi, networking and so on.
> >
> > The direction is lost. How many patchsets for vanilla kernel exist?
> >
> > Someone has decided that linux must go on desktops as well and
> > developing new magnificent features for desktop users is causing serious
> > problems to the ones who use linux at work on production servers.
> >
> > 2.4 tree is still the best solution for production.
> > 2.6 tree is great for gentoo users who like gcc consuming all CPU
> > (maxumum respect to gentoo but I prefer debian)
>
> The issue is that Linus _has_ changed the development model. What we have
> now is more flexable and much more responsive to changes. This does
> lead to stable releases that are not quite a stable as some of the previous
> stable series... This is why I suggest a fix/security branch. The idea being
> that after a month or so of fixes etc it will be a very stable kernel and it will
> not have slowed down development.
Linus doesn't want a stable branch, unfortunately. Many people have
suggested that 2.7 be opened, but it isn't going to happen until and
unless the politics change. The kernel.org kernels are fine if they happen
to works for you, but new features just keep being dropped into it like a
development kernel.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 27 Oct 2004, Massimo Cetra wrote:
> > On Wed, Oct 27, 2004 at 08:04:33AM +0200, Willy Tarreau wrote:
> > > Oh yes I remember... I was very interested because of netfilter and
> > > ramfs but couldn't use it because of its awful stability. That was
> > > when I started complaining about linux development model, where new
> > > features were more important than bug fixes, which resulted in no
> > > usable kernel before 2.4.18.
> >
> > 2.6.x has taken a rather different path from 2.4.x
>
> However, results are similar.
>
> 2.6 seems to work better than 2.4 in "early stage of stable branch" but
> It's quite impossible to set up a production server on 2.6.x, optimize
> it and keeping the same performance with 2.6.(x+2).
The catch here is "optimize it."
>
> Iosched has a lot of flavours, with performance worse than 2.4 (at least
> for databases).
> Swap is a misterious thing and It needs a degree in swappiness to
> understand how it works and how it changes.
I think one of the issues with 2.6 in general is that it doesn't auto-tune
as well as 2.4. While it's good to have controls, and I ran tuned -aa
kernels for several years because Andrea took the time to give me a two
screen primer on tuning bdflush, tuning 2.6 for i/o and CPU scheduling had
more benefits than 2.4. Unfortunately you now need to tune the algorithm
as well as the parameters, and in some cases the "tuning" needs to be done
with patch and gcc.
>
> I see a lot of efforts in making a top-performance kernel but these
> efforts are not compatible with a stable-tree.
I'm going to disagree a little here, what needs to be done is to put i/o
and CPU scheduling in modules (some work has been done), so that kernels
can be tuned, and use of a default delection should be stable, at least
defined as not crashing or hanging, and producing some reasonable
performance with self tuning.
>
> Stable means not only that the kernel does not hangs, but that features
> remains (almost) the same for a reasonable amount of time.
And there I agree, rewriting an app to go from 2.4 to 2.6 is fine, from
2.6.n to 2.6.n+1 isn't.
>
> Max
>
I hope you realize that the development model is decided by a democratic
vote, just be aware that there is only one voter.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.