Time to sink the Admiral (or, why using the DMCA to block adblockers is a bad move)

One of the testing steps I have to do, but don't enjoy, is running TenFourFox "naked" (without my typical adblock add-ons) to get an assessment of how it functions drinking from the toxic firehose that is the typical modern ad network. (TL;DR: Power Macs run modern Web ads pretty poorly. But, as long as it doesn't crash.) Now to be sure, as far as I'm concerned sites gets to monetize their pages however they choose. Heck, there's ads on this blog, provided through Google AdSense, so that I can continue to not run a tip jar. The implicit social contract is that they can stick it behind a paywall or run ads beside them and it's up to me/you to decide whether we're going to put up with that and read the content. If we read it, we should pony up in either eyeballs or dinero.

This, of course, assumes that the ads we get served are reasonable and in a reasonable quantity. However, it's pretty hard to make money simply off per-click ads and networks with low CPM, so many sites run a quantity widely referred to as a "metric a$$ton" and the ads they run are not particularly selective. If those ads end up being fat or heavy or run scripts and drag the browser down, they consider that the cost of doing business. If, more sinisterly, they end up spying on or fingerprinting you, or worse, try to host malware and other malicious content, well, it's not their problem because it's not their ad (but don't block them all the same).

What the solution to this problem is not, is begging us to whitelist them because they're a good site. If you're not terribly discriminating about what ads you burden your viewers with, then how good can your site really be? The other non-solution is to offer effectively the Hobson's choice of "ads or paywall." What, the solution to the ads you don't curate is to give you my credit card number so you can be equally as careful with that?

So until this situation changes and sites get a little smarter about how they do sponsorship (let me call out a positive example: The Onion's sponsored content [slightly NSFW related article]), I don't have a moral problem with adblocking because really that's the only way to equalize the power dynamic. Block the ads on this blog if you want; I don't care. Click on them or not, your choice. In fact, for the Power Macs TenFourFox targets, I find an adblocker just about essential and my hats are off to those saints of the church who don't run one. Lots of current sites are molasses in January on barbituates without it and I can only improve this problem to a certain degree. Heck, they drag on my i7 MacBook Air. What chance does my iMac G4 have?

That's why this egregious abuse of statute is particularly pernicious: a company called Admiral, which operates an anti-adblocker, managed to use a DMCA request to Github to get the address of the site hosting their beacon image (to determine if you're blocking them or not) removed from the EasyList adblock listing. They've admitted it, too.

The legal theory, as I understand it (don't ask me to defend it), is that adblockers allow users to circumvent measures designed to "control access," which is a specific component of the American DMCA. (It is not, in fact, the case in Europe.) It might be more accurate to say that the components of adblockers that block adblocker blocking are primarily what they object to. (Uh, yo dawg.) Since the volunteer maintainers of EasyList are the weak link and the list they maintain is the one most adblockers use as a base, this single action gets them unblocked by most adblock extensions and potentially gives other ad networks a fairly big club to force compliance to boot.

The problem with this view, and it is certainly not universally shared, is that given that adblockers work by preventing certain components of the page from loading, theoretically anything that does not load the website completely as designed is therefore in violation. The famous text browser Lynx, for example, does not display images or run JavaScript, and since most ads and adblocker-blockers are implemented with images and JavaScript, it is now revealed as a sinister tool of the godless communist horde. NoScript blocks JavaScript on sites you select, and for the same reasons will cause the end of the American Republic. Intentionally unplugging your network cable at the exact moment when the site is pushing you a minified blob of JS crap -- or the more technically adept action of blackholing that address in your hosts file or on your router -- prevents the site from loading code to function in the obnoxious manner the ad network wants it to, and as a result is clearly treason. Notice that in all these examples the actual code of the site is not modified, just whether the client will process (or in the last example even just receive) and display it. Are all these examples "circumvention"?

This situation cannot stand and it's time for us independent browser maintainers to fight fire with fire. If Admiral isn't willing to back down, I'll issue the ultimatum that I will write code into TenFourFox to treat any of Admiral's web properties as malicious, and I encourage other browser maintainers to do the same. We already use Safe Browsing to block sites that try to load malicious code and we already generate warnings for sites with iffy credentials or bad certificates, so it's not a stretch to say that a site that actively attacks user choice is similarly harmful. The block will only be by default and a user that really wants to can turn it off, but the point will be made. I challenge Admiral to step up their game and start picking on people their own size if they really believe this is the best course of action.

And hey, even if this doesn't work, I should get lots of ad clicks from this, right? Right?






I'll get my coat.

And now for several things that are completely different: Vintage Computer Festival aftermath, I pass a POWER9 kidneystone, and isindex isdead which issad

So, you slugs who didn't drag yourselves to the Computer History Museum in Mountain View for this year's Vintage Computer Festival West, here's what you didn't see (and here's what you didn't see last year).

You didn't see me cram two dorm refrigerator-sized Apple servers and a CRT monitor into my Honda Civic,

you didn't see my Apple Network Server exhibit, complete with a Shiner HE prototype and twin PowerBook 2300 Duos and an Outbound notebook serving as clients,

you didn't see a functioning Xerox Alto,

you didn't see SDF's original AT&T 3B2,

you didn't see Bil Herd, Leonard Tramiel and other old Commodore luminaries talking about then and now,

you didn't see a replica "CADET" IBM 1620, "just as it was" in 1959 (the infamous system that used lookup tables for addition rather than a proper adder, hence the acronym's alternative expansion as "Can't Add, Doesn't Even Try"),

