With 10.8 coming out, I took the opportunity to migrate my OS installation from a traditional hard drive to an SSD. (Specifically, I installed a 256GB Samsung 830-series drive). I followed the general approach over at tonymac (I bought 10.8 online, then used his Unibeast wrapper to build an install-from-USB stick), modified for my setup. The installation of 10.8 to my SSD went swimmingly, but I noticed something odd – I needed to upgrade my version of Chimera (the Chameleon bootloader fork), as the previous version I’d been using without problem on 10.7 just barfed. (It rebooted immediately after starting to boot anything 10.8). But that was easy to fix by updating my version of Chimera (which I do manually, since my loader is on its own partition on a separate drive & the tonymac auto-install tools tend to screw that up). Of course, I also had to install fakesmc & wanted to get rid of the orange icons for my hard drives, so I also installed the ahci port-injector kext. But, that was it. I much prefer not to use “Multibeast” for post-installation, because it tends to crap out kexts all over that I don’t want — and which could lead to problems across software updates. (I also just like to know exactly what’s installed).

During installation, I did a fresh, full install. I did not do any kind of upgrade. (In fact, my 10.7 installation is still intact on my hard drive). However, I did want to keep my old user accounts with as little fuss as possible. So, I took note of the user ID, group ID, and UUID settings for each of my accounts as established in 10.7. Then in 10.8, I first created accounts corresponding to each of the existing user accounts. But before ever logging in to those accounts, I went in and changed the user/group/uuid settings (and obviously the home directory setting, to point it to the location on the old hard drive where the user data sits). This made for a seamless transition – accounts log in & have all of their old settings as they previously did, but I get awesome speed from having my OS and applications on the SSD.

Using xbench, I see speeds of between 350 & 425 MB/s, which is about what I expected. It doesn’t approach the peak speeds that the interface and the disk support, but that’s because of the controller I have it sitting on. My Gigabyte X58-based board only has a Marvell SATA3 controller, which is somewhat notorious for its inefficiency, bad drivers, and limited architecture. Further, the Gigabyte implementation is apparently flawed & only has the controller connected to a single PCIe lane on a PCIe 1.0 link. This limits the theoretical throughput to 250 MB/s. So, I bought an add-in card (an Asmedia ASM1061) for about $10 on Amazon. It’s a single-lane card as well, but installing it in to a PCIe 2.0 slot will up the theoretical throughput peak to 500 MB/s. (This controller works out-of-the-box without any additional drivers/kexts required). The only real problem with my resultant setup is that I’d also like this on Windows, but I have about 300 GB of applications (games – thanks, Steam sales!) on top of the Windows requirement, and I don’t really want to mess around with uninstalling/reinstalling games as I use them. So for Windows, I’ll wait for prices to drop some more & pick up a 512 GB SSD at some time in the future. Given that it’s been more than 2 years since I did any kind of major hardware tweak to this machine, it probably won’t be any time soon anyway.

My beloved Astros have beenbusy. I get wanting to get better, but trading away two modestly-paid All Stars for prospects seems… well, crappy. They’re already flat-out terrible, but watching Pence chase a hitting streak this season or Bourn fly around in center was at least reason to watch when they were a (rare) option in my out-of-market lineup. At least they’ve saved me some money – I can’t imagine spending $180 or so on MLB Extra Innings for at least 3 years.

