A Flood of Stable Linux Kernels Released

Julie188 writes "Greg Kroah-Hartman has released five new stable Linux kernels, correcting minor errors of their predecessors and including improvements which are unlikely to generate new errors. As so often with kernel versions in the stable series, it remains undisclosed if the new versions contain changes which fix security vulnerabilities, although the number of changes and some of the descriptions of those changes certainly suggest that all the new versions contain security fixes."

Comments

unknown?

[Lord Ender]

Since when does the kernel team practice security-through-obscurity? It is essential to know when security fixes are available. Many organizations only patch stable systems if there is a security problem.

Re:unknown?

[Aboroth]

Since each kernel comes with a complete changelog, it is only "unknown" to people who aren't capable of reading it. It has always been the responsibility of those who build kernels to pay attention to this. I don't recall there ever being a special designation on the front page of kernel.org to designate kernels that fix security vulnerabilities. If you go through a vendor I'm sure they keep up on this or they are incompetent. If you patch your own kernels then you should pay attention to the changelogs. As always.

Yay for sensationalist writing.

Re:unknown?

[Enderandrew]

This has been the policy of the Linux kernel for ages.

They don't go out of their way to hide security fixes, but they don't advertise them either. All bugs are treated as bugs. You can read the lengthy changelog.

Linus doesn't believe in calling special attention to closed bugs, because it also alerts people that there are unpatched security holes in earlier versions. Some shops don't patch Linux boxes regularly.

Re:unknown?

[compro01]

Either the links weren't in TFA when the submitter posted this or they were too lazy to follow them.

there's a list of changes here.

Re:unknown?

[0racle]

Since Linus decided security holes and bugs are not any different then a bug that causes your screen to refresh a microsecond slower. They list everything as bug fixes and don't differentiate on the potential severity of the bug.

Re:unknown?

[Lord Ender]

Alerting people that there are unpatched security holes in earlier versions is exactly what he should be doing. Perhaps they don't prioritize vulnerabilities differently in their development process internally, but those of us who use their software certainly treat security problems differently! /. car analogy warning: would you rather buy a car from a company that treated a recall about the engine exploding and killing you the same way they treat a recall about the light in the trunk failing?

Re:unknown?

[adolf]

If you don't like the way things are announced, change it. There's absolutely nothing in the world to prevent you from condensing the kernel changelog into a list of security problems that have been fixed, and then publishing your findings in a concise and easy-to-digest form for others to consume.

Re:unknown?

[Enderandrew]

The car analogy fails.

You're suggesting a security bug guarantees a systemic failure, when really it just means there is a possibility (not even a probability) that you could be exploited under a very specific circumstance. And even then most kernel vulnerabilities should be protected by other means.

However, another bug might cause your partition to corrupt, your system to perform slower, or your system to crash.

One could contend all of those issues are closer to your engine exploding, and more severe than the security exploit.

Linus is doing nothing to stop others from reading the changelogs, or LKML and advertise which bugs fix security issues. He just doesn't believe in specifically advertising these things or else.

And in real life, most people either patch all the time, or don't really patch at all. You suggest that you need to decide whether or not to apply a patch based on security issues, but I'd wager every single kernel release fixes at least one security vulnerability, rendering the argument moot.

The information wouldn't really change anyone's behavior. In every single shop I've ever worked in, 99% of the Microsoft systems get patched every month, unless they can't be taken down due to lack of a maintenance window. The business doesn't decide each month whether or not to patch based on which security vulnerabilities were addressed, because every single month there are security vulnerabilities addressed.

Re:unknown?

[Lord Ender]

The mistake you are making is that you are forgetting that confidentiality is the most important property of many sorts of data. Availability and integrity are important, too, but companies routinely test to ensure their systems are reliable with a given system version.

Bugs with could allow sensitive data to be disclosed are fundamentally more important. Treating them the same is a disservice to customers.

Re:unknown?

[Enderandrew]

You're saying the potential for a kernel-level vulnerability (which hardly should matter because you should have other security methodologies in place) is more important that a bug which corrupts all your data, or breaks your system?

I have to disagree.

Now if you said a bug which GUARANTEES confidential data was trasmitted to others, I'd agree that is as critical as they come.

