Tuesday, July 18, 2017

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.

Saturday, July 1, 2017

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.