Pen Power

Very early in my career, I worked in Economic Development at the Western Valley Development Authority (now defunct) in Cornwallis, Nova Scotia. I got to do a lot of really cool things there, and work with people who loved their work and wanted to make a difference in the region. It was easily the most rewarding work I’ve ever done, and the artifacts of that work still benefit the region more than two decades later.

After a year or so of being overworked, I was excited to get a new colleague. A freshly minted Computer Science graduate named Graham (not Graham Lee, my current partner in multiple crimes) was joining to help out. I was really excited because I didn’t get to study at University, and was really self-conscious about this fact. I really thought I’d have a lot to learn from Graham.

Graham showed up first to work every day in a button-down shirt, and sometimes a tie. And he shared an office with a high-school dropout, foul-mouthed, blue-haired, atheist who wasn’t yet old enough to legally drink alcohol, but did anyway. Graham was everything I wasn’t: he did well in school, went to university, got married, bought a house, had kids, saved for retirement, all in the correct order. We respected each other, despite being polar opposites.

I learned a lot of things from Graham, but none of them were related to the CS education he’d had that I so desperately wanted. This is one of those things.

Every time we went to a meeting, Graham would bring a pen and a pad of paper. He was always first to volunteer to take the minutes. I found this weird: I always avoided being nominated to take the minutes because I found it a boring bit of busywork that I didn’t get much satisfaction from. I teased Graham for being a try-hard and assumed he was doing it in order to carry favour with the bosses. It annoyed me that Graham always volunteered to take the meeting notes.

During a drinking lunch one day, I told Graham that it annoyed me that he always volunteered to do things like this. Graham let me in on the secret. He told me “Steven, he who holds the pen, holds the power.” I snickered. I’d heard the phrase before, but I don’t think I’d ever really thought about it. He explained, “The minutes of the meeting are the official record. By taking the minutes, I can decide what to highlight and draw attention to, what to … the opposite of highlight, and perhaps in some cases what to forget to add.” In addition, he explained that when there was a meeting that didn’t have “minutes” he always took notes, and would send around a summary email to the participants after. This served the same purpose.

It was an almost too-cynical take for the do-everything-right goodie-two-shoes yes-man I’d assumed he was. I was impressed.

It has come up a lot in the decades that have passed. Not the sinister message manipulation bit, necessarily, but I have often found value in writing and sending a summary of the important bits of a meeting that I participated in. These summaries can come in handy, as a reminder of the things I want to remember, but also as a record of the decisions that were made and why they were made long after everyone has forgotten.

They’ve come in incredibly handy with problematic clients who want to insist on decisions that were never discussed, promises that were never made, or deliverables that were not late. When I’ve not taken these notes (and shared them), I’ve often come to regret it later.

I haven’t talked to Graham in over a decade. I hope he’s doing well. Last I heard, he had given up on the software industry and is a teacher now. I hope his students learn something like this that sticks with them for decades.

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.

Dos Amigans

Dos Amigans is a project that Graham Lee and I started where we explore developing software for the Amiga, and broadcast our experiences by streaming. You can visit the Dos Amigans website, or the stream site for more information.

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.