you didn't see a JLPGA PowerBook 170 signed by John Sculley,

you didn't see a prototype dual G4 PowerBook,

you didn't see a prototype Mac mini with an iPod dock (and an amusing FAIL sticker),

you didn't see components from the Cray-1 supercomputer,

you didn't see this 6502-based astrology system in the consignment section, of the same model used by Nancy Reagan's astrologer Joan Quigley,

and you didn't see me investigate this Gbike parked out front, possibly against company policy.

You could have, if you had come. But now it's too late. Try again next year.

But what you still have a chance to see is your very own Talos II POWER9 workstation under your desk, because preorders opened today. Now, a reminder: I don't work for Raptor, I don't get any money from Raptor, and I paid retail; I'm just a fairly intransigent PowerPC bigot who is willing to put my Visa card where my mouth is.

Currently on its way to my doorstep is a two-CPU, octocore (each core is SMT-4, so that's 32 threads) Sforza POWER9 Talos II with 32GB of DDR4 ECC RAM, an AMD Radeon Pro WX7100, a 500GB NVMe SSD and an LSI 9300 8-port internal SAS controller. The system comes standard with a case, eight SAS/SATA bays, EATX motherboard, fans for each CPU, dual 1400W redundant PSUs, USB 3.0 and 2.0, RS-232, VGA, Blu-ray optical drive, dual Gigabit Ethernet, five PCIe slots (PCIe 4.0, 3 x16 and 2 x8) and a recovery disc. It runs Linux on ppc64le, which is fully supported. The total cost shipped to my maildrop with a hex driver for the high-speed fan assemblies is $7236.

Now, some of you are hyperventilating by now and a few of you may have gone into frank sticker shock. Before you reach for the Xanax, please remember this is most assuredly not a commodity x86_64 machine; this is a different (and Power ISA successor) architecture with fully auditable firmware, the ability for you to do your own upgrades and service with off-the-shelf parts, and no binary blobs with hidden spies like the Intel Management Engine. This is a niche box for people like us who value alternative architectures, especially in a design that we can build and trust ourselves, and I always said something like this wouldn't come cheap. But let's compare and say you're in the market for a Mac Pro or something. You'll still be paying a lot, especially if you get any of the tasty BTO options, and the next Mac Pro is still months away or more. And if you were actually in the market for an AmigaOne X5000, this blows it out of the water. You could just run UAE on this and have cycles to spare!

When the Talos II arrives, I'll be sure to post some unboxing photos and take it through its paces on first boot and give you some initial impressions. My immediate goal is to get a RAID set up, get QEMU able to run a decent subset of my old Mac software (I'll probably start with OS 9, and then create a Tiger instance or clone the G5 to it), and get Firefox running with compiler settings appropriate to the CPU. Then will come the real fun of writing a JavaScript JIT for POWER9.

But don't worry: the G5 isn't going anywhere and neither is TenFourFox. I've got a lot invested in this Quad and it will still be serving workstation duty for awhile yet. Nevertheless, get your credit card and your intestinal fortitude out in the meantime and reserve a Talos of your own while the pre-order period is open. Time to get in while it's hot. This is the next evolutionary step in personal computing with PowerPC.

