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"

Comments

Just after ATI...

[xafan]

Just after hell froze over and ATI released new video drivers for Linux specifically supporting 2.6.11, 2.6.12 gets released.

Let me start off the collective "ARRGGGHHH!"

Re:Just after ATI...

[mr_z_beeblebrox]

Just after hell froze over and ATI released new video drivers for Linux specifically supporting 2.6.11, 2.6.12 gets released.

As someone who specifically uses 2.4.x kernels due to certain support issues, I give you permission not to upgrade. Matter of fact to go further I give you this checklist to decide any and all software upgrades in the future:
Does your current software solve your needs?
Does the upgrade mess with something you care about?
Does the upgrade fix a vital security issue?
Are you a developer?
I would discuss the answers in an if.. then... else sort of way. But, if you can upgrade your kernel you should be able to figure it out. Oh, one more thing, if you do not know the answer to any of these questions, you shouldn't even think about upgrading. Do not run code simply because it has been written. Code is written to address needs, use the code that was wrtten for yours and be happy that there is code for other people to.

Re:Just after ATI...

[David Hume]

laziness is a good enough reason to do anything

I thought laziness was a good enough reason not to do anything....

Now, there's the right message

[NitsujTPU]

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

Nothing instills confidence in those who are not convinced that Linux is mature enough for their application like the messages: "I was too lazy to download these files to put together a changelog" and
"the changelog wasn't in our CMS."

Re:Now, there's the right message

[tvon]

I agree, that's just embarassing.

Re:Now, there's the right message

[NitsujTPU]

Whoooaaa buddy.

I'm a card-carrying member of the FSF, a Linux user, a supporter, and didn't mean to HURT anybody. I meant to make an obvservation, and hope that it perhaps HELPS somebody.

Re:Now, there's the right message

[Chiisu]

Sums up Linux perfectly

Re:Now, there's the right message

[Curtman]

Embarassing to who?

