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

Comments

Just one previous post?

[Jugalator]

Maybe it's just imagination, but I thought I've been reading these kind of stories on Slashdot since the dawn of time.

Re:Just one previous post?

[Anonymous Coward]

Slashdot can't make the distinction between a project as enormous as Windows and a much, much smaller project. In my company we have fixed bugs within minutes of them being found (and shipped them! ((to our web based app))).

Re:Just one previous post?

[cp.tar]

Now, now...

I don't feel Mozilla is any smaller a project than Internet Explorer...

Let's work on preventing bugs.

[CyricZ]

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.

Re:Let's work on preventing bugs.

[Anonymous Coward]

Are you a developer?

Yea:
    What do you propose, since you seem to have experience?

Nay:
    Ok, great idea. As soon as you come up with and idea of how to do that, we'll let them know.

Re:Let's work on preventing bugs.

[qray]

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

Re:Let's work on preventing bugs.

[Anonymous Coward]

How do you know they aren't taking active measures to reduce the number of security issues "in the first place"?

You can never write perfect code the first time.

So much for "fixed within hours"

[man_of_mr_e]

Ok, I guess three weeks can be counted in hours, but that's a LOT of hours.

Re:So much for "fixed within hours"

[Anonymous Coward]

there is a difference between fixing the bug (usually happens in hours) and actually releasing an updated version of the program (usually happens in a small number of weeks).

Re:So much for "fixed within hours"

[kbielefe]

If a distro or individual were really paranoid about security, they could monitor the mailing list and patch within hours. Obviously, there isn't a significant demand for that in a structured distribution, and most people wait for the release, but I've done it early myself for a few of the more annoying bugs.

If you are really paranoid and compile with stack smash protection and position independent code, and run a system with with layers of protection like pax/grsecurity, a lot of those security issues would never affect you, technically giving you a negative patch latency in those cases.

"from the must-go-faster dept."

[Cutriss]

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.

Re:"from the must-go-faster dept."

[CyricZ]

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

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, and thus severely degraded their system's performance, they won't be too pleased.

Such a carelessness towards memory consumption would also suggest a similar lack of interest in writing code that is secure. When it comes to an Internet-enabled product, especially a web browser, security is paramount.

Re:"from the must-go-faster dept."

[RonnyJ]

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.

Re:"from the must-go-faster dept."

[iamlucky13]

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.

Re:"from the must-go-faster dept."

[Tweekster]

except the normal user doesnt realize it has consumed that much, doesnt care, doesnt even know how much RAM they have... basically those stats are for geeks to get all flustered over. However for a normal user, they dont care, they dont notice and it isnt a big deal to them I simply cant wait for the memory problems to be fixed, so people will stop bitching on forums

Re:"from the must-go-faster dept."

[Anonymous Coward]

For a look at what is being done about memory leaks, read this article.

Re:"from the must-go-faster dept."

[kidgenius]

System slowdowns aren't noticed? I have a case right now on my machine where SERVICES.EXE starts eating memory, until it reaches some critical point, resets to 0MB of RAM and then ramps back up. It does this until I restart the machine. My computer comes screeching to a halt when this happens. It takes 10-15 minutes to close programs, save work, and restart.

Re:"from the must-go-faster dept."

[Cro Magnon]

The normal user may not know how much RAM FF eats, but he will notice as it gets sloower and slooower and slooooooooower!

Re:"from the must-go-faster dept."

[tfreport]

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 on the way in Firefox 2 and 3. For more information check out Jesse Rudderman's post on the matter and if you want to report proper leaks check his write-up on the tool.

Re:"from the must-go-faster dept."

[slackmaster2000]

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.

Re:"from the must-go-faster dept."

[Ark42]

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 of ram. I keep everything in one window, and open many tabs at once, and open and close new tabs all day long, refreshing pages and running bookmarklets which may create 10 iframes at once. Pretty soon just clicking on a link has a 1-2 full seconds of delay before it actually changes color from the click and starts loading a new page. This never happened on Mozilla Suite or Firefox around 0.9 or so.

Re:"from the must-go-faster dept."

[diegocgteleline.es]

For a look at what is being done about memory leaks, read this article

No kidding, this article is also from a well-know firefox developer, they're fixing lots of memory leaks.

Apparently the top poster is one of those people who lovse to get karma for apparently-insightful articles. "Cyricz said that firefox developers don't care about memory leaks!". I mean, who wouldn't believe someone who says that a software developer don't want to fix a serious bug in his software?

I wonder what paragraph is the "most telling". The one where the firefox developer says that memory leaks are something normal? I'm running firefox in a 512 MB machine and I have never seen firefox eat 400 MB, right now it's eating 48 MB of RAM and that looks fine to me, specially when they're improving and fixing leaks on each release. I know opera is more resource-friendly....but then, opera is far from being as featureful (call me when opera can be as configurable as firefox + thousand of extensions) so I don't really see it as an alternative, just like IE.

Firefox developers are working hard to beat Microsoft. Maybe I should remember that if Microsoft controls the web browser market it controls a big part of the internet. The firefox developers are working hard to fight that - and they're fixing memory leaks on the way.

Re:"from the must-go-faster dept."

[Zephiria]

well right at this moment, having just opened firefox, and with 2 tabs open on sites that are mostly text with just some images, maybe at most 2 mbs per page, its using 38mb of memory.
I've had it happily eat up memory, i've had it crash horribly in such a way that i have to close the program through the task manager in order to recover my system.

That said i like it, but then i like IE too, the only thing stopping me from going back to IE is lack of tabs, and that i cannot import my bookmarks to it easily.

So... Were they to let me do that, and bring in tabs (hello IE 7) then i might just swap back, atleast for a while.

Re:"from the must-go-faster dept."

[bdaehlie]

The Mozilla developers spend quite a bit of time on reducing memory usage and leaks. 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.

P.S. Re: "the attitude of the Firefox developers" - I am only one Firefox developer. I am not speaking for any other devs.

Re:"from the must-go-faster dept."

[Ark42]

How do I use that javascript version 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.

Re:"from the must-go-faster dept."

[m3rajk]

i had issues with that to and found that the quality feedback agent would suck memory. i unintstalled then reinstalled without it and it magically disappeared, now i always custom the installation and leave out the QFA. try removing that and see if it helps

Re:"from the must-go-faster dept."

[iamlucky13]

Interesting...I've never installed the QFA. Also, however, I never leave Firefox running for more than a day, so my data obviously varies from people claiming to have it leak up to 400 MB.

Re:"from the must-go-faster dept."

[slackmaster2000]

I just uninstalled the QFA and some other extensions I wasn't using. Also uninstalled the Google toolbar that I installed a while ago out of curiosity. I've been browsing around for a bit now with multiple windows/tabs, and memory usage *seems* to be about 40MB less now.

