Other than the 24 beta and the 22.1 test release, all the beta and test releases have been removed from Google Code to reclaim as much space as possible, but the changesets are still there if you really want them and know the particular rev to check out from the Mozilla Mercurial repositories. Starting with 24.1 beta (hopefully available by the end of next week), downloads will be offered through SourceForge, and Google Code will be offered the finger. Issue tracking and the wiki will remain here for the time being.
Friday, October 25, 2013
Wednesday, October 23, 2013
Mavericks runs on the same machines 10.8 did, which is to say, no Power Macs, but it is nice that no new machines are left behind. It seems to continue some incremental improvements from 10.8 away from the overly iOSified interface of 10.7 and does not implement the excessive portions of the super flattened iOS 7 aesthetic, but it does not undo some of the irritating interface changes first introduced in 10.7 (scroll bars, ahem), and does not really add much to the underlying operating system other than some truly noteworthy improvements to energy saving. But hey, it's absolutely free. Whaddya want for free?
Instead of a full review -- if you want that, read John Siracusa's typically studious Ars Technica Mavericks analysis -- I think I'll just point out a few things especially relevant to us in the geriatric machine world that most of the 10.9 coverage has missed or not emphasized:
- No one has said what this means for Snow Leopard, and by extension, anyone still having a need to run PowerPC applications or anyone still rocking a 32-bit Intel Mac (or those of us whose token Intel Macs can't run 10.8 and refuse to update to 10.7). I'm presuming nothing good; I was surprised Apple still supported 10.6 with updates after 10.8 came out, and 10.6 is now four years old. Apple has historically not said when support ends for a particular version and it has always been inferred by what doesn't receive updates anymore. The last update as of this writing was in October 2013, consistent with Apple releasing a "final rollup" just before support is dropped in the wake of a new OS release.
- Apple has also declared war on plugins in Safari 7, just as Chrome and Mozilla have. Again, stealing from Siracusa's insanely detailed review, Apple has plugin blocking for both energy and security reasons in 10.9's release. It also shows considerable technical improvement in WebKit2, which because of its greatly improved reliability is now likely to completely eclipse the original WebKit in the very near future, and cannot be good news for Leopard WebKit.
- App Nap, the major power-saving framework in 10.9, is an integral part of Cocoa, and only Cocoa (and only GUI Cocoa apps, at that). Given Apple's increasing emphasis on battery life and power savings, it is eminently possible that this will accelerate the timeframe in which Carbon will be banned entirely from OS X. I would not be surprised if 10.9 is the last version of OS X with any Carbon support, but Apple to my knowledge has not taken the step of banning them from the Mac App Store ... yet.
Australis is still a big question mark. On OS X, there remain significant performance regressions, including some 10.6-specific issues. Now that 10.9 is out, this might accelerate Mozilla's desire to drop 10.6 support because we should expect some of the older Snow Leopard-only computers to get replaced (and drop Mozilla's 10.6 user base proportion), particularly if Apple is perceived to withdraw support. This does not mean that Australis can't be ported to 10.4, and because we are entirely software-drawn does not mean that we will have the same performance issues in exactly the same fashion, but it's a little concerning. It doesn't appear that it will be in Firefox 27 either, and there are still a lot of bugs on all the supported OSes.
The beta for TenFourFox 24 has been mercifully well-received, despite the benchmark regression. Most people find it more responsive overall than 17, which is very encouraging. Other than the known problem with Personas and window redrawing, the only other bug that has cropped up is a rare issue with an unresponsive menu bar. The app still works and can be quit and restarted, but the circumstances are not understood; I personally experienced it once, and I have not been able to trip it since. I do not consider this bug a showstopper at this time. I would appreciate anyone who has reliable steps to reproduce.
17.0.10 is building and should be available for testing by Saturday, our final 17 release. 24.0.1 will be released hopefully late next week as the last 24 beta. I am also planning to attack the 26 beta right away.
Wednesday, October 16, 2013
So, after months and months and months and months of work (that's almost seven months of work, for those keeping score at home), we are now on PPCBC, the PowerPC-specialized form of BaselineCompiler, and our hardworking methodjit is now released to that great tracing monkey in the sky (though a large part of it lives on in the regular expression library, and some portions are still used by Ion). Was it worth it?
IonMonkey, which we don't yet implement, is a high-latency compiler emitting very optimized code. But its latency comes at a price, particularly on single processors where compilation cannot occur in the background. In fact, Mozilla does not even try to invoke IonMonkey until a particular block of code has run at least 10,000 iterations; it doesn't pay off.
BaselineCompiler (I'll discuss PPCBC in a moment), on the other hand, is a low latency compiler, even lower than TraceMonkey. The browser will attempt to compile code running with as few as 10 iterations (!) in Baseline because there is little penalty to doing so: even though it generates low-quality code, the code that it does generate is over four times faster than the interpreter, and because it generates it so quickly the browser can start executing this code nearly immediately. However, it generates code that is about 60% slower than TraceMonkey, and about 7 times slower than JM+TI.
Fortunately, most pages do not have long-running scripts; they have quick-hit scripts, and most of them are using integer or object-based code. This is where PPCBC shines. Pages become significantly more responsive and because we jump into compiled code with a very short delay, there is much less wait. Many, though by no means most, sites fall into this category. YouTube is a site that could go either way, but eBay does very nicely. Gmail feels about the same, but at least it does not regress.
The definitive solution is to implement IonMonkey fully, of course. When fully operational, then after a period of time running, PPCBC-generated code will have accumulated enough type information to allow IonMonkey to emit very nicely optimized sequences, better than JM+TI would have generated for the same input. The good news is that implementing PPCBC first gets us about 2/3rds of the way to Ion since they use most of the same underlying machinery, and it is a predictably performing compiler which is important for our low end systems. (By the way, do not try to enable Ion in the browser. It will crash. You may need to restart it in safe mode to turn this off, so please don't. If you are using the js shell, be sure to start it with the --no-ion option.)
TenFourFox 24 does have better graphics support and improved DOM performance which helps to offset some of this performance loss. We are also using different widget code required by the Australis upgrade, which is improving some of our chrome drawing speed (more about Australis in a moment). I did attempt a build with jemalloc in it, the higher performance allocator that Firefox preferentially uses and that we did attempt an unsuccessful test build with back for the 22.1 release. We scotched it back then for being unable to deal with a memory leak, and jemalloc makes 24 even worse: overnight it ballooned to almost a gigabyte of memory on my quad G5. In addition, the performance delta between regular and jemalloc is much smaller for 24 due to improvements in the core and it only makes a small difference on a subset of sites. So it's not worth the headache now.
The only outstanding bug of significance so far in 24 is a problem with Personas covering up the "traffic light" buttons on redraw (issue 247). It's cosmetic; they repaint when you hover them, and they work normally, so it's just an ugliness that needs to be polished up. This will be fixed for the final release and does not occur with the regular chrome. YMMV, do report as you find them.
Localizers should consider strings frozen for this release, so language packs for 24 can now be created. I am thinking we will have one more beta (24.0.1) to coincide with 17.0.10, and then 24 will replace everything for 24.0.2; langpacks should be ready to go by then. I'll let Chris Trusch comment on the feasibility of that timeframe. Our long-suffering and greatly valued volunteer translators should look for activity in issue 42.
Looking ahead to the future, I am not likely to land Ion on 24 if we can get at least Fx26 running. The reason is simply because I don't know how our systems will deal with it; it's a heavyweight compiler, and it may be too much to be efficient on a G3. We might even only ship it for 7450 and G5, and let G3 and 7400 use Baseline only, which may perform more smoothly on those significantly older machines. However, because PPCBC works fine, Ion is now officially a "solveable" problem given enough time. Evaluating its responsiveness will thus be a big part of the upcoming new unstable branch releases.
What isn't necessarily a solved issue, though, is Australis, the new interface. Some of this code is already in 24, invisibly, and we use some of it for Personas (so fixing the Personas bug is important not because it's cosmetically wacky, but because it's a useful test of code to be used more heavily in a future browser version). However, it still has lots of performance regressions and bugs and it's not even a part of Nightly Firefox builds, just the UX branch; it is now debatable it even makes Firefox 27. Whenever it lands, we need to get Australis working to advance, since almost all of the browser chrome will depend on it; the odds are good as long as 10.6 support doesn't get dropped given our success thus far, but by no means guaranteed.
Anyway, I am relieved that 24 is not an utter disaster. Let me know what you think. I will start working on 26 beta in the very near future as well to kick off our assault on the next ESR, the far-away ESR 31.
Tuesday, October 15, 2013
It does have one downside, and this is a big one: if you already have a machine you're using for AppleShare, you're going to have to put it on something else; it will not run when the regular OS X AFP server is operating. But, assuming you can work around that limitation (or stop it and start it when you're done), I bet this will resurrect a lot of machines with bad optical drives or the like that just need a little push to get back on their feet. In fact, I have a WallStreet I PowerBook G3 with only a CD-ROM that I think I'm going to try to squeeze Tiger onto this weekend ...
... after I release 24, that is. :) I'm typing this in a test G5 optimized build and it seems to work very well. Although it's not all I hoped it would be, it's not the trainwreck I feared it might become and it's absolutely useable. I'm going to flip it over and build a full set of optimized browsers tonight and throw the lab Macs at them this week. The long nightmare is at last coming to an end.
Wednesday, October 9, 2013
As I received no objections from the floor, starting with TenFourFox.next (whatever it is after 24), the 10.4 SDK will be the only supported target for linking and the leftover 10.5 SDK code still in the changesets will be gradually purged as it bitrots. Remember, this is only for linking against the SDK. The browser will still run on 10.5, and you can still build it on 10.5, but the only build target will be to make a 10.4-compatible browser. If you want to look at 10.5 specific code, you could look at Tobias' AuroraFox changesets, though quite a lot has changed since then.
If all goes well, you should have a testing beta of 24.0 at long last in a week or two, and then our localizing team will have a full cycle and then some to do translation work which should be hopefully plenty of time for Chris and our gracious volunteers. The plan will be to migrate everyone to 24.0.2 on 10 December as the new stable branch.
Sunday, October 6, 2013
WebTV, just like it says, was intended for televisions with correspondingly larger fonts and less screen real estate. However, this wasn't really a problem in the early days of the Web when most computers were still limited to 800x600 or less, and while its 112MHz MIPS CPU was not really up to the task even then, it was supported by backend servers that pre-optimized sites for the screen and its 33.6kbps modem. Although the service got off to a slow start, by 1998 it was profitable and had nearly 325,000 users; by 1999 it had 800,000 (as late as 2005 it still grossed $150 million a year with a 65% profit margin). This rapid growth attracted Microsoft, who acquired the company in 1997, later rebranding it as MSN TV in 2001.
Microsoft's strategy then was of course to extend and extinguish, and a captive set-top platform that was theirs to control was a potentially powerful weapon. To encourage sites to design for the constraints of the machine, Microsoft designed a software simulator that mimicked the layout and screen limits, complete with a software remote. I don't remember when I picked it up, and Microsoft hasn't offered it for download in years, but there it was still on my home fileserver. The Mac version, below, runs on any Power Mac with System 7 and will also run on OS 8 and 9 and Classic under 10.4 (click to enlarge).
The part I find most amusing is that it even makes phony touch-tone sounds when it starts up and plays the "Connecting to WebTV" sounds like a real set-top of the time would. (Hint: change the startup URL; it's no longer valid. You can set it to something else in the preferences. Also consider setting it to PAL screen size, since it's a bit larger than the NTSC screen shot above.) In fact, the whole experience is incredibly detailed; you can even get into the TV and channel menus, (try to) look at listings or adjust the screen and TV settings, all from within the simulated WebTV interface just as you would have had to do back then.
Sadly, the browser has aged badly as one would expect. Keeping with the simulation's veracity, you will need to use the keyboard or the on-screen remote to scroll and select links. It has some limited scripting and Floodgap's pages, which are admittedly written to work with browsers as old as Netscape 3.0, still look okay on it, but searching Google is a little iffy and sites depending on CSS or with loads of embedded tables turn into narrow strips of text sprawling across the page. While it had an advanced SSL implementation for the time, and its encryption strength finally convinced the US government to stop classifying browser encryptions as munitions, it's almost useless with today's security standards.
But that's not what we're here today for. We're here to bow our heads in memory of a pioneering service that, despite several hardware upgrades and incremental improvements, is now mostly obsolete thanks to today's ubiquitous mobile devices and greater broadband availability. And that's good news, even as WebTV slips into that great modem pool in the sky. At least now we'll get to preserve a little bit of history.
Still working on getting 24 off the ground. Very crashy still, but it's getting further and further through the process. No ETA on a beta yet, but shooting for the next two weeks.