Qt 5.2 on Mac OS X

I had mixed experiences trying to install Qt 5.2 on two different Macs (both running the same version of OS X): on my personal computer the install went on with no trouble.  I ran an update using Qt's maintenance tool app, and then the package manager in the same app to select the bits of Qt 5.2 I wanted to install; my work computer, on the other hand, game me a lot of trouble. So, for future reference, here's how I got it working.

Problem 1 – Update did not complete

The update process was failing with an error pertaining to the system not being able to save the Updates.xml file due to it already existing. As far as I could determine, the update app creates a temporary directory for each repository—at /var/folders/rb/[random string]/T/remoterpo[some ref. code]meta/—and saves Update.xml file in there, before listing all the available updates. Due to either a bug in the maintenance app or an incorrect update package, one of the repositories was causing this error.

Solution

On the maintenance app's main window, select Update Components, then Settings, then Repositories, and turn everything off except for one, the Maintenance Tool online repos.  Run the update, and that should complete with an updated maintenance app. Then re-run the update process with all repositories selected, and it should go to completion. After this point you should be able to restart the app, select Package manager, and the Qt 5.2 packages should show. That leads into the next problem I encountered.

Problem 2 – Installation fails

The installation process either via the maintenance tool or using the installers from the Qt website fails some time midway with the message "Command install_name_tool failed," followed by a list of arguments to the command.

Solution

If you search the web for solutions you will certainly bump into posts asking "Have you updated Xcode?".  Well, I had. But there's more to it. On my work computer I had to install the Xcode Command Line Tools, which can be found in the Xcode preferences, under Downloads. Once I completed this step, the install worked fine. Strangely, this step was not required in my home computer (same OS X version): I just checked, Xcode Command Line Tools are not installed. Go figure.

Coming Home

Coming Home, a set on Flickr.

Took possession of our little racer. First thing we did was give it a good wash, and then we brought her in the garage to check out the state of the brake lines. Both rear lines are rusted through.

Volume Image Transfers in OS X

I've been frequently faced with the need to copy an image (usually a CD iso from some sort of installer) into a thumb drive, mostly due to the fact that I have a few machines that don't have a disk reader at all.  Yet this doesn't happen frequently enough that I actually remember all the steps, so every time I have to search and find this info again, which is not very efficient.  Hence this short note to myself here, where it might end up being useful to others as well.

In this case I want to copy a recently downloaded copy of a Linux installer .iso image to a USB thumb drive, so I can install it in a laptop.  We'll use the terminal in OS X, and the command line tools dd and diskutil. The symbol ">" indicates the command line prompt in my system.

From the command line:

> diskutil list

This will list all available volumes in the system, by device.  A typical output might look like this:

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            899.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                100.3 GB   disk0s4
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 GB     disk2
   1:                 DOS_FAT_16 DISK_IMG                1.0 GB     disk2s1

In our scenario, disk1 is the device that will host the image.  In order to access the disk directly for a low level copy—i.e., we're not copying the iso file here, we're loading that image into the device itself, so we can actually boot from it—we'll need to unmount it first.

> diskutil unmountDisk /dev/disk1
Unmount of all volumes on disk1 was successful

The above succeeds whether the volume had been mounted or not.  Next, we copy the disk image to the thumb drive using dd.

> dd if=/Users/beto/Downloads/ubuntu-12.04-desktop-amd64.iso of=/dev/rdisk1 bs=1m

The parameter "if" indicates the input file, "of" the output file (in this case a device), and "bs" the block size at the destination.  Notice I used "rdisk1" instead of "disk1".  In OS X, the rdisk device is the "raw" device, which can be accessed without buffering or alignment checks.  That removes I/O overhead from the process, making it orders of magnitude faster than if you were to use the buffered device.  Obviously, if in this case points to the iso file I am copying in my scenario.  This could also be another device, say if you were making an image backup of a disk.

The results of the copy above are:

698+1 records in
698+1 records out
732213248 bytes transferred in 237.283433 secs (3085817 bytes/sec)

As soon as the process finishes OS X will attempt to mount the new volume.  If the image's file system is not supported OS X will balk at this, showing a warning dialog complaining that the disk is not readable, and showing the actions "Initialize...", "Ignore", and "Eject".  Simply select Eject, and you're done.  Another option is:

> diskutil eject /dev/disk1

Subaru BRZ/Scion FR-S

This is looking very interesting.  2600 lbs, 200 hp at 7,000 RPM. That's better weight/power than a Miata.  RWD, with lim. slip diff standard. 151 lb-ft—could have used a bit more torque, but that's ok. Subaru starting at $24K.  Scion will sell the same package under the name FR-S, for probably a couple grand less.  My car buying experiences in the past few years tell me that the best bang/buck would be to get the bottom-cheapest version available (since all have the same drive train) and improve on that.

Article on the Subaru BRZ.

Article on the Scion FR-S.

White Clay Creek Park - July 2011

We go for a stroll on a hot July 4th weekend.

White Clay Creek Park - July 2011

PS3 YLOD Woes

Yesterday my trusty fat PS3 decided to have a stroke. It simply shut itself down without warning and entered Yellow Light of Death (YLOD) mode, where cycling the PS3 on starts it up, flashes the power LED yellow once after a couple of seconds, then starts blinking it red and refuses to continue, no matter how many times you retry.

The problem seems to be caused by the soldering under the CPU and GPU chips cracking, after thousands of heat/cool cycles during the life of the PS3 (mine is close to four years old). Fortunately, there is a fix for it, which requires disassembling the device completely and applying heat to the GPU and CPU areas, in an effort to reflux the soldering under the chips.

After some research I found this video by youtube user djwhetzel that does an excellent job walking through the disassembling, fixing, and reassembly of the PS3.

PS3 motherboard.

After following the steps in the three-part video I was able to get the PS3 working again. The fix is not exactly difficult. Breaking apart and getting the PS3 back together was a fairly straight-forward process, especially with the video's guidance. It's mostly a matter of having proper sized screw drivers (I used four different-sized phillips heads and a torx) and cleaning and reapplying thermal compound on the main chips.

Applying heat was a bit unnerving because of the potential for permanent damage. I actually went through this step twice, after I wasn't very convinced I had applied enough heat the first go round. I used a shop heat gun with 570/1100 F heat settings to complete this step.

The good news is that the PS3 came back online like a champ. The bad news is that this fix is usually not permanent and seems to last only for two or three months. Now that I've done it once I could probably repeat the process from top to bottom in less than an hour, but the sad truth is that my beloved PS3 is on its way out... At least I got a chance to back up all my data until I have to buy a new one, but I really like the old fat models: it looks better (IMHO) and has features there are missing in the new slim PS3s (more USB ports, more card readers, and mostly importantly, the ability to play PS2 games).

Salton Sea

I found this well-made YouTube video about California's Salton Sea, a man-made body of water somewhere southwest of the Mojave Desert. A very interesting place, we've been there with friends in one of our off-road trips. One of the things that struck me from this video was the notion of "what things would look like without us", and how eery do places look when humans abandon them. I didn't get that feeling so strongly when I was visiting it, probably because we could only spend a couple of hours near sunset and we were not looking forward to being there after dark; and then we spent a good bit of that time getting one of our companions unstuck off the "fish-bone" mud.

This is a selection of pictures from that 2009 trip, with our short visit to the place.

The fish-bone "sand".

The worst type of mud I've seen.