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?

[Anonymous Coward]

Hm... Sounds like we need some angry young blackhats to release exploits for these vulnerabilities before the kernel devs have a change to patch them and hide their patch through obscurity. Wouldn't that be hilarious?

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?

[Anonymous Coward]

This is more the case of the engine manufacturer telling Ford their engine has these issues that possibly cause these problems. Ford goes over these and either issues alerts or recalls or nothing. Unless you're specifically getting the engine directly and building it yourself, in which case, you have to look at all the parts that have changed and determine these issues yourself.

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?

[Anonymous Coward]

any broad definition of "security" doesn't really wash, In the car example it's like the trunk light failing vrs the headlights & brake lights at the same time at highway speeds - it is all "lighting" though.

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?

[Anonymous Coward]

Was slashdot, or should I say $la$hdot, bought by Microsoft recently?

Re:unknown?

[Anonymous Coward]

BadAnalogyGuy, is that you?

Re:unknown?

[Anonymous Coward]

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

Parent is right. There is a private Linux kernel security mailing list, and patches may be obfuscated: mislabelled, ambiguously labelled, simply downplayed, or multiple patches.

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?

[Anonymous Coward]

Let me translate that to you.

I can't be bothered to maintain a list of security bugs. Not that you should trust my list anyways because I have no knowledge about projects that actually do the right thing because they believe it is the right thing to do and not for convenience.

Fixing bugs regardless of "alleged" exploitability is what OpenBSD does every day. The only time I hear about "only a DoS" or "not exploitable" is when reading about Linux kernel and userland patches that the distributors choose not to include.

If Linus wanted to speak about monkeys he should have pointed his fat finger to the people making operating systems out of his kernel.

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?

[Anonymous Coward]

Stable linux kernel == Secure Microsoft Windows-3.1 Give up on toy operating systems (linux.windows) and try a real OS

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.

And nothing of value was lost

[Anonymous Coward]

see topic

2010: Year of the Linux Desktop

[MrEricSir]

Are we there yet?

Re:2010: Year of the Linux Desktop

[Anonymous Coward]

Have we ever been there as has been predicted many times before?

Re:2010: Year of the Linux Desktop

[jim_v2000]

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

Re:2010: Year of the Linux Desktop

[Anonymous Coward]

That year was 1996 here, if it hasn't happened where you are, you must be seriously behind the times. Having fun with your Windows 3.11?

Re:2010: Year of the Linux Desktop

[Anonymous Coward]

wikipedia has the answer as usual: http://en.wikipedia.org/wiki/File:Operating_system_usage_share.svg

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!

Re:2010: Year of the Linux Desktop

[Thud457]

People still use desktops?

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

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.

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:2010: Year of the Linux Desktop

[Cwix]

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

Re:2010: Year of the Linux Desktop

[Anonymous Coward]

given that a system that ought to have reached stability like xp has issue in installing an hp3940 while linux recognizes and correctly install it like it installed all the other network lasers and epson all in one, i think the year of the linux desktop will come before the window desktop's one.

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.

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

[Anonymous Coward]

Surprise, I disagree. You're looking at it from ease with which a programmer has to deal with change. From a business perspective it costs less to let Microsoft spend the money on "bugward" (shims) then to have all their customers fix their applications. The cost of doing so is then divided over the entire customer base. This lowers the TCO for companies because its not the price of the OS that matters, is the cost in labor for developers. Therefore Microsoft is very smart to keep doing "bugward" fixes.

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

[Anonymous Coward]

You're ghey. Ghey ghey ghey. Late for your ass-gyno exam, faggot?

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

[Anonymous Coward]

Are you talking about the Linux ABI? Kernel bugs have temporarily broken some ioctls in the past especially in terms of 64-bit kernel 32-bit backwards compatibility but if everything is statically linked you can still run just about any linux binary written 15 years ago complete with 2GB file size limits because enough kernel folks cared enough not to break the ABI.

I disagree with the sentiment backwards compatibility (bug for bug) is an inherent impedement to forward progress of an operating environment. You just need to design your system in a way that accounts for the issue and move on. Its no different than making the argument internationalization leads itself to unecessary code/data bloat when there is no inherit reason why it should. It certainly doesn't seem that way to people who don't speak english.

