Ten years of the Twentieth Anniversary Macintosh ... or something (plus: try MTE v2)

The Twentieth Anniversary Macintosh still doesn't know what to make of this:

On the other hand, I have a 1984-2004 poster on my machine room wall.

And yes, today is indeed the 30th anniversary of the original Macintosh Super Bowl big game ad, for those of you hiding out under a rock for the last several decades. Apple did a retrospective video for apple.com, which because they used a weird manner to do it, is not compatible with the QTE. However, here are the low bandwidth and high bandwidth versions (QTE users can right click and select "Open Link in QuickTime" to play the movie). While much of it is the usual Apple equals sex design twaddle, the following classic and vintage Macs are featured, in order of appearance: the original 128K (of course), the Macintosh XL (presumably standing in for the Lisa), the Macintosh II, the Macintosh Portable, the Macintosh LC, the PowerBook 100, a Quadra 9x0 (either a 900 or a 950, amusingly lacking the key), a Color Classic, a Power Macintosh 8500 or 9500, a Macintosh SE/30 (called SE 301, with an FWB hard drive icon), a Twentieth Anniversary Macintosh (mine is better), a tower beige Power Macintosh G3, a Bondi Blue iMac G3 (the machine that arguably saved Apple), a graphite Power Mac G4 (either a Yikes! or a Sawtooth), a Blueberry iBook G3, a Titanium PowerBook G4, a 15" iMac G4, a 14" iBook G4, and finally the Power Mac G5. After that is all the Intel rot. But it's fun to see the creative luminaries assembled for this well-produced short, and of course the return (however briefly) of the rainbow Apple logo we all loved back when:

For the record, I own about 2/3rds of the featured pre-Intel Macs; the first Mac I used was my friend's dad's Mac Plus, and the first Mac I personally owned was a IIsi. And, btw, as a physician the scene of an iPad over a sterile surgical field near the end makes me shudder.

The real anniversary for us is March 14, 2014, the 20th anniversary of the Power Mac 6100 and the first Power Mac (along with the 7100 and 8100). I remember the new Power Mac well when I was in college. We'll do a special retrospective then.

No one has indicated serious intestinal distress over the highly automated way I've taken the new MacTubes Enabler, so you can download a prototype and try it. Here's an appropriate one: the Apple 1984 Super Bowl big game ad. As a bug I've subsumed as a feature (I think this is a glitch in the Add-on SDK), if you search for a video in YouTube and go to it from there, the video plays in the browser, so you can still interact with the (puke) comments and (gag) other users. But if you click on a YouTube URL anywhere else, or you cut and paste a YouTube URL into the address bar, it automatically opens in MacTubes and goes back to what you were doing. If the URL opens in a new tab, the tab automatically closes. Try it. I like it.

24.3.0 should come out this week or weekend.

IBM, MacTubes, monkeys and morons (plus: Quake is better in OS 9)

UPDATE: IBM sold the entire x86 server line to Lenovo after all, for a billion less than Google paid for the Nest.

About eight months ago, your faithful chronicler reported IBM, developers of the POWER architecture from which PowerPC descended, was trying to exit the x86 server business and sell it to Lenovo. As I mentioned in that article, margins are thinning on x86 servers, especially as companies like Google and Facebook build their own bespoke devices (Google has even looked at designing its own POWER and ARM processors), and IBM has never liked being in low-margin markets just as Apple doesn't. Well, looks like that foundered and IBM is shopping the business to Dell. Either way, IBM really wants out and I think you'll see the bottom fall out of the commodity x86 rackmount market, leaving the low-margin no-name companies to struggle for that money while the big corporations like Oracle and IBM continue to produce their proprietary RISC lines. (That must alarm Hewlett-Packard, which is stuck on Itanium with its clouded roadmap having jettisoned PA-RISC long ago. I have a fondness for PA-RISC since my first job out of college was working on a HP 9000 K-Class.) As I mentioned in the previous article, it's good news for POWER in general, since this makes it a bigger proportion of IBM's product portfolio and ensures its continued evolution even if it is gradually disappearing from the mass consumer market.

