Hello again.
The thought of getting back to this blog has been in the back of my mind for quite a while, but unfortunately…
Muscle memory and why change hurts #
For the better part of four years, I’ve been using a non-standard keyboard layout to write, namely Workman. I’ve also been using ortholinear keyboards — specifically a Planck — after I fell down a pit of learning to build and tweak custom mechanical keyboards. I’ve spent tens — if not hundreds — of hours tweaking the firmware (available here, for the curious) and hardware in order to emulate the Workman layout in hardware so that I wouldn’t have to install any new (or custom) layouts on any computer I encountered. For all intents and purposes, this keyboard was a Swedish layout keyboard — it just really didn’t behave like one.
The unfortunate event came in form of a new directive from my employer’s IT security division. After some hubbub, it was decided that only authorized peripherals were allowed to be used with company hardware. That means no special keyboards, mice, webcams, or anything else really. A shitstorm immediately started brewing in relation to exceptions for ergonomic hardware but I have no idea where that went.
I was no exception to appealing for an exception — I figured that since I could account for all the hardware in my board and that the firmware was publicly reviewable, I should be able to get an exception. Right?
Nope.
Experience has taught me there is no sense in arguing with ITSec, so I accepted my fate. Unfortunately, that meant that I had to go back to using a “regular” QWERTY staggered keyboard, which I hadn’t done for years.
What followed was weeks of me struggling to even use a computer — I couldn’t touch type to save my life and even while staring at the keyboard, my typing speed was way down. In inverse proportion, my frustration was way up.
At the time of writing this — about two months after the “incident” — I can touch type to a reasonable degree, but my speed is still below 60 WPM, which feels pitiful. The process of unlearning Workman and getting comfortable with QWERTY is why I haven’t updated this blog much. I’ve been working on code in the background, but there’s usually a lot higher thought-per-character ratio there, which makes speed less important.
Anyway…
How’s the bootstrapping going? #
Glad you asked! Not well. At least not in the sense I discussed in The Bootstrapping Problem. See, setting up NixOS from absolutely nothing continues to be hard and not something I can easily automate. At least, not on physical machines. However, I have made progress in taking a non-NixOS system — e.g. Ubuntu — and turning it into NixOS.
Originally, I thought this sounded like a dirty hack. Surely you can’t take a running
system, shunt all of it out of the way and install a new one in its place without going
through the whole reformat/repartition song-and-dance-routine. I stumbled across tools
like
nixos-infect, but again — it smells
of hack.
As I read on about it, however, I learned that not only is this not a hack, it’s a supported method for installing NixOS known as “lustration”.
lustrate is a verb that is a synonym of “purify”, more specifically to ritually cleanse or renew through means of a sacrifice. (Source: Wiktionary)
I guess in this case the old/existing system is being sacrificed in order to make room for a “pure” NixOS system.
I’ll spare you the details on how I stubbornly rewrote the nixos-infect script into an
Ansible playbook — seemed like a good idea at the time — and cut to the chase. I
have, more or less, concluded that doing a single-step provisioning of NixOS is
infeasible. Not really because the system installation itself is gnarly, but because the
partition layout, filesystem choices, and so on vary too much between machines to be
reasonable. So, we’ll ignore that and get to the next stage: how do we manage NixOS
machines, once they exist?
NixOps #
The section title is a little of a giveaway — I was originally intending to base Kepler largely on Ansible, but in reading up on NixOps I have learned that it seems mature enough to be used in “production”. NixOps is kind of Nix’s take on both Ansible and Terraform — it’s supposed to be able to both provision and configure machines, but for my purposes I’ll be focusing on the latter.
This, of course, presents a new problem: I don’t know NixOps and the documentation is about as easy to read as any other Nix(OS) documentation — that is to say, completely impenetrable. In the usual Nix-style, it skips straight from “how to install NixOps” to “alright, time to deploy your first machine” with no explanation as to what command to run or whether the code snippets are a complete configuration file or a portion of something larger. At least it isn’t the word “closure” repeated ad nauseam, like the actual Nix language documentation…
This post was originally supposed to detail my first forays into writing NixOps configuration, but daylight has run out and tomorrow is a workday. That said, expect NixOps-flavored ravings going forward.