People who disagree with me are by definition crazy. (Until I change my mind, when they can suddenly become upstanding citizens. I'm flexible, and not black-and-white.)
- Linus Torvalds

There you have it.. Clearly he's in the right.

Re:Now, there's the right message

[TorKlingberg]

Still better than "We won't tell you what this 20 MB binary patch does, but install it anyway. Trust us."

Re:Now, there's the right message

[NitsujTPU]

Try telling that to a comporate entity. With the explanation in place (Linus' explanation as to why) it's fine, however, the blank statement would leave managers somewhat concerned.

Ironically, even ones who wouldn't have been concerned if it had never been mentioned at all.

Quite a few businesses put a greater value on the paper trail than the quality of the system.

Re:Now, there's the right message

[petermgreen]

using bitkeeper was only a mistake if viewed in a narrow light. if it wasn't for bitkeeper i suspect linux would still be struggling on with no version control at all.

afaict the basic story goes as follows.

linus fought off version control and in doing so painted himself into a corner.

bitkeeper came along and exploited that corner to get linus to use it.

linus was forciblly stopped from using bitkeeper and made a crude but workable version control system that suited his way of working based on his experiance using bitkeeper.

some people bend thier way of working arround the tools they have. others try to make or find tools that match thier way of working. Different approaches which suit different personalities but i wouldn't say either is wrong.

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

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

[Sheetrock]

When and why did they stop the system of releasing stable versions on the even minor releases (2.4.x, 2.6.x, etc.) and unstable/development versions on the odd minor releases (2.5.x, 2.7.x, etc.)?

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.

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

[The_Wilschon]

Yes, but one of Linux's strengths, and selling points, has traditionally been its stability. If we throw that out the window, then people will start drifting away to other systems, and then we'll have even *fewer* people using the buggy kernels. Calling buggy code "production" is a M$ tactic. And one of the reasons I moved away from that platform.

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

[slavemowgli]

Actually... the regular 2.6 kernels are pretty stable, or at least not more unstable than past stable kernel series like 2.4 were. This is especially true if you run the 2.6.x.y kernels (like 2.6.11.12, currently) instead of staying on the bleeding (mainline) edge by constantly upgrading to the latest -rc or even git snapshots.

I for one think that it's all a good idea: instead of backporting features (from devel to stable, or stable to old stable), we're simply back-porting bugfixes applied to mainline to a relatively short-lived stable off-shot so that people can get fixes without new features that also introduce new bugs. That should help stability.

Outside of that... well, yeah, I guess one could complain about the lack of proper regression testing, QA prior to releases, release schedules and all that. But the truth is that these things have not only hindered but actually *helped* a great deal when it comes to Linux development, so I don't see why they should be abolished. In the end, it's the developers that decide how things should work - and that's good, because it's the developers, not management (this includes everyone who's not involved with development), who know best.

That being said, the statement that distros don't roll their own kernels isn't true, anyway. Take Fedora, for example - if you read Dave Jones' blog, you'll notice that a lot of effort *is* going into stabilizing these and making them regression-free. How many distros do you know that ship with vanilla kernels? I know exactly one - Slackware. Every other (big) one uses patched kernels, no matter whether it's Debian, SuSE, RedHat, or whatever else there is.

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

[iabervon]

The problem was that starting an unstable series was exactly the kind of fork that causes problems with development. There was a substantial period when the functionality needed to run a system with recent software and on recent hardware was only in the unstable one of the official series, and was backported to the nominally stable series by each distro individually separately and to different degrees. Furthermore, there was constant pressure to add new features to the officially stable series, rather than to the unstable series (or backported from the unstable series).

The central problem was that series progressed from unstable to stable to obsolescent to non-functioning. The solution is to always have a place for unstable features (the -mm series) and a place for stable features (the mainline series), and features move into the stable series as they become stable, rather than requiring a major upheaval and years of fussing. Then there needs to be something that corresponds to the period where mistakes in a release are fixed in a release that doesn't include anything else, even new features which are extensively tested; this is only useful until there are no known regressions in the next version with added features.

The reason that the numbering changed is that, were the numbering maintained, the recent releases would now be 2.16.11, 2.18.0, and 2.19.0 (assuming that the new system was adopted at 2.6.6, the old numbering would make what was 2.6.7 into 2.8.0, and so forth, replacing one point release with two minors, which would just be silly). Also, it would be confusing if 2.17.x included stuff that wasn't in 2.18.0, was in 2.19.0, and was in 2.20.0; this is what happens to anything that's still in testing when a release is made and then stabilizes. Since there's always stuff in testing, no stable release could ever be made without having the existance of features be confusingly non-continguous.

In any case, 2.6.x.y is now about as stable as 2.4.x was during the period before distros started moving to 2.6.

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.

Priorities

[etymxris]

Sure, a full changelog would be nice. But Linus, I imagine, isn't too worried about appearing here isn't worth the effort. His time's better spent on actual kernel code.

This is the type of thing that happens when engineers manage projects rather than business people. That's not a criticism.

Re:Priorities

[Speare]

This is the type of thing that happens when engineers manage projects rather than business people.

Yeah, I hate it when engineers manage the business people.

Re:Linux+OpenSolaris

[Arker]

Does anyone think there will be anything benificial to linux to borrow from solaris now that the source is out, or does their license even allow this?

Short answer: No, and no.

Longer answer, while there are a few places Solaris still has an advantage, you can't just rip code out of one and stick it another. The structure of the code is quite different, so an implementation in one codebase just won't transfer to another cleanly.

And two, the CDDL, besides being horridly written, is clearly and intentionally not GPL compatible, so even if you could transplant code like that technically, it wouldn't work legally.

Making it stable...

[fprog]

They should really try to froze features,
at least subsystem by subsystem,
for a couple of months and perform
a deep code review (ala OpenBSD)
for bug hunting and security analysis.

I can understand that some part of the kernel
still needs heavy development
(ReiserFS, VM, some specific broken drivers),
but other parts should be revised
and certified gold bug free.

At least that would give us a roadmap,
on what is to be fixed before
they jump to 2.7.x series.

I mean what's the point to break stuff
at every .x release in a stable series,
that doesn't make any sense to me.

How are 3rd party drivers people, applications
are supposed to "trust" a 2.6 kernel,
if it break stuff continuously.

"You're Nvidia or ATI card works in 2.6.x but not in 2.6.x+2,
and VMware doesn't work in 2.6.y but only in 2.6.y+1"

As long as they keep breaking stuff,
I'm keeping my "stable" linux servers
on the 2.4.x series.

Re:Making it stable...

[njcoder]

Just make it easy
for us to read and do not
try and write haikus. :)

Re:Making it stable...

[jadavis]

I can understand that some part of the kernel
still needs heavy development
(ReiserFS, VM, ...

Speaking of VMs, I'm a little confused about the topic. Can anyone direct me to some good material that explains the differences between various VM systems? Specifically, I'm concerned about overcommitting memory and the OOM killer in linux. Do any other OSes have an OOM killer? Why or why not? If an OS overcommits memory, how can it not have an OOM killer? Does setting "vm.overcommit_memory = 2" disable the OOM killer, or just make it less likely?

Maybe?

[Saeed al-Sahaf]

Could this be part of the reason hardware manufacturers don't put a high priority for Linux drivers?

Re:Maybe?

[big_groo]

This is precisely why I choose Nvidia hardware - and I always will. Nvidia took the time to ensure that I can have accelerated graphics on my choice of OS, so I will reward them with my pocketbook. You should do the same.

Re:Maybe?

[flithm]

Could this be part of the reason hardware manufacturers don't put a high priority for Linux drivers?

No.

You don't need to release a new driver with every kernel release. ATI just has no idea what they're doing that's all.

A good example: When 2.6 first came out, the nvidia 2.4 kernel module could be made to compile with only minor modifications! I upgrade kernels with every release, and I've never had to go out and find a new driver release.

But to answer your question, the reason why most manufacturers don't put a high priority on Linux support is because the amount of effort it takes is simply not worth the trouble. Linux just doesn't have the install base.

On the other hand, if you're a cool company, and a lot of your engineers, devs, etc already use Linux, or *BSD then the effort it takes is much smaller, because they already know the system.

Ever compared the install between ATI and Nvidia. ATI's is a freakin' joke. It's horrible.

You know they basically took some of their people, forced them to slap something resemembling driver support together and released it on the public.

I agree with the grandparent post. Reward nvidia with your money. Quit your bitching, stop all the silly petitions to try to get ATI to release decent drivers. All that does is let them know they can do it and people will still buy them!

Re:Maybe?

[gnarlin]

Then perhaps you should take a look at this working free r300 driver 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.

Re:Maybe?

[smittyoneeach]

Absolutely. Let the market be the driver. Not the courts. Not some ideology.

Re:Maybe?

[nathanh]

I agree with the grandparent post. Reward nvidia with your money.

Reward nvidia for releasing *binary* drivers? Anybody with an interest in the long-term success of Linux should be *punishing* nvidia by NOT buying their hardware.

Reward the companies that produce open source drivers, or publish specs, or help the developers of open-source drivers. Don't reward companies who are destroying the core value of Linux.

Re:Maybe?

[flithm]

Open source isn't the be-all end all. Nvidia puts out a great product and a good driver to match. I fail to see how doing this "destroys the core value of Linux."

Without a proper nvidia driver, Linux would be basically useless for any real modern desktop use, as all we'd have is driver support comparable to say that of any of the other open sourced ones, SiS, via, intel, matrox, the open source nvidia, or ATI drivers. Which by the way all tremendously suck. Sure basic 2d operations are supported, but that's it.

nvidia is under no obligation to release the internals of their product, and why would they in such a competetive market!

Punishing nvidia for running a good, smart business, and support free and alternative operating systems with quality products is an absolutely ridiculous thing to say.

Before you spout your mouth off like that, I'd like to see you create and maintain the number one graphics card company in the world, then release the source code to your driver which would give your competitors a HUGE leg up on understanding the internals of your product.

Don't be such an idealistic ass. It's people like YOU that destroy the core value of Linux.

Re:Maybe?

[Frequanaut]

As if the market isn't an ideology.

Re:Maybe?

[nathanh]

Open source isn't the be-all end all.

With Linux, yes it is. If you don't care about open-source then use something else.

Don't be such an idealistic ass.

Idealism is not a dirty word. Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success. If you're too short-sighted to understand that then perhaps Linux is not for you.

Re:Maybe?

[flithm]

No No, you misunderstood what I said.

I didn't mean you have to change the driver itself. This would be impossible as it's a closed source binary only driver!

I just meant minor modifications to the system. And I was talking about a fringe case: the case where a whole new version of the kernel is released (not just a point release). If you think about this it speaks very well on nvidia's behalf.

Also, in their favor, they released a 2.6 version soon after the release of 2.6. (No modifications necessary).

My point, which you completely missed, was that you do NOT need to upgrade your driver every time a kernel point release is made, and I was talking about a very extreme case where nvidia really shone.

Re:Maybe?

[Nasarius]

Idealism is not a dirty word. Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success. If you're too short-sighted to understand that then perhaps Linux is not for you.

I agree. Unfortunately, the desktop video card market is largely binary (NVIDIA/ATI), and NVIDIA is clearly superior in their support for Linux. There are many theoretical and practical problems with binary drivers, but NVIDIA has gotten it mostly right. ATI's Linux drivers are awful, which is why I'll never buy their cards.

Re:Maybe?

[nathanh]

Nice way of skirting around the real issue.

With Linux, open source *is* the real issue.

Please tell me how having a closed source driver destroys the core value of linux.

The core value of Linux is that it is open source.

It's zealots like you that keep a lot of people from adopting Linux,

Good. Linux will be better off without them if the mere mention of "open source" is enough to scare them away.

Re:Maybe?

[Anonymous Coward]

Yeah, real big of nVidia to release closed, binary drivers that may or may not run on different configurations and most assuredly will not run on anything other than Linux/i386, and to make no mention whatsoever of hardware specifications or documentation. Really nice, how they've ensured that there will be no non-trivial open development of their drivers by providing a buggy, impractical, but "good enough" solution.

nVidia is ensuring that F/OSS graphics will continue to be criplled by establishing an inadequate and, in the long run, harmful status quo. Until some company comes along that releases specifications---not even drivers, just specifications---for its graphics cards, I will not spend a single penny on them. Closed drivers don't help me run Blender or play games under *BSD, or do much of anything at all on a non-i386 architecture, anywhere, so I'm not going to bother with them. Frankly, there's something to be said for the hardline, "we won't take it unless it's Free" approach that, e.g., the OpenBSD guys have taken.

Re:Maybe?

[Anonymous Coward]

This is a good point that gets brought up a lot but i don't think either side really understands. You see it all comes down to why you have and use a computer. If your computer is an expression of your beliefs (as yours appears to be) then you should not compromise those beliefs for anything and you should support the card that has the open driver support. However if your computer is used as a tool to get things done (as it appears the parent who uses nvidia drivers because they work) then you should use what gets the job done best.

The main thing to remember is to have an open mind and accept that people use their computers for different reasons than you and thus place their priorities in different areas. That's not a bad thing (even if it means they use Microsoft products).

Re:Maybe?

[Mornelithe]

The open source nvidia drivers are only good if you want a $600 video card to perform like a $10 video card. The ati drivers are better than that on old cards, but not much on the new ones.

If you want to play 3D games on Linux today, you need to use binary drivers. Another alternative is to use Windows for gaming, and Linux only for desktop applications. In that case, nvidia still has no incentive to release any specifications or open source drivers for Linux.

A third alternative is to forgo playing any 3D games at all, in which case ATI/nVidia lose perhaps 1% of their sales, and the user has to be unhappy. And ATI/nvidia still have no incentive to release open source drivers/specifications, so these people will be unhappy forever (or at least until way in the future when Linux has a large enough market share that a successful boycott can actually be established).

So, essentially, your position is that you should make significant sacrifices for no conceivable gain, whereas the people you're arguing against are suggesting that people reap the benefits of an almost completely open-source desktop in addition to being able to enjoy their games, by making a concession on a point that they have no hope of winning.

Does that sum things up pretty well?

Re:Maybe?

[drsquare]

In reply to "Open source isn't the be-all end all.":

>With Linux, yes it is. If you don't care about open-source then use something else.

What? I don't recall Linus Torvalds (the creator of Linux), saying that the whole point of Linux is to run entirely open source software. Perhaps you can find a quote, either from Torvalds or from the kernal copyright licence that says you're not supposed to use any non-open-source software on Linux.

The way I see it, Linux was created to be a decent Unix-alternative, the fact that it's open source is a bonus. Who are you to tell people what operating system to use because they don't follow your ideology. I could equally say that if you don't want binary-only Nvidia drivers then use another graphics card.

Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success.

What bigger picture is this? Are you saying that using your hardware is a 'fleeting fancy'? Where is the long-term success in having your hardware non-operative? Perhaps you think that Nvidia will open the source of their drivers if enough open-source zealots use 640x480 16 colours because they won't install the closed-source drivers.

If you're too short-sighted to understand that then perhaps Linux is not for you.

Repeat after me: (This also goes for the zealots who modded your hilariously close-minded rant to +4)

LINUX IS AN OPERATING SYSTEM, NOT A RELIGION. IT'S A MEANS TO AN END THAT MAKES YOUR WEB BROWSER AND EMAIL WORK, THE WORLD DOES NOT REVOLVE AROUND IT.

Poor Linus

[RickPartin]

Sorry about being off-topic but I've been thinking, since Linus is a normal guy and not some super human CEO, he must go through a "family tech support guy" hell that only exists in only our darkest of nightmares. I pity him.

borked

[Sparr0]

Yet another kernel release without fixed/rolledback highpoint RAID drivers :( Kernel Oopses and Panics abound and they insist on keeping the broken code merged in around 2.6.9. Well, there's always hope for 2.6.13!

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!

Switch to Linux

[Anonymous Coward]

We were negotiating with the Pentagon.
We had a blue screen of death.
That was the last straw.
When you're holding the moon for ransom, you value stability in an application.
Linux gives us the power we need to crush those who oppose us.
It's compatible with our orbiting brain lasers.
I've got a beowolf cluster of atomic supermen.
I have more friends now.
Genetically engineered cybergoats.
Henchmen with bad teeth.
Georgous fembots with a penchant for evil.
I mean Linux runs on anything.
I'm all about open source.
It's just changed my love life.
You have to uh.. config it.
Uh.. and then you have to write some shell scripts.
Update your RPMs.
You have to partition your drives... and patch your kernel.
Compile your binaries.
Check your version dependencies... probably do that once or twice.
It's just so easy and so simple, I don't see why most people don't run Linux.
Thank god they don't, because they'd all be super villans, wouldn't they?
Huh uh ha!
I'm Steve, and I'm a super villian.

Re:Switch to Linux

[einhverfr]

You have to uh.. config it.
Uh.. and then you have to write some shell scripts.
Update your RPMs.
You have to partition your drives... and patch your kernel.
Compile your binaries.
Check your version dependencies... probably do that once or twice.
It's just so easy and so simple, I don't see why most people don't run Linux.
Thank god they don't, because they'd all be super villans, wouldn't they?
Huh uh ha!
I'm Steve, and I'm a super villian.

So, Ballmer, What's up?

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.

Re:2.6.13

[stor]

You're not familiar with the Tao of Linux ;)

It sounds like a worse situation than it is: it can depend on your perspective. There are often patches that float around and never get integrated but usually there's a good reason for that (code quality sucks, minimal testing, breaks other stuff, not conforming to kernel coding style).

Speaking of Kernel Coding Style, are you claiming that this is unimportant? Do you understand the concept that once a piece of code makes it into Linux then it's supposed to be maintainable by a group of people? You realise that the original maintainer of a piece of code is free to walk away at any time, so if they've used their own funky style the code will be obfuscated and unmaintainable?

Have a look at the recent discussion wrt inotify! It's an important feature for the desktop IMNSHO but core maintainers are sticking their noses up at it. Is this a bad thing? If you are more interested in the functionality than you are in the opinion that it's "Just Not Right Yet(tm)" then maybe. I'm really keen to see it in but I'm sincerely appreciative that Christopher Hellwig criticises and vetos the work until it conforms to his idea of aesthetics and sanity. CH can be a hard-liner but people like him, Andrew Morton and Al Viro raise the bar and push for quality. This is inarguably A Good Thing.

Anyway, mistakes happen, patches get ignored, people crack the sads, life goes on. Problems occur in commercial software development too. It's not time to ring the alarm bells.

Cheers
Stor

human readable summary

[digitalderbs]

Changelogs are great, but does someone have a link to a list of major changes (short point list summary) from 2.6.11? I read the kerneltrap blurb, and that didn't satisfy me. thanks

Linus is our Family Tech Support Guy!

[Anonymous Coward]

he must go through a "family tech support guy" hell that only exists in only our darkest of nightmares

It seems today
that all we see
is Longhorn delayed
and OS X on PeeCees
but where's the free and open source
on which we used to rely?
Luckily there's our Family Tech Support Guy,
the guy who makes the kernel
that runs on all the hardware
we bought at Fry's.
He's
our
Family
Tech
Support
Guy!

Hmm. Sorry. I got carried away :).
Thanks Linus for all your hard work!

Re:Wow!

[frodo from middle ea]

Umm, wouldn't armageddon come first before Longhorn...and if armageddon does indeed come then we can safely say RMS taking a bath is not far away...

Re:You're Fired

[slavemowgli]

There is no release manager. A new kernel gets published when Linus decides it's time; in a way, that makes him the release manager, but it's not really managing as in "creating schedules, specifications, requirements, deadlines and all that". And I at least would rather see him do actual work instead of meeting arbitrary requirements imposed on him by the more marketing-oriented types.

That being said, Linus *has* given a reason why there's no full changelog this *one* time (it's reproduced right above in this very Slashdot discussion, for example); if anyone has issues with that, I assume they're more than welcome to create a full one and post that. If noone does... well, then the itch probably wasn't worth scratching after all.

So there. If it really matters to you, then go and create a full changelog. If it's not worth your time and effort, why do you complain that Linus feels the same way?

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.

Reiser4

[azdruid]

Well, I'm a bit disappointed that native Reiser4 support wasn't included in this release. It's one of the features I'm greatly looking forward to...and I'm too noobish to compile a Reiser4 kernel module myself.

Re:Wrong word

[nathanh]

Yes, because the word he should have used is Zealot.

He did use the word zealot. It's very amusing because apparently a lot of you think "zealot" is an insult. I'm not insulted by that word at all. I'm proud to be a zealot.

zealot (n): one who engages warmly in any cause, and pursues his object with earnestness and ardor

I pity all of you people who are so jaded with life that you can only express yourself with anger and cynicism. It's so... teenager. Try being a zealot. It's much more fun.

Be happy sitting on your little pedestol,

PS: the word you should have used is "pedestal". HTH. HAND.