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."

Comments

Reiser4?

[Anonymous Cumshot]

Does anyone know if/when reiser4 will be included into the mainline kernel? I recall reading a kerneltrap interview a while back with Andrew Morton, in which he basically said "sure, why not?" to including it into the next release..

huh?

[bcrowell]

Wow, there's not a single thing on that list of features that I understand. Either these are names for things I wanted but didn't know the names for, or these are all things I don't need.

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 -- in other words, drivers for proprietary devices that haven't had their specs released by the manufacturers?

Centrino wireless drivers

[lord_rob the only on]

How does that differ from ipw2200 drivers ?

BTW, here's a coral link for the kernel changelog.

Great for klik and go applications

[Anonymous Coward]

Well, this new kernel is great news for the http://klik.atekon.de/ service which allows you to directly run the latest experimental linux applications or stable debian packages in a user account by just clicking a link to run and install without messing up your installation (just like selfcontained Apple appliction folders).

The mounting of file systems without root permisson means klik will become even easier to install on linux distributions. And it already runs on several distributions without configuaration.

Re:wow

[mp3phish]

Maybe with those centrino drivers we can get this thing running wireless in linux:
Centrino pumpkin pc

Re:Reiser4? -- victim of politics+human nature

[lubricated]

If it's anything like 3 was when it came into the kernel please leave it out. 3 was only let into the kernel because reiser bitched and bitched, but it was unstable and buggy. I have been much happier with ext3.

Re:Reiser4? -- victim of politics+human nature

[dubl-u]

and I'm not blaming Hans.

Reading that thread, I'm not sure why. ReiserFS may be the bees' knees, but that's no excuse for that kind of behavior. Kernel style is kernel style; if Reiser thinks they should change kernel style, that's a reasonable thing to discuss, but the fuck-you-my-code's-better-than-your-crappy-code routine sure isn't the way to go about it.

Plan 9 protocol and FUSE

[spitzak]

If these work, this is BIG news. IMHO these make Linux into a completely new operating system, not just a Unix clone. Everything a computer process can think about should be named in a single hierarchial namespace. Until now all operating systems except Plan9 have been bogged down by concepts that think that only blocks of bytes on a disk are eligable for this naming scheme.

Expect vast numbers of FUSE programs. In the future I expect *most* non-trivial programs to actually be FUSE programs.

Re:This is funny

[Anonymous Coward]

One of the problems is that there isn't a mod for "wrong". So if you encounter a post which is just obviously incorrect, how do you mod it? Overrated, troll, or flamebait are your only options..

modern wifi, finally...but more needed

[drwho]

This is great, now that HostAP and Centrino are in the kernel. We've needed this to be in the mainstream kernel for some time. But Atheros support is still missing, and it's just as important, if not more important, than either of those chipsets. Most people are aware of the MadWifi drivers with closed-source HAL (i.e. part of the driver is closed source), but there's also a project by OpenBSD to make a completely open source driver for the Atheros cards, called OpenHAL. It's been ported to linux: http://cvs.pdos.csail.mit.edu/cvs/roofnet/release/ openhal/ - but needs testing. Please work on it!

Re:File descriptor offsets?

[achurch]

Try this patch. It's worked fine for me for the last few years.

Final straw

[Anonymous Coward]

I think this release of the Linux kernel is the final straw for me using FreeBSD.

Their failure to implement a fully functional ext3 makes it impossible to find a decent FreeBSD hosting company that offers virtual file partition management via web interface. Even with upcoming Xen3, most providers will be using Linux hosts and the inability to mount/resize FreeBSD partition is just another barrier for making FreeBSD available customers.

This latest release of Linux kernel is just another example of how difficult it will be for other OS to catch up in terms of continuously improving performance and features.

Here I come Debian. A formerly loyal FreeBSD fan since 3.x that is reminded of how Amiga lost out by failing to do simple things.

Re:Final straw

[Malor]

The Linux kernel has many features, but it has them at the expense of stability. This new kernel did not drive the network card properly on my server, an Athlon 1900+ on an ASUS K7V333. It complained about stuck interrupts.

To get it to run, I had to remove the 'noacpi' line from the kernel boot parameters. This makes me very nervous, because I ADDED it to fix a problem with the software RAID code on this machine. I got occasional, mysterious "ACPI error" messages in the system log, with no other explanation whatsoever. Then my RAID started failing routinely. One particular drive always failed, so of course I thought it was the drive, and replaced it. The new drive immediately started failing in exactly the same way.

