Heads up: 31.1.1 imminent

Mozilla is chemspilling for a high-priority security issue which we are vulnerable to; this will force a 31.1.1 build, on which I will also take all the current security and stability fixes Mozilla has landed on 31ESR to date. The G5 is currently chugging out release candidates hopefully for release to you the testers tomorrow evening to become live on Thursday.

For Chrome, 32 bits are not enough

Google is touting its 64-bit build of Chrome for OS X, scheduled for rollout with Chrome 39 in November. Almost a whisper by comparison, though, is what will happen to the 32-bit build. Well, it's very simple: it won't exist. This is the end for the 32-bit Intel Mac as far as Google is concerned, even though those Macs can run 10.6, which Chrome, at least for the moment, still supports. Chromium might still build, but I wouldn't bet on it.

Besides the obvious -- no 32-bit browser -- there are some other knock-on effects, the most important being that 32-bit plugins won't work either. This is not a big deal presently since the major plugins have 64-bit versions now, but Google is completely removing NPAPI plugin support later this year as well. This leaves its perverse little PPAPI plugin support, which only Chrome can run, to maintain Flash compatibility using its bespoke in-browser version; Mozilla, Microsoft and Apple have all uniformly refused to support PPAPI. That's okay with Google, because soon their Native Client implementation is going to take over your desktop with Android apps anyway.

As it stands, Firefox is a fat x86 binary with 32-bit and 64-bit versions, but historically when Google has withdrawn support Mozilla has been quick to follow, and Google's decision is already being discussed on the Mozilla developer channels. Currently the only thing really forcing 32-bit support is the need for Silverlight for Mac, which doesn't exist in a 64-bit version. Since Chrome won't be supporting NPAPI plugins of any kind soon, they don't have that limitation; should Mozilla find a HTML5 workaround for sites like Netflix, or the userbase drop enough, you can confidently expect the end of 32-bit support on OS X from Firefox as well.

