Linux Kernel 2.6.14 Released
digitalderbs writes "Linux kernel 2.6.14 was released on 10-28. OSnews reports on new features like 'HostAP, FUSE, the linux port of the plan9's 9P protocol, netlink connector, relayfs, securityfs, centrino's wireless drivers, support for DCCP (currently a RFC draft, PPTP, full 4 page-table support for ppc64, numa-aware slab allocator, lock-free descriptor lookup' and many other things. The changelog is also available."
Released October 27, 2005 changelog
Numa-aware slab allocator: It creates slabs on multiple nodes and manages slabs in such a way that locality of allocations is optimized. Each node has its own list of partial, free and full slabs. All object allocations for a node occur from node specific slab lists (commit - benchmarks)
Lazy page table copies in fork() for VMAs without anonymous pages (the ones with anonymous pages are still copied): Defer copying of ptes until fault time when it is possible to reconstruct the pte from backing store, speeding up fork() greatly specially for processes using lots of shared memory (commit)
Add /proc/$PID/smaps: This file will shows how much memory is
resident in each mapping. Useful for people who want to perform memory
consumption analysis (commit)
Add /proc/$PID/numa_maps: This file will show on which nodes pages reside (commit)
Lock-free file descriptor look-up (commit) - (commit)
Four-level page table support for the ppc64 architecture: extends the usable user address range to 44 bits (16T). (commit)
Support hotplug cpu on 32-bit SMP powermacs: When a cpu is off-lined, it is put into sleep mode with interrupts disabled. It can be on-lined again by asserting its soft-reset pin, which is connected to a GPIO pin (commit)
Add TASK_NONINTERACTIVE task state bit to the cpu scheduler: It can be used by blocking points to mark the task's wait as "non-interactive". This does not mean the task will be considered a CPU-hog - the wait will simply not have an effect on the waiting task's priority - positive or negative alike (commit)
PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637. Used to implement VPN products (notably, Microsoft in all the Windows versions). Wikipedia article (commit)
DCCP: "Datagram Congestion Control Protocol". Datagram protocol (like UDP), but with a congestion control mechanism. (LWN article) Currently a RFC draft (commit)
Implement SKB fast cloning: Protocols that make extensive use of SKB cloning, for example TCP, eat at least 2 allocations per packet sent as a result. To
Hasn't the kernel pretty much reached the point where, for the average user, the only problems are those that just can't be fixed
A lot of things that the "average user" takes for granted are supported by features in the kernel that they didn't know even existed.
A lot of things that Linux *applications* need to do require kernel features that need to be implemented.
Take all the new search utilities (Beagle et al.) for example, they are depending on kernel features like "Inotify". If you read about Inotify you probably wouldn't give a damn, but you read about Beagle and then understand the point.
Same goes for other types of features, like more secure/reliable filesystems. Sure the average user "doesn't care", but he sure cares when that feature wasn't implemented and he ended up losing half his work to a crash.
Besides, one of the biggest complaints about Linux is that when a brand-new application comes along that requires a user to "patch and recompile the kernel", it's *too hard* for the average user. So be happy when these features become included by default.
Just a quick scan of pages, though, so I could be off on some of these.
Check out FuseFS, for example (see why it's cool). Or encfs (see O'Reilly article).
Linux is starting to go beyond emulating the Unixes of yore, to create a whole new world of computing.
Linus won't order it in since Andrew Morton (his right-hand man) has already indicated that it will go in. There are a few concerns raised by Christoph Hellwig (lkml's resident pitt-bull) that Andrew Morton has asked to be fixed before it goes into vanilla. Mostly these issues have only held up inclusion (a filesystem would normally have got merged with just those style issues) because of concerns that after inclusion the code would be abandoned and even cleanups being opposed by the original developers as allegedly happened with reiser3.
features and performance are *not* the top priorities in Linux, the top priority is maintainability. The rate at which features and performance improvements are added is a consequence of the maintainability, which must not be compromised for the sake of a slightly cool filesystem.