Only by adding in the noacpi line was I able to use the system reliably. Now that noacpi no longer works, I may be backed into a corner... I may end up having to switch to some other server software I can trust. The Linux team's refusal to maintain old code without adding new features, just waving their hands in their air and saying that the distros will make it right, doesn't work for me. I already switched my firewall over to OpenBSD because I was tired of the incessant patching, security hole after security hole. On a CF-based system, that's a pain in the ass to administer. I haven't had to touch OpenBSD since I installed it, months ago.

I like features, but first and foremost I use open source software because it doesn't break. At least, for a long time, it didn't. The 2.6 kernel has directly cost me a couple hundred bucks, has had an absolute horde of problems ever since it shipped, and just failed for me YET AGAIN.

You may be impressed by all the whizbang features, but more and more, Linux is falling into the exact same trap that Microsoft has... shipping features instead of a solid product.

Re:Reiser4? -- victim of politics+human nature

[uhoreg]

Reiser4 is very stable, except for the recent releases. The recent releases became unstable due to the changes requested by lkml, but I believe that it's getting back to its previous level of stability. (When you make large scale design changes like what was requested on lkml, you're bound to get some bugs.) But before those changes, Reiser4 was extremely stable. The developers stopped being able to find bugs, and users stopped being able to crash it. I've been running Reiser4 since last February, and several people have been running it for longer than that, and I've never had any problems with it. When the current users have stopped being able to crash it (and it's already been in the -mm tree for some time), it's time to put it into the mainline kernel, so that other users can start pounding on it.

Re:Notable Release

[nihilogos]

Kernels are not intended for the consumer

Everyone should try compiling their own kernel at least once. It's not hard, and is a great learning experience. And there is something satisfying about knowing that the kernel you're running was compiled specifically for your machine, with no extraneous fluff like "Ham Radio Support".

Just make sure you keep the old one safe.

Re:SMP AMD64s need this version

[PenGun]

If you are running any x86-64 with Nvidia cards this fixes several things. Quake 4 for one ;).

    PenGun
  Do What Now ??? ... Standards and Practices !

Re:Stability

[Slashcrunch]

So if 2.4.x doesn't float your boat, try something a little behind the leading edge such as 2.6.10

You haven't said the 2.6.14 kernel is unusable, you hint that it could be. You say that it _may_ be totally unstable, not that it is. What is the actual problem? You smell very troll-ish to me.

I'm more than happy with the pace of development and I can stick with an older release if I need to. History shows that if you wait a bit your hardware will be supported. Whats the problem here? Sounds like a lot of complaining over nothing to me.

your Linux problems

[r00t]

Let's start with "noacpi". This is a very bad thing to specify, as you've seen. Modern systems rely on ACPI. Many of us think that this is gross, because ACPI requires a byte-code interpreter in the kernel, but such is life as designed by some nameless Intel committee. Your BIOS settings should be all hot-plug, plug-and-play, ACPI, buzzword++. Linux works quite well with those settings. You're expected to have udev to manage /dev, the hotplug tools, etc. This is how modern hardware is intended to be used, and you'll get burned if you try to stick to the comfortable old ways of static configuration.

I presume your OpenBSD firewall is not on such modern hardware. Linux is the UNIX-like system that is most tolerant of this brave new world of hot-plug hardware.

As for your software RAID, you'll need to file a proper bug report. I have a guess though: your BIOS, via ACPI, is playing with power management settings or doing something related to suspend and resume. This scrambles the drive. Send BIOS settings info with your bug report to linux-kernel@vger.rutgers.edu please.

Re:Stability

[q.kontinuum]

But you did notice the new versioning system of the linux kernel lately, didn't you? From http://en.wikipedia.org/wiki/Linux_kernel#Versions

For illustration, let it be assumed that the version number is composed thus: A.B.C[.D]

A D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimate the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Bugfixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number).

So, if you want stability go for the 2.6.13.4, it contains all bugfixes since 2.6.0 release (dec. 03), and the newest features are released already for 2 months and therefore tested.

But I do agree that it looks like the older stables are not maintained very long, e.g. when I look at the changelog to the 2.6.12.[1..6], none of the patches is available for the 2.6.11, also I'm pretty sure some of the fixed bugs are there as well.

So basically, if I want the latest bugfixes, I also need to accept features which are only released for two months and therefore might be unstable. I think, it would be a very good idea to pick one stable release p.a. and maintain it a bit longer, e.g. the 2.6.11.