02 Embedded Rust Plus Nix, pt. 1

2026-02-16T00:00:00+00:00

TL;DR</h2>

I made an embedded Rust workflow for the Arduino Uno (more broadly, the ATMega328p chips they use) using the Nix language. It takes the form of a flake, whose template you can use right now by using</p>

nix</span> flake init</span> -t </span>'</span>github:of-the-stars/flake-templates#arduino</span>'
</span></code></pre>
within your embedded Rust project! It allows you to build and deploy your project to your device automatically from a remote source with one simple command. It also allows you to enter a local development sandbox with all necessary dependencies included with nix develop</code> command or automatically with the wonderful direnv</a> project.</p>
My example blink project can be built from remote using the command</p>
nix</span> run '</span>github:of-the-stars/blinkyy</span>'
</span></code></pre>
Keep reading to learn about my journey on getting here!</p>
Motivation</h2>
Recently I found a big huge abandoned box of DIY electronics components at my job, mostly made up of an Elegoo Mega 2560 R3 Starter Kit, plus a few extra items which included a couple of ESP32 DevKit v1s. Before this I'd bought myself an Elegoo Uno R3 Starter Kit off of Amazon a couple of years back, and I wrote some baremetal C++ and Rust for it while on Ubuntu. I'd also used it for a research experience I was a part of. However, almost immediately before finding the components that I did, I'd been running into some problems creating a Nix flake-based toolchain for my Uno to use on my NixOS machine, namely getting rustc</code> to actually compile for the target architecture. I'd given up, but finding all these components and more than doubling my collection motivated me to actually knuckle down and figure out what was going on. Unfortunately, I decided to choose something that's such a niche within a niche that very little documentation exists for what I'm trying to do, and I had to piece this together via various code snippets and my growing understanding of both Nix and Rust. And in the spirit of leaving things better than how I found them, I'm writing this with the hopes that I'll be able to save other the headaches I've had to fight through.</p>
Trying to get specifically a Nix flake</em> working to cross compile Rust to the avr-none</code> target using Nix was my main goal, and while I eventually got it working, it took about a month's worth of trying to do so. They main goal of the project was that with the "experimental" nix</code> command, it could be possible to pull an embedded project's source code, and automatically deploy it from source with the guarantee that it's going to be the exact same resulting artifact with every invocation of a single command, that being</p>
nix</span> run '</span>github:of-the-stars/blinkyy</span>'
</span></code></pre>
If you have an Arduino Uno, try it! As long as you have Nix installed, with the nix-command</code> and flakes</code> experimental flags, and a stable internet connection, this will build a simple Rust program that flashes the on-board LED 10 times a second.</p>
The beautiful part is that this eliminates the hard part of embedded deployment so that anyone wanting to flash firmware can do so easily and frictionlessly. As a developer, this simplifies the often complicated installation of embedded toolchains, managing source, and building the firmware with specific flags for my end users and collaborators.</p>
The Great Battle</h2>
The Goliath of this particular fight, as it is with most niche Nix applications, is the complete lack of comprehensive up-to-date documentation. Nix has been evolving quite rapidly in recent years, especially since 2021. The core of the Nix language and package manager, the most well documented parts, haven't changed much. But when it comes to the newer features like Nix Flakes, the best one can do is follow breadcrumbs like a sleuth to piece together an understanding. And I agree with people like cafkafk</a>, a current member of the Nix Steering Committe, that the flake interfaces aren't unstable at all and that a path to release needs to be made immediately. For many, myself included, flakes are what finally made Nix "click" and make sense. Before I switched my system to using flakes, fiddling with channels and various shell.nix</code> files felt extremely weird, since they seemed to violate the whole "pure derivation" thing that I'd seen emphasized across the project. And pulling specific revisions from hard-coded magic number git revisions felt like an ugly hack that I did not want to deal with.</p>
This is why a flake-based approach was so important to me. It greatly simplifies the development and deployment, and the ability to do 5 different things with 2 small files and a couple command invocations seems like magic.</p>
For this project the main stack is:</p>