But that is not what we're talking about.

You're also skipping the second half of my last message. Most shops either never patch, or patch all the time, despite the fact that every kernel release fixes some security issues. You insist that shops would change their decisions if they knew about specific security exploits that are patched.

I disagree. Most shops will continue to operate as they always do.

Re:unknown?

[Anonymous Coward]

--
"I use a Mac because I'm just better than you are."

"Me too, but I quote myself in my message body, not my sig."

Re:unknown?

[geminidomino]

You're saying the potential for a kernel-level vulnerability (which hardly should matter because you should have other security methodologies in place) is more important that a bug which corrupts all your data, or breaks your system?

It depends on the role the machine is filling. Consider a financial or medical imaging server, which contains scanned copies of paper records. In cases like that, having the server crash and losing all of the (backed up) data is FAR preferable to said data being stolen.

Re:unknown?

[s.d.]

/. car analogy warning: would you rather buy a car from a company that treated a recall about the engine exploding and killing you the same way they treat a recall about the light in the trunk failing?

I don't think your analogy is right. Think of it more like the company that produces a car engine and doesn't necessarily make sure every person understands whether it's the engine spontaneously catching fire or the finish peeling. They say "this is the list of shit we fixed" and articulate everything they fixed and how they fixed it.

You bet your ass that Toyota will tell you if it's an exploding problem or a finish peeling problem. The distros, in every update, will tell you what bugs were patched, and their severity, as they should. Should it be up to the kernel team to notify every user, or the distros?

Some people can install their own engine in a car. Some people like to download their own kernels and install them; those people probably can read CHANGELOGs.

Re:unknown?

[kbielefe]

This is exactly what distributions do. Only people who really know what they're doing get their kernels directly from kernel.org. Even if you know what you're doing, it's still more convenient for most people to just get security updates from their distro.

A more apt analogy is a car manufacturer putting out a list of recalls, and your dealership giving you a personal call when the most serious recalls are needed.

Re:unknown?

[Just Some Guy]

Alerting people that there are unpatched security holes in earlier versions is exactly what he should be doing.

Do you follow the security notices of every package you have installed? I have 1,665 packages on my Ubuntu netbook. Each of those has a maintainer who's in charge of paying attention to that stuff for me and updating that package if something important comes along.

Same with the kernel itself: Linus tells the distro maintainers and the distro maintainers tell you.

Re:unknown?

[mysidia]

According to the slashdot article:

it remains undisclosed if the new versions contain changes which fix security vulnerabilities,

That would mean they are not published in the publicly viewable changelogs, as publishing in the changelog would be disclosure.

Re:unknown?

[mysidia]

Some shops don't patch Linux boxes regularly.

Because the non-advertisement of security issues allows them to have a false sense of security. If it were noted more prominently that a certain security bug were fixed in a certain version, those people who don't patch Linux boxes regularly would be more inclined to make an exception.

Security is important to these people, just like system integrity is.

It is irresponsible to not draw attention to bugs that allow easy intrusion, execution of arbitrary code, escalation of privilege, OR that put a system at significant risk for filesystem corruption.

Re:unknown?

[mysidia]

The Linux kernel developers don't make an operating system, they make a kernel. Downstream vendors do (Redhat, Ubuntu, Debian, etc), and the downstream vendors will keep track of changes to the upstream kernel, it is their responsibility to bring down security patches, build a fixed kernel, and deliver the fix to the end users.

If a design defect in a type of engine caused it to explode, wouldn't you expect the manufacturer of the cars to issue the recalls on products that use the effected type of engine?

If the manufacturer of the Xyz1234 engine issued a recall for a certain version of the engine, half the car owners would have no clue that the car they bought happened to come with an effected engine (because the car manufacturer chose to use it).

These days you get a kernel from a Linux distributor, and they are generally highly customized, even with changes, drivers, and fixes backported from newer kernel versions.

So each one can have its own set of security bugs and mitigating factors too, separate from the upstream code.

Re:unknown?

[darkpixel2k]

Some shops don't patch Linux boxes regularly.

Bah! I patch weekly. ...but I only reboot about once a decade.

Like Novel said: "For servers that only go down when you bring them down"...

Re:unknown?

[darkpixel2k]

