So, it's Labor Day weekend and I've spent it watching Law and Order DVDs, painting the house trim and tweaking TenFourFox. Today, for those of you with nothing better to do on a holiday weekend either, 7.0 beta 1 is available, roughly corresponding to Firefox 7 beta 4. Generally I am loathe to talk about subjective speed improvements in this blog because they are just that, subjective. However, there is a lot to like about Fx7, and the biggest one isn't the memory footprint improvements (because we're forced to take a hit on that, read on). Instead, it's the graphics stack, and the new Cairo really benefits our rendering pipelines. Pages paint quicker, animations are snappier and movie playback is less jerky. The improvement is subtle, and there is still much improvement to come, but I think virtually everyone will notice the difference. Tobias, the early trailblazer on 7, said it was the first version he felt was truly useable on his PowerBook. While I politely demur that I've been perfectly happy with TenFourFox on my iBook G4 ;) , I certainly do agree that 7 is better in nearly every metric.
Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.
Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D
So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.
Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.
A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.
We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.
Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.
Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.
I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.
In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.
For now, read the 7.0 beta release notes, and grab for your architecture:
Sunday, September 4, 2011
Wednesday, August 31, 2011
6.0.1 now available
6.0.1 is now available. As mentioned in the previous blog entry, this repairs the issue with fraudulent SSL certificates released by DigiNotar. Please note that all previous versions of TenFourFox are vulnerable to these certificates, so you are strongly urged to upgrade. There are no other changes to this version, and as such, there is no new changeset pack for builders (the old 6.0 one continues to apply to the current release repository). Read the release notes, then grab for your architecture:
Tuesday, August 30, 2011
6.0.1 chemspill imminent
Mozilla has decided to release a 6.0.1 chemspill due to a nasty issue with more fraudulent SSL certificates being issued through a compromised certificate authority (DigiNotar). Unlike the earlier issue that brought us 4.0s back in the day, this one actually requires the entire root certificate to be withdrawn because it is believed that the CA is completely pwned (rather than just a matter of blacklisting a few rogue certs). These malicious certificates are believed to already be in the wild, and there's apparently quite a few as Google Chrome's bad certificate count is up by 247! Mozilla is tracking the issue as bug 682927, but it is currently sec-locked pending release.
Obviously this is a serious enough compromise that we will also be issuing a 6.0.1 which is being built on the G5 as you read this. (Classilla users, this fix will be ported to 9.2.3 when I can get the G4 MDD system back online; unfortunately Classilla development is stalled entirely until my connectivity is restored.) I plan to have 6.0.1 available either tomorrow or Thursday. Although issue 85 has a fix, I do not plan to have it ride along with this release because it may increase memory pressure on marginal systems. More about that when the 7 beta emerges, which I plan to work on as soon as Mozilla certifies beta 3 (probably this week also).
Obviously this is a serious enough compromise that we will also be issuing a 6.0.1 which is being built on the G5 as you read this. (Classilla users, this fix will be ported to 9.2.3 when I can get the G4 MDD system back online; unfortunately Classilla development is stalled entirely until my connectivity is restored.) I plan to have 6.0.1 available either tomorrow or Thursday. Although issue 85 has a fix, I do not plan to have it ride along with this release because it may increase memory pressure on marginal systems. More about that when the 7 beta emerges, which I plan to work on as soon as Mozilla certifies beta 3 (probably this week also).
Tuesday, August 23, 2011
Decisions on 7.0
6.0r is mostly a success, with the majority of users pretty happy with the improvements. We do finally have a reduced test case for issue 84 (the table rendering problem which was reported by some users), but I don't have a cause for it yet since my debugging was limited to what I could do pretending to buy stuff at Starbucks and hiding in the back leeching off the WiFi. With this smaller and fully independent test case I hope to be able to do a more work to that end on the debugging G5. I'm also thinking about grabbing 5.0.1 and making a internal-only build to see if the bug was there too.
On the Floodgap connectivity front, AT&T should hopefully have the T1's NID in by the end of this week, if DSL Extreme's rollout schedule is in any way accurate. Then it's just a matter of running the line into the server room and getting the CSU/DSU up, and we should be good.
Once the T1 is in and we're back in business, I intend to start on Fx7 immediately, which as I mentioned earlier is mostly done already due to Tobias' hard advance work. If it's not, then we might try the emergency repo trick again that we used for 6.0 final, but I'm really nervous about a beta that's going to have no testing at all except for what Tobias himself has done, and I won't have full Mercurial history for debugging. Either way, I intend to deal with this no later than the end of the month. I am hoping to land a few riskier fixes such as a putative fix for issue 72, and put issue 78 to rest at the same time; I also have an idea to deal with user reports of intermittent and inconsistent JavaScript-related crashes, but naturally such bugs intrinsically lack stable test cases and the fix is a bit drastic, so I haven't decided if I'm going to try it or not. (I do have the fix written up, but without a test case, I have no idea if it actually accomplishes what I think it does.)
On the Floodgap connectivity front, AT&T should hopefully have the T1's NID in by the end of this week, if DSL Extreme's rollout schedule is in any way accurate. Then it's just a matter of running the line into the server room and getting the CSU/DSU up, and we should be good.
Once the T1 is in and we're back in business, I intend to start on Fx7 immediately, which as I mentioned earlier is mostly done already due to Tobias' hard advance work. If it's not, then we might try the emergency repo trick again that we used for 6.0 final, but I'm really nervous about a beta that's going to have no testing at all except for what Tobias himself has done, and I won't have full Mercurial history for debugging. Either way, I intend to deal with this no later than the end of the month. I am hoping to land a few riskier fixes such as a putative fix for issue 72, and put issue 78 to rest at the same time; I also have an idea to deal with user reports of intermittent and inconsistent JavaScript-related crashes, but naturally such bugs intrinsically lack stable test cases and the fix is a bit drastic, so I haven't decided if I'm going to try it or not. (I do have the fix written up, but without a test case, I have no idea if it actually accomplishes what I think it does.)
Tuesday, August 16, 2011
6.0r available
Thanks to you sharp-eyed people, issues 81 and 82 have been repaired in TenFourFox 6 (that means printing and print preview should now work correctly again in 10.4, and progress bars shouldn't shimmy around in 10.5), and the fixes are now spun out as 6.0r. I really appreciate everyone's patience with the server downtime and the delay in getting this out, but we've still met the release date, and we're still at source parity with Firefox 6!
To reiterate for people new to this blog, since this is now the "update channel" until I get Floodgap and my business line up again (I just signed a T1 contract with DSL Extreme today, so let's hope that works out), this is the intended final version of TenFourFox 6.0. If you are still using the 6.0 release candidate that came out on Saturday, please download and replace it with 6.0r. The version will still be 6.0, but about: should show a build ID of 20110815. Since there are no other showstoppers, this will replace 5.0, and there will be no subsequent 5.0 or 4.0 releases.
As one more reminder, plugins are disabled by default, and are no longer supported. If you are new to this policy, refer to previous entries in this blog, or see this wiki entry on plugin support.
For builders, there is a new changeset pack up to apply to mozilla-release with the issue 81 and 82 fixes in it.
Please read the revised release notes, and then download the version for your architecture:
To reiterate for people new to this blog, since this is now the "update channel" until I get Floodgap and my business line up again (I just signed a T1 contract with DSL Extreme today, so let's hope that works out), this is the intended final version of TenFourFox 6.0. If you are still using the 6.0 release candidate that came out on Saturday, please download and replace it with 6.0r. The version will still be 6.0, but about: should show a build ID of 20110815. Since there are no other showstoppers, this will replace 5.0, and there will be no subsequent 5.0 or 4.0 releases.
As one more reminder, plugins are disabled by default, and are no longer supported. If you are new to this policy, refer to previous entries in this blog, or see this wiki entry on plugin support.
For builders, there is a new changeset pack up to apply to mozilla-release with the issue 81 and 82 fixes in it.
Please read the revised release notes, and then download the version for your architecture:
Saturday, August 13, 2011
TenFourFox 6: saved by the sneakernet
UPDATE: retracted due to issue 82, respin available tonight or tomorrow
I had a brainwave (well, more like a duh moment) over the weekend about how to sneakernet the Firefox 6 repo updates to the G5 build system, which is still marooned from the Internet. (A parenthetical note about that: I've sent Time Warner the beginning pieces of a lawsuit and basically told them I'm walking away from the contract unless by some miracle the line's in this week. I'm quite certain it won't be. I'm getting bids for a T1, which I probably should have done in the first place; with luck, the downtime won't be more than a week or two more, and then Floodgap will be back in business with a super duper faster line.) So the iBook made several trips to the local Starbucks and back to the house, and several hateful cups of Zen tea later, TenFourFox 6.0 RC/final is built and this post is being typed in it.
I'm a little nervous about this release; there's been pretty much no time for serious conformance testing on all the architecture builds, although the iBook G4 checks out and so does the G5 (what I can test locally). So please thrash it. There's no new features in it, just fixes. The changesets for beta 1 still apply, so there is no new changeset package. If there is a serious showstopper, I did do a cursory security review of Firefox 5, so we can build a 5.0.2 for security parity purposes if needed.
For users new to TenFourFox 6, remember: plugins are disabled (see previous posts).
Looking ahead, Tobias (bless him) has already done just about all the porting work on Fx7 in advance and he says it seems to run really well on his G4. I have his changesets on one of the marooned servers, so as soon as I can snatch the Fx7 repo once it goes beta, we will work on that. I am quite concerned about Fx8, though. Mozilla has landed several changes to the build system that expect builds to occur on 10.6 (even though the build is ostensibly linked against the 10.5 SDK) and obliterate PPC references. This is unwindable (though it will probably hit the vanilla PPC builders such as MonkeyBoy and El Furbe), but may have other side effects, and a simultaneous change to require and use CoreUI for drawing UI elements is also of serious alarm to me as it means our Tiger widget code may no longer work even if we restore the old code. They seem to be having various issues with it, however, as you might expect from an Apple private interface, and I'm hoping they give up and punt it to Fx9.
Watch for a re-release tonight or tomorrow Pacific.Read the release notes, then grab:
I had a brainwave (well, more like a duh moment) over the weekend about how to sneakernet the Firefox 6 repo updates to the G5 build system, which is still marooned from the Internet. (A parenthetical note about that: I've sent Time Warner the beginning pieces of a lawsuit and basically told them I'm walking away from the contract unless by some miracle the line's in this week. I'm quite certain it won't be. I'm getting bids for a T1, which I probably should have done in the first place; with luck, the downtime won't be more than a week or two more, and then Floodgap will be back in business with a super duper faster line.) So the iBook made several trips to the local Starbucks and back to the house, and several hateful cups of Zen tea later, TenFourFox 6.0 RC/final is built and this post is being typed in it.
I'm a little nervous about this release; there's been pretty much no time for serious conformance testing on all the architecture builds, although the iBook G4 checks out and so does the G5 (what I can test locally). So please thrash it. There's no new features in it, just fixes. The changesets for beta 1 still apply, so there is no new changeset package. If there is a serious showstopper, I did do a cursory security review of Firefox 5, so we can build a 5.0.2 for security parity purposes if needed.
For users new to TenFourFox 6, remember: plugins are disabled (see previous posts).
Looking ahead, Tobias (bless him) has already done just about all the porting work on Fx7 in advance and he says it seems to run really well on his G4. I have his changesets on one of the marooned servers, so as soon as I can snatch the Fx7 repo once it goes beta, we will work on that. I am quite concerned about Fx8, though. Mozilla has landed several changes to the build system that expect builds to occur on 10.6 (even though the build is ostensibly linked against the 10.5 SDK) and obliterate PPC references. This is unwindable (though it will probably hit the vanilla PPC builders such as MonkeyBoy and El Furbe), but may have other side effects, and a simultaneous change to require and use CoreUI for drawing UI elements is also of serious alarm to me as it means our Tiger widget code may no longer work even if we restore the old code. They seem to be having various issues with it, however, as you might expect from an Apple private interface, and I'm hoping they give up and punt it to Fx9.
Watch for a re-release tonight or tomorrow Pacific.
G3- G4/
7400 - G4/
7450 G5
Monday, August 8, 2011
Time Warner: still sucks
We're still down and Time Warner Cable Business Class just sent out their third site survey to say, "we'll call you." I've had it with this company. Don't ever do business with them. I'm preparing a complaint to their legal counsel this week; this is unacceptably bad.
The problem is that this means our build system has no access to the Net either, so it can't pull down code and that makes building another 6.0 beta problematic. Unfortunately for us, Mozilla is still planning to release Firefox 6 on schedule, issues with Fennec permitting. One option is to build an interim security release "5.0.2" with whatever patches I can cobble together and then sneakernet the binaries off the G5 so that at least we maintain security parity. If our downtime extends up to that point, then we might try that. However, you'd have to watch this blog since obviously the automatic update system doesn't work either. I'm really hoping they get it together soon, because although I could request for and grit my teeth over a T1, it's going to be itself at least two weeks installation and I can't even start on that as long as I have an enforceable contract with Time Worthless.
I have never dealt with a company this awful, and I'll be doing my darndest not to renew with them when the contract is up. They are truly abysmal. If this is how they treat their business customers, I'm sure many of you have horror stories about how they treat their residential ones.
More as I have more information.
The problem is that this means our build system has no access to the Net either, so it can't pull down code and that makes building another 6.0 beta problematic. Unfortunately for us, Mozilla is still planning to release Firefox 6 on schedule, issues with Fennec permitting. One option is to build an interim security release "5.0.2" with whatever patches I can cobble together and then sneakernet the binaries off the G5 so that at least we maintain security parity. If our downtime extends up to that point, then we might try that. However, you'd have to watch this blog since obviously the automatic update system doesn't work either. I'm really hoping they get it together soon, because although I could request for and grit my teeth over a T1, it's going to be itself at least two weeks installation and I can't even start on that as long as I have an enforceable contract with Time Worthless.
I have never dealt with a company this awful, and I'll be doing my darndest not to renew with them when the contract is up. They are truly abysmal. If this is how they treat their business customers, I'm sure many of you have horror stories about how they treat their residential ones.
More as I have more information.
Subscribe to:
Posts (Atom)