The Unconventional Mac

 

Wednesday morning I was expecting to get in my next paycheck as well as some extra from cashed company stocks. The company I work for, like so many in the tech field lately, went from public to private. This resulted in all my remaining shares being cashed out in two payments. I was expecting the last of those this morning. I already had a number in mind, and planned out my finances accordingly. When I checked my bank account, however, I found I had twice the amount I expected. After being distracted by it all day, I decided to do something completely out of character: Over my lunch break I drove to my local Microcenter and bought a Mac.

Now for something completely different...

I outlined my reasons for buying a MacBook Air in my last New Laptop Game post. I felt that as an IT educator looking to break into the Drupal market, Mac knowledge was essential. Furthermore, I wanted to challenge myself by stepping out of my comfort zone. Yet, I still wanted something that could run Linux so I could continue to use the operating system I've come to love (and be aggravated by) so much. This kept me from buying until this unexpected windfall occurred. While I could put the money toward some bills, the desire for a new system countermanded the idea. After browsing Microcenter's website, I found a MacBook Air 2013 listed as an open box. That is, an otherwise complete system that was recently purchased and then returned. While the base price was still a lot, it had the right specs: 4GB of memory, the latest Hazwell architecture from Intel, and a 256GB SSD. I wanted an 11" screen rather than the 13" so as to make carrying two laptops -- one for work, and one for myself -- as painless as possible. 

The buying experience was already decidedly un-Apple like, much to my glee. Microcenter is far from the J.J. Abrams-esque lens flare of an Apple store. The box was indeed opened, taped shut, opened again, stickers applied and removed. While completing the purchase I chatted with the cashier. He told me a story about how someone demanded $300 off because his new MacBook was missing the protective plastic film over the LCD. I theorized with him that the system was returned because the previous owner wanted the 13" and bought this one by mistake. I did a quick check of the machine, the boxes contents, and swiped my debit card. 

Setup and web development woes

I didn't have much opportunity to play with the new system for the rest of the afternoon. I had work to finish, a call with the instructor for one of my classes. I did boot it up, run through the initial set up process, but little more. Once work was over, I invited over a friend and began to customize the system. I installed Mavericks. Finally, I started to get a Drupal development environment set up. This turned out to be much more difficult than it should have been. 

While I could have installed MAMP or even Acquia Dev Desktop and had a functional system online in short order. I've used Dev Desktop on Windows, and I understood it's caveats. It wouldn't run on the default port, the directory structure is weird, and the included version of Drupal included Acquia-specific extensions. None of those problems compare to my detest of MAMP. I spent more than a few hours trying to fix MAMP environments of a few local Mac using Drupalistas. The config files are downright confusing with duplicates and multiple versions everywhere. The free version appears to intentionally make things difficult so as to encourage you to buy the paid version of the product. I find this dishonest given that MAMP is essentially an installer for free, legal, and open source software (MySQL, PHP, Apache HTTPD). No. There's got to be a better way.

After Googling around, I found that you can install an entire *AMP stack using MacPorts. Given the large number of packages that MacPorts supported, it seemed a natural fit. Over the next 24 hours I fought with the system to get the web server online, PHP installed, MySQL up and running. It was pain, pain, pain, plus lots of waiting due to lengthy compile times. At the end of it, I managed to get everything except the GD graphics library for PHP installed. Without GD, Drupal 8 wouldn't install. 

Making Mac OS X palatable to the spoiled Linux user

One thing I'm spoiled about on Linux is package managers. Long before "App Stores" were popular, Debian had a networked package manager that would automatically calculate dependencies, download them, and install them with one simple command. This was back in 2002 (sorry, Mac fans, Apple didn't invent that). There was even a GUI, although more utilitarian compared to Apple's, Google's, or Microsoft's. My preferred distribution of Arch Linux has a wonderful two-tier package manager. For core OS components and applications, there's the default pacman package manager. It's as easy as Debian's apt-get. For unstable, unusual, and user-contributed packages there is the Arch User Repository, or AUR. AUR has no de facto manager, but several scripts and wrappers. My favorite, yaourt, allows you to install AUR and core packages without needing to invoke pacman directly. I've contributed to AUR myself, with the drush-git package.

While Macs have the Mac App Store, the selection is almost laughable for my purposes. I've resorted to downloading and installing *.dmg image files for many essential applications such as Firefox and Chrome. This makes the Mac experience for installing apps no better than Windows 7. Downloading separate packages in this way increases the administration footprint of the system as each program needs to be updated manually. For those applications with their own built-in update mechanisms, it increases the resource use and code size in what should otherwise be a function of the OS. 

MacPorts feels very much like something conceived of during a time when CVS and Subversion were the primary code sharing mechanisms. MacPorts is centralized with a single, canonical sort of ports. Everything is source-based, requiring lengthy compellation times. It feels a lot like emerge, the package manager of the Gentoo Linux distribution. I cut my teeth on Gentoo years ago when I was first getting into Linux. I learned a lot from the experience, but chief among them was that compiling absolutely every package you install is simply not worth my time. Arch's pacman, however, is largely binary based. Some packages are compiled where necessary. Install times are shorter, and the demands on the system maintainer are far easier.

After turning to Twitter, someone suggested I use Homebrew. Homebrew, or "brew" for short after it's primary command, is very much like MacPorts but for the GitHub age. Written in Ruby, brew relies largely on binary packages downloaded from Github. In some instances, source is downloaded and complied. User contribution is also built-in: The "tap" subcommand allows you to add a new app repository to Homebrew. The beer-centric humor of the package manager adds to the appeal. 