I recently bought Mac OS 10.7 (“Lion”) for both my 2006 Core 2 Duo Macbook Pro and my i7-based hackintosh. I assumed that the Macbook Pro update would go smoothly, so I focused on preparing first for my hackintosh (after reading generally favorable outcomes online). First, I updated my bootloader from Chameleon 2 RC4 to an RC5 variant. However, the App Store would not let me continue my purchase (giving me the error “This version of Mac OS X 10.7 cannot be installed on this computer”). After reading over at tonymac that his/their variant of Chameleon (“Chimera”) was required, I installed that over my Chameleon 2 RC5 build — this did not make the App Store error go away. I was using the required MacPro3,1 system definition in my smbios.plist file, but it turns out this wasn’t sufficient – I had a bunch of other stuff in there (including DRAM information) from my Chameleon 2 RC4 install that was causing the problem. I installed the tonymacx86-provided MacPro3,1 system definition (from Multibeast), which in fact is actually just a relatively spartan smbios.plist file. That seemed to do the trick. It’s not clear if Chimera was actually required after all, but from there on out it was smooth sailing. I installed using the steps here, which include copying the installation files and kexts such as fakesmc to an installation partition, blessing it for boot, and then booting the installation partition to continue the install. The only real hitch was that my sound driver (voodoohda) was out of date & was 32-bit only, and I had switched over to using the 64-bit kernel. So, I had no sound until I installed the new driver.

All told, it was actually a pretty smooth transition, as far as hackintosh operations go. My only real beef with the process is that the “Multibeast” installer is very opaque about what exactly it’s installing and where they go. For example, I have my boot loader on a separate partition from my system drive, and I then chain-load Mac OS from Chameleon/Chimera. The installer basically takes a volume as a target & emits the files to assumed locations, and it doesn’t tell you which files are getting written out. To hunt and peck through the process of getting only what I needed (and then manually updating my loader partition after the fact), I had Multibeast install its various pieces to a scratch volume (a USB stick, actually), and I tested the various pieces using a separate USB stick with my loader & basic kexts (ahci port injector, openhaltrestart, and voodoohda). Once that was stabilized & working with 10.6, I updated my loader partition for the 10.7 installation process.

In contrast to the quirky-but-functional hackintosh update experience, my Macbook Pro got hosed by the upgrade. I’m still not sure exactly what happened. My Macbook Pro contains a non-default hard drive (the previous one was too small), but I didn’t do anything crazy there — I initialized it using the Mac OS (10.6) installer several months ago when I installed the drive, installed Mac OS, reinstalled my applications, partitioned using Boot Camp, and installed Windows 7 on there as well. So I started the 10.7 installer/upgrade process, and midway through (after a reboot into the 2nd phase of the installer), I get “Mac OS X Lion couldn’t be installed, because the disk is damaged and can’t be repaired” (where is obviously the name of my 10.6 partition). It then told me to re-try the installation (which wasn’t very helpful, given that I was stuck in an installation loop booting back in to the 10.7 installer which wouldn’t complete). It also suggested I get the data off my hard drive and do a clean install. Brilliant! Various reports online attempted to attribute this to hardware failure – which is incorrect. I booted my 10.6 installation DVD and attempted to repair the volume – same issue. I reset PRAM – no luck. I checked for SMART errors – none. The only thing I can attribute this to is my non-factory hard drive on the machine, but it definitely isn’t failing. I booted Windows, copied the data off using the HFS+ driver that Boot Camp installs, booted the 10.7 installation DVD (which I made prior to attempting the installation, just for this sort of eventuality), erased my 10.6 partition, and then did a clean install. This worked, as did restoring my data. But it took many hours & brought me quite close to data-loss disaster. If I’d have had this experience prior to installing on the hackintosh, I don’t think I’d have attempted the hackintosh installation so soon (or at least, without backups in triplicate – admittedly, I operated somewhat without a net when doing the hackintosh update).

Anyway, those are my experiences with the update – all I can say is that I’m glad I at least didn’t lose my Windows partition as well, which I’ve read that others have experienced.

I’ve made a few sporadic updates to my Hackintosh, so I thought I’d share them here.

First, the update to 10.6.7 went smoothly, as anticipated.