Re:"from the must-go-faster dept."

[plover]

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 extension which allows you to open PDFs in a separate executable. That's helped a lot, and is part of the reason I haven't been keeping an eagle-eye on my memory consumption as of late.

But yeah, this has been an ongoing thing for me since at least Firefox 1.0.

Re:"from the must-go-faster dept."

[timeOday]

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.

Re:"from the must-go-faster dept."

[baadger]

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

One interesting observation, by default* Firefox doesn't swap out to memory to disk when you minimise the window, unlike Opera where doing so will reduce the RAM usage to something like 4-8 MB ('VM size' remains unchanged). Interestingly this doesn't return to the full amount when maximised again until you've 'visited' all the tabs and done some navigation.

This is my experience on WinXP, I haven't had any issues with multi-100MB usage since the release of FF 1.5.

* It's worth noting that you can enable memory clipping on minimise in Firefox. Someone can google it if they care.

Re:"from the must-go-faster dept."

[Anonymous Coward]

Then I'll flat out say it - the code base is sloppy.

You've got a mixed up mash of reference counted objects (XPCOM) interacting directly with garbage-collected objects (JavaScript) and this causes no end of memory leaks. Mozilla is designed from the ground-up to leak memory, since it mixes two different memory allocation schemes in its core.

Of course, that's not the end of it. There are a TON of support libraries that don't even use XPCOM *OR* JavaScript. So now we've got JavaScript GCed objects, reference-counted XPCOM objects, objects that use a custom malloc/free (so you better remember to call the Finish function!), C++ libraries that use new/delete, and - wow.

It's just a huge mishmash of memory techniques that's practically impossible to unravel. What does the PR hashtable implementation use to free memory when it's deleted? DOES it even free memory? I have no idea, because the documentation is completely messed up. I sure hope it deletes its contents, because my code doesn't even try.

Then there are the assertion errors. Assertion errors in released code?! WTF?! Starting up a fresh Firefox build with debugging enabled brings up several assertion errors. For added fun, closing windows also causes assertion errors. WHY are there still assertion errors in release code?! Especially 1.5 code?!

Anyone who's taken more than 5 minutes trying to deal with Mozilla from the C++ side can tell you that the system is a massive poorly documented mess. C, C++, JavaScript, all merged together to create a huge cludge of a browser. You peak under the hood, and you become amazed that the thing starts up, let alone runs. I suppose I'm glad that Firefox only leaks around 100MB/day, and hangs for a good 30 seconds after closing a window - because I wouldn't expect it to even run after looking at the code base.

If you want constructive critism, here are things I haven't been able to figure out after a month of playing with the code:

How are you supposed to use the "new" embedded string library?
How are you supposed to use the "old" string library?
How do you know which one you're using in the first place?
How do you create "thread-safe" XPCOM objects?
Does the PR hashtable implementation attempt to clean up its contents when it's destroyed? If so, which memory allocation scheme are you supposed to use for it?

Links to the MDC articles on string handling and hashtables will not be appreciated, because I already looked over those.

Re:"from the must-go-faster dept."

[baadger]

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

[baadger]

Correction: Minifox not Littlefox.

Re:"from the must-go-faster dept."

[Anonymous Coward]

You mean it isn't normal to say "hmm, I'm going to play a video game, time to close down all the browser windows so that I can get a decent framerate"? :-)

I'm not sure what Firefox is doing in the background, but I really do have to close it if I want to play video games without studdering.

Re:"from the must-go-faster dept."

[the way, what're you]

I'm not sure what Firefox is doing in the background, but I really do have to close it if I want to play video games without studdering.

Time to play "Choose your own adventure"!

If you would like to make fun of the poster's spelling, go to item 1. If you would like to imply the poster cannot speak well, go to item 2.

1. Apparently you also need to close Firefox to run your spellchecker. (Go to item 3.)

2. Try not to talk while playing video games. (Go to item 3.)

3. You fall in a hole and die.

Re:"from the must-go-faster dept."

[wheany]

opera is far from being as featureful (call me when opera can be as configurable as firefox + thousand of extensions)

Ring Ring

Re:"from the must-go-faster dept."

[Explo]

I suppose I'm glad that Firefox only leaks around 100MB/day, and hangs for a good 30 seconds after closing a window - because I wouldn't expect it to even run after looking at the code base.

Where does this figure of 100MB/day come from? I'm wondering about this, because (according to top; yeah, I know that it's not the most accurate way in the world to gauge memory usage...) the Firefox I'm running at work appears to have allocated about 375 MB, is in fairly constant use each workday and has been started in 2005. While FF is by no means perfect, I find the quoted figure somewhat ...interesting. I suppose that the 1.5 series leaks more than the 1.0.x series, but the figure still doesn't sound likely.

Re:"from the must-go-faster dept."

[diegocgteleline.es]

Ring Ring: i want extensions for my browser, not a cross-platform development platform - I'd use XUL for that

What about Opera, Safari, OmniWeb, etc?

[CyricZ]

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?

Re:What about Opera, Safari, OmniWeb, etc?

[PunkFloyd]

What is this non-sense that you speak? Alternative browsers? Poppycock!

-pf

MS Release Cycle

[Azarael]

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.

Re:MS Release Cycle

[ConceptJunkie]

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.

[Ancient_Hacker]

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

[XMilkProject]

To be fair, Microsoft's flaws are alot more serious, so it's only logical they will take longer to fix.

<laugh\>

Re:Be Fair

[chainy]

Well, that is kind of true in a way.

IE is a lot more integrated in Windows than FF. Probably to change anything they will have to test the impact on too many things to release the patch in an acceptabe time frame.

Maybe that is their mistake, and in any case 130+ days are too many.

__
Chäïnÿ

Re:Be Fair

[smitingpurpleemu]

Although some of the buffer overflow (and other) security bugs found in Firefox allow for execution of arbitrary code, which can do horrible things just like IE's security bugs.

Re:Be Fair

[Anonymous Coward]

:-)
That was just too funny

Re:Be Fair

[l0b0]

<laugh\>

Are you by any chance an IE developer?

Mozilla Adoption

[dasheiff]

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?

[WhatAmIDoingHere]

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.

Re:A bug ignored?

[slaker]

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?

Re:A bug ignored?

[Anonymous Coward]

Yeah, the memory leak is getting annoying.

When Firefox starts up, its a lean and clean 30MB on Windows. Less than 24 hours of use later it is using a whopping 201MB and gobbling up more with every refresh or link click on.

Re:A bug ignored?

[FooAtWFU]

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?

[dylan_-]

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 time I restarted). Why am I not seeing the same memory usage that others see? It's very odd.

Re:A bug ignored?