As we wind up our discussion of the future, however, one part of the past will soon be almost completely gone: the venerable old <isindex> HTML tag. Firefox will be removing it from 56 for technical reasons after it was already removed from Google Chrome and the Safari preview. This construct dates back to the very earliest days of the Web when early browsers didn't have form support; it was designed as an easy way of enabling the user to send search keywords or parameters to a webserver, much like Gopher servers receive queries over item type 7. Mosaic 1.x even had a little form that was a permanent part of the browser chrome with a search button, as you can see from the screenshot at the Macintosh Repository, which would be activated when the tag was seen. Later on, subsequent versions of Mosaic and most of the successor browsers turned it into a pseudo-form that functioned the same way as far as the server is concerned and some of those sites are still around. Myself I use the tag mostly as a convenience for old browsers and Lynx on the Hytelnet-HTTP gateway; the search system offers both a conventional search form and an <isindex> query, both of which work the same, and both of which can still be seen in 52ESR, 54 and the 55 beta for the time being. It goes without saying that I will not be removing it from TenFourFox, and it will eternally remain in our codebase and on my servers as a relic of the way things were and an echo of the way the early Web was.

TenFourFox FPR2 available

As I type in what is not quite the worst hotel room in Mountain View while Rockford Files reruns play in the background, TenFourFox FPR2 final is available for testing (downloads, hashes, release notes). The original plan was not to have a Debug build with this release, but we're still trying to smoke out issue 72, so there is a Debug build as well. Again, it is not intended for general use unless you know what you're doing and why.

The only differences from this and the beta, besides the usual certificate, HPKP and HSTS updates, are some additional debug sections in the widget code for issue 72 and the remaining security and stability update backports. One of these updates fixes a bug in HTTP/2 transactions which helps reduce latency and dropped connections on some sites, notably many Google properties and some CDNs, and affects pretty much any version of Firefox since HTTP/2 support was added. As always, the plan is to go live on Monday PM Pacific.

Day 2 of the Vintage Computer Festival West is tomorrow! Be there, or, um, be not there! And that is clearly worse!

And now for something completely different: when good Mac apps go bought

The Unarchiver, one of the more handy tools for, uh, unarchiving, um, archives, is now a commercial app. 3.11.1 can run on 10.4 PowerPC, but the "legacy" download they offer has a defective resource fork, and the source code is no longer available.

The same author also wrote an image display tool called Xee. 2.2 would run on 10.4 PowerPC. After Unarchiver's purchase, it seems Xee was part of the same deal and now only Xee 3 is available.

Fortunately my inveterate digital hoarding habit came in handy, because I managed to get both a working archive of The Unarchiver 3.11.1 and Xee 2.2 and the source code, so I can try to maintain them for our older platforms. (Xee I have compiling and running happily; Unarchiver will need a little work, but it's doable.) But that's kind of the trick, isn't it? If I hadn't thought to grab these and their source code a number of months ago as part of my standard operating procedure, they'd be gone, probably forever. I'm sure MacPaw (the new owners) are good people but I don't foresee them putting any time in to toss a bone to legacy Power Macs, let alone actually continue support. When these things happen without warning to a long-time open source free utility, that's even worse.

That said, the X Lossless Decoder, which I use regularly to rip CDs and change audio formats and did donate to, is still trucking along. Here's a real Universal app: it runs on any system from 10.4 to 10.12, on PowerPC or Intel, and the latest version of July 29, 2017 actually fixes a Tiger PowerPC bug. I'm getting worried about its future on our old machines, though: it's a 32-bit Intel app, and Apple has ominously said High Sierra "will be the last macOS release to support 32-bit apps without compromise." They haven't said what they mean by that, but my guess is that 10.14 might be the first release where Intel 32-bit Carbon apps either no longer run or have certain features disabled, and it's very possible 10.15 might not run any 32-bit applications (Carbon or Cocoa) at all. It might be possible to build 64-bit Intel and still lipo it with a 32-bit PowerPC executable, but these are the kinds of situations that get previously working configurations tossed in the eff-it bucket, especially if the code bases for each side of the fat binary end up diverging substantially. I guess I'd better grab a source snapshot too just in case.

As these long lived apps founder and obsolesce, if you want to something kept right, you keep it yourself.

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.