Security Holes Draw Linux Developers' Ire 477
jd writes "In what looks to be a split that could potentially undermine efforts to assure people that Linux is secure and stable, the developers of the GRSecurity kit and RSBAC are getting increasingly angry over security holes in Linux and the design of the Linux Security Modules. LWN has published a short article by Brad Spengler, the guy behind GRSecurity and it has stoked up a fierce storm, with claims of critical patches being ignored, good security practices being ignored for political reasons, etc. Regardless of the merits of the case by either side, this needs to be aired and examined before it becomes more of a problem. Especially in light of the recent kernel vulnerability debated on Slashdot."
Time for (even) better security? (Score:5, Insightful)
Re:Time for (even) better security? (Score:1, Insightful)
Because Linux servers are cheap, just load balance your charge between 2 or more of these and you'll still have the availability which is actually what you need.
Kind of an interesting contrast (Score:5, Insightful)
Re:Time for (even) better security? (Score:4, Insightful)
So it begins. (Score:5, Insightful)
Will Linux strike the perfect balance? Will Linux be taken over by a lunatic like Theo and go the OpenBSD route? Will Linux lose it's viginity to Windows and become a security nightmare? Stay tuned! All this and more on the next episode of OS wars!
Re:FUD (Score:3, Insightful)
Re:linux vs ??? (Score:1, Insightful)
Don't be an idiot. (Score:5, Insightful)
Here it comes (Score:2, Insightful)
Re:Time for (even) better security? (Score:5, Insightful)
Personally, I make sure I know the answers to that sort of question before ANY changes are made to my production systems.
Maybe it's time... (Score:5, Insightful)
My Windows XP machine is solid and secure. My FreeBSD machine is solid and secure. My Windows ME machine -- well -- it runs, and it's quarenteened so I suppose in some ways it's secure.
Right now I'm installing Gentoo on a box so I'm going to see where this goes, but I am going into it with full realization that no OS is perfect, nor is it perfectly secure. This means that I'm going to take security as seriously with this machine as I do the rest of them.
Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it.
Why people think OSS is automatically more secure is something I never have really understood. There is some added comfort in knowing that most holes will be discovered and fixed promptly, but even that is an assumption one shouldn't bank on.
Grsecurity is for real (Score:4, Insightful)
They are just the sort of real gurus that can spot new vulnerabilities from code and exploit them in a matter of minutes. When Grsecurity was having serious funding problems last summer Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies. (Those do exist, believe me. They are doing commercial intelligence, stealing trade secrets with the knownledge..)
Those guys are technically brilliant, years ahead of what Linux stock kernel has in security features. They are just a bit arrogant and bad with people. Also at the same moment the upstream kernel developers don't like being told that their stuff is complete crap on some area. They downplay it, ignore and use the "whoareyou,Iamthekerneldeveloper,youknownothing" tactic.
Grsecurity guys could absolutely smash LSM by showing the vulnerabilities they are talking about as pocs. They are just a bit too disgusted and pissed off. There are several other areas like the exec_shield (that *is* atm getting to upstream kernel) that have big faults as well...
They could prove their other points as well.. But it would be moot since they ARE correct in any case.
Re:Time for (even) better security? (Score:5, Insightful)
Personally, I know my servers can survive a reboot, because I test them for that. If I make any serious change that may affect startup I assume it will fail, and then set out to prove myself wrong.
PS: I wish I did not have to.
Re:Time for (even) better security? (Score:5, Insightful)
andy
Re:Here it comes (Score:5, Insightful)
holes in the kernel have been allowed to go on as long as they have?
Allowed to go as long as they have...by whom? By the volunteers devoting their time to kernel hacking? I'll give you the benefit of the doubt and assume you're an active kernel hacker...
You compared Linux to Windows in your original post: how many security holes in Windows still remain, years after they were first reported? (For that matter, how many holes are we still unaware of, because the source-code is closed?) Why have these security holes been allowed to go on as long as they have? (Answer: because resources are finite; and Microsoft has other things to focus on. Likewise for Linux. If you feel that too few resources are devoted to security in the kernel: volunteer. Or criticize and offer no helpful solutions. I choose option A).
It's all too political (Score:5, Insightful)
Start over, basing on OpenBSD for a change... (Score:5, Insightful)
Long-time shell-provider SDF used Linux
Now, it's a 64-bit version of NetBSD.
OpenBSD claims:
"Only one remote hole in the default install,
in more than 8 years!"
Why not start with a core built for security,
- ie, rather than one built for popularity?
My two cents...
Re:Maybe it's time... (Score:5, Insightful)
I pretty much agree with you, but... (!)
Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it. (my emphaisis)
Having the source available for anyone to read can lead to the OS (app, library, whatever) being more secure. Assuming that a wide-enough group of people do actually read the code. I'm confident that this happens with Linux, the *BSDs, etc.
Most people tend to equate OSS with secure, I'd guess, because security-through-obscurity is largely a false promise, and we recall that many-eyes-make-bugs-shallow. Both concepts that appeal to the type of geeks who are interested in security ;)
Waaah! 3 weeks without an answer! (Score:5, Insightful)
So ... rather than ask on the mailing list who is the best person for security submissions relating to whatever bug he found, he emails the top dude (during Christmas holidays no less) and then whines when no answer is forthcoming within his preferred timeline. Gimme a break!
As a total noob, I went to kernel,org and found this on the first page:n g-bugs.html if you want to report a Linux kernel bug.
Please see http://www.kernel.org/pub/linux/docs/lkml/reporti
http://www.tux.org/lkml/#ss5 explains why XX doesn't answer emails - too fricking busy is the usual reason.
If I were concerned about publishing the bug, I would have asked ON THE LKML LIST for who would be the best person to submit security-related bug and patch to for the XX module.
Re:Time for (even) better security? (Score:5, Insightful)
Re:Here it comes (Score:1, Insightful)
New Windows security flaw -- "Sigh, another bug. Use Linux, Windows is insecure."
New Linux security flaw -- "Well, um, you ignorant troll, all software has bugs, and most have more than Linux."
Re:Interesting point of view (Score:4, Insightful)
No, an important security rule of thumb. Don't waste effort fixing the holes which no one would need to exploit because you are wide open in other places.
Eg, would you worry about people being able to drill into your safe if the safe had no door?
There are special cases where you might (front of safe visible to trusted people 24/7 or something), but generally speaking, priorities are important.
Re:Time for (even) better security? (Score:5, Insightful)
That's not the point. I am getting ready to force my Unix admins to patch their boxes on a more frequent basis than "yearly", and they are already screaming bloody murder. I am sick and tired of our Unix boxes getting rooted because some admin wants 365+ days of uptime and can't be bothered to test and install a kernel patch that fixes some important hole. That there is NO scheduled maintenance to start is an even larger problem that I'll rant about in a different post.
And by the way, other Unix systems have capabilities, MAC labels, etc., and you know how most admins implement security on their systems? Every one of the Unix support team knows the root password, and the application support people use setuid scripts to administer their software, like they were doing in 1985. Capabilities, labels, and friends are extremely difficult to implement, and these features cannot save you from the one time a tired kernel programmer accidentally performs an unbounded input or forgets to check a counter. You will always need to patch your kernel (and reboot) in order to maintain operational security. Period. End of discussion.
And if your only availability measurements are along the lines of
please get a clue: Availability doesn't include all of those times when your users tries to access a rooted system (even though the system is "up"), and it isn't a bad thing to schedule maintenance windows and notify the users and take the system down for patches or upgrades. In fact, I would much rather do so in a controlled fashion, as I can have backups made and documentation updated and I can take my time to do things correctly because I had time to test everything beforehand. Versus a 50+ hour nightmare/marathon starting with the pages from the instrusion detection system (or worse, from someone else's IT security department) at the wee hours of (if you are lucky) Saturday morning.So don't complain to me about lousy uptimes. Because when your server gets hacked because of a kernel bug patched three months ago, and you didn't apply the update because "my uptime counter will get reset" (i.e. you are lazy), I have to clean up your mess: Investigating the attack, determining the extent of the intrusion, validating the backups, etc.
BAH. Rant mode off. I will spare you a discussion of the proper engineering processes that help to lessen (but not eliminate) the risk of security-related software flaws.
Re:OK, if not Fedora Core.. (Score:4, Insightful)
Re:Maybe it's time... (Score:1, Insightful)
A neglected Unix is far safer than any "competently administered Windows".
Two randomly selected individuals out of any population aren't going to be equal. One is likely to be inferior. This is reality, not a Vonnegurt novel.
Re:Grsecurity is for real (Score:2, Insightful)
I guess this is a good reason to trust them?
Re:Maybe it's time... (Score:3, Insightful)
Maybe it's time everybody get off of their OS Religious High Horse and finally admited that an OS is only as stable and secure as the user who is administering it.
Everybody acknowledges that. But that doesn't mean that operating systems are all alike. Linux - out of the box - is far more secure than Windows, and far less secure than OpenBSD.
My Windows XP machine is solid and secure.
Really? The last time I tried to secure a Windows machine, Microsoft had a list of 200-odd things to change, including obscure registry entries. Furthermore, the box was practically useless, as half the user applications insisted on being able to write to privileged directories or just plain run as Administrator.
Sure, in theory you can secure both machines quite well - ignoring the open vs closed tendencies of course. But in practice, it's a nightmare trying to get Windows to sane security settings and also work properly.
Why people think OSS is automatically more secure is something I never have really understood.
Nobody thinks that. You have misunderstood the argument that the OSS development model by its nature tends to result in more secure software.
Comment removed (Score:5, Insightful)
broken development process (Score:5, Insightful)
If I'm running 2.6.8, and a new bug comes out, I'm forced to either A) upgrade to the most recent 'stable' kernel, introducing new features about which I know nothing, and which themselves may be security problems, or B) can hope that someone will backport the security fixes to the kernel version I'm running. I don't know enough about kernel development to patch it myself, but I can no longer just drop in the most recent stable kernel and expect it to work unchanged.
A sysadmin's most precious commodities are time and attention. With this new development model, suddenly I am forced to either pay a great deal of attention (and a great deal of time) to each and every version of the Linux kernel, or I need to pay a vendor to do it for me.
The kernel developers are, in my opinion, shirking their single most fundamental duty... to ship a stable, secure product. Suddenly, because it's easier for them, they have abrogated the fundamental contract, that they will write great software. (buggy, insecure software is not great, no matter how many features it has.) They just wave their hands vaguely in the air and say tha the distributions will take care of those problems.
Guys, it's not gonna happen. The way you get stable software is by not adding features. In your case, by branching off to 2.7, and letting us beat the unchanging (except for bugfixes) 2.6 tree to death. If you keep adding features, you keep adding bugs. That's how it works.
You had this NAILED for years and years... there is a huge community that has built up around the fundamental social contract that even numbered kernels are as stable and secure as you know how to make them, and the odd-numbered branches are the home for new code and new features. Changing that contract simply becuase it makes your lives mildly easier is a hugely destructive idea. You may save yourselves a bit of work, but you create an enormous amount of it for everyone else.
Ted T'So said:
In other words, he thinks it's perfectly fine if only 1 out of 3 'stable' kernels are actually stable.This is not acceptable.
You can bet that Bill has a big grin on his face about this one. If I want new features with my security fixes, I might as well choose Microsoft and their service packs.
Heck, they even have a QA team!
You're basically right, but... (Score:5, Insightful)
But just to add a couple of minor details:
A) I'd argue that Microsoft didn't start secure and slowly get down the drain. They started by ignoring security outright.
E.g., if I remember right, for example, the file server security in NT 3.5 and the pre-SP1 NT 4.0 was entirely in the client. Yes, the client was supposed to check for itself if it's allowed to access a file, and if not, back down. However, if the client was not that nice, it could go ahead and request the file anyway... and get it.
E.g., MS Bob, in the name of userfriendliness, asked you to change the password if you miss-typed it 3 times. No, not if you successfully logged in after mis-typing it 3 times. That's it. Three failed attempts in a row, and you can set a new password.
Etc. I could go on for ever, but these are ludicrious enough to illustrate the point: MS didn't start making a compromise here and there. It outright ignored security until it bit them in the ass.
B) But to be fair, so did everyone else, and some still do.
E.g., it's not a case of Linux eventually getting as insecure as MS Windows. Linux already _was_ less secure than Windows, oh, say around the time Windows 2000 was released.
Sorry, I'll probably annoy the pinguinistas, but taking a Linux system as root online back then, meant you had a script kiddie logged in withing hours at most. _And_ most distros made the same MS mistake of installing and starting every possible service by default, and no firewall either. I know my SuSE systems got Apache, MySQL and God knows what else if I didn't uncheck those at install time.
It took some code reviews paid for by RedHat and the like, before Linux was anywhere _near_ secure.
C) Basically, sad to say, much as nerds balk at "clueless lusers" running without a firewall or MS for having exploitable bugs, most are just as clueless themselves when it comes to writing secure code.
And I don't mean just bugs or lack of communication ("oh, I thought YOUR function checked the buffer length already.") I mean outright lacking even the most elementary clue about secure design, and not giving even the bare minimum thought to what could happen.
Just as end lusers think they're safe without a firewall because they don't directly see the script kiddie breaking in, coders tend to ignore the unseen threats just as well. Mentalities like "oh, surely noone will edit the id in the URL and make themselves superuser" are the norm, not the exception. Or at most they'll repeat mantras they've heard before, without even understanding what those mantras mean.
It's not even a MS vs Linux thing. Windows, Linux, Solaris, whatever. Unless you have some security minded people trying hard to find a bug or way in, you end up with a catastrophe. The average coder's work is a heap of security holes waiting to be exploited.
Re:Grsecurity is for real (Score:1, Insightful)
> last summer Brad was forced to sell new
> vulnerabilities from Linux kernel code to
> unmentioned blackhat companies.
So, I see. If Grsecurity gets into the standard kernel, and Grsecurity has "funding problems" will Brad put "accidental" vulnerabilities into Grsecurity and sell those to blackhat companies?
Sorry but this is bull. When it comes to security, a person's integrity is crucial. Yes, we all know the "many eyes" argument, but as Ken Thompson showed in his ACM lectures, it's possible to defeat the "many eyes".
You're making a serious claim against someone in Brad's position. Either provide reference links to back up your claim or offer a retraction.
Re:Interesting point of view (Score:3, Insightful)
Tom
Unless you rip out what you don't need. (Score:3, Insightful)
If you aren't running it, you don't need to patch it.
Which only leaves the security/bug fixes for what you do run. Do I worry about a "reboot test" after I upgrade perl? No. Why should I?
On my Debian systems, the only patch that requires a reboot is a kernel upgrade.
A "reboot test" might still be a good idea, in the 0.0001% of non-kernel situations where it would show a software problem
I'd rather not reboot my boxes because that seems to be when the hardware fails. Much as most light bulbs that blow seem to blow when you turn them on.
Re:Time for (even) better security? (Score:3, Insightful)
At work we have 2 nearly identical systems that can each cope with the entire load and they don't need to talk to each other except for non real time things like end of month reports. The reboot test is a great way to keep from getting bitten by stupid things like a change in openssh's dealing with
How do you know that the disk label is still working? Most OS's won't let you read it (since its cached). There are many parts of modern hardware that are essential to booting but can't be accessed outside of the reset sequence. There are things like
flash bios that you can't test from a live system and that perpetual problem with hard disks of "will it wake up next time?"
I've got a few outstanding bugs with cisco because their NAT/PAT stuff doesn't come up quite the same way as when its entered so the only way to know if a config is going to "stick" is to bring the thing up from a full reset state.
I agree that a sysadmin should be able to come up with a full deadlock state diagram for the system but when that graph has more than 1000 nodes on it, the only sure way is a 'halt' and hit the reset switch but even that doesn't test a full start from a power off state.
That word doesn't mean what you think it means. (Score:3, Insightful)
- How much have you paid Linus, Alan Cox, Andrew Morton, et. al., directly?
- Did they make any promises to you about the reliability or stability of the kernel?
- Take a look at the GPL, particularly that explicit disclaimer of all warranties. Did Linus send you a certified mail letter in which he waived that clause for you?
- Did you get certified mail waivers of that clause from all the other kernel developers?
- I'm sorry, I didn't hear you the first time--how much did you pay Linus, himself, directly?
- Does Linus give you binaries only of the kernel, and thus make you dependent on him?
- Does Linus give you source code, and thus give you the option of auditing code yourself?
- Have you done your own code audit?
Just a few simple questions, really. Because before you go about saying that Linus, or any other kernel developer, or any other Free Software developer, has a duty to you, I'd like for you to know what duty means.Duty means a debt is owed.
So--as a result of the community giving you, at no cost, generous license to literally hundreds of millions of dollars of intellectual property... they owe you something? Because they gave you a gift?
I don't know where this false sense of entitlement within the community arose, but I really hope it goes away soon. You aren't entitled to anything. You aren't entitled to the sweat of my brow, the labor of my hands, the product of my mind--but when I release something under a free license, I give you those things. I say "here, have something; I made this. I want to give it to you."
And what are you doing?
Looking the gift horse in the mouth.
Re:Unless you rip out what you don't need. (Score:4, Insightful)
Quick, everyone RELAX (Score:2, Insightful)
It's going to take more than a couple of articles to bring about the demise of Linux. There are definite reponsibilities and issues that need to be addressed in Linux, as there always will be in any project of any size. Let's all just support our OS, and make sure that we make it known that it's important to us that these issues are addressed. A few negative articles are not going to kill OSS, and Linux has a way of weathering problems. Relax, and support the developers so they can get on with fixing the problem(s).
-Jay
Re:True, all politics (Score:3, Insightful)
I bet that Linux has alot better device-support out of the box than Windows XP or Windows Server 2003 has. Windows relies on third-party drivers that may or may not work, whereas in Linux they are already in the Kernel, where they receive more attention than third-party drivers would receive. And that's thanks to Linus's stance on drive ABI's. Without that, we would have a kernel that had minimal device-support and which needed flaky third-party drivers just to get a functional system. And those drivers would only work on x86-systems. Why would the OEM's spend time developing driver for PPC or Sparc, since those are niche-systems? But since they are in the kernel, they work on more exotic architectures as well.
Favorite Quote (Score:2, Insightful)
- sbergman27, [http://lwn.net/Articles/118251/]
These PaX "security experts" whine and complain like script kiddies. No wonder.
I think the real point is made that distro volunteers and employees are more likely to implement a patchset for security reasons. Also, this is in the best intrests of the community, by limiting the amount of direct communication forced upon our Overlord and Savior, and also because most of us are using a distro. If a distro has a security patchset and the vanilla kernel is left with holes, surely someone will take notice and go through the proper channels, doing all that hard contacting work for you.
Re:Grsecurity is for real (Score:5, Insightful)
It'd be nice if someone would ask the PAX developers why they modified their test suite to fail under exec shield. Run the pax test suite in a exec shield kernel and all the vulnerability simulations will succeed. That's not why exec shield is bad, it's because the test suite disables exec shield on purpose (you can disable exec shield, that's a feature)
BTW, exec shield is not going in the kernel. Exec shield != "amd NX bit". The amd nx bit support has already gone in the kernel, but I'm not surprised at all that no grsecurity patch is going to the kernel. Grsecurity developers have NEVER submitted their patches to mainstream, they haven't even tried it, they haven't listened to constructive criticism. That's why grsecurity is not in the kernel and LSM is. They have just sit back saying "our stuff is better, use it" without even caring. There're lots of projects that have go poop because of that attitude. Remember the guy who rewrote the whole building infrastructure which never go in mainline? He updated his stuff regularly and critized Linus for not getting his obviosly better alternative. He didn't listen to Linus when he said "ok, just split it in small, individual parts" (like everybody else does) "and I'll merge it". When some other guy started to fix the available building system, the "Better stuff" went poop. Same will happen with LSM. LSM is bad? Well, what will happen if the developers decide to fix it, where will go grsecurity?
I very much prefer a good developers/maintainer than a bad one, so I'll choose LSM at any time even if it is technically inferior. A good maintainer means that in the future he can rewrite his stuff if it's not good enought. That's much better than some guys who sit back in their mailing lists saying "our stuff is better"
New development model to blame? (Score:5, Insightful)
Some of these bugs, according to the article, have been around for ages, so the new dev model isn't to blame. But Linus and Andrew didn't even respond to these critical vulnerabilities....
Just go ahead and create a 2.7 branch, and then assign a maintainer to the 2.6 branch and let it stabilize. I don't see any reason for not doing this.
Re:Grsecurity is for real (Score:5, Insightful)
So basically what you're saying is that these are the sort of guys who're so morally broken that they wouldn't pass even the most superficial of background checks for a sensitive position, which is no doubt why they need to get money by selling to blackhats rather than getting a real job in computer security. Basically, exactly the opposite of the sort of person you'd want to trust as a contributor security information and patches. Thanks, I'll remember to disregard anything I see from these morally challenged turdballs in the future.
Right on! (Score:5, Insightful)
2.6 is currently a developer's dream and an administrator's nightmare.
It is a smoking pile of bleeding edge patchwork. It can do everything in double time and brew coffee concurrently, but it cannot serve a file reliably (for example - as outrageous as it sounds that last part is actually the truth).
The absolute major top-1 problem is the huge flux of patches; 4000 changesets between 2.6.9 and 2.6.10... One kernel fixes maybe 100 bugs and introduces the same number along with a heap of new features while it deprecates a few old interfaces.
If 2.6.5 is the latest stable 2.6 kernel for one particular use (which I know for a fact that it is for some uses), you're stuck with a local root vulnerability because most likely 2.6.11 which may have a fix for this one bug will crash with that workload (as 2.6.6-2.6.10 did).
And the examples I'm pulling out here (file serving and many unstable kernels in a row) are not unreported problems. They are not new problems. They have been worked on, partially fixed, etc. etc. but with the development model as it is, you just cannot expect fixes to have a very long life-time.
It is very very sad. But I think it will change as someone realizes how bad the situation is. Probably half a year or so from now, when people start getting really annoyed that you *still* cannot route, web-serve or file-serve in any significant volume with Linux 2.6.
Until then, it's Linux 2.4 and Solaris - both slow compared to 2.6 maybe, but at least they stay up over night
Re:Grsecurity is for real (Score:1, Insightful)
you're wrong when you say that paxtest disables execshield. to do that one would have to write to
the reason we have never submitted PaX (let alone grsecurity) to lkml is because... shock and horror... we never *wanted* to. now tell me what resulting constructive criticism we didn't listen to, i'm all ears.
you're also confused about LSM and actual modules. the former is a framework, as it is, it's unfixable for grsecurity because the needs of grsecurity are *beyond* the stated role of LSM. as simple as that.
Re:Time for (even) better security? (Score:3, Insightful)
Preproduction is key here generaly working of of split mirrors and the like to insure things are exact replica's. It's just an issue of procedure if you dont have good procedure here you wotn have good tests. So I would differ on the nigh-on impractical part as matches hardware and a good mirror is the same thing
Course I may be biased I work with exact matching boxes we I can bring up a server on any of the hardware at any time in case of failure.
Re:Patches are in -ac7 (Score:4, Insightful)
Linux isn't just a hobby toy anymore. If Linus is holding on to things too tightly, he's doing himself and the community a disservice.
Re:Time for (even) better security? (Score:3, Insightful)
Re:Interesting point of view (Score:3, Insightful)
The Linux guys failed more on the netiquette than the PaX guys. They failed to put forward a real working contact list. Security guys don't like to trust random results from google. How do you know your sending it to the 'real' security person? I can't put the blame on them for this mess at all. Imho, one should never ever ever fail to provide an easy to find current working contact list for exploits.
Re:Time for (even) better security? (Score:5, Insightful)
Next time there's a small hole in Apache that for instance allows execution as the apache or nobody users, that local kernel security hole will come back to bite you in the ass and lead to your box being rooted.
It doesn't even have to be a Apache hole. Say some little bit of user supplied input is being used in some chrooted or otherwise jailed context, perhaps you're generating a PS or PDF file in some temp directory on the fly. Again that little security mistake you've made combined with the local privilege escalation flaw you didn't patch will stretch the hole to goatse.cx proportions.
Unless your machine is unplugged from the net, patch that kernel. Seriously, it's like insurance, a little pain every now and then so that when the shit hits the fan you'll hopefully live through it.
Re:So it begins. (Score:3, Insightful)
Yeah, those OPENBSD'ers are stuck in the mud and never think about new development.
Re:True, all politics (Score:3, Insightful)
Absotively.
Windows relies on third-party drivers that may or may not work, whereas in Linux they are already in the Kernel, where they receive more attention than third-party drivers would receive.
More attention than from Microsoft? Certainly. More attention from the people selling the hardware in question? I would hope not, for the company making it's sake. The fact of the matter is that it is critical to their business, and that most windows drivers work, and work well. It doesn't matter if you're OEM or retial, if you make doohickeys for Dell, and customers complain to Dell, Dell will complain to you.
When you think it over though, that makes it better not to have closed source drivers for Linux. Why? Because Linux just isn't critical to their business. Having half-assed buggy, obsolete drivers that the developers can't fix would make the situation worse, not better. Not having a stable ABI is the lesser of two evils, but it is a drawback, not a strength.
You must understand that to users, putting in a CD to install the drivers is a non-issue (particularly if the task involves installing something *gasp* inside the case). If I thought Linux could get the same level of support as a Windows driver, I would recommend he did. But if Linux was that important, they couldn't afford not to support it anyway. So by the time you have the momentum to make an ABI work, you don't need it. Ironic, isn't it?
Actual Concern (Score:2, Insightful)
Re:OK, if not Fedora Core.. (Score:2, Insightful)
Yes, I'm shocked that you assume people have no life and can maintain a set of patches for their kernel just like you do. Sure, with Linux, I'm free to fork it, but I'm also free to write the next great epic novel. I leave you waiting in suspense, I guess, for my novel to appear in the book stores (I hope you are patient!).
Re:So it begins. (Score:2, Insightful)
I wonder how many Linux geeks use OpenSSH to tunnel X Windows from their PC over the network and think "Wow, Linux is the bomb, Linux does this cool stuff." Probably too many.
Re:broken development process (Score:4, Insightful)
There are actually improvements with 2.6: the distros have been invited to take over 2.6.x.y series, so that if they're going to be backporting patches, they can contribute this effort back to the community. In 2.4, the distros carry so many patches that you'd have an easier time backporting from the latest 2.4 vanilla kernel than from a distro kernel with the same nominal version. They have so many patches because they feel the need to add functionality in their stable series.
Also, Alan Cox is maintaining a tree of "really stable" kernels, where he takes only bugfixes from the current work and adds them to the base version he's using. I haven't determined if he's planning to continue 2.6.9-ac indefinitely, or if he's going to only release 2.6.10-ac kernels once he judges 2.6.10-ac to be sufficiently tested.
The real issue is that Linus is currently in charge of releasing the stable versions. He's really good at identifying what should go into the stable series, from the perspective of guiding development, but he doesn't have the discipline to identify a completely-working version and call that 2.6.x. My prediction is that, in accordance with the ManagementStyle document, he will eventually decide that people complain about his release descisions, and therefore he should get somebody else (probably Alan Cox) to do that.
As for development causing security problems, there has yet to be a 2.6 security hole in code that was added during 2.6. In general, new code is checked for all known patterns of bugs (almost all security holes fall into some pattern) and bad practices before being accepted. On occasion, a bug is found which is part of a new pattern, and future code with the same sort of bug will be caught, but existing code with that bug is not necessarily identified. This means that bugs are generally in code that hasn't been changed in a long time, not code which has been changed recently. In fact, there have often been bugs found in old versions which had already been eliminated unknowingly from new versions by people writing replacement code using improved techniques.
For example, the recent hole was in code written ten years ago to facilitate the switch from a.out to ELF. The hole was a race condition due to changes made several years ago in the requirements of common code.
Re:You're basically right, but... (Score:3, Insightful)
"MS people" don't need to defend the company based on Microsoft Bob because Microsoft Bob was sold for about a year a decade ago, then was dropped, and nobody has given a second thought about it since then.
That would be like criticizing Ford because their cars made in 1935 lacked seatbelts. "Ford is the worst auto-maker because their 1935 sedan had no seatbelts, they were trying to kill their users!" Does that make any sense as an argument? No.
Is Bob insecure? Sure. Does it matter? No, of course not! NOBODY USES IT! Just like nobody drives a 1935 Ford sedan on a daily basis. It doesn't matter. It's a pointless, and stupid, argument. Microsoft Bob can't be used as a hacking tool because NOBODY USES MICROSOFT BOB!
You're just as deluded as the poster I replied to. Join the rest of us here in 2005, where nobody has even seen Microsoft Bob in 8 years and few people have even heard of it. Nobody gives a shit about Microsoft Bob. Few people did when it was on store shelves, and nobody does now... except a few deluded people on Slashdot.
Re:Patches are in -ac7 (Score:3, Insightful)
Absolutely friggin brilliant. Because we all know no one ever fakes their idenity in IRC. You sir are a genius!