Mozilla's Firefox Patches Have Same Lifespan as a Mosquito
Scientists at the University of Waterloo have released an intriguing case study about the "secret life" of Firefox patches.
Specifically, the paper sheds light on the submission and approval process prior to the introduction of the Firefox rapid release process and after. The lifespan findings are among the interesting data that was published and shows that the rapid release process has its advantages, despite the criticism.
The lifespan of a patch, which defines the time of submission to a status of landed, abandoned, or resubmitted has been 3.7 days or, according to Mozilla evangelist Paul Rouget, about the same as the lifespan of a common mosquito. For patches that actually landed in Firefox, the lifespan was 4.5 days before the rapid release process and 2.7 days after (for core developers). For cases of abandoned patches, the time span increased to 31.2 days (before) and 11.1 days (after), while resubmissions are listed with 3.8 (before) versus 2.5 days (after).
The review concluded that the review of patches has accelerated by about 34 percent following the introduction of the rapid release process.
The scientists said that their investigation was based on the review of the 1-year time frame prior to the rapid release process and one year after with 6,491 and 4,897 patches, respectively.
Yes, because Safari is sooooooo awesome. Good one, iMoron.
Because retarded users dont use linux......
Yes, because Safari is sooooooo awesome. Good one, iMoron.
LOL @ anyone who defends that "Mac OSX and Linux can't get infected" stuff.
BTW what was the point of this study? I think that if a patch can be released in 4 days, that's great and needs to be carried on. Well done, Mozilla.
Because retarded users dont use linux......
What are you suggesting to leave an exploit/security hole open longer like other browsers?? Come on.
What the patch in this study refers to?
It's also quite secure because it has tens of thousands of developers examining the source code and patching bugs, and have been for decades.
Nothing can protect a system from a stupid user that grants a malicious process root privileges, or from bad software that has root and can be exploited. Linux just has a sturdier foundation to start from than other operating systems.
First of all, nobody is saying this is a bad thing. They're saying it's good, because patch turn-around time is lower.
Second, the "fix it now at all costs" strategy is the worst possible way bugs can be addressed. Trying to fix something before it's fully understood often does more harm than good, introducing other bugs or addressing symptoms and hiding the real problem.
For example, I ran into a situation much like this yesterday. A critical bug was discovered in a piece of software I work on. We got together immediately, discussed what was happening and decided on a plan of attack. Within 30 minutes, we had a fix for the bug. However, we spent the next couple hours validating and verifying our assumptions.
The risk of keeping a well understood problem around a little while longer is very small. The risk of deploying something you don't understand is very large.
Now imagine ANY other industry had that many product recalls :-)
It is quite amazing what Software companies are getting away with.
but unlike recalls, software patches can be done proactively.. they find the error and want to fix it...
auto companies do them reactively seeing the cost benefit of doing recall over lawsuits and fines
I'm sorry but this is a poor analogy. For instance, does patching your software give you the same headaches a car recall would? Not to mention these are two completely different universes with completely different problems and challenges.
The end result was that the car gradually became better and better; the first ones were good, and perfectly usable cars, but the latter ones had slightly better handling and were a bit safer, had better mileage, and when older, would have less rattling pieces all around. It was pretty much the same car at the beginning and at the end, with the same qualities and failings - but the former were improved and the latter smoothed.
Japanese car makers were very, very good at it - US car makers much less so, preferring to get a completely new model out once every couple of years.
Now, compare Firefox or Chrome to Internet Explorer: IE typically is slightly above the competition when it gets out, is caught up with in a matter of weeks, and is left in the dust 6 months later - and you have to wait for an extra 18 months to get the new one.
Having taken part to the IE9 beta program (bug reports etc.) I can tell you that Microsoft's turnaround on fixes, even on software which isn't out yet, is the crappiest of all browser makers out there: it took from 2 to 7 months for a bug report, complete with reproduction steps, to be acknowledged, and it was 50/50 between a WONTFIX resolution and a fix.
Compared to that, Mozilla is a dream to work with.
True.
But it shouldn't apply here, given that Firefox is free.
This is a great analogy. It's about time that we require certification to practice software development professionally. It would render software production companies liable for the software they produce - despite ridiculous EULAs and disclaimers which rarely hold up in court as it is - in addition to injecting a much-needed shot of ethics into an industry that is very sorely lacking.
All that said, Firefox needs to gather its senses and come up with production plans that don't require a hundred band-aid stopgap fixes. They are like a kid doing paper mache - adding more code doesn't translate to an improved product.