Saturday, November 21, 2015

TenFourFoxBox: because it's time to think inside the (fox)box. (a/k/a: we dust off Mozilla Prism for a new generation)

As long as there have been web browsers, there have been people trying to get the web freed up from the browser that confines it, because, you know, the Web wants to be free, or some other similarly aspirational throwaway platitude. These could be robots, or screen scrapers, or aggregating services, or chromeless viewers, but no matter what these browserless browsers are doing, they all tend to specialize in a particular site for any number of reasons usually circulating around business or convenience. This last type, the chromeless viewer, spawned the subcategory of "site specific browsers" that morphed into the "Rich Internet Application" and today infects our phones and tablets in the guise of the "lazy-*ss programmer mobile app."

Power Mac users have only had access to a few tools that could generate site-specific browsers. Until Adobe withdrew support, Adobe AIR could run on PowerPC 10.4+, but it was more for generally Internet-enabled apps and wasn't specifically focused at creating site-specific browsers, though it could, with a little work. Leopard users could use early betas of Fluid before that went Intel-only, and I know a few of you still do. Even Mozilla themselves got into the act with Mark Finkle's WebRunner, which became Mozilla Prism in 2007, languished after a few releases, got moved to Salsita and renamed WebRunner again in 2011, and cancelled there as well around the time of Firefox 5. However, WebRunner née Prism née WebRunner was never available for Power Macs; its required binary components were Intel-only, even though the Mozilla releases could run on 10.4, so that was about it for PowerPC. (Mozilla tried again shortly afterward with Chromeless, but this didn't get off the ground either, and was never intended as a Prism successor in any case. Speaking of, Google Chrome can do something similar, but Chrome was of course never released for Power Macs either because Alphagooglebet are meaniepants.)

There are unique advantages as TenFourFox users to having separate apps that only handle one site at a time. Lots of tabs requires lots of garbage collection, the efficiency of which Mozilla has improved substantially, but is still a big drain on old computers like ours which are always under memory pressure. In addition, currently Firefox and TenFourFox must essentially cooperatively multitask between tabs because JavaScript infamously has run-to-completion semantics, which is why you get the "script too long" dialogue box if the watchdog portion of the browser detects something's pegging it. Since major portions of the browser itself are written in JavaScript, plus all those addons you tart it up with, the browser chrome must also cooperatively multitask with everything else which is why sometimes it temporarily grinds to a halt. I've sunk an incredible amount of time over TenFourFox's existence into our just-in-time JavaScript compiler for PowerPC to reduce this overhead, but that only gets us so far, and the typical scripts on popular websites aren't getting any less complex. Mozilla intends to solve this problem (and others) with multi-process Firefox, also known as Electrolysis, but it won't work without significant effort on 10.4 and I have grave doubts about its ability to perform well on these older computers; for that reason, I've chosen not to support it.

However, generating standalone browser apps for your common sites helps to mitigate both these problems. While each instance of the standalone browser uses more memory than a browser tab, with only one site in it garbage collection is much easier to accomplish (and therefore faster), and the memory is instantly reclaimed when the standalone browser terminates. In fact, on G5 systems with more than 2GB of RAM, it helps you actually use that extra memory more effectively: while TenFourFox is a 32-bit application (being a hybrid of Carbon and Cocoa), you'd be running multiple instances of it, all of which have their own 32-bit address space which can be located in that extra RAM you've got on board. Also, separate browser instances become ... multiple processes. That means they preemptively multitask, like Electrolysis content processes would. They could even be scheduled on a different core on multiprocessor Power Macs. That improves their responsiveness substantially, to say nothing of the fact that the substantially reduced amount of browser chrome has dramatically less overhead. Now, standalone browsers also have disadvantages; they lack a lot of the features of a regular browser, including safety features, and they can be more difficult to navigate in because of the reduced interface. But for many sites those are acceptable tradeoffs.

So, without further ado, let's introduce TenFourFoxBox.

TenFourFoxBox is an application that generates site-specific browsers ("foxboxes") for you, running them in private instances of TenFourFox (a la XULRunner). This has been one of my secret internal projects since I got Amazon Music working properly with TenFourFox, so I wanted to use it as a jukebox without dragging down the rest of the browser, and to help beef up the performance of my online coursework site which has a rather heavy implementation and depends greatly on Google Docs and Box. And now you'll get to play with it as well.

Although TenFourFoxBox borrows some code from Prism/WebRunner, mostly the reduced browser chrome, in actual operation it functions somewhat differently. First, TenFourFoxBox isn't itself written in XUL; it's a "native" OS X application that just happens to generate XUL-based applications. Second, for webapps created with Prism (or its companion tool Refractor), it's Prism itself that actually does the running with its own embedded copy of the XUL framework, not Firefox. With TenFourFoxBox, however, foxboxes you create actually run using the copy of TenFourFox you have installed (and yes, the foxboxes will look for and run the correct version for your architecture), just as separate processes, with their own browser chrome and their own application support and cache directory independent of the main browser. The nice thing about that is when you upgrade TenFourFox, you upgrade the browser core in every foxbox on your system all at once, as well as your main browser, because TenFourFox is your main browser, amirite?

The implementation in TenFourFoxBox is also a little different with respect to how data is stored. Foxboxes are driven essentially as independent XULRunner apps, so they have their own storage separate from the browser. Prism allowed this space to be shared, but I don't think that was a good idea, so not only are all foxboxes independent, but by default they operate effectively in "private browsing" mode and clear out cookies and other site data when they quit. By default they also disable autocomplete, improving both privacy and a little bit of performance; you can, of course, change these settings, and override checks sites might do which could detect you're not actually in a regular browser. I also decided to keep a constant unchanging title (regardless of the website you're viewing) so that you can more easily identify it in Exposé.

So, let's see it in action. Here's Bing Maps, in full 1080p on the quad G5, looking for drone landing sites.

And here's what I originally wrote this for, Amazon Music, playing the more or less official album of International Space Year:

(Stupid Amazon. I already have Flood and Junta!)

So now it's time to get this ready for the masses, and what better way than to have you slavering lot mercilessly bang on it? The following bugs/deficiencies are known:

  • The application menu only has "Quit." This is actually Mozilla bug 1181977, and will be fixed in TenFourFox 38.5, after which all the foxboxes will "fix themselves."
  • Localization isn't supported yet, even if you have a localized TenFourFox; most things will still appear in English. It's certainly possible to do, just non-trivial because of TenFourFoxBox's dual nature (we have to localize both the OS X portion and the XUL code it generates, and then figure out how to juggle multi-lingual resources). I'm not likely to do anything with this until the rest of it is stable enough to freeze strings.
  • Although the browser core they run is shared, individual foxboxes have their own private copies of the foxbox support code and chrome which are independent. Thus, when a new TenFourFoxBox comes out, you will need to manually update each of your foxboxes. You can do this in place and overwrite them; it's just somewhat inconvenient.
  • There are probably browser features missing that you'd like. I'm willing to entertain reasonable requests.

Even the manual is delivered as a foxbox, which makes it easy to test on your system. Download it, try it and post your comments in the comments. TenFourFox 38.4 or higher is required. This is a beta, so treat it accordingly, with the plan to release it for general consumption a week or so after 38.5 comes out.

Let's do a little inside-the-box thinking with an old idea for a new generation, shall we?

Wednesday, November 11, 2015

Two interesting things

(Shout-out to Stories of Apple, which did a very nice piece on TenFourFox. Check out their other fascinating articles on Apple history. And a shout-out to my father, an American veteran, for his service to this country.)

First, from the Google Chrome blog:

Today, we’re announcing the end of Chrome’s support for Windows XP, as well as Windows Vista, and Mac OS X 10.6, 10.7, and 10.8, since these platforms are no longer actively supported by Microsoft and Apple. Starting April 2016, Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

(Recall that Google had already dropped 32-bit Intel Macs with Chrome 39.)

I've long warned on this blog that Firefox dropping 10.6 support will probably really hurt us in TenFourFox-land, since there are major API changes and assumptions about the compiler, as well as the loss of 32-bit support (we are a hybrid Carbon/Cocoa 32-bit application, even on G5 systems). Naturally, we would of course add it back in just like we did when 10.4 and 10.5 support was progressively removed from the tree, but it would greatly hurt long-term maintainability and may force dependencies on certain features Tiger just doesn't have. However, with 45 (the next ESR) now on Nightly with 10.6 support still fully in effect, and with even plans to merely drop 10.6.0-10.6.2 stalling, it doesn't look like that will happen before 45ESR. That at least gives us a chance at one more ESR version assuming Electrolysis isn't mandatory by then.

Now, second. I've never particularly been a big fan of Grüber Alles, but he says something very interesting in his review of the iPad Pro:

According to Geekbench's online results, the iPad Pro is faster in single-core testing than Microsoft's new Surface Pro 4 with a Core-i5 processor. The Core-i7 version of the Surface Pro 4 isn't shipping until December -- that model will almost certainly test faster than the iPad Pro. But that's a $1599 machine with an Intel x86 CPU. The iPad Pro starts at $799 and runs an ARM CPU -- Apple's A9X. There is no more trade-off. You don't have to choose between the performance of x86 and the battery life of ARM.

We've now reached an inflection point. The new MacBook is slower, gets worse battery life, and even its cheapest configuration costs $200 more than the top-of-the-line iPad Pro.

Although it's quite possible this says more about how bad the new MacBook sucks than about how good the iPad Pro is, it really looks like those P.A. Semi folks Apple snapped up a few years back (yes, the people who worked on the PWRficient PA6T, one of the PowerPC CPUs in the running for the post-PowerBook G4 PowerBook) are starting to make serious inroads against x86. POWER remains a monster in the datacenter because it can scale, and, well, it's IBM, but IBM hasn't cared (as much) about performance per watt in that environment for quite some time whereas that matters a great deal in the consumer market, and that's why we never got a PowerBook G5. For years industry pundits said the reason ARM chips were so thrifty with their power usage is that they weren't all that powerful, comparatively speaking. Well, the A9X changes that landscape substantially: now you've got an ARM core that's seriously threatening the low to mid range of Chipzilla's market segment and is highly power efficient, and I can't imagine Intel isn't scared about Apple licensing their design. This blog may be written by an old RISC fetishist -- in this very room I have a PA-RISC, a SuperH, a SPARC, a DEC Alpha, several SGI-MIPS and of course a whole crapload of PowerPC hardware -- but after seeing these surprising benchmark numbers all those old rumours about Apple eventually coming up with an ARM MacBook suddenly don't seem all that far-fetched.

Finally, okay, okay, three things, this Engrish gem from mozilla.governance, emphasis mine:

I’m now writing to you to tell you something that make me puzzled. As I know, Firefox is a free browser which offers users independent web suffering.

We all know it, brother. We all know it. :)

Friday, October 30, 2015

TenFourFox 38.4.0 available

TenFourFox 38.4.0 is now available for testing (release notes, downloads, hashes), just in time for you to surf on your iBook G4 while you aim your water cannon loaded with Tabasco sauce at juvenile delinquents craving candy. You know, as you do. Along with fixes for two crashes (most notoriously issue 308) and miscellaneous, this version, as promised, includes complete HTML5 MP3 audio support. To try it out, turn tenfourfox.mp3.enabled to true. If there are no major issues, it will be the default in 38.5.

As always, barring major issues, the browser will be released officially late Monday Pacific time, along with unveiling the new El Spoofistan design for the main page.

In other ecosystem news, I am incredibly delighted to see Tenfourbird 38.3 from our anonymous builder in the land of the Rising Sun, and it works great -- I use it for (appropriately enough) reading Try it. You'll like it.

Saturday, October 24, 2015

And now for something completely different: El Crapitan sucks (or why SIP will make me go Linux if they keep this crap up)

ObTenFourFox news: 38.4 goes to build next week when Mozilla drops build tags on ESR with a couple more fixes too. Watch for it. Recommended.

Yes, I confess I actually do own two Intel Macs, an old 2007 Core 2 Duo Mac mini running 10.6 which mostly serves as a test machine, and a 2014 i7 MacBook Air which I use for taxes and Master's program homework. The MBA reminds me regularly of why I preferred the New World Power Mac days, and why my daily drivers are still all Tiger PowerPC. Lately every year when Apple issues their annual update I get a bit nervous because their quality assurance seems to have gone right down the pot -- I think the beta testers just twiddle a couple buttons and call it good for golden master, and never mind when everyone's machines explode because they might actually have customized it a bit, or something similarly empowering that Apple doesn't want you doing with your overpriced appliances. (More on that when we get to my overall gripe at the end.)

Part of what makes my trepidation more acute is that I actually do write software that can run on a current Intel Mac from time to time, despite my reputation as a Power Mac-clinging troglodyte. Now, this software is still truly Universal in the strictest sense of the term -- I build on my G5 against the 10.4 universal SDK to make applications that generally run on any Mac OS from 10.4 till now, on any Power Mac and on any Intel Mac, and I even found a version of SDL 1.2 (1.2.14) that happily runs in the same environments on all systems without tripping any deprecation warnings so far. I'll be talking about one particular app in the very near future because not only is it Universal ppc/i386, it also includes AltiVec support, so it's actually 750/7400/i386. Keep an eye out for that column. Fortunately El Capitan didn't break the ones I write based on that environment.

Next, I turned to GopherVR and Mosaic-CK, my rebuilds of two venerable Motif-based X11 applications (the GopherVR client, allowing you to view gopherspace graphically, and an updated port of NCSA Mosaic that doesn't immediately barf on newer pages). These use a special launcher program to install a Dock icon and transfer control to the binary under X11. They both crashed immediately. I looked in the console and found that they were unable to run OpenMotif, which they should have detected, but I said no problem and got out my installer of IST OpenMotif 10.5+ which worked perfectly in Yosemite. On El Cap, it wouldn't install.

Why? Blame the new System Integrity Protection, which amongst other things blocks write access to certain directories, in this case /usr, even if you're root ("rootless protection"). OpenMotif expects to install itself to (more or less) /usr/OpenMotif. El Crap won't let it.

Now, you can keep your superior security snark out of my comments, thanks. I get why SIP exists, because users are stupid, and SIP saves them (somewhat) from themselves. At least so far, unless some gaping kernel hole is discovered, it looks pretty hard to toast an SIP-locked installation other than via hardware failure, and yes, if you're willing to jump through a couple hoops, you can turn it off. But you don't have to be particularly clairvoyant to realize Apple won't let you do that forever, and even now it's mostly all or nothing unless you turn SIP off and tinker with its configuration file. Frankly, making users go to all that trouble isn't a good way to distribute software.

So the first thing I did was patch OpenMotif to run from /Applications, which isn't protected (yes, /Library might be more appropriate, but I had to patch a couple paths embedded in the libraries in place and the length matched better), by changing all the linkages to the new path with a Perl script I dashed off and doing a couple direct binary changes. It looked sane, so I put it in /Applications/OpenMotif21 and rebuilt the apps on the G5 to link against that. It worked fine on 10.4 and 10.6, but on the 10.11 MBA they still crashed.

This time, the OpenMotif libraries could be found, but they were linking against /usr/X11R6, because that's where the universal X11 libraries are in the 10.4 universal SDK and every version of OS X from 10.5 to 10.10 had a symlink to /usr/X11 so it all just worked. Guess what new version of OS X doesn't? And guess what version prevents you from modifying /usr to add that link because of SIP?

I toyed with a couple solutions, but the simplest was to lipo a second i386 binary from the main one (since all Power Macs will run the original binary pointing to /usr/X11R6 fine) at the time the app package is built and rewrite all its linkages to /usr/X11 instead. Then, when the launcher starts, it figures out which binary to run depending if /usr/X11R6 exists or not, and transfers control to that. It's ugly and it bloats the app by about 25%, but it's transparent to the user, at least, and it doesn't require the user to have developer tools installed or I'd just have the launcher do the stripping and rewriting on the fly.

After that, I fixed a couple more bugs (including the original one where I had a short-circuit in the prerequisites detector) and packed everything up for distribution, and now you can use GopherVR and Mosaic-CK once again. Make sure you have X11 or XQuartz installed first, and then grab my patched OpenMotif from SourceForge (choose the 10.4 package for Tiger, or the 10.5 package for Leopard through El Capitan). Just drag the folder to /Applications without changing the name or any of the contents, and then run either GopherVR and Mosaic-CK's launcher app, and it should "just work" on any 10.4+ Mac just as it did before.

Why does SIP annoy me most, though, aside from making my binaries more complex and my headache larger? Simply put, I don't like the feeling I don't own my computer, and I'm getting that feeling more and more from Apple. I feel this much less on my Tiger boxes because I can patch them up manually and improve their security and functionality, or alter the way the OS is laid out to suit my taste and needs and how things are installed and activated, and I'm quite sure Apple has great concerns about allowing that on what they consider to be an "appliance." In fact, the irrepressible cynic in me suspects part of SIP's purpose is not just security -- it also has the (to Apple) desirable side effect of forcing most systems to exist in a specific uniform state so that installations and upgrades are more deterministic instead of allowing a (dangerously?) clueful user to muck about at will. While predictions that Gatekeeper would become locked in stone and unsigned apps would be never be allowed to run even by request have not yet come to pass, a lot fewer people will be inconvenienced by SIP than by Gatekeeper except for nutbag tinkerers and hackers like me, and Apple has little downside to making it permanent in a future version of OS X. That means one day you may not be able to change the OS at all except through those changes Apple authorizes, and that would really suck. It would also drive me to Linux on commodity hardware, because if system limitations mean I can't find a way to run my custom apps on a current Mac that run just fine on my G5 daily driver, then why have a current Mac? As it turns out, I'm not the only one thinking about that. What's Apple going to break next year, my legs?

Geez, Tim.

Monday, October 19, 2015

Waiting for the MP3 to do the tune thing, MP3, MP3, sing!*

I'm pleased to announce complete MP3 audio support for TenFourFox, i.e., HTML5 audio using MP3 (with minimp3 as the decoder since 10.4 AudioToolbox lacks MP3 decoding) -- the last remaining piece was getting intratrack seeking to function and I finished that up over the weekend. So far I've tested it against Soundcloud, Amazon Music and a few other sites as well as my own audio library and it all seems to work properly. Seeking is sequential, so it's a little slow on long tracks, but playback functions pretty much as expected. MP3 support will still ship disabled in 38.4.0 but if all goes well it will be publicly rolled out in 38.5.0 as I previously promised. The QTE will of course still work for playing tracks outside of the browser.

(*apologies to TMBG, "Dinner Bell" from Apollo 18)

Thursday, October 15, 2015

And now for something completely different: The Ricoh Theta m15 panoramic camera and QTVR LIVES!

It's been awhile since I've posted, mostly because I've been in Honolulu/Oahu for over a week with the fiancée and her family, but that doesn't mean I don't love you. Well, maybe it does mean that, but I still like you. Well, most of you. At times. Mood permitting.

Anyway, ObTenFourFox news. The two biggest crash bugs are hopefully repaired, i.e., issues 308 and 309. Issue 308 turned out to be related to a known problem with our native PowerPC irregexp implementation where pretty much anything in the irregexp native macroassembler that makes a OS X ABI-compliant function call goes haywire, craps on stack frames, etc. for reasons I have been unable to determine (our Ion ABI to PowerOpen ABI thunk works fine everywhere else). In this situation, the affected sites uncovered an edge case with checking for backreferences with UTF-16 text that (surprise) makes an ABI-compliant call to an internal irregexp function and stomped over rooted objects on the stack. I've just rewritten it all by hand the same way I did for growing the backtrack stack and that works, and that should be the last such manifestation of this problem. Assuming it sticks, the partial mitigation for this problem that I put in 38.3 will no longer be necessary and will be pulled in 38.5 since it has a memory impact.

Issue 309 was a weird one. This was another Apple Type Services-barfing-on-a-webfont bug that at first blush looked like we just needed to update the font blacklist (issue 261), except it would reliably crash even 10.4 systems which are generally immune. Turns out that null font table blobs were getting into Harfbuzz (our exclusive font shaper) from ATS that we weren't able to detect until it was too late, so I just wallpapered a bit in Harfbuzz to handle the edge case and then added the fonts to the blocklist as well. This doesn't affect Firefox, which has used CoreText exclusively ever since they went 10.6+. Both fixes will be in 38.4.0.

The problem with restoring from LZ4-compressed bookmark backups remains (issue 307) and I still don't know what's wrong. It doesn't appear to be an endian problem, at least, which would have been relatively easy to correct. The workaround is to simply not compress the backups (i.e., roll back to 31) until I figure out why it isn't functioning correctly and it will be in 38.4.0 also. I've also been doing some work on seeking within our MP3 audio implementation, which is the last major hurdle before enabling it by default. It won't be enabled in 38.4.0, but there might be enough of it working at the time of release for you to test it before I publicly roll it out (hopefully 38.5).

Also, some of you might have been surprised that I didn't post anything at the time about Mozilla's new plan to pull plugins (TenFourFox has of course been plugin-free since 6.0). I didn't comment on it frankly because I always figured it was inevitable, for many of the same reasons I've laid out before ad nauseam. Use SandboxSafari if you really need them.

Anyway, moving on to today's post, one of my hobbies is weird cameras. For example, I use a Fujifilm Real 3D W3 camera for 3-D images, which is a crummy 2D camera but takes incredible 3D pictures like nothing else. The camera takes both stills and video that I can display on my 3D HDTV, or I can use a custom tool (which I wrote, natch) to break apart its MPO images into right and left JPEGs and merge them into "conventional" anaglyphs with RedGreen (from the author of iCab, as it happens). I haven't figured out yet how to decode its AVI video into L/R channels, but I'm working on it. Post in the comments if you know how.

Panoramas have also been a longtime interest of mine, facilitated by QuickTime VR, another great software technology Apple completely forgot about (QTVR works fine through 10.5 but 10.6+ QuickTime X dropped it as a "legacy" format; you have to install QuickTime 7 to restore support). Most mobile devices still do a pretty crappy job on panos, and even though iOS and Android's respective panorama modes have definitely improved, they could scarcely have gotten worse. My original panorama workflow was to take one of my Nikon cameras and put it on a tripod, march out angles, and labouriously stitch them together with Hugin or QTVR Authoring Studio. QTVR Authoring Studio, by the way, works perfectly in Classic under 10.4, yet another reason I remain on Tiger forever. Unfortunately this process was not fun to shoot or edit, required much fiddling with exposure settings if lighting conditions were variable, usually had some bad merge areas that required many painstaking hours with an airbrush, and generally yielded an up-down field of view as roomy as an overgrown mail slot even though the image quality was quite good.

The best way to do panoramas is to get every single angle at once with a catadioptric camera. These can be added as external optics -- unfortunately with varying levels of compromises -- to an existing camera, or you can do substantially better by getting a camera expressly built for that purpose, which in this case is the Ricoh Theta m15.

The Ricoh Theta cameras are two fisheye lenses glommed together for a 360 degree view in both axes generated as an equirectangular image; the newest member, the Theta S, just came out (but too late for my trip). The m15 comes in four colours, all of them silly, but mine is blue. You can either take free shots with the button, or you can control it with a smartphone (iOS and Android apps available) over Wi-Fi using either the official Ricoh app or the free Android HDR one (tripod strongly advised).

The m15 doesn't take exceptional images in low light, and the resolution is a bit low (6.4 megapixels at 3584x1792, but remember that it's two images that the camera firmware glues together, and there's an awful lot of spherical aberration due to the design). But it does work, and you shouldn't be scared by the reviews and instructions saying you need a current Intel Mac or Windows PC to view your images. That's a damn lie, of course -- connect the camera over USB and Image Capture will happily download them (even 10.4), or have the smartphone apps download the images to your phone and send them over Bluetooth or E-mail them. Either way, the images work perfectly as QTVR panos; you don't need the Ricoh desktop software. When you load the image into QTVR Authoring Studio and make sure it's oriented horizontally, it "just works" with no tweaking necessary:

And here's a frame from the result, in QuickTime 7 (rendered out at 1024x768, high quality, 100% Photo JPEG compression):

Unlike the ugly map-on-a-sphere distortion the Ricoh apps cause, the QTVR pano looks just like "you're there," and you can share it with all your friends without any other software other than QuickTime. You can look all the way up and down, ignoring the camera's limp effort to edit itself and its base out, and there are no stitch lines or agonizing hours of retouching. With just a few seconds of processing, I'm back along the side of Interstate H3, looking over the Kaneohe bay once again. A perfect memory, perfectly captured. Isn't that what you bought the camera for in the first place?

The new Theta S bumps the resolution to 14.4 megapixels (5376x2688), and both the m15 and S are capable of video with the S offering 1080p quality. In fact, I'm so pleased with even the lower resolution of the m15 that I'll be picking up an S very soon, and my suspicion is it will work just as well. It's wonderful to see that an old tool like QTVR Authoring Studio still works flawlessly with current cameras, and given that QTVR-AS was never written for OS X, it's another example of how Classic is the best reason to still own an Power Mac.