[CyricZ]

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 poorly architectured beast. What could be achieved simply and effectively using a cross-platform toolkit (such as wxWidgets or Qt, depending on licensing requirements) has been bungled up by the Mozilla developers.

Thankfully, you do have alternatives. There are Opera, Konqueror, Safari, and OmniWeb availabe to you, depending on your platform(s). They're just as featureful as Firefox, if not more so. And they often have nowhere near the memory consumption of Firefox, even after prolonged use.

Re:A bug ignored?

[CyricZ]

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 decrease in the quality of software.

It's especially sickening to those of us who have been using languages like LISP and Smalltalk for decades. Garbage collection easily deals with many of the memory leaks exhibited by Firefox, for instance, without an overly significant performance penalty.

Regardless, there is no excuse for a program like a BitTorrent client or a web browser to consume 80 MB of RAM for normal usage.

Re:A bug ignored?

[cyclocommuter]

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?

[gregmark]

Interesting that TRA did not even mention extensions.

Adblock is ridiculous. It flakes out more than any other extension I've ever used - I got so sick an tired of reinstalling it that I just quite using it (too busy/too lazy to fix it myself). For the most part, No-Script is able to stip your string of the most annoying ad-work. No-script kicks butt.

And just as an aside, v1.5.0.1 with 35-40 tabs over two windows, 117K memory.

Re:A bug ignored?

[Anonymous Coward]

Wow, I have 26 tabs open in two windows. At least half of these are images. I have 16 extensions, including Adblock and Adblock Filterset G. Memory usage? 79megs. Before I opened all of these tabs to test, I had one window and two tabs opened, and it was taking up 32megs.

Or, if you want, you can go to portableapps.com and get Portable Firefox...something like 16megs without extensions, if I remember correctly.

Re:A bug ignored?

[slackmaster2000]

117K, or 117,000K?

Re:A bug ignored?

[starwed]

Do you really mean to claim that Firefox doesn't do GC? At all? Because that's what I would call "untrue."

Re:A bug ignored?

[WhatAmIDoingHere]

I'd switch to opera in a heart beat if I could use adblock with it.

Re:A bug ignored?

[WhatAmIDoingHere]

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.

Re:A bug ignored?

[itlurksbeneath]

