TenFourFox FPR2b1 available (plus: come to VCF!)

TenFourFox Feature Parity Release 2 beta 1 is now available (downloads, hashes, release notes). Besides various and sundry additional optimizations once again shamelessly backported from the Quantum project, this release includes the accelerated AltiVec string matching routine which I will be also hooking up to other parts of the browser in future releases, and reworks the font blacklist so that Apple sites work again (and more efficiently). Release is planned for August 8.

With this beta you will notice I've made a new build available - a true "Debug" build. Since currently we really only have comprehensive test coverage for JavaScript, this gives people a chance to help debug other browser issues without having to build the entire application themselves. I intend to only issue these for beta releases since the idea is to have as few changes as possible between the beta and the release version. Please take heed of this warning: the Debug version is not for mere mortals. Because it has a full symbol table, it could cause your system's crash dump facility to hang if it bombs and you weren't running it within the TenFourFox debugger (and if that happens, you'll have to kill the crash dump or it will peg your CPU; I actually hacked /usr/libexec/crashdump to not run if I've touched /tmp/no_crashdump as a flag). In addition, the debug build is much slower, runs a lot of sanity checking code and generates copious logging output. It is not optimized for any processor and has no AltiVec code, so it will run (badly) on any compatible Power Mac. Please refer to the developer instructions and understand what you're doing before you run it, and if you do run it, I strongly suggest creating a separate profile specifically for debugging if you intend to work with it often. The debugging versions will not be offered from the main TenFourFox page so clueless folks don't grab it by accident.

Next up, FPR3 will have some additional optimizations and performance improvements too, but will be focused instead more towards supporting new features again: in addition to some minor compatibility tweaks, I would like to get enough of our CSS grid support working to be credible and do further improvements to our JavaScript ES6 implementation. More on that a little later.

A schedule note: I'll be demonstrating the Apple Network Server 500 (the original floodgap.com) at this year's Vintage Computer Festival West August 5 and 6 at the Computer History Museum in Mountain View, CA (last year's exhibit was good fun). The ANS (codenamed "Shiner" after a local brand of beer in Texas, where it was developed) was arguably Apple's first true-UNIX server (A/UX notwithstanding), almost certainly the biggest computer they've ever made, and the last general purpose computer they built that wasn't a Mac. I ran mine almost non-stop from 1998 to 2012 as my main server (14 years), and it came back briefly in 2014 when the POWER6 currently running Floodgap blew its mainboard. I'll have it set up so you can play with it, plus an actual prototype Shiner for display and a couple (haven't decided?) PowerBook clients to demonstrate its unusual software powers. Be there or be less nerdy than I am.

Oh, and at last, Flash is dead (by 2020). But it was dead to us in Power Mac-land a long time ago. Finally the rest of the world catches up.

Do you work for Facebook? Do you like old Power Macs? Help a brother out.

Are you a front-end engineer for Facebook? Are you sympathetic to us struggling masses trying to keep our Power Macs out of the landfill? Do you, too, secretly agree that the iMac G4 looks far better than any of the crap Tim Cook and friends churn out now?

If so, give your TenFourFox users a little hand. Yes, I will preface this by saying I do not use, nor (candidly) particularly like, Facebook, but lots of TenFourFox users do and I've reached the limit of my debugging ability against the minified front end of Facebook.

We have an issue with our custom keyboard handling code with users pressing Delete repeatedly: it not only doesn't delete anything but the first character, but actually inserts repeated 0x08 bytes (i.e., the ASCII value for Delete). Everything else seems to work. Obviously this is our bug, because regular Firefox (including Firefox ESR 45, on which we are ultimately based) doesn't do this, but I can't determine what DOM fields our keydown events aren't correctly providing to Facebook's keydown handler because the code is minified to hell. And debugging minified event handlers even with my Quad G5 cranked to ludicrous is not a good time. No other site seems to do this, so I don't have something smaller to test against either.

So, if you're a Mac retronerd and also a Facebook front-end engineer, does this ring a bell to you? If it doesn't, is there at least a non-minified version I can test against? I sent an E-mail to browsers at fb but got no reply, so I'm asking publicly and begging for your mercy so we can keep our otherwise perfectly good Macs serviceable and running. And for some people, "serviceable and running" means Facebook. So I won't judge. Honest.

Jokes aside, I'd really appreciate any of your insights and time. You can drop a line to classilla at floodgap dawt com if you have a suggestion (or better yet the answer).

We're delayed on FPR2 because I'm trying to track down a regression one of the security backports caused during shutdown when network connections are pending. However, this blog post is being typed in it, so it's otherwise working and I'm still shooting for the official beta next week.

Talos take II

