Linux 2.5.2 Kernel Released 234
valdis writes "Amazing.. it's been out over 3 hours and not discussed to death. Well, maybe there's not as many bleeding-edge crazies out there. But if there are, here's what's new. You can get it at the usual place, but please use the mirrors if you can."
Mirrors (Score:5, Informative)
Re:Cool (Score:5, Informative)
Linux Kernel Mailing List FAQ (a must read before submitting bugs or oopses) [tux.org]
Good site about kernel hacking (not just for newbies either) [kernelnewbies.org]
Re:Hardware support (Score:3, Informative)
Instead of bitching around in message forums with your 24.6k modem connection, why don't you spend the time researching what works under linux and what doesn't. Maybe you would have found that there are card readers for every digital film format (compact flash, smartmedia, memorystick, sd etc) that work under linux.
Or maybe, if you can afford "the outrageous price" for the HP printer, you can afford a win32 CD and perhaps then _you_ could do something more than "practice networking skills and use the internet! Whopity-friggin doo!". Or even a mac (which are not expensive compared to a PC. definetly not -especially the imacs).
"I'll do everything within my power, be it donating money to carrying your kids to soccer practice, if you folks will just start writing drivers!"
How about stop bitching and be thankful to the people that _have_ written the million lines of code (including drivers) that make linux usable and enjoyable for us. Oh and start running windows. I have a feeling you two will get along just fine.
New Scheduler (Score:2, Informative)
I believe there was some discussion of integrating Ingo's patch with the preemptive patch, should be good for everyone.
A link to his discussion http://kt.zork.net/kernel-traffic/latest.html#4 [zork.net] on Kernel Traffic.
Re:New Scheduler (Score:3, Informative)
Definitely - but you probably won't notice much difference on most machines - his scheduler was intended to address problems particularly with huge systems. A mere 1-CPU or 2-CPU machine isn't going to see the real benefits.
Which isn't to say the patch is worthless on anything less than 4 CPUs - apparently it beats the old scheduler on all benchmarks. But for most of us, scheduling doesn't take a lot of CPU anyway.
Re:Communication barrier (Score:2, Informative)
Well, it is significant. (Score:2, Informative)
This story is significant because this kernel is really the first tangible departure from the 2.4 branch. Initial USB 2, a very improved scheduler, and other improvements a changelog would do a better job than I of documenting.
Like it or not, these types of changes are significant. Things like schedulers and IO end up being the reason Big Iron companies choose OSes. If Linux is getting there, I personally want to know. If you don't, hey... just move on.
Re:How to compile a standalone module? (Score:2, Informative)
after you configure the kernel, changeing it ONLY
by adding build as module, from something that was not buildt at all. then do a make modules ; make modules_install
this will make only the modules. nothing else.
Re:O(1) Scheduler? (Score:5, Informative)
http://people.redhat.com/mingo/O(1)-scheduler/ [redhat.com]
I must say that after using it for a few days, I'm impressed. It totally changes the characteristics of multiprocess servers like Apache and PostgreSQL under high load. For example, I've run ApacheBench against a mod_perl script that queries a pgsql database, in the new scheduler I get a mean response time that is N*1.05*concurrency with a standard deviation of less than 1% of the mean. In the old scheduler I'd get a mean that is N*1.07*concurrency with a sd of up to 75% of the mean. So in other words you get essentially the same throughput with both schedulers (O(1) appears slightly faster in my limited testing). But what's more important is that in the O(1) scheduler everyone is treated equally - they all get served in 1.05*N*concurrency, no more, no less -- while with the old scheduler some requests get a response that's 1*N and others get a response all the way up to 4*N*concurrency.
IMHO, it's better to give everyone an equal level of service than to randomly favor one group of users over another.
Re: benefits for UP and SMP machines (Score:2, Informative)
But you are absolutely correct in that the scheduler improvements will be more apparent and dramatic on 4 and 8-way machines because of the elimination of the global run queue. Each CPU gets its own run queue and processes will only bounce around when other cpu's are idle. We finally have a scheduler that will work on enterprise class machines.
Re:O(1) Scheduler? (Score:3, Informative)
According to the change log [kernel.org] ingo's scheduler changes _are_ integrated.
Re:or.. (Score:2, Informative)
Drivers are pretty self-contained. The only problem with supporting old hardware is that when you change an API you need to edit all the old driver files. But if you happen to forget one, and it quits working, life goes on - until a user who has the proper hardware complains, at which time the driver is updated.
The model works quite well.
Now occasionally a single driver will keep getting extended until it supports a wide range of similar hardware, and at some point, the developers split it into an "old hw" driver and a "new hw" driver, possibly with some overlap. This happened a long time ago with the NCR 53c8xx driver, and more recently with the Tulip driver.
It's called "Linux-2.2" or "Linux-2.0". Both are still being maintained, by Alan Cox and David Weinehall respectively.
Re:or.. (Score:2, Informative)
...but 2.4 still includes support for all that legacy stuff.
Re:or.. (Score:2, Informative)
Not quite all. Some drivers fall into disrepair and a few no longer even compile - because apparently nobody still has the hardware or cares.
A good example is the xd driver. It's for a PC-XT hard disk controller - that is, pre-IDE/ATA. Someone reported that it no longer worked (I think in the early 2.3 days, could be wrong) and I remember Linus saying "If you haven't upgraded your hardware in 10 years, why are you upgrading your kernel?" The retort was "Because retrocomputing is fun." Someone actually offered to donate an old xd interface card to any developer who would promise to continue to maintain the driver.
I have no idea if anyone took him up on it.