nullprogram.com/blog/2013/06/17/
I don’t know what to title or name this thing, so bear with me.
Two years ago I started versioning my Emacs configuration.
One year ago I started versioning the rest of my dotfiles
the same way. This has composed beautifully with Debian, which truly
is the universal operating system. To create my
comfortable development environment from scratch on a new (or used)
computer, all I need to do is
install a bare-bones Debian system, then direct it to
automatically install a short list of my preferred software (apt-get),
and finally clone these two repositories into place. Given a decent
Internet connection, the whole process takes under an hour to go from
blank hard drive to highly-productive computer system.
In fact, this whole process is so straightforward that it can be
automated using an amazing tool called live-build!
Taking the next step in versioning and automation, I wrote a
live-build build that creates a live system with my personal
configuration baked in.
A link to the latest ISO build can be found in the above link. To
try it out, burn it to a CD, write it onto a flash drive (it’s a
hybrid ISO), or just fire it up in your favorite virtual machine. You
will be booted directly into very nearly my exact configuration,
down to the same random wallpaper selection and PGP keys
(don’t worry, they’re safe!). It’s extremely minimal and
will look like this.
I don’t know for sure yet if this will be useful to anyone except me.
On occasions where I need to make quick use of some arbitrary
computer, or maybe just for system rescue, having this will be
incredibly handy. Knoppix is nice, but working without my
own configuration can be discouraging; it’s so slow in comparison.
It’s also a chance for others to glimpse at my workflow without any
commitment (i.e. potential dotfile clobbering). I like to study other
developers’ workflows, stealing their ideas for my own, so I want to
make mine easy to study. I think I’m doing some innovative things with
a hacked-together pseudo-tiling window manager, my Firefox
configuration, and my Emacs configuration. At least two of my
co-workers’ Emacs configurations are forked from mine (you know who
you are!). From a selfish perspective, the more people using workflows
like mine, the better these workflows will be supported by the
community at large!
I had said that it’s “very nearly” my exact configuration. At the time
of this writing, what’s missing is Quicklisp and
Leiningen, since these aren’t available as fully-functioning
Debian packages at the moment. I’ll work them in eventually. The build
is non-incremental and takes about an hour right now, so adding these
little extras by trial-and-error will take some time.
Pentadactyl really shines here, because it allows me to
completely configure Firefox/Iceweasel from a version-friendly text
file. Except for some user scripts (still figuring out how to install
those at build time), the browser in that image is identical to what
I’m using right now. Even though V8 is the king of performance,
Firefox still wins hands-down for power users due to its superior
configurability.
However, this Firefox configuration still has an annoyance. Several of
the browser add-ons that I pre-install always pop up their first-run
welcome messages. These messages flip a setting in Firefox’s registry
so they don’t run again, a setting that is lost when the system shuts
down. I can toggle these settings from the Pentadactyl configuration
file, but not early enough. By the time Pentadactyl gets to applying
these settings it’s too late. The messages, including Pentadactyl’s,
are already queued to be shown. I don’t think it’s possible to
completely fix this, even if Pentadactyl is fixed.
Anything not already installed is readily installable through apt-get.
Right now I’m considering the feasibility of some sort of lazy-install
system based on command-not-found. Debian has a package called
command-not-found which intercepts the shell’s error handler when an
issued command is not found. Instead of just giving the normal
warning, it prints out what package needs to be installed in order to
provide the command. What I think would be really neat is if the
needed package is automatically installed, then the requested command
is then re-run, all without returning control to the shell in the
interim. It would be a lot like Emacs autoloads. As long as I have an
Internet connection, most of Debian’s packages would be virtually
installed on my live system as far as I’m concerned. The initial run
of any program just takes a little longer.
I’ll continue to tweak this image over time, not only as I figure out
how to make things work in Debian live-build, but also as my
preferences and workflows evolve. Adjusting my configuration to work
on a live-system has been enlightening, revealing all sorts of little
manual things that I hadn’t yet automated. Perhaps someday this build
will replace traditional operating system installations for me, at
least for productive work. I could do all of my work from a portable
read-only live system with a bit of short-lived (i.e. local cache)
user-data persistence stored on a separate writable medium.