Slashdot Mirror
Taking a look forward: Linux 2.4
A reader sent us the latest story from Joe Pranevich regarding the Linux 2.4 Kernel. Much like his original article on 2.2, he takes a look at what's changing, and what's coming. (Hopefully by this fall. Hopefully).
As for major problems creeping in - uh, that's the point of patchlevel releases (as in major.minor.patchlevel). The filesystem corruption - well, as far as I know it's been mainly due to hardware problems, overclocking and faulty ram and the like. In any case, I think I remember Alan saying something about it being fixed.
Companies want to support Linux (with hardware drivers I suppose)? Great! So just submit the GPL'd driver code to Linus or Alan, get it included, and it'll probably be maintained by some people to make sure that it doesn't break with little tiny changes.
Oh, you mean non-Free, proprietary, binary module type support?
In that case, they can say "This module has been tested to work on 2.2.11. If it works on anything else, that's a complete fluke." as Linus has stated, over and over, that he'll not bend over for the companies who are too anal to release their specs or source code. As far as I personally am concerned, they can go straight to hell, because I'm not supporting them by buying their hardware (Creative Labs, are you listening?) unless they release specs (or the driver's source code).
Yes, they're difficult to write. The difference is, they do not have to be written (at least not the journalling filesystem). Stephen Tweedie has been working on ext3fs, the journalling version of ext2, for some time, even in 2.1-days. When it's finished, it'll probably still be 2.3, and it will be rolled in. Just because it hasn't made its mainstream appearance in the kernel until a certain point, doesn't mean that the work isn't largely finished.
Can we have process/thread forking/cloning as fast as with FreeBSD. My P100 with FreeBSD makes an embarassing mess of my K6-233 running Redhat 6.0. p.s. Does anyone know why FreeBSD (and Solaris) can fork so quickly, and Linux not... (p.s. I am not a kernel hacker :-)
John
John_Chalisque
I don't follow Linux development too closely becuase I don't know enough (yet...) to understand many things, much less contribute. But, does anyone know about how many people actually work on Linux? That is, how many are active and submit code that actually gets added to the kernel? Is there anyone out there who has a fairly accurate count or even a guess?
Take a look at Linux and DVDs for more information...
pb Reply or e-mail; don't vaguely moderate.
I didn't see anything in there about dvd support. Any active kernel developers have a word on that?
------------------
*BSD has the same problems linux does. I don't know if they are working to fix them, i imagine they are, but it's still just as broken.
-matt
I haven't heard this idea voiced yet in all the posts so I thought I'd mention it.
Let's say we get clever and start releasing new 2.x versions every 6 months or so. As we do this and as more and more features get added the chance of some serious problem creaping in becomes more and more likely.
Case in point the file system corruption problem that occures in 2.2.10. Maybe the latest prepatch has fixed this.
The other problem I forsee is that having too many major releases of stable kernels, 2.0,2.2,2.4 etc will make it harder for outside companies to support. That is when they're released within a short period of time.
What I personally would like to see is a release cycle with atleast 1 year between releases. This would give more time to iron out wrinkles.
Shawn
Well, Linus predicted 2.2.0 would come out around October 98, then "by Christmas," and it finally came out in January 99. Based on that track record, I'd predict 2.4.0 will come out around February 2000 or so.
Linux seems to follow the Microsoft release pattern: add six months to the predicted release date. Then, after a "final, stable" release, release 50 or so patches to fix bugs you didn't find before the release.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I don't know how many of you are using Linux in an NFS environment, but for anything more than casual file sharing, the 2.2 kernels and many of the 2.3 kernels can't even keep NFS going between themselves. They seem to make decent clients, but lockd is still broken as of 2.2.10ac12. knfsd still crashes servers sometimes. The user space daemon is fast enough for me (I don't have 40 clients banging on a server), but sometimes clients lose track of handles to the server. On my diskless clients, I seem to do a "mount -o remount,rw /"
:)
more often than I'm doing any work.
I know NFS can work... Linux had excellent NFS support for like three kernel versions somewhere in the 2.1 series. I think we should all make Linus use _only_ NFS for all his work for three months; that would get things fixed in a hurry.
- Faster TCP/IP
- binding NICs to processors
- Useable NFS - one that doesn't crash IRIX 6.5 servers and implements NFS v3
- Guaranteed rate I/O
- Finer kernel locks (this is being done already)
Filesystems/Drivers-- "It's a sad day for American capitalism when a man can't fly a midget on a kite over Central Park" - Jim Moran
2.2 took so long to stabilize because Linux allowed things in after the freeze and it takes time to stabilize two years worth of changes.
If Linus freezes 2.3 in (say) early October and sticks to it, I think 2.4 should be out by the end of the year.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow