Future of 2.4 and 2.6 Kernels

Blair16 writes "According to this article on C|Net, not everybody is chomping at the bit for the new Linux 2.6.0 kernel. Marcelo Tosatti, the appointed deputy for the 2.4 kernel is not expecting to make any non-crucial additions to the popular kernel, saying that all new projects should be pumped into the new 2.6. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?"

Comments

Get Real

[Richard_at_work]

From the linked email:

Having that mentioned, I pretend to: - Fix pending problems which might required more intrusive modifications during 2.4.24. New drivers will be accept during this period (for example, Cyclades PC300 driver, input userlevel driver support, or other sane driver which might come up). - From 2.4.25 on, fix only critical/security problems.

Heh, so that solves the issue of being a kernel maintainer with little time on your hands, only pretend to do stuff :)

From the story text:

. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold

Seriously, are people expecting major changes and new features to be added to a kernel that is supposed to be the stable branch? Doesnt this stuff belong in 2.6? or hell, even 2.7? I for one wouldnt like my kernel to constantly have new and untested features when its supposed to be production capable!

Re:Get Real

[zerocool^]

We're running 2.4.18 on our linux router at Netmar, and we have 3 Cyclades PC300 cards installed, running 5 T-1 lines.

I was under the impression that driver was already in the kernel. I don't remember putting it in there otherwise.

Hrm.

~Wx

Re:Get Real

[Leffe]

I for one wouldnt like my kernel to constantly have new and untested features when its supposed to be production capable!

You know... in the kernel configuration, you can choose yourself what features you want. Simply disable(do not enable) the new scary features and you're done.

I for one, welcome new EXPERIMENTAL/DANGEROUS features.

The virtual /dev file system(EXPERIMENTAL) is *really* nice. There are some problems though, no /dev/mouse. I know the solution though, just create some kind of link to the real device and save it with dev*(whatever its name is). It will be restored at boot, easy as caek.

Oh, and the /dev/mouse problem only affects some stuff, most applications will let you specify a device yourself or use the one XFree86 uses.

Also, the framebuffer stuff rocks.

Re:Get Real

[einstein]

that might explain all those people calling to say the T1 isn't working.... :)

Re:Get Real

[Ed Avis]

Yes. You can't have it both ways. If you don't want to use 'untested' or 'unstable' software, then you have to accept that a stable kernel series like 2.4 means not adding new features unless they are important bugfixes.

Re:Get Real

[ActiveSX]

I mean which is the One True Mouse?

/dev/input/mice - All events from all plugged in mice (hotplug supported ones, anyway) get sent through this device.

Re:Get Real

[GreyWolf3000]

Conversely, if you want to call software 'stable,' then you shouldn't put experimental features in it.

Re:Get Real

[Anime_Fan]

/dev/input/mice works in the 2.6 kernels.

It's a very nice node. I never even got /dev/input/mouseX working in 2.4, though.

$ ls /dev/input
mice mouse0 mouse1

historically

[OffTheLip]

Linux kernels are generally released when ready and not sooner.

well,

[Dreadlord]

...so-called untested software...

I don't know, but shouldn't someone actually test it to become tested? This is the way Open Source works, everyone should help developing the software, even non-programmers, by testing, and I guess the kernel team won't release something for production until it is ready for.

Re:well,

[log2.0]

Im still using 2.4 myself but what I have seen of 2.6 looks very promising.
Nobody is saying that you have to upgrade to 2.6 NOW. 2.4 will still be there and by the time you need something thats not in 2.4, it should be about time for you to switch to 2.6.
These people arent even paying anything for the kernel and they are bitching about it!
I say THANKS to the developers for providing a great piece of software, opensource.

Re:well,

[RealProgrammer]

That's right.

Linus even manipulates this: he knows there is a big hurdle for people between an odd-numbered kernel and an even-numbered one, but he also knows that his quality improvements depend on getting the widest range of bug reports. That's why there's a 2.6.0-testN series.

So even though the code is the same, there's a tension between changing to even numbers to get more use and staying with odd numbers while it's still evolving.

Re:well,

[Zork the Almighty]

I encourage anyone running a desktop system to try 2.6.0-test10. I've occasionally tried the various 2.5.x kernels, but I've always found myself going back to 2.4.2x with Con Kolivas' patchset. Well, no longer. 2.6.0-test10 is better than I expected the 2.6.0 release version to be. If you're the type of person who would upgrade to a new 2.4.x version readily, you should get the new bandwagon now.