would you rather buy a car from a company that treated a recall about the engine exploding and killing you the same way they treat a recall about the light in the trunk failing?

Yes. I like my Toyota, thank you very much.

Re:unknown?

[Anonymous Coward]

apt...har har

Re:unknown?

[Eil]

The releases made by kernel.org are intended for software distribution maintainers, developers, and the odd crazy DIYer. Not end users. If you get your operating system from Red Hat or Canonical, it's their job to tell you that there is a security issue and by the way here is the patch.

Re:unknown?

[atomic-penguin]

Here, let me fix TFA for you:

Greg Kroah-Hartman, released one new stable kernel today and made backport commits to four other "stable" long-life development trees. GKH went on to make a vague comment on folks using the 2.6.27 tree, needing to re-base to the current changes. Since nothing else new and exciting was going on, we thought we could merely speculate on our blog, and then post a sensationalist summary to Slashdot. Then we just had to sit back and watch the money roll in from the ad-revenue.

Seriously though, I'm not trying to troll because there seems to be confusion about what makes a kernel tree "stable" these days. The author of the article confirms this suspicion with speculative reporting on their blog. For long as I can remember, this version confusion has been a problem ever since the new numbering system has been in place. In the previous numbering system, there was no speculation or confusion necessary. All one had to ask themselves, is the minor number an odd number? If yes, this is a "development" kernel. If the minor number is even, then it must be a "stable" kernel.

I have a paid vendor to alert me what has changed, and they are a party which can be held accountable for breaches of trust and security. The CERT also has a responsibility to disclose breaches of trust and security. Nobody is being obscure, other than the blogger, and they do not have an informed opinion on the nature of the changes. That much is evident by their post. The comment by GKH was meant for vendors and kernel developers who follow the LKML. Unless the blogger in question has commit access to the kernel tree, they have neither the expertise, or implied responsibility, to speculate on the degree of impact from a seemingly harmless comment.

As for organizations who only patch for security bugs. I personally find it prudent to review what it is I am patching. Then make an informed decision, before taking action whether the patch be necessary, or unnecessary. If there happens to be a bluetooth bug fixed in the kernel, it tends not to be a pressing issue on a server. On the other hand, an Open-ISCSI bug fix or device-mapper-multipath bug fix tends to be more pressing on a server impacted by such a bug. There are other factors to consider of course, such as the impact of availability to the business when rebooting a server for a kernel update.

In most cases, a business critical database server shouldn't be running a kernel.org issued kernel. Production servers are the reason for the existence of Linux vendors and their backported and tested kernels. A pre-production webserver, or a desktop Linux system, is a completely different animal though. Out of nearly 100 systems I touch, the only one running a kernel directly from kernel.org is my laptop. I want to be both on the bleeding edge, and have a reasonably stable kernel, on my desktop. I tend to stick to the almost monthly 3 numbered (2.6.x) releases which have had a RC feature freeze, prior to their release. I'm not sure anyone else officially considers a 4 numbered (2.6.x.x) release a development tree. But what else would you call the "in-between" a major release?

Re:unknown?

[aiht]

Enderandrew arguing with Lord Ender?
What is this, an Orson Scott Card convention?

Re:unknown?

[cynyr]

so then read the change log.

Re:2010: Year of the Linux Desktop

[jim_v2000]

For a lot of people it is, for a lot people it isn't.

If this were Windows

[erroneus]

Okay HERE is what I will begin citing about what is wrong with the culture of Windows programming.

I am not going to claim that in every case, any given program compiled to run on Linux will not break because of a "fix" to the kernel, but I will say that it is very uncommon and very unusual for this to happen.

Thanks to the Windows source code leak years ago, we now know for certain that "bugward compatibility" is built into the Windows OS and its kernel. In case you can't guess what "bugward compatibility" is, it would be the support of programs that had been utilizing undocumented system calls utilizing system calls in unconventional ways to achieve their ends. DOS, and Windows by extension, programmers have been doing this since the beginning. It is such a problem now that when Microsoft wants to fix a problem in their OS, they also have to write code for "bugward compatibility" to prevent other software from breaking in the process.

