17.0.10 available, for the last time

17.0.10, the final release of 17, is now available from the Downloads tab (release notes). Use the 17.0.9 changesets to build it. Most everyone should know this by now, but there will be no further releases of 17 barring something cataclysmic between this and 24.2. 17 was a solid ESR. I'm sad to see it go. Assuming no reported issues, it becomes final as usual on Monday evening Pacific time.

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.

Tigers eat Mavericks, don't they?

OS X 10.9 "Mavericks," the first in Apple's new line of non-felid versions of Mac OS X, is now out and that can only mean one thing: I have to update our TenFourFox page layout to mock that instead. :) (The 10.9 spoof layout will come out for 24.0.2 final when we decommission 17.)

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.

In port news, IonMonkey PowerPC is evolving, but is not quite up to phase 3 (running simple scripts). It does now get entirely through code generation and optimization after fixing an endian bug in Ion, but I still have to write some of the Ion-specific pieces that I worked around for PPCBC. I'm aiming for a timeframe of 27 or 28, all things remaining equal.

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.

24.0b1 available, plus gdb7 patch 2

At long last 24.0 beta 1 is available (downloads, release notes). Some technical notes: we now also have new build instructions, and you must use the patchlevel 2 TenFourFox debugger to deal with a problem with debugging symbols. You can get that from the Downloads tab as well. I am hoping that our Tenfourbird friend in the Land of the Rising Sun will be able to make the jump to 24 with us.

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?

Let's talk about JIT theory. In general, the lower the latency of a just-in-time compiler, the quicker it generates code, but the poorer the quality of the code it generates (no time for significant analysis or optimization). Our first JavaScript JIT, TraceMonkey, was a tracing compiler that had low to medium latency but therefore had low to medium code quality (and because it was a tracing compiler instead of a method compiler, had a tendency to balloon memory usage and get snared compiling code it shouldn't have; much logic was dedicated by Mozilla to avoiding this sort of unnecessary work). Methodjit was a medium-latency compiler. Implemented as JaegerMonkey, it generated code of therefore medium and acceptable quality, but it had a startup penalty which some users complained about during the transition to 10.0. Type inference "JM+TI" improved the code quality, but required even more latency because the interpreter had to run a certain amount of time to generate type information before JM+TI could spit out code optimized to those types (but once it did, the code it generated was pretty efficient, moving the compiler to medium-high latency, but also medium-high quality).

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.

Because BaselineCompiler cannot make assumptions about the code it runs (methodjit could, because type inference greatly improved its ability to predict at the cost of -- you guessed it -- more latency), it has a dependence on guards to ensure that code that violates its assumptions is properly handled. These guards are an integral part of the inline caches it generates, which are little blobs of code popped out for specific operations as they are run by the JavaScript engine. PowerPC does not do well with branchy code, especially the G5, and because all of our supported CPUs are superscalar we can optimize these commonly emitted type guards with better instruction-level parallelism to reduce branches and improve throughput. That's what PPCBC does, converting these and certain other portions of the inline cache code to PowerPC-optimal straight line sequences, improving our performance on benchmarks by about 15-20% without any penalty to latency. This pulls us to around 40% slower than TraceMonkey, and about 5 times slower than JM+TI.

So by now you should have guessed the tradeoffs, but let's be explicit: virtually all benchmarks suffer. These are long-running sections of code that JM+TI optimized very well, since it had the time to do so. V8 drops on the quad G5 from 2300 to about 450 (but the interpreter clocks in at barely 100). SunSpider time increases by a similar proportion. Because such a large portion of Peacekeeper is predicated on our JavaScript performance, we suffer badly there too. BaselineCompiler also does not utilize the FPU very well, which is really painful on PowerPC because we have no direct ways of converting integer to floating point; benchmarks requiring lots of floating point computation really take it in the shorts, and there is no good way to fix this.

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.

And now for something completely different: turn your Mac into a netboot server

Kudos to Martin Kukač, who not only rediscovered this gem, but got the author to release it as freeware: BootMania, a netbooting server that allows any 10.4+ Mac (OS X Server or no) to netboot another. It not only netboots and/or netinstalls OS 9, 10.3, 10.4, OpenDarwin, *BSD and Linux, but it allows you to override the Tiger hardware check and even includes its own DHCP server (just make sure it's not going to freak out your router or other hosts on your network).

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.

24.0 gets off the ground

Finally, blogging from within a debugging build of 24.0 after a string of false starts and fixing bugs to get the browser to stabilize. We still fail that lone asm.js test that methodjit also failed, plus an obscure debug-mode-only test which looks like it might possibly be a Mozilla error; neither are causing issues for the regular browser so far. The last remaining crash bug in BaselineCompiler has been fixed, and some other polishing up has been done to make the browser now functional enough to do some larger scale testing. The change to PPCBC has made some things better and some things worse, but mercifully the net performance change is closer to a wash than I had thought. I'll try to give you harder metrics when I have an opt build working and have done more optimization work, and I'd like to see if we can reintroduce jemalloc after I do some testing with its memory consumption.

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.

So long, WebTV

Some of you may remember WebTV, the "classic" set-top box service which started operation on September 18, 1996, and may be surprised to know that even after Microsoft bought it and turned it into MSN TV with their usual lack of finesse, the service lived on. In fact, MSN TV remained in operation until just a few days ago, when it was finally shut down on September 30th, 2013 just a couple weeks after its 17th birthday.

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.

You can download it from the Floodgap gopher server's archives (install OverbiteFF in TenFourFox if you haven't already).

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.