Re:well,

[fireboy1919]

I'm using 2.6 most of the time. 2.6 compiles a little faster, runs a little better, and I don't have to patch it as much to use stuff I'd like to use (like ALSA, and preemptive scheduling). If it wasn't for the random crashes, it'd be great.

On the other hand, they STILL haven't addressed CD/DVD-burning at all. There's no support for variable length packet writing, and fixed length is in it's infancy (this is difficult because of a design flaw in the kernel - something that could have been redesigned about three years ago when the format came out). This will be a big problem specifically because DVD+-RW drives are getting pretty cheap, and people can just copy files straight to them on all the other major OSes.

The drives have a standard media format, as well as a standard kind of driver (MMC). There's not really a great reason why using DVD and CD media in UDF format shouldn't involve just mounting a drive and copying files to it.

I guess we'll have to wait another four years before we have close to decent support for cheap file backup.

Re:well,

[Anonymous Coward]

These people arent even paying anything for the kernel and they are bitching about it!

I don't know about that:

Wife: Why do you spend so much time in front of the computer?

Me: It's my job and I enjoy it.

Wife: You love the computer more than MEW

Me: Of couse I don't.

Wife: Then why do you spend so much time on it?

Me: It's my job...

On and on. Believe me I pay for the kernel every day.

Re:well,

[fireboy1919]

Okay. I'll spend a six or so months learning the UDF specification and how the drives work. Then I'll spend a year or two (probably two) learning how the kernel works (because it would be necessary to understand most of the kernel for this process), and another year making the largescale modification that would be necessary to solve this problem. Then I'll spend two more years supporting the project so that it'll make it into the kernel.

At this point, I've taken about as long as it will take for the people who already know how to do it to decide that making the change is a worthwhile endeavor, even from this point.

This comes to a fundamental nature of monolithic development: it takes much, much longer for anyone who didn't write it to write things for it than it does for it's developers to do something on it.

Re:well,

[Eric Green]

> This comes to a fundamental nature of monolithic development

The Linux kernel is monolithic in the sense that it runs everything in a single kernel address space, all at the same protection level, but it is not monolithic in terms of the code structure or the development model.

I'm not sure you understand just how tightly bound the filesystem layer is with the rest of the system now. Sure, you can write to the VFS layer and whip out something fairly swiftly -- but the buffer caching mechanism that is above and below the VFS layer is a hairy bunch of interactions if you want to do anything other than the buffered fixed-size block writes that the VFS layer currently supports. A filesystem that supports variable-sized packet writing would *NOT* be easy, and would require major modifications to the kernel from the VFS layer to buffer cache all the way down to the individual SCSI and IDE drivers (although SCSI drivers, at least, *do* have support for variable-sized packets, so if there's a problem there it's a problem at the IDE driver level). There's just too much hard-wired all down the bottom of the API stack to do things easily if they were not invented at the time that the original authors designed the API stack.

Look, this isn't a problem specific to Linux. When Solaris came out in 1989 or so, it had a state of the art tape driver. Today, its tape driver sucks the big one -- it locks up regularly, does not support any modern tape drive features such as the LOCATE function or block positioning, and otherwise shows the fact that it was designed in 1989-1990 to the primitive hardware available at that time. It appears to be an architectural limitation in the Solaris kernel where it'd take ripping up a bunch of code to fix it, because otherwise the functionality would have been added over the years just as it was in IRIX, FreeBSD, and Linux.

As for why the Linux API stack has gotten so intertangled: It's all about performance. The Linux API stack used to be a lot cleaner and simpler, but as Mindcraft showed (in their second, fair, test, not in the first one that was rigged), it was also significantly slower than a kernel that had been hacked up with all sorts of nifty performance tricks. If you want to, e.g., ship a packet directly from a disk buffer to a network interface (a common performance trick), that means you have an interaction between the network API and the disk buffer API (and the filesystem API that is filling the disk buffer). Those interactions build up over the years. It's called "cruft", and Linux is starting to get somewhat crufty, though it's not as bad as in some applications of Linux's age that I've dealt with.

Anyhow, enough for now. It's late at night even here in San Francisco...

-E

Isn't that the point?

[mortonda]

Hasn't this discussion been held before? Stable kernel remain just that - Stable.

