I’m trying to get Windows XP SP2 running on my MBP using both Boot Camp (to be able to run Windows natively) and virtualized using VMware Fusion, but sharing the same Windows installation. This turns out to be complicated by Windows annoying product activation system. When run under Fusion, Windows sees different hardware than when running natively on Boot Camp, so it wants you to reactivate.
According to this thread in the VMware forums and page 8 of the Fusion Getting Started guide (PDF), the solution is to activate things in a particular order:
- Install Windows XP SP2 using Boot Camp
- Activate Windows under Boot Camp
- Install Fusion, picking the Boot Camp as the virtual machine
- Install the VMware Tools
- Reboot the virtual machine
- Activate Windows under Fusion
Now one should be able to run under Boot Camp or Fusion with no reactivation problems. I am about to try the Fusion side now.
Note for Vista users, Fusion 1.0 isn’t able to finesse the Windows activation issue (this is mentioned in the release notes).
Update: When I tried to activate in Fusion, Windows told me my license key had used up all its reactivations. So, I was forced to use their automated telephone system to activate, which was comically bureaucratic to Brazil proportions. You have to repeat 9 groups of 6 numbers [sic!!] to an automated attendant, which then tells you 6 groups of 6 numbers that you have to type in. It boggles my mind that Windows users put up with this kind of crap. Anyway, that finally worked, but then when I booted back into Windows via Boot Camp it needed reactivation. Luckily, I could do it via the Internet activation option this time, and now Windows seems happy in both Boot Camp and Fusion. bleargh.
Here is an interesting new image processing technique. The authors have created an algorithm for stretching and compacting images while maintaining the important parts of the image by subtracting (or adding) the least complicated parts. The video is quite cool, especially the part at the end where people are removed from an image!
The paper has more examples (though I haven’t read it all the way through). I have directed the links via CoralCDN because the home site in Israel was loading very slowly, at least from Hawaii.
I recently came across this information in an Apple PDF worksheet and couldn’t find anything via Google that really laid out the full situation, so I thought I would write this up for posterity.
In Mac OS X 10.4.x Server (and the client version I believe [and possibly earlier versions], by default your hostname is determined dynamically. This is controlled by the following line in the file
(note that in my Mac OS X 10.4.10 client this line is absent from
/etc/hostconfig so I assume that absence defaults to automatic as well). If you want to your hostname to be static, just change
-AUTOMATIC- to whatever fully qualified hostname you want like
When the hostname is determined automatically, the OS steps through this list of possibilities and goes with the first valid name found:
- The name provided by the DHCP or BootP server for the primary IP address
- The first name returned by a reverse DNS (address-to-name) query for the primary IP address
- The local hostname (set in the Sharing pane of System Preferences)
- The name
So this means if you get different IP addresses at home, work, and on the road you will see your hostname bounce around, which can be disconcerting if you aren’t expecting your shell prompt to change (wave to Philip :)).
Update: I changed the hostname of a Mac OS X 10.5 Server, but in certain places (such as the output of the
hostname command) I would still get the old hostname. Turns out that there is a preference file that didn’t get updated for some reason:
/Library/Preferences/SystemConfiguration/preferences.plist. I found a reference to the old hostname there, and after editing the file and rebooting, it appears that the last traces of the old hostname are gone.
Thanks to this post from this thread on maxosxhints.com for the pointer on how to fix this.
I wanted to install MacPorts on an Xserve using ssh. This involved doing two things I had never done from the shell: mounting a disk image and running an installer. Here are some quick instructions in case someone else needs to do this. It is assumed that you have already installed Apple’s X11 and the X11SDK per the MacPort install instructions.
- ssh to the Mac OS X system
- Download MacPorts
- Mount disk image
hdiutil attach MacPorts-1.5.0-10.4.dmg
- Run the installer
sudo installer -verbose -pkg /Volumes/MacPorts-1.5.0/MacPorts-1.5.0.pkg -target /
/opt/local/bin (and probably
/opt/local/sbin) to your path in whatever way your shell requires
- Update MacPorts to the latest version
- Unmount the disk image
hdiutil detach -verbose /dev/disk4
- The device was displayed when you mounted the image, if you forgot it then run