Slashdot Mirror
Preview Of Linux 2.5
mojo-raisin writes: "Linux Weekly News is providing a report of the 'Linux 2.5 Kernel Summit,' a gathering of 65 core kernel hackers. Notes are provided on the first day of session, which covers changes required to make Linux more capable on high-performance machines and more user-friendly with hot pluggable devices." 2.5 looks close on the horizon, especially now that Linus has donned a funny paper hat. Better get your feature requests in soon;)
Picture this...
The kernel hacker summit begins, with a beautiful starlit night (hackers would never be caught hacking in bright sunlight). Hackers are absorbing caffiene, discussing better ways to manage memory, more efficient uses for resources and so forth...
Fade to Redmond. [Wide shot of the Microsoft campus] Lightning bolts, thunder and rain abound. Bill Gates is on his throne, stroaking his Evil Goatee(tm). As he pets his cat, he mutters..."Yes, this is my chance..." With a quick decisive action, he calls up his satelite targeting system...aims it at the hacker conference...presses the button, and *BLAM* Blue Screen of Death. Just at that time, our heroes stumble into the room. Scoobie Doo rolls into Bill Gates, knocking him down, and he's pinned under Scooby. "Curses!!!", Bill cries. Fred and Daphne walk up to Bill, and pull off his mask. It's Old Mr. Withers, the curator at the local museum! "I had a good scam going, and I would have got away with it, if it wasn't for you meddling kids, and that mangy mutt!"
Check out my sysadmin blog!
How about getting ACPI working?
/dev/mixer causing it to get reloaded?).
How about improving "apm -s" so I don't need to manually unload my cs sound driver (and first kill xmms which constantly reopens
How about improving boot up time? Including the bootup logo patch?
How about getting DMA mode working on all the IDE controllers out there and having them intelligently configure themselves (I've lost more than one disk to hdparm tweaking).
How about making my mp3's not get choppy when my system starts swapping? (short of needing to apply rtlinux patches and nice --19'ing mpg123).
(DMA overruns too!)
How about including a kflushd that's smart about laptops?
How about cleaning up the documentation for proc.txt, with some examples of what humans could set things to.
How about splitting scsi, ham radio support, pcmcia, architectures, etc, etc into seperate tarballs so I don't need to download them all, or watch make depend go through them all?
I can't imagine that the same schedule() used to handle Apache and Oracle would do the same job as running GNOME..
Why not try ditching LILO for GRUB?
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do ...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on ...
This has been the case for quite some time. I remember reading complaints by many would be contributors that Linux kernel development may as well be closed since it has now become so complex only a few people are able to contribute anything meaningful to it. Also Linus is notorious for not accepting patches that people have worked hard on for a variety of reasons that sometimes smack of petulence.
Anyway, exactly how do you expect the future roadmap of for the Linux kernel to be handled if not by disussions by the people who are contributing about 90% of the code? Heck just a few years ago it was done by one person, Linus, despite the number of patches that were received by the "open Source" community. It's one thing for patches and bug fixes to be handled in a bazaar manner where discussion is done via a mailing list but on the other hand when dealing with the design of the system architecture or "vision for the future" this is best done by as few people as possible. Design by committee is always bad.
Heck even Perl which has probably as many contributors as Linux gone a similar route with a fewer number of developers directing the future of the project.
This alone made linux great because it was a community effort to get the kernel rolling into a quality piece of code
However this "meeting" makes your wonder if this is a community project anymore, there are hundreds of kernel hackers out there, who have in some way contributed code to the kernel
however only 65 get to attend this meeting ..
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do ... ...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on
additionally forking the kernel code just so that the community can work on the code as opposed to a "core" team is even more stupid ... there go whatever standards the linux kernel had ... get what I mean?
just my 2 cents ...
Sunny Dubey
Isn't detecting CPU and internal system temperature already done at the BIOS level? It shouldn't be hard to implement here; just test the temperature levels every time a disk operation fails. But maybe the rest of the room is on fire! But we'll save space in the bad block table once the system is restored.
If you read further down the article, you'll see that Stephen Tweedie, a well-established kernel hacker, read his laundry list of changes, many of which mirrored the Oracle suggestions. Oracle is just pointing out what limits the performance of their file-intensive applications, limitations that other kernel hackers who care about file performance also observed.
I don't think you should see this as Oracle demanding stuff from Linux hackers. I think it is very useful that developers of high-performance application software, such as Oracle, are giving this kind of feedback on kernel performance issues.
Kernel hackers can use this for our (the users) good, not just Oracle's.