I've been playing with the next release of the MacTubes Enabler, which a number of you are already using. Since YouTube pages are only getting heavier and our computers aren't getting any faster, my current idea is to completely avoid making the browser do the work of loading the page so that you can labouriously click through the context menu to start MacTubes -- it should just hand the URL right off and halt the load so you can go back to what you're doing. And that's what it does: when a YouTube video URL is detected, it automatically fires up MacTubes and then either backs up to the previous page or closes the tab if it was a new tab like a program passing your browser a URL. In fact, if you visit any YouTube video page, the switchover occurs automatically, though things like the YouTube search are still within the browser (I figure you're doing that on purpose if you're not using MacTubes for the actual search portion). Embedded videos can be played if they properly include the embed code that has a link to the video -- you click the link and MacTubes starts, easy as that. You can still play an embedded video in WebM directly in the browser. If you use the QuickTime Player mode in MacTubes, you should be able to get HD videos and download them directly from the client.

So far this approach seems to be working well and it's nice that it's totally automatic. Please note that I haven't tested this with any tab-management addons, but this is using Mozilla's Add-on SDK for tab control, so it's not doing anything it shouldn't be. If anyone has objections, voice them in the comments; if people like how the idea sounds, I'll release that as the next version of the MTE in a couple of weeks.

IonMonkey PowerPC has progressed to the point where it can now compile and run loops in JavaScript, which particularly for floating point operations execute dramatically faster than the current PPCBC compiler (as expected). Memory usage is higher, but that is expected too; although function calls are still problematic, I have some ideas about how to fix this. I'm hoping to have a beta for IonMonkey for either 29-aurora or 31-aurora. If we make it to Fx31, I want IonMonkey to be ready by then as a marquee feature.

In other news, the morons at Google Code has shut down new downloads as threatened. Please extend your middle fingers in salute to this policy. All further uploads, including localization packs, will be on SourceForge; historical downloads will remain on Google Code "while they last." The transition to SourceForge is complete for file hosting, and we'll see what happens with the rest of it.

Finally, for you classic Mac OS gamers, I had some friends over for a good-old-fashioned LAN party so we could kill each other in Quake. We chose the original Quake because it has little network demand (particularly on modern networks), the same protocol works on Mac OS 9 and I have many OS 9 machines (this was a problem with Quake III Arena, where ioquake3 and the official id software Mac OS 9 compatible version use different network protocols), and you can get it hardware-accelerated with GLQuake for both OS X and OS 9. Our initial idea was to have the G5 be the Quake server, but GLQuake X crashed randomly and repeatedly during game play, greatly preventing me from firing rockets into my beloved friends' visceral cavities. So, just to see what would happen, I assigned server duties to the Power Mac 7300 running OS 9.1 (with 1GB RAM, a G4/800 Sonnet upgrade card and an ATI Rage Orion 3D accelerator). It never crashed for the hours of game play after that. Maybe GLQuake X is glitchy on 10.4, maybe it was some process on the G5, but if you want a solid Quake (or probably even Quake II) server, a reasonably-specced OS 9 machine did the trick for us. Go Classic go!

My New Year's Resolution is to fix IonMonkey ...

... and ask Scarlett Johansson out on a date. Fortunately, I have made progress on the more realistic goal of the two:

Starting program: /Volumes/BruceDeuce/src/mozilla-26.0/obj-ff-dbg/dist/bin/js --ion-eager -e var\ i=0
Reading symbols for shared libraries ... done

Program exited normally.

Like our initial victory with PPCBC, this is the simplest of simple JavaScripts. But it proves the basic machinery for IonMonkey optimized JavaScript compilation is now, finally, working. A very ugly hack was required that should stick for the time being. Meanwhile, we will move on to more complicated scripts and fill in the holes in the code generator that I know are not correct.

