Discussion on the new Linux kernel development model [story] continued on the lkml, and likely will continue for some time. Adrian Bunk began an email pointing out, "there's much worth in having a very stable kernel. Many people use for different reasons self-compiled ftp.kernel.org kernels." 2.6 maintainer Andrew Morton [interview] replied, "Well. We'll see. 2.6 is becoming stabler, despite the fact that we're adding features." He went on to note:
"Nothing is cast in stone here btw - we're pushing the envelope, trying new things, keeping that which works well and reexamining things which perhaps don't work so well. Feel free to disagree - we're listening."
From: Adrian Bunk [email blocked]
To: Jonathan Corbet [email blocked], Andrew Morton [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 01:52:28 +0200
On Wed, Jul 21, 2004 at 05:11:23PM -0600, Jonathan Corbet wrote:
> > Ok, is there anywhere else that isn't subscriber-only that has the scoop?
>
> For those who weren't here, the basic scoop is this:
>
> - 2.6 is doing great, despite the fact that (by Andrew's reckoning) some
> 10mb/month of patches are going into it.
>
> - Linus is majorly pleased with how the partnership with Andrew has been
> working, and few people feel that he shouldn't be. He is a little
> concerned about breaking a highly effective process when 2.7 forks.
>
> - There is not a whole lot of pressure to create a 2.7 now, but a lot of
> interest in getting patches into the mainstream quickly.
>
> The end result is that there may not be a 2.7 for a while. Instead,
> significant patches will continue to go into 2.6, after a vetting period
> in -mm. Andrew stated his willingness to consider, for example,
> four-level page tables, MODULE_PARM removal, API changes, and more. 2.7
> will only be created when it becomes clear that there are sufficient
> patches which are truly disruptive enough to require it. When 2.7 *is*
> created, it could be highly experimental, and may turn out to be a
> throwaway tree.
>
> Andrew's vision, as expressed at the summit, is that the mainline kernel
> will be the fastest and most feature-rich kernel around, but not,
> necessarily, the most stable. Final stabilization is to be done by
> distributors (as happens now, really), but the distributors are expected
> to merge their patches quickly.
>
> Anybody disagree with that summary?
Thanksfor this mail, this is exactly the information that was missing.
Discussing the contents:
Changes that remove functionally like Greg's patch are hopefully
still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades
inside a stable kernel series are a must for many users.
> jon
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
From: Andrew Morton [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 02:55:39 -0700
Adrian Bunk [email blocked] wrote:
>
> Changes that remove functionally like Greg's patch are hopefully
> still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades
> inside a stable kernel series are a must for many users.
I don't necessarily agree that such changes in the userspace interface
should be tied to the kernel version number, really. That's a three or
four year warning period, which is unreasonably long. Six to twelve months
should be long enough for udev-based replacements to stabilise and
propagate out into distributions.
That being said, mid-2005 would be an appropriate time to remove devfs. If
that schedule pushes things along faster than they would otherwise have
progressed, well, good.
Nothing is cast in stone here btw - we're pushing the envelope, trying new
things, keeping that which works well and reexamining things which perhaps
don't work so well. Feel free to disagree - we're listening.
From: Greg KH [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 03:04:54 -0400
On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> Adrian Bunk [email blocked] wrote:
> >
> > Changes that remove functionally like Greg's patch are hopefully
> > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades
> > inside a stable kernel series are a must for many users.
>
> I don't necessarily agree that such changes in the userspace interface
> should be tied to the kernel version number, really. That's a three or
> four year warning period, which is unreasonably long. Six to twelve months
> should be long enough for udev-based replacements to stabilise and
> propagate out into distributions.
Users have had the 6-12 month warning about devfs for a while now :)
And udev is currently available in the latest distro versions of:
- Red Hat
- SuSE
- Gentoo
- Debian
- Mandrake
While devfs is only supported in Gentoo at this time (and udev fills
that support issue for those users.)
> That being said, mid-2005 would be an appropriate time to remove devfs. If
> that schedule pushes things along faster than they would otherwise have
> progressed, well, good.
Ok, if people think that would really change anything, I'll wait a year.
I'm patient :)
thanks,
greg k-h
From: Andrew Morton [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 03:19:23 -0700
Greg KH [email blocked] wrote:
>
> On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> > Adrian Bunk [email blocked] wrote:
> > >
> > > Changes that remove functionally like Greg's patch are hopefully
> > > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades
> > > inside a stable kernel series are a must for many users.
> >
> > I don't necessarily agree that such changes in the userspace interface
> > should be tied to the kernel version number, really. That's a three or
> > four year warning period, which is unreasonably long. Six to twelve months
> > should be long enough for udev-based replacements to stabilise and
> > propagate out into distributions.
>
> Users have had the 6-12 month warning about devfs for a while now :)
No, they had a three year warning. "It'll be gone in 2.8".
> Ok, if people think that would really change anything, I'll wait a year.
> I'm patient :)
Delete 100 lines per week ;)
From: Adrian Bunk [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 21:33:37 +0200
Hi Andrew,
my personal opinon is that this new development model isn't a good
idea from the point of view of users:
There's much worth in having a very stable kernel. Many people use for
different reasons self-compiled ftp.kernel.org kernels. In 2.4, it took
until at about 2.4.18 or 2.4.22 [1] until it was reasonable stable.
Today, most code in the 2.4 kernel has had several years of testing and
it's therefore quite stable even in unusual configurations. Besides
this, an upgrade like from 2.4.25 to 2.4.26 is pretty low-risk since
there shouldn't be any changes that might break existing setups.
If your work together with Linus is so effective, why can't you both do
all the changes in a new 2.7 tree that includes also all incompatible
and potential dangerous changes as well as the removal of obsolete code
like devfs or OSS. I don't see the negative effect if a 2.7 branch was
created today and together with a feature freeze for 2.7 three months
from now this might result in a 2.8.0 before christmas [2] that contains
all the new features/removals/changes while 2.6 will evolve further into
a rock-solid stable kernel.
cu
Adrian
[1] there are different opinions on the exact version number, but it was
definitely not 2.4.10
[2] perhaps a bit optimistic, but it shouldn't be years from now
--
"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
From: Paul Jackson [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 15:28:39 -0700
> There's much worth in having a very stable kernel.
There certainly is. But the contribution that having a separate 2.7/2.8
kernel at the head (Linus, et. al.) end has to a user having a stable kernel
is not what you think it is.
The direction presented to us now is having smaller, more continuous,
steps in the head end, over having fewer larger, more disruptive steps.
Do we do all the incompatible changes in a big chunk, once every couple
of years, or do we do them one a week, ongoing.
Now, I repeat, this is at the head end. End users who want stability
aren't feeding directly off kernel.org anyway.
The affect downstream on real users is this. If the head end operates
in big chunky style, then as this big change flows downstream, it makes
transitions for distros, service providers and middlemen more costly and
difficult, creating expenses that must be passed on to the end user.
Yes - damming up the flow of changes creates stability. But if you're a
middleman, you don't need Linus to choose where to build the dam, and
when to open the flood gates. It's more efficient for you to choose for
yourself when to do that damming, based on your particular resources and
customer needs, rather than have to deal with hundred year floods and
draughts imposed on you by Zeus.
The end user always gets their stability, if only because they won't
upgrade a system that is "working".
And every change at the head end is disruptive for some poor slob.
The only perfectly compatible change is no change at all. We delude
ourselves if we think we can separate the "safe" fixes and additions
from the "unsafe" incompatible changes. Better that we should expend
some energy on smoothing out and minimizing the cost of change to those
downstream from us. This needs to be done the old-fashioned way, one
change at a time.
The question is whether we impose, on all those downstream from us,
occasional hundred year floods, or do we provide a steady stream, and
let them build their own little beaver dams, as suits their various and
diverse needs and business cycles.
The great lesson of capitalism over communism is that a thousand free
workers and investors, each optimizing their own little plot or
portfolio, beats a single centrally imposed five year plan, even if the
man pulling the levers is a genius such as Linus or Lenin (sorry, Linus,
couldn't resist ...).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [email blocked] 1.650.933.1373
From: Andrew Morton [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 16:01:12 -0700
Adrian Bunk [email blocked] wrote:
>
> my personal opinon is that this new development model isn't a good
> idea from the point of view of users:
>
> There's much worth in having a very stable kernel. Many people use for
> different reasons self-compiled ftp.kernel.org kernels.
Well. We'll see. 2.6 is becoming stabler, despite the fact that we're
adding features.
I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
fixes against 2.6.20 if there is demand for it. Anyone who really cares
about stability of kernel.org kernels won't be deploying 2.6.20 within a
few weeks of its release anyway, so by the time they doodle over to
kernel.org they'll find 2.6.20.2 or whatever.
From: Adrian Bunk [email blocked]
Subject: Re: New dev model (was [PATCH] delete devfs)
Date: Thu, 22 Jul 2004 22:18:58 +0200
On Thu, Jul 22, 2004 at 04:01:12PM -0700, Andrew Morton wrote:
> Adrian Bunk [email blocked] wrote:
> >
> > my personal opinon is that this new development model isn't a good
> > idea from the point of view of users:
> >
> > There's much worth in having a very stable kernel. Many people use for
> > different reasons self-compiled ftp.kernel.org kernels.
>
> Well. We'll see. 2.6 is becoming stabler, despite the fact that we're
> adding features.
4kb stacks were added after 2.6.0 and now 4KSTACKS=y results in Oops'es
under some circumstances if using XFS.
2.6 currently still becomes stabler, but every new/changed feature bears
the risk of breaking something.
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it. Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.
Who will maintain the many subtrees of 2.6 this implies?
Even after 2.6.20 was already released, you might have to release a
2.6.19.5 with a few additional security fixes since according to your
advice users should continue to use 2.6.19 for a few weeks which
implies that someone will have to maintain at least the 2.6.19 tree for
at least a few weeks after the release of 2.6.20 .
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
New development model
I think the whole development should evolve faster. I mean, there could be (backing up Adrian Bunk) a 2.7 version now, where all the new changes, and mid-risk patches gets applied, so, we could have a 2.8 kernel sooner.
2.6 branch should get only stability and security fixes, and perhaps low risk patches.
Maybe a 2.9 branch should be created now, so all the bleeding-edge and lets-rewrite-devfs-from-schatch patches have a place for testing.
So 2.6 for stability and security, 2.7 for normal changes, and 2.9 for big ones.
That should need more mantainers, thou.
Julian
"2.6 is becoming stabler, des
If that is true, then all fears are unsubstantiated. After all, people started to complain that the kernel was not going to be as stable anymore. If Linus and Andrew somehow manage to keep it stable while making changes, then that's fine for everyone, i guess.
Agreed
I think its being blown out of proportion. I mean, sh*t, doesn't anyone remember the horror of the early 2.4 series? How many of the first few releases led to data corruption? Let alone bizzare VM behavior, all of which had to be ripped out and re-designed in a hurry. 2.6, in comparison, seems awefully damn sane. Without question, to me, more stable then the early 2.2 or 2.4 series ever was. OSDL stressed tested the crude out of this series, something earlier branches never really got. 2.6, for me, has been /more/ stable on my hardware then the 2.4 series since the late 2.5 releases. I hadn't looked back.
personal versus professional
Are you talking about personal hardware?
The thing that worries me, isn't that my personal computer crashes once or twice. What I worry about, is a continuous crashing of the machines I administrate; it makes me look bad, it makes my company look bad, it frustrates customers, etc.
Do you know what it takes (time, effort, miles, people, access and permissions) to reset and troubleshoot colocated servers in serverparks? ... A whole lot more than rebooting my own little desktop, that's for sure.
Ofcourse I wouldn't run the last experimental kernel, but security issues (my speciality) force me to update fast and often - well, as often as a problem is found in the kernel. Not being able to have a more or less guaranteed stable and reasonably recent kernel from ftp.kernel.org, is a very bad thing.
bad choice
Dude, if you think the latest vanilla kernel from kernel.org is guaranteed to be stable, then you are seriously misinformed.
There's this urban legend that the "stable" series on kernel.org has some magical attributes that make it more stable than anything else. For that to be true it would mean that:
1. The kernel developers' primary focus is kernel stability
2. They have large amounts of testing resources at their disposal, other than anecdotal evidence on the kernel mailing list (LKML)
Neither is true.
The kernel developers have to please a lot of different people. The "stable" kernel on kernel.org has to be reasonably stable, that's true, but it also has to be reasonably fast (to please the supercomputing guys), it also has to be "shrinkable" (to please the embedded Linux crowd), it has to support all kinds of fancy features, etc.
There are a lot of conflicting requirements for that kernel version. Stability is just one of them. The kernel on kernel.org is a middle ground, it's a bit of everything but it does not excel at anything.
Want lots of features? Get the volks patch.
Want speed? See what the supercomputing people are using.
Want serious NUMA support? Get an SGI kernel.
Want a small kernel? Get one from an embedded Linux distro.
Want a really stable kernel? Get one from an enterprise Linux distro.
Andrew saying that a certain kernel branch may not be the most stable one is not news. It has never been the most stable one.
If your primary concern is stability and system uptime and you're relying on the vanilla kernel to deliver that, you're making a mistake.
I want a STABLE version
Please tell me dumb end users which .x version in 2.6.x series is
STABLE.
I understand it is important to get new features in as
soon as possible, but it is same important that we end users
could sleep well with the version running on our systems.
If every 2.6.x version is so solid then I wouldn't say anything,
but I am afraid it is not true. I think we still need to
distinguish between _bug_fix_ release and _feature_devel_ release,
being it 2.6.x vs 2.7.x, or
2.6.x vs 2.6.x.1, or
2.6.x vs 2.6.x+1-pre/-rc/-mm
stable 2.6
2.6.6 has been stable for me so far. 2.6.2 - 2.6.5 had some weird crashes on both machines were I tried them. One is with nvidia board + amd cpu and other with intel board, although the nvidia has known hardware+bios problem that has workaround in 2.6.6. The Intel board however had previosly worked fine even with 2.5 kernels, so I think it hit some bug in earlier 2.6 kernels. 2.6.7 has some more extensive changes afaik (objrmap) compared to 2.6.6, but maybe it is also fine (haven't tried it yet).
Um... if you want stability,
Um... if you want stability, only upgrade when -needed-, not whenever a new kernel comes out - basically, for security patches. Stick with 2.4 (or 2.2) for now, and/or some distribution's official kernel sources. Replacing the kernel on your system with random ones, even from kernel.org, is not a recipe for stability.
If you want vanilla 2.6, search/ask, and don't grab the latest .x; generally, stick to at least x-2 unless that one has serious bugs.
There are a -lot- of people maintaining various patchsets, optimised for security, new features, speed....
No one says you need to learn anything about any of this; however, if you want to start compiling your own kernels, it's obviously to your benefit if you know enough to be able to choose a fairly stable one [and things like distributions tend to help in this filtering process.]
2.6 has had a few nasty bugs, but nothing compared to 2.4.
Stable depends on your hardware and config as well, at times.
No, not every 2.6.x has been solid. Stability has been good, but there have been bugs.
You have a choice - if you want to be a "dumb end user", in your words, don't start arbitrarily upgrading your kernel - that's not in the realm of "dumb end user" tasks. If you want to, go for it; just don't hold the illusion that EVERY possible kernel in every config will do what you want...
If you want bug-fixes, rather than features, use 2.2 or 2.4.
communication problem
It looks like a communication problem.
Like someone else noted, 2.6 is currently more stable than the correspondent 2.2 and 2.4 versions, due to efforts by OSDL and others, and perhaps due to significant contribution from A. Morton, etc.
So, when Andrew says that perhaps 2.6 is not going to be the most stable series, it does not mean "it's going to be the least stable series among 2.0, 2.2, 2.4, etc." In fact, even taking Andrew's words into account, it may well be that 2.6 is going to be more stable than 2.4 - the same 2.4 that "clueless" users were happily using on their production servers, while at the same time complaining about 2.6 being too "unstable".
It could be that the ones who are complaining have an oversimplified, "binary" view of how things are:
- Caveman thinks 2.2, 2.4 stable is
- Caveman thinks 2.6 stable is not
Or, in other words, stability seems to be a magical property that's added or removed to/from a software based on their names/numbers/etc.
While the reality might well be more complex. So, 2.6 is not the most stable series. That's fine, vanilla "stable" was never the most stable - that title goes to the Red Hat Enterprise kernels and the like.
But if 2.6 is more stable than 2.4, then by all means that's fine with me.
It seems to me that some users do not want to just use the most stable kernel. They want to use the most stable kernel AND that kernel must be the "stable" vanilla kernel.
Sorry guys, but the vanilla kernel has many goals. Stability is only one of them.
Agreed, Again
Same poster as the original "agreed." To put things in perspective, Linux has run on faulty hardware that Windows crokes on since I can remember. First running Red Hat 5.1 on my IBM Aptiva around 1998 was a revelation. (hardware specs are roughly Pentium 133 mhz, 48 megs of RAM, 2.5 gig HD, 10 baseT Ethernet, quad speed CD-ROM) I was, at the time, searching for something better then Windows 95. Win 98 came out, and ran slower then 95 did. I had been a Windows user since 3.0, and even at its worst I don't remember the 3.x series being anywhere near as unstable as the infamous first few releases of Win 95. Initially it had 16 megs of RAM, huge compared to my friends 4 megs, and Win 98 struggled on it. Bought a 32 meg stick, bumping it up to 48 - night and day.
I was told about Win NT 4.0, gave that a shot - looked and felt like Win 95, didn't crash as often, and pre-emptive multitasking was nice - but no DirectX, none of my precious games would run. :-) Linux was starting to really hit the news then and after reading up on it, and learning that it was a flavor of Unix (officially or not), I drove my happy ass to Best Buy and bought Red Hat 5.1. I had been facinated with Unix since I first read about it in Byte Magazine years ago, but never had a chance to play with it. Linux was my chance. It took me three days to get the thing installed, mostly because the idea of partitioning my drive took some time to wrap my head around. But I learned alot too. Got it installed, got it online, and - finally - got X-Windows up and going. No, it wouldn't play my DirectX games either, but it ran sooo much smoother on that aging machine then Win 98 or NT ever did. Also, most importantly, it never crashed on me. Ever.
Thats been my experience ever since, mostly, if Linux crashed on me it was likely hardware. My SMP machine has a futzy motherboard, after a period of time Linux 2.4 or FreeBSD would simply lockup unless I ran in UP mode. 2.6, dunno what was different in that area, never locked up. For me, on my hardware, its simply more stable.
Long winded of me, but I've noticed far fewer "weird" things about the 2.6 series that the early 2.2 or 2.4 series had. Its, all in all, quite sane for me. I'm hardly an oldtimer, but I've been a user since the 2.0 days. 2.6 is great stuff, and its maturing really fast too. Although we may not quite be there yet, Linux can now approach the likes of Solaris or AIX. Perhaps with 2.8/3.0 we'll equal or best them on features, with better security and performance too.
One last thing, Linux (and *BSD) were the only operating systems I could get to run reliably on an old IBM Thinkpad of mine, every flavor of Windows from 98 to XP would run like crude - act like it was okay, then randomly crash. Who knows, maybe fault hardware, but Linux and company never complained. Been running Slackware on it ever since.
Offtopic, but
There is no such thing as "X-Windows". It is called "X Window System" or simply "X" with "X11" being a version of "X" and the name of a protocol. A less good name, but still used, is "X Window". Moreover it is confusing because of this and also because of "Microsoft Windows".
Yes
"Or, in other words, stability seems to be a magical property that's added or removed to/from a software based on their names/numbers/etc."
I've noticed this myself ever since 2.6 came out. Since its release, the kernel developers have been saying it's the most stable kernel yet. Yet all of the people who "know what's going on" complain about how unstable it is compared to 2.4 without any real evidence. I'm not really sure how you can convince people to follow the facts rather than their assumptions based on version numbers.
Yes, its stable
its my understanding that the /kernel/ itself is very stable, more so then any other series, its just many drivers that aren't yet up to snuff. The things been stressed tested to all hell, far more thoroughly then the earlier releases.
((excuse for my poor english)
((excuse for my poor english)
If someone wants the stable used in the coporate or commerce then he should use the vendor's distrobution or the community like fedora(though the fedora's kernel "often" have the worse stable than the vialian's kernel,(I mean sometimes , not always)),not in the kernel.org with use the viallian kernel and yous guys recompiled every day or every week.
I don't think the stable wanted in the commerce or end-user can be find in the vialian's kernel,or they should stable for end-user,though the vialian's kernel always stable before this discussion
so ,let linus try this new concept and maybe this is a good thing(maybe worse?),but if you don't try,nothing we can gain,and yes,nothing we can lost
Stable should be just that
2.5 and 2.6 have been in development for a long time now its
time to let 2.6 be its own thing and become the truly stable
branch - in fact as stable as possible.
It should not be down to distributions to add lots of patches,
I can only see this causing bigger variations, and more confusion.
Currently I use standard 2.4 kernel releases on the companies
production Debian Linux servers which run 24/7. Stability and
security are very important to any systems administrator, and the
2.4 releases (with later VM) have been excellent, it works well
please lets keep this model for 2.6.
I have upmost respect for Linus and Andrew, they are smart
guys. Smart guys get an itchy finger for new features, they are
inventors and creators after all. It's time to fork a 2.7 tree,
and if Linus feel his efforts are best used there then
another maintainer should be found for 2.6.
PS: My thanks to all kernel developers.
sig = 0xda1e;another maintainer
*FULL ACK*
There are many talented kernel hackers out there who might be willing to do the 2.6 job.
Linus & Andrew as an effective team to drive the new unstable tree. If they follow the current model (with a mm-tree to test and sort out) they might finally be able to release the next stable kernel within a much shorter period than ever before.
features
maybe Linus and Andrew think that 2.6.x is not feature complete?
there are a lot of stuff that people want in the 2.6.x main tree like UML, vservers, reiserfs v4...
and if you guys see in the changelogs, there are a lot of "bugfixes" and optimizations... so there are some ideias of stabilization in the 2.6.x kernel.
vanilla and stability
>Now, I repeat, this is at the head end. End users who want stability
>aren't feeding directly off kernel.org anyway.
For short: We are.
Agreed
Agreed, we definitely do.
Agree
Yes! We are!
I watched the LKML discussion, and it's not what you think.
I read the discussion on LKML, and things aren't as scary or "unstable" as people are interpreting them to be. First of all, people seem to be getting confused by two different meanings of "unstable". One is "crashes a lot" or "corrupts data", and the other is "API's and functionality that don't change a whole lot." The 2.6 kernel doesn't crash or corrupt data (at least not as much as 2.2 or 2.6), but it is evolving at a faster rate, so your applications may break because the kernel has become incompatible.
The other thing people don't seem to understand is that the higher rate of evolution isn't going to make a less reliable kernel, because the FILTERING model has also changed. That is to say, Andrew Morton's -mm kernels are now the testing bed for patches. Once things are proven in -mm, then they get ported into mainline. The result is a reliable mainline kernel that evolves faster. So instead of 2.7 being "experimental" leading to 2.8 "stable", we have 2.6.x-mm being experimental, and 2.6.x being stable.
One advantage here is that there won't be a sudden influx of patches the instant 2.7 opens. When 2.5 opened, it was a flood, and things got really bad really fast, and it was just too much for everyone to test and fix. Too many simultaneously changing variables. This is why 2.5 took so horribly long and why 2.6 had to go through a few revisions before it got to be really robust. If patches come in at a managable rate, then they can be tested and debugged more thoroughly.
I believe the new development model was described as something like this: 2.6.x-mm gets new features and that's where they get tested. Once they are tested, they are "forward ported" to 2.6.x. 2.6.x will also get some changes, but mostly in the form of bug fixes. When a bug is fixed it gets "back ported" to 2.6.x-mm. (I may have gotten the forward and back swapped.) The "stable" features of 2.6.x stay in sync, while the "experimental" features stay in -mm until they are proven no longer experimental, and then they sync up on new features slowly, through a managable process.
2.7 will be opened when much more "revolutionary" ideas are to get incorporated, like something which more fundamentally changes the way the kernel works. Furthermore, it's explained that 2.7 could be a "throw away" kernel where radical ideas are tested, the bad ones thrown away, and the good ones.... well, I don't think they said what they would do with the good ones. :)
-- Timothy Miller
very good comment.this is wha
very good comment.this is what i like in the future kernel evolutioning
Thank you!
This cleared things up for me a lot. Thanks!
As seen on the Tree Channel
stability in its many different forms
One thing I think has been only lightly touched on in existing discussion here (I can't speak for LKML - my mail is bad enough as it is without subjecting it to that) and that's the multiple meanings of stability.
Stability can mean:
As few code changes as possible happen
ABI stability ("My binary drivers still run")
API stability ("My drivers still compile")
Doesn't crash
Works how you expect and works smoothly
Copes well with odd corner cases and combinations
To a fair extent, I suspect that the first two or three are at odds with the latter few. That is to say, that to achieve a kernel that works smoothly on a wide variety of hardware and combinations of hardware and software, it may be necessary to change things sometimes.
As a system administrator, I would prefer - any day - a kernel that has niggling quirks and issues being fixed (even if it means updating some utility or driver) than one that's "stable" in the sense that I'm still swearing about the same kernel problems a year later. This is true ONLY if every change that may require admin action is CLEARLY DOCUMENTED, so that there's no "woohoo, LVM doesn't work anymore!" fun.
So long as the changes are carefully thought about (and they obviously are), staged and tested, I don't see the big deal. Distributors can act as a buffer between people who want even more testing etc and mainline. These people probably shouldn't be upgrading to latest mainline anyway - as it's always possible for a nasty bug to slip in. Others can choose to adopt mainline if it's moving in the direction they need.
I, for one, will be glad to see something that reduces or eliminates the need for me to maintain my own patched kernel just to get the fixes I need to keep my systems running smoothly.
Anyway, if things really don't work out there's always the option of creating a 2.6-STABLE branch once 2.6 has settled down a bit. It could be patched with critical fixes, and periodically be moved up to a newer 2.6 release when one is found that's tested well in production, works well, and has been around for a while. Think 2.4.18 . This branch could simply be a further buffer between mainline and users, and provide something that distributors could offer for users who needed it. This all assumes, of course, that 2.6 does remain "stable" in the sense that major breakage is avoided and it's mostly modified to incrementally add important features and tuneups.
Frankly, I'm much happer with what the kernel dev folks are talking about now. I never want to have to think "oh my god, 2.6 is based on 2.5 (which IIRC had repeated releases that couldn't even boot) and one day I'll need that on a server!" ever again.
2.5 showed that trying to rush features into a kernel to meet an arbitrary freeze deadline might not be the best way to get things done, because lots of things cannot be properly finished by that deadline and lots of other things are rushed in all together without enough testing (separately and especially combined). Perhaps slipping features in one by one while maintaining a kernel that always runs properly is a way to get a more reliable kernel and faster, smoother development. It also helps reduce the problem of important features missing release.
I'm game to wait and see what happens. I figure that any one kernel dev on a bad day with a hangover is probably smarter than me, so collectively there's a fair chance I can trust them to do something at least mostly sensible :-)
It's 3:30 AM, so sorry if I've rambled a bit.
--
Craig Ringer
stability
My definition of stability:
- never crash colocated servers (the hassle!);
- being able to update any (production) linux kernel within minutes to a reasonably stable newer version -from an 'official' source such as ftp.kernel.org- when crashes or security bugs are found.
This requires ftp.kernel.org to have a recent and very stable version ready. Which it wouldn't, the way things sound now.
I don't trust (as in, don't want to have to rely on) any distribution.
It's not my desktop I'm worried about; as sysadmin, you need a stable and fairly up-to-date kernel available.
Do you trust your OS vendor t
Do you trust your OS vendor to supply you other critical components, like system libraries?
If so, what makes you distrust your OS vendor for kernels but not for other components?
These are honest questions. I'm not trying to criticize or pick at you. In fact, I might agree with you even.
I'm not the original poster,
I'm not the original poster, but I want to answer this, based on my opinions, in which I fully agree with the original poster.
"Do you trust your OS vendor to supply you other critical components, like system libraries?"
If they are made by the OS vendor instead of a developer community? No. Not very much. They will do their best job, of course, but everyone can make a mistake. A community is IMHO _always_ better than a special vendor development, even if the vendor gives its development to the public domain - because most likely it goes into the distro before it can be tested a lot.
"If so, what makes you distrust your OS vendor for kernels but not for other components?"
Since the "If so" component does not fit anymore, I don't need to answer that, but I want to answer to the rest:
Because an OS vendor _always_ has a smaller testing base than the whole linux community. At least, that's what I believe.
Stability?
From my point of view, the bugs in the kernel will be found quicker which would reduce the number of kernel exploits. (The Good ThingTM)
Adding features should not affect the kernel that much but ripping things out and changing API would cause problems which is the Bad ThingTM.
It will interesting to see which direction it takes.
A comment on the LKML that might be worth reading to clarify
Peter H. Avin wrote:
Informative.
What's interesting is that the Linux kernel development actually seems to gravitate towards this structure naturally.
Really, if you think about it, the -ac tree wasn't so very different. Alan would aggregate patches and feed them to Linus when they were considered "proven", and he'd also carry a number of more experimental patches as well.
The biggest difference is that Andrew seems to be relaxing the thresholds somewhat as compared to Alan. Also, there's a slight reversal in the role of mainline vs. distro: Consider that RedHat essentially shipped the -ac kernel, even though some patches in -ac were seen as not stable enough for mainline.
I wonder if part of this shift is due to the fact that Linux sees more heavy-duty testing on a broad and open basis these days than it did a few years ago? A couple years back, most of the real heavy testing seemed to happen at RH or IBM or similar. Now we have OSDL and a number of other more-open resources.
Linux going the way of GNU libc
The issue here isn't just stability. What might (or even ought) to have some people bothered here is that a critical software component that has previously been claimed by a community is now essentially being taken over by a small group of OS vendors.
Linux is now going the way of GNU libc: Unless your name is Novell or Red Hat, we don't care what you think and wish you would go away.
If sites like Slashdot, Kernel Traffic, and yes, Kernel Trap are any guide, there are plenty of individuals who follow the daily developments of Linux and run recent kernels. These people have been the backbone of testing through the development cycles, right?
The Linux developers of linux-kernel are now leaving them behind, though. They're now disclaiming any usability of Linux on a production server, instead saying only the Red Hat non-freely-distributed kernel is suitable for that.
Is this sustainable? Wasn't Unix dying under this old model, of a bunch of different vendor forks?
The Linux developers of linux
I totally agree, that's exactly the problem, IMHO.
For me, kernel.org is THE authority when I want a "new" or "newer" kernel. Why I trust them? Actually, because of the unproven impression/believe that bugs/hiccups/whatever will become discovered sooner than from any enterprise distro.
How can Red Hat or any other vendor "make sure" (to some extend) that their kernels are "stable"? Simply by staying behind actual development - by using "old" kernels. Fine, they give me a "stable" kernel, but it lacks support of my hardware. Now what, wait a year, or look at kernel.org whether I can find support for it. If I can find a driver, then, of course I want to have it at least impact on the rest of my system. If the driver is only available in an experimental branch, I may decide to download the experimental kernel, use it on my own risk for some time and go back to the other kernel. Or wait until it is put into a branch which is considered to be "not experimental". But if the the idea of non-experimental branches is dropped or if they are hidden within some unclear numbering scheme, what choices do I have then?
The Linux developers of linux
I totally agree, that's exactly the problem, IMHO.
For me, kernel.org is THE authority when I want a "new" or "newer" kernel. Why I trust them? Actually, because of the unproven impression/believe that bugs/hiccups/whatever will become discovered sooner than from any enterprise distro.
How can Red Hat or any other vendor "make sure" (to some extend) that their kernels are "stable"? Simply by staying behind actual development - by using "old" kernels. Fine, they give me a "stable" kernel, but it lacks support of my hardware. Now what, wait a year, or look at kernel.org whether I can find support for it. If I can find a driver, then, of course I want to have it at least impact as possible on the rest of my system. If the driver is only available in an experimental branch, I may decide to download the experimental kernel, use it on my own risk for some time and go back to the other kernel. Or wait until it is put into a branch which is considered to be "not experimental". But if the the idea of non-experimental branches is dropped or if they are hidden within some unclear numbering scheme, what choices do I have then?
Propaganda
My thanks go out to Paul Jackson for his "capitalism versus communism"
propaganda. Ironically, according to Paul's anology, Microsoft, with
its "occasional hundred year [upgrade] floods", is "communist" too.
I think that the discussion of the development/release model of Linux
(the kernel) is more related to "evolutionary (steady stream) central
planning versus revolutionary (occasional floods) central planning"
than it is related to "capitalism versus communism".
Not all that ironic, if you t
Not all that ironic, if you think about it carefully. A corporation is essentially a totalitarian regime in miniature. (or not so miniature, as the case may be)
Contradiction
When I read "2.6 is not the most stable branch of all" that means that another branch is considered to be more stable. Which one could that be? Then I read that "2.6 is a lot more stable than 2.2 and 2.4" Now, should I believe that a development branch is more stable than a stable branch? (SCNR)