Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
The Linux Kernel's Fuzzy Future (InformationWeek)The Linux Kernel's Fuzzy Future (InformationWeek)Posted Dec 6, 2004 18:29 UTC (Mon) by iabervon (subscriber, #722)Parent article: The Linux Kernel's Fuzzy Future (InformationWeek)
It's a bit surreal to get to the point where he admits that Microsoft's three-year roadmaps aren't accurate, and have him claim that having additional inaccurate information would still be useful. In that case, shouldn't he just make up a roadmap for Linux?
The real issue is that it doesn't generally take Linux development three years to get from an idea being sufficiently thought-out that it could go on a roadmap to having it done, at least for features with any publicity. A lot of features come from people realizing that something useful is now really easy, due to other work.
On the other hand, it might be useful to have a running list of things that people have announced that they are working on.
As for the fears about the changes in the development process, they run entirely contrary to the actual evidence. Assuming 2.6.10 comes out in about a week, there will have been 11 major releases of 2.6 (counting 2.6.8.1) in 12 months. For 2.4, under the old process, in the first year, there were 17 releases. 2.6 has only recently completed the period, common to all stable series, of having monthly releases, so it is too soon to say anything about the regular rate of releases, although it looks like it is probably not going to be more than twice as fast as 2.4 was once 2.4 settled down (2.4 had a long fast period, then a couple of slow periods, and recently has gotten more consistent).
There has been a concern that the 2.6 series wouldn't include kernels that end users could actually use, and that they would have to use distribution-provided kernels instead. However, in 2.4, no major distribution provided an unmodified kernel, or even close, because they were all backporting changes they felt necessary from the 2.5/2.6 tree, which meant that it was often impossible to go from a distribution kernel to a kernel.org kernel and have the system continue to work correctly. For example, one 2.4 kernel I've used is linux-2.4.19-rmk7-pxa1-cerf1; this is at least 9 versions added onto the official 2.4 kernel to get it to work, and it doesn't include bugfixes in the past 9 2.4 kernels. The 2.6 kernel for the board is 2.6.7-cerfb1, with one set of patches and tracking the official kernel pretty well (2.6.8.1 was the newest kernel at the time).
The main points of the new process are really to minimize the differences between the kernels that distributions were shipping and the kernels that the developers were releasing, and avoid the periods at the start of a stable series where versions come out monthly and don't work very well. A better way of thinking about the new process is that, in the old way, there was a lot of stuff that got backported by distros in divergant ways; in the new process, the kernel team does the backports so they stay consistant. The development series is kept similar, such that bugfixes can be forward-ported to the development kernels as well, and things don't regress going into the next major version due to fixes not propagating. From the standpoint of terminology, it makes sense to keep the version numbers comparable, and the version numbers matter most to the stable kernels, so those numbers are used.
The only issue I see, currently, is that the fixes to the version numbering made in the 2.4 series, where -pre versions were known to not be ready, -rc versions could really become final at any point, and final versions were really quite reliable. I still think it's very odd that Andrew Morton is more in charge of the development series and Linus is more in charge of the stable series.
(Log in to post comments)
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 18:42 UTC (Mon) by allesfresser (subscriber, #216) [Link] I've been puzzled for a long time, (and this is no intended slight to you, iabervon, just an quizzical observation) that many people say it's impossible to run with a vanilla kernel.org kernel. I've *never* run a distribution-provided kernel--always a kernel.org variety--and have never had any problems with stability or dysfunctionality. I'm currently running vanilla 2.6.9 on all three of my machines at home and one at work, and they run like a charm. There's a mix of old and new hardware (Epia 600, Athlon 600, P4 2.6 and P4 1.0) and it doesn't seem to make any difference--the kernel just chugs right along. I'm running Slackware on all of them. I've run things this way since around 1.3.57, I believe... so I've had a while to observe... :-)
Am I just extremely lucky or is there something I'm missing?
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 18:57 UTC (Mon) by emkey (guest, #144) [Link] I've had fairly good luck with the generic kernel in the past. And in some cases I've encountered bugs in vendor kernels that didn't exist in the generic kernel.
In theory vendor kernels should be better since they likely do more formalized testing. In practice I doubt there is a huge amount of difference.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 19:04 UTC (Mon) by maceto (guest, #16498) [Link] hehe you might have a point :-) it has something to do with the user, but I have to say there have been issues with the 2.6 series. And a more tested kernel (debian/redhat/suse) is more TESTED than a vanilla one and might have some bugs fixed, however there are called new/experimential stuff in the kernel and "non -essential/-server stuff" that one can ( yes it`s possible!) leave out...
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 21:49 UTC (Mon) by iabervon (subscriber, #722) [Link] Now that there's better communication and flow of patches into the kernel, the bugs fixed in a distro kernel will probably be also fixed in the vanilla kernel from the same time (which will be a later version than the basis of the distro kernel). The issue is the rate at which bugs which affect the function of features already in the kernel are added. It has seemed that almost all of the regressions have been caught quickly, were necessary evils to fix a more serious problem quickly, or involve uncovering BIOS bugs.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 19:16 UTC (Mon) by iabervon (subscriber, #722) [Link] I've actually personally run only kernel.org kernels on my computers, although I've run distro kernels on all the computers that weren't my own. My experience is that kernel.org kernels rarely have problems, and I've never had any problem I couldn't solve by getting the latest kernel.org kernel. I actually ran 2.4.0 and 2.6.0 for at least a few months when each of these came out.
I believe the reason to use a distro kernel (back when it mattered) was that development kernels were frequently very broken, but stable kernels didn't support new stuff. It's plausible that, when Red Hat released their first 2.4 kernel which supported NTPL, that was a more stable kernel than the 2.5 kernel which was current at the time. So the argument is really that there are some kernel.org kernels which don't run (very true, especially in early 2.5), and that some distro customers want features not in any working kernel.org kernel at some point in time.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 1:59 UTC (Tue) by error27 (subscriber, #8346) [Link] Slackware and Debian etc use more stock kernels than RedHat and SuSE.
I've seen tons of problems where people upgraded to a non-RH kernel. For example, storView broke because Apache broke because it was compiled specifically for one kernel. Or RPM stops working unless you look up on google that you need to export a shell variable. Or stuff uses feature that are in RH 2.4.18 kernel but are not included in the 2.4.20 stock kernel.
The point is that if you move to a stock kernel you might be downgrading even if the number is higher. Downgrading is a pain. If you downgrade from an SE kernel to a kernel from half a year ago then you get fs corruption.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 6:13 UTC (Tue) by wolfrider (guest, #3105) [Link] --The only time I've seen problems when attempting to run a "vanilla" kernel.org kernel on a "Linux system" is with the Red Hat distro.
(Granted, it's been a few years since I even *touched* a RH box - but when they released a CD [~1998? 1999?] where you couldn't even **recompile the kernel** successfully with the **default software** after installation, I swore off RH forever... And switched to SuSE 7.3.)
--I've had good luck with SuSE, and even better luck with Debian (Knoppix.)
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 19:04 UTC (Tue) by dlang (subscriber, #313) [Link] the issue is that major standard kernel version changes useually require tool updates (2.4 to 2.6 involves changes to proc, modules, etc earlier versions had more changes)
if the vendor kernel is 2.4+200 patches implementing additional features then the toolset that is included with that kernel may be somewhere in between what 2.4 and 2.6 need and may not work with either a 2.4 kernel or a 2.6 kernel
RedHat has been the worst case example of this historicly (or at least the most visable) and preventing that is one reason why the 2.6 development is happening the way it is.
|
|
||||||||||