Kernel 2.6.12 Released

Mad Merlin writes "Linux kernel 2.6.12 has been released! Kerneltrap has a brief summary on it. The changelog is only partial however: 'The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory. The file that says ChangeLog-2.6.12 only contains the stuff from -rc2 onward.' As always you can find the changelog and the source at kernel.org"

Re:Now, there's the right message

[Anonymous Coward]

"the changelog wasn't in our CMS."

Are you living under a rock or did you probably notice that the core linux developers switched their cms?

mod him down (-3 flamebait)

x86_64 ctl32 removed

[etymxris]

It's some compatibility thing that allows 32 bit apps to run on a 64-bit OS. Shouldn't be a problem for GPL drivers, but will break older proprietary drivers. I believe nvidia just updated their drivers to be compatible with 2.6.12. But VMWare still won't work, last I checked.

Re:One thing I'm a bit confused about...

[ArbitraryConstant]

Because development was going quickly and they didn't want to lose momentum. We're getting new features much sooner than we otherwise would have.

The downside is that 2.6 kernels are now a regression-fest that makes Windows look positively stable. They claim distros are able to stabalize their own kernels, which is a theory I have yet to see put into practice. The idea now is to find a kernel version that doesn't have any show-stopper regressions for your hardware.

Some explaination in the changelog...

[Whyte]

commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Author: Linus Torvalds
Date: Sat Apr 16 15:20:36 2005 -0700

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

2.6.13

[jd]

There was a discussion on LWN about what was going to happen in the 2.6.13 and 2.6.14 timeframe. Apparently, there is speculation Linus may merge in a lot of the more stable stuff from Andrew Morton's -mm patchset. If the updated RAID drivers are in that patchset, there is a good chance they will be in 2.6.13 or 2.6.14.

In the meantime, there are a lot of valuable, interesting and worthwhile projects that aren't in ANY of the patchsets at this point in time. I e-mailed a few of the maintainers about that, and it appears that they're aware of the problem but want general users to pressure the patch maintainers to publish patches on the kernel mailing list AND that said patches should conform to the kernel programming style.

So, again, if you want updated drivers for RAID, or additional features you know damn well exist and are out there, lobby the maintainers until they publish the stuff in a way the core kernel maintainers like.

There is simply far too much good stuff out there that is not being seen and not being used. It has got to the point where I will be reviving my own FOLK patch series, to start documenting the patches that live out on the fringes of kernelspace. If we want a better Linux, all we have to do is ask in a way that will be heard.

CPU-FREQ changes

[glMatrixMode]

Skimming through the changelogs (link in story), I found many interesting CPUFreq changes, like :

* New governor 'Conservative' based on 'ondemand', except that it increases cpu freq step-by-step, instead of switching directly to the highest freq. This should improve battery time and address latency problems on amd64 systems.
* Improved support for PPC32 and ARM
* Support for dual-core opterons

One Change I Like

[Borealid]

I don't know if anybody cares, but this update supposedly fixes usb-audio so that disconnecting a running sound card won't eliminate your keyboard. Those of you with SB Audigy 2 NX or Extigy cards should probably upgrade.

Re:Maybe?

[gnarlin]

Then perhaps you should take a look at this working free r300 driver [sf.net] It may not be fully stable yet (although is has worked smoothly for me for about a week) but people seem to have forgotten the fight for getting free software drivers for their graphics cards indstead if kissing the asses of nvidia and ati for not releasing any source code or much specs. I will always choose the card which has a free driver over any that don't. Even if the perfomance is not on par with the best.

Also worth mentioning is the open graphics project [duskglow.com].

Re:Now, there's the right message

[man_of_mr_e]

have you been living under a rock? Google "Linus Subversion" and it's the first link.

http://subversion.tigris.org/subversion-linus.html [tigris.org]