4 ms·

Yep. What nix adds is a declarative and reproducible way to build customized OS images to boot into.

by rictic 8mo ago

CuriouslyC 8mo ago
Nix is the best answer to "works on my machine," which is a problem I've seen at pretty much every place I've ever worked.
- 0x457 8mo ago
  It's also an answer to caching with /nix/store. I wish more cloud services supported "give me your nixosConfiguration or something similar" instead of providing api to build containers/vms imperatively. Dockerfile and everything that mimics it is my least favorite way to do this.
  - Cyph0n 8mo ago
    It’s fairly trivial to map your NixOS config into a VM image: https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebuild-build-image https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui... An alternative is to “infect” a VM running in whatever cloud and convert it into a NixOS VM in-place: https://github.com/nix-community/nixos-anywhere https://github.com/nix-community/nixos-anywhere In fact, it is a common practice to use the latter to install NixOS on new machines. You start off by booting into a live USB with SSH enabled, then use nixos-anywhere to install NixOS and partition disks via disko. Here is an example I used recently to provision a new gaming desktop: nix run github:nix-community/nixos-anywhere -- \ --flake .#myhost \ --target-host user@192.168.0.100 \ --generate-hardware-config nixos-generate-config ./hosts/myhost/hardware-configuration.nix At the end of this invocation, you end up with a NixOS machine running your config partitioned based on your disk config. My disko config in this case (ZFS pool with 1 disk vdev): https://gist.github.com/aksiksi/7fed39f17037e9ae82c043457ed29401 https://gist.github.com/aksiksi/7fed39f17037e9ae82c043457ed2...
    - pillbitsHQ 8mo ago
      [dead]
    - 0x457 8mo ago
      I know that part is easy, i just nix-anywhere just yesterday to reinstall one of my servers. It's not what I'm talking about.
      - Cyph0n 8mo ago
        Okay, so your idea is that cloud providers should make this even easier? $ nixos-rebuild build-image --flake .#myhost --image-variant amazon $ aws-cli image upload < result/images/image.ami $ aws-cli create vm --image={image}
        0x457 8mo ago
        Less about IaaS providers, more about PaaS providers that often abstract away image you're running and tell you "just run pip/apt/gem install whatever". Same with the CI platforms, instead of `setup-*` steps in GHA it could have just take flake in. Yes, I know I can build OCI image with nix, again, not the issue. My private CI runs on top of nix, all workers on the same host share /nix/store. My pipelines focused on running actual things rather than getting a worker ready to run things. If I didn't want output to be parsed by CI, I could have just reduced my pipeline to `nix flake check`. I share the exact same pipeline and worker image across multiple projects in multiple languages, all because everything is hidden behind devenv's tasks. When I switched project different rust and node versions, I didn't have to touch my CI at all. When I added a bunch of native deps that usually needed to be installed separately on GHA - again, didn't have to touch anything beyond my nix env once.
schmuhblaster 8mo ago
Or try this: https://github.com/deepclause/agentvm https://github.com/deepclause/agentvm, it's based on container2wasm, so the VM is fully defined by a Dockerfile.

Yep. What nix adds is a declarative and reproducible way to build customized OS images to boot into.

by rictic 8mo ago

Yep. What nix adds is a declarative and reproducible way to build customized OS images to boot into.

Nix is the best answer to "works on my machine," which is a problem I've seen at pretty much every place I've ever worked.

0x457 8mo ago
It's also an answer to caching with /nix/store. I wish more cloud services supported "give me your nixosConfiguration or something similar" instead of providing api to build containers/vms imperatively. Dockerfile and everything that mimics it is my least favorite way to do this.
- Cyph0n 8mo ago
  It’s fairly trivial to map your NixOS config into a VM image: https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebuild-build-image https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui... An alternative is to “infect” a VM running in whatever cloud and convert it into a NixOS VM in-place: https://github.com/nix-community/nixos-anywhere https://github.com/nix-community/nixos-anywhere In fact, it is a common practice to use the latter to install NixOS on new machines. You start off by booting into a live USB with SSH enabled, then use nixos-anywhere to install NixOS and partition disks via disko. Here is an example I used recently to provision a new gaming desktop: nix run github:nix-community/nixos-anywhere -- \ --flake .#myhost \ --target-host user@192.168.0.100 \ --generate-hardware-config nixos-generate-config ./hosts/myhost/hardware-configuration.nix At the end of this invocation, you end up with a NixOS machine running your config partitioned based on your disk config. My disko config in this case (ZFS pool with 1 disk vdev): https://gist.github.com/aksiksi/7fed39f17037e9ae82c043457ed29401 https://gist.github.com/aksiksi/7fed39f17037e9ae82c043457ed2...
  - pillbitsHQ 8mo ago
    [dead]
  - 0x457 8mo ago
    I know that part is easy, i just nix-anywhere just yesterday to reinstall one of my servers. It's not what I'm talking about.
    - Cyph0n 8mo ago
      Okay, so your idea is that cloud providers should make this even easier? $ nixos-rebuild build-image --flake .#myhost --image-variant amazon $ aws-cli image upload < result/images/image.ami $ aws-cli create vm --image={image}
      - 0x457 8mo ago
        Less about IaaS providers, more about PaaS providers that often abstract away image you're running and tell you "just run pip/apt/gem install whatever". Same with the CI platforms, instead of `setup-*` steps in GHA it could have just take flake in. Yes, I know I can build OCI image with nix, again, not the issue. My private CI runs on top of nix, all workers on the same host share /nix/store. My pipelines focused on running actual things rather than getting a worker ready to run things. If I didn't want output to be parsed by CI, I could have just reduced my pipeline to `nix flake check`. I share the exact same pipeline and worker image across multiple projects in multiple languages, all because everything is hidden behind devenv's tasks. When I switched project different rust and node versions, I didn't have to touch my CI at all. When I added a bunch of native deps that usually needed to be installed separately on GHA - again, didn't have to touch anything beyond my nix env once.

schmuhblaster 8mo ago

Or try this: https://github.com/deepclause/agentvm https://github.com/deepclause/agentvm, it's based on container2wasm, so the VM is fully defined by a Dockerfile.