Archives filed under "OS X"

Like a lot of other designers & developers, I run Mac OS X & Rails—with all the dependencies that implies. In the past, I’ve been burned by OS X upgrade incompatibilities (upgrading to 10.7 was particularly painful in fact), so now I’m not as keen to upgrade to the latest & greatest as soon as it comes out.

Which brings me to 10.8, or “Mountain Lion”. I installed this on my laptop & it throughly munged the system. What’s worse, with the move & redesign, I had little time to fix it: so it remained seriously broken until about a month or two ago. This article helped the situation greatly.

However, when I finally got around to installing Mountain Lion on the laptop, using the notes above, of course the damned thing failed, but in a new and interesting(?) way. I had upgraded the system, reinstalled XCode & its command-line tools, and went to install rvm:

rvm reinstall 1.8.7 --without-tcl --without-tk

But I received the error:

ERROR: The autodetected CC(/usr/bin/gcc-4.2) is LLVM based, it is not yet fully supported by ruby and gems, please read `rvm requirements`, and set CC=/path/to/gcc .

So I looked at “rvm requirements”. It suggested I run rvm install 1.8.7, but this caused the same error message. Rooting around, I saw mention of “rvm notes”, which suggested that I run rvm get head && rvm reinstall 1.8.7. That did it!

After that I went into every local copy of Rails apps to trigger acknowledgement of the new rvm setup, and to re-trigger bundling in order to sort out all local gems. All sorted!

I also deal with a few PHP apps. It turns out that the httpd.conf files no longer enable PHP, and that you need to do so. Find the httpd.conf file in /etc/apache2/ & uncomment LoadModule php5_module libexec/apache2/libphp5.so (line 116 in my version of the conf). In addition, scroll down to configure the features for /Library/WebServer/Documents & edit for the following (line 209):

  
  <Directory />
      Options FollowSymLinks
      AllowOverride None
      Order deny,allow
      Deny from all
  </Directory>

Finally, under DirectoryIndex, ensure you add index.php (line 231), so that php files will be served. Restart Apache (sudo apachectl restart) Sorted! Many thanks to this article which helped with the PHP side of things.

I’ve written before about slimming Time Machine backups. Without careful pruning of the system, developers can find that their Time Machine backups become huge. For instance, if you’re developing Rails apps, you’ll likely want to not back up your logs directories. And everyone will probably want to exclude up their Cache directories, which of course are scattered throughout the system: I’ve counted /Library/Caches/, /System/Library/Caches/, and ~/Library/Caches/; and this doesn’t cover specialised caches you can find in */Library/Application Support/, for instance, for Flash. Remember this location, and note the asterisk: these become important later.

Well, since I’ve slimmed my Time Machine backups, I’ve noticed the occasional baffling 450MB or so backup in the morning, and periodically throughout the day. I couldn’t figure out what it was—remember, Apple doesn’t let you know what you’re backing up—and I was really worried that someone had broken into my machine and was using it to relay something really unsavoury.

Enter Time Tracker by Charlesoft, the author of Pacifist (I’ve since discovered BackupLoupe, which does much the same thing). Time Tracker is a very basic app that lets you view what, specifically, has been backed up, and how big it is. It’s a big help, and it helped me identify the culprit: Roxio’s Retrospect, which I use to create monthly backups of my work.

It turns out that even if you aren’t using it to back up your entire system, Retrospect creates a huge tally of your work. It’s located in /Library/Application Support/Retrospect/ and for me at least the files there tally usually in the region of 400–600MB in size. Which is backed up periodically throughout the day by Time Machine. Yes, the backups are backing up the backups. It’s backups all the way down, people.

I’ve never actually seen his show, but I giggle at the recursion jokes every time.

So, uh, if you’re paranoid like me & use Retrospect for monthly backups (because, you know, hourly backups aren’t enough), then you’ll want to exclude this from your backups. Since then, my backups are a lot saner in size, and my backup drive is no longer filling up with alarming speed.

If, like me, you had font problems after applying Apple’s Mac OS X 10.6.8 Update, there’s a simple solution: delete the font cache. You can easily delete the font cache by using the free tool OnyX—which also does much else besides.

