Extensions do whatever they want. Some just get callbacks, some set timers, some override core browser functionality. Most keep global non-threadsafe state and would fail spectacularly if invoked on multiple threads.
> There's no way to dynamically obtain such a handle after the window has > been created (correct me if I'm missing something).
You can get a handle to a toplevel window that has a name by using window.open with that name as the target. A name can be dynamically set by code inside the window. So for every window, there is the potential that you will end up with a handle to it. Fixing this requires either changing window targeting (possibly breaks sites, but might be doable) or coalescing window threads as needed if windows from one thread get a handle to windows from another thread (this souns hard to me).
There are also ways to enumerate all windows from code with expanded privileges in Gecko (see EnablePrivilege).
There might be other ways to get window handles too; these two were just off the top of my head.
It really isn't quite that easy; if it were it would have been done by now...
The JS runtime in Firefox supports threading and has for years. I believe it did that even before the Mozilla project started. Using this in the UI or across tabs/windows is blocked on several issues:
1) Web content expects all JS that might interact with each other (which includes JS in different windows) to run on a single thread. Not doing that breaks websites. 2) All the DOM code is single-threaded. Changing that would involve some nontrivial locking overhead. Might be worth it as processors become more and more parallel. 3) A lot of other application code is single-threaded in Firefox (though a number of worker threads _is_ used). This would need to be addressed.
Making the runtime support threading is the easy (and done long ago) part.
Of course that's a matter of acid3 test design. Browsers have been fixing the bugs pointed out by preliminary acid3 versions; as soon as the issue was fixed in browsers, the folks writing the test removed that part and replaced it with a new one.
One of the stated goals of acid3, as I understand it, is that at the moment when the test is declared "final" every single thing it tests must be failed by one or more of then-current-development Gecko, Webkit, and Presto. Which means they're likely to keep adding more and more esoteric tests up to that point.
> and I would consider them to be far more "featured" than Web Browsers
Even if that were true, did they have to maintain large data structures in memory at all times (forced to do so by the DOM specs)? Did they need to try to guarantee 50fps redraw (10ms timeouts being the standard "dhtml" sites use)?
Plus, I'm not sure that your more "featured" is correct. But it's hard to compare features that are so different in concept (controlling hardware vs doing predictive guessing on search terms based on past searches... which is more of a feature? Which takes more memory? Should the past search database be in memory or on disk, for acceptable performance?).
The real issue is that web browsers are trying to do everything at once and please a number of very different demographics (people with 100MB (I kid you not!) HTML files full of tables, people with pages that link in 800MB (again I kid you not) of images, users who want instantaneous response to any action without any memory being used to hold partially precomputed results, etc, etc).
Really, you can have fast, low memory usage, or doing all the bells and whistles people want out of a browser. Pick two, or maybe even one and a half.
> It is surprising that one is not able to disable JS on a per site basis by default.
You mean surprising that there is no user interface for this? The back end has support; setting a few preferences (to indicate which sites you're whitelisting or blacklisting; both modes are available) does the trick.
Yes. Certain persons affiliated with the W3C were members of the working group that created this RFC. So were others who are not affiliated with W3C directly (though they represent companies that might also participate in the W3C).
That doesn't change the fact that the W3C is not the standards organization responsible for RFC 2616: they don't control its status, and they're not the ones who voted to actually accept it as a standard.
Because certain constituencies ("semantic web", etc) feel that URLs (URIs, IRIs, whatever) are a one-size-fits-all tool for identifying everything. That's why XML namespaces are technically recommended to be URIs (though in the end you just to an explicit string match on the namespace and never actually fetch anything from the URI). This is why URIs are used for pointing to parts of the same document. The list goes on and on.
Basically, some people feel they have a hammer and all unique identification problems start to look like nails to them.
Plenty of that as well. Unfortunately, it's hard to find houses for sale near public transit in some areas.
With all the new developments going up recently during the bubble, most of the houses on the market (all in some places) were nowhere near public transit.
Of course whatever planners didn't bother to extend public transit to new multi-thousand-home developments should be fired... but I digress.
Sometimes that works, sometimes it doesn't. Route changes happen quite often in some public transit systems (I know I've seen changes to the same route less than a year apart here in Chicago). In the process, houses that used to be quite near a stop can end up very far away.
Did I ever say there are no flaws? Please point to where I said that!
Given that I've personally filed 1800-some bugs on Gecko and Firefox over the last 8 years or so, I'm quite aware that there are flaws. My point was that there are fewer flaws than there would be if no one were being paid to work on the browser. I note that you carefully avoided responding to this point.
> especially when the computer has been put into hibernation
Which Firefox version are you seeing this problem with? There was https://bugzilla.mozilla.org/show_bug.cgi?id=213637 but that claims to be fixed as of Firefox 2.0.0.8 or the latest Firefox 3 betas. If you're seeing high CPU usage after hibernation with something newer than that, please file a bug and cc bzbarsky atsign mit dot edu.
> Abuse by the developers of those who report bugs:
Are you sure they were developers and not just people who created a (free) account in the bug database and then started triaging bugs? The latter happens quite a bit. If people are being abusive, please report them to gerv atsign mozilla dot org. That sort of thing is unacceptable.
> That's been the response to the CPU hogging bug reports I've seen.
Can you please point me to these bug reports? I'd appreciate that very much.
> They don't seem to want to work on bugs that require extended troubleshooting.
Of course not! Who does?;) More to the point, given a choice between fixing two bugs that have equal impact, but one of which does not require extended troubleshooting while the other does, the choice is clear: fix the one that doesn't need troubleshooting. It's the obviously efficient choice, if the payoffs are really the same: it fixes one of the two equivalent bugs and leaves time to also fix other bugs. If there are enough developers that there are people idle, this calculus goes out the window, of course. But that's not the situation Mozilla (or any other software project I've ever encountered) is in.
Of course payoffs depend on things like the severity of the problem, its ubiquity, etc. They can be hard to peg down precisely, and it may be that in some cases people underestimated the impact of a bug. Can you point me to specific high-impact bugs that are being avoided because of a need for troubleshooting?
> Firefox cannot be made portable
I can't speak to this, since I've never tried to do it, to be honest.
> Firefox will not allow multiple instances.
Right. The profile system inherited from Netscape is a bit of a mess. I've never seen anyone deny this.
> Firefox session restore is not reliable.
Is there a bug filed for this issue? If there is, can you please cc bzbarsky atsign mit dot edu on it? If not, can you either file or provide reliable steps to reproduce so that I would be able to file it myself?
> Firefox hogs memory.
Yes. It's being worked on. See Stuart Parmenter's weblog and the large amount of work done on leak fixing.
> while continuing to deny that any exist.
I'm going to call your bluff here, sorry. Can you point me to one instance of an active Firefox developer denying that memory issues exist? (Note: Ben Goodger is not active, and wasn't by the time he posted the blog entry people live to cite.)
> Firefox advertises extensions, then blames them for problems.
This is an issue, yes.
> A common topic of articles about Firefox is some variation of "How to make Firefox work the > way it should".
Are these articles written by Firefox devlopers?
> Often Firefox developers blame Firefox extensions advertised on the Mozilla web site.
Advertised where, exactly? The link to addons.mozilla.org from www.mozilla.com?
> does not seem to produce faster results than Firefox developed by volunteers.
I'm sorry, but that's clearly false. Just compare the changes in the rendering engine between Gecko 1.7 and Gecko 1.8 to those between Gecko 1.8 and Gecko 1.9. The latter are much more extensive and would never have happened without the sort of funding that's been available over the last few years. As a simple example, if development had proceeded the same way it had right after the Netscape division at AOL was dissolved, there is no way Gecko would be passing Acid2 right now.
Do keep in mind that there is a lot more to Firefox than just the user interface. If you're comparing the user interface evolution right now to what was happening in the Phoenix 0.6 timeframe, then of course there is less "progress". The 80/20 rule applies to interfaces just as much as anything else.
As for the CEO thing, having met Mitchell and talked to her I would be inclined to take what she says at face value. She's been taking less and less of a role in the actual administrative aspects of running the corporation, and it makes sense to have the titles match the actual work being done.
Frankly, it sounds to me like you have a chip on your shoulder against Mitchell and the Mozilla Corporation for some reason, and it's clouding your judgment and keeping you from doing some basic research to verify your claims...
> Once the problem was made obvious, fixing was easy.
This is true of most bugs period. These are not the bugs that take the majority of the time to fix.
> The CPU hogging bug was reported 6 years ago
"The" CPU hogging bug? I've seen dozens (if not hundreds) of "uses too much CPU" bugs reported. A number have been fixed. Some have not, usually because they have proved impossible to reproduce, and thus impossible to debug. At that point, other bugs with equal payoff but lower investment needed get worked on. Which exact bug are you thinking about here?
> Very serious shortcomings in features, like the fact that Firefox can't be made completely > portable and the session restore often doesn't restore all tabs, have been ignored.
Very possible, yes. No one is claiming perfection for Firefox, or any other software project. I haven't kept as much track of the UI sort of things you're complaining about here as much as I have of the Gecko end of things, so I'm not really qualified to comment on it.
> Many of the "advances" in Firefox were documents that indicate how to make Firefox operate > the way it should, blaming crashes on plugins, for example.
Hold on. There are crashes in plug-ins at times. This is a fact. The browser can try to mitigate this problem by running plug-ins in a separate process (and somehow dealing with them trying to paint directly to its memory). The fact that Gecko doesn't do this is a somewhat poor design decision and definitely needs to be fixed.
Given that this is the state of things, however, documenting that certain plug-ins crash in certain situations is not unreasonable. Labeling it as an "advance" is unreasonable, of course. Can you point me to a document with such documentation being labeled as an "advance"?
50 programmers might be right ballpark, but might be a little high. It's hard to say; I don't have that information (nor do you). It depends on how many people are in marketing, QA, etc.
For the rest, I don't know where you're getting your information, but it's pretty bogus. Coverity has never uncovered any memory or CPU consumption bugs in Gecko or Firefox that I've seen (nor could it, given what it finds). They have found a few memory-safety issues, and lots and lots of false positives.
There were indeed no feature updates on the _stable_ release branch. The work has been going on in the development trunk (slated to become Gecko 1.9 and Firefox 3). I don't see you complaining that IE7 has had no feature updates, or that Safari 2 had no feature updates until Safari 3 got released. Same thing here. If you want to see what people have been working on, grab a build of Firefox 3 beta 2.
> they made it clear they don't do the difficult kinds of troubleshooting, just the easy > kinds.
First, this is simply false. I suggest you look into the sort of work Stuart Parmenter has been doing. There are others doing equally difficult work, but he's actually been blogging about what he's up to; for others you'd have to read bugs and/or their progress reports.
Second, given the choice between easy troubleshooting and difficult troubleshooting, with equal payoff, the easy troubleshooting is what will happen every time. It's a basic resource-allocation situation: finite resources allocated for maximum effect. Therefore, as long as there are more problems than people available to work on them, the easy problems are the ones that will get fixed. This assumes equal payoff, of course. But in fact, there has been no shortage of clearly reported, reproducible, well-explained bugs that cover things like "Firefox uses too much memory" until recently. So those bugs were the ones getting fixed, instead of the vague, unreproducible ones. Once the pool of things that were easy to fix dried up, the payoffs became unequal, which is why there is more focus now on hunting down things like memory fragmentation.
> That's enough for 200 programmers each earning $100,000 per year.
No, it's not. If someone earns $100,000 per year, that means that the employer is paying:
$100,000 salary
$7000-ish FICA
$10,000-ish benefits of various sorts
This does not include costs for things like:
* Building rent
* Computer equipment
* Unemployment insurance (varies by state)
* Travel reimbursements (a lot of the Mozilla work is distributed)
* Participation in conferences and standards organizations (W3C membership, e.g.)
and probably various other things I don't know about, not having ever employed anyone.
A good estimate is that an employee's cost to the employer is 1.5-2 times the salary.
As a matter of fact, the Mozilla Corporation employs on the order of 100 people. Some are programmers. Some are QA. A few are administrative staff. This is consistent with the factor of 2 multiplier.
> Yet in 2006, there were only a few somewhat minor updates to Firefox and Thunderbird.
And a lot of serious development on the next major versions of both Gecko and Firefox. It's not like this is being done in hiding, or anything; all the work is public. You also seem to underestimate the amount of work required for the security updates. Fixing security bugs on a stable branch (which doesn't allow major architecture changes) without breaking functionality is often very difficult.
> The question is, "Why isn't the money being spent on Firefox development?"
The answer has been publicly stated several times by Mitchell, for what it's worth. The money is not being spent because:
1) [Less important] Hiring competent people is hard (and you don't want to hire too many at once, because then all the time will be spent training them and not getting work done. See also The Mythical Man-Month. As a result, revenue growth (which in this case is directly correlated with usage growth) has simply outstripped expenses (which are limited by number of employees in this case, if money doesn't get wasted).
2) [More important] If tomorrow Google decides to be evil, or starts giving worse search results than a startup search engine, or decides to ship its own browser and not pay for searches from Firefox anymore, money in the bank means that development can continue until other funding sources are found. Put another way, why aren't you spending all the money you earn? You do save some, right? Why do you save it?
> If no regulations exist, then banking in Second Life can't be trusted at all.
Strictly speaking, this is not true. You could have a situation where banks promise that they are not running a Ponzi scheme and voluntarily submit to audits by either auditing experts or account holders or both.
That is, instead of having external regulation imposed, have self-imposed regulations and enough transparency that it's clear you're following them.
The problem then is account holders having to understand the regulations. Or having to pay someone (said auditing experts) to make a call on whether the bank is trustworthy.
This isn't to say that such a setup is necessarily better than imposed regulation, but that it could be a viable alternative depending on circumstances. Both involve a lot of infrastructure existing; it just happens that government (needed anyway for things like common defence) provides ready-made infrastructure for the imposed-regulation approach.
Really? Can you actually point to any instance of anyone actively working on Firefox who said anything like this? Note that Ben Goodger's blog post saying that _some_ (not all) instances of memory usage may be due to the back-forward cache came after he was no longer particularly active.
At no point have I ever seen anyone say anything resembling "doesn't have any bugs", and I would very much like to see your source for this. Or are you just regurgitating slashdot group-think?
Slashdot Mirror
Extensions do whatever they want. Some just get callbacks, some set timers, some override core browser functionality. Most keep global non-threadsafe state and would fail spectacularly if invoked on multiple threads.
There seem to be a number of people reporting the image issue... and they're all using the Ubuntu builds. You might want to report it to Ubuntu.
> There's no way to dynamically obtain such a handle after the window has
> been created (correct me if I'm missing something).
You can get a handle to a toplevel window that has a name by using window.open with that name as the target. A name can be dynamically set by code inside the window. So for every window, there is the potential that you will end up with a handle to it. Fixing this requires either changing window targeting (possibly breaks sites, but might be doable) or coalescing window threads as needed if windows from one thread get a handle to windows from another thread (this souns hard to me).
There are also ways to enumerate all windows from code with expanded privileges in Gecko (see EnablePrivilege).
There might be other ways to get window handles too; these two were just off the top of my head.
It really isn't quite that easy; if it were it would have been done by now...
A large part of this is that MSVC++ generates better assembly than g++ in a lot of cases.
The JS runtime in Firefox supports threading and has for years. I believe it did that even before the Mozilla project started. Using this in the UI or across tabs/windows is blocked on several issues:
1) Web content expects all JS that might interact with each other (which includes JS in different windows) to run on a single thread. Not doing that breaks websites.
2) All the DOM code is single-threaded. Changing that would involve some nontrivial locking overhead. Might be worth it as processors become more and more parallel.
3) A lot of other application code is single-threaded in Firefox (though a number of worker threads _is_ used). This would need to be addressed.
Making the runtime support threading is the easy (and done long ago) part.
I just checked, for what it's worth. This bug has never had the security flag removed.
> But not acid3...
Of course that's a matter of acid3 test design. Browsers have been fixing the bugs pointed out by preliminary acid3 versions; as soon as the issue was fixed in browsers, the folks writing the test removed that part and replaced it with a new one.
One of the stated goals of acid3, as I understand it, is that at the moment when the test is declared "final" every single thing it tests must be failed by one or more of then-current-development Gecko, Webkit, and Presto. Which means they're likely to keep adding more and more esoteric tests up to that point.
> and I would consider them to be far more "featured" than Web Browsers
Even if that were true, did they have to maintain large data structures in memory at all times (forced to do so by the DOM specs)? Did they need to try to guarantee 50fps redraw (10ms timeouts being the standard "dhtml" sites use)?
Plus, I'm not sure that your more "featured" is correct. But it's hard to compare features that are so different in concept (controlling hardware vs doing predictive guessing on search terms based on past searches... which is more of a feature? Which takes more memory? Should the past search database be in memory or on disk, for acceptable performance?).
The real issue is that web browsers are trying to do everything at once and please a number of very different demographics (people with 100MB (I kid you not!) HTML files full of tables, people with pages that link in 800MB (again I kid you not) of images, users who want instantaneous response to any action without any memory being used to hold partially precomputed results, etc, etc).
Really, you can have fast, low memory usage, or doing all the bells and whistles people want out of a browser. Pick two, or maybe even one and a half.
> It is surprising that one is not able to disable JS on a per site basis by default.
You mean surprising that there is no user interface for this? The back end has support; setting a few preferences (to indicate which sites you're whitelisting or blacklisting; both modes are available) does the trick.
Yes. Certain persons affiliated with the W3C were members of the working group that created this RFC. So were others who are not affiliated with W3C directly (though they represent companies that might also participate in the W3C).
That doesn't change the fact that the W3C is not the standards organization responsible for RFC 2616: they don't control its status, and they're not the ones who voted to actually accept it as a standard.
> Given that RFC2616 (written by the w3c)
I'm sorry to break this to you, but anything called an "RFC" is not in fact written by the W3C. RFCs are an IETF thing.
> So why is the unique identify a URL?
Because certain constituencies ("semantic web", etc) feel that URLs (URIs, IRIs, whatever) are a one-size-fits-all tool for identifying everything. That's why XML namespaces are technically recommended to be URIs (though in the end you just to an explicit string match on the namespace and never actually fetch anything from the URI). This is why URIs are used for pointing to parts of the same document. The list goes on and on.
Basically, some people feel they have a hammer and all unique identification problems start to look like nails to them.
Just use html5lib instead of rolling your own; it'll parse pretty much "the same way" for all practical purposes.
Plenty of that as well. Unfortunately, it's hard to find houses for sale near public transit in some areas.
With all the new developments going up recently during the bubble, most of the houses on the market (all in some places) were nowhere near public transit.
Of course whatever planners didn't bother to extend public transit to new multi-thousand-home developments should be fired... but I digress.
IE also relies on the doctype to switch between standards and quirks (though they're planning ot add some bells and whistles in IE8).
> Next time look for bus stops when you buy.
Sometimes that works, sometimes it doesn't. Route changes happen quite often in some public transit systems (I know I've seen changes to the same route less than a year apart here in Chicago). In the process, houses that used to be quite near a stop can end up very far away.
> Here are a few Firefox flaws.
;) More to the point, given a choice between fixing two bugs that have equal impact, but one of which does not require extended troubleshooting while the other does, the choice is clear: fix the one that doesn't need troubleshooting. It's the obviously efficient choice, if the payoffs are really the same: it fixes one of the two equivalent bugs and leaves time to also fix other bugs. If there are enough developers that there are people idle, this calculus goes out the window, of course. But that's not the situation Mozilla (or any other software project I've ever encountered) is in.
Did I ever say there are no flaws? Please point to where I said that!
Given that I've personally filed 1800-some bugs on Gecko and Firefox over the last 8 years or so, I'm quite aware that there are flaws. My point was that there are fewer flaws than there would be if no one were being paid to work on the browser. I note that you carefully avoided responding to this point.
> especially when the computer has been put into hibernation
Which Firefox version are you seeing this problem with? There was https://bugzilla.mozilla.org/show_bug.cgi?id=213637 but that claims to be fixed as of Firefox 2.0.0.8 or the latest Firefox 3 betas. If you're seeing high CPU usage after hibernation with something newer than that, please file a bug and cc bzbarsky atsign mit dot edu.
> Abuse by the developers of those who report bugs:
Are you sure they were developers and not just people who created a (free) account in the bug database and then started triaging bugs? The latter happens quite a bit. If people are being abusive, please report them to gerv atsign mozilla dot org. That sort of thing is unacceptable.
> That's been the response to the CPU hogging bug reports I've seen.
Can you please point me to these bug reports? I'd appreciate that very much.
> They don't seem to want to work on bugs that require extended troubleshooting.
Of course not! Who does?
Of course payoffs depend on things like the severity of the problem, its ubiquity, etc. They can be hard to peg down precisely, and it may be that in some cases people underestimated the impact of a bug. Can you point me to specific high-impact bugs that are being avoided because of a need for troubleshooting?
> Firefox cannot be made portable
I can't speak to this, since I've never tried to do it, to be honest.
> Firefox will not allow multiple instances.
Right. The profile system inherited from Netscape is a bit of a mess. I've never seen anyone deny this.
> Firefox session restore is not reliable.
Is there a bug filed for this issue? If there is, can you please cc bzbarsky atsign mit dot edu on it? If not, can you either file or provide reliable steps to reproduce so that I would be able to file it myself?
> Firefox hogs memory.
Yes. It's being worked on. See Stuart Parmenter's weblog and the large amount of work done on leak fixing.
> while continuing to deny that any exist.
I'm going to call your bluff here, sorry. Can you point me to one instance of an active Firefox developer denying that memory issues exist? (Note: Ben Goodger is not active, and wasn't by the time he posted the blog entry people live to cite.)
> Firefox advertises extensions, then blames them for problems.
This is an issue, yes.
> A common topic of articles about Firefox is some variation of "How to make Firefox work the
> way it should".
Are these articles written by Firefox devlopers?
> Often Firefox developers blame Firefox extensions advertised on the Mozilla web site.
Advertised where, exactly? The link to addons.mozilla.org from www.mozilla.com?
> does not seem to produce faster results than Firefox developed by volunteers.
I'm sorry, but that's clearly false. Just compare the changes in the rendering engine between Gecko 1.7 and Gecko 1.8 to those between Gecko 1.8 and Gecko 1.9. The latter are much more extensive and would never have happened without the sort of funding that's been available over the last few years. As a simple example, if development had proceeded the same way it had right after the Netscape division at AOL was dissolved, there is no way Gecko would be passing Acid2 right now.
Do keep in mind that there is a lot more to Firefox than just the user interface. If you're comparing the user interface evolution right now to what was happening in the Phoenix 0.6 timeframe, then of course there is less "progress". The 80/20 rule applies to interfaces just as much as anything else.
As for the CEO thing, having met Mitchell and talked to her I would be inclined to take what she says at face value. She's been taking less and less of a role in the actual administrative aspects of running the corporation, and it makes sense to have the titles match the actual work being done.
Frankly, it sounds to me like you have a chip on your shoulder against Mitchell and the Mozilla Corporation for some reason, and it's clouding your judgment and keeping you from doing some basic research to verify your claims...
> Once the problem was made obvious, fixing was easy.
This is true of most bugs period. These are not the bugs that take the majority of the time to fix.
> The CPU hogging bug was reported 6 years ago
"The" CPU hogging bug? I've seen dozens (if not hundreds) of "uses too much CPU" bugs reported. A number have been fixed. Some have not, usually because they have proved impossible to reproduce, and thus impossible to debug. At that point, other bugs with equal payoff but lower investment needed get worked on. Which exact bug are you thinking about here?
> Very serious shortcomings in features, like the fact that Firefox can't be made completely
> portable and the session restore often doesn't restore all tabs, have been ignored.
Very possible, yes. No one is claiming perfection for Firefox, or any other software project. I haven't kept as much track of the UI sort of things you're complaining about here as much as I have of the Gecko end of things, so I'm not really qualified to comment on it.
> Many of the "advances" in Firefox were documents that indicate how to make Firefox operate
> the way it should, blaming crashes on plugins, for example.
Hold on. There are crashes in plug-ins at times. This is a fact. The browser can try to mitigate this problem by running plug-ins in a separate process (and somehow dealing with them trying to paint directly to its memory). The fact that Gecko doesn't do this is a somewhat poor design decision and definitely needs to be fixed.
Given that this is the state of things, however, documenting that certain plug-ins crash in certain situations is not unreasonable. Labeling it as an "advance" is unreasonable, of course. Can you point me to a document with such documentation being labeled as an "advance"?
50 programmers might be right ballpark, but might be a little high. It's hard to say; I don't have that information (nor do you). It depends on how many people are in marketing, QA, etc.
For the rest, I don't know where you're getting your information, but it's pretty bogus. Coverity has never uncovered any memory or CPU consumption bugs in Gecko or Firefox that I've seen (nor could it, given what it finds). They have found a few memory-safety issues, and lots and lots of false positives.
There were indeed no feature updates on the _stable_ release branch. The work has been going on in the development trunk (slated to become Gecko 1.9 and Firefox 3). I don't see you complaining that IE7 has had no feature updates, or that Safari 2 had no feature updates until Safari 3 got released. Same thing here. If you want to see what people have been working on, grab a build of Firefox 3 beta 2.
> they made it clear they don't do the difficult kinds of troubleshooting, just the easy
> kinds.
First, this is simply false. I suggest you look into the sort of work Stuart Parmenter has been doing. There are others doing equally difficult work, but he's actually been blogging about what he's up to; for others you'd have to read bugs and/or their progress reports.
Second, given the choice between easy troubleshooting and difficult troubleshooting, with equal payoff, the easy troubleshooting is what will happen every time. It's a basic resource-allocation situation: finite resources allocated for maximum effect. Therefore, as long as there are more problems than people available to work on them, the easy problems are the ones that will get fixed. This assumes equal payoff, of course. But in fact, there has been no shortage of clearly reported, reproducible, well-explained bugs that cover things like "Firefox uses too much memory" until recently. So those bugs were the ones getting fixed, instead of the vague, unreproducible ones. Once the pool of things that were easy to fix dried up, the payoffs became unequal, which is why there is more focus now on hunting down things like memory fragmentation.
> That's enough for 200 programmers each earning $100,000 per year.
No, it's not. If someone earns $100,000 per year, that means that the employer is paying:
$100,000 salary
$7000-ish FICA
$10,000-ish benefits of various sorts
This does not include costs for things like:
* Building rent
* Computer equipment
* Unemployment insurance (varies by state)
* Travel reimbursements (a lot of the Mozilla work is distributed)
* Participation in conferences and standards organizations (W3C membership, e.g.)
and probably various other things I don't know about, not having ever employed anyone.
A good estimate is that an employee's cost to the employer is 1.5-2 times the salary.
As a matter of fact, the Mozilla Corporation employs on the order of 100 people. Some are programmers. Some are QA. A few are administrative staff. This is consistent with the factor of 2 multiplier.
> Yet in 2006, there were only a few somewhat minor updates to Firefox and Thunderbird.
And a lot of serious development on the next major versions of both Gecko and Firefox. It's not like this is being done in hiding, or anything; all the work is public. You also seem to underestimate the amount of work required for the security updates. Fixing security bugs on a stable branch (which doesn't allow major architecture changes) without breaking functionality is often very difficult.
> The question is, "Why isn't the money being spent on Firefox development?"
The answer has been publicly stated several times by Mitchell, for what it's worth. The money is not being spent because:
1) [Less important] Hiring competent people is hard (and you don't want to hire too many at once, because then all the time will be spent training them and not getting work done. See also The Mythical Man-Month. As a result, revenue growth (which in this case is directly correlated with usage growth) has simply outstripped expenses (which are limited by number of employees in this case, if money doesn't get wasted).
2) [More important] If tomorrow Google decides to be evil, or starts giving worse search results than a startup search engine, or decides to ship its own browser and not pay for searches from Firefox anymore, money in the bank means that development can continue until other funding sources are found. Put another way, why aren't you spending all the money you earn? You do save some, right? Why do you save it?
Amen to that! What happened to just liking (or not) a product without turning it into a religion?
> If no regulations exist, then banking in Second Life can't be trusted at all.
Strictly speaking, this is not true. You could have a situation where banks promise that they are not running a Ponzi scheme and voluntarily submit to audits by either auditing experts or account holders or both.
That is, instead of having external regulation imposed, have self-imposed regulations and enough transparency that it's clear you're following them.
The problem then is account holders having to understand the regulations. Or having to pay someone (said auditing experts) to make a call on whether the bank is trustworthy.
This isn't to say that such a setup is necessarily better than imposed regulation, but that it could be a viable alternative depending on circumstances. Both involve a lot of infrastructure existing; it just happens that government (needed anyway for things like common defence) provides ready-made infrastructure for the imposed-regulation approach.
> Firefox said they didn't have any bugs
Really? Can you actually point to any instance of anyone actively working on Firefox who said anything like this? Note that Ben Goodger's blog post saying that _some_ (not all) instances of memory usage may be due to the back-forward cache came after he was no longer particularly active.
At no point have I ever seen anyone say anything resembling "doesn't have any bugs", and I would very much like to see your source for this. Or are you just regurgitating slashdot group-think?