Google, nobody asked for a new Blogger interface

I'm writing this post in what Google is euphemistically referring to as an improvement. I don't understand this. I managed to ignore New Blogger for a few weeks but Google's ability to fark stuff up has the same air of inevitability as rotting corpses. Perhaps on mobile devices it's better, and even that is a matter of preference, but it's space-inefficient on desktop due to larger buttons and fonts, it's noticeably slower, it's buggy, and very soon it's going to be your only choice.

My biggest objection, however, is what they've done to the HTML editor. I'm probably the last person on earth to do so, but I write my posts in raw HTML. This was fine in the old Blogger interface which was basically a big freeform textbox you typed tags into manually. There was some means to intercept tags you didn't close, which was handy, and when you added elements from the toolbar you saw the HTML as it went in. Otherwise, WYTIWYG (what you typed is what you got). Since I personally use fairly limited markup and rely on the stylesheet for most everything, this worked well.

The new one is a line editor ... with indenting. Blogger has always really, really wanted you to use <p> as a container, even though a closing tag has never been required. But now, thanks to the indenter, if you insert a new paragraph then it starts indenting everything, including lines you've already typed, and there's no way to turn this off! Either you close every <p> tag immediately to defeat this behaviour, or you start using a lot of <br>s, which specifically defeats any means of semantic markup. (More about this in a moment.) First world problem? Absolutely. But I didn't ask for this "assistance" either, nor to require me to type additional unnecessary content to get around a dubious feature.

But wait, there's less! By switching into HTML view, you lose ($#@%!, stop indenting that line when I type emphasis tags!) the ability to insert hyperlinks, images or other media by any other means other than manually typing them out. You can't even upload an image, let alone automatically insert the HTML boilerplate and edit it.

So switch into Compose view to actually do any of those things, and what happens? Like before, Blogger rewrites your document, but now this happens all the time because of what you can't do in HTML view. Certain arbitrarily-determined naughtytags(tm) like <em> become <i> (my screen-reader friends will be disappointed). All those container close tags that are unnecessary bloat suddenly appear. Oh, and watch out for that dubiously-named "Format HTML" button, the only special feature to appear in the HTML view, as opposed to anything actually useful. To defeat the HTML autocorrupt while I was checking things writing this article, I actually copied and repasted my entire text multiple times so that Blogger would stop the hell messing with it. Who asked for this?? Clearly the designers of this travesty, assuming it isn't some cruel joke perpetuated by a sadistic UI anti-expert or a covert means to make people really cheesed off at Blogger so Google can claim no one uses it and shut it down, now intend HTML view to be strictly touch-up only, if that, and not a primary means of entering a post. Heaven forbid people should learn HTML anymore and try to write something efficient.

Oh, what else? It's slower, because of all the additional overhead (remember, it used to be just a big ol' box o' text that you just typed into, and a selection of mostly static elements making up the UI otherwise). Old Blogger was smart enough (or perhaps it was a happy accident) to know you already had a preview tab open and would send your preview there. New Blogger opens a new, unnecessary tab every time. The fonts and the buttons are bigger, but the icons are of similar size, defeating any reasonable argument of accessibility and just looks stupid on the G5 or the Talos II. There's lots of wasted empty space, too. This may reflect the contents of the crania of the people who worked on it, and apparently they don't care (I complained plenty of times before switching back, I expect no reply because they owe me nothing), so I feel no shame in abusing them.

Most of all, however, there is no added functionality. There is no workflow I know of that this makes better, and by removing stuff that used to work, demonstrably makes at least my own workflow worse.

So am I going to rage-quit Blogger? Well, no, at least not for the blogs I have that presently exist (feel free to visit, linked in the blogroll). I have years of documents here going back to TenFourFox's earliest inception in 2010, many of which are still very useful to vintage Power Mac users, and people know where to find them. It was the lowest effort move at the time to start a blog here and while Blogger wasn't futzing around with their own secret sauce it worked out well.

