Slashdot Mirror
Another Look At Mozilla's BugFix Rate
An anonymous reader writes "Washingtonpost.com's Security Fix blog has published the results of a look back at three years worth of critical patches from Mozilla, and found that Mozilla typically ships updates for critical flaws in about three weeks, though in more than a third of the cases it pushed out a fix in ten days or less. The data comes just a few weeks after The Post published data from a similar study that found Microsoft averaged 130+ days to fix critical flaws. Slashdot also covered that study in a previous post."
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.
I used to think it was just poor management, but now you have open source projects with thousands of eyes looking at every line of code.
IMHO, I believe that the reason why is because most of the developers are looking "at the edges" - where new functionality is being added. For example, how many of those developers are looking at the JPEG decompress routine? Turns out that wound up being important exploit-wise recently. And there it sat for years, unnoticed.
from what I remember in taking computer science, if you follow some simple procedures, the code is robust.
Well, robust doesn't just come from simple procedures. It's also design and style. You can't come up with excellent procedures and guarantee good software. You have to design well, communicate well, and implement ideas correctly. A lot is also owed to experience - sometimes, the only way to find out you've screwed up is after the fact. A good example is strcpy(). We know unbounded copy is a bad idea now, but how many years went by before we did?
Weaselmancer
rediculous.
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.
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.
TODO: come up with a clever sig
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.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.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
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.