The zune wasn't a failure. [...] There is nothing technically wrong with it.
The Zune came out six months before Apple introduced the iPhone.
Even if there was "nothing technically wrong with" the Zune, if you seriously believe it was the right product at the right time, I have a portable CD player to sell you...
For some reason, I think [it's] not quite right [to say that FFOS is "an OS built in HTML5"]. Perhaps the intent was to write "an OS with built in HTML5"?
FFOS developer here.
The entire FFOS front-end is written in HTML5. That includes the homescreen and the task switcher. So "The Web" is the API that applications use to communicate with the system.
But there's of course plenty of C/C++ below that. To a first approximation, it's probably accurate to guess that parts of Android written in Java were re-written in JS for FFOS.
even today's high-end devices struggle with a modern web pages.
At some point, designers are going to have to make concessions. cnn.com takes hundreds of MB of RAM to render in Firefox. It's a huge hog, loading hundreds of resources. That's just not going to work on a phone with limited memory; you're right that there's only so much optimization we can do.
But the idea isn't to run desktop Gmail or desktop CNN on your phone. If our competition is "native apps", all of which are purpose-built for the OS, I don't think it's unreasonable to expect app developers to make at least/some/ changes to their sites to make them work well on our devices.
that, and web apps can't tap into the hardware as well as "native" (note the quotes) apps. you can talk about extensions, but then you are asking devs to write FF OS apps, not web apps, and you are right back in WebOS land.
One difference is that Mozilla's "extensions" (and ohboy do we have them) can become part of Firefox and the general web platform. As a simple example, we added an API for reading the state of your battery. That's primarily useful on phones (and I believe we support it on both Firefox for Android and Firefox OS), but we added it to desktop Firefox, too, so you can read your laptop battery's charge.
Of course, not all APIs are relevant to all devices. If you want to frob the device's vibrator, well, that's probably not going to work so well on a laptop. But the idea is for all of our extensions to become standardized (that is, to no longer be "extensions"), and for them to be available on more platforms than Firefox OS, where applicable.
i'm sure you can rattle off some differenes between FF OS and [WebOS and iPhone web apps] but unless there's something profoundly different from the user's perspective, i don't see it.
Well, WebOS didn't fail because the web stack was a fundamentally bad user experience; in contrast, I know a lot of people who really liked the UI. It failed for a variety of reasons, but in terms of UX, it wasn't particularly performant. In this realm, I think Mozilla is in much better shape: We have a large team of Gecko experts working on the performance of our device; thus far, we've been able to get pretty decent perf on super-low-end hardware. In contrast, Palm didn't have any expertise in WebKit, and this has been cited as a reason they were unable to make it fast.
For all the talk about "native" apps, keep in mind that Java is not a native instruction set. It's interpreted and JIT'ed on Android just like JavaScript.
Well, smartphones all got native progams because anything else is just too inefficient. I don't really see what's changed.
The question is whether the inefficiency was a result of web technologies themselves, or their implementations. I don't think we have a definitive answer to that yet.
The developers of WebOS simply didn't have the kind of expertise with WebKit that Mozilla has with Gecko. We're able to optimize the hell out of this thing.
there's this little company called Google that has this thing called ChromeOS. it is EXACTLY [Firefox OS]... an OS that boots into a browser. it's not lighting the world on fire either.
(Firefox OS developer here) This is a common misconception, but Chrome OS is a lot different from Firefox OS, at least from an architectural perspective.
Chrome OS is, as you say, an OS that boots into a browser. You're running a full desktop Linux client, including a window manager.
In Firefox OS, the window manager is an HTML page. Gecko (that is, Firefox) shows the window manager. All your apps, are iframes (with special attributes on them). The browser is an app (a special iframe). The browser's tabs are more special iframes inside the browser iframe. There are a lot of iframes in Firefox OS.
Also note that Chrome OS is not targeting smartphones (afaik). It's really quite different.
I actually thought this was a joke at first glance. So overall they went from white, to grayish, to grayish with some noise, to this. It's so nice working with such a consistent interface.
If only we had more observant people like you using the nightly channel and filing bugs, we might have avoided this rigamarole altogether!
Noooo it is NOT having "security vulnerabilities" because the Pale Moon devs are fixing holes and porting patches themselves so that is not a problem, and they have already said in their forum they are sticking with the V12 UI because they don't like what the Moz roadmap looks like.
Could you link me to this? Here is a post which implies that they have not forked, and are planning to port FF15. I could not find any discussion about porting security fixes on the bulletin board.
Isn't that the point of FOSS? If you don't like the direction you can fork? Well that is what they did, they forked.
Indeed (*), and if that's what they're actually doing, more power to them. I just hope you and others on/. don't get burned assuming that this software is secure.
(*) Although I should point out that this guy is not, in my view, acting in the best FOSS faith, regardless of whether he's complying with the license. In addition, if he is backporting security fixes and not releasing the resultant source, he may be in violation of the MPL.
I've seen with my own eyes the difference on an Athlon X2 I keep at the shop. FF is a little piggy core hog while Pale Moon isn't slamming the shit out of the cores. [...] FF sucks major ass on older chips like Pentium Ds and Athlon X2s while PM is snappy.
If you have a reproducible benchmark or testcase, I'd be really interested to see what's going on. We use SSE extensively on hot paths in Firefox, and our assumption has been that having the compiler insert it elsewhere (as PM does) would not be a win. If that's not correct, I'd like to know.
If you are on Windows try Pale Moon [palemoon.org] which has forked away from FF as of V12 because they too grew tired of UI changes.
Firefox is currently at version 14. If you're using Firefox 12, you're using software with known security vulnerabilities.
It's not clear to me that the Pale Moon guys have actually forked Firefox at version 12; it may just be that they haven't upgraded to the latest version yet. But I seriously doubt that Pale Moon has backported every security fix from FF13 and FF14, and if not, it's insecure.
If you don't like the possibility of getting UI changes every six weeks, use Firefox ESR, or, for that matter, use IE. But you're not doing yourself any favors by running an insecure web browser.
it also has the SSE flags set at compile so its snappier than FF
I can't find the benchmarks on the Pale Moon site anymore, but I looked at them some time ago, and didn't observe that it offered any significant performance improvements. I doubt you'll be able to observe a performance difference due to anything other than the placebo effect.
So, here we have Mozilla saying, "porting Firefox to a process (nee thread) model is too hard, but we're going to build an operating system!"
FWIW, most apps in b2g^WFirefox OS will run in separate processes. The difficulty is specifically in porting Firefox to a multi-process architecture; Gecko is pretty capable of working multi-process.
Yet, Chrome continues to grow in market share, for the same reasons as outlined at the start of Electrolysis. In my opinion, the narrative changed but the conditions on the ground did not.
I totally agree. It's possible that the snappy project will get us many of the performance improvements we want without the trouble of electrolysis -- it's hard to say at this point.
I think part of the problem facing WebOS was that they lacked the WebKit expertise necessary to optimize their platform. We at Mozilla do not have the equivalent problem.
Mozilla has such a long history of abandoning [lawrencemandel.com] really good ideas [mozilla.org] when they turn out not to be easy.
[Insert cliche about how if you're going to climb a mountain, you'd better be willing to turn around and run if you encounter a pack of hungry polar bears.]
While you certainly have a point, I think Mozilla gets treated unfairly in this kind of thing. You'll never hear about Apple's failed projects; they might have a much worse history than we do with this sort of thing, for all either of us knows.
FYI, the multithreaded bug has been recently resurrected. I'm still not convinced it's possible, but bhackett is one of the best hackers at Mozilla; if anyone can do this, it's him.
Can you describe just briefly what image.mem.max_decoded_image_kb and image.mem.max_bytes_for_sync_decode control?
max_decoded_image_kb is the soft cap on number of bytes that decoded images can consume. We'll try to discard decoded images so we get under this value, with the unfortunate proviso that we'll never discard images on the current tab.
max_bytes_for_sync_decode affects our behavior when decoding previously discarded images. If the image's *compressed* size is less than this value, we'll decode it synchronously. Otherwise we'll decode async. From a practical standpoint, tab switches are blocked until all sync decodes complete, so if you set this too high, you'll observe slow tab switching. If you set this value too low some images may "flicker" into view when you switch tabs.
Fast tab switching is a key goal for us right now, so our plan is to set max_bytes_for_sync_decoded much lower in the near future. (It too is blocked on some stupid things.)
I haven't had much luck finding documentation for these options
Yeah, these prefs are intended to be internal knobs for us to tweak. You're welcome to modify them yourself, but if you notice that Firefox is acting up six months from now, it might be worth resetting them to their default values.
Why aren't they concentrating on just making a seriously good browser engine and then leaving the extra stuff to the extension developers
Believe it or not, 90% or more of our engineering effort goes into "the browser part" (that is, Gecko, our rendering engine, and SpiderMonkey, our JS engine). Have a look through the list of bugs fixed in FF13 to see what I mean.
It's just that these back-end improvements are not things most people can understand -- I work on Gecko and I don't understand most of the changes that go into it -- so PR and the press instead focus on highly visible UI stuff.
My biggest complaint with these memory "improvements" is in regard to image handling:
I agree we haven't done a good job tweaking image discarding parameters. We have a plan to fix it, but it's been stuck on some stupid stuff for a long time. I hope we'll get resolved for FF16.
In the meantime, you can make Firefox much less eager to throw away images. Open about:config and set image.mem.min_discard_timeout_ms to some large value (e.g. 120 000, for 120s), and also bump up image.mem.max_decoded_image_kb (to e.g. 256 000, for 250mb).
Maybe I missed something there, but it adds to my experience that I couldn't hear a *good* explanation about why, and if it is "we think that's better because it's easier for us to handle if we just have one number to increment".
Does it occur to you that this is the tiniest nit of nits? It's a version number. Perspective.
I think it's unfair to say "they made this one change I don't understand, and it signals the end!". But it's even worse to do what you've done and say "they made this change, which is horrible" and mean "this change isn't such a big deal, but I fear what it portends." You admit that you don't say what you mean, and you wonder why we don't listen?
But if you want an explanation, here it is: In the new rapid release scheme, all releases are equal. There are no "major" and "minor" releases. There's just the next release.
If we labeled these releases as Firefox Major.Minor, that would be a lie. People would conclude incorrectly that an update from FF 5.1 to FF 5.2 is somehow smaller than an update from FF 5.2 to FF 6.
If there are no major and minor releases, it makes no sense to have major and minor version numbers.
Now, maybe you think we should have major and minor releases. I hope this is no longer a problem now that you can download ESR.
Maybe I should just write an extension that re-labels Firefox N as Firefox 3.6.(N + 24). I'm sure that would make me a hero to some.
I am frustrated with the latest development of things (Gnome3, Ubuntu/Unity, Android)...it feels like the developers of The Good Old TimesTM have been replaced with "We need more shiny and less configurable stuff!" developers which mainly orientate themselves at MacOS and friends. We all fear that Mozilla goes down that road, too...well, don't get me wrong and please excuse dragging that dead horse out here, but the change of the version-scheme was the start for many of us. It did not seem to follow anything except "Google does it, so we must do it, too", or at least it feels that way because we/I do not understand why you can't do more frequent releases with staying with the previous version scheme
This is the most cogent explanation I've ever heard for the anger over the version numbers thing. Thanks.:)
But here's the thing: We made one decision you didn't understand. It's a version number. Seriously,/. in particular made such a huge deal over this, you'd have thought we were adding mandatory a porn filter.
What I think is missing here is perspective. Believe it or not, more people use Firefox who don't read/. than who do. If you say "I don't care about new features; I care only about X", as an earlier poster did, and Mozilla adds new features despite your protestations, take a moment to try to see things from someone else's point of view.
The same goes for the status bar, the awesomebar, tabs on top, and the version numbers. Try and have perspective; try and empathize. Is it really the end of the world (or the beginning of the end)?
Mozilla is the only web browser developer fighting for you. We're responsible to no higher goal than keeping the Web open and free. Even if you think Mozilla is run by a bunch of idiots and Firefox will never approach the quality of v3.6 again, I think we deserve some credit for what we have done and continue to do on behalf of all those who use the Web.
But it does feel like it, "you don't need to know what version you're running, because if it is old you just need to push this button to get the newest". It feels like removing control from a users point of view.
So your argument is "If Mozilla removes the version number from the 'about' dialog, next thing you know, they'll force us all to run the latest version."? This is known as the slippery slope fallacy. You may wish to familiarize yourself with it.
Your larger argument is that "marketing" (of which Asa is not actually a member) runs the show at Mozilla, and engineering needs to take back the reigns. But notice that bug was WONTFIX'ed -- it didn't happen. Shot down. So this is a particularly poor example of your point; it in fact is evidence for the opposite.
I'm sorry that we've lost your confidence. I really am. I wish we hadn't, and I'm posting here in an effort to restore this community's confidence in us. But you and the rest of the people in this thread are not doing any good by repeating, apparently without thought, the same lines about "bloat" and "bugs" and "marketing" that have been floating around/. for years.
Specifically with respect to 3.6 being faster than current: That's a testable claim. I'd love to see a benchmark -- literally any repeatable benchmark -- which runs faster in Firefox 3.6 than in FF 12. I suspect we'd consider that to be a bug.
That bug is not titled "make it impossible for people to run old versions of Firefox". I know Asa is unanimously hated here, but you can't just pull a random bug and say he's advocating for something he's not.
On a more serious note: What is really going on over by you? I have the feeling marketing took over Mozilla...
For example, the bug you linked was landed in Firefox over the objections of those of us in engineering. Oh, wait...
It's fine to have options. But if they are hard to find them it kind of defeats the point of having them.
We have no interest in forcing you to run the newest version. But we do have a vested interest in most users running the latest version. Only the latest versions get security updates. Only the latest versions get performance and memory usage updates. Only the latest versions get new web features.
Maybe you don't care about some or all of these things. That's totally cool. But what benefit is to be gained by going out of our way to provide buggy, slow, insecure, unsupported, and out-of-date software to our users? Do you think most people could even give informed consent to run such a version of Firefox?
Like I said, we're not hiding these old versions. Even if you can't find them with Google (the FTP server is linked to from the fourth hit for "old firefox versions" for me; it's the first mozilla.org hit), post on any Mozilla mailing list, drop in on irc.mozilla.org at basically any time of day or night -- for goodness sake you can even post on a site like this one -- and I can almost guarantee one of us will see it and give you that link. I don't think we've set the bar particularly high here.
We don't design Firefox or our websites for the top 1% most computer-literate users. If we did, Firefox's options menu would look a lot more like Eclipse's, and we never would have gotten rid of the status bar.:)
Slashdot Mirror
The Zune came out six months before Apple introduced the iPhone.
Even if there was "nothing technically wrong with" the Zune, if you seriously believe it was the right product at the right time, I have a portable CD player to sell you...
FFOS developer here.
The entire FFOS front-end is written in HTML5. That includes the homescreen and the task switcher. So "The Web" is the API that applications use to communicate with the system.
But there's of course plenty of C/C++ below that. To a first approximation, it's probably accurate to guess that parts of Android written in Java were re-written in JS for FFOS.
These are good questions.
At some point, designers are going to have to make concessions. cnn.com takes hundreds of MB of RAM to render in Firefox. It's a huge hog, loading hundreds of resources. That's just not going to work on a phone with limited memory; you're right that there's only so much optimization we can do.
But the idea isn't to run desktop Gmail or desktop CNN on your phone. If our competition is "native apps", all of which are purpose-built for the OS, I don't think it's unreasonable to expect app developers to make at least /some/ changes to their sites to make them work well on our devices.
One difference is that Mozilla's "extensions" (and ohboy do we have them) can become part of Firefox and the general web platform. As a simple example, we added an API for reading the state of your battery. That's primarily useful on phones (and I believe we support it on both Firefox for Android and Firefox OS), but we added it to desktop Firefox, too, so you can read your laptop battery's charge.
Of course, not all APIs are relevant to all devices. If you want to frob the device's vibrator, well, that's probably not going to work so well on a laptop. But the idea is for all of our extensions to become standardized (that is, to no longer be "extensions"), and for them to be available on more platforms than Firefox OS, where applicable.
Well, WebOS didn't fail because the web stack was a fundamentally bad user experience; in contrast, I know a lot of people who really liked the UI. It failed for a variety of reasons, but in terms of UX, it wasn't particularly performant. In this realm, I think Mozilla is in much better shape: We have a large team of Gecko experts working on the performance of our device; thus far, we've been able to get pretty decent perf on super-low-end hardware. In contrast, Palm didn't have any expertise in WebKit, and this has been cited as a reason they were unable to make it fast.
For all the talk about "native" apps, keep in mind that Java is not a native instruction set. It's interpreted and JIT'ed on Android just like JavaScript.
The question is whether the inefficiency was a result of web technologies themselves, or their implementations. I don't think we have a definitive answer to that yet.
The developers of WebOS simply didn't have the kind of expertise with WebKit that Mozilla has with Gecko. We're able to optimize the hell out of this thing.
(Firefox OS developer here) This is a common misconception, but Chrome OS is a lot different from Firefox OS, at least from an architectural perspective.
Chrome OS is, as you say, an OS that boots into a browser. You're running a full desktop Linux client, including a window manager.
In Firefox OS, the window manager is an HTML page. Gecko (that is, Firefox) shows the window manager. All your apps, are iframes (with special attributes on them). The browser is an app (a special iframe). The browser's tabs are more special iframes inside the browser iframe. There are a lot of iframes in Firefox OS.
Also note that Chrome OS is not targeting smartphones (afaik). It's really quite different.
T-Mobile value plans are $40/mo for 500 minutes of talk plus 2GB of data. That's what I was paying on AT&T just for voice.
You have to bring your own phone, and the iPhone is not compatible with their 3G network. But I like my Nexus S well enough.
If only we had more observant people like you using the nightly channel and filing bugs, we might have avoided this rigamarole altogether!
Could you link me to this? Here is a post which implies that they have not forked, and are planning to port FF15. I could not find any discussion about porting security fixes on the bulletin board.
Indeed (*), and if that's what they're actually doing, more power to them. I just hope you and others on /. don't get burned assuming that this software is secure.
(*) Although I should point out that this guy is not, in my view, acting in the best FOSS faith, regardless of whether he's complying with the license. In addition, if he is backporting security fixes and not releasing the resultant source, he may be in violation of the MPL.
If you have a reproducible benchmark or testcase, I'd be really interested to see what's going on. We use SSE extensively on hot paths in Firefox, and our assumption has been that having the compiler insert it elsewhere (as PM does) would not be a win. If that's not correct, I'd like to know.
Try the beta (FF15); it fixes most memory leaks in add-ons.
Open this image of waveforms in Firefox 13+ to see the problem.
Actually, this is fixed in Firefox 15. Go download the beta and try it out.
Firefox is currently at version 14. If you're using Firefox 12, you're using software with known security vulnerabilities.
It's not clear to me that the Pale Moon guys have actually forked Firefox at version 12; it may just be that they haven't upgraded to the latest version yet. But I seriously doubt that Pale Moon has backported every security fix from FF13 and FF14, and if not, it's insecure.
If you don't like the possibility of getting UI changes every six weeks, use Firefox ESR, or, for that matter, use IE. But you're not doing yourself any favors by running an insecure web browser.
I can't find the benchmarks on the Pale Moon site anymore, but I looked at them some time ago, and didn't observe that it offered any significant performance improvements. I doubt you'll be able to observe a performance difference due to anything other than the placebo effect.
FWIW, most apps in b2g^WFirefox OS will run in separate processes. The difficulty is specifically in porting Firefox to a multi-process architecture; Gecko is pretty capable of working multi-process.
I totally agree. It's possible that the snappy project will get us many of the performance improvements we want without the trouble of electrolysis -- it's hard to say at this point.
I think part of the problem facing WebOS was that they lacked the WebKit expertise necessary to optimize their platform. We at Mozilla do not have the equivalent problem.
[Insert cliche about how if you're going to climb a mountain, you'd better be willing to turn around and run if you encounter a pack of hungry polar bears.]
While you certainly have a point, I think Mozilla gets treated unfairly in this kind of thing. You'll never hear about Apple's failed projects; they might have a much worse history than we do with this sort of thing, for all either of us knows.
FYI, the multithreaded bug has been recently resurrected. I'm still not convinced it's possible, but bhackett is one of the best hackers at Mozilla; if anyone can do this, it's him.
Yep, same guy. You have me to thank for most of these changes. :)
I think it ends up being 1-2hr.
As of this bug being resolved, it does not.
max_decoded_image_kb is the soft cap on number of bytes that decoded images can consume. We'll try to discard decoded images so we get under this value, with the unfortunate proviso that we'll never discard images on the current tab.
max_bytes_for_sync_decode affects our behavior when decoding previously discarded images. If the image's *compressed* size is less than this value, we'll decode it synchronously. Otherwise we'll decode async. From a practical standpoint, tab switches are blocked until all sync decodes complete, so if you set this too high, you'll observe slow tab switching. If you set this value too low some images may "flicker" into view when you switch tabs.
Fast tab switching is a key goal for us right now, so our plan is to set max_bytes_for_sync_decoded much lower in the near future. (It too is blocked on some stupid things.)
Yeah, these prefs are intended to be internal knobs for us to tweak. You're welcome to modify them yourself, but if you notice that Firefox is acting up six months from now, it might be worth resetting them to their default values.
Believe it or not, 90% or more of our engineering effort goes into "the browser part" (that is, Gecko, our rendering engine, and SpiderMonkey, our JS engine). Have a look through the list of bugs fixed in FF13 to see what I mean.
It's just that these back-end improvements are not things most people can understand -- I work on Gecko and I don't understand most of the changes that go into it -- so PR and the press instead focus on highly visible UI stuff.
I agree we haven't done a good job tweaking image discarding parameters. We have a plan to fix it, but it's been stuck on some stupid stuff for a long time. I hope we'll get resolved for FF16.
In the meantime, you can make Firefox much less eager to throw away images. Open about:config and set
image.mem.min_discard_timeout_ms to some large value (e.g. 120 000, for 120s), and also bump up image.mem.max_decoded_image_kb (to e.g. 256 000, for 250mb).
Does it occur to you that this is the tiniest nit of nits? It's a version number. Perspective.
I think it's unfair to say "they made this one change I don't understand, and it signals the end!". But it's even worse to do what you've done and say "they made this change, which is horrible" and mean "this change isn't such a big deal, but I fear what it portends." You admit that you don't say what you mean, and you wonder why we don't listen?
But if you want an explanation, here it is: In the new rapid release scheme, all releases are equal. There are no "major" and "minor" releases. There's just the next release.
If we labeled these releases as Firefox Major.Minor, that would be a lie. People would conclude incorrectly that an update from FF 5.1 to FF 5.2 is somehow smaller than an update from FF 5.2 to FF 6.
If there are no major and minor releases, it makes no sense to have major and minor version numbers.
Now, maybe you think we should have major and minor releases. I hope this is no longer a problem now that you can download ESR.
Maybe I should just write an extension that re-labels Firefox N as Firefox 3.6.(N + 24). I'm sure that would make me a hero to some.
This is the most cogent explanation I've ever heard for the anger over the version numbers thing. Thanks. :)
But here's the thing: We made one decision you didn't understand. It's a version number. Seriously, /. in particular made such a huge deal over this, you'd have thought we were adding mandatory a porn filter.
What I think is missing here is perspective. Believe it or not, more people use Firefox who don't read /. than who do. If you say "I don't care about new features; I care only about X", as an earlier poster did, and Mozilla adds new features despite your protestations, take a moment to try to see things from someone else's point of view.
The same goes for the status bar, the awesomebar, tabs on top, and the version numbers. Try and have perspective; try and empathize. Is it really the end of the world (or the beginning of the end)?
Mozilla is the only web browser developer fighting for you. We're responsible to no higher goal than keeping the Web open and free. Even if you think Mozilla is run by a bunch of idiots and Firefox will never approach the quality of v3.6 again, I think we deserve some credit for what we have done and continue to do on behalf of all those who use the Web.
So your argument is "If Mozilla removes the version number from the 'about' dialog, next thing you know, they'll force us all to run the latest version."? This is known as the slippery slope fallacy. You may wish to familiarize yourself with it.
Your larger argument is that "marketing" (of which Asa is not actually a member) runs the show at Mozilla, and engineering needs to take back the reigns. But notice that bug was WONTFIX'ed -- it didn't happen. Shot down. So this is a particularly poor example of your point; it in fact is evidence for the opposite.
I'm sorry that we've lost your confidence. I really am. I wish we hadn't, and I'm posting here in an effort to restore this community's confidence in us. But you and the rest of the people in this thread are not doing any good by repeating, apparently without thought, the same lines about "bloat" and "bugs" and "marketing" that have been floating around /. for years.
Specifically with respect to 3.6 being faster than current: That's a testable claim. I'd love to see a benchmark -- literally any repeatable benchmark -- which runs faster in Firefox 3.6 than in FF 12. I suspect we'd consider that to be a bug.
That bug is not titled "make it impossible for people to run old versions of Firefox". I know Asa is unanimously hated here, but you can't just pull a random bug and say he's advocating for something he's not.
For example, the bug you linked was landed in Firefox over the objections of those of us in engineering. Oh, wait...
Just disable automatic updates, like I said. Maybe the menu is different in 3.6, but I bet there's an option somewhere.
But just to be clear, the reason we're wailing to you about 3.6 is that we've stopped supporting it. It no longer receives security updates.
You're welcome to run an insecure browser if you want, but that's serious shit.
We have no interest in forcing you to run the newest version. But we do have a vested interest in most users running the latest version. Only the latest versions get security updates. Only the latest versions get performance and memory usage updates. Only the latest versions get new web features.
Maybe you don't care about some or all of these things. That's totally cool. But what benefit is to be gained by going out of our way to provide buggy, slow, insecure, unsupported, and out-of-date software to our users? Do you think most people could even give informed consent to run such a version of Firefox?
Like I said, we're not hiding these old versions. Even if you can't find them with Google (the FTP server is linked to from the fourth hit for "old firefox versions" for me; it's the first mozilla.org hit), post on any Mozilla mailing list, drop in on irc.mozilla.org at basically any time of day or night -- for goodness sake you can even post on a site like this one -- and I can almost guarantee one of us will see it and give you that link. I don't think we've set the bar particularly high here.
We don't design Firefox or our websites for the top 1% most computer-literate users. If we did, Firefox's options menu would look a lot more like Eclipse's, and we never would have gotten rid of the status bar. :)