This is a cultural problem to be sure. If DOS and Windows programmers routinely followed the rules (and I am sure most do, don't think I am painting ALL DOS/Windows programming with that brush) Microsoft wouldn't have to worry about issuing bug fixes so much so long as their API remains true to the documented specs. This is a pretty sharp contrast with Linux programming where such stunts as using the OS in unconventional was is at the very least severely frowned upon... and when a kernel update does break a program, the programs are expected to get updated and not the other way around which makes sense. Microsoft went down the wrong path long, long ago and has been paying for it ever since.

Re:If this were Windows

[The MAZZTer]

Microsoft has since the leak you described moved "bugward compatibility" into something called "shims". They are basically compatibility fixes that only affect specific applications, to ensure newly written apps won't run into the compatibility hacks. More info.

Re:If this were Windows

[Blakey Rat]

Congratulations on being completely off-topic, yet getting modded up.

Thanks to the Windows source code leak years ago, we now know for certain that "bugward compatibility" is built into the Windows OS and its kernel.

1) No matter how many times you type "bugward compatibility" it's not going to catch-on, ok? Your phrase coining is not working, give it up already.

2) That's all been moved into shims, so only the specific application that needs that specific bug is affected now. Every other application gets the default, documented version of the APIs.

Microsoft's shim technology pretty much addresses all of your complaints there.

Microsoft went down the wrong path long, long ago and has been paying for it ever since.

Microsoft (and all OS makers, to some extent) are between a rock and a hard place. Look, they can't do anything to prevent you, the developer, from writing horrible code, from relying on side-effects, from relying on specific internal data structures. Etc. So you, the developer, don't-- so you go all out and put all that shit in your Foobar application because, shit, it runs, right?

Then Microsoft releases a new version of the OS, and what happens? Your Foobar application crashes! And now we get to the end-user. Is the end-user going to think, "wow, Foobar crashes in Windows XP, but it didn't in Windows 2000-- they must be relying on undocumented internal data structures!"? No, the end-user is going to say, "wow, Windows XP sucks shit because it can't run Foobar."

See what happened there? Foobar's problem just became *Microsoft's* problem. And what makes it even worse, and going back to the culture issue you brought up, is that a lot of Windows programmers *side with the end-users on this one!!!*

Look how many developers on this site alone were bitching and moaning about UAC when Vista and Windows 7 added that in. Hey buddy: your program triggers UAC prompts *because it is buggy!!* The only thing that changed from XP to Vista, permissions-wise, is that Microsoft's attitude changed from "grin and bear it" to "let's give these developers a little hint that their apps are broken."

They were sitting here on this site bitching at Microsoft because Microsoft didn't silently fix as many of their errors for them anymore! Unbelievable.

OS X doesn't have this problem because of their hipster mentality where anything older than about 3-4 years doesn't have to work anymore, since the *cool* people have already moved on. Linux solves it by having virtually every user also be a developer.

But because of the Foobar problem above, it's in Microsoft's best interests to keep Windows running everything possible, even if it means adding shims. And that's what they do. And that's why they have such a huge market share.

Re:If this were Windows

[heffrey]

Yeah it really sucks that programs that run on one version of Windows keep on running on versions released far into the future. I really hate it when I can run my old programs. It just drives me mad. I wish the MS would make all my old programs break when they release new versions of Windows. Heck, I might just buy a Mac!!

Re:If this were Windows

[kiwix]

The main reason for this is that the vast majority of Windows programs are Closed Source, while the vast majority of Linux programs are Open Source. When a change in the kernel breaks an Open Source program, it's no big deal because any one can fix the program. With a closed Source program, you have to wait for the author to fix the program, assuming that he still cares about the program...

Re:If this were Windows

[shutdown -p now]

This is a pretty sharp contrast with Linux programming where such stunts as using the OS in unconventional was is at the very least severely frowned upon

I can assure you that using undocumented APIs, or relying on undocumented behavior and effects of public APIs, is very much frowned on by Microsoft developers as well. You only need to read Raymond Chen's blog to find that out...

Re:If this were Windows

[RocketRabbit]

I am running software written for OS X 10.0 on a PPC, on my Intel Mac under 10.6 and it works great. If I need to run software going back to the 80s I can, using an older Powerbook that still works great after 15 years, or a slightly newer Powerbook that replaced it 7 years later which of course runs OS X.