This is important for us in two respects: we rely on a lot of 10.6 code still, and a 64-bit only build clears the way to end 10.6 support; and we are a 32-bit hybrid Carbon/Cocoa application. The only 64-bit Power Mac is the G5, but even if I limited TenFourFox to the G5 systems exclusively (which I won't do, because at a minimum I myself use the 7450 build also), it still wouldn't work because there is no 64-bit Carbon and 10.4's 64-bit Cocoa support is incomplete. As long as 32-bit builds persist, 10.6 support is likely to remain as well, because they serve no purpose on 10.7+. Once they disappear, I predict Mozilla will drop both 10.6 and 10.7 simultaneously and support only 10.8+. (Remember, Firefox already can no longer be built on 10.6, even though it will still run on it.) We could probably still make much of the cross-platform code work on 32-bit PowerPC because the Linux and Windows tier-1 builds still support 32-bit, at least for the time being, but the OS X-specific portions would become much harder to work with.

On that note, due to my dissatisfaction I've decided to scotch the 33 release and jump to working on 34. (If you want the changesets to build your own to play with, you can get them from the unstable folder on SourceForge. Please note that they are against 33-aurora, which is now 33-beta, so you should expect some merging to be required.) For now, I'm just concentrating on getting to 38, and secondarily on completing the MIPS JIT conversion to PowerPC; 34 is currently crippled by a severe bug on systems without hardware acceleration, but this is biting Mozilla as well, so it is virtually certain they will fix it shortly. 38 is kind of a nice milestone because by the end of 38ESR support, even the last quad G5 to roll off the assembly line will have received a full 10 years of support, from 2006 to 2016. I'd really like to make that, at least, and pick up the important HTML5 and ECMA6 features that are being added such as <picture>.

In other news, I picked up an Apple Workgroup Server 9150 and restored it this weekend. I'm sort of developing a hyperspecialized interest in Apple server-grade hardware, such as it existed, particularly the truly unique Apple Network Servers; while I don't really have much interest in the Workgroup Servers in general because they were rebadged workstation Macs with occasionally different storage loadouts, the WGS 9150 is a legitimately odd chimera of the Quadra 950/Apple Workgroup Server 95 and the Power Macintosh 8100 with some strange attributes of its own. In its prototype form as Green Giant, it was also the testbed for Apple's brief and sorrowful flirtation with NetWare (the so-called "Wormhole" project); it went over so badly with testers that Apple ended up developing Shiner in its place, which became the ANS, and the Green Giant prototype was recycled into the 9150 with MacOS. After stripping it down, cleaning its profoundly grimy contents, applying a bit of steel wool and gentle care to get the yellowing and deep marks out of the plastic, and then replacing the CD-ROM, adding another hard disk and recabling it, it is now sitting next to the G5 quietly installing MkLinux. Why MkLinux, you ask? Because it's period-appropriate, it probably doesn't suck on the 601, Apple actually supported it, and I want to compare it to Rhapsody. Watch for an "ANFSCD" on it in the near future.

Finally, I am concerned that SeaMonkey PPC has halted updates; I haven't seen anything since May of this year. Our Tenfourbird builder from the Land of the Rising Sun has been keeping pace, but SeaMonkey PPC is based on its own code, and it's possible he hasn't been able to keep it working. Hopefully that's not the case, since the looming end of the original WebKit1 will also limit Leopard WebKit users, though I know Tobias will continue to work on fixes and improvements. We need more and better browser support for OS X/ppc, not less.

TenFourFox 33 sort of gets off the ground

This is being typed in TenFourFox 33, which bodes well, but this was a very hard port and I don't have full confidence in it. For one thing, it was a very large merge and overall I had to backout several changes that would break us. While irregexp, the new regular expression engine for JavaScript derived from Google V8, does appear to mostly work after some substantial time spent sniffing out all the test failures and endian problems, it has one big problem in that it can't grow its backtrack stack, used for complex match jobs, without crashing. I suspect an OS glitch; I can't find anything wrong with my generated code yet. Right now the system simply uses a large enough default stack to pass the tests and refuses to enlarge it further. This seems to work, but I can't guarantee it works with every possible addon (Ghostery in particular has had past problems with limitations on regular expressions) and it requires several megabytes of space by default even if it never actually uses it, potentially per compartment. If memory or compatibility pressure becomes too high we can run or at least force Firefox to run without native regular expression compilation, but although that works fine it is very slow by comparison.

In addition, WebRTC's new screen capture code doesn't compile at all on 10.4. I think I have it hacked so that it will work without it and we can still use WebRTC for webcams as we are doing now, but it's all very rickety. The rapid development of that code means further bustage in the near future.

Finally, the one thing I was really hoping for out of Fx 33+, asynchronous pan and zoom where you can move around and scroll the page at least while it is loading and JavaScript is running, won't compile on 10.4 either. Tiger completely lacks any method, even an undocumented one, for turning a CGEvent from an event tap into an NSEvent, and I am so far not able to find documentation on the opaque CGEvent object to be able to fake up enough of it to get scrolling to function. The old CGSEventRecord does apparently have undocumented support, but I can't find any documentation on that either, just some references in code to header files that do not exist in the SDKs that come with Xcode 2.5.

Overall, although it works, I'm not happy with what I had to do to make it work. I'm not sure I'm going to make a release of 33 (other than changesets) -- I might turn this around immediately into aurora 34 and try to get cracking on converting the MIPS IonMonkey JIT because if the stack limitations of irregexp become a big problem, I may need the rest of the Ion JIT to overcome the performance hit we will take by disabling native regular expressions. I think this should be the biggest priority for 38, the next ESR. There may not be much further we can take the browser after that if we even get that far.

The irregularities of irregexp (plus: the resurrection of thule)

31.1.0 is now released to an adoring public, a little ahead of Firefox which apparently releases on Wednesday but I don't see any reason why we should be delayed.

I also made a major breakthrough over the weekend and irregexp, the regular expression engine Firefox switched to in Fx32, is now generating working JIT code on PowerPC. This involved fixing a couple of undiscovered bugs in our JIT and adding support for the PowerPC byte-swapping load instructions (lhbrx and lwbrx) so that irregexp's inherent little-endian orientation could be worked around on our side. It now passes V8, and I think I can get it passing all the tests in a couple more days. This was a must-complete milestone because without it not only will we be unable to implement our new MIPS-based JIT, but we almost certainly won't make the next ESR. This makes our chances much better.

That's the good news. The bad news is that, at least on V8, it seems to be anywhere from 30 to 50 percent slower on compiled expressions than YARR, which we use in 31 stable. It's always hard to assess final performance on a debug build, but I want to make sure that our use of the byte-swapping instructions is not to blame. It may end up being faster to emit code to do a regular big-endian load and then rotate things around with rlwinm and rlwimi, even though that's two or three more instructions in the I-cache; I'm going to do some more testing with that once I have the test suite passing completely. It doesn't look like it's an emulated instruction on G5, thank goodness.

Those of you on ThinkClassic will have already seen this story, and if you're not on TC you should be, but this weekend thule, my long-running Macintosh IIci NetBSD/mac68k server, finally blew its logic board after fifteen years. Most likely it needs a recap, but the good news is, I already had a spare board with fresh caps in reserve for just such a day and thule is running again. When it was the only server in my apartment, it acted as a cross-development machine for my Commodore 64 programs (the 7300 mounted it over AFP and I ran a cross-assembler on it that emitted binaries the 7300's C64 emulator could pick up and run in the debugger), a small file server and a backup repository. Today, a decade and a half later, it still handles internal DNS resolution and AppleTalk services for the classic pre-OS X machines, and even though a 25MHz '030 is glacial by current standards -- especially since I pulled the L1 cache card to improve its uptime -- it has rendered reliable and sterling service since 1999. I see no reason it won't continue to do so on its new logic board. Here's to another fifteen years of putting a classic to work every day.

