3 ms·

> 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

> 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.

KingMachiavelli 4mo ago
> 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.
- xyzzy_plugh 4mo ago
  Using Nix of course. My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up"
  - bow_ 4mo ago
    > My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up" Those aren't necessarily oppposing points. NixOS is a declarative distro. It also happens to come with some defaults that, I assume, caters to the commonly expected use case (and maybe has some historical roots as well). NixOS is not a minimal, build-from-scratch distro. It's more opinionated than e.g. Arch. For example, it ships with firewall turned on by default (https://nixos.wiki/wiki/Firewall https://nixos.wiki/wiki/Firewall). Another example: the default list of packages is somehow Perl, rsync, and strace (https://search.nixos.org/options?channel=26.05&query=defaultPackages#show=option%253Aenvironment.defaultPackages https://search.nixos.org/options?channel=26.05&query=default...). Blanking this default to an empty list is IME harmless. The declarative nature is probably the subtext the author is trying to convey: what are the things one can do to disable these defaults, to reach a very minimal system (ISO really) that one can then build as one wishes.
  - nh2 4mo ago
    Seems to me that such boolean flags do not force you to think about "building up" or "building down". You just declare what _is_. Who cares what the default is? When you're building a minimal thing, changing some defaults is fine.
    - xyzzy_plugh 4mo ago
      As your sibling points out, it's not just about boolean flags: it's about the abstraction, which is opinionated. I posit that it is perhaps more laborious to untangle those abstractions than to just write your own. It's like improving the lighting in your house by going to the breaker panel and flipping breakers and splicing extension cables that you run up your stairs and down your halls.
  - Nullabillity 4mo ago
    I think NixOS itself could do a much better job here in terms of moving stuff from defaults into profiles. But yes, it'd also be nice to have something closer to dockerTools.streamLayeredImage.
