Slashdot Mirror
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.
the only problems are those that just can't be fixed -- in other words, drivers for proprietary devices
(note: I'm no expert on the linux kernel) Yes and no. Much of what is left to be done in linux kernel has to do with proprietary devices. However, these things are not in the category "cannot be fixed." In fact, OSS developers constantly reverse-engineer new devices and standards, and get them working properly. It is hard, but can be done. For instance, this release includes enhanced support for Centrino, which is a standard for wireless connectivity (in laptops, etc.). Just because companies do not release specs does not mean that the linux kernel cannot include support for them. It is very very hard, but somehow they manage to do it!
And in a broader sense, the kernel is never "done" because computer hardware and software is constantly evolving, and thus the kernel must constantly evolve to meet modern demands. Yes, a 10-year old kernel will probably run your web server just fine, but the newer kernel versions integrate much better with newer hardware technology.
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.
Sorry - this isn't the MPPE patches. This is support for PPTP packets being tracked through iptables. What I believe this will let you do is have multiple PCs behind a Linux firewall be able to use PPTP at the same time (prior to this PPTP through a Linux iptables firewall would work for only one PC at a time.)
In fact, OSS developers constantly reverse-engineer new devices and standards, and get them working properly. It is hard, but can be done. For instance, this release includes enhanced support for Centrino, which is a standard for wireless connectivity (in laptops, etc.).
Bad example, these drivers are officially supported by Intel. See, e.g. the project page.
Assorted stuff I do sometimes: Lemuria.org
If you're running an SMP AMD64, you need this version to avoid random segfaults. It turns out that 4-level page table support on all but very current AMDs tickles a processor bug. See this discussion on the kernel Bugzilla for more detail than you ever wanted to know.
Disinfect the GNU General Public Virus!
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.
The vfs already has modularity, and the vfs is *the* Linux filesystem where the filesystems are modules that implement separate storage backends but all the same semantics.
One problem with reiser4 (now addressed in the code proposed for inclusion at this time) was that it changed some of the defined semantics of the vfs. This bit won't go in until it is thoroughly discussed and user-space has subsequently been prepared for it (and deprecation of the old behaviour widely expected).
The problem with the modularity of reiser4 is that is implemented fully inside reiser4 instead of being designed as a modification of the vfs where reiser4 simply provides one storage backend. The reiser4 modules should have been put right up behind the vfs as a proof of concept for the first integration, where the new modularity features could be moved bit-by-bit into the vfs, where all filesystem are then just a storage backend and all could be easily made to support the transaction and query facilities expected.
Some of the style problems included things like generic datatypes being implemented in the reiser4 directory instead of as a general facility for the kernel as a whole. Most of these were fixed, I believe, but AFAIK the problem of the level at which the modularity is implemented, and the failure to distinguish between semantic/feature modules and storage backend is not a good design.
Grub does not overwrite sector 0, EVERY TIME ONE CHANGES THE CONFIG. An operation which can fail for a number of reasons. (In other words, everytime lilo is run.) Grub instead writes the sector once, then relies on a text (and other files) which live in another sector. Even if grub's configuration file is messed up, grub will still come up, and likely be able to boot your old/new kernel. (There are ways of screwing this up, but all but one I can think of would result in lilo also failing, without even coming up.)
There are a lot of other advantages, but they weren't the one the GP was referring to. Rewriting Sector 0 like lilo does is like playing Russian Roulette with a hundred (or more) chamber pistol with one bullet.