Linux 2.6.16 released

diegocgteleline.es writes "Linux 2.6.16 has been released after two months and two weeks of development. You can check the comprehensible changelog (text mirror of the site). The new features include OCFS2, a clustering filesystem contributed by Oracle, new unshare(), pselect()/ppoll() and *at() system calls, support the moving of the physical location of pages between nodes in NUMA systems, support for the Cell processor, cpufreq support for G5s plus thermal control for dualcore G5s, improved power management support for many devices and subsystems (libata, alsa...), a new mutex locking primitive, high-resolution timers, per-mountpoint noatime/nodiratime, 64-to-32-bit ioctl compatibility for the v4l2 subsystem, IPv6 support for DCCP, the TIPC protocol (Transparent Inter Process Communication, ACL support for CIFS filesystem, HFSX filesystem support, new configfs filesystem (which complements sysfs, not replaces it), support for running executables from v9fs (plan9 9P distributed filesystem), support for many new devices, improved support for others and lots of other changes. Check it out from kernel.org"

Re:Inconcievable!

[slavemowgli]

It's definitely much more comprehensible than the automatically-generated changelog, at least.

I'm mixed up here

[Adult film producer]

I thought the 2.6.x series of kernels was stable ? Shouldn't all of these new features being showing up in 2.7.... ?

Re:Linus' new philosophy of development in main tr

[10Ghz]

Well, you basically have two options:

- Use the STABLE-tree (2.6.15.2 for example)
- Use a vendor-kernel. Vendor-kernels are the ones that are considered stable these days.

As for me.... I haven't had any issues with the kernels. But I use vendor-kernels mostly, not vanilla-kernels.

Re:cdrecord

[Mr. Underbridge]

He wants something consistent, is all. Remember how towards the end of the 2.4 lifespan linux people were saying "ide-scsi is obsolete, move to the new ATAPI: method"? And then in a few months that was old and deprecated and it was all "move to the ATA: method"? And then it was changed around again around 2.6.9 for no discernible reason at all?

I'm reminded of an Emerson quote, "Foolish consistencies are the hobgoblin of small minds." In this case, Schilling wants something that 1) is consistently *bad*, and 2) in general makes life difficult for anyone *not* using a SCSI drive, which 3) is 90%+ of the population. An "elegant" solution that doesn't work isn't a solution.

The sooner people stop their hero-worship of Linus, stop the persecution of Schilling, and start looking at the facts, the sooner something can be done.

I think "persecution" is a tad much, and if there are any ill feelings Schilling has earned them.

Re:cdrecord

[m50d]

In this case, Schilling wants something that 1) is consistently *bad*, and 2) in general makes life difficult for anyone *not* using a SCSI drive, which 3) is 90%+ of the population. An "elegant" solution that doesn't work isn't a solution.

It worked. Under 2.4.20 my cd burner worked flawlessly. In fact, it still doesn't perform as well as it did then (since I can't have cdrecord setuid root now, I have to burn a bit slower so I don't get buffer underruns). It was fine from the hardware perspective - any atapi drive worked, any scsi drive worked, the clunky 2x parallel port drive I was able to dig out worked. It was fine from the application's perspective - atapi drives support the scsi commandset, so all you had to do is send scsi commands, much like how you send ip packets and don't care what kind of networking hardware is underneath. The only people who didn't like it were kernel people who seemed to have some grudge against ide-scsi - though the only real criticism I've ever seen offered was that it was "ugly". The people going for an elegant solution that doesn't work are the kernel devs.

Re:I'm mixed up here

[Your Anus]

While the 2.6.X has no meaning regarding stability, there is a "stable" release series, 2.6.X.Y, that runs in between each 2.6.X.

Once a 2.6.X kernel is released, another team tracks patches for critical and security issues. It then releases patches on top of 2.6.X, starting with 2.6.X.1. The stable series for 2.6.X usually ends when 2.6.X+1 is released, although I hear that the stable team now tracks 2.6.X until 2.6.X+3 is released.

For 2.6.16 in particular, one of the kernel developers says that he will track 2.6.16 for the long term once the stab;e team stops tracking it. Linus also mentioned that the 2.6.16 release is very similar to the patched-up kernels RedHat and SuSe ship right now, so it is a good base for distributions to build their own kernels.

Re:But....

[CarpetShark]

VMWare isn't required. Linux can run Linux :)

Re:hows about...FIXING it?

[Anonymous Coward]

if only the bloody kernel devs would accept it

The kernel devs actually accept it, as long as the bloody reiser devs fixes the obvious defiencies the code has. It has been more than one? two? years since reiser 4 "was ready to be merged" according to hans reiser and the haven't even tried to submit it in the 2.6.16 time frame - a sign that there is not a lot of work to do, for sure (they last time reiser tried it people pointed out him a list of things that haven't been fixed - yeah, reiser sure "was ready to be merged").

