Femtodata

Technology Should be for Freedom

2026-01-20T00:00:00+00:00

Open source technology for freedom of choice </blockquote>
I'm not saying technology should be free; even in open source, people need to be paid somehow. But, technology should be used for furthering freedom.
Instead, technology seems increasingly designed and deployed to force us into the same compromises. In a way, the tension between freedom of choice and forced compromise is a natural one -- market economics incentivize vertical integration and horizontal expansion, even as new startups and services take a stab at widening the market or finding lucrative niches.
Regulatory capture</a> turns this tension into this dystopia where best practice dictates technology choices that trade our freedom for increasing corporate control, income disparity, centralized vulnerability, and general societal malaise:

Your emails / browser activity / photos probably belong to a company which has made generative AI a cornerstone of its existence.</li>
Video monitoring of your private property, nominally for your use, feeds corporate surveillance which can be accessed by / sold to government agencies (ring</a>), or maybe everyone (eufy</a>).</li>
Centralized backend dependencies expose your personal and professional data to singular, large surface areas of service interruption and attack (aws</a>, crowdstrike</a>)</li>
Social media platforms that were started or marketed as communal spaces, become increasingly directed by corporate / political ownership.</li> </ul>
There are alternatives. Gamers are actually trying Linux, finally fed up with the unstable, ad-ridden, AI-crammed monstrosity that Windows has become. Open source alternatives to big-tech are self-hostable. Servers can be built and colocated at datacenters. "The cloud" really is just "someone else's computer" -- may as well make it yours.
I want to offer some of these alternatives, or at least make them more widely known. Contact</a> me for more info on Femtodata services</a>.

ZFS-on-root on Nixos: Working Multiple EFI Partitions

2025-11-17T00:00:00+00:00

