Skip to main content

Primitive Tooling



I regularly see posts on Twitter about some new whiz-bang shell or vim plugin that automates some task, making it more pleasant. I almost never use any of them.

The reasons why can be traced back to my first job as a systems administrator, where I had to learn Solaris on the fly. I learned most of my Unix-fu on Linux, where I learned on bash. The shop I was working at used the Bourne shell that shipped with Solaris 2.6 and 2.7. This was a frustrating time because many things that were easy in bash didn't work at all in /bin/sh, so I started 'downgrading' to the Bourne shell way of doing things.

A couple years passed and I had gotten to the point where I pretty much used only basic /bin/sh and was mostly happy with that. Then along came HP-UX and its POSIX shell, which is just like Bourne shell only maddeningly different in a few places. Since the environment I was working in had both Linux and HP-UX in production, I usually wrote scripts to support both and it was tedious. I talked my team into switching to pdksh everywhere and things were mostly better. I got a stable environment across operating systems while the experienced HP-UX admins got an experience more like what they were used to on Linux. Win-win for the win.

Eventually, AT&T opened up the code to the original Korn shell and the pdksh project stagnated. As far as I know, it still compiles on Linux, but it did not work very well on HP-UX / Itanium without patches. I wrote the patches, but if you know anything about HP-UX shops, you know that they tend to be conservative so pdksh was out. And now I'm back to writing POSIX shell code.

That's just one part of the story, but I think it demonstrates why I still stick to primitives a decade later. With every move between versions of shells, Linux distributions, FreeBSD, OpenSolaris, etc. I've simply found it easier to stick with primitives and avoid any heavily modified environments. These days, I do default to bash and use bash syntax regularly. I don't work on any operating systems that don't ship bash. I also start my shell scripts with #!/bin/bash instead of #!/bin/sh so the dash thing never bothered me a bit.

My vim setup is similarly minimal. My ~/.vimrc is around 30 lines and has changed very little in the last decade. I added Pathogen a couple years ago, but I only really use it for filetype and syntax plugins. I also only use about 5% of vim's features, mostly things that work in vi. Just like with the shells, I can log into almost any Unix system around and get up and running with vi without installing anything.

Over the years I have applied the approach to more things. I've always used the default clients for social media. I don't use browser plugins (except for rikaikun). I only install a half-dozen or so applications on my Mac. My Windows machines have no OS-level plugins. My preferred desktop on Linux is XCFE with a basically default config, no compositing, all shininess disabled. My phone has a stock ROM and I use the default UI settings most of the time.

It's not for everybody, but it does have some advantages:

1.) it takes me about 5 minutes to get set up on a new workstation
2.) I rarely have to install anything extra on machines I admin
3.) the few rcfiles I use are easy to move around with `cat > ~/.rcfile` and ctrl-d
4.) the few aliases I use are noops when not present (e.g. ls --color)
5.) I don't have to remember or think about trivial details very often

Like every decision, it's a tradeoff. I'm trading off small efficiencies every day to avoid having to memorize lots of things. My editor isn't as powerful as yours, but I always have my editor even when I'm not root. My shell is boring, but whether I'm root, atobey, or any other account it works the same.

I also tend to apply similar thinking to code, which is probably one of the reasons I like Go so much. A small syntax is easy to remember and apply consistently. I also don't put as much emphasis on code reuse as I see others do. The backflips required to make code actually reusable is rarely worth the effort and increases testing burden, so why bother? It's another tradeoff obviously and one I default to with increasing frequency as I grow in experience.