I've wondered this myself. As a test, I opened up FireFox 1.5 (I have a fair amount of extensions loaded also), created 5 tabs and opened up 5 IE windows with the exact same URL's as the 5 pages in FireFox. FireFox was taking up 120M. The sum of all the IEs open was 112M. So, the difference wasn't that great, or at least not as great as one would think. I haven't looked at a FireFox with no extensions compared to IE yet (don't feel like deleting all my extensions just to find out). I'm sure deleting the extensions would bring them into closer alignment.

Re:A bug ignored?

[Devynn]

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.

Re:A bug ignored?

[Zathrus]

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 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 anything my memory should be up, not down. Adblock Plus still works with FilterSet.G, and it also adds whitelists. There are a few esoteric features it doesn't have compared to Adblock, but I certainly haven't missed them.

Extensions are the really powerful bit of Firefox, and something matched by no other browser in ease of development and capability. Unfortunately they seem to also be prone to memory leaks. Firefox, in and of itself, doesn't leak memory (much), but a lot of extensions and plugins (Flash) do. If you want to test this, go for it -- start Firefox in Safe Mode and watch its memory usage over time. Note that plugins (fucking Flash) are still enabled, so if that's what's leaking memory (yes) then you'll still see memory usage increase over time. Surf to sites that don't require plugins and you shouldn't see much of a memory leak though. Remove the Flash plugin (or maybe use NoScript or Flashblock -- although I've had many issues with the latter, including conflicts with GreaseMonkey scripts) and you'll eliminate what's the second biggest memory leak.

But, really, ditch Adblock and replace it with Adblock Plus. You'll solve most of your problems right there. It's the biggest memory leak I've seen in a long, long time.

Re:A bug ignored?

[WhatAmIDoingHere]

Actually, I just installed and set up opera 9.00 and am loving it a bit more than Firefox. If only there was a way to block ads.

Re:A bug ignored?

[ztirffritz]

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?

Re:A bug ignored?

[Schugy]

Please write a bug report. I can visit hundreds of pages, open 50 tabs and it won't consume more than 100MB. Please tell the developers which pages you usually visit and the bug will be fixed.

Re:A bug ignored?

[CTho9305]

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?

Re:A bug ignored?

[arcade]

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?

Re:A bug ignored?

[spacefight]

Privoxy

Re:A bug ignored?

[WhatAmIDoingHere]

So, that's an in browser extension that blocks ads for me without taking up additional system resources? Oh, it's not? Yeah. I thought so.

I'm looking for something just like adblock. Not an extra program.

Re:A bug ignored?

[Jesus_666]

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 Firefox stand out. And the fact that Konqueror tends to be unstable.
If you could give me a lightweight browser that hat the extensibility of Firefox I might consider a switch, Until then I guess I'll stick with Mozilla's offer - even if it's not the most efficient bowser out there.

Re:A bug ignored?

[Anonymous Coward]

No need to delete your extensions. Start Firefox in safe mode instead.

firefox.exe -safe-mode

Re:A bug ignored?

[fafalone]

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 things like java thrown in there from time to time (and I don't browse through lots of large picture files :) ). It's almost like it just never unloads pages from memory even when you browse away from them or close their window, so it just keeps building up without limit. And before you jump all over that claim I'm well aware that's probably not what it's doing, thats just the best interpretation I can think of since I'm not familiar with how firefox manages (if you can call it that) memory.
It might build up like that because I'm "old school" and never use tabs, always new windows when needed, but it's still piss poor memory handling that I hope the developers get better control of. Fortunately I have 1GB of RAM and I rarely run something else that requires enough additional memory to notice a performance hit; but the average person is going to notice a slow down because of memory leaks and that might hurt firefox's ability to gain market share among the non-geeks.

Re:A bug ignored?

[advocate_one]

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

Re:A bug ignored?

[Anonymous Coward]

Don't forget to look at virtual memory (Task Manager - view - select columns..., check the Virtual Memory Size check box). If you have a browser open for "days" and there are several tabs, and another application needs some memory, a "dead" page could get flushed to VM. This is why when you click on a tab and have to wait a second or two. You might be shocked if you add those two columns up.

Re:A bug ignored?

[Anonymous Coward]

checkout the new 9 beta they released today, it might have the features you seek with "content blocking". You can pick and choose on a single page what you want blocked.

Re:A bug ignored?

[wheany]

If you are really using Opera 9 Technical preview 2, right-click on the page and select "Block content..."

Re:A bug ignored?

[spacefight]

Ok, I assume you want to have it comfortable, but any ad blocking browser extension takes up additional system resources too...

That's a result of their past decisions.

[khasim]

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.

Re:That's a result of their past decisions.

[Azarael]

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.

Re:That's a result of their past decisions.

[bmajik]

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 no matter what, and linux users put up with recompiling everyhing if the fix "requires" it (where "requires" means "author chose to do it that way")

Re:That's a result of their past decisions.

[thefogger]

They 'welding' of IE into the OS consists mainly of having the rendering component as a seperate dll that is also used by other applications. Having modularized applications and thus enabling code reuse is a good thing. It is just unfortunate that mshtml.dll seems to be full of bugs. Writing a HTML renderer is far from trivial and not a task that should be left to every single application developer. With a shared component at least every application that uses it gets the benefits of patches to that component.

Cheers, Fogger

Re:That's a result of their past decisions.

[Knuckles]

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.

Re:That's a result of their past decisions.

[bmajik]

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 of) your favorite distro" dichotemy. Although I couldn't tell you from memory which, 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. Do you disagree and suggest that there are no pain points around patch management and excessive rebuilding/redeploying on linux, or are you arguing just for arguments sake?

In any case, a much better example of linux shared library hell would be the earlier GTK libraries, where apps often required mutually incompatible versions of GTK source distributions. The distribute-as-source model really sucks unless you want to be in the business of recompiling a lot of software _all the time_.

Re:That's a result of their past decisions.

[Knuckles]

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 in 9 years usage mostly on Debian, but earlier also RH and SuSE. Maybe with the exception of X, but that also only just required a rebuild of all of X, and not applications using it. Anyway, X.org 7.0 gets rid of that too.
So if you want to argue not for argument's sake, at least one of these horrible examples would be helpful.

Do you disagree and suggest that there are no pain points around patch management and excessive rebuilding/redeploying on linux, or are you arguing just for arguments sake?

Again such a broad statement that makes sure you are right. Plus you open a false dichotomy with using "and" in "Do you disagree and suggest that there are no pain points".

First of all, I neither agree or disagree at this point because as I repeatedly said, I haven't encountered such and still wait for your examples. Suggesting that there are no pain points would by itself however not make your allegations of patch hell correct.

And of course there are pain points, suggesting otherwise would be moronic. Everything has pain points. The question is how they are dealt with and what tools are provided. Good distros seem to do both, at least until you provide examples to the contrary: just look at the toolset Debian provides for sitewide updates, and into their update policy for stable releases, that ensures as much as possible that behavior does not change.

If I compare that to the 100 MB service packs of Windows we have to deploy at our organisation (the actual applications not even included, which all have their own incompatible mechanisms because Windows lacks a framework they can use), which touch god-knows-what and break the other, I know which system features "excessive rebuilding/redeploying". I don't know if Windows actually has a deployment mechanism for patches, only that the guys in our IT felt the need to purchase something extra (Altiris).

In any case, a much better example of linux shared library hell would be the earlier GTK libraries, where apps often required mutually incompatible versions of GTK source distributions.

Do you even know what you are talking about? First of all, the shared library system in GNU/Linux distros ensures that security fixes to libs actually reach the apps, which is a good thing in my book. Then, what's the problem? Again, I don't think I have seen this in Debian (and I used Gnome since, what, 0.35?). Then, it's a good thing to be able to accomodate incompatible versions of libs and have apps use the right one. Much better at least than Window's "solution" of last one wins.

Re:That's a result of their past decisions.

[Anonymous Coward]

It is completely relevent BECAUSE they have to test all of that stuff, which they shouldn't have to.

Integration will just kill those turnaround times

[thePowerOfGrayskull]

Acomparison between Mozilla's time to patch and MS's isn't necessarily apt. After all, since their browser can't be separated from the OS, they clearly must regression test the entire Windows platform with every IE patch.

Re:Flash + Mozilla = CPU on a treadmill

[Anonymous Coward]

That bug has existed for several years now and has not been fixed. Hardly offtopic...

The Firefox exodus.

[CyricZ]

What we're seeing these days is an exodus from Firefox towards Opera, Konqueror, Safari, and other alternative browsers.

The Firefox 1.5 release didn't go nearly as well as it should have. Touted as being a breakthrough release, numerous people upgraded only to find that it was buggy, consumed far too many system resources, or just plain didn't work. Thus many people moved towards the other browsers that are available.

I used to recommend Firefox to my relatives, non-technical friends, and others. But I won't do it any more. Firefox has started to get a bad reputation, and I won't let their reputation affect my reputation. Thus I recommend Konqueror most times, but for people who can't switch to Linux or BSD I often suggest the use of Opera. Opera has shown for years now that they can write solid, secure, portable, performant browser. Thus they get recommendations from me.

Re:The Firefox exodus.

[Anonymous Coward]

Hummm, I still use Firefox 1.5.0.1 at this time anyway

Only publicly known bugs

[unixmaster]

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.

Re:Only publicly known bugs

[icydog]

And there are cases when there were MS security bugs known for years but... wait, never got fixed after public disclosure.

Don't just rely on averages

[PIPBoy3000]

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.

Re:Don't just rely on averages

[Anonymous Coward]

Firefox had one flaw that took 674 days to fix, nearly twice the max of Microsoft's 357 days.

This exact same flaw took Microsoft even longer to fix though, but was not included in their data, because Microsoft classified it as "moderate", whereas Mozilla classified it as critical.

Re:Don't just rely on averages

[vertinox]

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.

Re:Don't just rely on averages

[skuenzli]

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 95% confident that the median time to critical issue resolution is between 11 and 22 days.

Stephen

Moderate Spin, but still embarassing.

[bmajik]

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 :)

Re:Moderate Spin, but still embarassing.

[Anonymous Coward]

If you're running a linux distribution such as Ubuntu then it's the quick availability of the developer patches that matters and not the times listed in for a distributable version. This is because the distributions will grab the patches and apply them to their trees making them available to users within a day or two of when they get them.

Re:Moderate Spin, but still embarassing.

[Evan Meakyl]

As an MS employee, the data on our speed of patch delivery is pretty upsetting (...) Sorry about that, everyone :)
--
My opinions are my own, and do not necessarily represent those of my employer.

Indeed :)

Not really fair...

[RyoShin]

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.

Re:Not really fair...

[Anonymous Coward]

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.

Moz is pretty much an OS too, just like emacs.

Re:Not really fair...

[DarkKnightRadick]

Totally agree. Comparing a browser/email app bugfix rate to that of an integrated OS bugfix rate is rather disingenuous

Re:Not really fair...

[Jerry]

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 Windows itself. Microsoft has rolled many services and devices into its kernel, so stability of the Windows platform is not entirely in Microsoft's hands. If a video card mfgr creates a buggy driver it is going to crash Windows.

