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."
word to GNAA
Keep in mind the new kernel development model, where anything outside of major architectural changes is permissable in the Y of W.X.Y releases, and there is now the stable W.X.Y.Z releases to provide stabilized security patched kernels for those who want a slower moving target.
--Brandon
Because of this troll.
lol.
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
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
Just because you don't understand the features, doesn't mean their not useful to someone.
Bran muffins and whiskey.
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.
it takes you 2 days to compile a kernel?
your computer most be from the stoneage then...
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.
Wow, there's not a single thing on that list of features that I understand.
Much of what is on that list is a bit esoteric, but I think you might be exagerating. If you don't know what these are, you don't deserve the title of ``geek'':
PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637 [ietf.org]. Used to implement VPN products (notably, Microsoft in all the Windows versions).
IPV6: Support several new sockopt / ancillary data in Advanced API (RFC3542)
FUSE: Allows to implement a fully functional filesystem in a userspace program
9P support: Linux port of the Plan9's 9P protocol
Suspend support for CIFS filesystem
HostAP: Adds support to work as "Wireless Access Point"
Driver for the IBM Hard Drive Active Protection System (HDAPS), an accelerometer found in most modern Thinkpads (LWN article)
Add Apple USB touchpad driver for the USB touchpad which can be found on post-February 2005 Apple Powerbooks
Largefile support for accounting: The accounting subsystem in the kernel can not correctly handle files larger than 2GB. This fixes it by adding the O_LARGEFILE flag
There is much miscommunication happening w.r.t. Reiser4 on LKML and elsewhere. Until that is cleared up, don't expect Reiser4 in the mainline anytime soon without some kind of fallout.
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.)
You've always been able to mount filesystems as a normal user if you set up your fstab correctly. You will never be able to do so without some sort of prior configuration because it's a massive security risk if any user can mount/unmount any FS.
FUSE has nothing to do with security or user permissions for mounting. FUSE allows filesystem drivers to be run in userspace (most likely still with root permissions) rather than forcing them to be compiled into the kernel or loaded as a kernel module. (Similar to binfmt_misc for "executables", where the kernel does not directly execute certain executable files, but can be told which userspace program it can call in order to execute it.)
retrorocket.o not found, launch anyway?
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
It's stable, it's been stable by Hans standards(i.e. officially released) for the last year. The filesystem is pretty darn fast, stable, very secure, and quite advance. The issue isn't about the stability, it's about the code. One of the major things is it doesn't conform to Kernel Code guidelines, so Linus is arguing that it is going to make it harder to maintain and manage by other developers. Another issue is Reiser4's plugin system, which in Han's vision becomes the base of all filseystems and changes are brought in through plugins, and the issue is that the plugins system breaks the design of how the kernel deals with filesystems, it basically repeats functionality that could be replicated in other ways.
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.
Odd numbers (like 2.5 and 2.7) are only used for experimental kernels. What you're really waiting for is a 2.8 kernel, and given the life of 2.6 I don't see 2.8 coming anytime soon.
I think reiser 4 should be delayed untill it's ready this time, instead of burning a bunch of users, like 3 did.
It has been statistically shown that helmets increase the risk of head injury.
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.
I'm pretty sure patent concerns are part of it.
Reiser3 is FAR from abandoned by Namesys. Anyone can post patches to it and get them in the kernel, Hans has no control over that, and it has been proven because SuSE developers have gotten patches in to the kernel against Hans wishes.
ReiserFS3 is "version 3" of the Reiser filesystem. Hans wants it to be deemed "stable" and free from new FEATURES, and only bug fixes be applied. Any new features he wants to put in the next version of ReiserFS, v4. Rarely do you see MAJOR features from Kernel v2.6 being backported to v2.4, there is reason for that, because with features comes bugs.
For some reason people consider this to be abandoning Reiser3. When it is quite the opposite.
Open Source Time and Attendance, Job Costing a
The centrino drivers need a firmware to run. This isn't the same as a closed source module because the firmware doesn't run on the CPU, it executes on the subprocessor of the card itself (and thus can't screw up the entire system AFAIK). //fatal
There are two main reasons to run GRUB. The first is because you can build new kernel start lines on the fly. LILO has to be hardcoded with kernel locations on disk. You can change the boot parameters, but you can't start random kernels. GRUB, on the other hand, understands enough of the filesystems on which it lives to allow you to boot arbitrary kernels on the fly.
The second reason (closely related) is that if, for some reason, the kernel files move around on disk (did you just restore from backup?), LILO blows up, and GRUB just works.
Either bootloader can be used safely to remember multiple different kernels for routine experimentation.
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.