An Elegoo Uno R3</li>
The avr-hal</a> to provide Rust abstractions to interact with the hardware</li>
Oxalica's rust-overlay</a> to use tell Nix which Rust toolchain to use</li>
Crane</a> as the Nix library to build the rust code</li>
A Nix flake to create a development environment, package the code, and create a shell script to flash the firmware</li>
Ravedude</a> as a fancy avrdude</code> wrapper to flash the firmware and open a console</li>
</ul>
Seems simple enough, and minus Ravedude and the Arduino, this looks identical to a lot of others' setups for building Rust projects with Nix. The main blocker was the hardware itself. Getting a Rust toolchain declaratively set up with Nix seemed possible; avr-none</code> was at least a supported target, albeit a tier three one. If it weren't an officially supported target, like xtensa-none-elf</code> which is the ESP32 target, that's a whole other ballgame, and it warrants a part 2 in this series.</p>
The main supervoid that ate up all my time was trying to use nixpkgs</code>'s built-in cross compilation framework to build the package. The main reason this simply doesn't work is because Nix isn't running on the Arduino. While getting Nix working in an embedded context seems like an interesting exercise, the ATMega328p microcontroller on the Arduino simply doesn't have the power to run such an overhead. Once I moved past this approach, I started to make leaps in progress towards the final goal.</p>
The second major obstacle was getting Crane, the Nix library, to actually build for the Arduino. By this time,, I'd already gotten the pretty simple dev envrionment set up, and running cargo build</code> or cargo run</code> worked just fine to build and flash the artifact to the board. However with Crane, I kept hitting snags where certain dependencies couldn't be reached when running nix build</code>, but running cargo build</code> in the dev shell worked just fine.</p>
As it turns out, as part of its effort to maintain reproducibility, Crane vendors</em> its Cargo dependencies, keeping the entire dependency graph in the Nix store. The reason this doesn't work out of the box with the Arduino target is because avr-none</code> is a tier three target for the Rust language. In all Rust projects targeting ATMega microcontrollers, we have to pass -Z build-std=core</code> to the Rust compiler to build the core Rust language from scratch because the Rust Foundation does not provide pre-built artifacts for the avr-none</code> target. So whenever Crane vendors its dependencies, including the rust-src</code> component via the custom toolchain we provided, it can't find the crates that core</code> depends on. Now, when inspecting the Nix store, I found out that Rust already vendored core</code>'s dependencies for us, and placed them together to be found locally. But Crane doesn't automatically know that, so I figured out that I have to provide it the core</code>'s Cargo.lock</code> file to let Crane know that all of its dependencies are already packaged, and that it doesn't need to look among its own vendored dependencies to find them. Unfortunately, to automatically do this from our custom Rust toolchain would result in what we in Nix circles call Import From Derivation, or IFD. Scary, no? Apparently it is, because it's a performance boogeyman that throws a wrench in the way Nix evaluates expressions. So we have to manually update the lockfile locally, which is a bit of a dirty hack. The next major version of this workflow will need to at least update this automatically and keep it tied to the flake.lock</code> file which dictates which cached version of the Rust toolchain we'll use.</p>
59</td> # Helps vendor 'core' so that all its dependencies can be found
</span></td></tr>
60</td> cargoVendorDir </span>=</span> </span>craneLib</span>.</span>vendorMultipleCargoDeps </span>{
</span></td></tr>
61</td>   </span>inherit </span>(</span>craneLib</span>.</span>findCargoFiles src</span>) </span>cargoConfigs</span>;
</span></td></tr>
62</td>   </span>cargoLockList </span>= [
</span></td></tr>
63</td>     </span>./Cargo.lock
</span></td></tr>
64</td>     </span>./toolchain/Cargo.lock
</span></td></tr>
65</td>   ];
</span></td></tr>
66</td> }</span>;</span>
</span></td></tr></tbody></table></code></pre>
The goal is to make this automatic as a part of running nix flake update</code>, or to just bite the bullet and just accept the IFD anyway. However, I like my builds to be completely pure, so it'll likely take me a while before I get a breakthrough with it.</p>
Conclusion</h2>
Now that I've built this workflow, it's gonna be time to actually put it to the test and build some projects using it. While I get the IFD situation figured out, I'll also be looking to create the same workflow for the ESP32. However, since the chips I have aren't officially supported rustc</code> targets, I'll either be waiting for the gccrs</code> front-end to be completed, or more likely, have the Espresif-maintained forks of Rust and LLVM be merged upstream to use.</p>
Resources I Used</h2>

