Slashdot Mirror
2.4 Kernel Delayed, Says Linus
cnkeller writes with this snippet from an article in InfoWorld: "BERLIN -- THE much-anticipated 2.4 version of the Linux
kernel will take at least another two months to
complete, Linus Torvalds, creator of the open-source
operating system, said here Friday.
'It's been a slower process than many people would
like,' he said, remarking that developers are no
longer adding new features, only fixing bugs. 'With
luck, we'll see it in early December, and with not so
good luck, I still hope that we can do it this side of
the year.'"
I assume you mean "all other OS's VFSes" because, as absurd as that claim is, the claim that Linux NFS could leave anything at all behind is just too ridiculous even to imagine.
The Linux VFS effort is still crap. Viro and Co. are still fixing major bugs, there are still no regression tests available, there has still been no serious measurement of the changes' performance impact (the only actual numbers I've heard were worse than 2.2), there's still no documentation of interfaces ("read the $#@! code" seems to be Viro's mantra), there are still filesystems that used to work and are now broken because of the changes.
No...Al Viro isn't a genius. He's an arrogant boob who has done more to screw up the Linux kernel than any other single individual has ever been allowed to do. Many people, most particularly Rik van Riel, have had to make heroic efforts to get this mess under control, and it's still barely limping toward respectability.
Oh, believe me, they are adding support for quite a lot
Seriously, how can something be late, when it was never promised by a specific time?
AFAIK, Linus and the kernel crew don't set "scheduled release dates" like Microsoft, so what is this late for?
Move along people, nothing to see here, your new kernel will come when it's ready... Move along..
Recent versions of gcc (2.95 and above, RH7 has 2.96) and kernels don't mix. It's a kernel bug that for some odd reason the kernel developers never accept the existence of. (The same went for egcs during the 2.0.x series...)
Because of this known issue, RH7 includes a "kgcc" package for compiling kernels. You will have to change the kernel makefile to force use of this compiler. (On my machine, 'export CC=kgcc' doesn't seem to do anything...)
retrorocket.o not found, launch anyway?
Well, it seems that most of the people in this thread have had no problems whatsoever with test8 - I love it.
As to Microsoft products - Winblows won't recognize the second IDE channel on my new mobo (VIA KT133 chipset). Bye-bye DVD drive. The drivers that come with Winblows give a "Device is not present or is not working properly.", VIA's updated drivers crash the machine when I try to install them. Yeah, Windows is reeeeaaally stable. That's in addition to the standard BSODs.
retrorocket.o not found, launch anyway?
From what I recall, his project was, among other things, "Mobile Linux", essentially creating a version of Linux to take advantage of all of the Crusoe's power-management features. Admittedly, I'm sure he's up to other things, too.
retrorocket.o not found, launch anyway?
I threw a tarball (uncompressed, thank God) onto a fat partition, then tried to recreate it as an extended rather than primary partition. Bad move; this overwrites both fats.
[lots of failed tries deleted]
I made a new partition there, dd'd it to a file, which gave me a 1.7G file. I then tried to load this with beav on a machine with 160M of ram, and 64M of swap.
It runs out of memory and goes away, hard. It answers pings, but that's it. This is repeatable.
I did the same thing to FreeBSD (3.0?) by middle-clicking on a whole bunch of images in netscape, causing many instances of netscape 3 and xv to launch . . .
These were both as a regular user, not root.
hawk
I'm also running test8 too. Its been a while since I played with devel kernels, but there was a warm fuzzy feeling seeing it was so close. There are many new toys in the code to play with. Its been only running for a few days, but no bugs seen around here.
I'm running test8 as well. If I leave the machine alone for a a few hours I find it covered in dust and cobwebs when I return. As I switch desktops and cause windows to be repainted, I can actually see them being drawn piece by piece, accompanied by a barrage of disk access. Then all is well again. Test8 is not without problems.
--
Fuck the system? Nah, you might catch something.
You got a kernel, it works, end of story.
For what definitions of "works"?
2.2 still has lousy SMP support, and there are a few dozen other things that could be made to work better, which is why we're bothering with 2.4 in the first place. It's the same reason we don't build cars the same way that we did in 1930, despite the fact that the automobiles of 1930 worked.
And pre-2.4 is still rather buggy, for example the IDE support is still unstable. Unknowingly releasing an OS that hoses file systems a significant amount of the time may be an acceptable practice for Microsoft (anybody remember MS-DOS 6.0 and 6.2?), but even they don't knowingly release them.
Second, Linus disagrees with the microkernel philosophy. He believes that the kernel should be close to the hardware, not insulated from it by a hardware abstraction layer. If you think the hardware should be abstracted away, you can always use Minix . . .
Steven E. Ehrbar
The problem isn't that Linus says "the kernel will be out a month from now", every now and then, because generally he hasn't. He's said things like "if we're lucky, we might get this out before the summer", etc. The problem is that people try to put words in his mouth and claim a release is close or misinterpret the numbering of kerenels (v2.4.0test) to mean that the stable version is imminent.
Don't expect a v2.4.0 before seeing at least a few kernels named v2.4.0preX, where X probably should be at least 6 or 7.
Oh, and consider that the v2.1 series went to v2.1.132 before going into pre-patches...
Linus still decides over the kernels. When it comes to the v2.2 kernel, Alan Cox maintains it (he'll probably take over v2.4 sometime in the future when Linus takes on v2.5, but who knows?) and your truly maintains the v2.0 kernel. Linus has the final say on everything though, if he so chooses. The distro's can't force Linus to include anything.
Linus includes what's good technically, not what's good for business. It companies makes good patches, he includes it. Simple as that.
This is true, but nobody would have any way to know if the new Microsoft product were vaporware or not. We know for a fact that the Linux kernel isn't, and if you care to look, you can even get an extremely detailed list of things that still need fixing. Definitely not vaporware. *grin*
Need a Python, C++, Unix, Linux develop
Remind us again how that differs from CSS?
The only differences we're seeing in this regard are -
--
Sheesh, evil *and* a jerk. -- Jade
If you believe the conclusions of The Cathederal and The Bazaar -- that with enough eyes all bugs are shallow you would have to wonder why several of the large open source projects (the Linux 2.4 kernel and Mozilla come to mind), are always late. Yeah yeah, they aren't released until they are ready and there are no release dates, but in both cases the projects have taken much longer than the people running the projects anticipated. Most software projects end up running late becuase of two reasons: feature creep and bug smashing. Given that the 2.4 release has had a feature freeze for quite some time now, the question is... what's holding things back?
Are large open source projects lacking some sort of organizational tools needed to make things run more smoothly? Are they the victims of bad project management, such as it is? Is it becuase after you get above some number n, you fail to gain any more advantages by having more people looking at and working on the code?
DrLunch.com The site that tells you what's for lunch!
Add this one to the fortune database, its too good !
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Yeah, test 8 was nasty. I have been sitting at test 4 since my 2-mouse usb/ps2 combo with gpm only works that far. Test 4 is fine for my vanilla, non-stressed x86. Thats the thing though, are you going to run it under load? Will you loose your job if it crashes? No? Live dangerously, run unstable... who cares when Linus advises the masses to try a crackat it.
-- http://thegirlorthecar.com funny dating game for guys
But that's because NVidia sucks and won't release open-source drivers that people can debug.
NVIDIAs "driver" is a full featured, highly optimized OpenGL implementation containing intellectual property of SGI. You should be happy to get it for free (as in beer, and OK, you had to buy the video card).
Now I have disabled Fast Writes and the driver runs rock solid and really fast (almost on par with Windows) under 2.4.0-test. I really don't care if it's open-sourced now...
A Dick and a Bush .. You know somebody's gonna get screwed.
War is necrophilia.
I've been using the 2.3 backbatches and they work fine. I've got a Logitech USB trackball, a sony F505 digital camera and the matel electronic magnifing glass all working fine. I did have to make a few changes in a table for the sony camera but it now works fine. There is a bug in the scsi drivers that had to be fixed as well.
But it's going to be rock-solid when it comes out...
Linus said a similar thing just before he put the paper bag over his head. Seriously, no software is going to be released rock-solid. Linux is getting very complicated.
The only thing you can hope for is all the major show-stopping stuff cleaned. The little bugs found later can and will be patched as required.
What really irks me is that this kernel is already in -test. What exactly have they been doing to a test kernel? Wasn't the feature freeze months ago? I remember that the 2.2-test series was like a month long. Methinks that someobody was so eager to get 2.4 out the door, that they went to 2.4-test prematurely.
A deep unwavering belief is a sure sign you're missing something...
Again, you overestimate the power of OSS. OSS developers have almost the same amount of pressure to get a release out as do commercial developer. Paying for a long project is only one reason why commercial developers push out releases early. Other reasons, ones that OSS developers are prone to as well are,
A) Expectations of the people. If somebody said that something was coming out in January, and it comes out in November, a lot of people are going to be pissed. In the real world, you can't afford to piss of your userbase.
B) Competition. If it looked like FreeBSD 5.0 would be out three months before 2.4 would be ready, and it would have tons more features, you can bet that the devs would be under pressure to get 2.4 out the door. Nobody, including OSS developers, wants their software to be obsolete the minute it comes out.
C) Getting bored. Long projects are seriously dull. The longer a project like the kernel wears on in the bug-fix stage (without sexy features to work on) the more tired people are going to be of it, and the more likely they will be to release it.
If you need proof that OSS isn't a magic bullet, take a look at Diakatana. Their parent company really didn't do much to force them to release the thing, and they had tons of time for development. Yet, the product was still released prematurely. OSS prevents a company from breathing down your neck about how much the project is costing. All the other factors are still a problem.
A deep unwavering belief is a sure sign you're missing something...
decent kernel compiled with knowing just a little about what they need (ie if you can't identify it, you don't need it usually).
>>>>>>>>>
Really? I remember when I compiled my first few kernels, I had no clue what TCP/IP did (I wasn't on a network) and I left TCP/IP and networking completely out of the kernel. Then I spent a couple of days wondering why the hell X wasn't working.
A deep unwavering belief is a sure sign you're missing something...
Uh, as much as I advocate user involvement, final bugfixes of a kernel release are maybe not the best way for people just learning C to start out.. :). But, anyone with a few logic skills can help out by A) finding crashes/bugs/bad stuff, B) isolating the variables that affect said problem, and C) sending detailed reports to the kernel mailing list.
People with some experience in C may want to look at the code to try to find the problem, and either point kernel hackers at the suspect area or submit a patch. But this is much less important than detailed bug analysis: usually it is a simple matter for a kernel hacker to fix many bugs once reproducing them is down to a science.
If you feel like hacking, by all means dig in, but always include bug reports in addition to patches. And test patches on as many systems as you can before submission.
No big deal, for me. I'm pretty happy with 2.2.17, and I'll be even happier with 2.2.18(the pre- series has some bugfixes I've been waiting for). I'm glad Linus decided to postpone the release, but it would have been nice had the article mentioned specifically what was holding it up. ie; bugfixes, waiting for some important code/drivers, etc., etc..
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I've been running test-7 at work for since it came out and have nothing but praise for it. Just wondered what was going to take so long to fix.
2.4 will be late (not as late) probably have a number of bugs (but not 64K worth) and have way more than what was originally promised.
You can flame if you'd like, but I can easily see the value and equity of waiting a bit longer for a lot more.
`ø,,ø`ø,,ø!
Free Software: Like love, it grows best when given away.
Will it be Mozilla or 2.4?
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
But when will I be able to get a distro including Kernel 2.4, Gnome 1.4 and KDE 2.0? I want to show of Linux to my friends but I don't think the current distrobutions are ready for that.
That said, I do prefer a delay over a buggy kernel/desktop environment.
Monkey sense
[drug]
;)
I am a patch junkie! I need to get 2.4!
I don't trust the pre-versions and the bloody-edge odd numbered releases!
Please, call it 2.4! C'mon, man!
I'm jonesin' for a fix!
[/drug]
Seriously, I hope that 2.4 is filled with fresh code and higher-levelUSB support. (I cannot wait to add a USB HD
And maybe better joystick support.
I used to be someone else. Now I'm someone better.
Real life is underrated.
censor
/'sen(t)-s&-ri[ng],
'sen(t)s-ri[ng]/
Date: 1882
: to examine in order to suppress or delete
anything considered objectionable
Function: transitive verb
Inflected Form(s): censored; censoring
IF ANYONE DOESN'T LIKE MY SIG PLEASE EMAIL CMDR_TACO AND CONVINCE HIM TO DELETE IT.
134340: I am not a number. I am a free planet!
The Pre release Kernel running in the machine on my right works fine.
The Win 98 machine on my left has locked up twice today.
1. Beta Software That works
2. Production Software that Dies
3. Cowboy Neal
134340: I am not a number. I am a free planet!
kdb in mainstream sources in a overworked point.
You can patch the kernel for use with a debugger without a problem, Linus just doesn't want to distribute a standard one. It's kruft in his opinion and he isn't/can't stop anyone from inserting their own anyway.
It's the use or not of kdb that's actualy at issue with the developers. The violent discussions are about whether it's a good idea or not. To include one or not isn't something that too many developers care that much about.
Those who need one, will choose one from the many available and install it - not a tough issue.
As for vaporware the difference in the Open Source / Free Software case is that anyone can try it out and see for themselves how vapourous it is.
Open developments can be no more vaporware than the brain one carries on the upper shelf.
Why? Because its open and you can watch and judge for yourself.
If one can not judge for himself, he has been lost to the world of marketing and may require rehabilitation if one so desires.
Sure, other another OS may be more stable, but who gives a rats ass if they can't click on the edit button in IE and edit content on their intranet using a word processor (IE and MS Word).
And if companies use this MS technology themselves, other companies would want to use the same technology to communicate with them!
Here of B2B? Yes, automate the exchange of information. How many are using Linux solutions on the desktop? There isn't a choice that compares. No I am not talking about the linux guys back in the computer room. I am talking about the employees that only want to click and edit. These employees can not do this with a current Linux solution. They cannot do this because Netscape currently sucks.
What about Star Office? Sure, do they have a web browser that incorporates all this data in a way that is easy to edit, share, and post like IE and MS Office? No.
Until a solution is provided for Linux, MS will dominate. And if MS continues to dominate at this level, you will see other MS products being used because the can "integrate" this information more easily with "common" IS employees that they employ.
Linux needs a new web browser.
"Being a person with very little Linux experience, I would like to know how this thing works. Does Linus still make the kernel releases, and then other companies change it? Or does he incorporate parts of companies' codes along with it? Please help a curious nerd out."
From what I've seen, the answer is "yes"...
It looks like Linus is where the final "official" kernel comes from, posted at ftp.kernel.org, and then the distros add what they feel they want to. Since the GPL is what the kernel is released under, changes that the distros make can be re-incorporated into Linus' version of the kernel, and the distros can't really get mad, and don't. If Linus doesn't want a distro's mod in the kernel, he doesn't have to, but the distro can continue to use it, and Linus can't really get mad either. The point here is that some really intelligent company can always add to it, and until Linus and his people get the new mods installed, the distro can sell the service for that particular variant as a unique service. Later, one that component is integrated, they will have to develop a new piece. A really bad company can be ignored by the original sources, and will just die off if they do a bad job.
I think this is how it goes...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
Well, yeah... Microsoft doesn't release source code for their beta releases. We can't actually see what they've done, and we can't decide to use it professionally anyway. Maybe some year they'll realise why people are so willing to adopt X.0 releases of UNIX products and why people wait for Microsoft X service pack 1 before buying their products...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
Thank you
> we were on 2.0 for a LOT longer
Mmm.
2.0.0: Jun 96
2.2.0: Jan 99
That's two year and a half. We'll be on 2.2 for nearly two years *if* it releases in december.
So, no. Not a LOT longer...
Cheers,
--fred
I don't know if anyone here still remembers the days when Linus jumped the revision numbers of the kernel from the .Teens to the .9x...he was sure it was almost ready...but we had at least 50 revisions before the 1.0 kernel was ready. It was challenging to keep track of the various number/letter/level version...but I didn't mind. We eventually got the 1.0 kernel, and I was happy to wait until it's done, because it was done well. And I expect it is the same with the 2.4 kernel.
It's chick to slam Linus and Co., but it's one heck of a job they are doing, many in their spare time...let's cut them some slack, eh?
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
While I don't know about HDs, USB audio devices and scanners are supported. (Your particular device may not be, but many are.) There is USB storage support in the kernel, but I think it's going to remain marked as experimental even in the final 2.4 release. (Of course, some of the "experimental" code in Linux works quite well...)
:)
The kernel support for USB mice definately kicks ass. I finally moved my IntelliMouse Explorer from the PS/2 port to the USB port (Higher sampling rate with USB), and I'm 2-3 times as lethal with the sniper rifle in Q3Fortress and Unreal Tournament.
retrorocket.o not found, launch anyway?
I have to agree... Yeah, 2.4 may be a bit late. But it's going to be rock-solid when it comes out...
I'm running 2.4.0-test8 (was running test7) on my box, and it's a champ. This pre-release already kicks the crap out of anything our friends in Redmond can put out...
The only time my box is unstable is when doing 3D work. But that's because NVidia sucks and won't release open-source drivers that people can debug.
In an offtopic note: Could NVidia's refusal to release source have to do with the fact that the GeForce and Quadro are identical chips, only differing in their device ID number? (i.e. from what I've read at http://www.geocities.com/tnaw_xtennis/, the driver is what makes the difference between the two "chips" - If the card reports itself as a GeForce, the driver disables some features.)
retrorocket.o not found, launch anyway?
I've been running 2.4.0-test8, and most of the 'test' patches have been *big* patches. Along with that, I've also patched in support for reiserfs, arla, and ALSA.
:)
Since the filesystem code has been overhauled somewhat, the first patches I got broke, and I had to fix them; alsa was fine (sound code), reiserfs was fairly stable, and arla was just broken. After waiting a bit longer, I got the latest patches; it all compiled cleanly, and reiserfs is solid, the kernel is a little less stable, and arla is still somewhat buggy, but much improved.
So half the reason for delaying a kernel release is to fix bugs, but the other half is to make sure that everyone else relying on the kernel has time to catch up and write for the new API. OpenWall will have their patch for 2.4 when it's stable, which they predict to be around 2.4.10.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
It's not vaporware -- you can use a 2.4.0test kernel right now.
And as for Microsoft? Most importantly, Microsoft uses product announcements and projected delivery dates to deflect interest in competitor's products and they time releases to benefit their business. Why? Their product decisions are driven by their marketing efforts. They seek to create demand, and then fill it.
Linux kernel development and feature advancement are technology-driven and aim to supply solutions for existing demand. (Note that I'm referring to the kernel, not to application SW.) There is no marketing machine at the heart of Linux, and vaporware is the product of marketing.
-dwd-
Different reasons for different projects.
In Mozilla's case, (according to JWZ at least) it was the combination of a poor decisions and bad management of the overall project.
Linux releases are always "late" because they've always been that way, because there is no due date. Who cares when a release comes out? True, Linus would like to get stuff out, but only because it's important to keep things moving. He's certainly not motivated by any corporate interests, if his resistance to whiny coders complaining about features not being added or APIs being changed is any indication of his stalwardness.
But 2.0 and 2.2 did make it out eventually, and they weren't too late to still be a progressively royaler pain in every competing operating systems' ass. What more could one want?
s/NFS/VFS/ -- Yup, wishful typo... :^)
Alexander Viro might be arrogant, but the VFS is still something extraordinary. Of course, there are major bugs. After all, he did a major overhaul of it. The performance gains with the new VFS is mostly on the SMP level. And the major gain isn't even the performance question. The VFS rewrite was done to make the code sane.
The rewrite is not finished; Al is still working on fixing the remaining non-working filesystems. But some of the filesystems doesn't have a maintainer anymore, and they'll probably remain broken. But we can't possibly set the VFS in stone forever on just to make sure filesystems that lack a maintainer still work for all coming kernels. Drivers/subsystems without a maintainer is a breed-reactor damn closed to having a nuclear meltdown.
It seems that everyone around here has ants in their pants whenever kernel 2.4 is mentioned anywhere. Linux is growing up folks, and some people around here are acting like 5 year-olds in a toy store - they see it, they want it now, and they'll kick and scream untill they finally get it.
Linux has gotten a lot of press lately and that means that in addition to all the hackers' eyes, we've got the media paying quite a bit of attention too. Rather than bashing Linus for going 'corporate' and doing his job at Transmeta instead of devoting every single waking moment to 2.4, we should be grateful that such attention is being payed to quality. If we're going to win the battle agains MS we're going to need some pretty kickass software to do it with.
There is no one stopping you from using kernel 2.4.0test9 right now, and completely free. With Microsoft software, and other closed-source software, you cannot take advantage of any of the new features, although maybe you wouldn't want to because it's so buggy. Also, if they'd done anything on the product, they're preventing any of the good stuff they've been creating from being used by the public.
"The price of freedom is eternal vigilance." - Thomas Jefferson
And for those who want to follow things more easily, read Kernel Traffic. (Click latest on the left bar).
- Michael T. Babcock (Yes, I blog)
Sorry, you've been busted by the FUD police. I don't know what you do with your box, but I run an Oracle 8i instance on mine which is heavily used by software developers. I had to go back to 2.2.16, test8 is atrocious under heavy load. Windows 2000 would never run as poorly as test8 does. Note they've put in an new VM for test9, which is in the "pre" stage right now.
--jbIt might be worth you time then to bring this up on linux-kernel. A large amount of 2.4 stuff (USB and the kernel DRI code at least and I think more) is being backported into the 2.2.18-pre's. If you asked nicely (or better yet helped if you have the know-how) you might get that wish.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
It may be annoying that 2.4 will be later, but I'd rather stick with 2.2 and wait for a really good 2.4, than have to go to 2.4.1, 2.4.2, etc. If this were any other *cough* operating system it would have been released anyway. Besides, we've not been on 2.2 for an extremely long time, we were on 2.0 for a LOT longer...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
I take it you've never worked on a big software project? Every big piece of software I can think of has been late, including the ones I've been on.
My theory is that you initally can't see all the problems you're going to hit in software development. So the first schedule is never right, because nobody can truely estimate what it takes to ge the job done. And once the first date is off, then you're slipping and the pressure is on to bring in the dates. But that just makes things worse because now people get burnt and hurried.
It comes down to the fact that unlike other engineering efforts, nobody can accurately estimate software development.
It has little to do with open source v. closed source, IMHO.
-- topher71
I didn't know that there was a schedule. I coulda sworn that the official statement of kernel releases was that "It'll be out when it's done."
We need stable, reliable software, not buggy software. People have come to love and use Linux because it's stable and reliable. The last thing Linus needs is pressure to release the most important part of _our_ OS because of marketing hype. Look at some of the Open Source Releases lately (trying not to point fingers!!).. markey hype pushes them to release software before it's ready, then they trickle the patches and updates through the Internet.
I never was afraid of using a x.x.0 kernel, and I don't want that to change. People wanting the bleeding edge can simply compile the PRE kernels!
I mean, uh, I have an idea guys, how about we NOT worry about it, since this isn't really news? :)
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
Tux the Linux Peguin lived in a Red Hat box
and debugged the kernel with a guy named Alan Cox
Little Linus Torvalds loved that rascal Tux
and wrote him strings and bits and bytes and took out all the cruft
Oh, Tux the Linux Penguin lived in a Red Hat box
and wished upon those closed-source guys a great big nasty pox
Together they would travel to a place known as Slash Dot
Old Bill kept a log-book of all the flames that MS got
All the Gates and Windows would close whene'er they came
Stevie B. would have bad dreams and call out Tuxs' name
Oh, Tux the Linux Penguin lived in a Red Hat box
and sorted the linked lists with a guy named Alan Cox
A Penguin lives forever, but not so old man Bill
E.S.R. and R.M.S., they shot his life to hell
One day it happened, Bill could no longer hack
and Tux the Linux Penguin let out a mighty quack
His belly filled with herring, free software fell like rain,
Every man and woman could change the stuff in main()
Without his life-long rival, Tux began a GNU
So Tux that Linux Penguin finally flapped his wings and FLEW
One of the main reasons that the v2.4 kernel has taken so long is the late rewrite of the VM. However, as of a released fix today by Rik van Riel, it's REALLY looking nice. I've tried extremely hard to make my 16MB memory/64 MB swap box to croak, and yet failed so far.
And the new VFS in the kernel leaves most, if not all other OS's NFS:es far behind, imho. Alexander Viro is a genious in this regard.
Some things will simply have to wait for v2.5, such as a good journalling layer for the journaling filesystems, but it would not be too wild a guess that we'll see a journaling filesystem going into the v2.4 series before v2.4.6.
It seems that the only BAD thing is that Linus started us out on the 2.4.0testXXX series way too early. It got peoples hopes up even when the VM was horribly broken and many kernel features were broken...
I can only see this as a good thing, because when 2.4 hits the streets, it will be used by LOTS of people... and we want it to be as stable and reliable as ever...
right?
-Chris
I have been following the development of the 2.4 kernel since test5, which is about 3 months ago.
For starters, a bunch of drivers that worked in 2.2.x are broken currently in 2.4. Those need a fix before 2.4 turns final.
Recently there was a lot of work on the VM (virtual memory subsystem). It's a very smooth VM, reminds you of FreeBSD ;). But it's also a bit buggy at the moment, so it must be fixed before 2.4-final.
With more people testing the 2.4 kernel, with more bug reports, it will be a lot better for the developers to fix 2.4 to perfection, so hurry up and try the new kernel. I recommend trying out test8 or test7, or test9 with Rik van Riel's latest VM patch.
.