Apple, for reasons known only to it, killed Rosetta — its PowerPC compatibility layer — starting with versions of Mac OS after 10.6.8. They also, for reasons that are similarly opaque but seem related to discontinuing Rosetta, make it intentionally difficult to virtualize non-server versions of OS X prior to 10.7.

My read on this is that it’s all part of the Great Apple Upgrade Treadmill, which is their process of intentionally making the entire Apple hardware/software ecosystem obsolete every few years, forcing everyone to buy new stuff. It sucks, and I hate it.

As a way around this, and because I have a fair bit of old hardware hanging around that’s dependent on software that will only run on PowerPC Macs (of which I don’t have any, anymore) or in Rosetta, I needed a way to run OS 10.6.8 in a virtual machine, while allowing my machine’s ‘bare metal’ OS to be upgraded.

It’s a bit of a challenge and not for the faint of heart, although it can be done.

Start state: Mac Pro running OS 10.6.8 (Snow Leopard), which is the last version of Mac OS that has Rosetta installed for compatibility with PowerPC applications. This is a capability we want to preserve.

End state: Mac Pro running OS 10.9 or later on the bare metal, with 10.6.8 running inside a VMWare Fusion container. Machine can also boot up directly into 10.6.8 on the bare metal, for full utilization of the hardware (games, 3D accel., etc.) if required.

Process:

1. The first step is simple: Install OS 10.9 to a separate hard drive, preserving the hard drive that has 10.6.8 on it. When I upgraded, I installed a new hard drive for the new OS, making this pretty easy (in general, if you replace boot drives at the same time as major OS upgrades, you won’t have to deal with failing boot volumes in your primary machine—a small expense for a lot of avoided pain).

2. Install VMWare Fusion 6.0.3. (That’s the version I used; other versions may also work but you’ll need some different hacks.)

3. Make sure VMWare Fusion isn’t running, and install/run the “VMWare Unlocker” from InsanelyMac.com. This is required to run a 10.6.8 non-Server guest. This is sort of the key to the process, and it patches your copy of VMWare to remove the asinine checks that Apple apparently mandated that VMWare put in to enforce their obsolesence-suicide-pact EULA.

4. Don’t update Fusion. If you do, you’ll have to re-install the Unlocker.

5. Open Fusion, create a new VM. (You can save the files wherever you want; it defaults to ~/Documents/Virtual Machines/ which I think is an obnoxious place to put them, but whatever.) Choose “Mac OS 10.6 Server (64 bit)” as the guest OS type. Or 32-bit, if you’re on a 32-bit machine or trying to boot a 32-bit guest image, although I haven’t tried this. Close the VM and quit Fusion.

6. Following the instructions here, determine the disk identifier of the hard drive containing 10.6.8. E.g. “disk2” or “disk0” or something similar. Make sure the 10.6.8 volume is unmounted!

7. From a terminal, run:

   /Applications/VMware\ Fusion.app/Contents/Library/vmware-rawdiskCreator \
   create /dev/disk1 fullDevice ~/external-hdd ide
   

   You will need to change the disk1 part as needed. Basically, what this does is it creates a VMDK file (external-hdd.vmdk) that points to the specified block device; it doesn’t actually copy any data over. I have it creating the vmdk file in the current user’s home directory, but you can put it wherever.

8. Locate the virtual machine file (in ~/Documents/Virtual Machines/ or wherever) that you created earlier in Fusion. Right click on it, do ‘Show Package Contents’, and move the external-hdd.vmdk file created with the last command into it.

9. Using a text editor, modify the .vmx file, also inside the package for the virtual machine, and add the following two lines onto the end:

   ide1:0.present = "TRUE"
   ide1:0.fileName = "external-hdd.vmdk"
   

   Note that this differs from the “techrem” instructions linked above; its procedure specifies the drive ID as ide1:1 which is bus 1, slave. That causes an error when I tried it in Fusion; it wants the drive to be bus 1, master instead. YMMV.

   Also, if you changed the name of the vmdk file created using vmware-rawdiskCreator to something besides external-hdd, then you need to change the name of the vmdk appropriately.

10. Now, you should be able to fire up Fusion and boot the VM. It will prompt you to authenticate as an administrator, saying that it needs privileges to access a Boot Camp volume (that is apparently what Fusion thinks the raw device vmdk is).

    The first time I booted, it took a long time to actually start up at a grey screen with the Apple logo, but then it did boot. Be patient. If you get a message saying that the “operating system is not supported and will now shut down”, or something to that effect, then it means the Unlocker modification didn’t take, and you need to retry that step (make sure the unlocker version you’re using supports the version of VMWare you’re trying to patch; they are pretty sensitive to particulars).

    As soon as you get booted up, you will probably want to change the virtual machine’s Machine Name (in System Settings, Sharing), and perhaps also the machine’s IP address if it’s statically configured. I set mine to Bridged networking and let my DHCP server sort it out.

At this point, you have a 10.9 machine, running 10.6.8 in a VM, giving you the ability to run PowerPC applications via Rosetta. It’ll be slower than molasses, but it does work, after a fashion. And because the VM references a physical drive that’s still installed in your computer, you also have the option of booting directly from that disk and running 10.6.8 on the bare metal.

Further Reading:

• http://fortysomethinggeek.blogspot.com/2013/03/convert-physical-mac-into-vm-guest.html This page shows a process for converting a physical Mac into a guest, but adds several intermediate steps including making a sparseimage using CCC, and then copying everything from the sparseimage to the VMDK virtual disk back again. This gets you a self-contained virtual machine file but is unnecessary if you are OK keeping the physical hard drive connected.