I know the fashion is to bash on Apple, but it was possible to run truly ancient code on a Mac until the burial of OS 9. OS X applications are compatible across platforms and backwards compatibility is perfect. There are some Windows 2000 applications that will not work properly with Windows 7, however apps written for OS X Beta which emerged about that time will still run on 10.6.

If you want to see some shitty backward compatibility, try running Tribes 2 for Linux on your modern Linux distro. They have obsoleted so many interfaces and drivers etc, that it can be impossible to run legacy software.

Re:If this were Windows

[shutdown -p now]

Accidental anon post, sorry. It was mine, of course.

Re:If this were Windows

[Zakabog]

Look how many developers on this site alone were bitching and moaning about UAC when Vista and Windows 7 added that in. Hey buddy: your program triggers UAC prompts *because it is buggy!!* The only thing that changed from XP to Vista, permissions-wise, is that Microsoft's attitude changed from "grin and bear it" to "let's give these developers a little hint that their apps are broken."

Yes, we all know a program is horribly broken when it wants to be installed somewhere crazy like in the %Program Files% directory...

UAC was a hacky way of defending against malware (it worked for a little while till malware writers found ways of going around it.) On Vista it's been nothing but a nuisance, I've never seen it actually stop anything unwanted from running though I have observed many users growing so used to the pop up that they disregard it without reading (since it pops up so frequently.) On Windows 7 it seems much more refined, only coming up when it's important rather than every time you try to run anything.

fixes are fully disclosed, stop fud'ing

[bl8n8r]

The disclosures aren't in a pretty clicky-clicky-box but the kernel devs *do* strive to maintain formats which cater to the major users:

for shell ninjas:
    wget www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33 -O - | less

for geezers/people with lawns:
    telnet ftp.kernel.org 21

for the lamer++:
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

Re:fixes are fully disclosed, stop fud'ing

[Anonymous Coward]

I'm a programmer by trade but this change log is absolutely useless to me. For example:

Revert the change made to arch/ia64/sn/kernel/setup.c by commit
        204fba4aa303ea4a7bb726a539bf4a5b9e3203d0 as it breaks the build.

        Fixing the build the b94b08081fcecf83fa690d6c5664f6316fe72208 way
        breaks xpc because genksyms then fails to generate an CRC for
        per_cpu____sn_cnodeid_to_nasid because of limitations in the
        generic genksyms code.

What the fuck does that even mean and how does it affect an average user? How am I supposed to know if this is a security problem or not? This resembles a commit log, not a change log.

Re:fixes are fully disclosed, stop fud'ing

[compro01]

If you don't know what that means, you're probably not a member of the 2% or so of users who manually upgrade their kernel and thus probably don't need to worry about it. These updates to your system will be handled by the maintainers of whatever distro you use.

Though to summarize that one, it's undoing a fix (the original issue caused the kernel not to build) to some initial setup code (find the terminal, initialize additional CPU cores, etc.) for the Itamium processor which would cause genksyms (GENerate Kernel SYMbolS, which generates symbol version (checksum of all the typedefs, structs, unions, etc. in the kernel down to their base types) information) not to work properly as it fails to generate the checksum for a particular variable in a struct.

Re:fixes are fully disclosed, stop fud'ing

[/dev/trash]

bash: telnet: command not found

Variety is the spice of life

[MonsterTrimble]

I understand that this means that the different linux kernel families all have updates released, but I don't understand why you need fixe or six concurrent kernel branches. Not to be a troll, I just don't know why. It seems like a lot of work for not a lot of return.

Re:Variety is the spice of life

[Anonymous Coward]

Because there just aren't enough rolling release distributions out there. Instead we have things like Ubuntu's LTS releases which hang on to kernels forever (2 years or so which is long enough for around 8 to 10 kernel release cycles).

Re:Variety is the spice of life

[Hatta]

Yeah, I don't get it. If there's a bug in kernel 2.6.27, why patch it to 2.6.27.48 instead of upgrading to 2.6.34?

Re:Variety is the spice of life

[mandelbr0t]

