That's how I manage all of my virtual machines: building an ISO from a NixOS config and booting it as a virtual machine. I'm going to take some time to see what bits of this I can copy to slim down my ISOs.
One additional benefit: I build all my software from source (by disabling the nix cache) so stripping out these extra programs will not only slim down my ISOs but it will also reduce the build time.
You could manage those VMs with https://microvm-nix.github.io/microvm.nix/ that helps with mounting the nix store read only from the host into the vm. That should save more space than trying to reduce the dependencies of the system closure of the vm.
> `bin/switch-to-configuration` is a Perl script from the beginning
Since NixOS 24.11 the default is `switch-to-configuration-ng`, in Rust. That is a 2.8 MB binary, compared to NixOS's 55 MB Perl distribution. Thus such Perl-less systems shrunk that dependency by 20x regarding activation switching.
There is a project by a group of nix/nixos enthusiasts aiming to replace some of these core deps https://github.com/manic-systems/nixos-core. I havent tire-kicked it much, but it seems useful.
What's most amazing is how easy it is to switch kernels on NixOS as this article touched on. This prompted me to switch to Cachy kernels, and after some caching delay (apparently need to switch once before caches set) I was able to take advantage of a completely different OS's core strength. Truly the one OS to rule them all.
> we should be able to disable shipping Nix entirely, by setting nix.enable = false.
It was at this point I began to question the entire exercise. If you don't want nix to even be installed, do you really want NixOS at all?
It would probably be much simpler to just build an image from scratch with the packages you want, composed in the way you want them, rather than contort the NixOS "UX" to produce the image you want.
I disagree, I can reuse my entire tool-chain that I develop on, easily package things, get the whole reproducibility, integration tests, blah blah, and make an image for maybe an embedded or net-booted image that I would prefer be smaller. Especially if I have no intention of tinkering or rebuilding things on the final prod target. Much more reproducible and easily portable than say a giant folder of alpha-numeric bash scripts, installation scripts, etc.
I got a bootable NixOS iso down to 91 MB. Pointed Claude at the Nixpkgs repo and asked it to strip things aggressively and inspect the build closure iteratively.
i'm doing this using nix2container and a rust program that generates a landlock filter so i can mount nix store and only the supplied derivates are visible :)
coming to you in a few month, tix.im
tbh, this is the most powerful computer program I have ever seen. Working on this now for over 6 month, ~600k LOC. I think it will grow to 800k in the base package. Unfortunately, uncompromised security requires quite some LOC.
This works:
tix workflow submit ../vx-maintainer/workflows/change-management/default.nix --follow -- --feature-branch="feat/2lines" --instructions="tui overview should show running flows in 2 lines. 2 line: running steps, done, failed, etc. reports counter: info/success/failed/warning/error sparkle line with load ... . then if extended by double click, each running step has a line. what step, memory, cpu usage, token counters, ... subgraphs should be rendered under the parent flow. Title should always show that subgraph. details has link to parent " --source-repo=/home/poelzi/Projects/tix/tixim --implementor=opencode\#gpt-5.5
I get a human gate after the plan is finished where I can give feedback (in this workflow). And then another gate when everything is done. 4 different models, multiple harnesses, multiple reviews, rest cases etc. :)
It makes me so smile watching the workflow progress. And the shit becomes global in a few days...
22 comments
[ 3.2 ms ] story [ 54.5 ms ] threadOne additional benefit: I build all my software from source (by disabling the nix cache) so stripping out these extra programs will not only slim down my ISOs but it will also reduce the build time.
Here's another good article on the topic
It's unfortunate that Perl and Python are core deps, as well as Bash
> `bin/switch-to-configuration` is a Perl script from the beginning
Since NixOS 24.11 the default is `switch-to-configuration-ng`, in Rust. That is a 2.8 MB binary, compared to NixOS's 55 MB Perl distribution. Thus such Perl-less systems shrunk that dependency by 20x regarding activation switching.
And since NixOS 25.11, `nixos-rebuild-ng` in Python replaces its former Perl counterpart, see https://wiki.nixos.org/wiki/Nixos-rebuild
Of all the things to get nixpilled over, this isn't one.
It was at this point I began to question the entire exercise. If you don't want nix to even be installed, do you really want NixOS at all?
It would probably be much simpler to just build an image from scratch with the packages you want, composed in the way you want them, rather than contort the NixOS "UX" to produce the image you want.
That’s exactly what this does, elegantly
But the resulting ISO:
- has no network
- can't switch configurations
- doesn't have a text editor
https://gist.github.com/siraben/a8fce9912891d85e1ec3cf74081b...
tbh, this is the most powerful computer program I have ever seen. Working on this now for over 6 month, ~600k LOC. I think it will grow to 800k in the base package. Unfortunately, uncompromised security requires quite some LOC.
This works: tix workflow submit ../vx-maintainer/workflows/change-management/default.nix --follow -- --feature-branch="feat/2lines" --instructions="tui overview should show running flows in 2 lines. 2 line: running steps, done, failed, etc. reports counter: info/success/failed/warning/error sparkle line with load ... . then if extended by double click, each running step has a line. what step, memory, cpu usage, token counters, ... subgraphs should be rendered under the parent flow. Title should always show that subgraph. details has link to parent " --source-repo=/home/poelzi/Projects/tix/tixim --implementor=opencode\#gpt-5.5
I get a human gate after the plan is finished where I can give feedback (in this workflow). And then another gate when everything is done. 4 different models, multiple harnesses, multiple reviews, rest cases etc. :) It makes me so smile watching the workflow progress. And the shit becomes global in a few days...
Why are we talking in fake childish speak?