Re:I can haz smoller NixOS ISOs?
by craftkiller on Saturday June 20, 2026 @11:44PM
(#48615480)
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.
Re:I can haz smoller NixOS ISOs?
by khuedoan on Sunday June 21, 2026 @01:59AM
(#48616067)
Curious bout your use case for building all software from source, is it because you're worried about the supply chain since nixpkgs builds don't have reproducibility guarantee?
Re:I can haz smoller NixOS ISOs?
by craftkiller on Sunday June 21, 2026 @09:57AM
(#48619050)
I was already building the vast majority of it from source because I enable CPU optimizations for the specific microarchitecture in the machine (nixpkgs.hostPlatform.gcc.arch and nixpkgs.hostPlatform.gcc.tune), so once I learned about the risk of supply chain attack on the nix cache, disabling it entirely was a pretty small change.
So far, I'd say the biggest negative (aside from the build times that I was already experiencing due to the optimizations) is that GNU savannah will temporarily IP ban you when you download too much from them. For example, building the grub that is used for the ISOs downloads like 70+ patches from GNU Savannah which frequently triggers the IP ban.
Re:I can haz smoller NixOS ISOs?
by craftkiller on Friday June 26, 2026 @12:04PM
(#48688220)
One suggestion for improving the cache's posture: Give each dedicated builder machine a TPM. On each builder, generate a TPM-backed signing key. Only use those TPM-backed keys for signing packages that end up in the cache. That way we'd ensure that signed packages _must_ have been built on the dedicated build machines (due to the TPM) rather than potentially uploaded from a compromised developer machine using a compromised signing key.
It seems the current situation is there is a single signing key that has been in use since 2015 which implies that key is not tied to specific hardware and therefore could be leaked/exfiltrated/copied: https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774...
Re:I can haz smoller NixOS ISOs?
by chickensong on Saturday June 27, 2026 @05:51AM
(#48696743)
A reasonable suggestion, for any code signing system really. We need all the help we can get these days.
Have you measured the gains from your source-based approach? I was into Gentoo for tuning a long time ago when hardware wasn't as powerful, but I hadn't considered optimizing at that level with nix.
Re:I can haz smoller NixOS ISOs?
by funcDropShadow on Wednesday June 24, 2026 @03:36AM
(#48656491)
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.
Re:I can haz smoller NixOS ISOs?
by nh2 on Wednesday June 24, 2026 @05:53PM
(#48666064)
Note that's somewhat out of date:
> `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.
Re:I can haz smoller NixOS ISOs?
by tfrancisl on Friday June 26, 2026 @10:55AM
(#48687384)
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.
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.
So far, I'd say the biggest negative (aside from the build times that I was already experiencing due to the optimizations) is that GNU savannah will temporarily IP ban you when you download too much from them. For example, building the grub that is used for the ISOs downloads like 70+ patches from GNU Savannah which frequently triggers the IP ban.
Building from stage1 with customized CFLAGS was all the rage then…
Do you not trust hydra, the infra hosts, the people, all of it? What could be done to improve the cache's posture?
It seems the current situation is there is a single signing key that has been in use since 2015 which implies that key is not tied to specific hardware and therefore could be leaked/exfiltrated/copied: https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774...
Have you measured the gains from your source-based approach? I was into Gentoo for tuning a long time ago when hardware wasn't as powerful, but I hadn't considered optimizing at that level with nix.
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