Linux, on the other hand, does NOT need Mozilla for proper operation. If Mozilla crashes it goes away. The Linux kernel cleans up the mess and continues doing its job. When a buggy video driver in Linux fails one control is given back to the console.

Re:Not really fair...

[n8k99]

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.

Is that really market share that would cause MS users to sit around waiting for third party patches? It seems to me that such a situation results in having to depend upon a third party who's code is closed as well to get fixed. Now, if i have security update on my machine and recompile the kernel and it breaks my KMail - personally, I would not be able to fix it - I'd like to be able to - but at least I could open the hood and poke around and look like I know what I'm doing on the side of the road. That is until help arrives and I pull my head out from beneath the hood only to have it to pointed out to me that the rear tires are flat!

That said, I do think that there is something important in what you said.

Re:Not really fair...

[Jussi K. Kojootti]

Except for one small fact: IE is part of (has been rolled into) the Microsoft kernel

Oh for fuck's sake, stop spreading that ridiculous myth already. IE does not run in the kernel space, ok?

Honest question

[LeonGeeste]

Something I've really wondered about, and would really like an answer to: Why the hell is it so hard not to include bugs and exploits? 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. How is it that you can't write code that prevents these exploits? It's nice that you can patch it after the fact, but from what I remember in taking computer science, if you follow some simple procedures, the code is robust. What's the problem? I am dying to know.

Re:Honest question

[mixmasterjake]

I can imagine it's probably easy to think of a bug as some kind of syntax mistake or typo in the program where, were you to look at the offending line, it would be obvious. That may be true in some rare cases, but with complex programs like FireFox a bug or security hole can be caused by an unusual reaction or side-effect that happens only when two components interact under some specific, unusual (often unexpected) circumstance. There may not be one single line with a mistake - it may encompass various libraries or even the architecture of the application. When a program grows beyond a certain size, the possible interactions grow exponentially and it isn't realistic to simply test every situation by hand.

Also, the code-base is constantly evolving. A new feature or a fix in one place may break something else. If there are 1,000 developers working on the code, then it is likely a large code-base and developers each work on their own tiny part. There is probably not an individual developer who knows all of the code.

Writing solid code is very tough, especially so as the organization grows. The coders do need to follow best practices as you mention, but you need a lot more than that. A good QA procedure and getting people to follow the rules in a large organization is really a difficult task. My hat is off to companies that do a good job.

Re:Honest question

[LeonGeeste]

I can imagine it's probably easy to think of a bug as some kind of syntax mistake or typo in the program where, were you to look at the offending line, it would be obvious. That may be true in some rare cases, but with complex programs like FireFox a bug or security hole can be caused by an unusual reaction or side-effect that happens only when two components interact under some specific, unusual (often unexpected) circumstance. There may not be one single line with a mistake - it may encompass various libraries or even the architecture of the application. When a program grows beyond a certain size, the possible interactions grow exponentially and it isn't realistic to simply test every situation by hand.

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"?

Re:Honest question

[Cygnus78]

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.

The number of eyes looking at a random sourceline is probably quite low. That you can look at it does not mean that many do so.

Re:Honest question

[juglugs]

How do you test software for EVERY eventuality, on every system, with every other piece of software running?

Now, copy a dozen paragraphs, by hand, out of a newspaper into a wordprocessor. How many mistakes did you make? Your spell checker will pick up some of them, but others slip through the tools.

See? QED

Re:Honest question

[hey!]

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.

Re:Honest question

[linuxmop]

The problem with provably correct software is not that the specifications are too complicated. It's that it's currently too difficult to prove desireable properties about code. The academics still have not produced any workable system for real-world code. However, it is still a hot area of research, with groups at Princeton, CMU, Yale, and other schools working on it.

The specification needn't be complex to reap many of the benefits of verified code; in some programs, you might just want a proof that the program cannot seg fault. In more widely used or more important programs, you might want a proof that the program cannot throw exceptions. In only the most vital code will you see very specific specifications, and this will be in areas where detailed specifications are already the norm (medical, military, etc.).

Yes, software bugs are a human problem. Maybe they're even a social problem. But we cannot just throw our hands into the air and claim that since we haven't solved these problems with technical means in 40 years, we never will. We need more time to develop the tools and ideas that will allow the computer to assist in finding bugs.

Re:Honest question

[mixmasterjake]

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"?

In a theoretical situation where you're working on a simple program, that might be a valid strategy. Another approach might be to say, "what are all the possible states of the program." You could then put the program into all those states and test that they're all stable.

If you take a program like FireFox, though, you don't get off that easy. The possible inputs/outputs/states are too great to test - even if you could fully automate it. For example, how many different java-scripts can be written? The possibility is already infinite and that's just one small aspect of a browser. One solution is that you automate as much testing as you can, you use as many utilities as you can, and you have a QA process in place so that everything gets tested as much as humanly possible...

... then the marketing manager comes in last minute and you have to make some crappy change because of some deal that was made with another company

... then the admin upgrades the version control system and you spend a whole day getting your automated unit tests running correctly

... oops! we missed our launch deadline. the boss is now yelling at everyone and it's getting stressful around here. we're all staying late and working our asses off to get this out the door. people are getting tired and making stupid mistakes.

... then you finally manage to get all the critical bugs off the list. now there's only 25 medium priorities and less than a hundred low priority items

... ah! at last you ship or launch the software. only 50 low priority bugs left in the QA system - excellent!

Re:Honest question

[LeonGeeste]

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.

It doesn't matter. A robust program would check that input is a member of a well-understood set of inputs it knows how to handle, and if not, reject it. This is exactly what we did in first year (high school) computer science -- refuse all user input except for the type we know how to handle. I don't think it requires a mathematical proof, just limiting input.

Re:Honest question

[hey!]

Yes, software bugs are a human problem. Maybe they're even a social problem. But we cannot just throw our hands into the air and claim that since we haven't solved these problems with technical means in 40 years, we never will.

There's no doubt in my mind that software bugs are mainly a social problem. The vast majority of software is nowhere good as the current state of the art permits. There is little reason to expect that as the state of the art progresses, that this situation will change.

That's not saying throw up your hands, or stop researching better methods, it's just saying be frank in admitting that most of the problem is ourselves. To a large degree, this is what agile methods and XP are about: altering the waythe development organization functions.

The specification needn't be complex to reap many of the benefits of verified code;

The trick then becomes knowing when it's worth the effort and when it's not.

I think though that the exercise of doing proofs might be a healthy one for programmers regardless of its immediate practical benefits of the problem at hand. A lot of hard to maintain code just seems to meander around somewhat pointlessly. Strong programmers write purposeful code. For example when a strong programmer writes a loop, you get a much more vivid sense of how exiting the loop guarantees that certain conditions hold that may not have been true when the loop was entered first.