Of course, the moving target that is the JavaScript JIT compiler in Firefox is moving again. Mozilla is unhappy with the slow, nay, nonexistent pace of progress on YARR, the regular expression library used in Firefox/TenFourFox imported from WebKit. At least one suggestion that has legs is to switch to V8 irregexp, the regular expression library used in V8 imported from Google Chrome. irregexp is pretty fast, but it means yet another macroassembler to write, and more importantly it means the Nitro macroassembler we use now for both YARR and (underlyingly) PPCBC would be removed and we'd have to actually write two new backends just to restore the level of JIT function we have now. Understandably I am less than thrilled with this possibility even though the work would not be excessively difficult; it would just be tedious and delay my porting activities further. I'm hoping Mozilla develops their own regex and bases it on the existing infrastructure so I'd only have to port our underlying code generation once when they get rid of Nitro. Fortunately this is not likely to be consummated in any meaningful way much before Firefox 31.

Don't even get me started on asm.js, by the way. That's waaaay down on the priority list.

24.3.0 is scheduled for 4 February, at which time the assault on 29 and Australis will begin. By the way, does anyone have Scarlett's phone number? Asking for a friend.

26.0, trouble in paradise

So over Christmas weekend I managed to get a debug build of TenFourFox 26 up and running. It basically works, though I figured it would (29, the first Australis release, is what worries me more). So that's the good news.

The bad news is that there are three major problems, one of which is worked around only incompletely, all of them having to do with the graphics stack. Recall that starting with Firefox 12, Mozilla introduced a scheme called Azure to reduce the overhead of graphics drawing by mapping graphics calls more directly into operating system primitives rather than running them through Cairo, the abstracted graphics system Firefox has used for almost everything since 3.0. We support Azure for HTML5 <canvas> elements, and in that employ it works very well, improving overall canvas performance for most shapes by about 60 percent.

Where our implementation falls flat is text and gradients; we need lots of hacks for 10.4 to make this work, and the overhead for these specific elements is significantly greater. (Text filled with gradients is even worse.) Unfortunately, a browser's primary job is to render lots and lots of text, and Mozilla now wants to use Azure to do the rendering for everything (relegating Cairo to a backup engine, and for printing). I have to disable "content Azure" in 26, or the browser renders things about three times slower overall in the debug build (and in an opt build we'd lose AltiVec-accelerated compositing through pixman too). I think we can get away with this for awhile since Cairo is still an integral part of the layout stack for now, but if Mozilla finds another printing solution then Cairo becomes expendable. I'm going to try to do more research to figure out if we can speed this up, but remember that the vast majority of supported Macs running Firefox have hardware acceleration and we don't. It's entirely possible that the combination of 10.4 graphics thunks and their hardware-tuned rendering strategy is just too much for Macs limited to software rendering like us.

On top of that, our current Azure implementation exposes bugs in 10.4 CoreGraphics that, although not obviously severe, generate invalid context errors and other such annoyances that suggest we're just wallpapering over more significant problems. I haven't figured out where these errors come from yet (I suspect DrawTargetCG::FillRect), and because of their frequency I can't enable content Azure in TenFourFox until I'm forced to.

The third problem is the most serious, and the one I don't know how to fix definitively. One of 10.6's new system features is blocks, a construct for creating closures in C, C++ and Objective-C that allows applications to better exploit Grand Central Dispatch: you can generate little snippets of code, wrap them up as a block, and pass them around in such a way that they can remember their original state when finally run and even execute in parallel. Blocks require both runtime support from the operating system to handle and execute them, and compiler support to understand the new syntax and generate the closure code. Apple implemented this in Xcode using their fork of gcc, but blocks are really a better first-class citizen in clang, and regular gcc doesn't support them.