NixOS specialisations for EFI partition redundancy </blockquote>
tldr; Multiple efi partitions are possible to complement zfs-on-root, with nofail</code> filesystem options and specialisations to handle drive failure.
DISCLAIMER: There's probably a smarter way to do this, I am not an expert in any of the following topics.
edit 2025-11-17: rsync instead of cp to avoid orphaning generations in efi partitions, also removing extraneous generationsDir.copyKernels</code>; thanks @ElvishJerricco</a> for pointing this out
Initial Setup</h1> My server's storage setup is a single zfs-on-root pool, 2x2 with a hot spare. I wanted to try zfs on root, instead of the perhaps standard solid state boot / system drive and zfs for storage, for maximum survivability. Instead of a single /boot</code> efi partition, each drive contributes its own boot partition, mounted to /boot/efis/efi1</code>, /boot/efis/ef2</code>, ..., /boot/efis/efi5</code>. My config has this snippet (cribbed from this thread</a>): boot = { loader = { systemd-boot = { enable = true; extraInstallCommands = '' ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi1/ /boot/efis/efi2 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi1/ /boot/efis/efi3 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi1/ /boot/efis/efi4 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi1/ /boot/efis/efi5 ''; }; # systemd-boot efi = { canTouchEfiVariables = true; efiSysMountPoint = "/boot/efis/efi1"; }; # efi }; # loader # kernelPackages = config.boot.zfs.package.latestCompatibleLinuxPackages; }; </code></pre> And relevant filesystem config as detected by nixos-generate-config</code>: fileSystems."/boot/efis/efi1" = { device = "/dev/disk/by-uuid/41D1-D66C"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" ]; }; fileSystems."/boot/efis/efi2" = { device = "/dev/disk/by-uuid/41D2-DAE6"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" ]; }; fileSystems."/boot/efis/efi3" = { device = "/dev/disk/by-uuid/41D3-FEA1"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" ]; }; fileSystems."/boot/efis/efi4" = { device = "/dev/disk/by-uuid/41D5-0933"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" ]; }; fileSystems."/boot/efis/efi5" = { device = "/dev/disk/by-uuid/41D6-53CC"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" ]; }; </code></pre> This was my first server, kinda YOLO'd and figured it would work. Can you spot the problem(s)? Missing filesystem -> boot to emergency mode</h1> If systemd-boot can't find one of those efi partitions, it kicks you out to emergency mode, which, if you don't have a root password set up, is completely unworkable unless you do SYSTEMD_SULOGIN_FORCE=1</code> in kernel params. It also starts with no networking, which is a problem for my server, colo'd at a datacenter some distance away from home. Note that the system actually will boot, as long as one of the efi partitions is around. But you get stuck in emergency mode after waiting 1.5 minutes for a failed mount. I was comfortable with setting all of these to nofail</code>; if enough drives were dead that the pool was inoperable, I'd have bigger problems. So, they now look something like fileSystems."/boot/efis/efi1" = { device = "/dev/disk/by-uuid/41D1-D66C"; fsType = "vfat"; options = [ "fmask=0022" "dmask=0022" "nofail" ]; }; ... </code></pre> We're still not done though... Missing efiSysMountPoint -> problems with nixos-rebuild</h1> As it stands, if the drive with boot/efis/efi1</code> goes down, I can't do nixos-rebuild</code>, I think because there's nothing at the current boot.loader.efi.efiSysMountPoint</code> -- the error is that no previous version of systemd-boot can be found. My fix is a set of specialisations</a> that specify the other efi partitions as efiSysMountPoint</code> -- for good measure they also attempt to copy the bootloader to the other efi partitions as appropriate: specialisation = { efi2.configuration = { system.nixos.tags = [ "efi2" ]; boot.loader = { systemd-boot.extraInstallCommands = lib.mkForce '' ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi2/ /boot/efis/efi1 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi2/ /boot/efis/efi3 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi2/ /boot/efis/efi4 ${pkgs.rsync}/bin/rsync -a --delete /boot/efis/efi2/ /boot/efis/efi5 ''; efi.efiSysMountPoint = lib.mkForce "/boot/efis/efi2"; }; }; ... }; </code></pre> We can use nixos-rebuild</code> with the --specialisation</code> argument to use an alternate efi partition and get out of our pickle. When I get back to the datacenter I may try to actually pull a drive and test this, for now I've verified on a libvirt vm and five qcow2 files to simulate the pool.
Neovim via Nixos (but not too much) 2025-08-01T00:00:00+00:00 Thinner wrappers, impure symlinks </blockquote> neovim-with-plugins.nix</a> is a neovim-wrapper heavily inspired by @viperML's blog post</a></li> symlink.nix</a> is a very basic symlinking mechanism that allows for nix-based (copied to /nix/store, immutable) and regular filesystem (symlinked from wherever, impure) sources, heavily inspired by (and borrowing code from) @jade's blog post</a></li> </ul> I've been using nixpkgs' programs.neovim</code> module happily for a while now, with an init.lua</code> packaged as a plugin, for nice lua editing experience. However, the edit / build / debug iteration cycle of this setup is quite slow. Overall, this kind of wrapper feels quite "thick"; which can be a benefit, as mentioned by @fzakaria 's post</a>', since you're pushing a whole executable and configuration as a program. I wanted something halfway in between, using nixpkgs' vimPlugin infrastructure, but supplying my own ~/.config/nvim</code> for config. @viperML had a great post</a> on writing your own neovim wrapper, from which I borrowed heavily in writing neovim-with-plugins</a>. It's basically a thinner wrapper, you give it a list of vimPlugins you want included in the wrapped packpath; not-yet-packaged vimPlugins can be defined witih vimUtils.buildVimPlugin</code>: # nvim-config.nix { pkgs, ... }: { environment.variables = { EDITOR = "nvim"; }; programs.neovim-with-plugins = { enable = true; startPlugins = with pkgs.vimPlugins; let vim-godot = pkgs.vimUtils.buildVimPlugin { name = "vim-godot"; src = pkgs.fetchFromGitHub { owner = "habamax"; repo = "vim-godot"; rev = "1c8385789f7f4558bdbbf6e75033b34b4727944b"; sha256 = "sha256-uqe954fyDK5d5D+Tm/iDLXHfxFYO7BiLdQYyS4UGFMs="; # sha256-uqe954fyDK5d5D+Tm/iDLXHfxFYO7BiLdQYyS4UGFMs= }; }; in [ nvim-treesitter.withAllGrammars telescope-nvim vim-godot ]; }; } </code></pre> For config, I took inspiration (and the bash script) from @jade 's post</a> on supplying configs through non-nix means. symlink.nix</a> is a very basic symlinking mechanism that allows for nix-based (copied to /nix/store, immutable) and regular filesystem (symlinked from wherever, impure) sources. I use it this way to symlink directly from my nixos config repo checkout to ~/.config/nvim</code>; changes take effect immediately, and are checked in / pulled along with the nixos configuration repo: { services.symlink = { enable = true; entries = { "/home/alexou/.config/nvim" = { sourcePathImpure = "/home/alexou/dev/amp/nix_hosts/self/modules/config/nvim"; }; }; }; } </code></pre> For my servers where I don't have a full checkout of my nixos repo, I would do something similar but with sourcePath</code>, which would copy nvim/</code> into /nix/store</code> and link it to ~/.config/nvim</code>, as home-manager.file</code> would do: { services.symlink = { enable = true; entries = { "/home/deploy_user/.config/nvim" = { sourcePath = ./nvim; }; }; }; } </code></pre> Some caveats: For neovim python, I copied what nixpkgs' programs.neovim</code> does for python -- wrap a pythonEnv that has pynvim. But as I wasn't generating the config in nix, I have to set it manually in init.lua</code>: vim.g.python3_host_prog = '/run/current-system/sw/bin/nvim-python3' </code></pre> Could not for the life of me figure out how to properly escape the single quotes to set it in the wrapper. I would also not recommend using my flake and importing these modules -- they're small enough that you can just read and write your own versions. Or better yet, go read the blog posts linked above, they're better and more original. docker-compose.nix 2025-05-14T00:00:00+00:00 docker-compose ergonomics in NixOS config </blockquote> docker-compose.nix</a> enables nix-defined or imported docker-compose.yml</code> services with secrets (e.g., sops-nix</a>) integration and optional systemd service. Nixos has decent support for containers (see oci-containers</a>), and ideally you package the app and write a nixos module to go full native, but sometimes a project's preferred distribution and installation method is by docker-compose. docker-compose.nix</a> is like a halfway point; in its most basic usage, you provide a docker-compose.yml</code> and it gets copied to /var/lib/[service-name]</code> . You can either start it yourself with docker-compose up -d</code>, or you can enable a systemd service to do it for you. I used to do this via home-manager's home.file</code> directive, then I wrote this for my systems that don't really need home-manager. Secrets</h1> Docker itself has support for secrets provided by environment variables or interpolation; this module provides some additional wiring to that effect. If envSubstFile</code> is provided, then any VAR=VALUE</code> definition found therein will be used to replace $VAR</code> found in docker-compose.yml</code> with VALUE</code>. The same substitution is done for files provided by additionalFiles</code>; the use case here is where a docker-compose definition mounts a separate config file as a volume, and that config format does not allow for environment variable usage for secrets. Example: frigate</h1> An example for a combined frigate</a> and frigate-notify</a> service definition, both of which actually do allow for environment variables for passwords, but for purposes of demonstration: # frigate.nix { config, ... }: { sops.secrets.frigate-env = {}; services.docker-compose = { enable = true; services = { frigate = { composeFile = ./docker-compose.yml; envSubstFile = config.sops.secrets.frigate-env.path; additionalFiles = [ ./config-frigate.yml ./config-notify.yml ]; }; }; }; } </code></pre> sops.secrets.frigate-env</code> is a multi-line yaml definition: frigate-env: | FRIGATE_MQTT_PASSWORD=asdfasdfasdfasdf FRIGATE_NOTIFY_MQTT_PASSWORD=asdfasdfasdfasdf FRIGATE_NOTIFY_NTFY_TOKEN=asdfasdfasdfasdf </code></pre> In docker-compose.yml</code>, note volume mappings of config-frigate.yml</code> and config-notify.yml</code>, which are included in the nix config up above. The relevant lines in docker-compose: # docker-compose.yml services: frigate: image: ghcr.io/blakeblackshear/frigate:stable volumes: - ./config-frigate.yml:/config/config.yml frigate-notify: image: ghcr.io/0x2142/frigate-notify:latest volumes: - ./config-notify.yml:/app/config.yml </code></pre> Relevant parts of the config files: # config-frigate.yml ... mqtt: user: frigate password: $FRIGATE_MQTT_PASSWORD ... </code></pre> # config-notify.yml ... mqtt: username: frigate-notify password: $FRIGATE_NOTIFY_MQTT_PASSWORD ... </code></pre> You can specify a secrets file in env_file</a> attribute of docker-compose -- the documentation says the path is relative but in my experience it can also be absolute. If I had gone that route, then I'd probably do # docker-compose.yml services: frigate: env_file: /run/secrets/frigate-env frigate-notify: env_file: /run/secrets/frigate-env </code></pre> with the appropriate adjustments to the env var names. Good luck! switch-fix.nix 2025-05-06T00:00:00+00:00 Dead man's switch for nixos-rebuild boot / switch </blockquote> tldr; switch-fix.nix</a> lets you set an automatic rollback to current generation / profile on nixos-rebuild [switch | boot]</code> unless you cancel with cancel-rollback</code> from a terminal within a set amount of time Have you ever been messing with the network config of a nixos install on a physical machine you don't have physical access to, and started sweating bullets wondering if a nixos-rebuild was going to come back up? (There's another blog post in here about why bare-metal at a colo datacenter is way better than a cloud provider, hopefully I'll get to that in the future.) (Also up ahead should be how I do remote bare-metal installs with a custom iso via tailscale / headscale and safe ACLs.) This comes up if I manage an on-prem bare-metal install for a client, particularly one that has some more involved networking -- perhaps a vm host with bridged networking for vm guests. switch-fix.nix</a> is a set of commands to handle this situation; you set-rollback</code> before you do your nixos-rebuild switch</code> or nixos-rebuild boot</code> (probably the latter, I like to make sure it comes back up after a full reboot). This links the target of /run/current-system</code> to a rollback directory. A systemd service checks for this rollback directory and link on sysinit.target</code> (instead of multi-user.target</code> because maybe it never gets there with whatever garbage I made of the new config); if it's found, then a configurable timer starts counting down. Unless cancel-rollback</code> is called before the timer is up, then the systemd service sets the stored profile via switch-to-configuration boot</code>, and restarts the system. The way I usually use it is, I'll first nix build</code> the target profile on my build machine, then nix copy</code> the resulting closure to the target machine. I ssh into the target machine, set-rollback</code>, then nixos-rebuild --target-host [target machine] boot</code> from the build machine. I manually trigger a reboot, then ping the target till it comes back up. Once it's up, I ssh [target-machine] cancel-rollback</code>, then check to see if it succeeded or broke. If that sounds a bit too manual... yeah, probably. I haven't gotten around to bundling this into a proper program, and rely a bit on really good tmux / fzf integration plus ridiculous zsh command history. Before this, I used deploy-rs</a>. At the time, at least, I couldn't get it to do rollbacks on boot</code>, only on switch</code>, and sometimes the latter would still be wonky. (This is also why the module is switch-fix</code>, and I found that I would have to do a manual nix-env</code> call after deploy to make sure things stuck -- this is probably fixed by now.) Maybe that project has gotten more features and stability, probably worth looking at. In looking at the code for the first time in some years, I realize there could be many improvements; maybe an actual systemd timer instead of sleep</code>, using wall</code> is sometimes flaky, etc. But, seems to get the job done. When I have time I'll do some more testing to make sure functionality is there, but this one is something I use on a pretty regular basis. Good luck!