First, ob-TenFourFox stuff. As the wonderful Dutch progressive rock band Focus plays "Sylvia" in the CD player, I'm typing this in a partially patched up build of FPR2, which has a number of further optimizations including an AltiVec-accelerated memchr() implementation (this improves JavaScript regex matching by about 15 percent, but also beefs up some other parts of the browser which call the same library function) and some additional performance backports ripped off from Mozilla's Quantum project. This version also has a re-tuned G5 build with some tweaked compiler settings to better match the 970 cache line size, picking up some small but measurable improvements on Acid3 and other tests. Even the G3 gets some love: while it obviously can't use the AltiVec memchr(), it now uses a better unrolled character matcher instead and picks up a few percentage points that way. I hope to finish the security patch work by this weekend, though I am still annoyed to note I cannot figure out what's up with issue 72.

Many of you will remember the Raptor Talos, an attempt to bring a big beefy POWER8 to the desktop that sadly did not meet its crowdsource funding goal. Well, I'm gratified to note that Raptor is trying again with a smaller scale system but a bigger CPU: the POWER9-based Talos II. You want a Power-based, free and open non-x86 alternative that can kick Intel's @$$? Then you can get one of these and not have to give up performance or processing (eheheh) power. The systems will use the "scale-out" dual socket POWER9 with DDR4 RAM and while the number of maximum supported cores on Talos II has not yet been announced, I'll just say that POWER9 systems can go up to 24 cores and we'll leave it at that. With five PCIe slots, you can stick a couple cool video cards in there too and rock out. It runs ppc64le Linux, just like the original Talos.

I'm not (just) interested in a thoroughly modern RISC workstation, though: I said before I wanted Talos to be the best way to move forward from the Power Mac, and I mean it. I'm working on tuning up Firefox for POWER8 with optimizations that should carry to POWER9, and once that builds, beefing the browser up further with a new 64-bit Power ISA JavaScript JIT with what we've learned from TenFourFox's 32-bit implementation. I'd also like to optimize QEMU for the purpose of being able to still run instances of OS 9 and PowerPC OS X in emulation at as high performance on the Talos II as possible so you can bring along your legacy applications and software. When pre-orders open up in August -- yes, next month! -- I'm going to be there with my hard-earned pennies and you'll hear about my experiences with it here first.

But don't worry: the G5 is still going to be under my desk for awhile even after the Talos II arrives, and there's still going to be improvements to TenFourFox for the foreseeable future because I'll still be using it personally for the foreseeable future. PowerPC forever.

OverbiteFF will cease functioning with Firefox 56 (we need WebExtension sockets)

For those unfamiliar, TenFourFox and Classilla aren't my only Mozilla-related projects; the other one I've maintained for some time is OverbiteFF, which adds Gopher support back to Firefox as a first-class citizen. It does so by implementing nsIChannel and nsIProtocolHandler objects which speak Gopher and allows everything to "just work" like any other URL. Because of how the protocol works, the add-on also enables whois and finger protocol support with a little bit of URL gyration, and to this day there is a small but dedicated userbase.

As of Firefox 56, it is my understanding that non-multiprocess-compatible extensions will no longer be supported, which is currently in nightly. Even if I were able to make OverbiteFF MP compatible, however (there were some technical hurdles to be overcome when I tried), it is highly dependent on XPCOM and Firefox 57 will be the end of that. As a result, OverbiteFF in its current form will cease functioning with Firefox 56. It will, of course, continue to work with TenFourFox and Firefox 52ESR, so I would recommend switching to 52ESR as a stopgap if you need to run XPCOM-dependent extensions like this one and are not lucky enough to have a Power Mac. For Firefox Android users, Overbite Android works wonderfully as an external application and Firefox Android will hand Gopher URLs to it; I use my own work on a Google Pixel XL with Android 7.1.2.

Unfortunately, there is no way to make OverbiteFF compatible with WebExtensions, even with reduced functionality: no one has implemented TCP socket access for extensions, and the protocol handler support is not only incomplete but actually intentionally excluded the Gopher protocol in URLs (so I can't even implement it like the old Overbite Chrome, which rewrote requests for any of the available Gopher->HTTP gateways). I'd submit a patch to whitelist gopher for the latter but there's been no motion on dealing with the standards clash that caused it, and there's not even an API description for WX socket support, let alone code written to implement it.

Clearly OverbiteFF is hardly alone among extensions in these requirements (for example, uProxy, Chatzilla, FireFTP and FireSSH will all stop working too), but I'm particularly bitter about this because its genesis came from the protracted end of Gopher support in Firefox 4. The tl;dr from that bug was, paraphrased straight from Mountain View, it's being yanked and you can't stop it, so learn XPCOM and write an add-on and maintain the feature yourself. Well, I did, it worked, people used it, and now it's going to stop working and unless motion occurs on these APIs I won't be able to make it work ever again in the future. You can post all the happy talk about how wonderful the end of XPCOM add-ons is for paying back Gecko's technical debt and I'm not going to dispute that, but that doesn't mean it doesn't suck. On the eve of WebExtensions' full takeover it feels like yet another broken promise.

Please, let's see motion on these and related APIs soon.