For me, the issue became clear when I went to look at a job in Adobe Illustrator. Opening the file should have triggered Extensis Suitcase Fusion to load a particular font, but it didn’t. In fact, none of my fonts could be previewed in Fusion: instead was a note stating “Font Unavailable”. Once I deleted the font cache & restarted, everything was fine.

Wow! It’s been quiet here. That’s for a lot of reasons, but partly because a) I’ve been getting over a long-term illness that had really had an effect on my work (which is now gone, thankfully) and b) my Mac suffered a nasty failure. It experienced weird symptoms, which were fixed when the graphics card & RAM riser boards were replaced. Good thing I got AppleCare for the machine.

In any event, while the machine was in the process of breaking, I realised that my local development databases weren’t backed up. Why? Because Apple’s Time Machine would want to back up hulking single-file monstrosities every time you modified it slightly. In my haste (and panic), I made an imperfect backup. When the databases were restored onto the machine, they wouldn’t work. I could see that they were there, the databases were listed, but attempts to access them inevitably resulted in failure.

It turns out to have been a permissions issue (Errno 13 in MySQLspeak: I now know that gzipped tarballs won’t preserve permissions). It took some hunting to get to the root of the problem, but if anyone else experiences this problem, the answer is that the MySQL data directory is likely to be owned by root, when it needs to be owned by MySQL. In my example, I’m assuming that the data directory is the one specified in a MacPorts installation:

  
    sudo chown -R mysql:mysql /opt/local/var/db/mysql5
  

Restart your MySQL server, and everything should work!

Apple’s latest release of OS X is version 10.6, or “Snow Leopard”. For most users, upgrading isn’t a worry: you upgrade, and everything just works. Developers, however, will find that upgrading is more haphazard, as the environment has switched from 32-bit to 64-bit. Plus, you have to find enough downtime in which to upgrade & deal with any issues that arise. For me, that downtime finally occurred over the Christmas/New Year’s holiday period. In a hazy, and admittedly alcohol-induced moment, I rashly decided to install 10.6 around midnight a couple of days ago, forgetting that I hadn’t fully thought out what to do with all the Rails apps I had on my machine.

So here are some notes for when/if you want to take the plunge to 10.6 (which I recommend that you do). Matt Aimonetti’s August 2009 article on the Riding Rails blog contains very good general information. What I took away from it is that Snow Leopard requires 64-bit versions of your Unixy software: remaining 32-bit isn’t an option, as I’d hoped (from a position of laziness, that is, prone). So you’ll need to recompile not just all your MacPorts goodies, but of equal importance, all your gems.

Matt suggests that upgrading ain’t that bad. In my experience: lies, all lies. Virtually nothing he or the commenters suggested worked for me, so like some crazed frontiersman, I had to forge my own path. I blew everything away & started afresh. Here’s what I did:

• Before anything: export your databases (or at least have their contents close to hand in some fashion);
• Start your MacPorts dance, installing/upgrading to the latest MacPorts & then installing all the software you need;
• I had a lot of trouble updating MySQL. The tips in this article did me a real treat when nothing else worked;
• A little titbit of info: apparently you can have problems with the MySQL gem, as apparently it wants to compile as 32-bit. You’ll have to force it to compile as 64-bit:
  sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-include=/opt/local/include/mysql5 --with-mysql-lib=/opt/local/lib/mysql5 --with-mysql-config=/opt/local/lib/mysql5/bin/mysql_config
• Re-create your databases & use your db exports to populate them;
• For Rails apps that have gems in vendor/gems (thanks to Ian for this), you’ll need to recompile them for 64-bit:
  rm -rf vendor/gems/* ; sudo rake gems:install ; rake gems:unpack ; rake gems:build
• For Rails apps that don’t have gems in vendor/gems (boo! hiss!), the situation is more hit & miss. The easiest option is to just install new versions of all your old gems. However, I wanted to take this as an opportunity to prune through the thicket, hence my slight pain. If you follow my lead here, just try to run your app & see what gem is missing: then install it.

The end result: when the sites popped up, I was stunned by how quickly they appeared. In addition, the whole compiling MacPorts apps was shockingly quick.