31.1.0 available

31.1.0 is now available (downloads, release notes). This incorporates the fixes for trackpad scrolling and Mighty Mouse scrolling, and some changes backported from Fx33/34 to improve overall scrolling performance. It also slightly reduces the latency of the JavaScript JIT compiler which improves SunSpider and V8 by around 0.5-1% (since the improvement is in code generation, it is more noticeable in scripts with short runtimes and microbenchmarks). If you are using the "31.1pre" you should upgrade to this finalized version as it fixes a glitch in rendering and adds the JavaScript changes, as well as the security and stability fixes, of course. Assuming no issues, it will become live on Monday night as usual.

I still don't know what's wrong with irregexp yet. I plan to do more work on that over the long Labour Day weekend.

Status update

Sorry for the radio silence, but I've just been incredibly busy with this and the degree. The patches are down for TenFourFox 33, but it took me about a week to get JavaScript compiling again after most of the old Nitro macroassembler was ripped out and V8 irregexp added to replace YARR as the regular expression engine. The JIT mostly works ... except irregexp, which gets simple patterns wrong and crashes on complicated ones. The issue is probably endian, though running the JIT with native regular expression compilation disabled works fine. However, the performance regression this would cause is not acceptable to ship, so this has to be fixed or we can't advance. Fortunately, I still have over six weeks yet to figure that out.

The MIPS JIT also landed, which is important because it is the architecture Mozilla supports most similar to PowerPC. The MIPS JIT is little-endian, so we still have to account for that, but it's a more conventional RISC instruction set than ARM, has a link register, requires lui/ori to load 32-bit quantities just like we need lis/ori, and has similar requirements for branch stanzas. Moreover, it does not have the technical debt we have accrued getting our JaegerMonkey (Firefox 10-era) JIT working at all with BaselineCompiler, which is the basis of PPCBC; as it stands there are several bugs in full IonMonkey branching and bailouts I can't fix with our current implementation. The MIPS JIT gives me the chance to blow up everything and start over with a template that will be very similar for our own machines, but I have to get 33 working first. If we're really lucky, we can get this in for Fx38, if there is one.