Some linux/unix decisions I find extremely distasteful like refusal to address the time_t 2038 issue in 32-bit binaries.

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

[Anonymous Coward]

This sounds very nice until one remembers that your own applications often use undocumented APIs. It's not like Linux stands in a higher ground though. Linux applications often use undocumented or Linux/GNU-specific extensions to C, Posix and X.

By the way my reply to you in the "hip devs" story seems to have been lost in the ether, so instead of a well-thought post I will just say that I hate Microsoft for introducing the bastard and retarded C++-friendly function strncpy_s(which is not a real strncpy+_s) to the C standard instead of just strlcpy or even strlcpy and strlcpy_s for C++ loonies.

Re:If this were Windows

[Anonymous Coward]

This sounds very nice until one remembers that your own applications often use undocumented APIs.

I can tell you that a use of an undocumented or otherwise non-public API from Windows, at least in product teams I'm familiar with, would be a rather serious offense - both for reasons of correctness and maintainability ("undocumented" means "can break in any future release", really, which means that even any WU hotfix can potentially break your code), and - in fact, probably first and foremost - due to associated legal issues. Any attempt would likely be shot down very quickly during code review.

Furthermore, if you're talking with people from e.g. Windows asking questions like "how to do this", the first thing they ask is if you're also working on Windows or not; if you're writing any other product, you're not entitled to the use of any of Windows internal libraries and such, and that will be plainly stated. Even if using some non-public API, or hack relying on internal knowledge, can achieve what you want in a much, much easier way, you have to jump through the same hoops as everyone else out there.

(no-one wants to be that guy responsible for another $X billion fine from, say, EU)

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.

Re:If this were Windows

[Anonymous Coward]

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

UAC doesn't pop up just because a program is installed & running under Program Files, but it will if the app tries to write to files there (or write to HKLM, or write to System32, and so on). MS has told us where writable files should be put (not under Program Files) since at least Windows 2000, and most of their recommendations for file storage locations have been reasonable. Assuming you're a programmer, in software development terms you've had fucking forever to fix your programs. If you're not a dev and just need to use badly written closed source abandonware, Vista is usually capable of running those apps without too much inconvenience to the end user, and 7 is even less annoying.

- T

Re:If this were Windows

[Anonymous Coward]

It wouldn't surprise me if all of that is true today, but MS did have a history of using undocumented DOS and Windows APIs in its own products. If you can find a copy of Undocumented Windows by Andrew Schulman, it's worth a read. I suspect MS has changed its tune only because the risks (e.g. "another $X billion fine") now outweigh the competitive advantages.

- T

Re:If this were Windows

[Anonymous Coward]

As I said, why is a program broken for trying to be installed in the program files directory? Every installer pops up a UAC alert, except of course for the malware UAC was attempting to stop in the first place, those pop ups tend to annoy users (especially in vista) so users start ignoring them. UAC was terribly implemented at first and that's quite obvious from how it was changed to be less annoying in Windows 7.

Re:If this were Windows

[Anonymous Coward]

If you mean the installer itself causing a UAC prompt, so what - it only happens when you install the program, which is usually a rare occurrence, most often just a one-off for each application. If somebody is installing things so often that the UAC prompts grow annoying, they should step away from 123smileys.com (or whatever the popular crapware site is these days).

Once the app is installed, the user shouldn't see any UAC prompts from it, and that's not hard to accomplish for most apps. Usually the developer has little or nothing to do if he followed MS recommended practices from around the time of Windows 2000. Still, many smaller apps expect to be able, for example, to write to an INI file in the same folder as the EXE under Program Files. That sort of thing was wrong long before Vista & UAC.

- T

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

[Anonymous Coward]

Oh yeah mod me troll because it hurts your feelings freetard. You know it's true.

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

[Zero__Kelvin]

"Because I'm a programmer by trade, this change log is absolutely useless to me.

Get a software engineer to explain it to you.

Re:fixes are fully disclosed, stop fud'ing

[/dev/trash]

bash: telnet: command not found

Re:fixes are fully disclosed, stop fud'ing

[Anonymous Coward]

