One of the more noticeable limitations of the Raspberry Pi is using an SD card for its main storage. If you’ve been using a Pi for a while, you might be looking for more storage, faster access times, or media with a longer lifespan than many SD cards turn out to have.

This tutorial and its associated script borrow heavily from HOWTO: Move the filesystem to a USB stick, by paulv on the Raspberry Pi forums.

There’s a lot of thoughtfully composed documentation out there on doing just this (see the guide’s Further Reading section for a bunch of links), but as with most step-by-step processes culled from forums and blog posts, it took me a while to get the particulars right. Hopefully the shell script will alleviate some frustration if you’re looking for a similar setup.

Lately, as I work with little projects like this one, apt.adafruit.com, custom kernel packages, and helper scripts for the PiTFT, I’ve been thinking about how the technical community approaches sharing our knowledge and making work reproducible for others.

There’s a staggering amount of work done every day – by people in the libre software community, engineers and tech support specialists at companies like this one, forum users, bloggers, tutorial authors, on down the line – to communicate what makes hardware and software work to other users and creators. Over the past few years I’ve seen a lot of how the sausage gets made (so to speak) at companies like SparkFun and Adafruit. I’ve followed a lot of conversations on mailing lists and groups like debian-devel and vim_use. I’ve spent a whole lot of my waking life for the last decade googling for the solution to some esoteric technical problem, and I’ve started to experiment with the problems of packaging, distributing, and documenting software for other people to use. (I’m not great at this yet, because it turns out to be way harder to do well than I ever knew.)

The thing I have realized is that, even when you’ve figured out how to solve a problem for yourself, it’s a lot of work to share what you’ve done with other people, especially if you want them to be able to actually use it. Oftentimes, it’s a lot more work to share your solution than it was to come up with the solution in the first place. What’s more, it’s often the kind of work that’s the least glamorous and shiny that makes the difference:

• Writing thorough, clear documentation.
• Keeping your stuff in public version control.
• Keeping track of sources and referencing the things that helped you solve the problem.
• Organizing your code to be understandable, even at the expense of cleverness and brevity.
• Writing runnable scripts and Makefiles and so on in addition to prose instructions.
• Packaging software for redistribution, complete with all the bureaucracy of licenses and changelogs and manual pages.
• Fielding bug reports while maintaining composure and compassion for fellow users of things.

I don’t have any earthshaking revelations to share, but it’s on my mind that a lot of the problems most important to our community are about this kind of labor: The barely-visible work of scaffolding and infrastructure and communication. This is work that makes all the difference, even if it’s often thankless and unremarked by comparison to other things.