Will it be by mid-2011, which is the earliest point that Firefox 3.6.x would stop receiving security updates? And that's assuming they hit their end of the year release target for 3.7, which is the version that would be dropping 10.4 support.
The 10.4-supporting Firefox 3.6.x series will be getting security updates at least until mid-2011 (assuming the non-10.4-supporting 3.7.x or whatever they end up calling it series ships by the end of the year as planned). It's not inconceivable that it'll end up being longer than that given that Firefox 3.0.x still receives security updates.
It's discussed in the discussion thread also, but it's a matter of what resources it takes to continue support. In the case of Win2K/XP, maintaining compatibility doesn't require nearly the resources that maintaining 10.4 compatibility does. OSX tends to change a LOT between the various 10.x releases, far more than Windows.
Also, it's important to note that this is being discussed for the next major release of Firefox - i.e. 3.7 or whatever they end up calling it. If they hit their targets, that won't be out at the earliest until the end of the year. Adding in security updates, 10.4 users wouldn't be left out in the cold until the middle of 2011 at the earliest. It stands to simple reason that the proportion of 10.4 is only going to continue dropping over the next year and a half. Why should Mozilla continue to devoting limited resources to an OS that requires disproportionate resources to support at that point?
*citation please
Seriously, show me where the developers have ever said "There's no such thing". And don't start with the ancient blog post by Ben Goodger (a Chrome developer now, BTW) which even Mozilla developers have refuted. Honestly, I keep seeing this tripe posted as fact but nothing to actually substantiate it. Fanboys != Developers.
No reasonable person would expect unit testing to produce bug-free software, but I don't think it would be unreasonable to say that it should at least be able to prevent regressions of previously-found bugs. If this is truly the same bug as was previously discovered and patched (and not some variant of it), why wasn't a test created to catch any reintroduction of it in all future builds?
Even if there was a test for SMB and not SMB2, wouldn't it have made sense to port whatever relevant tests existed for SMB to avoid any glaring regressions like this one?
I'm sure it's more complicated than I'm making it out to be, and I want to give them the benefit of a doubt on this, but it seems to me that this is something that could have been avoided with better planning.
Yes, because surely Mozilla has the same people working on the front-end that would otherwise be working on performance and stability. It's not like different developers within a team might specialize in different areas or anything.
Honestly, I think I'd be more troubled if that actually were the case...
I think the plan for Gecko 2.0 has changed since Brendan's post a couple years ago, shifting in favor to smaller, incremental improvements with shorter lead times instead of long, drawn-out changes creating release gaps like the one between 2.0 and 3.0.
Yes, they've done a lot of work to reduce the number of fsync() calls used. There are numerous bugs filed tracking that work. More work is still planned, but it should already be in better shape than 3.0.x was.
In the advanced options, under the general tab, you can have Firefox warn you about automatic redirects with an information bar instead of just going. Yeah, it's a bit of a workaround to the problem, but you may find it useful.
I don't see why the risk would be any greater than it was going from 2.0-->3.0 or 3.0-->3.5. All have been based on new Gecko versions. Furthermore, as I said before, their unit test framework has improved substantially over time to help prevent layout regressions from occurring. The only exception I could see from that would be in cases where the rendering had to change for proper spec compliance or where the existing tests were lacking (in which case, file a bug!).
Because Mozilla has such a track record of doing that, right? By the way, have you ever looked into the amount of unit tests they run after every build to ensure that there are no functional or visual regressions?
1.) Service Packs are cumulative. You don't have to install all 3. You can just install SP3 and be done.
2.) SP3 can be slipstreamed directly into the install CD so that you don't have to install it after the fact. Google it.
Everyone remembers FF devs flaming people in those FF memory leak stories from a few years ago
I don't remember any Firefox developers flaming people about memory issues. I remember fanboys doing it, but there's a big difference there. The only "official" response I know of from any Firefox developers was Ben's "It's a feature, not a bug" blog post from 2005, which is long-obsolete. Ben doesn't even work for Mozilla anymore (ironically, he's on the Chrome team now).
uh...looking at the Google Chrome team page, I can immediately pick out the following people as being ex-Mozilla employees or contributors: Ben Goodger, Darin Fisher, Brett Wilson, Peter Kasting, Mike Pinkerton, Jonathan Haas, Pam Greene, Jungshik Shin
I'm sure there are more that I'm not aware of, but those are all certain.
Slashdot Mirror
Will it be by mid-2011, which is the earliest point that Firefox 3.6.x would stop receiving security updates? And that's assuming they hit their end of the year release target for 3.7, which is the version that would be dropping 10.4 support.
They actually used to use the OSX spellchecker and stopped because it had major issues with dictionary support.
Here's the bug for it
The 10.4-supporting Firefox 3.6.x series will be getting security updates at least until mid-2011 (assuming the non-10.4-supporting 3.7.x or whatever they end up calling it series ships by the end of the year as planned). It's not inconceivable that it'll end up being longer than that given that Firefox 3.0.x still receives security updates.
It's discussed in the discussion thread also, but it's a matter of what resources it takes to continue support. In the case of Win2K/XP, maintaining compatibility doesn't require nearly the resources that maintaining 10.4 compatibility does. OSX tends to change a LOT between the various 10.x releases, far more than Windows.
Also, it's important to note that this is being discussed for the next major release of Firefox - i.e. 3.7 or whatever they end up calling it. If they hit their targets, that won't be out at the earliest until the end of the year. Adding in security updates, 10.4 users wouldn't be left out in the cold until the middle of 2011 at the earliest. It stands to simple reason that the proportion of 10.4 is only going to continue dropping over the next year and a half. Why should Mozilla continue to devoting limited resources to an OS that requires disproportionate resources to support at that point?
*citation please Seriously, show me where the developers have ever said "There's no such thing". And don't start with the ancient blog post by Ben Goodger (a Chrome developer now, BTW) which even Mozilla developers have refuted. Honestly, I keep seeing this tripe posted as fact but nothing to actually substantiate it. Fanboys != Developers.
No reasonable person would expect unit testing to produce bug-free software, but I don't think it would be unreasonable to say that it should at least be able to prevent regressions of previously-found bugs. If this is truly the same bug as was previously discovered and patched (and not some variant of it), why wasn't a test created to catch any reintroduction of it in all future builds?
Even if there was a test for SMB and not SMB2, wouldn't it have made sense to port whatever relevant tests existed for SMB to avoid any glaring regressions like this one?
I'm sure it's more complicated than I'm making it out to be, and I want to give them the benefit of a doubt on this, but it seems to me that this is something that could have been avoided with better planning.
One would hope that they'd have a suite of unit tests that would catch something like this, though.
Yes, because surely Mozilla has the same people working on the front-end that would otherwise be working on performance and stability. It's not like different developers within a team might specialize in different areas or anything.
Honestly, I think I'd be more troubled if that actually were the case...
Yes
I think the plan for Gecko 2.0 has changed since Brendan's post a couple years ago, shifting in favor to smaller, incremental improvements with shorter lead times instead of long, drawn-out changes creating release gaps like the one between 2.0 and 3.0.
No, though it should be noted that the download manager doesn't open by default since version 3.0, instead going in the status bar.
Stuart Parmenter made a RAMBack extension that may do what you're looking to do.
Yes, they've done a lot of work to reduce the number of fsync() calls used. There are numerous bugs filed tracking that work. More work is still planned, but it should already be in better shape than 3.0.x was.
See bug 418866 for some guidance.
Doesn't Chrome's address bar work pretty much the same as Firefox 3's? Not to mention Opera 10. Not sure about Safari.
In the advanced options, under the general tab, you can have Firefox warn you about automatic redirects with an information bar instead of just going. Yeah, it's a bit of a workaround to the problem, but you may find it useful.
I don't see why the risk would be any greater than it was going from 2.0-->3.0 or 3.0-->3.5. All have been based on new Gecko versions. Furthermore, as I said before, their unit test framework has improved substantially over time to help prevent layout regressions from occurring. The only exception I could see from that would be in cases where the rendering had to change for proper spec compliance or where the existing tests were lacking (in which case, file a bug!).
You can slipstream SP3 into an SP0 disc. I've done it personally with no ill effect.
Because Mozilla has such a track record of doing that, right? By the way, have you ever looked into the amount of unit tests they run after every build to ensure that there are no functional or visual regressions?
1.) Service Packs are cumulative. You don't have to install all 3. You can just install SP3 and be done. 2.) SP3 can be slipstreamed directly into the install CD so that you don't have to install it after the fact. Google it.
hmm, I think I was thinking of Dave Haas. Oh well. Thanks for clarifying.
Is it starred by chance? (To my annoyance,) entries can't be deleted unless they're un-starred first.
I don't remember any Firefox developers flaming people about memory issues. I remember fanboys doing it, but there's a big difference there. The only "official" response I know of from any Firefox developers was Ben's "It's a feature, not a bug" blog post from 2005, which is long-obsolete. Ben doesn't even work for Mozilla anymore (ironically, he's on the Chrome team now).
See bug 273310 (not that there's much there to help)
uh...looking at the Google Chrome team page, I can immediately pick out the following people as being ex-Mozilla employees or contributors: Ben Goodger, Darin Fisher, Brett Wilson, Peter Kasting, Mike Pinkerton, Jonathan Haas, Pam Greene, Jungshik Shin I'm sure there are more that I'm not aware of, but those are all certain.