Linux Kernel v2.6.23 Released 346
diegocgteleline.es writes "After 3 months, Linus has released Linux 2.6.23. This version includes the new and shiny CFS process scheduler, a simpler read-ahead mechanism, the lguest 'Linux-on-Linux' paravirtualization hypervisor, XEN guest support, KVM smp guest support, and variable process argument length. SLUB is now the default slab allocator, there's SELinux protection for exploiting null dereferences using mmap, XFS and ext4 improvements, PPP over L2TP support. Also the 'lumpy' reclaim algorithm, a userspace driver framework, the O_CLOEXEC file descriptor flag, splice improvements, a new fallocate() syscall, lock statistics, support for multiqueue network devices, various new drivers, and many other minor features and fixes. See the changelog for details."
What about the license? (Score:4, Interesting)
I love my Thinkpad (Score:3, Interesting)
Woot!
Methinks... (Score:5, Interesting)
What about O_CLOEXEC for sockets? (Score:5, Interesting)
Yes, this is a good thing. However, they seem to have missed some: sockets and pipes. Sockets are not close-on-exec by default, so you may pass a sensitive socket to a child.
Windows NT has the same problem: sockets are inheritable by default until you call SetHandleInformation to disable inheritance. Other handles' inheritability is selected at open/create time.
Luckily, there is a workaround for it, if not pretty: use a reader/writer lock with opening handles as writers and forks as readers.
By the way, the linked changelog on kernelnewbies.org has a bad link for the "recommended LWN article".
For the SELinux thing against null pointer attacks, won't that break DOSemu?
Linux catches up to Windows 2000? (Score:4, Interesting)
I was about to go and make fun of Linux for creating a feature that's been around in Windows for quite a while - take your pick of SetFilePointer or sparse files. Yes, yes, I understand that reserving space for a file is not the same as growing it and not using that space. Twas meant to be a troll....But, it turns out that a bit of googling reveals that sparse files under Windows are not all that they are cracked up to be:
http://www.flexhex.com/docs/articles/sparse-files.phtml [flexhex.com]
Re:What about the license? (Score:3, Interesting)
Relicensing existing code might be too strenuous, but if many developers decide to follow this dual-licensing approach, the relicensing of Linux may be made easier by module replacement, as old GPL v2 code is swapped out for new "either GPL v2 or v3" dual-licensed code coming in.
In any case, this is highly speculative, and as much as I would like Linux to be under the GPL v2 (I think tivoization sucks), if its authors don't care about it as much as we do, I don't feel inclined to raise a stink. Or maybe I am inclined to raise it against tivoizers, but not against developers themselves. We can still use Linux, and I for one thank our kernel developer overlords for their good job working for all of us.
(Note: I know there are several BSD kernels, but that's true also of Linux: there are several forks for different uses and profiles).
Userspace drivers? (Score:3, Interesting)
The real Linux news today. (Score:5, Interesting)
Re:Userspace drivers? (Score:5, Interesting)
Long answer: if NVIDIA ever makes open source drivers, they will almost definitely be kernel space drivers. Apparently this is in the works, same with ATI, but I'll believe it when it happens. It would be possible for some bored hacker to take the NVIDIA binary blobs and make a userspace driver from them. This driver could be legally distributed with the NVIDIA binary blobs (probably). And yes, this would mean that recompiling the drivers for a new kernel would not be necessary.. and it would also mean that the kernel wouldn't be "tainted" by using this driver (maybe).
I, personally, think the stability and security advantages of running binary blobs in userspace drivers outweighs the possible performance hit (no-one has measured the performance hit, yet), so it's a good idea. But, ya know, I've got some other stuff to do...
Re:Massive speed of kernel evolution (Score:5, Interesting)
Proprietary operating systems can't compete because they're closed. The best an innovative user/developer can do is fire off feedback asking for a feature, and it'll be implemented wrong anyway, and then released 3 years later in the next major version.
Even more impressive is that this is the *stable* kernel branch that's growing so fast. The -mm experimental branch has gone right off the hook, to the point Andrew is complaining the development doesn't scale any more with only him at the helm.
For those who want a more conservative choice for servers, there's always something like FreeBSD. It's nice to have choice and interoperability. FreeBSD is more compatible with Linux than Windows XP is compatible with Windows Vista. If you don't believe me, consider that at least FreeBSD and Linux have a lot of standards (APIs, file formats, layouts, etc) in common.
Re:A pre-packaged ISO, please... (Score:3, Interesting)
Re:Massive speed of kernel evolution (Score:3, Interesting)
I think they write out every little thing they did, designed to more impress than really say oh wow, big new features. Microsoft major releases go in circles, but they do some pretty big stuff. Let's see, starting in NT4, they put the graphics drivers into the kernel, then a few releases later, they moved them out. Then they shifted the whole driver model around a few times. Then they put http protocol into the kernel, then they put the sound drivers outside of the kernel and probably down the road, something will inspire them to move http out of the kernel and put the sound drivers back into the kernel space. And, some of the features they've added along the way include incremental improvements to kernel queues, and, like Linux, MS seems to always be searching for a better scheduler.
bloat (Score:1, Interesting)
Dreamcast support (Score:3, Interesting)
More dreamcast support is on the way - expect some more stuff in 2.6.24 and 2.6.25 and I (the author of the code) would love to hear from willing testers, etc
Re:You know the drill... (Score:3, Interesting)
They have heredity - the actual text of the cliche. E.g. "In Soviet Russia X verb Y", or "In Korea only old people do X".
They are subject to natural selection as popular memes will replicate faster by definition.
They have mutations - random(ish) changes, typos or non sequitur that add humour. They even have sexual repoduction since memes can be combined for humorous effect. E.g. in a story about dogs attacking people in North Korea I could quip "In Soviet Korea, dog eat old people!" combining two memes. Both effects are used to avoid an analogue of Muller's ratchet [wikipedia.org] where a stale meme is no longer funny and thus is not copied.
They are also highly virulent to the point where they can take over message boards completely.
Re:You know the drill... (Score:2, Interesting)