Why I bought a Mac (again)

While I use Linux for my day-to-day work, I have given in and purchased another Mac for my personal computing.

This new MacBook Pro is a beautiful piece of hardware. The old one was, too. After some shaky early adventures with conventional aluminium casings, Apple settled on their unibody design, in which the entire machine is carved from a single piece of metal. This makes it amazingly robust, and basically lets the entire body work as one big heatsink. As a result, the machine has a single fan, and hardly ever needs to run that. Now that there isn’t even a gently whirring hard disk, the silence is a little eerie.

The sound quality on the new Mac is nothing short of amazing. As far as I can tell, the sound is fired through channels from vents located at the screen hinge, and bounced off of the glass surface of the screen. The result is a good, wide stereo image and clear, deep bass.

My work machine is a Lenovo ThinkPad. ThinkPads are still widely renowned as the best build quality PC laptops you can get, but still, the contrast with the Mac is stark. The Lenovo creaks here and there, its fans are loud, it’s big and heavy, and parts of it are plastic. The sound quality is terrible, tinny and quiet.

Of course, a Lenovo laptop is a lot cheaper than an equivalent Mac. Apple’s machines are luxury items, and priced accordingly. But what I really want to talk about is the software. I was rather hoping that Linux would be good enough to replace OS X at this point. It certainly looked as if it might be, a couple of years ago; Ubuntu was making good progress, the KDE project had gotten KDE 4 stable and usable, there were new projects tackling traditional Linux shortcomings like lack of a good video editor, Valve were launching Steam to provide video games on Linux, and so on. And yet today, I feel as if we’re not really any closer to making Linux a good enough desktop environment, and in many ways the Linux ecosystem has regressed. As someone who uses Linux every working day, I think I’m in a good position to judge it fairly, and talk about a few of the areas where it just doesn’t stand up to OS X.

1. File management.

This week I cleaned up my files on my work machine. It was a truly horrible experience. While Dolphin is a passable file manager, it had decided to randomly lock up for minutes at a time. There was no particular pattern to what would make it lock up; I wasn’t asking it to browse a network drive, and even trivially small JPEGs sometimes triggered it. Google searches suggest that this is a fairly frequent complaint, going back years.

I considered using Konqueror, but combining a web browser with a file manager is a horrible idea. Nobody was crying out for file management in their web browser; Microsoft only did it so that they could weld Internet Explorer into Windows too tightly to allow its removal.

So, I installed Krusader. It did the job, but the two-pane UI was frustrating. I often found myself clicking the up arrow, only to find that the wrong pane moved up a directory. Dragging and dropping items into folders never felt reliable enough to trust it, a problem I also have with Dolphin.

Now, there are quite a few things that could be improved about the OS X Finder, but it’s so much better than anything I’ve found for Linux that I usually end up managing my Linux files from the command line, as the path of least frustration.

2. Sound

I know this particular dead horse has practically been flogged into paste at this point, but the state of sound on Linux is a disaster. Or rather, it’s several layers of disaster plastered on top of each other.

Sure, if you want to play some MP3s and hear some system beeps, stuff pretty much works these days. But when I say “sound”, I mean multiple streams of low-latency audio plus MIDI.

Once upon a time, there was OSS. It worked. However, the authors decided to try and make a proprietary version, which pissed off the free software community. So ALSA was created, to be a free replacement for OSS. By the time ALSA worked, OSS was back to being available for free, but it was too late — like that other license-politics-driven project known as GNOME, the monster was too far advanced to kill.

So, most Linux distributions had OSS and ALSA, supplied as ALSA with an OSS compatibility layer. However, ALSA didn’t allow multiple programs to make noise at once, so desktop environments needed a mixer to take the sound from multiple applications and combine it into a single stream. And obviously, each desktop built its own mixer. So you had aRts, ESD, or gstreamer, on top of ALSA or OSS. Any given piece of software would talk to some combination of those 5 APIs.

