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"

But....

does it run Linux?

Inconcievable!

"Comprehensible"? I do not think that word means what you think it means.

Re:Inconcievable!

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

Obligatory question...

Any point in me upgrading the kernel from 2.6.14? My suspicion is for myself is "no" since everything still works as usual. Alright, maybe I'll just go download and compile it.

Re:Obligatory question...

It depends really.
Lately, the kernel has put lots of improvements for desktop frameworks.
For example, 2.6.15 put forth uevent for managing devices. Wich the latest udev needs.
Udev keeps being more and more powerful, and latest hal takes advantage of it, and DE like Gnome and KDE also take advantage of this.
For the desktop, power management (and suspend) is the reason to go 2.6.16.
Most distros still don't use these features, but I already do, and some tools already use even the 2.6.16 features (no kidding).
That means you don't have to go 2.6.16 now, but eventually, distro will have to install it if they want to upgrade their desktop features on Linux.
The kernel and all the Utopia framework that goes with it.

Udev is still moving fast, some distro are stuck at udev 036. We are already at udev 087 (unusable on anything below linux 2.6.15) !!

Cell

support for the Cell processor

I guess the PS3 HDD with Linux was true...

Re:Cell

Keep in mind that Sony is a Linux supporter. In the past, they've released Playstation dev kits that are based on the Linux Operating System. (requisite Wikipedia link [wikipedia.org]) I don't see any reason why they'd stop the program, especially if the professional devs were also finding the technology useful.

Re:Cell

I guess the PS3 HDD with Linux was true...
Not necessarily. AFAIK, IBM and friends have had Linux running on a cell for some time. And they plan on selling cell-based machines outside of the PS3. A quick google leads to this page : http://www-128.ibm.com/developerworks/power/librar y/pa-expert4/ [ibm.com]

Bugs

Well, I've been using it for a few minutes, but it seems that there are a few bugs, like whe8#@4!n;)NO CARRIER

cdrecord

Slightly OT, but have Linux and Schilling decided to let cdrecord work right when acting as an IDE device yet? Last I checked, it's still been broken since 2.6.8.

Re:cdrecord

The problem is that Schilling wants linux to behave exactly like Solaris' incomprehensable s,b,l format even though Linux has to support more devices and refuses to even read patches that make things easier for Linux users. It's at the point that if cdrecord accidentally supports something that doesn't look like the solaris way Schilling will add code to disable it.

Combine that with the fact that the DVD tools from Schilling are no longer open source and requires a License key [berlios.de] The project has been forked [arklinux.com].

If your having trouble with cdrecord I'd suggest using the alternate version [arklinux.com] instead.

Re:cdrecord

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

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:cdrecord

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:cdrecord

And on that subject, what's so inherently difficult about writing CD recording software? FreeBSD comes with an IDE burning tool, burncd [freebsd.org], that has worked perfectly every time I've used it. Is it harder to do the same under Linux, or does cdrecord include some advanced, hard-to-implement functionality that burncd skipped?

Re:cdrecord

As noted above, the cdrecord code has been forked. This forked version of the code is now called dvdrecord [arklinux.org]. They dropped Joerg's artificial bullshit errors about linux, enabled the dvd code, and fixed up the build to use standard tools.

I'm mixed up here

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:I'm mixed up here

I believe now it is 2.6.X where when X is odd it is development (includes adding new features) and X is even it is release.

No goddamit, NO! I find it really surprising that people STILL get this wrong! 2.6.15 is considered just as stable as 2.6.16 is. Hell, if you even bothered to read the summary of this discussion, you would see that they added several new features to this version!

The closest thing to a "developement-version" is the -mm-tree, where new stuff is tried out before being added to the Linus-tree. Then we have the STABLE-trees (like 2.6.15.2).

It used to be that odd-numbered kernels (2.x.y, where X is odd or even) were developement-kernel (like 2.3.0), while even-numbered kernels were stable ones (like 2.4.0). But that system is NOT used with the 2.6-series in any shape or form!

Re:I'm mixed up here

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.

mknodat, etc.

I don't understand the need for all these new calls. Why not make chdir thread-safe? Is there any reason not to have a per-thread working directory?

Slackware

When will 2.6 be the default kernel for Slackware?

All I want from the kernel ...

... is PF_KEY reliability!

My Linux-based VPN concentrators will thank you.

hows about

everyone get together and create 1 really good filesystem instead of 20 halfassed bugridden ones?

Re:hows about

Have you ever tried to hack someone else's filesystem code? It's no fun. Most of them are small-team efforts, and the code is so low-level they have to be - anything else kills performance, so it's at the stage where you need to be deeply into the filesystem before you can do anything with it.

I would go on about how reiser4's plugin system makes it much easier for people to contribute their own small parts to the filesystem and means we could have the best of everything if only the bloody kernel devs would accept it, but that's a rant for another day.

Re:hows about...FIXING it?

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.

Pardon my ignorance...

But just what in the hell is a 'High Resolution Timer'?

Re:Pardon my ignorance...

But just what in the hell is a 'High Resolution Timer'?

A "timer" is a software or hardware device that keeps track of how many time increments have passed. The "resolution" of the timer is how small the increments are. Thus a timer that tracks the number of milliseconds (1000 increments per second) wouldn't be of a particularly high resolution, a timer that tracks nanosecond increments (1,000,000 increments per second) would be.

The purpose of high resolution timers is to provide better performance through more accurate digital timing. Take a serial port as an example. At 9600 baud, the timer it uses will "tick" about 9,600 times per second. The computers on each side align with these ticks to know that there's new data on the line. Assuming that the electronics can handle it in a stable fashion, the speed of that connection can be increased by changing the timer used for the port. On many serial ports, this speed can be over 100,000 baud, or 100,000 ticks per second.