Because all the distro's packages were tested against kernel 2.6.27. Integration testing is a badly overlooked phase by many distros. However, I've seen that Debian-based stuff undergoes extensive integration testing, thus making a kernel version upgrade a huge testing process. Fixing the bug in the kernel version used by the distro saves a lot of testing time, and is much less likely to break distro-specific applications.

Re:Variety is the spice of life

[MikeyO]

This might have been a more reasonable thing to do when we had the "even numbered" series (2.0, 2.2, 2.4) for stable kernels and "odd numbered" (2.1, 2.3, 2.5) kernels for new features. But now 2.6 is where both stable kernels and new development is released from, So things you might have been relying on could drastically change from one stable release to the next. For example, the entire devfs subsystem was removed completely in kernel 2.6.13. If you had something that depended on the existence of devfs, you could not upgrade to 2.6.13 or later until you got rid of your dependance on devfs.

Re:Variety is the spice of life

[JesseMcDonald]

For example, the entire devfs subsystem was removed completely in kernel 2.6.13. If you had something that depended on the existence of devfs, you could not upgrade to 2.6.13 or later until you got rid of your dependance on devfs.

And if we were still using the old version number format, and devfs had been removed in 2.7.13 or 2.8.0 rather than 2.6.13, you still would not be able to upgrade to that version or later until you'd removed your requirement for devfs. Features would still tend to be introduced in the same order, after all—they'd just be even later in getting to actual users. You get the same effect by freezing your distribution at, say, 2.6.27, and backporting only security patches and bugfixes until you're ready for the next major release.

Re:Variety is the spice of life

[MikeyO]

And if we were still using the old version number format, and devfs had been removed in 2.7.13 or 2.8.0 rather than 2.6.13, you still would not be able to upgrade to that version or later until you'd removed your requirement for devfs.

Yes, but if the new features were going into 2.7.x instead of 2.6.x, you'd not need to worry as much about upgrading to 2.6.latest in order to get the latest bugfixes, as Hatta was asking about above.

Re:2010: Year of the Linux Desktop

[Eternauta3k]

Yup, this kernel fixed the task-switching problem that was keeping the general public from using linux as their main OS. Take that, Microsoft!

My first thought...

[IANAAC]

Reading the topic summary, my first thought was "how boring", and apparently I'm not alone, considering that the third reply in has really nothing to say on the subject other than "Linux is better than Windows".

What does Windows done wrong have to do with a flood of stable Linux kernels being released?

Re:2010: Year of the Linux Desktop

[Thud457]

People still use desktops?

oh, I get it, ees joke! BWAHAHAHAA ! Veery gud!

Oxymoron

[bradgoodman]

"Flood of Stable Kernels"

Last time we sent our customers a "flood of stable releases" we got an angry letter from them...something about Quality Control....

Re:2010: Year of the Linux Desktop

[Kjella]

At least on Internet-facing computers according to the hitslink numbers, Linux' market share is very stable at around 1%. Since February 2009 it's been in the range 0.94-1.17& with the last being 1.07%. However, the total PC market is still growing rapidly so in a way it's healthier than ever, at the last guesstimate there's an installed base of about 1.4 billion computers - that's 14 million Linux users.

It really depends on how you look at it, in relative figures it's still struggling. But if you believe that some fixed fraction of users decide to become developers, then in absolute numbers there are more developers than ever. I'll not pretend people don't have problems today, but I've fiddled with Linux long enough to know it has been much, much worse and survived and evolved past that. There's at least no reason to be grim about the future.

When I first dabbled with Linux, the ruling operating system was called Windows 98. Let me tell you, Win7 and OSX 10.6 are vastly different beasts, the competition has come a far way. But so has Linux, it's always stayed in the race. Sooner or later the race will slow down, the next OS version will look much like the last. When they do, Linux will catch up. That's the whole difference, the others have to be in front, they have to constantly find a way to be ahead. Linux can just copy the beaten path until it catches up.

Revision ids in the GIT repository...

[mengel]

Those big long hex numbers are revision id's in the GIT version control system used for the kernel. Perusing any instance of said repository (such as the one here will let you look at that commit, what files changed, what log messages were included, who made it, etc.

Re:Revision ids in the GIT repository...

[Anonymous Coward]