• http://serverfault.com/questions/223547/how-do-you-copy-a-physical-hard-drive-to-a-vmware-virtual-hard-disk Generic process for making a VMDK from a physical hard drive. This would be another way to a self-contained VMWare image, shorter than the process in the link above.

• http://techrem.blogspot.com/2012/12/add-physical-disk-to-vmware-fusion.html
  Adding a physical disk to VMWare Fusion. This is a key part of the process we use.

• http://www.insanelymac.com/forum/files/file/20-vmware-unlocker-for-os-x/ Homepage / discussion thread for the VMWare Fusion Mac “Unlocker” utility, which patches VMWare Fusion to disable the OS X guest version check. There is a similar utility available for Fusion 7, but I haven’t tested it.

Although I’ve mostly switched over to Linux on the majority of my computers, I have one remaining Mac OS X machine for stuff like photo/video editing, running Quicken and TurboTax, interfacing with odd bits of hardware (label printers, film scanners, etc.) and other stuff that’s just obnoxiously fiddly on Linux.

The machine runs 10.9.5 and doesn’t typically cause me much trouble. However, in the last week or so I’ve noticed that it keeps waking up from sleep in the middle of the night every few minutes, sometimes for hours at a time, but then sometimes sleeping peacefully for long periods as well.

The culprit, according to the system logs, is apparently a Dymo LabelWriter printer connected via USB.

12/29/14 9:29:52.000 AM kernel[0]: The USB device HubDevice (Port 3 of Hub at 0xfd000000) 
 may have caused a wake by issuing a remote wakeup (2)
12/29/14 9:29:52.000 AM kernel[0]: The USB device HubDevice (Port 4 of Hub at 0xfd300000)
 may have caused a wake by issuing a remote wakeup (3)
12/29/14 9:29:52.000 AM kernel[0]: The USB device DYMO LabelWriter 330 (Port 4 of Hub at 0xfd340000)
 may have caused a wake by issuing a remote wakeup (3)
12/29/14 9:31:28.000 AM kernel[0]: The USB device HubDevice (Port 3 of Hub at 0xfd000000)
 may have caused a wake by issuing a remote wakeup (2)
12/29/14 9:31:28.000 AM kernel[0]: The USB device HubDevice (Port 4 of Hub at 0xfd300000)
 may have caused a wake by issuing a remote wakeup (3)
12/29/14 9:31:28.000 AM kernel[0]: The USB device DYMO LabelWriter 330 (Port 4 of Hub at 0xfd340000)
 may have caused a wake by issuing a remote wakeup (3)
[Repeat several hundred times]

Unfortunately, aside from just unplugging the offending device every night, there doesn’t seem to be a good solution to this problem. Apple’s tech support forums are filled with similar tales of woe, stemming from all sorts of USB devices. There’s no way—at least, not that it would seem—to control which devices are allowed to wake the system and which aren’t.

Even worse, there doesn’t even seem to be a way of disabling USB wake altogether, and just using the front-panel power button to wake the system, which would be a viable if drastic solution. Reaching down to hit the power button isn’t much of a hardship, and is analogous to the way I have most Linux-based laptops set up anyway (wake on power button, not on keyboard/mouse). But Apple thinks they know better and doesn’t allow it.

This, to be honest, just sucks. Apple seems content to blame USB peripheral manufacturers for “not understanding Mac sleep”, as one forum poster put it, rather than just making their systems less oversensitive, or more configurable. Those obscure bits of hardware are the only reason I still have a Mac, so ditching them isn’t much of a solution.

I guess perhaps it’s what I deserve for buying a computer from a consumer-electronics company, but still, disappointing.

An apparently common issue with Outlook for Mac 2011 is crazily high CPU usage, enough to spin up the fans on a desktop machine or drain the battery on a laptop, when Outlook really shouldn’t be doing anything.

If you do some Googling, you’ll find a lot of people complaining and almost as many recommended solutions. Updating to a version after 14.2 is a typical suggestion, as is deleting and rebuilding your mail accounts (ugh, no thanks).

Keeping Outlook up to date isn’t a bad idea, but the problem still persisted with the latest version as of today (14.4.3).

In my case, the high CPU usage had something to do with my Gmail IMAP account, which is accessed from Outlook alongside my Exchange mailbox. Disabling the Gmail account stopped the stupid CPU usage, but that’s not really a solution.

What did work was using the Progress window to see what Outlook was up to whenever the CPU pegged. As it turned out, there was a particular IMAP folder — the ‘Starred’ folder, used by both Gmail and Outlook for starred and flagged messages, respectively — which was being constantly refreshed by Outlook. It would upload all the messages in the folder to Gmail, then quiesce for a second, then do it over again. Over and over.

Outlook’s IMAP implementation is just generally bad, and this seems to happen occasionally without warning. But the Outlook engineers seem to have anticipated it, because if you right-click on an IMAP folder, there’s a helpful option called “Repair Folder”. If you use it on the offending folder, it will replace the contents of the local IMAP store with the server’s version, and break the infinite-refresh cycle.

So, long story short; if you have high-CPU issues with Outlook Mac, try the following:

1. Update Outlook using the built-in update functionality. See if that fixes the issue.
2. Use the Progress window to see what Outlook is doing at times when the CPU usage is high. Is it refreshing an IMAP folder?
3. If so, use the Repair Folder option on that IMAP folder, but be aware that any local changes you’ve made will be lost.

And, of course, lobby your friendly local IT department to use something that sucks less than Exchange.