New features always go in new releases. Since 2.6 is around the corner, any new feature need to go in 2.7 now. Big deal. Move along, nothing new or interesting to see here.

Since when does C|Net = reality?

[Gothmolly]

How do these guys have any credibility? Aren't they just fanboys for whonever buys ads, or for whomever [SPIFFY CONSULTANCY COMPANY] says is the Next Big Thing. Want information? Ask RedHat. Ask Linus. Ask the folks at SuSE. What's next, Slashdotters panicking when Dvorak weighs in on kernel patches?

Have cake and eat it too

[the eric conspiracy]

Of course people want new features AND stability.

Pretty funny.

Re:Have cake and eat it too

[TheFrood]

Of course people want new features AND stability.

Exactly. More specifically, they want their new features (i.e., the ones they're interested in) added to 2.4, and everybody else's new features put off to 2.6 to improve stability.

For example, the article mentions that SGI wants their XFS filesystem included in 2.4, so that it can be available quickly in a stable kernel. But they seem to be ignoring the fact that by adding XFS to 2.4, they're making the 2.4 kernel as a whole less stable.

TheFrood

Re:Have cake and eat it too

[macshit]

XFS is apparently a bit unusual in that it requires changes to the generic portions of the kernel as well, so its presence could adversely affect stability even when it's not configured; this is the main reason why Marcelo is reluctant to merge it.

However, he's apparently also decided to wait for a pending review of the XFS changes by Christoph Hellwig (who's a widely trusted kernel hacker, and more pedantic than most [pedantic used in a good sense here :-]), and perhaps will merge it based on that.