Why was this modded down?

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

[Anonymous Coward]

Short:
Because manually upgrading your Linux kernel from 27 to 34 is a painful and traumatic experience.

Long:
Most people who use Linux do so through distributions. The kernel number typically stays the same during the life time of the distribution. Since there are several customers paying companies like Red Hat to maintain a solid distribution for years, you see a patch like .27.48 to fix various kernel problems (usually a back-port from the higher kernel, but not always). Businesses like stable servers, and don't want to have to continually test the new functionality that comes with implementing the higher patch builds.

Re:Variety is the spice of life

[Anonymous Coward]

Because 2.6.34 adds features not in 2.6.27 which may have their own new bugs or might break software dependent on a 2.6.27 way of doing things that has been phased out since then. I don't know if any such issues exist, but the distro maintainers want as few changes as possible between releases because it means there is less to worry about.

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.

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?

Who cares?

[Anonymous Coward]

Guh noo slash lin-ocks sucks. It's not like it'll ever be ready for the desktop or whatever. When will you dweebs learn that proprietary for-profit software is always superior?

Re:Who cares?

[Anonymous Coward]

You troll like a ten year old.

Re:Who cares?

[Anonymous Coward]

You troll like a cow...

Re:Who cares?

[Flossymike]

Well I like Monkey Island :-)

Re:Who cares?

[Anonymous Coward]

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

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

Who does upgrade ?

[alvieboy]

I don't think people realise that less than 2% of Linux users will actually download, configure and compile its own kernel.
So it's actually irrelevant if changelogs or announcements depict whether high-risk security fixes were or were not applied.
You, as a Linux Distribution user (Ubuntu, Debian, RedHat, SuSe, you name it) do not care about it. You just want to upgrade your system. And you will - if your distro maintainer sees any urgency to push this or that fix.
And kernel maintainers (distro) happen to know exactly what's on the table. They follow the mailing lists, they follow bugtrackers.
Even if a bug shows up relevant enough to cause panic among everyone, no one will update their systems by hand. Instead they will rely on "standard maintenance procedures", like running their favourite distro-specific upgrade program.
Just like M$ Windows people do. And Apple. And just like everyone else.
People still use IE6. People still use W95. People still use OS2.
You are all paranoid if you think otherwise.
Álvaro

analogy () returns FAIL

[Anonymous Coward]

Ford builds their own engines, nimrod. PLZ try again.

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:analogy () returns FAIL

[nschubach]

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

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

[Anonymous Coward]

It isn't a flood in the sense "Lots of bugfix releases against the same product in quick succession", it's like "A bugfix release for all our maintained releases".

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

Here's your sign.

[Zero__Kelvin]

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

Newer versions of the kernel always have fixes, and it is unlikely that any major kernel release has ever been made that didn't have security fixes in them. I suppose Linus, Greg and the gang could appease you by stating "there are security fixes in this release" every single time they release a kernel, but this seems a bit ludicrous. If you have a brain and an hour to learn how to use git to search the changelogs the information is readily available to see exactly *what* gets fixed.

I'm not sure if you are new to Linux, or a troll, but this is not a concern for those of us who use the software. That is why distributions exist, and it is those people who worry about such trivialities. Almost all Linux exploits are theoretical, and the highly heterogeneous nature of the beast makes targeting specific kernel versions rather ridiculous. Even if you think you are attacking 2.6.27.x you still don't know what patches have been applied by the distributions team members.

Or in other words, use the latest stable release and you'll be fine. This isn't Microsoft. Nobody is ignoring known security issues and hoping they never get discovered.

Kernelnewbies

[JonJ]

Always has a nice human readable summary of the changes.

Here's a question

[Anonymous Coward]

How long will it take to move to 2.8? 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?

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.

A flood eh?

[Anonymous Coward]

It's a pity the guys name is Kroah-Hartman and not Noah-arkman.

oss-security

[Anonymous Coward]

You can keep track of security fixes at http://news.gmane.org/gmane.comp.security.oss.general/ or http://oss-security.openwall.org/subscribe. If you use twitter, you can choose to follow @oss_security too.

Time to drop 2?

[AnuradhaRatnaweera]

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