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.
Nah this kind of thing is pretty common for servers or little embedded computers. If you're always building the image on some other machine, there's no compelling reason to include that binary or it's dependency closure on the system.
Typically someone who goes for this indeed likes and runs "full fat" NixOS on some systems. What they want is to get really small images for some special purpose, like containers or disk images for a puny old Raspberry Pi, and build them using their usual NixOS workstation or server or whatever.
> build an image from scratch with the packages you want
Using what? Using NixOS to configure a system is orthogonal to the system actually running the Nix binary. Nix/Nixpkgs provide well maintained package derivations and module configuration for the largest amount of software of any ecosystem. IMO it's far simpler than Yocto or Buildroot or the dozen OCI container builder ecosystems that go in and out of favor.
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.
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?
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.
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.
Nah this kind of thing is pretty common for servers or little embedded computers. If you're always building the image on some other machine, there's no compelling reason to include that binary or it's dependency closure on the system.
Typically someone who goes for this indeed likes and runs "full fat" NixOS on some systems. What they want is to get really small images for some special purpose, like containers or disk images for a puny old Raspberry Pi, and build them using their usual NixOS workstation or server or whatever.
> build an image from scratch with the packages you want
Using what? Using NixOS to configure a system is orthogonal to the system actually running the Nix binary. Nix/Nixpkgs provide well maintained package derivations and module configuration for the largest amount of software of any ecosystem. IMO it's far simpler than Yocto or Buildroot or the dozen OCI container builder ecosystems that go in and out of favor.
Hey, thanks, nice adventure! I will have a look. I'm trying to ditch Arch for NixOS and I'm starting from Distrobox probably. Super useful!
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.
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?
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.
https://sidhion.com/blog/nixos_server_issues/
Here's another good article on the topic
It's unfortunate that Perl and Python are core deps, as well as Bash