Re:Honest question

[hey!]

It doesn't matter. A robust program would check that input is a member of a well-understood set of inputs it knows how to handle, and if not, reject it. This is exactly what we did in first year (high school) computer science -- refuse all user input except for the type we know how to handle. I don't think it requires a mathematical proof, just limiting input.

Naturally. You did this in first year CS because every experienced programmer knows : never trust input. And the reason this maxim is still important is that it's ignored too much.

That said, real world problems are more complex than what you did in CS101. There are two huge problems in my view:

(1) Input that is executable.
(2) Reliance on OS or libraries.

As input becomes more complex, I think that theoretically speaking it becomes harder to reject "bad" input because it becomes harder to characterize what is "bad". If this were not true, then we could write a compiler that rejects bad programs. I'm not saying you can't secure complex input that does all kinds of things to program state, but it's more work and it's more pervasive than just writing a simple state machine for validating numeric input.

The second problem is a huge day to day issue for any programmer. You use components provided by other people and you have to assume they are secure and correct, although this assumption is often bad. The recent WMF vulnerability is a good example of this.

Count me as one of those...

[Richard Steiner]

Firefox 1.5 introduced a keyboard error which drives me crazy -- keyboard navigation drops out while editing messages (I think due to activity on other tabs), and I also lose the apostrophe key and other things (both it and the forward slash bring up the Find toolbar even when in an edit box like this one).

I tried to search for a way to report the problem, and found the Firefox bug reporting page to be a fricking maze.

Users sure do notice!

[CyricZ]

Remember, there are many, many user out there who have systems with only 512 MB of RAM, if not far less. They will quickly notice their system performance tank when they start using Firefox, especially if along with other heavy software such as Microsoft Office and Photoshop.

Even if they don't care about the numerical values in question, they still do care about getting work done. And when Firefox (or any other piece of software) is directly responsible for such slowdowns, it will be remembered.

Recall, excessive memory consumption is one of the most difficult reputations for a piece of software to break. People will come to associate Mozilla and Firefox with slow, bloated software. That won't bode well for future adoption of their products by the masses.

Re:Users sure do notice!

[starwed]

Newsflash; I use Firefox constantly, and have only 256MB of RAM. On average it eats 30-50MB, and I've never noticed a slowdown because of it. Firefox will happily use the RAM which is available. That doesn't mean it does so greedily...

Re:Users sure do notice!

[drinkypoo]

Firefox will happily use the RAM which is available. That doesn't mean it does so greedily...

Oh, yes it does. Because it does. Granted, I'm running a bunch of extensions so the problem could be anything :) but every so often Firefox will stop responding because of some webpage, and eat up 300 or 400 MB and refuse to die until I kill the process (not just the task.) This is really fucking annoying and if I didn't know how to use the task manager I'd have to reboot, because the firefox.exe process running in the background has no windows, and even if it did, killing the task doesn't work.

compared with

[Anonymous Coward]

The amount of time it takes the average user to install the updated software, both figures pale into insignificance....

Why the difference in buxfix rate?

[stavromueller]

It's the difference between people who write code with the intention of benefitting the community, and people who write code because they're paid to.

The eyes are looking at the edges

[Weaselmancer]

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?

Re:The eyes are looking at the edges

[CyricZ]

It was well-known in the late 1960s that it was not a good idea to use unbounded copying. Indeed, that is before C, let alone strcpy(), was first implemented.

Memory-related exploits should never be an issue. A proper garbage collection system, like that offered by most implementations of LISP, Smalltalk and OCaml, for instance, eliminates memory leaks. It lets the developer focus on writing solid code, without having to worry about mundane issues, without affecting performance to any extent.

And no, don't use a GC'ed language like Java or the various .NET languages. Their use of a virtual machine often brings in more problems than it solves, in addition to using poor garbage collection policies and schemes.

Re:The eyes are looking at the edges

[Anonymous Coward]

What is it with you and the anti-Mozilla/pro-OpenBSD rants? Are you some kinda astroturfer or you just like moving all the threads offtopic? Or, perhaps it is just the crack as usual? Momma's-crackboy?

Re:The eyes are looking at the edges

[Nevyn]

You are talking about things that _you_ want, and I can even mostly agree. However it has been proven repeatedly that only a very small minority are willing to put security/quality before other design trade offs ... things might well get better in the next 10 years due to python/C#/etc. not having as significant downsides. But even so we are going to be stuck with C based programs for a long time, and there are still very few people who want to pay to do even the minimal fixes.

