cloudhead.io


Why OS X just doesn't cut it

April 18th 2011

Once upon a time, I did all my development in OS X. It was quite nice: I did my editing in TextMate and sometimes Xcode, I typed commands into Terminal.app, and most of the packages I needed had a nice .pkg file I could open. I was fairly happy with this setup.

With time, though, I started to look for ways to optimize my workflow further. Cut corners, automate—cause that’s what us hackers do. The first thing I did was to switch from TextMate to vim, it was really painful, but once I got through it, there was bliss. Then I started playing around with X11 and tiling window managers, like xmonad. After a while, I realized I was spending most of my time in the X11 app. How odd it was. But it had the advantage of letting me have a full-screen terminal, run vim without the limitations of Terminal.app (no I don’t like MacVim), and use xmonad instead of Aqua (See picture).

This was awkward at times though, and X11 was buggy on OS X. So finally, I decided to drop OS X all together, and install my favorite Linux distribution: Arch Linux. This is the best decision I’ve made for my workflow and productivity. I’ll try to explain why.

package, packages

Now why does this matter? It’s simple: to develop, we need tools, and to download and install these tools, we need a good package manager and a well maintained package repository. OS X comes with a lot of things pre-installed, but they are often out of date, so we need the ability to get new packages.

OS X has been gimped for a long time, when it comes to package management – we’ve gone through fink, the awful ports system, and now homebrew. All this to get a slice of the Unix pie. But none of these offer a complete package-management system like that offered by Arch Linux. Homebrew, the only sane choice not only has a tiny package repository, but has been pretty unreliable in my experience, when it comes to installing things with a lot of dependencies, such as Haskell or couchdb. This is not homebrew’s fault though: OS X is just unlike other *nixes (more on this later).

The other issue is that it has to download everything as source code, and compile it. Need a package right now? Nope—you have to wait for it and all its dependencies to compile on your lightning fast MacBook Air. This can be really annoying, some packages take a long time to compile. Arch Linux, on the other hand, has 64 bit binaries for everything. It literally takes less than 10 seconds from typing pacman -S ruby to having ruby-1.9.2 installed on your system. Want to upgrade every single package on your system? No problem. The pacman command can even upgrade your kernel on the fly. This is a big problem with OS X—it doesn’t come with package management built-in, so when you install something via homebrew, you end up with two versions, and there’s no way to just upgrade the packages that came pre-installed, unless you re-install everything with homebrew.

Many OS X users love it, and I don’t blame them, when you’ve had to deal with ports or (gasp) no package management at all for so long, homebrew is a breath of fresh air.

Homebrew’s beautiful ruby DSL will not save you.

darwin

When it comes to *nix systems, Darwin, Mac OS X’s naked body is one odd duck. Things which build & run cleanly on other *nixes won’t necessarily build & run that easily on Darwin. This is because it functions differently to other *nixes, and isn’t used much, outside of OS X, so a lot of *nix packages aren’t tested on it.

This will never be a problem on Linux. If I want to install some esoteric language run-time, I just know it’ll work, and you know why? Because it was fucking built for it, like all other system packages. Mac OS’s support for tools like valgrind is still in its infancy, for example.

The other annoyance is that unless you’re developing iOS apps, you’re not developing on your target platform.

workflow

The OS X terminal blows. If you haven’t realized, then maybe OS X is for you after all. But if you know what I’m talking about you’re probably using something like iTerm right now, and using MacVim or TextMate for your editing needs. Not only is Terminal.app not a full-color terminal, it can’t handle mouse events (yes, in X, I can re-size a vertical-split in vim with my mouse), can’t go full-screen, and isn’t very customizable. As a hacker, I like to optimize my workflow and customize my tools as much as I can. If I’m not in my editor, I’m probably in the terminal, so this is a big deal.

OS X isn’t very customizable either. Advanced settings are hidden in .plist files, managing daemons is a bitch, and you’re pretty much stuck with Aqua as your UI. Now don’t get me wrong, I would take Aqua over Gnome or KDE any day. But these interfaces are really not that great for programming, they are mouse-centric, cluttered, and force you to manually arrange your windows if you want to see more than one thing on the screen. When you’re in flow, reaching out for the mouse sucks. Ideally you’d want a window manager which was built for the keyboard, in the same way your editor was built for the keyboard, and so was your terminal. On Linux (X11), there’s a wide variety of these to chose from. I’ve settled for dwm after trying several of them out.

We’ve all played around with dotfiles, I have my very own set. But why stop there?

open source

Well, as a developer, having a fully open-source system is a win. I don’t think I need to further argue this subject—we all agree open-source is good.

closing thoughts

If everything I said went over your head, and you think I’m crazy, it just means your time hasn’t come yet.

I remember reading Salvatore Sanfilippo (the author of redis)’s thoughts on this matter two years ago, when I was still on OS X: http://antirez.com/post/linux-better-for-coding.html. It’s a good read, and covers some of the stuff I covered here.

Enjoyed the read? follow me on twitter, or subscribe to my feed.