Second, I put in wired networking in my house, so I needed a wired-NIC solution. (I had been using wireless). I also needed something better than 100mbit, because that was a big motivator of bothering to put in wired networking in the first place. After enabling the onboard realtek gigabit NIC in my BIOS, it “just worked” in macos using built-in drivers. (Remember, I have a patched DSDT). However, realtek nics are less than stellar performers and are not that reliable. I could never get more than 750 mbit/s with it, and it would periodically just go down — this happened in both MacOS and Windows. Resetting the driver wouldn’t work. I’d have to reboot the machine. This is actually somewhat common with realtek hardware because of their crappy heavily MMIO-based interface — too many MMIOs in a short period of time and the state machine in the NIC’s firmware gets wedged (because some portions of the state machine do not have positive acknowledgement that they’ve completed – you do step A, then B, then C from the driver), and that’s it, you’re done.

So, I looked for an add-in card. I have a BCM5721 gigabit NIC, but I could not get this to work with stock drivers. I’d read people had success copying drivers from old MacOS builds, but I wanted to avoid this path because it could get killed in any subsequent update, and I’d have to redo it. There were multiple problems here. First, the driver attempts to enable wake-on-lan, and it fails given my system + hackintosh’s acpi information. However, you can disable wake-on-lan in the driver’s Info.plist. (this setting *is* sticky across most updates, btw). Even doing that, however, I couldn’t get the driver up. After a great deal of debugging (and playing with writing my own driver, which I discovered others had started on as well), I found that basically the stock driver isn’t handling message-signaled interrupts (MSIs) correctly. Likely Apple does not have this hardware installed on any systems that use MSI, or for those that do, the default interrupt vector is the correct one. I considered either modifying other drivers or writing my own, but at this point, I’d already spent a lot of time on this problem.

So, I took a gamble on a Marvell-based gigabit NIC. I bought a Rosewill RC-401-EX from Newegg for $23. And, I’m happy to report that it works out-of-the-box, with stock drivers. (No modified plists, nothing). I get line-rate with it (~940mbit/s using TCP netperf), and I have yet to have the interface wedge on me. It’s a great solution to this sort of problem, if you run in to it.

My late-2006 era Core 2 Duo iMac’s hard drive died recently. Though I don’t use that machine that often, fixing it was worth the effort given that I could probably sell the thing on craigslist for $500 if I really wanted to. (But, I actually do use it in our guest room when I’m working from home, because it’s quiet there). Anyway, disassembling an iMac of this era is *not* trivial. It’s not as bad as the newer (“Aluminum”) iMacs, which involve using a toilet plunger to suck the glass off the LCD. But, it’s still no treat.

Overall, I followed this guide over at ifixit.com, who also had the guide for replacing my Macbook Pro’s keyboard that I’d used before. As with the Macbook Pro teardown, you’ll want to read all the way through the instructions prior to starting and have some containers around for the screws at every step so that they’re clearly organized for reassembly.

However, the trickiest part by far was releasing the clips that hold the front bezel on to the main part of the chassis. Though the ifixit.com guide accurately describes what has to be done, it was really helpful for me to actually see a video of the process so I knew what the release was supposed to behave like and how the case came apart once released. This video from the Small Dog Electronics folks was really, really helpful – you probably want to check this out if you’re going to attempt this same repair (or upgrade, as the case may be):

Remember to fire up disk utility & partition your disk after completing the repair (during re-installation of Mac OS). The installer won’t recognized the uninitialized disk by itself – you have to partition it first, then resume the installation.

For those who sometimes follow the hackintosh scene, I thought I’d post an update that the upgrade to 10.6.5 via “Software Updates” went fine for me, without issue. (My hackintosh build is described in this post). There were some horror stories yesterday over at insanelymac. These sort of underscore the increased risk associated with all these non-vanilla build methods that have been around for a while. If you’re using a bunch of nonstandard kexts or (especially video) hardware that requires special tricks to get it to work, reliability seems really, really spotty. I’ve been pleasantly surprised with the reliability of my build so far – let’s hope it keeps up.