Again, I'm not saying I wouldn't like to do that trade off, indeed I wrote my own secure Web server (with a monetary guarantee you won't be owned) because I didn't like apache-httpd ... but there just isn't the general buying power to bring secure software out of the niche.

Opera conversion on its way here...

[Colonel Angus]

After upgrading to 1.5, I too have been using Opera more and more as of late. I've had the keyboard nav periodically not work. Trouble getting certain plugins to work and a noticeable increase in memory usage.

I'm doing with Opera what I did with Firefox (then Phoenix just prior to the name change to Firebird) when IE was pissing me off.

I downloaded Phoenix and would use it when I thought of it or when IE did something specific to piss me off. As time went on Mozilla's browser became the default browser and that has remained for some time.

Now with these nagging problems in Firefox, Opera is seeing a lot more light of day with Firefox use decreasing. I suspect that Opera will end up being my default browser when all is said and done if the trend continues unless Mozilla pulls it together.

As always, that's just my $.02 and YMMV.

Re:Opera conversion on its way here...

[CyricZ]

Indeed. It is often said that one becomes what he fights against. In this case Firefox decided to take on Internet Explorer, and hence has started to become much more like it.

Firefox is indeed starting to show the same poor planning, poor implementation, numerous security issues, and poor resource usage that Internet Explorer is well known for.

It is just your imagination.

[douglips]

Slashdot has only existed since 1997.

Re:It is just your imagination.

[plover]

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.

Re:It is just your imagination.

[dfries]

No kidding, my syslog doesn't even support that there was a 2005! Maybe one of these years someone will teach it out to print a year.
Oct 3 04:31:54 SpacedOut squid[2235]: storeDirWriteCleanLogs: Starting...
Oct 3 04:31:55 SpacedOut squid[2235]: Finished. Wrote 2423 entries.
Oct 3 04:31:55 SpacedOut squid[2235]: Took 0.1 seconds (23658.4 entries/sec).
Oct 3 04:31:55 SpacedOut squid[2235]: logfileRotate: /var/log/squid/store.log
Oct 3 04:31:55 SpacedOut squid[2235]: logfileRotate: /var/log/squid/access.log
...
Feb 7 04:32:16 SpacedOut squid[2235]: storeDirWriteCleanLogs: Starting...
Feb 7 04:32:16 SpacedOut squid[2235]: Finished. Wrote 2830 entries.
Feb 7 04:32:16 SpacedOut squid[2235]: Took 0.1 seconds (35392.3 entries/sec).
Feb 7 04:32:16 SpacedOut squid[2235]: logfileRotate: /var/log/squid/store.log
Feb 7 04:32:16 SpacedOut squid[2235]: logfileRotate: /var/log/squid/access.log

Has squid been running for four months or a year and four months?

Now you're just being silly!

[CyricZ]

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.

Re:Now you're just being silly!

[Anonymous Coward]

Not all memory used by Gecko is under the control of the garbage collector.

firefox, 1.5 was a ram gobbler

[madnuke]

Current useage for me with 4 tabs open is 76 mb, I don't know if this is a lot my Tuneup Utilities 2006 is green and I'm experiencing no system lag. In the days of 1 gig of ram do we really need to worry about a little memory leak, its like you put Norton on it slows down your system but it protects (I use AVG) but is security the price we pay for a less memory use browser. Remember leaks could also be down to the extensions you use that may have memory leaks themselves.

Re:firefox, 1.5 was a ram gobbler

[coolcold]

well, my system is still 512Mb. Even with 1Gb of ram, I prefer my memory to be used on other application than wasted on a bug. Maybe that's just me.

Re:firefox, 1.5 was a ram gobbler

[aj9703]

Well that's the problem with memory leaks... you never know. If you look at Bugzilla for Firefox's memory leaks, i can see atleast 5-10 major and critical memory leak issues. In my own example, as i typing out this post, i have 5 tabs open and one of them is a pdf. My memory consumption is 242,000MB out of 512MB and my page files are being written at an all time high. Honestly, I think once MS comes up with IE7, we might see a reversal in all the growth and publicity firefox has acquired.I love firefox and hopefully the memory leak issues are resolved sooner than later cuz i hate to go back to see the blue E all over again

Re:firefox, 1.5 was a ram gobbler

[madnuke]

Have you tried updateing too the latest version as that sounds a bad leak.

Re:Best solution!

[vertinox]

When even a normal user finds that Firefox has consumed 400+ MB of their 512 MB of RAM,

Buy more RAM! ;)

Mozilla Bug Fixes

[El Royo]

This is the view of an outsider to the project; I'm speaking strictly as a user here. It appears that the in particular Firefox and Thunderbird were brought along to certain level of functionality and usability and now are floundering. Critical security problems are being addressed but very old usability bugs stick around for years. It's the small things that tend to drive a person over the edge. That last bit of polish that makes the difference between a 'commercial' application and an open source one. I had high hopes that Firefox 1.5 would raise the bar even more but thinking back, I can't think of what was significant about the 1.5 release now. I think it was fixing the automatic updates, which was pretty critical.

Re:Mozilla Bug Fixes

[The One KEA]

The reason why these so-called "usability bugs" don't get fixed is because the users, upon finding out about the bug, scream and holler and fill up the bug report with lots of useless spam, advocacy, and flaming.

This of course turns off the people capable of fixing the original issue, and it thus gets ignored. A good first step would be creating a new Bugzilla bug, containing a distilled report of the pertinent issues surrounding the problem, and ensuring that it does not get spammed.

A perfect example is Bug 38486.

Difficult bugs simply aren't fixed.

[Futurepower(R)]

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.

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:

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.

[The One KEA]

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

[pavera]

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.

Re:Difficult bugs simply aren't fixed.

[RyoShin]

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 that, when last accessed, started hogging CPU cycles, FireFox just sits merily with no problems.

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.

Re:Difficult bugs simply aren't fixed.

[mibus]

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 currently 21 "blocker" bugs, a few of them are outright crashes - eg #296298, which is a crash-on-startup that's been around for six months, even with a pair of stack traces.

