Re: My thoughts on the "new development model"

Re: My thoughts on the "new development model"

[Chuck Ebbert]

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

Re: My thoughts on the "new development model"

[Ed Tomlinson]

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.

RE: My thoughts on the "new development model"

[Massimo Cetra]

> 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

Re: My thoughts on the "new development model"

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 13:09:59 +0200, Massimo Cetra <mcetra@navynet.it> 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

Re: My thoughts on the "new development model"

[Mathieu Segaud]

Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> 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.

Let's make a small change to the process

[Paolo Ciarrocchi]

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

Re: Let's make a small change to the process

[William Lee Irwin III]

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

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 13:22:24 -0700, William Lee Irwin III
<wli@holomorphy.com> 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

Re: Let's make a small change to the process

[William Lee Irwin III]

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

Re: Let's make a small change to the process

[Dave Jones]

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

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 16:36:44 -0400, Dave Jones <davej@redhat.com> 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

Re: Let's make a small change to the process

[Jan Knutar]

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. :-/

Re: Let's make a small change to the process

[John Richard Moser]

-----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-----

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 16:48:59 -0400, John Richard Moser
<nigelenki@comcast.net> 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

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

Re: My thoughts on the "new development model"

[Ed Tomlinson]

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

Re: My thoughts on the "new development model"

[Marcos D. Marado Torres]

-----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   -	  marado@student.dei.uc.pt
    () 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-----

Re: My thoughts on the "new development model"

[Rik van Riel]

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

Re: My thoughts on the "new development model"

[Willy Tarreau]

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

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

Re: My thoughts on the "new development model"

[Willy Tarreau]

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

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

RE: My thoughts on the "new development model"

[Massimo Cetra]

> 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

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

RE: My thoughts on the "new development model"

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: My thoughts on the "new development model"

[John Richard Moser]

-----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 majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/
|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBf6cPhDd4aOud5P8RAhWIAJ4u8W+KobiYoGKhsXEqw5TL+zUIggCaAueL
AWGds1692rVAhFb/+KHiyvM=
=jB3R
-----END PGP SIGNATURE-----

Re: My thoughts on the "new development model"

[Theodore Ts'o]

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

Re: My thoughts on the "new development model"

[John Richard Moser]

-----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 majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/
|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBf8AshDd4aOud5P8RAjwtAJ4je6e8ubxmnMJexVY0Db6JSNRPLwCeMvNY
HjEB1Ve+ZSdToiwPOsMJWnM=
=DJkR
-----END PGP SIGNATURE-----

Re: My thoughts on the "new development model"

[Marcos D. Marado Torres]

-----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   -	  marado@student.dei.uc.pt
    () 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-----

Re: My thoughts on the "new development model"

[John Richard Moser]

-----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   -      marado@student.dei.uc.pt
|    () 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-----

Re: My thoughts on the "new development model"

[Rik van Riel]

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

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

Re: My thoughts on the "new development model"

[John Richard Moser]

-----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-----

Re: My thoughts on the "new development model"

[John Richard Moser]

-----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   -      marado@student.dei.uc.pt
|    () 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
| /* *************************************************************** */

- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfzFZhDd4aOud5P8RAiTmAJ9obM88F5YW29Rcke3oKrWngs/rRACaAxqZ
BBoLsEO2QdBIJfZlBvGpZHk=
=hMNm
-----END PGP SIGNATURE-----

Re: My thoughts on the "new development model"

[michael]

John Richard Moser <nigelenki@comcast.net> 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.

Re: My thoughts on the "new development model"

[William Lee Irwin III]

On Thu, Oct 28, 2004 at 04:46:58PM +1000, michael@optusnet.com.au 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

Re: My thoughts on the "new development model"

[Hacksaw]

> 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

Re: My thoughts on the "new development model"

[Adrian Bunk]

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

RE: My thoughts on the "new development model"

[Massimo Cetra]

> 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

Re: My thoughts on the "new development model"

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



michael@optusnet.com.au wrote:
| John Richard Moser <nigelenki@comcast.net> 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-----

Re: My thoughts on the "new development model"

[Theodore Ts'o]

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

Re: My thoughts on the "new development model"

[michael]

John Richard Moser <nigelenki@comcast.net> writes:
> michael@optusnet.com.au 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.

Re: My thoughts on the "new development model"

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



michael@optusnet.com.au wrote:
| John Richard Moser <nigelenki@comcast.net> writes:
|
|>michael@optusnet.com.au 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-----

Re: My thoughts on the "new development model"

[Rik van Riel]

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

Re: My thoughts on the "new development model"

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: My thoughts on the "new development model"

[Barry K. Nathan]

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 <barryn@pobox.com>

Re: My thoughts on the "new development model"

[Espen Fjellvær Olsen]

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
espenfjo@gmail.com
Norway

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

Re: My thoughts on the "new development model"

[Gene Heskett]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.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.

Re: My thoughts on the "new development model"

[William Lee Irwin III]

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

Re: My thoughts on the "new development model"

[Alan Cox]

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.

Re: Let's make a small change to the process

[Chuck Ebbert]

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

Re: Let's make a small change to the process

[Alan Cox]

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

Re: Let's make a small change to the process

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Let's make a small change to the process

[Chuck Ebbert]

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