Blocks can be added to 10.5 using PLBlocks, which offers a modified gcc (presumably using Apple's patches) and a userland framework for runtime support. Tobias himself already uses this package for Leopard WebKit, so we have good evidence it should work fine for this purpose. Although this framework does not exist for 10.4, it looks like it doesn't require any 10.5 Objective-C features to function, so it could probably be ported. That's not the real problem. The real problem is the compiler: we don't use gcc 4.0.1 or 4.2 anymore, and Apple never ported blocks to a later version (we use 4.6), so we'd have to roll this support ourselves off Apple's patches. Even assuming it works (which is a big if), I really don't want to be maintaining a compiler and an entire tool chain on top of a browser, linker and debugger, especially since it's likely we'll have to force another compiler change in the not-too-distant future (fortunately MacPorts already offers 4.8 and it works fine on 10.4). David Fang is still industriously working away on a PowerPC OS X clang, but I don't know how far along he is with it or if its codegen for blocks will work with the PLBlocks runtime, which we'll still need.

Fortunately, Mozilla uses blocks in a very limited way and only within the OS X widget library as callbacks for graphics calls, since no other compiler other than Apple's supports them. For the time being, these callbacks (which so far appear to only apply when hardware acceleration is active) can be partially emulated by spinning the closure out as a static function that can be passed as a function pointer. I say partially, because what this doesn't emulate is the, you know, closure part: being static functions they don't have access to class member properties, and even if they did (or we figure out some Rube Goldbergian bridge class) they have no memory of their value at creation, so it's possible for them to have the wrong value when the callback is triggered. I hacked around this and the app seems to be fine, but that's no guarantee it will continue to be. As Mozilla tries to optimize Firefox more for multi-core systems and Off-Main Thread Compositing looms on the horizon, the use of blocks in Mac-specific code is likely to increase because it's what Apple wants developers to do and it's relatively straightforward for developers to use, but it's going to be a big problem for us if that code is an essential part of the application.

26 will be issued as changesets only and maybe a debug build. The first unstable release will either be 29-aurora, if Australis works, or a new 24 branch if it doesn't. Cross your fingers.

Merry Christmas and Happy Holidays

Merry Christmas and Happy Holidays to you and yours.

TenFourFox 26's JavaScript is finally working again after some breaking changes Mozilla made. However, the graphics stack is now going to need a lot of work. Oh well. The good news is that 27/24.3.0 are on a slightly longer timeframe because of the holidays, so I have until February 4th to catch up.

So far no major bugs in 24 have cropped up; there are some minor ones that will be fixed in 24.3.0.

And now for something completely different: Mining Bitcoin with your Power Mac for fun and (not much) profit

Now that I've got some time over the holidays, the Firefox 26 port continues. Don't expect an unstable from this release (I'm not even done with JavaScript, though I'm almost done); it's just to keep things working until 29, when Australis descends like a ravenous harpy from the skies. At that point there will either be a 29-aurora or a hasty retreat.

Six months ago, Ars Technica ran a little article on Butterfly Labs' small Bitcoin miner. (For those of you unfamiliar with Bitcoin ("BTC"), this blog won't do it justice, but Wikipedia has a good overview.) The heart of "mining Bitcoin" is repeated, exponentially scaling computations to verify transactions based around the SHA-256 algorithm, for which participating computing resources receive a share of the fixed total number of Bitcoins themselves. Mining used to be done on regular general computing hardware, but this moved to GPUs as the profitability dropped, and now anyone who wants to seriously mine Bitcoin is now on dedicated ASIC hardware that simply computes SHA-256 hashes over and over as fast as possible. There are USB block erupters that generate around 300-400 MH/s (that's million hashes a second), this small BFL BitForce miner in the Ars article is a 5 GH/s miner (five billion per second), and the 28nm ASICs due in early 2014 are now in the 1-2 TH/s (trillion) range.

Bitcoin is highly speculative because there is no guarantee it will hold current value or even hold any value -- so please don't even think about BTC exchange unless you're good with obscenely high risk components in your investment portfolio. Furthermore, exchanges routinely fail, taking customer assets with them, and a large holder cashing in their hoard (Satoshi?) is likely to put the exchange price in the toilet. At the time the Ars article came out they were trading for around $130 per BTC, and I figured that a $274 investment to pick one up wasn't much money (to me) to be out if the company folded or the currency faded. I did a couple of tests on the G5 to make sure I could compile the software and it appeared to work (with CPU mining, at a pathetically low yield -- more later), so I pre-ordered one and then promptly forgot about it.

Almost six months passed. On Friday, a nondescript box arrived. It was the miner.

This particular Bitcoin miner connects over USB and appears as a serial port to the Mac. It uses standard FTDI serial drivers, which work just fine with 10.3 and 10.4 PowerPC. It draws about 35W under load, but because it requires a small amount of work from the G5 to keep it busy, I'm estimating its overall power impact at about 50W. Impressively, bfgminer says it's actually averaging around 5.6 GH/s, a nice boost over its stated capacity. The G5 is on 24/7 anyway to allow me to access files and run remote computing jobs, so it's no big deal to let the G5 run the miner also. Some people have assigned a Raspberry Pi to this task, so it's clearly not something that requires a heavy-duty computing controller.

Okay, you don't care about that. You care how much money it's making. Right now, Bitcoin trades at around $850/BTC. Bitcoin mining becomes exponentially more difficult as more BTCs enter circulation to avoid depleting the currency early, which is part of why the value increased from six months ago (simple supply and demand). At the current difficulty and exchange rate, the machine makes about $2.50/day. Given the slope of the curve, the estimated payback time is in the order of 5-6 months (this is imprecise because the difficulty is not totally predictable), but because of its very low power usage, it still remains fractionally profitable even down to making just 5 cents a day. I'm not going to be supermodels-and-Learjets rich, but it will probably make me at least a couple hundred dollars in overall profit.

However, this doesn't help you much because BFL doesn't make these things anymore, and the block erupters you buy on eBay are more than 10 times slower. A 333 MH/s USB block erupter makes about $0.15/day right now, and if one sells for $50 and the difficulty is always increasing ... well, you do the math. One argument against buying this kind of specialized hardware is that it's more profitable to make the mining devices than it is to do the actual mining. That is quite possible. ;) These little MH/s block erupters are easy to get because they don't really generate much money anymore; the heavy duty rigs take months to preorder and by then the difficulty has gone up even further.

But since we run web browsers on decade-old computers, we're clearly not here because we're excessively practical, so let's say you either want to just play around with Bitcoin or you got a block erupter or a proper ASIC miner from a generous friend. You'll need a wallet and a pool, for which the Ars Technica article has some suggestions, and then you'll need the software. Linux Power Mac users have it easiest; you can probably find a pre-built package for bfgminer or cgminer, both of which will run almost any hardware Bitcoin mining device. For 10.5 users, there is a port of cgminer that will apparently run on PowerPC with a basic interface. I'd be interested to hear if it works.

For 10.4, the situation is harder. I wasn't able to get cgminer to build at all, though I suspect I'm merely missing some of its prerequisites, and although the most current version of bfgminer can build with minor changes (3.8.0) it doesn't seem to work. Fortunately, the version of bfgminer (3.1.1) I hacked into building "back then" does work fine with the BFL miner, and as long as you have libusb installed from MacPorts or Fink it will work with most USB block erupters also. It emits a rather alarming number of hardware errors, but I suspect these are spurious because the mining pool I'm working with accepts my shares without comment and the mining pool's estimated GH/s rating matches what bfgminer is reporting. In about a week I should get my first 0.02BTC payout. So I guess that was worth my $274.

What if you just want to prospect a little with your own hardware, just for laughs? GPU mining is probably impossible on PPC OS X, though it might work on Linux (although I don't think any GPU that shipped with a Power Mac is OpenCL-capable), but you can use either software package to do CPU mining and bfgminer at least does have AltiVec support. The problem is you won't get very far even compared to a "basic ASIC" setup: a 600MHz G3 ekes out a pathetic 0.14 MH/s; a 1.67GHz 7450 G4 struggles to maintain 1.29 MH/s (source; recall that our miner is 5 GH/s == 5000 MH/s). Both are reasonably power-efficient computers, but neither will do their work in 35 or even 50 watts. Speaking of which, using the G5 for this is almost comically inefficient: my quad manages, with altivec_4way and four CPU threads, a comparatively impressive 6.7 MH/s but requires almost 300 watts of power to do it and pegs all four cores, rendering the computer essentially useless for any other purpose.

So, uh, keep clicking on the Google ads on this blog if you want to financially support this project. ;)

24.2.0 is live

And so is Maverickspoof.