As mentioned multiple times, loss of 10.6 support would hurt us very badly. Mozilla will not do this until Google does in Chrome, though they have made some steps towards removal of support, the most important being that 10.6 is no longer supported as a build platform. (If you had hopes of me creating a TenSixFox, sorry.) The browser currently will still run on 10.6, but is linked against a later SDK. For their part, Chromium is tallying 10.6 specific bugs in their tracker as well as bugs hard to fix with 10.6 support, and it is possible that some future changes for 10.10+ will make it infeasible for them to continue supporting Snow Leopard. Generally this decision comes without warning, as it did for 10.5. I am watching these issues carefully. If the blade does not fall by 37 or 38, and Electrolysis is still not mandatory, we should make it.

31.1 will be out later this week with the scrollpad/Mighty Mouse scroll gestures fix, a tiny tweak to reduce JIT latency and some improvements to scrolling screen performance backported from Fx32 and 33.

Get your pkgs from the src on PPC

Ob10.4FxNews: about 50% done with the Firefox 33 patches. Not sure if it'll even build yet after the irregexp changes, but we'll see when I have the rest of the changes landed.

One of the things that keeps our Power Macs relevant (besides this project, of course) is a steady stream of ready-to-use open source software; as even 10.6 becomes considered "legacy" this is an even greater concern. In fact, because TenFourFox depends on gcc 4.6 to build (a compiler never shipped with any version of PPC OS X) and various other tools, we wouldn't exist as a project without it.

For years, getting such ported software meant MacPorts (what we currently use here at Floodgap HQ) and Fink, and lately Tigerbrew. However, other than Tigerbrew, which Misty DeMeo specifically targets at PowerPC OS X 10.4, both MacPorts and Fink no longer officially support PowerPC even on 10.5 or only do so on a best-effort basis. Whatever support exists is what's there modulo occasional port updates contributed by nice folks, and as a result I've lately started backing up /opt before I go updating a port lest I endure bustage I can't back out. More to the point, virtually no pre-built MacPorts binary packages remain for 10.4, so every update is an arduous and possibly fruitless build from source code.

So I'm delighted to shamelessly pimp a new alternative which is also available, but based on a very old friend. If you are familiar with the BSD family (I've used NetBSD on 68K Macs and Power Macs since 2000, and to this day I have a NetBSD Macintosh IIci and Cobalt RaQ 1 providing critical services on the internal Floodgap HQ network), you are almost certainly already familiar with pkgsrc, which evolved from the FreeBSD ports subsystem to be the default package manager in NetBSD and is now available on Linux, proprietary Un*ces like Solaris, AIX, HP-UX and IRIX, and even MINIX, Haiku and Cygwin. pkgsrc has also supported Darwin and OS X since 2001, and at least in theory still should build packages on 10.4, but it's all going to be from source now too because the binary packages currently available are for -- you guessed it -- 10.6. And that's assuming they build.

That's where Sevan Janiyan comes in: an up-to-date build of substantial parts of pkgsrc-current for 10.4/10.5 on PowerPC, with pre-built binaries saving you enormous amounts of time. Using his easy-to-follow instructions, install the bootstrap, set your environment up, and start pkg_adding your way to awesome. All the usual suspects are there, including Perl, Python, Ruby, gcc and lots of necessary libraries.

Not everything builds yet, which is why not all the standard packages are available (besides the fact that a G4 Mac mini compiling any large project is generally a pedestrian affair). However, the mini so far has chugged through 1064 out of a queue of 2083 packages over the last week, and fixes are landing for the pieces that don't build yet. Not bad for a little white box on the shelf.

The more package managers we have that work on PowerPC, and the more binary offerings we have available, the better off we'll be and the easier it will be to bring things back up if something fails. So thumbs up to Sevan for another alternative, along with the hard work Misty still does on Tigerbrew and our usual unsung suspects quietly keeping MacPorts and Fink still viable on the platform Apple wishes would just go away.