Pardon the rambling musings; I'm beginning to describe my [failure modes], and I'm sure I'll speak more clearly once I consider my [composure].

My sleep has been rough, because I am happy to be nocturnal some days. The long pre-day hours open up, and I see the hours click by as I push through command after command, building up some shape in my code that I'd been dreaming of for days.

unplanned (& poignant) misalignment, a CSS cure for the image rotation.

This seems to be a therapy after so long in a nomadic limbo. I loosen up my solar alignment and embrace the universal alignment, recognizing that in this phase of the year, the stars that I'd see if I chose to escape the house may perhaps be closer to those arranged at the moment of my birth, than any other moment ahead of us. There's some geography, no - astrography - I could measure someday.

---

So in the early morning on 06-09, a day ago, I was pushing through a problem of deployment, using my normal means; microvm.nix. I'd learned of this mechanism years ago, and became enthralled. The (current) most inspiring company in the cloud space chose to use microVMs, so how else could I choose? Besides, this could only amplify my nix skills, I assumed.

I spent months working up to my deployment, when I began. I published a codebase designed to help me reproduce and re-launch apps easily. I then broke the VM description into the per-app flake.nix, so I could adapt a new VM per application, and oppose the dominance of Dockerfile as the norm for deployments.

So early morning a day ago, I was deep into the deployment of Fizzy, a modern kanban app made in Ruby on Rails. Has been years since I looked seriously at Rails, though I spent the first half-decade of my career in that framework.

Fizzy has been pleasant to use locally, in development mode, as a single user. I could spin up the process when need be. I had all the dependencies coded in a flake.nix so I'd be sure to have an easy re-deployment path. Now though, holding back sleep, I began realizing that the VM was failing me. From the MicroVM element discussion board:

I'm trying to package up Fizzy in a microvm for easy re-deployment. Some of the ruby gems have native extensions and need to be compiled from C, My packages include lld gcc gnumake libc.dev libyaml.dev openssl_4_0.dev. The bundle install command runs in a normal nix develop shell, and fails inside the microvm; the compiler is unable to link yaml.h or openssl/error.h, and I'm unsure how to make these headers appear to the compiler - I thought that's the purpose of lld.

I shared this in the morning after having another go. These are the problems that become depressing - they keep us from actually making progress on the apps that are necessary.

I realized I had enough experience, after a year of this nonsense, to close one of my experiments; a failure of implementation that leads to a new direction. I quickly shared my decision:

now, after my domain has relied on microvm.nix for close to a year, I think I'm ready to move on.

I heard a "FLOSS Weekly" episode featuring the author of Incus

• (for Nix: https://wiki.nixos.org/wiki/Incus )
• I think this is a simpler mechanism for deployments, more broadly compatible with existing container formats ( https://images.linuxcontainers.org/ ), and I can see how the same "hyperconvergence" mechanisms of microvm.nix could be used to mount a read-only store into containers that are prepared using nix flakes
• see the "Custom Images" section of the Incus wiki page.

I'll compose some side-by-side comparisons for my blog

• these microvm experiments have been a fun journey so far, and has really amplified my experience. A comparison should help close the loop on these lessons.

I need to admit that I began this research after hearing that fly.io was running on firecracker; as a solo experimentor I need to scale back to something more commonplace. Maybe we can bridge lessons from microvm.nix into more commonplace deployment practices.

---

Where did the failure occur?

Nearly three years ago, perhaps

• when as a member of HacDC, I pulled up a video from NixConf, saw the connection between a few groundbreaking ideas, and decided that I could probably reach a similar technological success as Fly.io.

The failure began to display when I composed pool, which seemed necessary to keep the mechanisms clear in my mind. When I shared this in the microvm.nix forum, someone asked me to explain it more clearly. I rather quickly gave up, deciding that I needed to re-think the codebase, and then keeping it dormant through a season of social change.

These were alignment issues - I failed to recognize the difference between my homelab needs and the needs of a hyperscale cloud; the difference between my deployments and the normal uses of nix, for space-satellite-grade reliability. I failed to align my publication of pool to the needs of the microvm.nix group, or learn the reasons that we all chose to gather around this technology specifically.

Luckily, that final piece is a new chance; I proposed a change in my alignment to the group, and I can begin to ask others to describe their purpose, to see where we are aligned in a broader sense than mere code use.

---

Another failure has been choosing to expand my use of Fizzy; this seems to be a misguided pursuit for alignment to 37Signals. This company is behind Ruby on Rails in large measure, and they do run an inspiring business. As someone who imagines Ruby to be behind me, is there any sense in re-sparking my Ruby skills? Why would I go back to Kanban, especially since learning to produce much more nuanced mission diagrams?

Maybe I'll be able to follow the docker deployment guide, alongside Incus, because I'm going back to alignment with deployment norms. I can build on the practice of others, and rely on the published guidance. In a sense, this is the decision described by "innovation tokens", where do you align to the main-line norms, and where do you choose to branch a path to take the herd in a new direction?

Of course, this small change in alignment means I can keep learning from Fly; I no longer need to manage the core network interfaces, so maybe their wireguard scheme is more reachable.

---

Finally, I've begun to describe this small crisis-arc of my career as "experiments in deployment engineering". I've learned enough by now; and I realize why the underlying layers can be so incomprehensible. The science is inspiring, but largely insignificant compared to the needs of media publications.

I'd like to resume the career arc I excelled in - composing social programs, especially aligned to current needs.