oxalica Rust overlay rust-bin cheatsheet</a></li>
oxalica Rust overlay cross compilation examples</a></li>
oxalica Rust overlay cross compilation docs</a></li>
"Just a simple Nix Flake for Rust and WASM" by Gijs Burghoorn</a></li>
The avr-none section of the rustc book</a></li>
Cargo environment variables</a></li>
avr-hal docmentation</a></li>
Crane cross compilation docs</a></li>
Crane build customization docs</a></li>
</ul>


01 Nix and I
2025-12-17T00:00:00+00:00
My experience with Nix</h2>
I've been daily driving NixOS on my laptop since June 2025. My previous laptop was running Windows 11, then Ubuntu when Windows decided to be Windows. After that system broke (I dropped it), I had to buy a new laptop and decided it was also time for me to go distro hopping. While I'd been happy on Ubuntu and knew it well, I also had one glaring issue: packages.</p>
apt</code> isn't well known for having a bunch of fresh-off-the-PR-merge packages available to install. Ubuntu specifically also had me deal with the Snap store, which I didn't like at all. Why should I have to deal with an entirely separate marketplace just to get Firefox installed, especially one that sucked. Flatpak solved a few problems for me, but I didn't like the idea of having to add yet another package manager to my already convoluted system. Appimages frustrated me with how manual they were, especially for a program such as Discord which shipped updates frequently. Combined with an install of QT Design Studio I couldn't seem to get rid of, I no longer felt that I had a complete understanding and control of my system. The cord had become too tangled and Gordian in nature, and it had to be cut. Breaking my already failing little Hewlett-Packard was the blade to do so.</p>
What introduced me to and sold me on NixOS was a video by No Boilerplate</a>, which adressed ever single one of the problems I'd been facing. Before that, I was considering using Arch, by the way, or perhaps one of its derivative distros like CachyOS or Manjaro. Learning that nixpkgs had not only more packages, but fresher ones at that than the AUR completely dwarfed the Nix learning curve I'd heard about. When my new Thinkpad T14 Gen 5 arrived, I spent about 10 total minutes in the pre-installed Windows environment solely to create an installer image for NixOS. I promptly washed my hands after the encounter.</p>
Going straight to NixOS on baremetal actually seems to be a little uncommon now that I've spent more time in the community, so I'm quite proud that my experience was a good one. I was pretty quick to wrap my head around the basics of the Nix language and what my configuration.nix</code> was doing. Making use of a heavily modified version of 0atman</code>'s rebuild script was a lifesaver. Speeding up the time it took me to iterte through another Nix generation, even if it was just adding a few packages, made the whole experience lightyears better than what I'd been dealing with before.</p>
Thoughts on Nix and its future</h2>
I liked the guarantees presented by using NixOS, which I refer to as the "Nix Promises": Immutability, Reproducibility, Reliability, enough to get past the hurdle that is using Nix. Even though NixOS isn't truly</em> immutable by default, it gains a lot of the benefits from playing in that space via the /nix/store/</code> directory. The reproducibility hasn't been something I've used all that much yet, but I'm excited to explore it as soon as I get my hands on some more hardware. The reliability has been the biggest strength of choosing NixOS as my operating system, and it's something I think the community would do well to emphasize.</p>
Like with my favorite programming language, Rust, I think the Nix community often forgets some of the tool's greatest strenghts that would help push adoption. Actually, I think that Rust and Nix are both facets of the same kind of object, and not just because of how big of an overlap in the userbase there is, or the fact that they work well together. Rust and Nix set out to solve a class of problems that can really mess things up by strictly enforcing and maintaining a certain amount of theoretical correctness that most don't really care about. The Rust borrow checker and packaging binaries with Nix both offer some overhead for their invariants that programmers just starting out with either often clash with. When speaking to people I know in person who haven't really interacted or heard of either, I often run into the shared question of "but why tho". And it's hard to answer! Why would someone bother with Rust and Nix when C++ and Ubuntu have served just fine. Nix  has a big problem with lacking a clear raison d'être, which Rust does have. Yes Rust can be "blazingly fast", but other languages are often fast enough and easier for most applications that citing its speed as its main strength isn't enough. But if you want low-level performance, like C, that's memory safe without the overhead of a garbage collector, you use Rust. It's simple, it's clear, and it gives people the motivation to actually use Rust without relying on the intellectual curiosity many use to climb up the learning curve. It's why Rust is a permanent part of the Linux kernel, when no other language has ever been added after it was originally written in C. In the same way, other operating systems are "good enough" for most. NixOS is a minority within the minority that is Linux as a PC operating system. Even ignoring the fact that Windows and MacOS all dwarf Linux's numbers, there are plenty of alternatives that someone might choose instead of Nix: Ubuntu, Fedora, Arch. NixOS lacks the same "default choice" that Rust has, or at least the criteria that make it a default choice are too narrow. If one were only looking for the Nix Promises, like I was, well then Nix is</em> the obvious choice. However, the Nix Tradeoffs are something that I was willing to deal with in exchange for the Promises. That simply isn't true for everyone, and if Nix is going to grow its numbers and its ecosystem, it needs to be the best and hopefully only logical choice for a certain problem that people actually encounter, like Rust.</p>
While thinking about its reliability, I realized that Nix is probably the best tool for "fire and forget" deployment for the space between general PCs and embedded systems that still needs to be user-customizable. Something where you really don't need to be doing much outside a specific usecase, but not so specific that you tailor and lock it down to one specific function as you do with an embedded system, and where it needs to work every single time. A kind of system where for whatever reason, you don't want it to ever break from a software bug. Update break your system at a critical time? Just roll back and deal with it when you're not depending on it. You get all of the benefit from the latest software, but you don't need to worry about your system breaking. As long as it works in your tests, it'll just work identically in production.</p>
Admittedly, I think this is a pretty small use case. Besides a personal project of mine that is nowhere near finished enough to share details about, I'm having a hard time thinking of a usecase for such a system that isn't already filled in by some kind of embedded system. Servers and hosting for large companies are the only other one I can really think of, and Determinate Systems</a> seems to have already thought of this before me. Eelco Dolstra, the inventor of Nix, is one of its cofounders, so I'll be watching to see if Nix's adoption grows in that space over the next few years via their efforts. However, I personally would much prefer to see a growth in Nix's usage come from innovations brought about by its community, and not any single corporate entity, regardless who's a part of the corporation. Perhaps especially because of who's a part of the corporation.</p>
I quite hope that Nix grows, not just because I like the technology, but because I think that Nix solves a lot of the problems inherent to the way we currently use computers and I because I believe that using Nix will make things easier. I personally am itching to help it get to this point. I need to figure out a lot about the lnguage and how packaging works, but I have a few programs I'm hoping to help get on Nixpkgs and become a contributor. Getting to where I am with only 6 months of experience at the time of writing feels like an extremely good place to be, and I imagine 6 months from now I'll be well beyond where I want to be when it comes to Nix.</p>


