Rosetta 2: This Time It's Personal (and busting an old Rosetta myth)

Apple's back in the RISC camp, though I still hate the name Apple Silicon, as if Apple has some special sauce for certain inorganic elements that makes it any better than any other kind of silicon. With the release of the M1 ("merely" an A14 on steroids by all accounts) a series of benchmarks have been turning up on Geekbench, which because I'm such a big conspiracy theorist I suspect are probably being astroturfed out of Infinite Loop itself. One that particularly attracted my attention, however, is this one which shows Rosetta 2 (the x86_64-on-AARM emulator analogous to the Rosetta PPC-on-Intel emulator in 10.4-10.6) exceeding the single-core performance of Apple's other Intel machines on Intel apps. The revenge-of-the-G5 Mac Pro is conspicuously absent (for the record a cursory search on the 2019 model yields scores from around 1024 to 1116 depending on configuration), but M1 still eclipses it and even edges past the i9 in the current 27" iMac.

That's pretty stupendous, so I'd like to take a moment to once again destroy my least favourite zombie performance myth, that the original Rosetta was faster at running PowerPC apps than PowerPC Macs. This gets endlessly repeated as justification for the 2005 Intel transition and it's false.

We even have some surviving benchmarks from the time. Bare Feats did a series of comparisons of the Mac Pro 2.66, 3.0 and the Quad G5 running various Adobe pro applications, which at the time were only available as PowerPC and had to run in Rosetta. The Mac Pros were clearly faster at Universal binaries with native Intel code, but not only did the Quad G5 consistently beat the 2.66GHz Mac Pro on the tested PowerPC-only apps, it even got by the 3.0GHz at least once, and another particular shootout was even more lopsided. The situation was only marginally better for the laptop side, where, despite a 20% faster clock speed, the MacBook Pro Core Duo 2.0GHz only beat the last and fastest DLSD G4/1.67GHz in one benchmark (and couldn't beat a 2.0GHz G5 at all). Clock-for-clock, the Power Macs were still overall faster on their own apps than the first Intel Macs and it wasn't until native Intel code was available that the new generation became the obvious winner. There may have been many good reasons for Apple making the jump but this particular reason wasn't one of them.

And this mirrors the situation with early Power Macs during the 68K-PPC transition where the first iterations of the built-in 68K emulator were somewhat underwhelming, especially on the 603 which didn't have enough cache for the task until the 603e. The new Power Macs really kicked butt on native code but it took the combination of beefier chips and a better recompiling 68K emulator to comfortably exceed the '040s in 68K app performance.

If the Rosetta 2 benchmarks for the M1 are to be believed, this would be the first time Apple's new architecture indisputably exceeded its old one even on the old architecture's own turf. I don't know if that's enough to make me buy one given Apple's continued lockdown (cough) trajectory, but it's enough to at least make me watch the M1's progress closely.

TenFourFox FPR29 available

TenFourFox Feature Parity Release 29 final is now available for testing (downloads, hashes, release notes). There are no additional changes from the beta except for outstanding security patches. Locale langpacks will accompany this release and should be available simultaneously on or about Monday or Tuesday (November 17 or 18) parallel to mainline Firefox.

Because of the holidays and my work schedule I'm evaluating what might land in the next release and it may be simply a routine security update only to give me some time to catch up on other things. This release would come out on or about December 15 and I would probably not have a beta unless the changes were significant. More as I make a determination.

TenFourFox FPR29b1 available

TenFourFox Feature Parity Release 29 beta 1 is now available (downloads, hashes, release notes). Raphaël's JavaScript toggle is back in the Tools menu but actually OlgaTPark gets most of the credit this release for some important backports from mainline Firefox, including fixes to DOM fetch which should improve a number of sites and adding a key combination (Command-Option-R in the default en-US locale) to toggle Reader View. These features require new locale strings, so expect new language packs with this release (tip of the hat to Chris T who maintains them). The usual bug and security fixes apply as well. FPR29 will come out parallel with Firefox 78.5/83 on or about November 17.

The December release may be an SPR only due to the holidays and my work schedule. More about that a little later.

TenFourFox FPR28 available

TenFourFox Feature Parity Release 28 final is now available for testing (downloads, hashes, release notes). Since there are a couple more user-facing features landing hopefully for FPR29 out of some great work by OlgaTPark, we've temporarily held Raphaël's Enable JavaScript menu option since these will both require new locale strings and I'd rather not release two language pack sets back to back. Both features will instead debut officially in FPR29 with new langpacks side-by-side, along with some targeted Gecko fixes which should improve site compatibility as well.

In the meantime, all the other improvements and upgrades planned for FPR28 have stuck, and this final release adds updated timezone data as well as all outstanding security updates. Assuming no issues, it will go live as usual on or around Monday, October 19 Pacific time.

TenFourFox FPR28b1 available (and a sordid tale of more Google screwery)

TenFourFox Feature Parity Release 28 beta 1 is now available (downloads, hashes, release notes). The two most noticeable changes in this release are the triumphant return of the user-exposed "Enable JavaScript" toggle (now moved to the Tools menu), as submitted by Raphaël, and further improvements to Reader View that make it current with Firefox 82. Because the new toggle menu item requires a new locale string that can't be built from existing ones, a langpack update will also be shipped parallel with this version.

Under the hood there are a couple layout fixes for text wrapping and upgrades to NSS, the browser's security and cryptography library. Of particular interest in that last is the change to Bernstein and Yang's fast constant-time greatest common divisor algorithm. Don't ask me the fine details of the math here, but switching to their variant of Fermat's little theorem over constant-time versions of Euclid's algorithm is not only faster, but particularly faster on weaker machines. And of course all our machines are considered weak by modern standards, so it's nice to see an upgrade that disproportionately benefits the low-end for a change. The usual security updates also apply. Unfortunately, although I was able to better narrow down what code at LinkedIn makes the browser crash, I am unable to minimize the crash to a working reproducible shell test case so far, so JavaScript on LinkedIn remains blocked at the browser level (issue 621) though you can turn it back on if you really have to.

Finally, there's one other minor change which ordinarily would not be worth calling out except for the story behind it. As first reported 17 (!) years ago, if a Content-Disposition header does not put the filename in quote marks, Firefox will split on whitespace, and if there are any spaces then the filename will be truncated. This is not a bug because RFC 2231 is clear on the requirements, but Internet Explorer and others took an excessively relaxed view of the spec and dupes of the report occurred repeatedly over the years. That brings us to bug 1440677, yet another dupe, where it was made clear that even if you want to relax the spec there still needs to be some consistency about what to relax it to. Google was consulted, and decided that "we'd prefer not to change behavior there, just out of a general desire not to break sites" while adding "I agree the spec unambiguously disallows unquoted spaces." (This from the company that decided FTP must die, even though that also certainly breaks sites.)

You can read that as Google saying, we know our behaviour is wrong, we're not interested in hashing out an independent standard because no one's complaining to us, and (effectively) Chrome's behaviour therefore determines how all other browsers should operate. So Mozilla gave up, and since one thing people do use their Power Macs for is downloading files, now we do as Chrome does too. After reading this whole exchange and others like it, I'm left with this thought question: why haven't we trust-busted Google yet? When, exactly, are they "too big" and need to be broken up? It's not money they're gouging us on: it's the hegemony of a Google-centric view of the Web where everything must be and benefit Google's way with no incentive nor even really interest to work with anybody else on a common playing field. Surely that's anticompetitive on some actionable level.

FPR28 goes final on or around October 20.

TenFourFox FPR27 available

TenFourFox Feature Parity Release 27 final is now available for testing (downloads, hashes, release notes). Unfortunately, I have thus far been unable to solve issue 621 regarding the crashes on LinkedIn, so to avoid drive-by crashes, scripts are now globally disabled on LinkedIn until I can (no loss since it doesn't work anyway). If you need them on for some reason, create a pref tenfourfox.troublesome-js.allow and set it to true. I will keep working on this for FPR28 to see if I can at least come up with a better wallpaper, though keep in mind that even if I repair the crash it may still not actually work anyway. There are otherwise no new changes since the beta except for outstanding security updates, and it will go live Monday evening Pacific assuming no new issues.

For our struggling Intel friends, if you are using Firefox on 10.9 through 10.11 Firefox ESR 78 is officially your last port of call, and support for these versions of the operating system will end by July 2021 when support for 78ESR does. The Intel version of TenFourFox may run on these machines, though it will be rather less advanced, and of course there is no official support for any Intel build of TenFourFox.

Google, nobody asked to make the Blogger interface permanent

As a followup to my previous rant on the obnoxious new Blogger "upgrade," I will grudgingly admit Blogger has done some listening. You can now embed images and links similarly to the way you used to, which restores some missing features and erases at least a part of my prior objections. But not the major one, because usability is still a rotting elephant's placenta. I remain an inveterate user of the HTML blog view and yet the HTML editor still thinks it knows better than you how to format your code and what tags you should use, you can't turn it off and you can't make it faster. And I remain unclear what the point of all this was because there is little improvement in functionality except mobile previewing.

Naturally, Google has removed the "return to legacy Blogger" button, but you can still get around that at least for the time being. On your main Blogger posts screen you will note a long multidigit number in the URL (perhaps that's why they're trying to hide URLs in Chrome). That's your blog ID. Copy that number and paste it in where the XXX is in this URL template (all one line):

https://www.blogger.com/blogger.g?blogID=XXX&useLegacyBlogger=true#allposts

Bookmark it and you're welcome. I look forward to some clever person making a Firefox extension to do this very thing very soon, and if you make one post it in the comments.