In contrast to MacPorts, installing PHP and MariaDB (a compatible fork of MySQL) with Homebrew was a breeze. In about an hour, I had a functional virtual server configuration on my system. I blew away all my hard work with MacPorts and removed it completely from my system. GD did, once again, become a sticking point. Some quick research led me to the Github issue queue for homebrew/PHP. It suggested I needed to downgrade to the previous version of Freetype and provided a few quick commands to accomplish the task. How you troubleshoot the package manager of a system tells you a lot about the quality of the community around that system. Arch's forums and Wiki provide a wealth of troubleshooting information. Drupal's issue queues and IRC channels are a lifesaver. With Homebrew, it's all about Github issue queues. Homebrew makes OS X palatable. 

Seven of Nine: "Your system is flawed, I'm implementing a new one."

But is has to run Linux

Of course, I couldn't leave the system be for long. It had to run Linux at some point. There are just too many odd things about Mac OS X that I cannot fix or modify. While I could have started with Arch, I decided to "put on the training wheels" and start with Ubuntu. The logic is, if it runs Ubuntu, it should run Arch decently. While I could, theoretically blow away OS X completely, I love having my systems dual-booted. After all, if one system fails, the other still works. 

Like any modern Windows 7 system, dual booting Mac OS X starts within it's native operating system. In Disk Utility, shrink the main partition to free up space on which to install Linux. While I've run Arch in as little as 20GB, I decided to allow for 50GB in this case. This left about 200GB for Mac OS X, or a future shared file partition. I downloaded the latest version of the Ubuntu ISO and followed the online instructions to burn it to a USB drive. After all, the Air has no optical drive, nor have I used a CD to install an OS in years. 

Booting into Linux on the Mac is actually remarkably easy. Unlike many of the newest Windows 8 systems, Macs have been using UEFI for years now. There's no need to reconfigure the hardware to boot into "Legacy BIOS" mode. Simply plug in the USB drive, reboot the system, and hold down the alt/Option key. A selection dialog appears. Choose the USB drive and off you go. Ubuntu booted quickly and painlessly. The only thing that didn't function during my Live CD session was the wireless. While I installed the driver easily enough, it failed to associate with any access point. Experience suggested that this was due to this being a Live CD session rather than a hard-installed OS. Many Live CDs use a ramdisk configuration that makes installing and enabling drivers wonky. Despite this fact, my confidence was high enough to install the OS for real.

I rebooted into the USB stick, and proceeded directly to installation. This time, the wireless driver came up and associated without problem. Everything went well, and I couldn't stop giggling that I was doing something "wrong" by installing Linux on a Mac. When I rebooted, I ran into my first problem.

Bootloader, bootloader, where for art thou?

I had assumed that after installing Linux, either the default Apple bootloader would have been replaced. This is what I expect on legacy BIOS systems as the default Windows bootloader is "chainloaded" after the Linux bootloader GRUB. This was not the case. The Air rebooted into Mac OS X without even commenting on what I had just done to it. Scratching my head, I rebooted and held down the alt/Option key thinking that I just needed to select it. Nothing. Only the Mac and Recovery partitions appeared. 

Again, the problem is UEFI. UEFI allows for much more complicated bootloaders than BIOS. They are almost small operating systems in their own right. Apple's default bootloader wouldn't recognize anything that wasn't either Mac or Windows. I had neglected to use Bootcamp to create a Windows partition. Since the drive was already partitioned, I couldn't use Bootcamp to do so now. I either needed to blow away my Linux install, or try something else. 

Despite the fact I was installing Ubuntu, the Arch wiki came to my rescue. The rEFINd bootloader is an open source project that replaces the Apple bootloader. It detects the available systems and provides a select list on start. It's not as pretty as Apple's, but it certainly works. After installing, I was able to finally get into my Linux installation.

Running Ubuntu 13.10 on the 2013 Macbook Air

To my surprise, I lucked out when I bought the system. My Air is one version removed from the newest -- MacbookAir(6,1), versus (6,2) -- which caused many Mac owning Linux users so much trouble. After playing with the system for a short while, everything appeared to work. I was even able to mount the Mac drive with no difficulty. Many of the problems reported in blog posts and issue queues have been resolved for (6,1) in the last few months. 

The only thing that doesn't work well is the bane of many a Linux laptop. Suspend/resume has a problematic history on Linux. For many years it worked only on a minority of hardware, and then only occasionally. The shift away from desktops to laptops have encouraged a lot of work in this area. Many systems suspend and resume on Linux well now. The Air, however, doesn't.

The first problem is that the monitor will go dark shortly after resume. For a while I assumed that it was completely dark. After moving to my better lit kitchen, however, I discovered that the problem wasn't that the screen was black, it was that the LED backlight was off. The brightness keys were useless, or so I thought. After hacking away with scripts and reading device info from /sys/class, I mashed the brightness key in frustration and discovered the backlight came on! Apparently, the problem is that anything lower than brightness level 2337 (about 75% of max) is coded as "off" post-resume. 

I also discovered that the speakers no longer worked post-resume. This is similar to errors reported to others on (6,2). I'm hoping that future driver updates will resolve the problems. Arch may be further along than Ubuntu in that way given the community is much more technical and updates are bleeding edge. For now, I'll just need to put up with the problems, or shutdown instead of suspend. 

Summary

Technically, I have the better part of a month to decide if I'm going to keep the MacBook Air. I'm enjoying the experience so far, warts included. The feel of the hardware is amazing, and the battery life is excellent even on Linux. Given that this is the first laptop I've bought in cash, I'm not inclined to return it. 

The only problem? I haven't come up with a name for it. Usually I name my systems after an anime character, but nothing is coming to mind (yet).