Maybe we should accept low-quality code in linux just because it's...reiser and it's c00l? Hey, that's the Microsoft Way, and it works for them! Apparently some people thinks that just because reiser 4 has plugins and plugins sound cool it mean it has zero bugs and all the design mistakes are magically fixed by some sort of magic.

  Are you aware that lots of "cool features" were rejected in the past in linux?. Being able to use 1 GB of memory, 64-bit processors, SMP, rmap-based memory management: Those features that sound "natural" today were rejected by Linus because the implementation was HORRIBLE and they weren't merged until someone implemented them in a cleaner way. Why reiser should be different? Linux developers are not going to allow people to fuck up everything because something is "great". It has taken a lot of hard work to take linux where it's now and make it work in 512-cpu SGI beasts, lowering the bar is not going to make linux any better.

New philosophies == new horizons

[CarpetShark]

I agree, it's less stable. However, you're free to use your distro's more stable tested and patched kernels (assuming your distro maintains its packages like Debian does). Unless you're deliberately running the latest and greatest GNU/Linux desktop, or trialling new hardware setups, then you should certainly be doing that.

What the new 2.6 development model gets us though, is much faster turnaround between kernel developers and kernel users. I think in the end, this will give us more features and a generally better kernel, without too much sacrifice.

Sadly, I think DRM is coming to Linux soon, so I'll probably have to jump ship to Debian GNU/Hurd or Debian GNU/kFreeBSD before Linux efforts bear much (non-DRM) fruit.

Re:cdrecord

[Overly Critical Guy]

It was forked before (dvdrtools), and will doubtless be forked again. The forks will die out once the maintainers realise that it's not Schilling being awkward, it's the kernel people. Last I knew, the fork you mention was depending on ide-scsi, which had a witch hunt against it towards the end of 2.4, was declared obsolete a few times as the latest poorly-thought-out replacement arose, and when this didn't get people to abandon it, was intentionally crippled around 2.6.9 or 2.6.10 time. Whoops. CD writing on linux is bloody hard - the only other project which has lasted any amount of time is cdrdao, and that uses Schilling's libscg for drive access. The sooner people stop their hero-worship of Linus, stop the persecution of Schilling, and start looking at the facts, the sooner something can be done.

All this crap is why I stick with the BSDs. They actually act professional and make it a point to retain common sense and stability in their operating systems. I've watched Linux over the years become something like a spiraling rocket that looks a little out of control.

Re:I'm mixed up here

[anothy]

people get it wrong because the Linux community spent a really long time yelling very loudly that the old model was so simple to understand, and getting really frustrated when people got it wrong. they worked for years to get people to understand the old model (to the extent that people ever really did; x.y.z... which one's significant here again?). it shouldn't be surprising at all that people "still" get this wrong - after all, if there's still multiple trees under active development (2.4.33-pre2 hit a month ago tomorrow), shouldn't one expect to have some sort of standard rule for what goes where, or what to look for where? tracking changes to the linux development model isn't particularly high up on the list of most people's priorities, and, despite whatever you seem to think, such changes aren't, in anything resembling absolute terms, high-profile items. it's also not mentioned on the kernel.org front page, which is, i believe, still the official repository for kernel versions.

or, more simply: yelling "we have these arbitrary rules we made up, that are totally different from our old arbitrary rules; why is everyone stuck on the old arbitrary rules we spent years yelling at them about?" over and over makes you look like a foolish git.

Re:Linus' new philosophy of development in main tr

[archen]

I'd say I'm an open source advocate, but the Linux kernel hasn't made me very happy with the quality of Linux. When someone says "So is Linux more stable than windows?" I have to answer with they're about the same.

In my opinion its coming down to version-o-phobia. Everyone is so scared to incrament a version number that they pushed the problem farther down the number set. I've become really impressed with the quality of FreeBSD releases, which dropped the ball initally in the beginning of 5x, and now have gotten into a more steady release schedule - that also means increasing version numbers. On Linux we arbitrarily screw with the current version and dump the problem of stablizing them on the distros. What in the hell sort of solution is that? Linux needs to get back to developing far away from the stable tree. Linux needs to start with a real testing/release cycle on a regular basis. You don't need to break compatability when you increase version numbers. As Linux has developed into a stable non-hobbiest OS, it needs to step up to the plate and stablize itself. Using the stable version (2.6.x.x.x) or whatever isn't really fooling anyone. No distro is going to maintain ALL kernel versions, sooner or later you have to bite the bullet and upgrade and accept all the new garbage that has introduced bugs in THIS version of the kernel.

And it's sort of funny that everyone shuns the BSDs because they are some sort of "leet" club, yet the reason for the messed up situation is because the finall word must always come from Linus. And this time Linus is wrong. Get the hell out of the stable branch!

Re:Linus' new philosophy of development in main tr

[tayhimself]

Agreed. I had a hunch that I wasnt alone with these problems. People upthread and you have described exactly the problems I have with various versions of 2.6 breaking different things. 2.2 and 2.4 kernel releases didnt scare me but 2.6 ones do.