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.
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."
Has anyone collected similar data regarding Opera, OmniWeb, Safari, and other alternative browsers?
If so, how do they compare to Mozilla and Internet Explorer in not only the time it takes to address security problems, but also in terms of the number of incidents per release?
Cyric Zndovzny at your service.
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.
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.
That bug has existed for several years now and has not been fixed. Hardly offtopic...
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.
> 1. Maybe this bug is fixed in the nightly build.
It usually is. The yahoo.com crashes in 1.5 were one prime example - they were already fixed on both the MOZILLA_1_8_BRANCH and the MOZILLA_1_8_0_BRANCH.
> 2. Yes, this bug exists, but other things are more important.
While this is a rather contentious thing to say, it's usually true - there often _are_ bugs that are more important, and very little (except getting more people to hack Firefox and fix the unglamourous bugs) is going to change that.
> 3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
This is rare - TalkBack usually runs for most crashes, and for ones that don't generate a report, someone can usually apply some debugger-fu to make it happen.
> 4. If you would just give us more information, we would fix this bug.
This is an excuse?
> 5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
So? If you're reporting more than one bug in a single report, then it gets much harder to fix each of them. Separate bugs, separate reports - that's the way Bugzilla works.
> 6. You are using Firefox in a way that would crash any software. [But the same use does not crash Opera.]
Can you give an example?
> 7. I don't like the way you worded your report. (So, I didn't read it or think about it.)
If the bug report is crap, who's going to read it? Bugs don't get fixed if you can't properly explain what the bug is.
> 8. You should run a debugger and find what causes this problem yourself. (Then when you have done most of the work, tell us what causes the problem, and we may fix it.)
Why is this a Bad Thing? Some users are more than happy to do this - I personally haven't seen more than a few bugs in Bugzilla where this was even requested.
> 9. Many bugs that are filed aren't important to 99.99% of the users.
Sad, but sometimes, true.
> 10. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week.]
This sort of thing is subjective.
> 11. Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site.]
Advertisement on website != Well-written.
> 12. Your problem is probably caused a corrupt profile.
This is almost always the primary, major source of just about all of the problems experienced by most users. That's why there's been so much effort with mechanisms like the Extension Manager modifications, the extension versioning mechanism, the bookmarks-backup code, and the general depreciation of profiles in order to prevent users from misusing them and potentially breaking their Firefox installation.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
I am a programmer of the type you describe, I actually love debugging, its alot of fun to apply the scientific method to code...
And I was intrigued by the bug you mentioned, as it seems like it would be great fun to figure out. I have never had any stability issues with firefox (any version), and I am a pretty heavy user, 8 tabs open right now, and thats really light usage for me. Normally I'll have 2-3 windows with 10-15 tabs each... I tried to use the gnu libc page, I opened 20 tabs of it, and yeah firefox was using quite a bit of RAM (about 35MB per tab), but I opened 10 windows if IE to that page and each IE window was using 45MB of RAM... so firefox was 10MB per page better as far as RAM usage is concerned... Firefox used more CPU each time I opened a new tab, but also rendered each new page faster than IE, which used less CPU for a longer period of time... I am running Win XP SP2 all patches applied, Firefox 1.5...
The only time I've seen firefox die has been on pages with that really annoying smiley face animated GIF or flash I don't know which banner ad. However, that is not the bug you are describing, so they are most likely not related... and I haven't had that bug crash FF since 1.5 came out. In fact I haven't had FF crash at all since 1.5 was released...
In short if you are having a problem, and people can't recreate it, the only option really is to attach a debugger and get to the bottom of the problem that way. As I explained above I tried to recreate your bug, I'm actually trying it on a 3rd computer right now (Dell latitude d810 512mb ram, white box winxp sp2 1gb ram, mac os 10.3 512MB ram powerbook) none of these computers exhibit the problem.. I would love to help, show me how to recreate it, and I'll gladly try to figure it out.
I understand this, but I don't think it changes my point. That kind of complexity can be solved with asking "what are all possible inputs" and "what are all possible outputs"?
What you're talking about is one of the oldest pieces of programming advice ever: never trust input. One of the most common human cognitive failings is to focus on intended outcomes (in this case processing valid data) and not focusing on unintended outcomes (having to handle invalid data). Probably 90% of the bugs in the world would go away if people took this very old advice.
But it isn't that simple.
Software is the product of social institutions. The culture of these institutions, the structures of rewards, the character of the people they attract are a huge influence. In a nutshell: broken organizations produce broken software. You may know that taking an extra week to design your input routines is the right thing to do, but it may not be the answer that is acceptable to the person you work for, and the aggregate sum of doing all the things that are right to do is nearly certain to be unacceptable at some level. In that sense, many bugs are like pollution: you take a problem you have right now, and make somebody else pay for it later. Often that person is your future self.
Secondly, you can't really consider "every possible input". A mere stream of eight bytes has 2^64 possible values, but is not enough to contain the smallest possible HTTP transaction.
Naturally, what you do is break inputs up into categories or sets. But this process itself is fraught with error. There was an academic vogue a few years back for "provably correct software". The idea was to create a detailed specification, then use a mathematical proof to show that a given program implemented that specification. The reason it didn't take the world of professional programmers by storm is that the proof itself, indeed the specification itself, are nearly complex as the program and susceptible to their own errors.
Which leads us to the last item: your specification. IF your specification doesn't meet the real needs of your user, now and forever more, it will be perceived by the user as a bug.
That said, it's really our dsyfunctional development organizations that are the biggest source of bugs. When we build the perfect society, or at least a perfect piece of a society, then we'll be able to eliminate the largest source of bugs.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The trolling that you're doing is not saying bad things about Mozilla and Firefox. It's about two programs that do nearly the same thing in the same situation, then claiming one has serious stability problems, while the other exhibits no problems of that nature. As others point out, they cannot reproduce any sort of problem in Firefox with your demonstration.
If you ever do figure out how to demonstrate some serious problem in Firefox, be sure to let us know, and we can help get it fixed. Until then, no amount of ranting is going to help; it's likely to just get you ignored.
What a fool believes, he sees, no wise man has the power to reason away.