Fair enough but that still doesn't give me any idea of what was actually fixed from an end user perspective. I still don't know what configurations the fix might affect. I still don't know if it's a security issue.

Take this article from Microsoft for example:
http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx
It says in plain English which versions of the software will need the patch and how the flaw might be exploited. It even gives an estimate of how critical the vulnerability could be.

I think this is the kind of thing that the submitter is looking for when he says "it remains undisclosed if the new versions contain changes which fix security vulnerabilities".

Re:Revision ids in the GIT repository...

[Anonymous Coward]

If you want information digested in that way, maybe you should use get kernel updates from a Linux distribution, not from the kernel developers.

Re:Revision ids in the GIT repository...

[erikdalen]

And Linux distributions condense it into similar formats:
http://www.debian.org/security/2010/dsa-2012

Re:Who cares?

[Flossymike]

Well I like Monkey Island :-)

Re:Who cares?

[Anonymous Coward]

I'm glad to hear you attended your family reunion.

Kernelnewbies

[JonJ]

Always has a nice human readable summary of the changes.

Re:2010: Year of the Linux Desktop

[Snowbat]

Hitslink numbers for Linux are suspiciously low.
Wikimedia: 1.8%
W3Counter: 2.78%
W3Schools: 4.5%

Re:analogy () returns FAIL

[mysidia]

Right... you mean Ford builds many of their engines.. there are exceptions

Would you expect Yamaha to be the company to issue the recall for Ford Taurus SHO V-8's, if a defect of some sort were ever found with the SHO V8 engine?

Re:Who cares?

[LingNoi]

It'll never be ready for your desktop. For me, I already use it every day and although there is stuff that pisses me off it meets my needs fine.

Re:2010: Year of the Linux Desktop

[Cwix]

Yay.. looks like its the year of the XP.. still...

Re:Here's a question

[aiht]

How long will it take to move to 2.8?

Probably forever. This reflects changes in the development methodology followed by the kernel team(s).

It seems to have been a very long time now that the kernel has been in 2.6-land and people make a big deal about changes in that third group of digits. Is significant progress really being made?

Yes, it is. The amount of work done is not dependent on changes to the major version number.
There has probably been more progress between 2.6.0 and 2.6.34 than there was between 2.2 and 2.4, or 2.4 and 2.6.0.

Re:analogy () returns FAIL

[nschubach]

Mazda also co-designed and makes some engines for Ford.

Re:2010: Year of the Linux Desktop

[pandrijeczko]

It's impossible to say because "desktop" means different things to different people.

I've been using Linux for about 15 years now, UNIX for about 20 and Windows since 3.11.

In all honesty, the point at which Linux did everything I need a desktop to do was about 18 months ago when I changed away from a Windows-based mobile phone to one based on Android - at that point, I didn't need Outlook or ActivSync to sync to my mobile phone any more and could get rid of Windows.

I do write a lot of documents and presentations but I don't need VisualBasic or MS Office macros, so OpenOffice does me.

I do take photos and edit them but I wouldn't know how to begin using Adobe Photoshop, GIMP & Picasa do all the photo editing I need to do.

I do some programming in Bash and PERL, if I need to mess about with any files on a Windows machine then I generally mount a Windows share onto the Linux file system and run scripts from there.

I do play some games and is the sole reason I keep a Windows XP installation around - but, quite frankly, these days I'm only interested in releases from Valve or Stardock, or any new Fallout games as new releases, otherwise I replay old titles with updated game engines and mods (Duke Nukem 3D, the Quakes, the Unreal Tournaments, etc.) and any of those that don't now have native Linux ports do run well in WINE.

Yes, I know some people like to do advanced graphics or video editing, in which case the tools they can get for Windows are probably more suitable than those in Linux - but I think for most people, Linux would work perfectly well as a desktop replacement if they gave themselves a little time to get accustomed to it.

Time to drop 2?

[AnuradhaRatnaweera]

Wonder if it is time for Linux to drop 2. prefix, like with Java.

Re:Who cares?

[mcgrew]

It's been on many people's desktops for years, troll. If almost every computer made didn't come with Windows, Linux would be the dominant OS. As it is, only people who understand computers use it. I've installed Linux on computer noobs' PCs, and all of them like it better than Windows.