Slashdot Mirror
Linux 2.5.2 Kernel Released
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."
Sounds rather interesting. I've had some issues with my Rio 800 MP3 player with many 2.4 kernels, perhaps it's more stable now? Also great that the kernel guys are working on 2.0 support.
Ciryon
Apart from the entire 'slashdot is not freshmeat'-discussion I'd like to note, that maybe slashdot should not mention the URL to the kernel archive, but only the URL for the mirrors-list. I'm sure everyone able to compile and use a 2.5.x kernel is able to find the correct download directory, should he be confronted with a mirror list.
Those of you anxious to contribute by testing I suggest you get acquainted with the following sites:
Linux Kernel Mailing List FAQ (a must read before submitting bugs or oopses)
Good site about kernel hacking (not just for newbies either)
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
Who's modding this thread? Why is everyone a troll for having a laugh? Anyway, everyone knows the fastest way to upgrade linux is to alter the version verision number in the source.
Or maybe most of us are at work and are working on (relatively) stable workstations that we can't tinker with. I'm not a kernel hacker myself (I wait until a distro comes out with a new stable kernel and all the trimmings) but I can imagine that kernel traffic probably peaks after business hours.
Reading LKML has been one of the most enlightening experiences. Following the conversations, reports, complaints and rants you can really piece together a very lucid picture of the very complex nature of large open-source projects. The whole process of kernel development demonstrates why open-source works; how hundreds, if not thousands, of people scattered accross the globe can work on a project; how cooperating with fierce competition produces results.
Some days it's like going to the pub and discussing politics. Other days its a horse track where betting takes place on patches. Still, other days its a battlefield where someone has to prove that he can match wits with his adversaries who are also hacking the kernel. Linux kernel development shows that when you embrace all those human traits (competitiveness, arrogance, violence, love, friendship, shame, curiosity, idolitry, desire, hate, intelligence, stupidity, humor, spite, disgust, altruism), and apply them in the appropriate places at the appropriate times you can achieve much more than if you listened to what you were supposed to do. Like all of life it is a seathing, organic process that becomes what it becomes through relentless change and its ability to fulfill a particular niche. The chemestry is the drive of the hacker; the elements are the lines of code: a primordial soup of abstract ideas.
Just a couple of my thoughts at 5:00am.
http://people.redhat.com/mingo/O(1)-scheduler/
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.