Slashdot Mirror
Another Look At Mozilla's BugFix Rate
An anonymous reader writes "Washingtonpost.com's Security Fix blog has published the results of a look back at three years worth of critical patches from Mozilla, and found that Mozilla typically ships updates for critical flaws in about three weeks, though in more than a third of the cases it pushed out a fix in ten days or less. The data comes just a few weeks after The Post published data from a similar study that found Microsoft averaged 130+ days to fix critical flaws. Slashdot also covered that study in a previous post."
While it's important to fix bugs quickly and correctly, perhaps the Mozilla project should take some initiative within the open source community to work on preventing security issues in the first place. They could partner with the OpenBSD project on such an initiative, for instance.
Together they could come up with a development system that focuses on writing solid code. Such a methodology won't prevent all security bugs by any means, but it could go a long way towards vastly increasing the quality of the Mozilla project's software.
Cyric Zndovzny at your service.
Ok, I guess three weeks can be counted in hours, but that's a LOT of hours.
If you need web hosting, you could do worse than here
Funny. IMHO, the speed of the browser peaked a long time ago (0.8 IIRC), and now it's just getting progressively slower over time.
They might be fixing critical security bugs, but they certainly don't seem to be fixing memleaks and such.
"Mod, mod, mod...and another troll bites the dust."
In fairness, everything that I've read about MS's patch cycle indicates that it is a pretty huge undertaking. Joel from http://joelonsoftware.com/ is always going on about have every single code fix/feature addition has to go through a whole bunch of people (several testers, documentation team, etc) before it can be released. If anything maybe Microsoft is a bit too thorough with their patches, in some ways at least.
No problem, they just made the shovels REALLY HEAVY, so they only had to make a few of them.
Software metrics are very slippery things.
To be fair, Microsoft's flaws are alot more serious, so it's only logical they will take longer to fix.
<laugh\>
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
I'd love if Firefox didn't take up 256 megs of ram with 5 tabs open. Is that something we can get fixed soon? That'd be great. All I want is for Firefox to take less memory than Azureus. I only have adblock and bugmenot, so it's not extensions causing the problem.
Not a Twitter sockpuppet... but I wish I was.
Because they chose to weld IE to the OS, they have more difficulty with patching (and the vulnerabilities become OS vulnerabilities).
If they had maintained a rigid distinction between OS & apps, they wouldn't have those problems.
This was predicted back when MS first "integrated" their browser.
I'm not a statistician, but the average is sometimes a poor way to describe data. It's often useful to look at modes, standard deviations, and so on.
For example, the standard deviation for 2005 had Microsoft with a 80.87 stdev and Firefox with a 97.5 stdev.
Firefox had one flaw that took 674 days to fix, nearly twice the max of Microsoft's 357 days. Does that make up for such a larger average? Dunno. I suppose you could look at the issue and decide for yourself.
Averages are important, but it's not always the single most important thing to consider.
Skimming through the previous Slashdot story, it looks like the Microsoft vulnerabilities covered both the OS and IE, not just IE. Mozzilla, afaik, only does the browsing and mail programs.
Granted, that's no small task, but it still isn't on the level of fixing an O.S., in my opinion. It's like comparing apples and pumpkins.
It would be better to compare Windows patch release time with Linux patch release time, which I believe has been done before (and then covered on Slashdot- Linux probably had the shorter time.)
Regardless, how much does market share factor into this? With Linux, if a patch breaks a program, most people can just shrug it off and rewrite the program to work with the patch. So mass testing isn't as big of an issue. With Windows, if a patch breaks a program, a user doesn't have a lot they can do except to sit there and weep until Company X releases their own patch or next version.
I used to think it was just poor management, but now you have open source projects with thousands of eyes looking at every line of code.
IMHO, I believe that the reason why is because most of the developers are looking "at the edges" - where new functionality is being added. For example, how many of those developers are looking at the JPEG decompress routine? Turns out that wound up being important exploit-wise recently. And there it sat for years, unnoticed.
from what I remember in taking computer science, if you follow some simple procedures, the code is robust.
Well, robust doesn't just come from simple procedures. It's also design and style. You can't come up with excellent procedures and guarantee good software. You have to design well, communicate well, and implement ideas correctly. A lot is also owed to experience - sometimes, the only way to find out you've screwed up is after the fact. A good example is strcpy(). We know unbounded copy is a bad idea now, but how many years went by before we did?
Weaselmancer
rediculous.
Yes, and we all know that the dawn of time occurred precisely at midnight (GMT) on January 1, 1970. While it's rumored that time existed prior to then, there is no evidence for it in the syslogs.
John
However, other bugs simply aren't fixed. For about 3 years many, many people have reported the CPU hogging bug which is unique to Firefox and Mozilla browsers. For a small example of the reports of problems see Firefox is the most unstable program in common use.
Now the problems are beginning to be reported in technical magazines, newsletters, bloggers, and even the mainstream media.
Under the conditions mentioned in the bug reports, I'm not able to make the CPU hogging bug fail; it is always there. I've tried Linux, Windows XP SP2, and Windows 98 SE. I've tried Intel and Via chipset motherboards. For about 3 years, in all versions, the CPU and memory hogging bug has always been there. Firefox version 1.5.0.1 is worse than Firefox version 1.5, and those versions are worse than earlier ones. This is with a clean profile and no extensions except DOM Inspector, which is a menu choice on the installation program.
In 3 years, I've never had any evidence that any Firefox or Mozilla developer has reproduced the conditions that cause the problem.
The problem with Firefox and Mozilla developers not fixing difficult bugs seems to be a social one, not primarily a technical one. The developers keep asking for the problem to be made easier, but it appears to me that there is already plenty of evidence that would allow further investigation.
Perhaps the developers do not understand that there is a class of bugs that can only be found using the methods of scientific research. Many people like programming, but only people who accept the biggest challenges truly have programming in their hearts and minds:
Three biggest challenges of programming
Here are programming's three biggest challenges. Coding is relatively easy. It is these challenges which separate a true professional from an average programmer:
Instead there are excuses:
Mozilla Top 12 Excuses
Top 12 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 3 years: