Scribble Nearly Anywhere. Sort of.

I watched WWDC this year, and as with most years, didn’t really care about most of what I saw. The usual suspects made an appearance: required re-work that you won’t get paid for that only serve Apple’s purposes, a new look that nobody asked for that includes walking back decades of UI research and norms (many of which Apple themselves pioneered), and anti-features that make it harder to use things that you paid for in a way you see fit.

But there was one, possibly obscure, feature announced that I was immediately in love with: Scribble.

Scribble is iOS 14’s handwriting recognition feature. It’s not exactly new: it’s the welcome return of a beloved feature I lost when I parted ways with my MP2000 nearly twenty years ago. If Scribble in iOS 14 were only as good as the MP2000, I would be overjoyed to use it.

Scribble has been added to all native text fields. This means that you can Scribble in any text field that uses native components. If you have made a todo list application, and you used native widgets for this, your app is “automatically upgraded.” You don’t have to do any work. Your app on iOS 13 didn’t have handwriting recognition, your app on iOS 14 does. Apple did the work for you by improving the native text field widget.

This is the kind of user-positive “rising tide raises all ships” behaviour that I want to see from a platform vendor. It is Apple at its best, and it’s an unfortunately uncommon look for them these days.

I have had iOS 14 on my iPad Pro for a little while, and I’ve used Scribble a lot. I was surprised to find that the handwriting recognition isn’t actually better than it was on my Newton MessagePad. And it can’t seem to understand any of the Swedish words I write. But it’s still a welcome feature for when it does work, and I hope it will improve.

I had assumed based on this lovely implementation detail, that Scribble would be available in _most_ of the text entry fields on my iPad: not just in the apps provided by Apple. I was disappointed to find that Scribble only works in about half of the places I expect it to. There are a lot more non-native text field widgets out there than I realised, and I think this is one of the major problems afflicting modern software development.

Text field widgets are something that computers have had since the dawn of graphical user interfaces in the 70s and 80s. They are a very simple, standard, widget element provided by pretty much every platform. You wouldn’t think there was a lot of room for improvement or innovation, but Apple found one in Scribble. Unfortunately, a bunch of other folks who haven’t found room for improvement or innovation decided to spend time making their own from scratch that behaves ever so slightly differently, and doesn’t benefit from the positive changes that Apple was able to provide.

If Scribble isn’t available basically everywhere then its utility is compromised. We can’t become proficient at using this feature, and have it improve our lives if it’s not nearly ubiquitous.

The old adage If it ain’t broke don’t fix it comes to mind here. By making custom, from scratch text field widgets, something that wasn’t broken wasn’t fixed. But with the release of iOS 14 it was broken.

We talk a lot in the software industry about the pitfalls of re-inventing the wheel but the wheel is being re-invented constantly, everywhere. And it’s getting in the way of what little innovation we might find, and what small improvements there are left to make.

Marketing Avoidance

Graham and I have started a new project. We are Dos Amigans: two Amiga nerds who are broadcasting our foray into software development on the Amiga platform. We’re having a lot of fun doing it, too. You can tune in every Thursday at 18:00 UTC. We hope you’ll join us.

Wow, that felt weird.

Like many folks around me, I struggle with marketing. It always makes me feel … a bit dirty to talk about the things I make or services I provide. I think a lot more people would find Dos Amigans interesting if they only knew it existed, but we haven’t really done any marketing yet. The audience we have now is already bigger than I thought we’d have, mostly because they’re our friends, or exist on a discord where “stream announcements” are welcomed.

A lot of the things I do would have far and wide appeal if people only knew I was doing them, but I often avoid talking about them or drawing attention to them. This is a post about that.

I posted a link in a stream chat to Dos Amigans the other night because it was asked for, but it felt weird. Graham messaged me and said “I feel like the amount of promo we could do without being cunts is significantly higher than the amount we do.” And he’s right. We are the dudes making the thing, so why do we feel like cunts for telling people about the thing we’re making? Even when they might enjoy it? Even when they ask for it? Why does it feel so weird to talk about the thing that we’re doing?

We aren’t the only ones who feel this way. Eric Diven, of Long Walk Woodworking, recently posted on [a popular “news” website for “hackers”] thread about his move from software into woodworking: “It feels a bit weird to mention it, but [Cabinet on Stand] is also for sale through the museum” (emphasis mine.) Why does that feel weird? The entire thread was about Eric’s departure from software, and the whole audience was there to congratulate Eric and learn about what he’s doing next. I was very happy to learn where his work could be purchased.

Every marketing professional will tell you that marketing is “just letting people know that your thing exists,” but that’s just marketing as described. Marketing as practised is more often “trick people who don’t need your thing into thinking they must have your thing.”

I think marketing as practised is why some of us have such a strong negative reaction to marketing. I often go out of my way to make sure I’m not drawing too much attention to the valuable things that I’m doing that someone might be interested in, because I don’t want to be seen as a sketchy marketer who’s tricking people into buying my stuff or giving me their attention.

In the last week, I’ve noticed that a person (who was off my radar, because I had blocked them for being a smarmy prick and lacking substance) has made a considerable amount of money and gained a lot of attention because they effectively marketed a programming practice that I taught them. Because I’m not telling anyone what I’m thinking, or doing, or solving, other people are free to take it as their own. “It’s almost like we’ve been conditioned not to compete with the alpha capitalists,” Graham pointed out.

If I’m avoiding marketing, nobody will know that my stuff exists. If nobody knows it exists, then I’m more likely to be discouraged and give up because it won’t look valuable. If I market my things myself, at least I know that I’m being honest about what I can provide. Perhaps it’s time for nerds like me to learn how to do a bit of marketing. Maybe, to paraphrase a former boss of mine, “Marketing is too important a job to be left to marketing professionals.

I’m going to try talking more about the things I’m thinking, the things I’m creating, and how you might benefit from them. I hope I don’t come off as the sleazy kind of marketer, I really just want to share the things that I’ve enjoyed learning and creating so that I can help folks and be encouraged to do more.

My question to you, dear readers, is: where are the marketing books and materials for people who want to be honest and up front, and not try to trick people into buying things they don’t need? Do these materials exist?


CocoaFIBS is a Mac client for the First Internet Backgammon Server originally written by Adam Gerson.

After a number of years of not being updated, I forked CocoaFIBS to modernize it and improve it. I am also using it as a testbed for ideas about how to modernize and improve legacy code.

My work on it is sporadic, but I am preparing it for release.

Source Code

Five Things I Learned Working in an Office

I’ve seen a few “n Things I Learned Working Remotely” posts in recent history, as people migrated to remote work from office-based work and described their experiences. I’ve made the opposite transition since moving to Sweden in 2015, and thought I would share some of my experiences.

Everyone’s experiences are different, but these are mine. These things have been learned since being required to show up in an office every day at prescribed times. This list is intended to be fun, but they’re only half-joking: there’re at least a few amusing anecdotes behind each item.

1. Sick Days Exist, and Are Glorious

When working from home, a light sick day can mean a regular working day, or maybe a late start. A really bad sick day can mean you just work from your bed, and are maybe quite slow or mildly unproductive. Illness doesn’t really have to get in the way of your participation in the work, and you don’t have to count or juggle the days to ensure you’re meeting your obligations.

In contrast, when work must be done from an office, working while even a little sick is painful and inconvenient. It is also incredibly rude to your colleagues, who would probably prefer to not catch whatever you brought in with you.

The lightest sniffle means you absolutely must stay home and not work. Feeling a bit sad? Well, you don’t want your colleagues to catch melancholy, so you should stay home. Spending the day reading a book, playing video games, or watching silly videos on the internet may seem like a waste of time, but you are really doing yourself and your colleagues a favour by not working while sick.

2. Your Schedule is Rigid

One of the upsides of working remotely is that nobody knows where you are when you’re working, so your schedule can be very flexible. Doctor appointment in the middle of the afternoon? No problem! Long lunch with a friend from out of town? Who cares! Car needs fixing? Any time! Any period not already booked with a meeting or call is pretty well open to whims.

When you work in an office, there is an expectation (often, a strict requirement) that you’re always there. Running out to drop your car off at the mechanic can be risky: what if someone walks by your desk to interrupt you while you’re not there? Even if you’ll “make up the time” after hours, nobody will be there to see it, so it would be as if the work was never done.

The middle of your day will have this eight-hour block where you can’t be anywhere else but your office. Whether you’re productively working or not, you absolutely must be in your chair so that your colleagues can witness your presence.

3. Clothing is Not Optional

Working remotely means the ability to do the work from wherever you want, without people nearby. This can mean that clothing is optional. Since nobody is actually watching you do the work, it doesn’t matter what you’re wearing. Clothes or no clothes, good style or bad, only your family and pets will have any knowledge of the matter.

Showing up in the buff to an office, though, can subject you to many problems: from HR-related issues, to the negative effects of a cold office climate, to that colleague who just won’t leave you alone afterward. Clothing considerations need to be made carefully and deliberately when you work in an office.

Note: I have also learned that in Finland the rules are slightly more complex: clothing is still required in the office, but a lack of clothing is required in the office’s sauna. And there is an office sauna. Violating either of these two rules is simply not done, as far as I can tell.

4. Looking Busy is Paramount

In my remoting life, no matter the company or the project, the work was always the most important thing. It didn’t matter where I was when I did the work: I would switch between my home office, my sofa, the local coffee shop, the pub, the library, a plane, a hotel, or any other place I cared to. Nobody cared where I was, as long as I was getting the work done.

Since working in an office, though, I have learned that looking busy is the most important thing. Furthermore, I’ve learned from others that actually doing work can be completely avoided if you are really good at looking busy. The most valued contributors in some offices I’ve been in have been the people who are very good at looking busy, not the people who are necessarily doing the best work.

Starting at 11am and staying well more than eight hours is slacking behaviour, because you “come in late every day.” But starting at 7am can be basically a free pass to leave basically any time after lunch because you’re always the first one in.

If some work is done, and nobody sees it being done, was it really done?

5. Distractions are Welcome and Expected

When working remotely, communication is asynchronous. You ping someone, and they will respond when they are best able. If you need to have a call, you arrange a time in the future when both parties are in good shape to do so. This enables relatively long stretches of focused work.

I’ve found that one of the main oppositions to supporting remote working is that communication is harder when you can’t “just walk over” to someone. This is code for “I want to be able to interrupt you any time I like.”

In an office environment, you need to be open and available for interruptions and distractions at any and all times. You must be careful not to appear to enjoy such interruptions, though, because then you’ll be breaking the cardinal rule of “looking busy.” It’s a fine balance that takes practise to achieve.

Speaking at Elm Malmö

I am pleased to announce that I’ll be speaking at Elm Malmö on Friday, 23 November 2018.

My talk will be about my early experience with Elm while using it to build FocusFrog, an application for implementing the Getting Things Done method. I’ll be talking about what my goals with FocusFrog are, and why I chose Elm. I’ll cover my entire experience of this implementation, however limited so far. I’ll include what I like and dislike about Elm, what I found easy and natural, and what I found difficult and awkward.

More important than my talk, though, is that Richard Feldman (one of the most prolific contributors to Elm) author of the forthcoming Elm in Action will be speaking and answering questions as well.

If you’re in or near Malmö next Friday, and you have an interest in Elm, or you would just like to say hello and hang out, you should definitely consider dropping by.

The event is hosted at FooCafé, and as always there will be pizza and beer provided!

Managing Dotfiles with GNU Stow

Managing dotfiles can be tricky when you have multiple machines. Fortunately, there’s a beautifully simple tool that makes this easy: GNU Stow. If you have dotfiles that you want to share across multiple machines, or manage revisions, GNU Stow will make it easy.

Here you’ll learn about how to use GNU Stow to manage your dotfiles. I’ll start with a simple example, explain in detail how it works, and finally demonstrate a recommended workflow for using GNU Stow to manage your own dotfiles.

What is GNU Stow?

From the website:

GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place.

While GNU Stow is an excellent tool for package management, its real beauty lies in the simple design that makes it adaptable to other uses. Despite not being designed specifically for dotfiles, it is a perfect tool for the job.

GNU Stow is available nearly everywhere, and can probably be installed with your favourite package manager as the package stow. I use it on OpenBSD, FreeBSD, Debian, and macOS (available via MacPorts and HomeBrew).

Note that GNU Stow does not work on Windows. There exist some alternatives such as Eric Subach’s Stow Lite, but I do not have enough experience with such alternatives to comment on their suitability.

A Simple Example

Let’s get started with a simple example. You probably already have a .gitconfig in your home directory, so let’s start by stow-ing that.

Create a new home for your git-related dotfiles:

$ mkdir -p ~/dotfiles/git

Now move your .gitconfig there:

$ mv ~/.gitconfig ~/dotfiles/git

Get it back using stow:

$ cd ~/dotfiles
$ stow git

Behold, your git config:

$ cd ~
$ ls -l .gitconfig
lrwxr-xr-x  1 srbaker  srbaker  23 Jun 13 16:00 .gitconfig -> dotfiles/git/.gitconfig

If you’re not quite sure what running stow will do, you can find out by enabling verbose output, and telling it not to perform operations: stow --verbose --no and it will display what it would have done, without making any changes.

By now you have all of the knowledge necessary to manage all of your dotfiles using stow using the pattern from above. In the following sections, you’ll learn details about how it works. If you would like to get started immediately, you can just skip to the recommended workflow section at the end and learn the details later (if needed).

How It Works

The basic premise of GNU Stow is that it takes files in multiple directories, and manages symlinks to make them appear in one directory.

When invoked with a directory as an argument, stow simply changes into that directory, and creates a symlink for everything it contains to the parent directory. When invoked with many directories as arguments, it does this for each directory listed.

Take this example:

$ pwd
$ ls -R
bar foo



If we run stow bar, barfile will appear the in the parent directory.

$ ls ..
barfile stow

This is everything you need to know to make full use of stow. By default, GNU Stow is smart enough to do the right thing with files that you probably don’t want included, handling directories, and identifying conflicts.

Ignoring Files

GNU Stow can ignore files that you don’t wish to have stow-ed. You can tell stow to ignore files on the command line using the --ignore argument, and supplying a regular expression. If we want to use stow, but ignore files named foo we could do so like so:

stow --ignore=foo *

Likewise, if we wanted to ignore all files starting with the word foo we could use a regular expression: stow --ignore=foo.* *.

It would be cumbersome to add the --ignore argument to every single run. To solve this, stow will read an ignore list from .stow-local-ignore in the current directory, as well as a global .stow-global-ignore in your home directory.

By default, when neither a local nor global ignore list exists, GNU Stow will use its default ignore list which includes entries for version control related files, emacs backup and autosave files, and README, LICENSE, and COPYING. You can look at the GNU Stow documentation for the default ignore list.

Handling Directories

When stow-ing files, directories will be handled as well. I use this trick for managing my ~/bin directory, which you will see in the recommended workflow section below.

Consider that you have a directory foo that contains a file foofile and a directory qux which itself contains a file fooquxfile, as demonstrated here:

stow-example$ find foo

Running stow foo will create links to both the file foofile and the directory qux:

stow-example$ ls -l ..
total 4
lrwxrwxrwx 1 srbaker srbaker   24 Nov 13 16:49 foofile -> stow-example/foo/foofile
lrwxrwxrwx 1 srbaker srbaker   20 Nov 13 16:49 qux -> stow-example/foo/qux
drwxr-xr-x 4 srbaker srbaker 4096 Nov 13 16:42 stow-example

You can see that foofile is appropriately a link to foo/foofile and qux is a link to the directory foo/qux.

But what if in addition to foo containing a directory qux as described above, you also have a directory bar which has a qux directory of its own? From the example above, we can see that the stow-ed qux is already a symlink to foo/qux. Where will bar/qux live?

Fortuantely, stow does the right thing:

stow-example$ stow bar
srbaker@carbon:~/tmp/stow-example$ ls -l ..
total 8
lrwxrwxrwx 1 srbaker srbaker   24 Nov 13 16:54 barfile -> stow-example/bar/barfile
lrwxrwxrwx 1 srbaker srbaker   24 Nov 13 16:54 foofile -> stow-example/foo/foofile
drwxr-xr-x 2 srbaker srbaker 4096 Nov 13 16:54 qux
drwxr-xr-x 4 srbaker srbaker 4096 Nov 13 16:42 stow-example

The qux directory that stow created is now a directory of its own:

stow-example$ ls -l ../qux
total 0
lrwxrwxrwx 1 srbaker srbaker 31 Nov 13 16:54 quxfile -> ../stow-example/foo/qux/quxfile
lrwxrwxrwx 1 srbaker srbaker 32 Nov 13 16:54 quxfile2 -> ../stow-example/bar/qux/quxfile2

When stow creates a directory and links the contents from multiple sources inside on the second run, it’s called tree folding. stow has noticed that the directory qux is in two different sources, and folds them into the same tree. GNU Stow calls the reverse of this operation tree unfolding.

Identifying Conflicts

The default beahviour of GNU Stow covers most use cases without even displaying output. In most cases, it just does the right thing. Since files are being linked around the filesystem, it’s possible that stow will be asked to put two files with the same name in the same place. Consider two source directories foo and bar which both have a file called bazfile inside:

stow-example$ stow *
WARNING! stowing foo would cause conflicts:
  * existing target is stowed to a different package: baz => stow-example/bar/baz
All operations aborted.

In this case stow has recognized that there is a conflict, and refuses to make any changes.

A stow invocation that would overwrite an existing file also results in a conflict warning that aborts all operations. Consider that our parent directory (the target) already has a file called foofile and we try to stow the foo directory containing foofile:

stow-example$ stow foo
WARNING! stowing foo would cause conflicts:
  * existing target is neither a link nor a directory: foofile
All operations aborted.

This very careful default behaviour means that running stow is always a completely safe operation: no files will be moved or overwritten unless it can be done non-desctructively.

Using GNU Stow to manage your dotfiles is made infinitely better by storing your dotfiles in version control. By doing this, you will have history of your edits, and you can use existing tooling to share your dotfiles across machines.

If you keep your dotfiles in a VCS repository, setting up a new machine is as easy as:

git clone my-git-host:dotfiles.git && cd dotfiles && stow *

The machine you’re sitting at right now probably already has your preferred dotfiles, so you can get started immediately.

$ git init dotfiles

Now, for each program you have dotfiles for, move them into a directory inside your dotfiles working copy. For example, if you want to stow your git and bash dotfiles, you might do the following:

$ mkdir git
$ mv .git* dotfiles/git
$ mv .bash_profile .bashrc .bash_aliases dotfiles/bash
$ cd dotfiles && stow *

Whenever you make changes to your dotfiles in place, you will need to remember to commit those changes. If you add new files, you will have to remember to re-run stow: cd ~/dotfiles && stow *. If you’ve removed files since the last run, you should re-stow: cd ~/dotfiles && stow -R *.

Finally, if you decide that you would like to un-stow all of your dotfiles for whatever reason, you can cd ~/dotfiles && stow -D.


I hope this introduction to dotfile management with GNU Stow has been helpful. If you find any errors, or have any questions, I am more than happy to respond to email.

Happiness Adjacent

Our life in Sweden started as these kinds of moves do for many people: in the arrivals section of an airport. After flying all night, and having a several-hours layover in Reykjavik, we landed at the Copenhagen Airport, ready to begin our life in Sweden.

It is well known around the world, and often celebrated in Denmark, that Danes consistently rank the happiest people in the world according to the kinds of people who try to measure such things. I find it hard to believe, having spent some time in Denmark and having interacted with many Danes, but the experts seem to agree on this point. If nothing else, the Danes are quite skilled at giving the right answers on the appropriate tests, and tests are how we measure and certify many other things so why not happiness, too?

Raymond was only 7 at the time, but we had done a good job of selling the move to him, and he was prepared for an adventure. He didn’t have a good sense of geography, international boundaries, time-zones, or cultural differences, but he knew that this move was a big deal. He was taking it all in. He inspected every object, read every sign, and asked many questions.

Raymond and I were tasked with fetching the bags, while wife and daughter went to explore the facilities. On the wall near the baggage claim, there was a floor-to-ceiling Carlsberg advertisement that referenced the happiest people in the world. Raymond read the sign and asked, “Daddy, what is a Carlsberg?” Having experienced Carlsberg I was able to answer honestly while watching for our bags. I said, “It’s shit beer that they make here in Denmark.” He walked closer to the sign and inspected it more thoroughly, now several metres away from me on the other side of the stream of people walking toward the exit. After thinking about it for a bit, he yelled across the crowded airport, “Daddy, why are they the happiest people in the world if they make shit beer?”

There were a few seconds of dead silence, followed by dozens of people chuckling. I didn’t answer my son’s question, in part because I was startled by the situation, but in part because I didn’t have an answer. The boy had made a good point.

When most people think of Sweden, they think of Stockholm. For people who have only ever travelled to Sweden, or those who live there and enjoy it, Stockholm is synonymous with Sweden. Much like Toronto is Canada for people who have only travelled there, or enjoy living there. And, much like Torontonians think that Toronto is the centre of the universe, Stockholmers[^stockholmers] often think that Stockholm is the only bit of Sweden that exists. It’s only sometimes said out loud, but it shows in their actions, and especially in those of the politicians who work there.

[^stockholmers]: nollåtta is the term used for a Stockholmer, and I’m told the plural is nollåttor, referencing the region prefix for Stockholm phone numbers: 08. It would be like calling a Torontonian “a 416.”

The part of Sweden that we moved to is its southernmost province, Skåne. Skåne was a part of Denmark until 1658, and much of the rest of Sweden pretends it still is. Many of the Skånska people would prefer it that way, as well. Copenhagen considers Malmö its own suburb, and thanks to Öresundsbron, in practice it is.

A few hundred metres from my house is a beach. From that beach, I can clearly see Öresundsbron. Öresundsbron is a marvel of modern engineering that connects the part of Sweden that Sweden doesn’t want, to the part of Denmark that still claims it. The happiest people in the world live on the other side of that bridge, and I live next to them. Happiness adjacent.

The move to Sweden has been amazing for me and my family. My kids are getting an excellent education, and they’ll get to continue their education for as long as they care to. Thanks to the sensible amount of vacation that I get here, we actually get to do things. Because the working culture is reasonable, and people are respected as important parts of society, it is possible to actually do things that aren’t related to your job.

It hasn’t all been perfect, of course. The job didn’t turn out to be any of the things I thought it would be, and I’ve had a really hard time figuring out where I fit in. It has been very difficult at times to integrate and learn the customs, and when you make a mistake or social gaffe you often don’t know for quite a while, if ever, because people here tend to be quite indirect. To top it off, many things that used to be nearly reflexive routines like reading mail, paying bills, and seeing a doctor, have become chores that are painful and error prone.

But the positives outweigh the negatives dramatically. My life here is wonderful, and my whole family is far better off for the move. All of the issues I’ve experienced will only get easier, too: I’ll figure out where I best fit at my job; I’ll learn the customs and expectations; and I’ll get better at reading my mail, understanding my bills, and navigating public services.

The future is so much more promising here in every way, too. At work I get to work on Free Software, in a domain that has a lot of interesting use cases. Many of my colleagues are the smartest and most skilled people I’ve ever worked with, and I’ve made many great friends at work.

Sweden has excellent education, public services and infrastructure, and the people are generally quite excellent and easy to get along with. I’ve also been learning that not only will I not have to give up any of the dreams I had before moving here, many of them are even more attainable than they were in Canada.

There are a lot of things to like about my day to day life. I live in a quiet house, on a quiet street, in a quiet neighbourhood. A few hundred metres away is a beautiful beach. If you look at a map, I live on a peninsula next to Denmark, the place where the happiest people in the world live.

For the last year and a half, geographically, I have been very close to the happiest people. On a clear day, I can even see how to get there. And now, mentally, I am very close to the happiest I can be. With a clear mind, I can even see how to get there.

Sustainable Scripting

At NSScotland 2015, Amy Worrall gave a talk about how to enable your Mac programs to be scriptable with AppleScript. AppleScript itself, and the APIs around AppleScript haven’t changed much in the last twenty years. As a result, Amy was able to give her talk on a vintage PowerBook running some equally ancient version of MacOS[^spoiler-alert].

[^spoiler-alert]: Spoiler alert!

A few of us knew ahead of time that she was giving her presentation on this old computer, and we recognized the fonts and resolution differences. For some, there was an indication that something was amiss from the tap-tap-tapping noise of the harddisk head that could be heard across the entire room. Many people weren’t aware until she switched to do a live demo.

In order for Amy’s talk to work, she needed MacOS to run on her old computer. She also needed Metrowerks CodeWarrior, for the live code examples, and a program to develop and present her slides on. Of course, because software was distributed on physical media in those days, and there weren’t foolish laws that prevented you from backing up your own data, she was able to find what she needed (mostly from her own collections, as I recall). All of these things worked just as well as they did when they were released, and the computer was as fast and reliable as it always had been.

Barring physical deterioration of the installation media (which can be backed up to newer, more reliable media), there’s no reason why twenty years from now, Amy won’t be able to do exactly the same thing on exactly the same computer.

Phoning Home

The same feat will not be possible twenty years from now, with a computer purchased today. A Mac laptop purchased today, will almost definitely require a new disk in fewer than two decades. When the disk is replaced, it will need an operating system. This is where the fun falls apart: current versions of MacOS phone home during installation[^os-phone-home]. It is unlikely that the server on the “home” end of “phone home” will still exist and work in the same way twenty years from now.

[^os-phone-home]: I know that you can use tools to make a complete bootable installer for your Mac, but you have to do that yourself. And the installer still phones home, and again on first boot. There is an entirely separate set of problems associated with the “must plan ahead to not be screwed over” angle.

Users of the Mac App Store got an early glimpse of this future a few months ago when Apple let a signing certificate expire. This signing certificate was used in the Mac App Store’s DRM (Digital Restrictions Management) when the application (which was legitimately purchased) phoned home to make sure Apple still allowed your computer to use the software you purchased. For the time that this certificate was expired, users who paid for programs on the Mac App Store were unable to use them. Worse still, the error message displayed was cryptic and non-informative:

Application is damaged and can’t be opened. Delete Application and download it again from the App Store.[^blatant-lie]

[^blatant-lie]: The error message was a blatant lie. There was actually nothing wrong with the application in this instance: there was a problem with Apple’s oversight of the running of this application.

If the user were to actually follow these instructions, they would have deleted the application they purchased and then found that they were unable to download a “replacement,” because the Mac App Store wouldn’t install new software at that time. Yes, the Mac App Store came back, but what happens when the phoning-home endpoint doesn’t exist anymore? In this future, the computer would refuse to run the existing program, and would not be able to download a new copy.

This major gaffe has been mostly ignored or glossed over by Apple, but it points to a larger problem: the programs that are purchased on your Mac today will only work for as long as the Mac App Store functions exactly as it does today, at best. At worst, your programs only work as long as Apple sees fit that you have working programs (that you’ve paid for).

This error message will be seen again, in one of several possible circumstances. The most likely is that Apple overhauls the Mac App Store, and the “home” end of the “phone home” scenario simply disappears. I expect this to happen within a “regular” upgrade cycle (say, three to five years)[^upgrade-cycle] of a current MacBook Pro. At a certian point, maintaining the “old” phone-home endpoint isn’t worth the hassle for Apple, and they will stop.

[^upgrade-cycle]: Yes, I know you get a new Mac every year and can’t imagine owning such an old machine. But I’m talking about normal people. The people who won’t understand why they aren’t allowed to use the thing they paid for. And then blame computers for not working, when it’s actually DRM and copyright law that don’t work.

The Impermanence of Software

I know that in 2016, it might be hard to imagine a time when the world’s richest company doesn’t exist anymore[^microsoft-relevance]. But many of the most influential companies, and much of the most widely used sofware doesn’t exist anymore. Not that many years ago, I used computers from SGI, NeXT, and Sun. None of those companies exist anymore. But the computers work just as well as they ever did: the same is not true of the computer you have today.

[^microsoft-relevance]: Twenty years ago it was hard to imagine a time when Microsoft would be irrelevant and following everyone else.

We’ve been moving to a culture of renting. The computer you think you purchased from Apple, is effectively rented because the software will cease to exist some day. The media you buy from Apple, Google, Audible, and others is rented because the ability to play it can (and will) will some day be revoked. Thanks to laws like the DMCA and its related friends, you aren’t allowed to make unencumbered backup copies of these things, so you cannot keep forever the media you’ve purchased.

Perhaps it’s harder to see with computers that many of us replace every year or two. But anyone who’s been on a farm will have seen equipment that was manufactured by a company that doesn’t exist anymore. A tractor that has been purchased can eventually fail to work, or will be unable to be repaired because of the same forces.

This terrible end won’t come in one obvious change where we are suddenly unable to do the things we used to. It will come a little bit at a time. Our freedoms, and our abilities to use the things we’ve purchased will be eroded a little bit at a time. This is inevitable unless we start paying attention to what we’re buying, which practices we’re supporting, and what we’re willing to stand for as users.

I would like to look forward to a future where the things that I like, whose operation I’m happy with, work just as well many years from now as they do today. But I fear those days are behind us. I fear we’ve already lost, and sustainability is a thing of the past, not just for software but for everything we organize our lives around.

Switching Back

I first discovered and started using Free Software as a child. I was a Debian developer at one point before I was old enough to drive a car. I learned to shave on the #debian IRC channel on Valhall (an IRC network, or server, that pre-dates Freenode and OFTC.) I’ve been referred to as “one of the kids Debian raised.” Of course, I experienced internal conflict about my Free Software ideals from time to time: the industry seemed to be moving in a different direction, it was often impractical to use Free Software. But I have always either been a staunch supporter and advocate of Free Software ideals, or carried a hefty guilt over the abandonment of those ideals. I’ve always ended up coming back to Debian[^coming-back-to-debian].

[^coming-back-to-debian]: I’m about to start moving to OpenBSD, and possibly even work towards building my own platform based on it. I wonder if this is just yet-another temporary diversion from Debian, or if it’s my final move away.

At one point early in my career, I used an SGI O2, which was (and still is, I think) my favourite hardware. At another, I used a NeXT pizza box, which was my favourite software platform (still is, I think). When using those machines, I held on to my Free Software ideals, but briefly (and with massive feelings of guilt) put them on the back burner to use systems that didn’t require so much fiddling and fuckery to get work done. Of course, my work was extremely portable (and continues to be): Emacs, a terminal, various compilers and interpreters, and a sometimes a web browser. I saw commercial Unix as a means to get work done today, and GNU as the escape hatch for when things got really bad. It was convenient.

Commercial Unixes were even kind of a “free software” grey area compared to other options. They were based on mostly open[^unix-open] standards, and programs were expected to behave in certain ways that encouraged interoperability. In a Unix environment, even if I don’t have complete freedom (and source code) for the foo program, I can at least trust it to be simple and powerful and behave in predictable ways.

[^unix-open]: For some definition of “open.” The standards were at least well understood, and widely implemented if not strictly “open”. In those days, at least; Unix is a shit show these days. There are actually programs out there that won’t work across even distributions of GNU/Linux, let alone across different Unixes.

A Tale of Two Monitors

In the summer of 2005 I went to Parksville, BC to work at a web hosting and advertising company that was adopting Ruby on Rails and needed some help making the move. I was issued a custom-build PC, like everyone else, and installed Debian. Nearly everyone on the development team was running GNU/Linux of some description, and everyone had two monitors. My monitors were back ordered, so I was set up with a spare one to start, and would swap later.

When my two monitors arrived, I wasn’t in a huge hurry to set them up. They sat on my office floor for a few weeks before I opened the first of my brand new 21″ monitors and plugged it in. I spent the better part of a day before getting pixels pushed to it. Then I spent another two days trying to get the second working. At some point the first one stopped working. It was extremely frustrating, and was getting in the way of my ability to work.

Around this time, many people in the Ruby community were switching to Macs. With the release of OS X Tiger, Apple was basically a commercial Unix vendor at a time when the other commercial Unix vendors were starting to fade away. In the summer of 2005, Apple was providing a real Unix, on nice hardware, with great applications. And Mac users didn’t have to fuck with XF86Config to get their new monitors working. It wasn’t Free Software, and Apple certainly wasn’t a good citizen of the community, but one could at least have a computer that was pretty well guaranteed to work and would operate well with my Free Software.

On the third day of failing to get my new monitors working, I stomped over to the IT support guy’s office and asked him to order me a Mac mini. Then I went home while I waited for it to be delivered. For convenience.

The Switch

That’s how I became a “switcher.” I was the only one in the office at that time, and the only one in my immediate circle of friends to do so. Prior to switching, I had used PowerMac era Macs in public school, and had occasionally managed Macs that were part of a network I was responsible for, but at the time of the switch I had been pretty much exclusively a Unix guy for a decade. With Jordan Hubbard at the helm, I really hoped that I was getting FreeBSD with a modern GUI. I found it encouraging that the BSD folks had been rubbing OS X’s heritage in the faces of GNU/Linux users, claiming that FreeBSD had “won” the desktop. I guess that 2005 was, for me, the year of FreeBSD on the desktop.

Switching to the Mac at that point was delightful. I was up and running within an hour of opening the box. I copied my Emacs and Gnus configuration over, and imported my Firefox bookmarks into Safari. The first weekend I had the Mac, I read through some developer documentation and was reminded that OS X was basically NeXTstep: my favourite system to develop software for.

I was hooked. I finally had a real commercial Unix, on excellent hardware, that had a real (and growing!) library of software applications. I started questioning everything I thought about Free Software. Maybe the Free Software people had it all wrong. Maybe our ideals weren’t feasible. Maybe Free Software didn’t scale. Maybe there was some room for compromise. Maybe this new shiny machine would solve all of my problems. Maybe Apple could be trusted to do what was best for their users after all. Maybe convenience was more important than my ideals.

In the most enjoyable of my Mac-using days, I was using a perfectly married combination of hardware and software. When I was using beautiful, powerful, easy to use software directly from developers who seemed to genuinely care about my computing experience, it was easy to forget all of the reasons why I ever cared about Free Software.

I endured a lot of ridicule from my colleagues for switching back then. But not for idealistic reasons: they didn’t care about freedom. They cared about being the “cool nerds” that were smart enough to use “Linux.” They thought it somehow made them special to know which magical incantations were required to get a monitor working; they saw the fiddling and fuckery as a rite of passage. In time, however, I proved to be just the first of many. Everyone else on that team ended up ordering Macs when it came time to replace their hardware, too. As soon as it became cool for them to do so.

A Thousand Papercuts

I was “mostly” a Mac user for nearly a decade. I was fairly content with the decision at the best of times, although I was never one of those rabid must-buy-every-new-product crazies, worshiping at the altar of Steve Jobs, professing Apple’s infallibility. Apple would often do things that pissed me off. The first time was when they announced the switch to Intel[^switch-to-intel]. Later, the DRM on the iTunes Music Store. Then the iPhone with no native SDK. Of course the ridiculous restrictions on iOS applications (there was a time when you weren’t allowed to publish books about how to make iOS applications.) Every time one of these things happened, I would be overcome with rage, sell my Apple laptop, buy a non-Apple laptop, and install Debian. This would last a few months (or weeks) before I’d throw my hands in the air and get a Mac again. For convenience.

[^switch-to-intel]: They spent 30 years fighting an up-hill battle about the merits of a superior hardware architecture, and then just as the tides were turning in their favour, they gave up. And that they did so on the blatant lie that IBM couldn’t keep up with their “demand” (which was paltry) really rubbed me the wrong way.

My friends made fun of me for being on this treadmill. The Mac faithful were certain I’d be back. Apple had the functional high ground, after all: everything “just worked.” The applications were refined, easy to use, and improved my work-flows. When I installed Debian, something wouldn’t work quite right, some work-flow would be terribly unrefined, and I’d wind up back on Apple gear for the same reason I wound up there the first time in 2005: for convenience.

Somewhere in the back of my brain, my Free Software ideals still existed. Those feelings were still strong enough to make me feel guilty about using Macs. I continued using Macs despite Apple’s poor treatment of the Free Software communities their business depended on. Despite the proliferation of DRM in Apple’s products. Despite my nervousness about throwing money into the eventual black hole that was the walled-garden App Store ecosystem.

My friend Graham talked about his experience of a thousand paper-cuts. I remained a conflicted user of Apple products until Yosemite came out. Apple had finally lost the functional high ground[^marco-regret]. Suddenly wifi never worked, bluetooth was sporadic at best, lost my mail, notifications were unreliable, and my machine crashed constantly. Up to Yosemite, every release of OS X was worse than the one before it[^every-release-worse-than-before], but there was still immense value in the convenience of “just works” often being true.

[^marco-regret]: Marco has since claimed that he regrets posting that article, but only for the attention it got, not for the factual inaccuracy within.

[^every-release-worse-than-before]: A trend that seems to have continued with Apple breaking a bunch of Unix things in El Capitan. Apparently you’re not allowed to have /usr/local anymore (Update: apparently I’m crazy, and this isn’t true; I may have been confused by a related bug.)

With Yosemite, the advertised features stopped working, on all of my Apple products. “Family Sharing”, a feature I waited for impatiently for years, never worked properly (and as I understand it, still doesn’t.) It was no longer convenient for me to be a Mac user. The new features never worked, and because they were pushing tight integration between the Mac and the iPhone, it meant that everything broke all at once.

Apple itself is the biggest hindrance to the Apple ecosystem. I don’t miss iCloud, iMessage, or the App Store lock-in. I don’t care to let Apple be in charge of synchronizing my Music and Photo libraries between all of my devices, I can do that better myself[^apple-sync]. I don’t even care about Evernote, Dropbox, or any of those other “cloud[^cloud] services.” But I sure miss the stable of independent app developers who really care about shipping a quality product that their users will love. This is what you’re leaving behind when you ditch Apple.

[^apple-sync]: Apple is so terrible at services that my data might be safer written in pencil on paper and left out in the rain.

[^cloud]: There is no cloud, it’s just someone else’s computer.

I went for the convenience, I stayed for the functional high ground. Once both were gone, I suddenly remembered that I have ideals and morals that were being violated. I wasn’t aware quite how much I was giving up until I looked at the big picture.

Now it’s time to take a step back, and look at what computers can actually do for us to improve about our lives. It’s time to solve those problems, well, and in a responsible way. It’s not enough to be new and shiny.

It’s time for the tools to start earning their keep, and providing more than they take away.

I called this post Switching Back. It’s a reference to the words used in Apple’s “switch” campaign. But this isn’t about switching to or from Apple, it’s about reclaiming my data, my identity, and my freedom. It’s about switching back to the way things were before we were owned by the cloud, which isn’t a cloud at all: before we were owned by other people’s computers.