Archives filed under "os x"

In its recent Worldwide Developer Conference, Apple has announced that we’ll soon be able to write extensions to expand the capabilities of iOS in hitherto-unexpected ways.

I’m not an iOS developer, but this news hit me like a kettlebell to the nose. My memory extends (ha, ha) back to the days when Apple created such a system for Mac OS 7. The system was, indeed, extended in ways well beyond its original intentions. And it became spectacularly crash-prone as a result. (Even OS X is not immune to it: it’s worth searching “kext conflicts.”) These days, when I work on Rails sites, the development problems I encounter are without fail due to gems, the Rails equivalent of an extension. I’ve lost whole days trying to figure out which extension caused sites to fall flat on their faces & why.

So, why should my trepidation extend (ha, ha!) to Apple’s latest effort to enhance its OS? After all, today’s Apple is a very different one from the one that created Mac OS 7: they keep closer tabs on everything. By its very definition, opening up a system to accommodate unforeseen needs means that they open up the platform to unforeseen problems, bugs, and—and here’s the terrible word that brings back OS 7-era shudders—conflicts. Developers will take shortcuts (as developers will) and their extensions will be poorly tested and incompatible with other extensions—to say nothing of exposing users to security problems. Apple will play constant catch-up in its developer documentation.

It opens up the platform to chaos. It leaves the job of untangling the problem to the end-user, tearing her hair out trying to figure out which extension is causing her phone to go bonkers.

I don’t normally like to steal the words of fascists, but whenever I hear the word ‘extension’, I reach for my gun.

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.

When starting up Photoshop today I received an error:

Could Not Initialize Photoshop Because the Disk Is Not Available

And then I was told that, specifically, my scratch disk wasn’t available. Huh? I have four of them! They’re right there!

It was all very peculiar, because I haven’t changed anything about my computer in the past several months. Other than to update to Adobe’s newest version of Camera RAW. I can’t say that this caused some problems, but I searched for the error message. Several people suggested checking out the scratch disk’s permissions.

Whilst doing that, I tried a little repair tip that’s useful for a lot of applications: I started up the app with the Command + Option keys held down. Voilà! I was asked to pick my scratch disks, and everything is sorted.

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.