Future of 2.4 and 2.6 Kernels 314
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?"
Get Real (Score:5, Insightful)
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!
"pretend" (Score:5, Funny)
Apparently enough people had sent him a patch for that one
Re:Get Real (Score:4, Informative)
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 (Score:5, Funny)
Re:Get Real (Score:5, Interesting)
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
Oh, and the
Also, the framebuffer stuff rocks.
Re:Get Real (Score:5, Informative)
/dev/input/mice - All events from all plugged in mice (hotplug supported ones, anyway) get sent through this device.
Re:Get Real (Score:4, Informative)
It's a very nice node. I never even got
$ ls
mice mouse0 mouse1
I support Marcelo's position (Score:5, Insightful)
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 (Score:5, Informative)
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:Get Real (Score:5, Insightful)
Re:Get Real (Score:4, Insightful)
Re:Get Real (Score:3, Insightful)
Don't know why people insist on having their cake and eating it too. Greedy/lazy I suppose.
historically (Score:5, Funny)
Re:historically (Score:3)
Lets make sure we take care of all those root exploits [securitytracker.com] this time.
well, (Score:5, Insightful)
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, (Score:5, Insightful)
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 (Score:2)
I personally use 2.6 test 11 and while I can't tell if it is anymore stable than 2.4, it is much easier to compile (very few errors vs. vanilla 2.4), and the layout is far easier to understand.
I think it is a good thing to make people move to the 2.6 for new features. The 2.4 kernel will become more stable as less features are added, in theory, and it is open source. I mean they can just add the code themselves like what S
Re:well, (Score:5, Informative)
Even better... (Score:4, Informative)
Re:well, (Score:5, Insightful)
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, (Score:4, Interesting)
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, (Score:3, Insightful)
Okay. I'll spend a six or so months learning the UDF specification and how the drives work.
Maybe. Actually, I don't think it's anywhere near that complicated, but it might take that long because docs may be hard to find.
hen 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)
No. The kernel is quite modular and compartmentalized, and the code is very clean (outside of the device drivers, anyway). You
Re:well, (Score:4, Informative)
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
Re:well, (Score:3, Funny)
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.
Been using 2.6.0-test11 for 2 weeks now (Score:5, Informative)
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.
Re:well, (Score:4, Insightful)
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.
Isn't that the point? (Score:5, Insightful)
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.
"Barn" is to "Stable" as "Manure" is to... (Score:2, Insightful)
In the meantime, there are some bugfixes that look like new features; that's the way software works. There are some new features that look like bugs; ditto. We know that security bugs are considered vital no matter how old the kernel (well, to a point). And so someone often will fix that.
All that to say that it's called "software" b
Since when does C|Net = reality? (Score:5, Informative)
Bias? (Score:3, Insightful)
Yes. I mean, God knows those people won't be biased. It's only Linus' most famous accomplishment. He's a good guy, so he'll not have the slightest bias what-so-ever in any way. And RedHat's not supporting their business model on this stuff, are they? And SuSE, well, they're Germans! That alone should tell you that they'll have no bias for something that their income depends on.
Have cake and eat it too (Score:5, Insightful)
Pretty funny.
Re:Have cake and eat it too (Score:2)
Which is next week...
Re:Have cake and eat it too (Score:5, Insightful)
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 (Score:5, Interesting)
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
[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!
Error: Circular Logic (Score:5, Insightful)
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 (Score:5, Interesting)
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.
Re: (Score:2, Insightful)
nforce2 support (Score:2)
Re:nforce2 support (Score:3, Interesting)
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 k
Re:nforce2 support (Score:4, Informative)
Re:nforce2 support (Score:4, Interesting)
Re:nforce2 support (Score:2)
Does anyone know if this new kernel will support nVidia's nforce2 motherboard? I have it and use the integrated ethernet adapter, but I can't it to work in Linux. It'd be nice to see support for it compiled into a kernel perhaps, or maybe offered as an easier-to-use module. I'm a total newbie, but the learning curve is somewhat steep.
nVidia released a patch for 2.4.20 (with extremeley detailed instrurtions) for the AGP support, and it is the main tree since 2.4.22. The ethernet module (binary only) work
Re:nforce2 support (Score:2, Informative)
* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
* probably the worst PCI ethernet controller ever made, with the possible
* exception of the FEAST chip made by SMC. The 8139 supports bus-master
* DMA, but it has a terrible interface that nullifies any performance
* gains that bus-master DMA usually offers.
better spend those 4 bucks somewhere else...
Re:nforce2 support (Score:3, Informative)
Re:nforce2 support (Score:2)
Future of Linux generally (Score:5, Interesting)
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 [nat.org]
- Zero Install [sourceforge.net]
- Gnome Storage [gnome.org]
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.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.
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.
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.
Re:Future of Linux generally (Score:3, Insightful)
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).
Re:Future of Linux generally (Score:2, Informative)
Re:Future of Linux generally (Score:2, Informative)
Re:Future of Linux generally (Score:2)
Jedidiah
Re:Future of Linux generally (Score:2, Insightful)
Zero Install: Say the zero-install servers get hacked and compromised. Instant virus on millions of computers at once.
Gnome Storage: Hello BeOS. This will be nice, but its been done before.
The future of linux may include these things, but people w
What's the big deal? (Score:5, Informative)
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? (Score:2)
The big deal is... (Score:2)
Seriously, if 2.6.2 or 2.6.3 were out, this would be a much different scenario, but we're only at 2.6.0-test11, so refusing to add new features to the newest non-development kernel strikes me as a major league bad decision!
Re:The big deal is... (Score:2)
Uh.....no. (Score:2)
2.6 is on feature freeze as it should be. But to end the entire kernel series forcing an upgrade to a new kernel that doesn't exist yet? How can you tell me that's not premature?
Re:What's the big deal? (Score:5, Insightful)
Tough (Score:4, Insightful)
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.
Re:Tough (Score:2)
Re:Tough (Score:3, Insightful)
It's not like the maintainer is just there to type "patch -p1 new_feature.patch". He is tasked with studying everything going in, making sure that it works together, and distributing a kernel that meets the users' needs. He has decided (appropriately, in my opinion) that people's needs will be best served by refraining from adding lots of new stuff to the 2.4 kernel. If you want new f
Re:Tough (Score:2)
That's right, and... (Score:2)
And the companies that make money off Linux, especially the ones like Red Hat who have yet to use any sort of 2.6 for anything, who EMPLOY people who make major contributions, don't have to continue to contribute the time of their employees.
Open source may not m
Why moving now to 2.6 is not always possible (Score:5, Informative)
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.
Re:Why moving now to 2.6 is not always possible (Score:2)
Re:Why moving now to 2.6 is not always possible (Score:2)
2.6 is very stable.
But implementation of some features (especially device-mapper) is still incomplete. And it will not change when it will be called 2.6.0, it means adding a lot of new code, not fixing an obvious bug.
Re:Why moving now to 2.6 is not always possible (Score:2)
1) rocks
I'll agree here.
2) is stable.
Not so definite on this one, particularly since my laptop freezes every time I do really intensive database work (and I mean _really_ intensive here - the postmaster process is sitting at 99% CPU utilisation for upwards of 12 hours when it doesn't crash).
Oh well - I'm running test9 as packaged by Debian - I should grab a test11 and see if it still crashes. Or maybe just boot back into 2.4.23 and get
an original SCO joke (Score:5, Funny)
The problem this is? (Score:2, Interesting)
Even easier than you imply. (Score:2)
You just grab a copy of tree and start your own development.
You get your stuff stable AND TESTED and then you talk to the maintainer about adding it.
Some people are never happy (Score:4, Insightful)
Just in from Microsoft.... (Score:2)
Time for Stability (Score:5, Insightful)
2.5 didnt immediately follow 2.4.0 release..... (Score:5, Interesting)
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..... (Score:5, Interesting)
CNet's utter failure to understand (Score:5, Insightful)
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? (Score:4, Insightful)
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...
Official tree only (Score:2, Interesting)
I'd like to point out that the nature of open-source de-emphasizes the importance of central decisions such as this.
Linus and his helpers are the de-facto maintainers, yes, because people find they generally make a good job of it. AFAIK the only legal claim they have is to the name "linux".
If you want the 2.4 kernel line to still have new features added, fine. Download the source, add the features, put it up for download. You could even apply the security and stabilisation patches from the main tree to
not a problem (Score:3, Insightful)
This doesn't even begin to sound like a problem. They'll be on 2.6 soon enough - whether it's a "tried platform" sooner or later.
Re:not a problem (Score:2)
Cnet article lacks information (Score:3, Insightful)
There is very little reason to include it in the stable 2.4, when there may be unresolved issues. I'm not saying that you shouldn't use XFS, but it needs more work than to be in 2.4 by default. Lets face it, XFS has alot of cruft still. The main development right now is in the unstable branch 2.6, which is basically XFS's status. If XFS wants to prove it's stable enough for 2.4, it should do so in 2.6, and then it will get back ported then.
Generally, when something is not ready for a stable line, it doesn't have enough people using it. Even linus said recently that he knows very few people that use XFS.
Then use the old kernel (Score:2)
Sheesh, there are still 2.2, and 1.2.13 boxed kicking around doing work.
If you don't need new features, you can keep using an old kernel.
If you need new features, you probaly want a new kernel anyway.
Jan Rychter is an expert? (Score:3, Insightful)
"I am terrified of the following scenario, which is extremely probable to happen soon," responded Jan Rychter in a Wednesday post. "2.4 is being moved into 'pure maintenance' mode and people are being encouraged to move to 2.6. While people slowly start using 2.6, Linus starts 2.7 and all kernel developers move on to the really cool and fashionable things. 2.6 bug reports receive little attention, as it's much cooler to work on new features than fix bugs."
What insight! I can't imagine how anybody could see that far into the future as Jan Rychter.
So many people use the "cooler to work on new features" argument without evidence. Since when has Linux favoured new features over fewer bugs? Linux 2.4 bugs receive plenty of attention, thank you very much -- so do Linux 2.2 bugs and 2.0 bugs.
Re:Jan Rychter is an expert? (Score:2)
And s/he (Jan) misses the point entirely: people who want the stable kernel series want it because it's stable, not because they're itching for new features.
The nightmare isn't that 2.7 starts, not at all -- it would be developers trying to shoehorn big new features into the released 2.6 series. I suppose another bad situation might be that the stable series doesn't get updated with fixes, but a quick look at kernel.org shows that the 2.0 series is up to .40, the 2.2 series is up to .25, and the 2.4 seri
Open Source Model (Score:5, Insightful)
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 (Score:5, Interesting)
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:
Re:XFS on 2.4 (Score:4, Insightful)
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:
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 (Score:3, Insightful)
Not quite. "In late 1994, SGI released an advanced, journaled file system called XFS on IRIX"> I was managing SGI engineering stations ca '96 when sgi's workstations still by default installed efs. At that time I had been streaming engineering analysis data 24x7 on rs/6000-jfs for months at a time since '93 (when we thought of continuous read/write at 5MB/s as fast :
Re:XFS on 2.4 (Score:4, Interesting)
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 [lkml.org] or the kids at NASA [iu.edu]? Maybe the newbies at the Salk Institute [sgi.com] or at Incyte Genomics [sgi.com]. Perhaps you were thinking of the know-nothings at Quantum [sgi.com] or the meddlers at Echostar... [sgi.com]
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 (Score:3, Insightful)
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.
Apache 2.x (Score:3, Informative)
And so it will be with Linux 2.6.x
2.6 adoption (Score:4, Interesting)
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).
Linux's Acillies' heel? (Score:3, Insightful)
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 (Score:3, Informative)
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! (Score:3, Insightful)
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
"Back in day..." (Score:5, Interesting)
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.
Re:game API? (Score:2, Informative)
Re:If that is his attitude, consider FreeBSD. (Score:3, Insightful)
Re:Champing, not Chomping (Score:2)
http://dictionary.reference.com/search?q=chomp
Re:Champing, not Chomping (Score:2)
But Google, the Fount of All Truth and Knowledge and Only Some Occasional Lies, says you're wrong [googlefight.com]! Do you dare to challenge the opinion of the WHOLE INTERNET?
God I hope so. Bunch of illiterate bastards, if you ask me...
Re:Champing, not Chomping (Score:2)
do you mean that someone will actually come back to /. in the future in order to know how to spell something? He's just screwed then.