Oracle recently sued Google over alleged infringement of Java-related software patents as implemented in the Java-ish userland operating environment of Google’s Android OS. I haven’t read a good breakdown of the actual alleged violations, so I can’t speak to their merit. However, it’s not as though Oracle is some patent troll — they legitimately own the intellectual property associated with Java patents by virtue of their acquisition of Sun Microsystems, and they continue to develop Java technology. Shortly after this announcement, Oracle also announced that they will no longer develop Solaris (the commercial software) through Open Solaris (the open-source development project that has, heretofore, “run ahead” of Solaris). Instead, Solaris will be developed in-house by Oracle and its source will be released after, not before, a commercial release.

Since then, there’s been a steady stream of free-software enthusiast outrage. Over at zdnet, there has been (and I’m not joking) nearly one articleorblogpostperday, all decrying the evil that is Oracle. The crux of their complaining stems from their underlying assumption that software patents should not exist, and that a company cannot be “a friend of open source” and also defend its intellectual property via software patents. This is utterly ridiculous. Oracle’s lawsuit may be meritless (I don’t have the expertise on the exact allegations to say one way or the other), but they’re not evil for killing off a money-losing endeavor (Open Solaris — which was already almost exclusively developed by Sun/Oracle engineers or those working for them through partnership agreements) or claiming a stake in the multibillion dollar mobile OS market that is Android, and which may in fact be based on Oracle-patented technology. Being “open source” doesn’t necessarily mean “here, take everything for free, I disavow any claim to this.” That’s what the GPL hippies want “open source” to mean, but that’s not what it meant long before the GPL ever came around. And, I’ve got no problem with people wanting to develop “Free” (as the GPL hippies define it) software – cool beans for them. But, they’re crazy to demand that businesses license their software and their intellectual property according to their nutjob demands. (The GPL hippies aren’t exactly completely altruistic, either. Though they are bemoaning what they perceive as Oracle “changing the deal” with Java by coming back now and asserting intellectual property rights on something they believed was “Free”, they do the exact same thing if a company improperly appropriates GPL code in to a closed-source product: they “come back later” and demand that the terms of their intellectual property agreement — the GPL — be enforced). This latest bout of batshit insane demands from the corners of Free Software enthusiasts only reinforces my underlying belief that Free Software is mostly about one thing for its proponents: gimme gimme gimme.

I’m a big fan of Google Voice. Combined with Verizon Friends & Family, I get tons of free calling on my HTC Incredible. Also, the free SMS service (via my google voice number) using the google voice app is awesome.

That said, the voicemail-transcription service could use a little work… I found this one highly comical. My buddy Darren called me up to share what he’d heard on local sports-talk radio in Austin regarding UT moving to the Pac 10 (this was under consideration a few months ago – it wound up not happening). Apparently google voice seems to think people with a slightly Texan accent are talking about Japanese names. Similarly, google voice butchers the transcripts when my dad calls me, who also has a bit of a Texas accent. For whatever reason, though, my plumber with a Southie accent gets transcribed perfectly…

Anyone thinking Google is harvesting your voice calls for anything useful is insane. That, or Google is about to rat out Darren for having important information about Yukiko infecting Yuki.

Anyway, this is Darren’s voicemail:

This is what the transcript thought he said:

This is what Darren actually said:

Just heard on the radio, it’s mostly official. UT’s going to the Pac-10. UT, Oklahoma, Oklahoma State, Texas Tech. A&M has 72 hours to decide, but apparently the SEC is also courting A&M, and why they would want to go to either one of those, I have no idea. So, what the fuck. Anyway, I’ll talk to you later. I’m on my way to soccer. I won’t be done until 8:30 local. Talk to you later, bye

I find blog updates about most minor Mac OS updates to be mundane and unnecessary, but for those following the Mac-OS-on-generic-hardware scene, it’s useful to know how others with similar hardware fare with Mac OS updates. I used the software-updates method (rather than the “combo update” mechanism some seem to prefer — that’s useful in configs different than mine). There were no issues whatsoever.