[From what I understand, part of the problem is that SGI still uses Irix as the `native' platform for XFS, and so the linux port of XFS tries a bit to make linux look like Irix in order to minimize linux-specific changes to the XFS code-base.]

This post is based merely on casual readership of the LKML, not on actual knowledge of the linux XFS implementation!

"pretend"

[Anonymous Coward]

He sent another mail later that he ment "intend".

Apparently enough people had sent him a patch for that one ;)

Error: Circular Logic

[LostCluster]

If the "well tested" 2.4 kernel were to be adding new features, such new features might risk making it unstable, therefore the time-tested status it has would have to be restarted.

If 2.6 isn't "well tested" enough for your production servers, wait a while. The test of time will perform itself... of course, if you want the new features, you'll just have to take the plunge because somebody's gotta do the testing...

Untested but Worth the Risk

[Bruha]

I think the benefits of a few bugs outweigh the problems they may cause. If I can save 5 million dollars in a server deployment and there's a slight risk of a crash but my data is safe then I'll run that risk.

However some companies are still running RH 7.2 so there will be those who stick with the 2.4 kernel as long as they can. This will more likely be the groups that are unable to move their software from 2.4 to 2.6 due to how they built their systems possibly.

Future of Linux generally

[Sanity]

I think a more general question about how Linux is going to topple Microsoft on the desktop is also warrented. The answer has to be innovation, Linux has been playing "catch-up" for too long.

Fortunately, there are a few really interesting technologies that have received surprisingly little attention, but which I believe point the way toward Linux overtaking Microsoft, and perhaps even Apple on the desktop:

• Dashboard
  This is a wonderful idea where a "dashboard" essentially acts as a memory augmentation tool. It watches what you are doing and presents information it thinks might be relevant. For example, if you are chatting with someone on IRC, it will look for information about that person and present it to you (such as their name, homepage, recent blog entries etc). Applications can support it by sending it "clue packets" to alert it to what it might want to pay attention to.
• Zero Install
  This software essentially eliminates the process of information by mapping web-servers to the filesystem, and combining this with a fast local cache. If your software relies on another piece of software, it can just refer to its binary or libraries on this "web" filesystem, and the appropriate files will be downloaded transparently. The next time you need them, they will be cached. It is infinitely cooler than DEBs or RPMs, and very flexible indeed.
• Gnome Storage
  This project blurs the line between filesystems and databases, creating much more flexibility than is possible with more conventional filesystems. This is particularly powerful when combined with Zero Install. Microsoft is also moving in this direction with their WinFS that will be part of Longhorn.

These projects are the future of Linux, they are novel ideas that will allow Linux to leap-frog its non-free competitors on the desktop. It is a shame that they receive so little attention.

Re:Future of Linux generally

[penguinoid]

I'd like this for my college:

Hibernate-logout hybrid: save data relevant to all programs you have running and logout. Next login starts up everything as you left it. To be presented as an option on logout, for use in shared computers (particularly at a college).

What's the big deal?

[3Suns]

Microsoft no longer develops for Windows 98... Apple no longer develops for OS9...

So they don't want to move on to "untested" 2.6? If people added features to 2.4, it would become just as untested. Nobody's saying to halt all development on 2.4, just not to add new features. Stability fixes will still go in... heck, stability and security fixes are still being added to 2.2! Those who don't want "untested" software favor stability and security anyways... so stick with 2.4.

Re:What's the big deal?

[edwdig]

The big deal is the 2.4 kernel was receiving massive changes (i.e. completely new VM system) in the 2.4.1x range. It really took a while for 2.4 to become a reliable platform. People are scared of the same thing happening here.

Tough

[rnicey]

Well then "some people" can get off their butts, or cough up the cash to do it themselves. It's amazing how some people who use free software think that the developers owe them something.

Erm, no. They wrote it, they can do what they like, how they like and when they like. They don't have to put in features if they don't want to. They certainly don't have to justify their work or decisions to anyone except their contributing peers. If you don't like it please whine to somebody else. Nobody is stopping you from backporting code or doing it yourself.

Why moving now to 2.6 is not always possible

[chrysalis]

The logical volumes manager (device-mapper) is still incomplete in current 2.6 kernels.

Snapshots don't work without an experimental patches.

Other patches are needed to make EVMS properly work.

This is a showstopper.

However, if you don't need virtual volumes, yes, 2.6 definitely :
1) rocks
2) is stable.

an original SCO joke

[Dreadlord]

Checking SCO site, I couldn't find anything regarding the new 2.6 kernel, so I guess no additional fees are charged over the 2.4 kernel, you can upgrade guys with no worries.

Some people are never happy

[bogie]

Sorry but this the way the world of software works. The old version gets put into maintainance mode and eventually is retired. In the Linux world as far as kernels go users and companies have much better deal then they get in the commercial closed source world. For example company X wants to stay on 2.4 for some odd reason. Once 2.6 comes out 2.4 will still be around and updated for security flaws AND they can add/remove/improve 2.4 inhouse any way they want. Sounds like these people just want OSS hackers to continue to do free work for them on an old kernel without regard for the natural order of things. It's all a bit selfish really. They are course free to migrate to an OS where they have Zero control over the kernel and when updates stop, they just stop.

Re:nforce2 support

[Trbmxfz]

There is an nForce configuration option at least in 2.6.0-test10, but, according to discussions that took place this week, there are stability problems. So I guess that yes, this board is going to be supported somehow.

It is interesting to note that Linus doesn't like nVidia releasing binary-only, proprietary drivers, and thus doesn't plan to make it easy for graphics card makers to distribute modules in binary form. To quote him: It's a two-way street: if you don't help me, I don't help you.

So, I don't know whether the nForce documentation comes with hidden "trade secrets" or such, but if nVidia's attitude is the same as for graphic cards, it may not motivate developpers to support their products.

Been using 2.6.0-test11 for 2 weeks now

[ScottGant]

And it's working great. That's 2 weeks without rebooting.

Now, I don't do anything critical or really strain the kernel at all, but it works great...never had one lick of trouble. It's also very peppy!

But for people running critical servers and the like, I can understand their reluctance.

Time for Stability

[M_Carling]

Marcello's position means that the 2.4.x will become much more solid than any Linux kernel has ever been. As new hardware is introduced, there will be pressure to accept drivers to support popular hardware. I expect that Marcello will accept drivers as necessary for 2.4.x to run on popular hardware -- after all, such new drivers impose minimal risk on users without such hardware. I welcome this development, but will keep on open mind as time prove its merit or lack thereof.

2.5 didnt immediately follow 2.4.0 release.....

[Anonymous Coward]

When Linus released 2.4.0, there was a several
month pause before opening 2.5.0. This was to
allow continued bugfix and stabilization work
to happen on 2.4.0. It seems reasonable that
he would do the same w/ 2.6/2.7. So, there should
not be any fear of 2.6 suffering from developer
inattention in the several months after release.
If Linus doesn't release 2.7, the developers can't
ignore 2.6.

Re:2.5 didnt immediately follow 2.4.0 release.....

[uhmmmm]

But because 2.5 wasn't immediately opened, there wasn't an experimental kernel on which experimental ideas could be tried. This led to experimental patches being applied to 2.4 kernels, the so-called stable kernels. Like in 2.4.10, when the whole virtual memory manager was rewritten.

CNet's utter failure to understand

[Xtifr]

Their example is of people who are using XFS with a 2.4 kernel. These people are (according to CNet) "upset" because XFS won't get added to 2.4. Now just think about this for a second: they are using XFS with 2.4 right now! So obviously, they are not being prevented from doing what they want. The whole issue (which CNet is trying to make out as a big deal) is that these people wish they didn't have to perform an extra step (applying a third-party patch). I hardly think it's going to kill these people to keep on doing what they have been doing for a little while longer (i.e. until they decide that the 2.6 series is sufficiently tested that they're willing to trust it). No one is being "left in the cold".

Actually, to be fair to CNet, they're only mildly misrepresenting the situation. The major source of confusion and misrepresentation is (as usual) the slashdot summary.

Huh?

[joto]

saying that all new projects should be pumped into the new 2.6. This has upset some people who are not quite willing to move to so-called untested software.

Exactly what are they bitching about? If they don't want to run untested software, they should run 2.4. If they want new features, they should run 2.6.

So, if untested patches go into 2.4, does that make them anything more stable? The logics of this just escapes me...

Re:nforce2 support

[narfbot]

I have been in the "nforce2 stability discussion", and the lockup issue surrounding it has been believed to be solved. There are two kernel patches available for test11. I don't believe there are any other issues.

I support Marcelo's position

[palmito]

This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold.

This is really not true, since almost ALL the features in the 2.6 branch are available as patches for the 2.4. The 2.4 branch has achieved a nice level of maturity and adding a lot of new stuff to it now makes no sense.

The people complaining should learn the magic of open source. They should realise that at any desirable time they can start mantaining their own tree with their desired features. Hell, starting a new tree is not even necessary since there is such a big variety of 2.4 trees around that the feature they want is most likely already beeing supported by someone else in one of them.

Re:I support Marcelo's position

[ePhil_One]

The people complaining should learn the magic of open source.

Worth noting is that the people complaining are the developers of "new" features, not the users. If a user needs a feature, he'll get the patch and apply it. The particular complainers are SGI's XFS file system team, users already have several choices in the kernel, so if they are not included the kernel their share will drop

Users, on the other hand, want their stable kernels to be stable.

Re:If that is his attitude, consider FreeBSD.

[Pecisk]

I don't get your point. He is about STABILISING 2.4 kernel, NOT about adding new and new features to vanilla kernel and so causing maintaining 2.4 kernel difficult. It's stable now, so let's leave it alone. If you want use XFS with 2.4 kernel, do your patching and go. No one forbids you to do that. And about a trust - I trust my Linux systems. Only because I run them by myself. Not because Linux development is somehow more superior that FreeBSD (or vice versa).

Re:nforce2 support

[narfbot]

Oh yeah. Sound, IDE, and AGP I believe are all supported and working for the nForce2 in 2.6. There is an alpha ethernet driver patch available. I don't see any reason why nvidia should do closed source drivers for a motherboard chipset. If they truly believe there are trade secrets in it, they are truly sick. But since they are new at at it, time will tell if they will change, and if I will buy any more of their products.

Open Source Model

[jfmiller]

Isn't the joy of the OSS model, that if this were truely a problem, a group of users (presumable corperations interested in the viability of thier 2.4 kernel) could get together to create and maintain a patch for the 2.4 kernel that would back port more then just the critical updates from 2.6? I thought that the whole point of having an open model was to allow everyone to mess with the code to make it fit their needs. I know there is always a fear of forking, and that someone will bring up the issue, but there are many patches some like the -ac patch even get posted on kernel.org.

There has alwasy been a gap between the needs of buisness for stable and realiable software and the desire of enthusiests for the latest and greatest. as Linux continues to gain share in diverse markets, I antisipate that the number of patches will likewize increase, making a kernel that can meet the needs of several different types of users.

JFMILLER

XFS on 2.4

[fw3]

See the following from gentu's install doc

We only recommend using this filesystem on Linux systems with high-end SCSI and/or fibre channel storage and a uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly.

And this from one of the more bleeding-edge dists no less.

The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree (see prior posts in this thread). Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high performance, yet have no concept of the tradeoffs delineated above -- well I can see why it's not being accepted into mainline. I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.

Marcello on XFS:

JFS did not touch generic code as I remember. ....
Come one, it is not so hard to maintain a patch in a distros kernel. ....
Distros maintain hundreds of patches (even I did maintain hundreds of patches while maintaining Conectiva's RPM). One more patch is not that hard. ...
Fine, so people who want XFS go compile 2.6.0 by hand. I'm using test11 on several boxes and its working very well. ....
Also I'm not completly sure if the generic changes are fine and I dont like the XFS code in general.

Re:XFS on 2.4

[groomed]

XFS gets a lot of flak. Most of it completely unfounded and wholly inconsiderate of the hard work done by the fine people at SGI to port XFS to Linux. Never mind that it's wholly inconsiderate to the large body of people relying on XFS daily.

The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree

The kernel maintainers haven't been clear on this at all. It's not even true, since XFS has been a part of Linus' tree since 2.6.early.

Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high

XFS has been in service with SGI for over a decade. Arguably it has seen more heavy duty action than most every other filesystem in Linux. It's reputation for being "unreliable" is completely unfounded. At the same time another filesystem for which many, many reports of data loss have come across the lkml, viz. ReiserFS, gets merged into the kernel almost as soon as it compiles. But nobody seems to mind that.

I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.

This has *always* been the argument against the inclusion of XFS, even though the SGI people have done virtually *nothing but* clean up the XFS interfaces since XFS release v1.0. The facts are that there is little, if anything, remaining to clean up: people just don't like XFS.

Marcello on XFS: ... I dont like the XFS code in general.

That is what it boils down to.

The reality is that Marcello has held off on merging 2.4 for over a year, telling the XFS developers to "come back later" or to "clean up X". Now that pretty much everything has been cleaned up, and the definitive deadline is getting near, the real reason for the holdup has finally emerged: Marcello doesn't like the XFS code.

Well, that's his prerogative. But he should have told them in advance. They could have spared themselves the effort!

Re:XFS on 2.4

[Booker]

See the following from gentu's install doc

...snip...

And this from one of the more bleeding-edge dists no less.

Indeed. Bleeding edge often means instability; I have heard some of the freakiest XFS problems from Gentoo users. Problems that often go away when they revert to the stock kernel, so I have to wonder what all Gentoo is doing in their kernel.

Considering that so many of the people who clamor for xfs (imx) are kids...

Indeed. Would those be the kids at Fermilab or the kids at NASA? Maybe the newbies at the Salk Institute or at Incyte Genomics. Perhaps you were thinking of the know-nothings at Quantum or the meddlers at Echostar...

I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.

Please also offer some pointers on which parts of the "interface" you feel should be cleaned up.

Things need to change

[neopara]

I sympathize with the SGI developers, about the inclusion of the xfs filesystem into the kernel. The reasoning for this is because there is a perception that something that is not included into the main kernel branch is unstable, which is absolutely wrong. So it is beneficial for a developers to have their module included into the branch, so it can be considered a proper part of the kernel. I think this is a major weakness to how the kernel releasing structure it set up.

Honestly, I would like to have this releasing structure changed. For example, filesystems don't need to be inside of the kernel branch, only the virtual file system. Let the distributions take care of putting all of the different filesystems into their kernel branch. The kernel branch should be the base point of all the other distribution branches. If you want ext2 in your kernel then go to the ext2 guys and grab the patch and apply to the kernel, no more inclusion. I have already heard people state that patching should not be done by a regular user, which is correct; but that is why you have distributions that have there kernel branches with all of the filesystems they think should be included. No more arguments why one module is inside of the kernel branch and the other isn't.

Linus and his maintainers can now only worry about the main system and let everyone else deal with there on patches. If your patch needs a change to the kernel branch then you talk to Linus and his maintainers. Which they decide if it is a good idea, or if you need to change something in your code. This would lower the amount of releases of the main kernel branch, since there is a smaller amount code that can be changed. Also the releases can be base on if a interface to the main system has been changed which effects the other patches, or just a fix to the internal code. This can lead to easier maintenance of other patches. The more code that can be taken out and put into there out tree the better. Kinda like having a hierarchy of trees.

This can lead to cool pseudo linux distributions where one can say I have xx branch of the kernel. This is already happening like mm-sources, redhat-sources, etc; But taking out the favoritism of the main kernel developers. This could also solve a problem with the size of the kernel source tree in the future when there is tons of different drivers,filesystem,etc.

This is just an example of what it could be like, and I am sure there is more that has to be look at; but think this approach has some credits.

Linux's Acillies' heel?

[MROD]

Now, this comment is mildly off topic, but the article in question does show up a problem with the current structure of the Linux kernel, namely that drivers (including filesystem drivers) are closely intertwined with the workings of the kernel at a source level.

Currently, there is no way that you can have a totally stable kernel and yet have device drivers and filesystems develop independently. To do this, Linux would need at the very least a standardised device driver and filesystem API or better yet, a standardised ABI which doesn't change for the lifetime of a major revision.

All the major commercial UNIX's I know of have a standard ABI for their drivers, as do Windows. This is why you can still get hardware developers who maintain and release versions of device drivers for old releases of kernels for those operating systems for new hardware, because they can. I'd like to see someone try doing that for the current crop of Linux kernels.. oh yes, which version and sub-version from who's source tree was that for?

Not having a standard ABI for drivers helps cause a support hell, not only for end users, but as demonstrated here, the kernel maintainers as well.

explanation

[boldi]

Here's how You should understand this issue:
linux-2.4.0.tar.gz is 24378762 bytes
linux-2.4.23.tar.gz is 37010062 bytes.

So you can expect 2.4.25 etc. won't go over 40 megs compressed. That's what a "stable" kernel development stands for.

(BTW it is kind of weird thing that a stable kernel has grown so much)

This is precisely what the MS FUD machine wants!

[71thumper]

I'm a technical PHB. I started working as a System Admin back on SCO (the original) Xenix in the late 80's. I'm still fairly technical and hands on, but now, at 36, I manage a team and make purchasing decisions, etc., as well.

This is simply WAY WAY WAY too early to talk about stagnating the 2.4 kernel. It feeds directly into the "open source is really a bunch of geeks who are far more interested in shiny new baubles than core business requirements!"

2.6 isn't out yet. And it's not known when it will stabilize (my definition of stable is when revs "live" for more than 30 days).

It's quite possible that a 'stable' 2.6 won't be out for a year. Then it needs to be tested, and a migration plan (since this is NOT a 'build and drop in' kernel) put into place, and that tested.

Easily 18 months or more -- and that's assuming that as soon as the kernel stabilizes, it becomes a company priority to migrate.

Again, MS loves to tout "with open source, you have to build your business around your solution, rather than building your solution around your business."

Big companies don't want to be on this treadmill, they don't want to develop and maintain their own kernel team and kernel tree -- they want stuff that WORKS. And having your own dev organization is a fast way to spend more money than buying someone else's solution.

Hopefully this won't come to pass. But sadly, the fuel's been added to the fire.

Steve

2.6 adoption

[Fenris Ulf]

I disagree, in this case.

2.6 is getting more positive reports and more good buzz on lkml than I have ever seen for a 2.x stable series. There can be no comparison to 2.4's rocky childhood, for example.

I think 2.6 is going to be the smoothest early stable series yet, and that 2.4 is going to be looked back upon as a relative stinker. The subtext in Marcello's posts about 2.4 imply that he thinks the same.

Sometimes I wonder if the difference between 2.4 and 2.6 is the change in the development maintainer's (Linus') source control model -- that is to say, he finally started using one (bitkeeper).

"Back in day..."

[NerveGas]

Back in the day, when everyone was excited for the 2.4 kernels to come out, I was waiting very eagerly. You see, I had just purchased a quad-processer machine, and 2.4 was supposed to scale much better than the 2.2 series. Now, as should be imagined, this wasn't a "toy" or "testing" machine, it was a production database server that the entire company depended on.

When 2.4.1 came out, I downloaded it, compiled it, and installed it on the production machine. It purred along beautifully. I completely forgot about it.

Some time later, the o(1) scheduler patches came out, so I downloaded what was the then-current version, 2.4.17. Here's where it gets good: The database server with the 2.4.1 kernel was still running.

No, I don't mean that I was just still using it. I mean that it was *still running*. It had never been shut down, crashed, or had a reboot for any reason.

Based on that experience, I'm not terribly worried about using the 2.6 kernels.

Even better...

[Spoke]

Is to try out 2.6.0-test11 which is the latest at this point in time.