Slashdot Mirror
Open Source == Faster bug fixes
solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.
Is this important? IMHO, yes. Never mind corporate interest, something like the Bastille Project, OpenWall, Trustees, ACL, or even ReiserFS, could -never- have been written by 3rd parties if Linux had been closed-source, and many of these packages might never have been written at all.
100,000 developers & debuggers is a lot more than Sun, Microsoft, IBM and Apple can muster, combined. Why should it surprise anyone that such a large number can out-perform such small companies? *Note: The 100,000 is an estimate of the number of people who are on the kernel mailing list, plus the number who aren't but who play with the development kernel and will write bug reports in the event of finding any.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Additions and corrections welcome. And I don't require payment for them, either. :)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"These people generally cite certain prime examples to support their arguments.
And we all know THAT is a really dumb way to support arguements. Better to just yell and scream. "
Let me clarify: everybody seems to use the SAME examples. A couple of sunny days doesn't make it summer.
"and you actually support linux"
You've got that one right (I started with Slackware on a 1.1 kernel). Unfortunately I work from home on in an NT environment, so other than web browsing, I've have had little incentive to reboot into it for a while. I like the way Linux gives me back control of my machine. But in reality, NT is very stable (I haven't had any need to reboot in over two months), and it fills my requirements equally well.
"find a more popular web server than Apache (suprise, open source). Seems PERL is pretty open"
I'll give you that. I think that current popularity of perl is partly due to the success of Apache. Thanks to the AC's reponse for the Netcraft address (http://www.netcraft.com/survey/) that demonstrates Apache's rise to popularity at a time when there was no real competition (the NCSA server quickly proved insufficient). Apache like many of the other UNIX tools that have been the glue of the internet are popular because they were the first successes. As Linux finds it difficult to enter the desktop market, so Microsoft finds it difficult to dominate the internet.
I think that Apache's popularity will decrease in favour of IIS of the next few years. Whether Microsoft will pass Apache in popularity is another issue, and will certainly be a key point in the open vs closed source debates.
BSDI made their fix first because they had information about the bug direct from Intel (under NDA, before the bug was announced to the general public). They were forced by Intel to remove the fix they posted almost immediately because it violated the NDA. The Linux fix, IIRC, was not reverse engineered from the BSDI fix, but was a separate effort that worked in a slightly different way, without the help of Intel's additional info. As I understand it, BSDI's fix was later reengineered to behave in the same way as the Linux fix.
PS. I'm not knocking BSDI here, who I think make a great product. I'm merely correcting misinformation (at least, I think I am -- my memory's not great, and I'm too lazy to search the Linux kernel archives to find out for sure :-)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
They should have, IMHO, tracked how bugs fixed made it into production environments. The chief complaint I hear now is "I have to depend on some kid in Nebraska to fix his software, or at least get the patch happening and released?" (no offense to anyone from Nebraska). I had this very conversation at a meeting where I was in a kind of cheerleader/salesman mode for Linux/OSS.
I think that ANY commercial Linux distributor should, as point one of the business model, establish a means to rapidly and loudly manage bug fixes and updates. Hell, call 'em "Service Packs" so the PHB's will understand what you're talking about. Coordinate with the developers. Try to create a "path of least resistance" for people, esp. those that don't care about technology, just that they can have it fixed. Hire a couple of people to deal directly with developers and customers.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
From the web page. Apologies for the formatting.
1999 Advisory Analysis
Vendor - Total Days of Hacker Recess - Total Advisories - Days of Recess per Advisory
Red Hat - 348 - 31 - 11.23
Microsoft - 982 - 61 - 16.10
Sun - 716 - 8 - 89.50
Interesting that Red Hat comes out better overall than both of the others, even though Red Hat is generally considered least secure distribution of Linux available.
Microsoft Windows users use their computers in multitudes of different ways than Linux users. While a Linux user would know to use "shutdown -n blah blah blah" a Windows user might just hit the power switch. That's not a direct comparison, but really, I'm sure that there are some flaws in Linux that just haven't been found because Linux users operate their computers (for the most part) in a different manor than Windows.
Also, it doesn't help that with their popularity, Microsoft draws the fire of every scriptkiddie, security wannabe, etc, who all want to be the first to find a new bug and either exploit it or publish the fix.
The article seems to be slashdotted right now, so i can only speculate here... But i'm not convinced that Open Source produces cleaner code. It just allows you to have multitudes of people available to fix flaws, AS THEY'RE FOUND. In other terms, though, I think that closed source still has some advantages in a completely different context from security. Just more direction, rather than having everyone run around coding whatever it is they want to code.
Here's hoping that Microsoft stood up to their promise of not shipping Win2000 til it was ready.
FWIW, BSDI had a fix on day one or two of the F00F bug announcements. Sources reported that the BSDI fix was reverse-engineered to make a Linux fix. Days later, BSDI came up with improvements to their fix (first enabling it only on Pentium chips, later improving performance even on those systems affected). I assume the Linux folks did too.
Solaris and MS took weeks, plural, as I recall.
Conclusion? Competent engineers who care make for faster code fixes too.
(Disclaimer: I work for BSDI, but honestly, if I didn't really think their engineers were that good, I wouldn't work here either.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
apparently, the moderators also believed that this hypocrisy (especially in the light of Rob's obnoxious answer in the /. interview) should be moderated up for more people to see.
Of course by the same token, there are a fair number of Closed Source commercial products that have been dead-ended due to lack of developer support. In those cases there is even less likelyhood for bug fixes to come out.
In the OpenSource community there is always the possibility that, so long as a project is useful someone may pickup the torch and keep maintaining/developing a project beyond the point that the initial author(s) is/are involved.
Case in point would be MetaCreatations. They produce quite a number of 3D modelling/animation programs (Poser/Bryce/Painter/Ray Dream Studio). There have been recent rumors (it may be fact by now) that they are dropping support and development of all these packages in favor of a 'web-enabled' product called MetaStream (ie. producing content for a web plugin), and a 'High-End' product called Carrara.
The current install base either has to pay a much bigger than usual (and for some unafordable) 'upgrade' fee to switch to Carrara (versus the modest fee charged to purchase a new version of a software they currently own), or else stick with Ray Dream Studio and any bugs that remain.
If it was OpenSource then there would be more possibility bugs being fixed even if a 'new and improved' product came out, simply because some people would both care, and have the code to do it.
Colleen:Its a black-hole.
Hunter:Is that a good thing?
C:It is if you want to be compressed into oblivion.
H:Oh.. coooool.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
A nice example of proof-by-anecdote.
I suppose this is karma bait, but assuming that the same day fixes are all "friendly" a reasonable assumption considering the inertia of companies of these sizes then the following figures come out:
Red Hat:
348 days for 22 fixes 15.8 days per fix
Microsoft
982 days for 35 fixes 28.1 days per fix
Sun
716 days for 6 fixes 119.3 days per fix
Also Red Hat had 29% (about 1/3 for those non-math inclined out there) friendly bugs, MS had 42% (~2/5) friendly bugs and Sun had 25% (1/4) friendly bugs.
Draw your own conclusions.
I thought it was interesting that although Red Hat came out on top by a decent margin, the article said that RedHat could be even faster if they payed more attention to the community.
Billy, Steve, and all the rest
Try to make their code the best,
Flapping hard against the storm,
Going nowhere, getting warm.
Linus T. and RMS
Found the way to true success:
Hiding errors makes no sense;
You can fly with turbulence!
: Fruitbat :
I have discovered a truly remarkable
Maybe someday you will understand what Open Source Software (OSS) is about well enough to not make such strange statements.
Here are some clues: it is not about writing software "for free"; it is not about not being paid a lot of money for writing it; it is not about giving your competitors the ability to put you out of business.
And here's the biggest clue the market has yet to particularly appreciate: once customers of software come to appreciate the benefits of insisting on Open Source, and assuming they therefore do insist on it in greater numbers, you won't be able to get paid well for writing software that isn't Open Source.
Keep in mind the fact that the huge valuations of RHAT and LNUX on NASDAQ; the success of GNU/Linux, Apache, etc.; and so on have all taken place with nearly 0% of the end user of software insisting on Open Source per se. All those end users have cared about so far is faster, better, "cooler", more reliable, etc., all of which Open Source can deliver, more or less.
Once it becomes clear that Open Source per se delivers advantages closed source cannot -- advantages that can trump all the disadvantages (slower, fewer features, etc.) in any given instance -- how will you make money writing closed-source software?
Really, do take the time to investigate just how much money people are making writing OSS, how much more freedom we have to change jobs and still take our expertise, even our code, with us to the next job, and so on, before you make public statements about whether OSS is "suited" for certain kinds of software development.
Practice random senselessness and act kind of beautiful.
I should probably clarify my "even our code" statement.
It refers to the fact that, of the various products whose source code I've been an "expert" in maintaining during my career, I can be hired to maintain that code by a large percentage of its users only when the code was distributed Open Source (more specifically, GPL'ed).
Put another way, closed-source development isn't just about locking in customers -- it's about locking in the vendor's programmers as well, by making it harder than it would otherwise be for them to get good jobs maintaining the same code elsewhere.
So if you're still using PRIMOS, or Numerix machines, or you use Cadence's NC-Verilog on Suns, it really won't help you much that I've got some expertise maintaining portions of those systems, unless you've paid lots of extra $$ for the source. The $$ I was paid by the respective companies (Pr1me, Numerix, Cadence) to work on that code was, indeed, decent, but is about all I can expect to ever earn for that particular expertise.
But if you're using GCC, g77, etc., you can hire me to work on them. (In theory, anyway; I'm not exactly looking for work these days.)
That makes OSS development more valuable to me as a programmer than closed-source software development, and in fact it gives me incentive to favor long-term viability of OSS products over the sort of short-term focus that has so characterized closed-source products over the past 20 years.
I.e. if I can profit from closed-source development for only the duration of my employment at, say, BigSoftwareCo, then it behooves me to maximize my salary & benefits during that duration, leaving it essentially up to BigSoftwareCo to decide how it will maximize its long-term viability. Since I can profit from OSS development for the duration of the practical life of that software, I have more incentive to make it live a long, healthy life, even if that means making less $$ in the short run (not necessarily always the trade-off I have to make, but one I've willingly made a few times already).
So, as an OSS developer, I'm more interested in making sure the software is, and remains, useful for a long, long time (ideally, with as few changes made by others to my own code as necessary, so I have maximum expertise in it).
Though I've personally applied similar incentives when writing closed-source software, it hasn't been due to financial or most other incentives, because there really aren't any. In fact, one of the reasons I was attracted (back) to OSS development is that I could continue to apply my own sense of ethical software development while being able to gain some potential for financial reward for it (for a change), or at least while not being punished (say, by management) for doing things such as taking extra time to make sure the software works correctly and as documented.
(Not that there aren't all sorts of similarly bone-headed people in the OSS movement pushing for "gimme what I want now, you worry about making it work right later" from time to time. But I don't report to them. Besides, it's usually easier for the general public to see these sorts of discussions going on in OSS development than in closed-source development. That allows people to come to more informed conclusions regarding, e.g. the long-term viability of proposed extensions.)
Practice random senselessness and act kind of beautiful.
Microsoft does amazingly well when you stop to consider what the have to work with. Their code is probably very complex due to the requirements of backwards compatibility and interaction along unusal connections between types of software. They only have a comparatively small number of programmers to be working on it at a given time, and they get the hot seat as soon as there is a problem. Everyone in the business world simultaneously expects perfection and low quality from MS, so that they can bitch about something all the time. When you consider the strains they have to deal with, they are doing very well.
I work for IBM and Sun is one of our big competitors, so I can't really say anything without risking excessive personal bias. However, I suspect that people are less inclined to roast Sun for every security breach, as there are fewer personal users than either of the two other systems.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
Which brings me to an OT rant about small ISV's and (wait for it) open source:
;) Usually, the story goes like this:
:-)
The consulting company I work for (and many others) makes a lot of money fixing problems created by some dork who was too stupid to realize you can't start your own software company.
Dork writes app with some puny but vital business purpose (If unethical dork, insert "on customer's time" here.), invariably in a lame-ass tool that really should only be used to handle smallish recipe files.
Dork manages to sell to one big client where an in-law works.
Dork makes major release and generates marketing pamphlets for distro at industry trade shows, which promise that the app will have user docs and a real-database port Real Soon Now.
Meanwhile, the app really hasn't progressed beyond "almost alpha" at the one big client who is paying for "integration services".
Hapless company (my future client!) correctly decides that buy is better than build, but incorrectly assumes that there must be a decent package out there for this. Someone at hapless company randomly stumbles upon dork's marketing pamphlet or web site, and buys in.
Hapless company is promised by dork that software is ready to go, and the "integration services" should only last a month or so.
Fast forward six to eighteen months (depending on client IQ)...
Client has no system, or worse, has a crippled system and turned off or stopped paying for the old one, has spent hundreds of thousands on dork hours alone, has no docs on how to install, operate, or fix, has no source to allow me to fix or diagnose it for them, has no database schema (and often a dork-encrypted/proprietary database), is paying more thousands for staff to babysit and undo the misdeeds of the app, has dork saying that he can't spend any more time with them (assuming his number is still listed), etc.
Basically, the only good news is that hapless company didn't bring Andersen Consulting in to do the app
So, how would this have improved with Open Source?
Well, dork could have:
Had input on his app from client or consultant help,
Started a bit smaller before hapless company showed up,
Made continuous improvement to his app based on experiences at first big client,
Gotten paid the honest way, for development services, rather than for vaporware,
And eventually have built a user base big enough to handle the Hapless account smoothly.
Meanwhile (and, per RMS, more importantly), the client could have:
reviewed dork's code before betting the company on it,
brought in extra help that would really fix problems, not just clean up after them,
been assured that they could still improve the app after dork fled the country,
had a consultant provide necessary docs and schema,
and been part of a community of users that would work together to improve the app, whether dork was there to help or not.
Or, at least I've heard it could work this way...
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
I used to code at a small accounting software company - and saw the worst side of this issue. Starting with the totally irrational resistance of the luddite owners to posting patches on the web site, there was an economic disadvantage to releasing patches when another (due to city tax schedule releases) would be out a few weeks later - shipping 10,000 diskettes was a substantial cost for a small company. Add to this the understaffing of the testing department and tech support, and even the refusal of the owners to allow us to use point designations for patches (on the theory that it advertised how many time it took to get it right), and you can imagine the confusion and frustration. I don't (oh blasphemer!) think open source is the solution to every problem - but I'm sure that my prior employer wasn't the only sociopathic corporate greedhead torturing employee and customer alike. I gave them a lot of unsolicited legal advice (why I'm no longer working there ;-) - such as this - if a company knows of a material defect in their product and conceals such to the consumer, resulting in losses to the consumer - said greedheads are liable under the higher standards of gross-negligence, recklessness, or even intentional tort, resulting in statutory treble damages or unlimited punitive damages in some cicumstances. Of course it is common in the industry to hide bugs as long as possible, under the mistaken idea that quietly fixing the bug in a later release saves consumer goodwill by avoiding embarassment. Sometimes the lag between discovering a problem and coming up with an assured good fix is even justified. But maybe what we need is a good Pinto case - wherein the bean counters at Ford decided that the cost of adding an 8 cent plastic cap to a bolt in front of the gas tank was more than the projected number of immolation-deaths per year. Jury-award was a record at the time, nailing Ford for hundreds of millions in punitive damages to demonstrate the moral repugnance of such calculation. Something to think about, at least.
The article clearly focuses on plugging security holes, which is just a subset of the vast debugging space out there. Sure this may be the main concern of a sysadmin, but what about the 95% of us who do not have to admin for a living? Would security be our prime concern? Would an all-bugs comparison bring the same results?
Most bugs are just annoying, but some make you waste time, some lead to wrong results with varying consequences and some lead to data loss. I have never seen an advisory or a mailing list dealing with this kind of bug. I *know* there must be some, but the point is it's so easier to be informed about security gaps. Isn't anybody paying attention to overall quality or is this just a natural PR reaction to the known preference mainstream (even underground) media has for security holes, given its theft/trespass inviting nature?
It's easy to understand one's motivations to code, but we just debug because we *have* to. So, if these smaller bugs are something software can live with (mainly software planned to last only for a certain period), what would be the motivations for real debugging?
I am not saying that an intense debugging effort maens quality (maybe even the contrary is true), but if the only motivation to take corrective measures is pressure from consumers/clients who can have sensitive data compromised, then we will continue to use buggy software.
OTOH, when pride, reputation and commitment enter the scene, then we do our best to excel. So, my guess to the question in the first paragraph is that OS can have a response time orders of magnitude shorter than commercial products if we consider bugs in general, but that, if true, would be something hard to prove.
-------------------------
-------------------------
"People ask FAQs all the time". - David Allen
First, let me say this isn't a flame, troll bait non any disrespect to the open source community or Red Hat software, just my opinion.
:)
No offensive, but I don't think Red Hat is a fair repersentive of Open Source software, at least in this test here. The test is going to be on open source verus closed source in terms of "turn around" on bug fixes.
Linux/GNU which is what Red Hat is pushing, is not coded by Red Hat. It is made by out side developers and Red Hat only puts the product out. When Red Hat learns about a patch fix, they check it, package it and then up load it.
Case goes like this, a bug is found in Linux/GNU and people are informed for it. Some guru fixes the bug, posts it to ftp site. After awhile Red Hat finds the fix, reviews it, packages it, documents it, puts it on it's ftp then releases it, the announces the fix is avaiable.
The extra step of Red Hat doing this, is going to cost allot of time for the open source community. It should not count when the bug is found to when RH announces the fix, it should count from when the bug is found to when their is a working fix or work around anywhere in any form (even if it is source) on any ftp site.
Red Hat can only work with what the community gives them, say this
Day 1 - bug that opens a hole in program found in OSS
Day 2 - nothing
Day 3 - Maintainer and head programmer of XYZ announces a fix and uploads the source to ftp.
The problem is fixed, patch is avaiable to close the hole and fix the nasty bug is XYZ software.
Day 4 - nothing
Day 5 - Red Hat reviews the code
Day 6 - Red Hat tests the code
Day 7 - Red Hat packages the code
Day 8 - Red Hat documents the code and uploads it to ftp
Day 9 - Red Hat announces there is a fix avaiable for Red Hat users that are using XYZ software.
Now, yes, I know this is REALLY dramatic, but I am trying to make a point. (BTW, I got some REALLY good fishing stories). Anyway, I haven't seen a bug in a RH last more than 3-4 days at the very most (then again I don't use RH), but time of fix, to time of RH announces a fix, can be, and is drawen out. This could impact the study some what.
Neither a-less I still know Red Hat is going to kick MS ass at bug fix turn arounds, but the point it, raw OSS could do it faster and better than RH ever could. But the packages are allot nicer with RH
Again this is not a flame and I don't mean any disrespect to anyone.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
Sometimes I wonder how many closed source bugs have been known before the bulletin/news went public, with the fix withheld until there was a known "problem". Which can make the response time seem really nice if you're just holding onto the bugfix and releasing at the right moment.
And I'll still wonder what's with the legalese every bulletin has about "no known people being affected" by the security bug.
zlxiss
Not to mention that Windows "security" has been notably poor about keeping people out of where they should be... you want to delete kernel32.dll or add some extra bytes to ifshlp.sys - it may ask you, are you sure, but it lets you do them... not too great.
2k is supposed to have some provisions for not allowing other random progs to overwite dll in system/system32 (which would be nice) - every random Joe Blow app should *NOT* replace system-wide dll s. Ever. Even MS Office (are you listening, chief of software architecture??
Imagine installing BitchX or XAmp and having them overwite parts of QTLibs, Xlibs, and why not, glibc... our versions *have* to be better, right?
Oh well...
"It's tough to be bilingual when you get hit in the head."
Don't be too quick to judge based on the statistics Security Focus gave:
Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.
After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.
I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).
John Wiltshire
Fear: When you see B8 00 4C CD 21 and know what it means
Important bugs in important software will be fixed just about as quickly in either system: the 5 key people who know the source behave more or less the same way in open or closed source situations. It's the vastly larger number that matter to most developers. And, as more and more developers realize this and enjoy more working on open source, it won't matter what the other guys think.
Didja read the article? I know it was /.'ed -- I waited a longish time for it -- but it addressed the quality-of-fix issue pretty well.
BTW, while I don't know for sure whether you're right that many OSS projects don't regression-test such fixes first, I do know the ones I've worked on could stand some improvement...and also that it's a bit easier to regression-test a fix to a small component than a large one, and that OSS thrives on collections of small components in a way Closed Source $$$-making development doesn't (the latter favors the development of monoliths, since they represent a harder-to-reverse-engineer, and therefore steeper, wall for competitors to climb).
Also, the article made mention of various Microsoft-issued "fixes" that, themselves, had to be fixed. Didn't mention that happening with GCC, though it has happened there (not security fixes AFAIK, but the same principle applies), but the implication was that the most heavily-funded closed-source-development organization in the world doesn't seem to do to well producing correct fixes in the first place.
Practice random senselessness and act kind of beautiful.
Taco, How can you find this information interesting while refusing to release the slashdot source via CVS and following the OpenSource model which so many other applications use.
/. source.
/. bugfixes is more interesting perhaps?
Your comment says "interesting" while you still remain uninterested in your user's demands to Open the
Slow
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
I think I'd like to point Slashdot readers to a wonderful book: The UNIX Philosophy by Mike Gancarz. This book explains the tenets and values that traditional UNIX programmers have held. It goes on to list the 9 most primary tenets:
As you probably guessed, Open Source _pushes_ Tenet 6 to the forefront. Let others use your code!
Along with those primary, religiously-followed tenets, 10 lesser tenets are typically followed:
The book also mentions something very important: The Three Systems of Man. Software goes through the First system, the "innovative" cycle where one or only a few develop something revolutionary, to the Second system, where committees are formed for the software so more people can feel they're worth something contributing to the idea, and the Third system, where experts who left the scene during the 2nd stage come back to implement the idea, now that the obvious solution for it is well-known and has been walked many times.
CREDITS: This posting contains lots of quotations from, of course, the book: The UNIX Philosophy by Mike Gancarz, Copyright 1995 Butterworth-Heinemann. ISBN 1-55558-123-4 ... about $19.95. Well worth the money.
People calm down. We have our best perl coders here slaving over the Slash release. Patrick, Rob, and Pater are trying to convert their undocumented code and database schema into something that can be installed on other machines besides this one. The Slash code really is hardcoded in many ways and they are trying to unhardcode it for you now now. But they very much appreciate your flames so please keep 'em coming. =)
there seems to be a rather vocal fundamentalist open source community here on /.
Yeah, I've noticed that too. It's funny, you get the same kind of thing on Freshmeat.net, with all these open source programs for download. Strange stuff.
These people generally cite certain prime examples to support their arguments.
And we all know THAT is a really dumb way to support arguements. Better to just yell and scream.
Although Linux is a stable and it's security holes are filled quickly,
This seems to be in direct contention with your subject.
I don't think that there are any hugely successful pieces of open source software
This one is way too easy. I'm starting to think this whole post is sarcastic and you actually support linux. Either way, find a more popular web server than Apache (suprise, open source). Seems PERL is pretty open, as is sendmail. I'm not sure what you mean by a monopoly when refering to the latter.
I don't work for free, I have to pay bills. Infact, I'm quite happy to be paid a lot of money for what I do.
Hey, we are all happy for you, now when are you going to get to the part about "Open Source doesn't always == faster bug fixes", or was this just a clever way to repeat the tired "open source cannot make money" monologue?
Finkployd
Bill Gates: "Innovation"
Sure, open source can get bug fixes out there faster... but its not like for most open source projects anyone is going out and regression testing the fixes against anything to make sure nothing else is broken by the fix, etc...
As far as speed goes, big deal... give me a fix that works.
DrLunch.com The site that tells you what's for lunch!
Redhat is kinda slow at getting out the official fix. For example, the linux kernel is at 2.2.14 but Redhat has not put out a official rmp yet even though 2.2.14 contains a bunch of fixes
Red Hat has actually released several 2.2.14 RPMs in Raw Hide, our more experimental version. If you want to be on the bleeding edge, use that.
Also, check the source RPM for Red Hat's 2.2.13 kernel - it already contains a number of the fixes that later made it into the official 2.2.14 kernel.
We don't put out errata RPMs for every minor bug (misspelled man pages and such); this stuff gets fixed in Raw Hide and then makes it into the next release.
Errata RPMs are released only when they fix a MAJOR bug, such as a security problem (such as the bind update currently available) or a real functionality problem (such as the lynx update).
Releasing them for every minor problem, or every base version update, would be a bad idea because it would be very hard to keep track of everything. (And of course it would lead to "You need to update 1500 packages before Red Hat Linux works well" FUD from Microsoft and other people who don't care to check what an update does before writing flames).
This message is provided under the terms outlined at http://www.bero.org/terms.html
The assumption was that bee wings act like airplane wings. Uner those assumptions, a bee would not be able to fly. Somewhat more recently it was shown that bee wings do not work the same as airplane (or ornithoper) wings. Aside from the flapping thing, there's a basic modal difference.
Airplane and ornithopter (and bird?) wings work on laminar airflow. Try 'too hard' to fly, and you get turbulence above the wing. In other words, a stall.
The bee has a different method of dealing with this. Rather than prevent turbulence, the bee wing uses turbulence, and has a machanism for continually spinning the turbulent vortices off of the wing. In this flight mode, a given size wing has much as 50X more effective lift than in laminar mode.
I'm not sure we can apply this to the whole Linux vs Microsoft thing, other than to say that a new modality changes the whole landscape. But I guess that's what Open Source is all about. In this case, we're the bee.
The living have better things to do than to continue hating the dead.