Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Mozilla The Internet Bug

Another Look At Mozilla's BugFix Rate 174

Posted by Zonk from the must-go-faster dept.
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."
This discussion has been archived. No new comments can be posted.

Another Look At Mozilla's BugFix Rate More

Another Look At Mozilla's BugFix Rate

Comments Filter:

  • Just one previous post? (Score:3, Funny)

    by Jugalator ( 259273 ) on Tuesday February 07, 2006 @12:51PM (#14661022) Journal
    Maybe it's just imagination, but I thought I've been reading these kind of stories on Slashdot since the dawn of time.

  • Let's work on preventing bugs. (Score:4, Insightful)

    by CyricZ ( 887944 ) on Tuesday February 07, 2006 @12:52PM (#14661033)
    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.

    • There was an initiative back at the end of Netscape's browser team. Each component was tasked with going through a security review. Now sure how much of that lived beyond that.

      --
      Q

  • So much for "fixed within hours" (Score:4, Funny)

    by man_of_mr_e ( 217855 ) on Tuesday February 07, 2006 @12:52PM (#14661039)
    Ok, I guess three weeks can be counted in hours, but that's a LOT of hours.

  • "from the must-go-faster dept." (Score:5, Insightful)

    by Cutriss ( 262920 ) on Tuesday February 07, 2006 @12:53PM (#14661047) Homepage
    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.
    • There was a very interesting post here earlier regarding the attitude of the Firefox developers towards memory consumption. I invite you to read it for yourself:

      http://it.slashdot.org/comments.pl?sid=176459&cid= 14655214 [slashdot.org]

      The last paragraph is perhaps the most telling. It is apparently felt that issues such as memory consumption just don't matter to the average user. Of course, that's a very incorrect assertion to make. When even a normal user finds that Firefox has consumed 400+ MB of their 512 MB of RAM
      • Have people really had problems with Firefox showing a memory leak? The worst I've seen with half a dozen tabs open is probably around 75 megabytes, which is still better than I get with 6 IE windows open at 25+ megs each. 400 sounds beyond ridiculous.
        • I thought it was bunk at first too, but I just checked and with only three firefox (1.5) windows open, including this one, it's using 90MB on my system. That seems a bit excessive for a web browser.

          I'm going to start watching this thing. There are times when I'm working in Photoshop or Illustrator when I have to start shutting things down to free up memory. I never really bothered to close out browsers though because I didn't think they'd use much.
        • I used to leave Mozilla Suite, and older Firefox open for weeks on end without issue, but now, after some normal usage, every 2-3 days Firefox will reach 400MB easily. Closing Firefox always throws it into a 99.9% CPU usage for quite a while, and it will eventually finish and terminate on its own, but I just get fed up and kill it from task manager because I want to restart it right away. The responsiveness really suffers when the memory usage goes up, but it is not because of swapping, since I have 1024MB
        • Firefox frequently goes on a memory eating binge for me. I've not strongly blamed Firefox in the past because I usually have about a dozen extensions loaded up, and so I've never had direct evidence that it's Firefox's fault vs. one of the extensions.

          I do think it's related to the pages I visit -- for example, I notice it more after browsing a dozen photoshop forums on Fark. And a simple shutdown/startup does clean it up, of course.

          I had thought it was PDF related, so I installed the PDF Download exte

        • I've actually found the latest Firefox (v1.5.0.1) to be very very gentle with my memory. After opening BBC News, Slashdot, Digg, MSN.com and Google in tabs both FF and Opera 9 TP2 I've found that FF uses approximately 35MB in RAM and 35MB 'VM size' compared to about 40-55MB in RAM for Opera and 70MB 'VM size'.

          I couldn't believe it (I am a die hard Opera 'fanboy', although all things said Opera still wins hands down in terms of rendering performance, application startup time and general UI responsiveness).

          On
          • In addition and for completeness, I don't use the standard Firefox theme (I use Littlefox, Breeze or any other nice 'Compact' themes going) and have only the "Tab X" (adds an x to all your tabs like in Opera) and FasterFox (tweaks rendering settings) extensions installed. Although i'm not claiming this is the reason I get low memory usage, it probably helps a bit (lack of huge # of extensions and graphics).

            IMHO it seems to vary alot from system to system on how well that naughty fox behaves.

      • Re:"from the must-go-faster dept." (Score:5, Informative)

        by bdaehlie ( 537484 ) on Tuesday February 07, 2006 @01:53PM (#14661713) Homepage
        The Mozilla developers spend quite a bit of time on reducing memory usage and leaks [squarefree.com]. The issue is taken very seriously. All I said was that leaks exist, and that they don't indicate that Mozilla's entire codebase is sloppy. That doesn't mean Mozilla developers aren't doing anything about them or they think they are OK.

        CyricZ, please stop trying to get attention by being dramatic and twisting words. Your criticism is not contructive, just uninformed and inflamatory. [slashdot.org]

        P.S. Re: "the attitude of the Firefox developers" - I am only one Firefox developer. I am not speaking for any other devs.
      • When even a normal user finds that Firefox has consumed 400+ MB of their 512 MB of RAM,

        Buy more RAM! ;)

      • Such a carelessness towards memory consumption would also suggest a similar lack of interest in writing code that is secure


        That, I think, is wrong. Finite resources mean setting priorities. If you set hardware conservation above all else, it will come at a cost to conceptual integrity, security, usability, etc.
    • I agree - 0.8 was the point at which I started to use Firefox as my main browser. Since then though, I can't think of much that they've added that's been a major improvement to me, and I just became fed up with memory leaks and slow performance.

      I now use Opera, and I'm extremely happy with it. That's not to say I wouldn't go back to Firefox permanently if they make further improvements, but I haven't really seen too much in recent releases.

    • While, memory leaks have not necessarily always been the priority of Firefox's developers, it is on their radar screen and something that they recently are putting more of a focus on. A tool was developed to allow people to test for leaks and report leaks in a manner that has allowed devs to actually do something about it. Whinning that you have a bunch of tabs open and a lot of RAM is being used does not usually help a dev make a change.

      Already 1.5.0.1 has incorporated two memory leak fixes and more are
      • How do I use that javascript version [mozilla.org] of the tool under Windows Firefox 1.5.0.1?
        I created a .cmd file with

        @echo off
        set NSPR_LOG_MODULES=DOMLeak:5,DocumentLeak:5,nsDocShe llLeak:5
        set NSPR_LOG_FILE=C:\Documents and Settings\ME\Desktop\nspr.log
        cd "C:\Program Files\Mozilla Firefox"
        start firefox.exe

        But npsr.log is always 0 bytes when I close or kill Firefox.

  • What about Opera, Safari, OmniWeb, etc? (Score:3, Insightful)

    by CyricZ ( 887944 ) on Tuesday February 07, 2006 @12:54PM (#14661061)
    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?

    • "Today's post marks the second in what I hope will be a series of similar analyses. " He's got a link to a meta-study from CMU in that article too.

  • MS Release Cycle (Score:5, Insightful)

    by Azarael ( 896715 ) on Tuesday February 07, 2006 @12:56PM (#14661091) Homepage
    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/ [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 is certainly true, MS's slow patch cycle probably applies to other products as well though. Bureaucracy and coupled design probably are the two big problems that they have to deal with.
      • Can you explain/justify this?

        The problem is that the regression testbed for IE is "everything". every website ever, and almost every windows app that uses HTML rendering (which is about all of them). What you define as "welded to the OS" is irrelevant - IE's "welding" to the OS is more or less "the HTML renderer and transport layers are available as shared libraries, and are used in a few spots".

        It's no more severe than a fix being made to glibc - except that windows users expect software to keep running
        • linux users put up with recompiling everyhing if the fix "requires" it

          Not all linux users are on gentoo. When was the last time you recompiled your entire system because of glibc fixes? I haven't had to do that once in 9 years of using GNU/linux.

          except that windows users expect software to keep running no matter what

          That has to be the funniest thing I read all day.
          • Not all linux users are on gentoo. When was the last time you recompiled your entire system because of glibc fixes? I haven't had to do that once in 9 years of using GNU/linux.

            Never.

            I stopped using linux for anything meaningful prior to glibc being widely used - my last linux machine still had libc.4.so and libc5.so on it. I "survived" the a.out->elf transition, etc. That is of course an exceptional case, but it illustrates the "either rebuild world, or take an entire new binary set (from a new version
            • Re a.out -> ELF and similar ancient stories. What can I say, you have a point. But then, every fricking DOS app needed its own printer driver, but do you hit WinXP over the head because of that?

              there have certainly been library patches for freeware unix systems that have required significant rebuilding-from-sources, or installing-over your machine with a newer vendor supplied binary set.

              Certainly "there have been". Probably on some special-case distro with 50 users. But I still haven't seen such a thing
    • If anything maybe Microsoft is a bit too thorough with their patches, in some ways at least.

      Perhaps the reason for this is that everything in Windows is so grotesquely interdependent that MS is forced to do a full regression test on the entire OS for every little fix. When's the last time replacing your windshield wipers caused your car not to start up?

  • It's just numerology. (Score:5, Interesting)

    by Ancient_Hacker ( 751168 ) on Tuesday February 07, 2006 @12:57PM (#14661098)
    Kinda reminds me of story about the Soviet shovel factory that was given a quota to ship 500 tons of shovels per month.

    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.

  • Be Fair (Score:5, Funny)

    by XMilkProject ( 935232 ) on Tuesday February 07, 2006 @12:57PM (#14661102) Homepage
    To be fair, Microsoft's flaws are alot more serious, so it's only logical they will take longer to fix.

    <laugh\>
  • While I hope that this will encourage the average person to download Mozilla, I think that the person who might be swaded by this is already infected and doesn't know/understand what is to be gained.

  • A bug ignored? (Score:4, Interesting)

    by WhatAmIDoingHere ( 742870 ) * <sexwithanimals@gmail.com> on Tuesday February 07, 2006 @01:00PM (#14661122) Homepage
    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.
    • My Firefox 1.5 with 5 Tabs open is only using 84,740k. Azureus on my machine (5 active downloads, 3 seeds) is using 72,912k if I count the running java process. I don't think that's too bad in either case.

      Now, Firefox with three or four HUNDRED open tabs is kind of beastly, but then, what else was I going to do with that second gigabyte of RAM, anyway?
      • Please don't mislead yourself. Neither program's memory consumption is reasonable, especially when you consider what each program does. Either way, the cause is the same: poorly architectured software. Java and Mozilla both involve far too much bloat.

        Many of us who were developing software in the 1970s, and even up until the mid-1990s, are quite horrified at how poorly software today manages memory. Whatever gains have been made in terms of increased memory capacity are quickly lost due to a subsequent decr
        • Do you really mean to claim that Firefox doesn't do GC? At all? Because that's what I would call "untrue."
          • I'm well aware that Mozilla supports the Boehm garbage collector, in addition to various other memory allocators. The fact remains that none work as well as the garbage collectors offered by most production-quality LISP and Smalltalk implementations. Then again, that's partially because of C++ being so fundamentally different from other languages, to the extent where it isn't an easy task to write a solid garbage collector for it.

      • I'm downloading one thing with Azureus, and it's using 139 megs of ram. If I get fancy and try to download 5+ things at the same time, it can hit 500 megs.
    • My Firefox process is presently running 13 tabs in 2 different windows, most of which involve a plenthora of images (large-format webcomics) and even a little Flash here and there. It's only taking about 88 megs.

    • Re:A bug ignored? (Score:3, Interesting)

      by dylan_- ( 1661 )

      I only have adblock and bugmenot, so it's not extensions causing the problem.

      I think it must be adblock. I've heard so many people complaining about this, I wish one of them would try and narrow it down to a single cause. I have Firefox 1.5.0.1 on XP, with 26 tabs, over two windows, and my memory usage is at 130 MB. This includes several comics and sites with Java. I have All-in-One-Gestures, SessionSaver, undoclosetab and FLST as extensions. It's been running for about a week (I think that's the last

      • Re:A bug ignored? (Score:2, Interesting)

        by Devynn ( 948459 )
        I'm also running Firefox 1.5.0.1. I was only on this page, no other tabs open and had AdBlock installed. I was sitting at 100MB of memory used for Firefox. I went into extensions, Uninstalled AdBlock and restarted the browser. On this same page, Firefox is now only using 25MB of memory. That tells me right there that it's not the browser's code that has the problem, it's AdBlock's code with the memory leak.
      • How long firefox is running (and how much time of that is actually in use) is also a major factor in its memory leaks. I restarted firefox yesterday morning; right now it's taking up 113MB with 6 windows open (I don't use tabs). It was restarted because it was taking up over 500MB of memory after being left open for about 2 weeks; I don't remember how many windows were open, but I'm sure it was never more than 10 at once. And I just use it for normal html web browsing, with only a couple resource intensive
    • While some Mozilla developers may suggest otherwise, I doubt there is much that can be done to deal with such issues. The general architecture and code quality of Mozilla is so bad that fixing such issues would be a massive undertaking.

      One of the main indicators of over-engineering in the software world is a high level of memory consumption. Even without using an in-RAM cache, the memory usage of Mozilla is still excessive. A quick glance at the code or developers documentation will show you why: it's a poo
      • I'd switch to opera in a heart beat if I could use adblock with it.
      • While some Mozilla developers may suggest otherwise, I doubt there is much that can be done to deal with such issues. The general architecture and code quality of Mozilla is so bad that fixing such issues would be a massive undertaking.

        I've seen you repeatedly make this claim. Can you back it up with some examples? Perhaps a link to LXR showing some bad code?
      • Konqueror!?

        Right.

        Konqueror is slow as a dog on my system. And after only opening three of norways major newspapers (www.vg.no, www.dagbladet.no, www.aftenposten.no) this is the memory consumption:

        runevi 28997 21.3 6.4 157080 65476 ? S 20:36 0:09 konqueror [kdeinit] --silent

        Plus all the kio_http proocesses, of course. Why the fsck does konq need to fork out a dozen children just for http?

      • Opery, Konqueror et al. are nice, but what makes Firefox so great is the extensibility. What do you think made Winamp big? The skin support (i.e. absence of standard widgets and window decorations)? It was the fact that you could make it do pretty much everything if you had the right plugin. What I love about Firefox is not the fact that it's from Mozilla, it's things like Greasemonkey, Web Devloper, DownThemAll, Translation Panel, DictionarySearch, the Download Statusbar... The extensions are what makes Fi
    • The latest version of Adblock (ver 0.5.3.042) fixes memory leak issues. Firefox 1.5.0.1 also addresses at least two memory leak problems. After upgrading both Adblock and Firefox to the latest versions, I find the memory leak problems I suffered from before more or less resolved.

    • Re:A bug ignored? (Score:3, Informative)

      by Zathrus ( 232140 )
      I only have adblock and bugmenot, so it's not extensions causing the problem.

      No, it is extensions causing the problem. Specifically adblock. Adblock appears to be a horribly written piece of shit -- it leaks memory all over the damn place. Use Adblock Plus [mozdev.org] instead -- I think it still leaks memory a bit, but I can surf for several days without reloading Firefox and be at <200M usage, while I'd hit 400M with Adblock in a day.

      And I've actually added a couple extensions since switching to Adblock Plus, so if
    • What version of Firefox are you people using? I use Firefox all day with about 5-8 tabs open and it rarely, if ever, cracks the 80 meg barrier. If you have 256 megs of RAM consumed are you viewing a web page that loads a Java version of Linux and have 4 copies of it open?
    • wtf are you doing???
      11081 ***** 16 0 101m 39m 17m S 0.3 7.8 0:26.43 firefox-bin
      6 tabs open... FF 1.0.7 with adblock, noscript, foxytunes, bugmenot, imagezoom & flashblock... only 7.8% of 512MB... that's a paltry 40 Meg... sheesh, my first hard disk was 32Meg... wtf have we done since the good old dos 3.2 days...
  • There were cases when there was a security bug known for years but only got fixed after public disclosure. If you look at that way they are not better than Microsoft at all.

  • Don't just rely on averages (Score:4, Interesting)

    by PIPBoy3000 ( 619296 ) on Tuesday February 07, 2006 @01:11PM (#14661235)
    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 [mozilla.org] and decide for yourself.

    Averages are important, but it's not always the single most important thing to consider.
    • I suppose you could look at the issue and decide for yourself.

      Ok... *click*

      Sorry, links to Bugzilla from Slashdot are disabled.

      Ook! I suppose not.
    • You're quite right. The average for this dataset is essentially meaningless because the data is not normally distributed (Anderson Darling p-value is <0.005). Minitab says the critical issue resolution process might follow an exponential or gamma distribution.

      The median would be a better measure of the location of the "center" of this dataset.

      The median is: 18 days
      Lower bound of 95% confidence interval for median: 11.137
      Lower bound of 95% confidence interval for median: 21.621

      This means that you can be

  • Moderate Spin, but still embarassing. (Score:3, Interesting)

    by bmajik ( 96670 ) <matt@mattevans.org> on Tuesday February 07, 2006 @01:11PM (#14661236) Homepage Journal
    FTA: In recognition that 2004 was most likely the first year in which a significant share of the company's new user base was coming from Windows users, Security Fix based each of "date patch issued" date for 2004 and 2005 on the release date of the next product update that incorporated the fix for that critical security vulnerability -- not the date on which a fix was available to developers. For 2003 critical Mozilla flaws, Security Fix relied on the times listed in the "date fixed" field for each critical flaw listed on the "Older Vulnerabilities in Mozilla Products" page.

    So if you cut the days-to-fix time up by year, for 2004, the avg is 65 days. In 2003 they used the "fixed" date in the bug DB. For 2005, its 37 days, and for 2004/2005 combined, its 42 days.

    The 2004/2005 # is the interesting one, because that measures how long until the patch actually makes it into a shipping build. The availability date of source-code patches is irrelevant because most organizations are not equipped to deal with them; this is especially the case with firefox!

    None of this is an excuse, however. As an MS employee, the data on our speed of patch delivery is pretty upsetting - the numbers are much worse than I would have expected. They're so bad that I am suspicious and wonder if there isn't some deeper story somewhere, but in any case, I'd like to think the maximum time anyone would have to wait would be ~1 month (flaw reported on the wednesday after "patch tuesday"), but according to this data we're not hitting that at all. I can't speak for the IE or the MSRC teams but those numbers really appear to suck. Sorry about that, everyone :)

    • There's an analysis up at CMU (linked to in the WaPo article) which shows that closed source vendors as a group are slower at patching than open source ones.

  • Not really fair... (Score:5, Insightful)

    by RyoShin ( 610051 ) <tukaro AT gmail DOT com> on Tuesday February 07, 2006 @01:12PM (#14661250) Homepage Journal
    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.
    • Totally agree. Comparing a browser/email app bugfix rate to that of an integrated OS bugfix rate is rather disingenuous
    • it looks like the Microsoft vulnerabilities covered both the OS and IE, not just IE. Mozzilla, afaik, only does the browsing and mail programs.

      Except for one small fact: IE is part of (has been rolled into) the Microsoft kernel, according to Bill Gates and friends at the DOJ trial. Remember that faked video where they tried to prove it wasn't so?

      So any discussion of IE vunerabilities must of necessity include the Windows kernel. Countless are the times IE or Windows explorer crashed, only to bring down W

    • 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.

      Personally I would have thought that this was more a development model and documentation issue than a market share i

  • Difficult bugs simply aren't fixed. (Score:4, Interesting)

    by Futurepower(R) ( 558542 ) on Tuesday February 07, 2006 @02:05PM (#14661858) Homepage
    It does seem that security bugs in Mozilla and Firefox are fixed promptly.

    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 [slashdot.org].

    Now the problems are beginning to be reported in technical magazines [cmp.com], newsletters [scotsnewsletter.com], bloggers [slyerfox.com], 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:
    1. Being a scientist -- Often the most difficult programming is easier than the most difficult debugging. Often debugging requires creative scientific thinking. First, it is necessary to gather information. Second, make a theory that fits the facts. Third, design an experiment that tests the theory. Fourth, perform that experiment and analyze the results. Fifth, using the information that was learned, design a new theory, and repeat the steps above. The information that has been provided about Firefox instability is plenty to begin making theories.
    2. Skill in social interaction -- Often the social interaction necessary to understanding what is needed and wanted is more difficult than any coding challenge. Social skills can be learned, and are part of being a good programmer.
    3. Designing the user interface -- Only someone who has habits of caring for others can have the necessary detailed insight and creativity to discover how to do everything possible for the user.

    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:

    1. Maybe this bug is fixed in the nightly build.
    2. Yes, this bug exists, but other things are more important.
    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.]
    4. If you would just give us more information, we would fix this bug.
    5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    6. You are using Firefox in a way that would cras

    • Re:Difficult bugs simply aren't fixed. (Score:4, Insightful)

      by The One KEA ( 707661 ) on Tuesday February 07, 2006 @02:39PM (#14662282) Journal
      > 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.

    • Re:Difficult bugs simply aren't fixed. (Score:4, Insightful)

      by pavera ( 320634 ) on Tuesday February 07, 2006 @02:44PM (#14662344) Homepage Journal
      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.
      • When I have the CPU bug happen, it's usually after leaving FireFox open for a long period of time. It seems to be triggered by loading large files, such as many big images, flash files, videos, and the like. However, there have been times that I've left FF open (usually to Fark or Slashdot) while something is downloading overnight, only to hear my CPU fan kick into high gear as I'm drifting off to sleep.

        Part of the problem is that it doesn't seem to happen the same way each time. Even if I revisit something
        • The memory/CPU hog is the biggest and most blatent issue of FireFox, and nothing else should be done until the problem is at least identified.

          I think that's a bit of an over-simplification. It's the biggest issue for you, and undoubtedly for a number of others - but to say that nothing else should be done until it's fixed is a stretch.

          It should be given a fair priority, in the context of all of the bugs outstanding. (FWIW, I know a huge number of FF users, none have seen this problem AFAICT). There are curr

    • If you are saying bad things about Mozilla and Firefox, you must be trolling.

      I have nothing against people saying bad things about Mozilla and Firefox. However, in your infamous Firefox is the most unstable program in common use [slashdot.org] post, you state:

      You can demonstrate the memory use problem quickly by loading and closing the following large web page into multiple Firefox tabs a few times: http://www.gnu.org/software/libc/manual/html_mono/ libc.html [gnu.org]. To see the memory and CPU percentage used in Windows, rig

Slashdot Top Deals

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Close