From a quick search in Bugzilla, it seems likely to me that there are several separate problems (many to do with Flash, Java, and suspending laptops) that are causing most of the CPU issues. (No wonder there's a hell of a time trying to narrow down problems...)

There are 38 open critical or blocker bugs assigned to FF1.5 (I haven't checked the trunk). Having all of the FF developers focus on one problem and do nothing else will not gain you anything, but will certainly lose out time to fix other problems.

Re:Difficult bugs simply aren't fixed.

[bunratty]

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 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. To see the memory and CPU percentage used in Windows, right-click on the Taskbar and choose Task Manager. Choose the Processes tab.This demonstrates one aspect of the bug, but is not representative of big occuring in normal use, since that web page is huge.

When I tried opening the page you specified in three tabs in Firefox, memory use went up to about 200 MB, and the memory was released when I closed the tabs. Then you stated:

...does it seem reasonable that opening 3 tabs showing the same 4 megabyte HTML file should require 200 Megabytes? Why is it that Opera has no problems of this nature?

When I tried the same test in Opera, it used 165 MB of memory. Granted, it's nearly 20% less than what Firefox uses, but how can you seriously claim that 200 MB of memory use in Firefox "demonstrate[s] the memory use problem quickly", but 165 MB of memory use in Opera shows "Opera has no problems of this nature"?

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.

Re:Difficult bugs simply aren't fixed.

[Anonymous Coward]

So, is the bug where closing a Firefox window causes the browser to freeze at 100% CPU use for around 30 seconds ever going to be fixed? Of course, closing the last window causes it to freeze even longer, with the only recourse being to either wait for Firefox to finish it's FOR I=1 TO 10000000000 NEXT I loop or kill it in the task manager. Those bugs going to be fixed, ever?

They've existed ever since the browser was released. It's ridiculous to have to wait SO long for a window to close. Opera doesn't have this problem. Internet Explorer doesn't have this problem. In fact, no other browser I can think of has a problem with closing windows. Just Firefox.

Any plans on that ever being fixed?

Futurepower(R) is 100% right about Firefox - the biggest, most annoying bugs, never get fixed. I shouldn't have to remember to close Firefox on a daily basis to keep its memory usage below 500MB. I shouldn't have to wait a good minute after I've closed it for it to do - well, I don't know what it's doing.

From TFA

[wiredog]

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

Not just Microsoft

[wiredog]

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.

Firefox is not the enemy

[Anonymous Coward]

It's important to remember that the enemy in TFA is Microsoft, not Firefox. It doesn't matter that Firefox has long-running problems that people have complained about for years. Firefox is Good. Microsoft is Bad. Remember that next time you want to complain about Firefox chewing a couple hundred megabytes of memory.

Firefox's leniant users
either your computer or what you're doing is the problem. Sorry. It doesn't matter if everything else works fine either. It is not Firefox.

Re:Firefox is not the enemy

[n8k99]

Perhaps i am terribly confused, and it would not be the first time in my life that has happened; we're not going to talk about my senior prom; but is not the enemy the process which produces these products. Perhaps, I have it all wrong, but are there people who are using FF who are having this problem using up all the memory, who do not work for Mozilla, who are also capable of applying the principles of scientific inquiry and discovering what's up?

What I am trying to say is this. Mozilla is part of the community that allows anyone to make corrects to their code. I am sure that they are doing what they can to fix the problem, but is it possible that someone else may find it as well and submit it to them? If that is indeed the case here, then the enemy which we like to portray as Microsoft, is actually the process of software creation that is completely closed.I'm just asking because I don't always have the story straight and would like to know.

Not that much here

[Anonymous Coward]

I got firefox 1.0.7 here on gentoo gnu/linux with 5 tabs open using 21 MB shared or 50.4 MB RSS memory. Extensions: Adblock v5 d2 nightly 39, web developer 0.9.3, BugMeNot 0.6.2, adblick filterset G updater 0.2.4, proxybutton 0.2.1 and cookie button 0.8.4.

Remember, these values are WITH shared libraries that can be and are used by many other applications. So no, I don't think firefox is using too much memory.

What's eating memory is probably flash (which I don't have) or some other plugin.

Lies, Bigger Lies, and reporters doing statistics

[skeptykus]

Anyone with a bit more education in stats would have noticed the Extreme Outlier (674), the data looks much different when not counting item: Average about: 23 days. (NOT 37!)

OMG!!!

[TheSkepticalOptimist]

Your comparing fixes to a web browser to that of an operating system!

Give me a friggin break!

I mean, Mozilla makes a web browser and an email client, period. Regardless of what any other project they have on the go, that is their bread and butter. I would expect a company with a singular focus to be able to fix bugs in their TWO major products quickly. On the other hand Microsoft makes an OS, an infinitely larger code base and more complicated set of code to fix in addition to many many many other products. Even if its just an I.E. vulnerability, Microsoft still has to focus on ensuring OS system components are not affected because of the integration of I.E. in Windows. Microsoft has billions of clients, and while firefox is a hot product now, Mozilla doesn't have to ensure that 95% of PC's are not going to be adversely affected by a quickly rushed security patch.

It would be more appropriate to compare bug fixes between Apple and Microsoft, or Sun and Microsoft, (not really fair between RedHat and Microsoft because RedHat is a one hit wonder as well).

I can't stand double standards and people jumping on the bandwagon every time Microsoft is mentioned negatively in an article. If Mozilla had the depth of innovation and breadth of products Microsoft maintains, and they still fixed critical flaws in 3 weeks, then my hats off too them. But to say a company making one product fixes bugs 10 times faster then a company with a more complicated set of products and larger codebase is ridiculous, period.

I am not fan of Microsoft, but give me a break here. If Microsoft was a person, it would be criminal the kind of bias, slander and double standards imposed on them by every self righteous narrow minded geek out there.

Re:Integration will just kill those turnaround tim

[Hellken242]

Who cares how much work it takes for them to "turn around" a patch. What matters in the end is when the hole is fixed. And Mozilla seems to fix them faster. End of story.

journalistic ethics

[Anonymous Coward]

How about the irony of seeing this article with a nice big "get the facts" advertisement from M$?
Nice work slashdot. This is journalistic ethics at its peak.
I know it is randomized and not everyone gets the same add but it is so hypocritical as to make me want to vommit.

Re:Lies, Bigger Lies, and reporters doing statisti

[Anonymous Coward]

RTFA: "I must insert a strong caveat here, however. The 37-day average is skewed mightily by a flaw found in various Mozilla products that potentially allowed malicious Web sites to trick users into accepting security dialog boxes -- a flaw which Mozilla took 674 days to fully remedy. This was a vulnerability that apparently existed in all browsers. (Microsoft got around to fixing an identical flaw -- which it labeled a "moderate" security risk -- in December.)

According to Chris Hofmann, Mozilla's director of engineering, the fix was delayed in part by speculation that it could cause the browser to constantly pop up annoying alert dialog boxes. But Hofmann noted that the early beta releases of Firefox in March 2004 closed off the problem as originally defined by the guy who discovered the flaw (Jesse Ruderman, who was since hired on as a full-time researcher at Mozilla).

With that flaw left out of the data, Mozilla took an average of 23 days to develop and incorporate fixes. And even this lower average does not give a clear picture of Mozilla's typical response time. In the past three years, Mozilla produced roughly one-third of its critical security updates within less than 10 days of being notified of a potential problem"

Amazing

[Bagoomba]

Your skill in oversimplifying is clearly underrated. And your adept ability to equate apples and steak should not go unmentioned.

Move out of your parents house and get a job.

Never knew they had so many (and I don't care)

[Angelox]

As a user, Firefox works fine for me, I have never had any "critical" problems or seen any "bugs" in it. And I would not trade my Firefox for any other browser

It seems as much development model as market share

[jesterzog]

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 issue. One of the major reasons that third party software breaks when Microsoft changes its own software is that it's so often unclear about its API's. Programmers have to rely on half-documented API's, and on brittle work-arounds for badly documented Microsoft bugs rather than robust and clear interfaces.

Try writing a non-trivial Outlook addin, for instance, without having to cope with a range of Outlook API bugs and strange ways of acting. The unofficial way of getting around these is to use undocumented hacks that end up being completely unofficial and quite flakey.

Market share seems to be one reason that Microsoft needs to test so many individual software packages with its changes, simply because it can cause such huge problems for people every time they break. If it'd provided stable, robust and well documented API's in the first place, though, I don't think that other people's software breaking would be nearly as much of a problem.

Thunderbug

[gonz]

I have been frustrated by various usability problems with Thunderbird, compared to other e-mail clients. Recently I started reporting issues via their Bugzilla system and was surprised to see most of my issues marked as duplicates of other bugs, many of which had been sitting in the database for a surprisingly long time!

Some examples:

• Added in March 2005, still unresolved: The "Search Messages" feature sucks because you can't select multiple folders to search (Bug #288046)
• Added in 2000, still unresolved: No progress bar for downloading mail - (Bug #61139)
• Added in 2000, still unresolved: You can't paste a screenshot from the clipboard when composing an e-mail (Bug #47838)
• Added in 1999, still unresolved: The "new mail" alert is triggered every single time a mailing list message arrives (Bug #11040)

-Gonz

Re:Integration will just kill those turnaround tim

[PhxBlue]

No one forced Microsoft to integrate the browser into the OS. That was their mistake.

Re:Integration will just kill those turnaround tim

[thePowerOfGrayskull]

Judging by replies, perhaps my intended sarcasm wasn't apparent...