isityettime 4mo ago
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.
- Chu4eeno 4mo ago
  Well, if someone wants a less painful method just install and run buildroot instead (and if you enjoy pain use yocto and bitbake).
  - isityettime 4mo ago
    For Nixers, this isn't painful; it's magical! :'D One of the great joys of NixOS is that configuration of existing features is continuous with development of new features. Both are just NixOS modules. In the same way, configuring your desktop is continuous with configuring a server is continuous with preparing a netboot image for an embedded device. If you know how to configure a NixOS desktop, you also know how to prepare your own custom NixOS install media. If you want it to, Nix can cure the stomach ache HCL gives you when you write Terraform. Nixpkgs is also the largest collection of packages in existence.¹ Anything you could want to throw into an image is likely already there. The author of the blog post is already a Nixpkgs/NixOS contributor, too, so they might also be thinking "some of the improvements I make in shrinking dependency closures or finding deeper ways to turn off certain features are potentially upstreamable". And even if the experiment is a wash, in exploring this kind of (ab)use of NixOS for generating tiny images, a NixOS user is also learning more about the dependency relations and other structure of the NixOS systems they're already running, which might be interesting or rewarding. I'm not saying that as a Nix enthusiast I'd never use Buildroot or Yocto, but I understand the appeal of exploring how far NixOS can be pushed for this and how easy or hard it is to do. While we're here we should also note that NixOS isn't really the Nix tool for this job anyway. There's a cool project called not-os² where minimization is one of the goals that has already succeeded in getting the image size down to < 50 MB. There's also a project targeting commodity wifi routers called Liminix, which likewise takes some NixOS ideas and uses them to produce teeny-tiny images, (presumably even smaller than not-os, given many of the target devices don't include so much as 50 MB of flash). -- 1: https://repology.org/repositories/statistics/nonunique https://repology.org/repositories/statistics/nonunique 2: https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os 3: https://www.liminix.org/ https://www.liminix.org/
brianjlogan 4mo ago
Pretty common method these days to build something just for the task at hand and consider deployment immutable requiring a new build of the ISO.
whateveracct 4mo ago
Yes? Because NixOS is configured by Nix code. But the user of the image itself doesn't need to run `nix`
lukeweston1234 4mo ago
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.
solarkraft 4mo ago
> build an image from scratch with the packages you want, composed in the way you want them That’s exactly what this does, elegantly

KingMachiavelli 4mo ago

> 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.

xyzzy_plugh 4mo ago
Using Nix of course. My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up"
- bow_ 4mo ago
  > My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up" Those aren't necessarily oppposing points. NixOS is a declarative distro. It also happens to come with some defaults that, I assume, caters to the commonly expected use case (and maybe has some historical roots as well). NixOS is not a minimal, build-from-scratch distro. It's more opinionated than e.g. Arch. For example, it ships with firewall turned on by default (https://nixos.wiki/wiki/Firewall https://nixos.wiki/wiki/Firewall). Another example: the default list of packages is somehow Perl, rsync, and strace (https://search.nixos.org/options?channel=26.05&query=defaultPackages#show=option%253Aenvironment.defaultPackages https://search.nixos.org/options?channel=26.05&query=default...). Blanking this default to an empty list is IME harmless. The declarative nature is probably the subtext the author is trying to convey: what are the things one can do to disable these defaults, to reach a very minimal system (ISO really) that one can then build as one wishes.
- nh2 4mo ago
  Seems to me that such boolean flags do not force you to think about "building up" or "building down". You just declare what _is_. Who cares what the default is? When you're building a minimal thing, changing some defaults is fine.
  - xyzzy_plugh 4mo ago
    As your sibling points out, it's not just about boolean flags: it's about the abstraction, which is opinionated. I posit that it is perhaps more laborious to untangle those abstractions than to just write your own. It's like improving the lighting in your house by going to the breaker panel and flipping breakers and splicing extension cables that you run up your stairs and down your halls.
- Nullabillity 4mo ago
  I think NixOS itself could do a much better job here in terms of moving stuff from defaults into profiles. But yes, it'd also be nice to have something closer to dockerTools.streamLayeredImage.

isityettime 4mo ago

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.

Chu4eeno 4mo ago
Well, if someone wants a less painful method just install and run buildroot instead (and if you enjoy pain use yocto and bitbake).
- isityettime 4mo ago
  For Nixers, this isn't painful; it's magical! :'D One of the great joys of NixOS is that configuration of existing features is continuous with development of new features. Both are just NixOS modules. In the same way, configuring your desktop is continuous with configuring a server is continuous with preparing a netboot image for an embedded device. If you know how to configure a NixOS desktop, you also know how to prepare your own custom NixOS install media. If you want it to, Nix can cure the stomach ache HCL gives you when you write Terraform. Nixpkgs is also the largest collection of packages in existence.¹ Anything you could want to throw into an image is likely already there. The author of the blog post is already a Nixpkgs/NixOS contributor, too, so they might also be thinking "some of the improvements I make in shrinking dependency closures or finding deeper ways to turn off certain features are potentially upstreamable". And even if the experiment is a wash, in exploring this kind of (ab)use of NixOS for generating tiny images, a NixOS user is also learning more about the dependency relations and other structure of the NixOS systems they're already running, which might be interesting or rewarding. I'm not saying that as a Nix enthusiast I'd never use Buildroot or Yocto, but I understand the appeal of exploring how far NixOS can be pushed for this and how easy or hard it is to do. While we're here we should also note that NixOS isn't really the Nix tool for this job anyway. There's a cool project called not-os² where minimization is one of the goals that has already succeeded in getting the image size down to < 50 MB. There's also a project targeting commodity wifi routers called Liminix, which likewise takes some NixOS ideas and uses them to produce teeny-tiny images, (presumably even smaller than not-os, given many of the target devices don't include so much as 50 MB of flash). -- 1: https://repology.org/repositories/statistics/nonunique https://repology.org/repositories/statistics/nonunique 2: https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os 3: https://www.liminix.org/ https://www.liminix.org/

brianjlogan 4mo ago

Pretty common method these days to build something just for the task at hand and consider deployment immutable requiring a new build of the ISO.

whateveracct 4mo ago

Yes? Because NixOS is configured by Nix code. But the user of the image itself doesn't need to run `nix`

lukeweston1234 4mo ago

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.

solarkraft 4mo ago

> build an image from scratch with the packages you want, composed in the way you want them That’s exactly what this does, elegantly