00 Blogging
2025-12-12T00:00:00+00:00
I must admit this whole endeavor is a bit intimidating.</p>
I've only been writing consistently for about a year and a half now. Leading up to now, I've been trying to journal on a daily basis. Writing about myself and for myself has been an enlightening experience, which I treasure dearly. To be honest, I wouldn't have this perspective if it weren't for a writing class I took my first semester of college that changed how I viewed the actual writing process. It helped make me comfortable with the idea of writing as an actual process, as opposed to something you just do. Since then, I've beein toying with the idea of creating and publishing more long form content. This blog is an experiment and learning experience designed to do exactly that.</p>
Being an experiment, I expect a lot of what I do and how I go about it to change. I'm likely to tweak my text editor, neovim</a> to be more comfortable with writing long-form english language content. Having an autocomplete with suggested words would be quite nice, beyond the ones I do get as blink.cmp</a> scrambles to predict what I'm typing using what I've written elsewhere in the file. I may incorporate Obsidian</a> and turn this place into more of a 'digital garden'. Then again, I might simply migrate to a different static site generator besides Hugo</a> and stick with it till the day no one is left to speak time's name. I know that the only reason I'm not using Jekyll</a> is because of its Ruby-forged dependency hell.</p>
Expect this site to change often. That is a good thing. Publishing a new post is change. I will certainly tweak the colorscheme and the layout incrementally. As I become more comfortable with my workflow, I foresee this whole blogging thing to become a big part of my online activity, which would be desireable. Much better than doomscrolling. Until then, may the stars shine favorably on you, dear reader.</p>