And then people realized that users would still want to be able to get sound out of applications built for GNOME even if they were running KDE, and vice versa. So another layer was built on top, called PulseAudio. PulseAudio supported all the previous APIs, and inserted itself in the middle so that all sound would get routed through it, no matter what API was used. So now software could talk to any of 6 APIs.

Next, people decided they wanted a standard multi-platform audio routing and mixing system, so JACK was built.

What this means is that given any particular piece of Linux audio software, you are faced with 7 possible APIs for audio, each with a different set of configuration parameters. For instance, Rosegarden is a popular Linux sequencer; take a look at the simple setup instructions and gaze in horror at the configuration dialogs. Now look at the corresponding dialog from Ableton Live on the Mac.

Which would you rather deal with? Yeah, me too.

And that’s assuming your MIDI interface just works and your sound card just works. There are driver issues too, but I’m not going to talk about those because they are largely the fault of the hardware manufacturers — whereas the disaster that is the Linux sound API battleground is solely the Linux community’s fault.

3. Video

Every now and again I make home videos for friends and family. Fifteen years ago, this was a fairly cutting edge pastime involving tapes, analog video signals, digitizers, DV files, and computers whose hard drives could barely keep up. Nowadays my needs are pretty simple; my camera spits out standard MPEG-4 H.264 files, so all I need to be able to do is chop them into pieces, rearrange the pieces, adjust the audio levels, and then render the result out into a new file I can upload to YouTube or turn into a DVD. I don’t even need 1080p, I’m happy with 720p for my trivial purposes.

There are two main video editing options in Linux, Openshot and kdenlive. (Cinelarra is far too complicated, avidemux is barely an editor, and Kino has been a dead project since 2009.) I took a handful of 720p MPEG-4 files and tried both options, and couldn’t manage to complete a 5 minute movie in either of them. For what it’s worth, kdenlive worked for longer before crashing.

4. Power management

Some time in the last year or so, the X.org driver’s screen brightness controls stopped working. I’m running nVidia’s proprietary driver, so there’s really no excuse, yet when the desktop tries to dim the screen, nothing happens. Sometimes when I reboot the machine, the screen will initially have zero brightness, and I have to rush to hammer the “brightness up” key combo a bunch of times before Linux takes over and the keys stop working.

If there’s a way to make the machine suspend properly when it’s left idle, I haven’t found it yet. Closing the lid suspends, but when I open the lid it’s really touch and go whether the machine starts back up where it left off, or just kinda sits there until I do a hard power off and on again.

Needless to say, the experience with my Mac is completely different. When I shut the lid, the machine instantly suspends, and when I open the lid, it instantly comes back to life. And here’s the amazing bit: while it’s asleep, as long as it’s plugged in, it will periodically wake up enough to handle housekeeping tasks like software updates, backups, downloading mail, and so on.

Now, I know that not all of this is Linux’s fault. Power management problems are frequently down to bugs in the manufacturer’s firmware, particularly the DSDT which is part of the ACPI firmware. The screen brightness stuff is probably nVidia’s fault. But regardless of whose fault it is, it results in daily annoyance when using Linux. I feel like I spend enough time dealing with that during working hours.

The success of Android, which after all is built on Linux, suggests that what Linux really needs is for a company to step in and fix the things that need to be fixed, regardless of how many people object. For a while it seemed like Canonical would be that company, but I feel like they’ve lost their way. They’ve been too eager to forget about the core issues and chase whatever trend is being talked up in the industry, from cloud storage to tablets to mobile phones. At the same time, they’ve wasted resources on projects nobody else wants, like Mir and Unity.

So, who will be the next Canonical?

Update 2014-04-22

I updated my work machine to Kubuntu 14.04 from Kubuntu 13.04. On reboot, the entire system was 640×480:


The GUI-based installer for the video drivers didn’t work, so I had to use command-line tools to install the missing drivers.

On the plus side, the screen brightness controls now work again.