Modern USB ports can easily require timing in the nanosecond range to produce a high speed signal. Thus the need for high resolution timers capable of producing the necessary signal. Many other uses (such as video signal synchronization) exist.

Re:Pardon my ignorance...

Whoops. I can't count today. (Hey, it's a monday. :-P)

Nanosecond == 1E-9 == 1,000,000,000/sec
Microsecond == 1E-6 == 1,000,000/sec

Thanks for pointing that out. :)

Re:Pardon my ignorance...

Bah, hit submit too soon on my previous reply:

A high resolution timer is very useful when asking a question such as:

How far apart (in time) were these two 10 Gbps ethernet packets?

With the old, low resolution, timers, you got one of two answers typically: 0 ms or 1 ms. And when it said 1ms, it was actually probably closer to 0 ms, the clock just happened to roll over. The 'real' answer was probably 0.000000030 seconds, and that happened to be enough to make the clock trip into the next millisecond.

With a higher resolution timer, the above scenario might tell you that those 2 packets were 30 nanosecs apart.

This can be rather useful for assorted predictive algorithms, and pretty much any code that needs to measure the passage of time while operating in the greater than 1000 operations per second range.

Re:Pardon my ignorance...

I believe you have confused "timer" with "timestamp". All you need for your example is a high resolution time *stamp*. The kernel has had usec accurate timestamps for ages now, and each architecture generally has a way to get better than that (although it's not generically available across the whole kernel).

High resolutions timers are a different thing all together. They're what you would use if you had some code that you wanted to run 100usec from now, but you wanted to give up the cpu in the meantime.

Linus' new philosophy of development in main tree

I must say that I am not happy with the 2.6.x kernel development. It has given me problems on both my server/desktop (dual P3-866 VIA board) and my laptop (toshiba portege p3 750). There are too many new features being added that seem to break others on working hardware. I would prefer if only hardware compatibility and bug fixes stayed in the main kernel tree while development continued in the 2.7.x tree like it used to previously.

I would like to know other peoples experiences with upgrades on 2.6.x. BTW, I run the debian testing kernels and the hotplug to udev switch has given me problems as well.

Re:Linus' new philosophy of development in main tr

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!

Two Months, and Two Weeks!

Linux 2.6.16 has been released after two months and two weeks of development.

Goddamned I can't believe they made an entire kernel in two months and two weeks.

Thanks!

I'm just writing this to congratulate and thank the Linux developer community on yet another innovative release.

That's all there is to my post - nothing interesting to say, just express my gratitude. Mod me down if you wish.

Linux 3.0 ?

What would an upgrade to the Linux Kernel have to do in order to be ordained 3.0?
3.0 Looks better than 2.6.16.3.14159265eeee+ IMHO ;)

Reiser4 FS.

When it will be included at vanilla? Any idea?

Soft Cell

"support for the Cell processor"

What do I need to do to recompile my P4 OS and apps to run on my PS3? Or some other Cell box that doesn't lie beyond the Magic Gate?

NVIDIA drivers broken in 2.6.16

In order to install them you must use a patch here [suselinuxsupport.de], or they won't work.

~ Jim

SiS USB

Looks like a lot of general updates to the EHCI and USB BIOS interfacing, doesn't specifically mention SiS USB chipsets but I'll have to try this kernel in the hopes that my laptop USB ports will finally work, having been useless since kernel 2.4 and all bug reports falling on deaf ears.

Secure file permissions :)

Are the kernel source files permissions part of a new security policy? rwxrwxrwx!

Moving physical memory pages on NUMA systems?

I have a dual Opteron 265 (dual core) server running AMD64, which, so I understand, uses the NUMA architecture. I am no expert, but I understand that my 4GB RAM is split between the two processors on this architecture, at 2 GB each. Thus I have always wondered how exactly the OS can move tasks efficiently between processors if the memory for each task is so tied to a particular memory bank. For example, if you happen to have some tasks that are on one of the CPUs and they all suddenly start taking up more processor and more memory, was it possible previously for the kernel to move some of the tasks over to the other CPU, given the two separate memory banks?

Is this what the new kernel is addressing, or am I way out here? Anybody who knows about this stuff? Thanks in advance.

ATI installer

I have a laptop with an ATI mobility (X600) chipset. I've consistently had issues compiling the ATI-provided drivers in various 2.6.x kernels, but I've heard from many that it should compile cleanly under 2.6.16. I'll try to update this post when I know more, as the kernel is currently compiling as I write, and the driver will soon (hopefully) follow.

SATA NCQ

I can't wait for NCQ support [linux-ata.org]. Hopefully 2.6.17.

More syscalls

Great, that's just what Linux was lacking.

Dapper

should they delay ubuntu 6.04 (dapper) a couple of weeks more and try to squeeze in the 2.6.16? last i know dapper rides on 2.6.15.8 so it would probably be worth it if they stretched the release date a little bit more to bring out an Ubuntu on par with the coming SuSe and Red Hat releases (which are going to have 2.6.16).

Bugs

Let the bug hunt begin.

It is an joke... just smile...

Rico, bug hole, nuk'm.

Re:Great!

You have linux installed on your toilet? And you need to upgrade it the minute a new release is available? You really are l33t!

Re:Linux is dying

First of all WTF? second of all, even if you were right... who cares? I run Linux because it doesn't suck quite as much as everything else that actually supports my hardware (I'm currently toying with FreeBSD, but you have to admit that the hardware support moves a bit slower). I don't give a crap if major corporations like it, that's not my goal, why should we care? I just want something good, that I can modify and customize if necicary, and is policed by a large populatin of zealots so it's usable, free and stays that way. If people are too stupid to use it, that's their problem.