Kernel Summit Wrapup
Jonathan Corbet at LWN has posted a terrific summary of the first Day of the Ottawa Kernel Summit, and you should expect the second day soon. In it he relates the greatest hits of the first day's talks, including the AMD Hammer Port, Block I/O, Modules, and more. For mp3s or oggs of this event, check out the Kernel Summit MP3 Repository on SourceForge. The big news is the desire to feature freeze 2.5 within 4 or 5 months. Halloween. I've posted a very small gallery of the group pictures from the summit on my site.
Considering the number of things that are supposed to go in, including things that aren't really even started (beyond looking a bit at the issues) and things that are likely to be disruptive that haven't started to be merged, Halloween seems rather unrealistic. Of course, pushing off things that haven't been acceptably merged by then until 2.7 would probably make for the reduced-feature 2.6 that nobody wanted to commit to explicitly.
Personally, I like the idea of a 2.6 as soon as the big things which are partially merged are finished, with everything else put off until 2.7 and everyone who got their stuff into 2.6 responsible for making sure it's stable under wide testing. There are a number of big improvements already in 2.5, and cutting over to a stable release with those features would be nice. And maybe Marcello could be swindled into maintaining it because it's not _that_ different from 2.4...
When will the ability to run a .class file from a command line be part of the kernel? That is what I care about.
You can't judge a book by the way it wears its hair.
Mmmmmm..... ACLs......
There is a patch (or group of them) that give Linux ACL support. I don't remember the name of it, something like grsecurity. It was mentioned in the WOLKs interview a few stories before this one.
Under capitalism man exploits man. Under communism it's the other way around.
Well, y'see, there's this OS called Windows, made by this guy Gates... it might suit you better.
Somehow I knew I'd get a comment like that. I can't tell if you are a Windows user singing its praises, or some die-hard Linux user that wouldn't ever touch modprobe your life depended on it. Either way, your comment completely misses the point.
I find Linux to be a better OS in general, but it is not without flaws. What is the harm in fixing these flaws? I didn't say everyone needs to use a point-n-drool driver GUI. What I want is a better driver layer, so that stuff like that can exist if necessary. In the instance that you're a "die-hard Linux user", then continue to recompile your kernel or uncomment a modprobe line in your Slackware config whenever you want to install hardware. I just see a lot more potential with Linux driver configuration than that.
We ooh and ahh about "apt-get mozilla" or "emerge mozilla". Single commands that do all the hard work for you. Wouldn't it be great to have programs that could do the same kind of things for drivers also? The best part about Linux is that it is so flexible. You are not confined to a GUI or anything. A powerful underlying driver layer means more sane configuration, more powerful driver scripts, and the possibility of making easy-to-use configuration tools. And best of all, you can continue recompiling your kernel just as you may have always done. Yay! Everyone is happy.
My suggestion was to make Linux better, not to make it Windows. I hope you can see the difference.