59</td>	# Helps vendor 'core' so that all its dependencies can be found </span></td></tr>
60</td>	cargoVendorDir </span>=</span> </span>craneLib</span>.</span>vendorMultipleCargoDeps </span>{ </span></td></tr>
61</td>	</span>inherit </span>(</span>craneLib</span>.</span>findCargoFiles src</span>) </span>cargoConfigs</span>; </span></td></tr>
62</td>	</span>cargoLockList </span>= [ </span></td></tr>
63</td>	</span>./Cargo.lock </span></td></tr>
64</td>	</span>./toolchain/Cargo.lock </span></td></tr>
65</td>	]; </span></td></tr>
66</td>	}</span>;</span> </span></td></tr></tbody></table></code></pre> The goal is to make this automatic as a part of running `nix flake update</code>, or to just bite the bullet and just accept the IFD anyway. However, I like my builds to be completely pure, so it'll likely take me a while before I get a breakthrough with it.</p>` Conclusion</h2> Now that I've built this workflow, it's gonna be time to actually put it to the test and build some projects using it. While I get the IFD situation figured out, I'll also be looking to create the same workflow for the ESP32. However, since the chips I have aren't officially supported rustc</code> targets, I'll either be waiting for the gccrs</code> front-end to be completed, or more likely, have the Espresif-maintained forks of Rust and LLVM be merged upstream to use.</p> Resources I Used</h2> oxalica Rust overlay rust-bin cheatsheet</a></li> oxalica Rust overlay cross compilation examples</a></li> oxalica Rust overlay cross compilation docs</a></li> "Just a simple Nix Flake for Rust and WASM" by Gijs Burghoorn</a></li> The avr-none section of the rustc book</a></li> Cargo environment variables</a></li> avr-hal docmentation</a></li> Crane cross compilation docs</a></li> Crane build customization docs</a></li> </ul> 01 Nix and I 2025-12-17T00:00:00+00:00 My experience with Nix</h2> I've been daily driving NixOS on my laptop since June 2025. My previous laptop was running Windows 11, then Ubuntu when Windows decided to be Windows. After that system broke (I dropped it), I had to buy a new laptop and decided it was also time for me to go distro hopping. While I'd been happy on Ubuntu and knew it well, I also had one glaring issue: packages.</p> apt</code> isn't well known for having a bunch of fresh-off-the-PR-merge packages available to install. Ubuntu specifically also had me deal with the Snap store, which I didn't like at all. Why should I have to deal with an entirely separate marketplace just to get Firefox installed, especially one that sucked. Flatpak solved a few problems for me, but I didn't like the idea of having to add yet another package manager to my already convoluted system. Appimages frustrated me with how manual they were, especially for a program such as Discord which shipped updates frequently. Combined with an install of QT Design Studio I couldn't seem to get rid of, I no longer felt that I had a complete understanding and control of my system. The cord had become too tangled and Gordian in nature, and it had to be cut. Breaking my already failing little Hewlett-Packard was the blade to do so.</p> What introduced me to and sold me on NixOS was a video by No Boilerplate</a>, which adressed ever single one of the problems I'd been facing. Before that, I was considering using Arch, by the way, or perhaps one of its derivative distros like CachyOS or Manjaro. Learning that nixpkgs had not only more packages, but fresher ones at that than the AUR completely dwarfed the Nix learning curve I'd heard about. When my new Thinkpad T14 Gen 5 arrived, I spent about 10 total minutes in the pre-installed Windows environment solely to create an installer image for NixOS. I promptly washed my hands after the encounter.</p> Going straight to NixOS on baremetal actually seems to be a little uncommon now that I've spent more time in the community, so I'm quite proud that my experience was a good one. I was pretty quick to wrap my head around the basics of the Nix language and what my configuration.nix</code> was doing. Making use of a heavily modified version of 0atman</code>'s rebuild script was a lifesaver. Speeding up the time it took me to iterte through another Nix generation, even if it was just adding a few packages, made the whole experience lightyears better than what I'd been dealing with before.</p> Thoughts on Nix and its future</h2> I liked the guarantees presented by using NixOS, which I refer to as the "Nix Promises": Immutability, Reproducibility, Reliability, enough to get past the hurdle that is using Nix. Even though NixOS isn't truly</em> immutable by default, it gains a lot of the benefits from playing in that space via the /nix/store/</code> directory. The reproducibility hasn't been something I've used all that much yet, but I'm excited to explore it as soon as I get my hands on some more hardware. The reliability has been the biggest strength of choosing NixOS as my operating system, and it's something I think the community would do well to emphasize.</p> Like with my favorite programming language, Rust, I think the Nix community often forgets some of the tool's greatest strenghts that would help push adoption. Actually, I think that Rust and Nix are both facets of the same kind of object, and not just because of how big of an overlap in the userbase there is, or the fact that they work well together. Rust and Nix set out to solve a class of problems that can really mess things up by strictly enforcing and maintaining a certain amount of theoretical correctness that most don't really care about. The Rust borrow checker and packaging binaries with Nix both offer some overhead for their invariants that programmers just starting out with either often clash with. When speaking to people I know in person who haven't really interacted or heard of either, I often run into the shared question of "but why tho". And it's hard to answer! Why would someone bother with Rust and Nix when C++ and Ubuntu have served just fine. Nix has a big problem with lacking a clear raison d'être, which Rust does have. Yes Rust can be "blazingly fast", but other languages are often fast enough and easier for most applications that citing its speed as its main strength isn't enough. But if you want low-level performance, like C, that's memory safe without the overhead of a garbage collector, you use Rust. It's simple, it's clear, and it gives people the motivation to actually use Rust without relying on the intellectual curiosity many use to climb up the learning curve. It's why Rust is a permanent part of the Linux kernel, when no other language has ever been added after it was originally written in C. In the same way, other operating systems are "good enough" for most. NixOS is a minority within the minority that is Linux as a PC operating system. Even ignoring the fact that Windows and MacOS all dwarf Linux's numbers, there are plenty of alternatives that someone might choose instead of Nix: Ubuntu, Fedora, Arch. NixOS lacks the same "default choice" that Rust has, or at least the criteria that make it a default choice are too narrow. If one were only looking for the Nix Promises, like I was, well then Nix is</em> the obvious choice. However, the Nix Tradeoffs are something that I was willing to deal with in exchange for the Promises. That simply isn't true for everyone, and if Nix is going to grow its numbers and its ecosystem, it needs to be the best and hopefully only logical choice for a certain problem that people actually encounter, like Rust.</p> While thinking about its reliability, I realized that Nix is probably the best tool for "fire and forget" deployment for the space between general PCs and embedded systems that still needs to be user-customizable. Something where you really don't need to be doing much outside a specific usecase, but not so specific that you tailor and lock it down to one specific function as you do with an embedded system, and where it needs to work every single time. A kind of system where for whatever reason, you don't want it to ever break from a software bug. Update break your system at a critical time? Just roll back and deal with it when you're not depending on it. You get all of the benefit from the latest software, but you don't need to worry about your system breaking. As long as it works in your tests, it'll just work identically in production.</p> Admittedly, I think this is a pretty small use case. Besides a personal project of mine that is nowhere near finished enough to share details about, I'm having a hard time thinking of a usecase for such a system that isn't already filled in by some kind of embedded system. Servers and hosting for large companies are the only other one I can really think of, and Determinate Systems</a> seems to have already thought of this before me. Eelco Dolstra, the inventor of Nix, is one of its cofounders, so I'll be watching to see if Nix's adoption grows in that space over the next few years via their efforts. However, I personally would much prefer to see a growth in Nix's usage come from innovations brought about by its community, and not any single corporate entity, regardless who's a part of the corporation. Perhaps especially because of who's a part of the corporation.</p> I quite hope that Nix grows, not just because I like the technology, but because I think that Nix solves a lot of the problems inherent to the way we currently use computers and I because I believe that using Nix will make things easier. I personally am itching to help it get to this point. I need to figure out a lot about the lnguage and how packaging works, but I have a few programs I'm hoping to help get on Nixpkgs and become a contributor. Getting to where I am with only 6 months of experience at the time of writing feels like an extremely good place to be, and I imagine 6 months from now I'll be well beyond where I want to be when it comes to Nix.</p> 00 Blogging 2025-12-12T00:00:00+00:00 I must admit this whole endeavor is a bit intimidating.</p> I've only been writing consistently for about a year and a half now. Leading up to now, I've been trying to journal on a daily basis. Writing about myself and for myself has been an enlightening experience, which I treasure dearly. To be honest, I wouldn't have this perspective if it weren't for a writing class I took my first semester of college that changed how I viewed the actual writing process. It helped make me comfortable with the idea of writing as an actual process, as opposed to something you just do. Since then, I've beein toying with the idea of creating and publishing more long form content. This blog is an experiment and learning experience designed to do exactly that.</p> Being an experiment, I expect a lot of what I do and how I go about it to change. I'm likely to tweak my text editor, neovim</a> to be more comfortable with writing long-form english language content. Having an autocomplete with suggested words would be quite nice, beyond the ones I do get as blink.cmp</a> scrambles to predict what I'm typing using what I've written elsewhere in the file. I may incorporate Obsidian</a> and turn this place into more of a 'digital garden'. Then again, I might simply migrate to a different static site generator besides Hugo</a> and stick with it till the day no one is left to speak time's name. I know that the only reason I'm not using Jekyll</a> is because of its Ruby-forged dependency hell.</p> Expect this site to change often. That is a good thing. Publishing a new post is change. I will certainly tweak the colorscheme and the layout incrementally. As I become more comfortable with my workflow, I foresee this whole blogging thing to become a big part of my online activity, which would be desireable. Much better than doomscrolling. Until then, may the stars shine favorably on you, dear reader.</p>

Of The Stars

02 Embedded Rust Plus Nix, pt. 1

01 Nix and I

00 Blogging