So, for future posts, my anticipated Rube Goldbergian nightmare is to use Compose view to load my images, copy the generated HTML off, type the rest of the tags manually in a text editor as God and Sir Tim intended and cut and paste it into a blank HTML view before New Blogger has a chance to mess with it. Hopefully they don't close the hole with paste not auto-indenting, for all that's holy. And if this is the future of Blogger, then if I have any future projects in mind, I think it's time for me to start self-hosting them and take a hike. Maybe this really is Google's way of getting this place to shut down.

(I actually liked New Coke, by the way.)

TenFourFox FPR25 available

TenFourFox Feature Parity Release 25 final is now available for testing (downloads, hashes, release notes). There are no additional changes other than outstanding security updates. Assuming all goes well, it will go live on Monday afternoon/evening Pacific time.

For FPR26 there will be one additional change to DOM workers and I'm looking at some problem sites to see if there are some easy fixes. Still, the big issues continue to be the big issues and we'll just have to do things like the AppleScript workarounds to deal with them better in future. I'd like to see more people experimenting with AppleScript, too -- we have a whole page of documentation devoted to it and some examples which you can download if you don't want to type them in.

Meantime, did you know Apple had LocalTalk cards for the PC?

TenFourFox FPR25b1 available

TenFourFox Feature Parity Release 25 beta 1 is now available (downloads, hashes, release notes). Raphaël traced the the Twitch JavaScript crash we wallpapered over in FPR24 back to an issue with DOM workers not having sufficient memory allocated, so we widened that out. There still seems to be an endian issue Twitch is triggering, because it needs a huge amount of memory for its worker to finish and then can't spawn another thread because there's not enough memory to (but it reportedly works on Intel TenFourFox, so it's something specific about PowerPC). But hey! No crashes!

Raphaël gets a second gold star for noticing that the gcc runtime we include with every copy of TenFourFox (because we build with a later compiler) is not itself optimized for the underlying platform, because MacPorts simply builds it for ppc rather than one of the specific subtypes. So he built four sets of runtime libraries for each platform and I've integrated it into the build system so that each optimized build now uses a C/C++ runtime tuned for that specific processor family (the debug build is still built for generic ppc so it runs on anything). This is not as big an improvement as you might think because JavaScript performance is almost overwhelmingly dominated by the JIT, and as I mentioned, JavaScript is one of the few areas TenFourFox has tuned and tested to hell. But other things such as DOM, graphics, layout and such do show some benefit, and scripts that spend more time in the interpreter than the JIT (primarily short one-offs) do so as well. There are no changes in the gcc runtime otherwise and it's still the same code, just built with better flags.

This release also includes additional hosts for adblock and additional fonts for the ATSUI font blocklist, and will have the usual security updates as well. It will come out parallel with Firefox 68.11 on or about July 28.

TenFourFox FPR24 available

TenFourFox Feature Parity Release 24 final is now available for testing (downloads, hashes, release notes). There are no additional changes other than outstanding security updates. Assuming all goes well, it will go live on Monday afternoon/evening Pacific time.

I don't have a clear direction for FPR25. As I said, a lot of the low hanging fruit is already picked, and some of the bigger projects are probably too big for a single developer trying to keep up with monthly releases (and do not lend themselves well to progressive implementation). I'll do some pondering in the meantime.

The Super Duper Universal Binary

A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Binary possible? You bet it is! In fact, Apple already documents that you could have a five-way binary, i.e., ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64. Just build them separately and lipo them together.

But it's actually more amazing than that because you can have multiple subtypes. Besides generic PPC or PPC64, you can have binaries that run specifically on the G3 (ppc750), G4 (ppc7400 or ppc7450) or G5 (ppc970). The G5 subtype in particular can be 32-bit or 64-bit. I know this is possible because LAMEVMX is already a three-headed binary that selects the non-SIMD G3, AltiVec G4 or special superduper AltiVec G5 version at runtime from a single file. The main reason I don't do this in TenFourFox is that the resulting executable would be ginormous (as in over 500MB in size).

But ARM has an even more dizzying array of subtypes, at least nine, and the Apple ARM in the new AARM Macs will probably be a special subtype of its own. This means that theoretically a Super Duper Universal Binary ("SDUB") could have all of the following:

• ppc750
• ppc7400
• ppc7450
• ppc970 (this would work for both 32-bit and 64-bit on the G5)
• i386
• x86_64
• x86_64h (i.e., Haswell, here's an example, thanks Markus Stange for pointing this out)
• armv4t
• armv5
• armv6
• armv6m
• armv7
• armv7em
• armv7k
• armv7m
• armv7s
• whatever AARM Macs turn out to be

That's potentially a 17-way binary. The best part is that each individual subpart can link against a different Mac OS X/macOS SDK, so the PowerPC subportions could be linked against 10.4, the i386 subportion against anything from 10.4 through 10.6, the x86_64 subportion against 10.4 through 10.15 (+/- the Haswell subtype), the various weirdo ARM subportions against whatever macOS SDK is relevant to the corresponding iOS version, and the AARM Mac-specific subportion against 11.0. It may be necessary to lipo it together in multiple stages using multiple machines or Xcodes depending on which subtypes are known to that platform, but after you do that, code-sign and/or notarize you should have the ultimate Super Duper Universal Binary able to run on any of these systems. Now, there's a challenge for someone. I look forward to one of those Developer Transition Kits getting put to good use here.

macOS Big Unsure

Finally, Mac OS X goes to 11 with macOS Big Sur. In keeping with Apple's name selection from wildly inappropriate California landmarks, in just three versions you can go from a dusty, hostile desert to an expensive, cramped island and now steep cliffs with rugged beauty as your car goes off a substandard bridge into the Pacific Ocean.

But there's no doubt that Apple's upcoming move to ARM across all its platforms, or at least Apple's version of ARM (let's call it AARM), makes supreme business sense. And ARM being the most common RISC-descended architecture on the planet right now, it's a bittersweet moment for us Power Mac luddites (the other white meat) to see the Reality Distortion Field reject, embrace and then reject x86 once again.

Will AARM benefit Apple? You bet it will. Apple still lives in the shadow of Steve Jobs who always wanted the Mac to be an appliance, and now that Apple controls almost all of the hardware down to the silicon, there's no reason they won't do so. There's certainly benefit to the consumer: Big Sur is going to run really well on AARM because Apple can do whatever hardware tweaks, add whatever special instructions, you name it, to make the one OS the new AARM systems will run as fast and energy-efficient as possible (ironically done with talent from P. A. Semi, who was a Power ISA licensee before Apple bought them out). In fact, it may be the only OS they'll be allowed to run, because you can bet the T2 chip will be doing more and more essential tasks as application-specific hardware adds new functionality where Moore's law has failed. But the biggest win is for Apple themselves, who are no longer hobbled by Intel or IBM's respective roadmaps, and because their hardware will be sui generis will confound any of the attempts at direct (dare I say apples to apples) performance comparisons that doomed them in the past. AARM Macs will be the best machines in their class because nothing else will be in their class.

There's the darker side, too. With things like Gatekeeper, notarization and System Integrity Protection Apple has made it clear they don't want you screwing around with their computers. But the emergence of AARM platforms means Apple doesn't have to keep having the OS itself slap your hand: now the development tools and hardware can do it as well. The possibilities for low-level enforcement of system "security" policies are pretty much limitless if you even control the design of the CPU.

I might actually pick up a low-end one to play with, since I'm sort of a man without a portable platform now that my daily driver is a POWER9 (I have a MacBook Air which I tolerate because battery life, but Mojave Forever, and I'll bet runtime on these machines will be stupendous). However, the part that's the hardest to digest is that the AARM Mac, its hardware philosophy being completely unlike its immediate predecessors, is likely to be more Mac-like than any Mac that came before it save the Compact Macs. After all, remember that Jobs always wanted the Mac to be an appliance. Now, Tim Cook's going to sell you one.

TenFourFox FPR24b1 available

TenFourFox Feature Parity Release 24 beta 1 is now available (downloads, hashes, release notes). This includes Raphaël's mitigation for Twitch frame crashes and Ken's Intel build system fixes, plus minor updates to JavaScript, DOM and layout, and fixes for sundry issues with MP3 playback (make that G4 Mac mini an Internet radio today) along with the usual security updates. Assuming all goes well, TenFourFox FPR24 will go final on or about June 29 parallel with Firefox 78.