5 ms·

I have recently adopted Nix and NixOS and it's been truly fantastic. It does have a really harsh learning curve though. Big downsides, but for me the upsides ar

I have recently adopted Nix and NixOS and it's been truly fantastic. It does have a really harsh learning curve though. Big downsides, but for me the upsides are so huge that it's worth it. I had been incrementally building this complex workflow using mkosi. At some point I sat down with a pencil and asked myself "ok, what am I building here, what's the ideal endgame?" I sketched out the system I wanted and pondered it for a bit... And then went "wait, have I just described NixOS?" And yeah basically it's exactly what I wanted and more. Funnily enough, this article is _exactly_ what I need as I haven't exactly figured out the best way to install NixOS on a totally blank machine. (So far I have been muddling through what's described in the "Manual installation" section and, yeah it sucks). The exception is for Raspberry Pi where it's straightforward to just build an SD card image from a flake. I had _guessed_ that something like the "Building your own installer" section would work, but because of the nature of Nix I never really feel 100% confident that something is gonna work as I hope until I physically try it. Usually it does. But still, this is a very big downside of Nix!

secure 1y ago
Glad to hear that the article describes exactly what you need :) Try out building an installer and run it in a VM, it only takes a few minutes!
7bit 1y ago
I dtarted my Linux journey 3 weeks ago with Arch and Ansible to create a declarative system. The installing-part however was tricky, because I have a second disk with Windows and I want to use secure boot. And if I wanted to use Ansible, I would have to create a specific ISO. And then I would have to manually define the disk I want to use or run into the risk of formatting the wrong one and lose a lot of data. Then I found NixOS, which is like Ansible, but better, because Ansible only adds information to a system, but NixOS also ensures that anything that is not declared is removed as well. After three weeks, I realized that the effort to declaratively (or automate an imperstively) install the OS is such a lot of work that does not pay off if you're not going to install multiple systems each week or month. How many commands does it take to actually install NixOS? You partition the disk which take 3 commands. Then you format it, which takes 3 commands. Then you mount the disks, which takes 3 commands. Then you install it, download your configuration and apply it, which is another 2-3 commands. It takes 5 minutes vs whatever effort you put into creating a declarative installer and keeping that up to date. I also had to think of the time it would cost me to actually figure out HOW a declarative installation would work and the tools I would require. I reckon that the first 24 system would essentially be free (opposed to the 2 hours or so it would cost me to figure out declarative OS installations). I decided that for me, it is not worth it, although I am the type of personality that just hates not automating things.
- secure 1y ago
  Welcome to Linux! I agree that through the lens of “how much time do you save?”, automating a NixOS installation is not worth it. As you describe, it’s just a few interactive commands in the upstream installer. But from the perspective of “how much effort is it to spin up a new VM for this new project / task?”, spending the extra few minutes on building the fully automated installation path is well worth it. Also consider the perspective of “how many steps does it take to recover this VM in a disaster scenario?”, where reducing the manual steps to a minimum is very helpful. BTW, the maintenance of the installer is virtually free: The configuration I show is the configuration I use in NixOS as well, so that needs to be updated anyway. Aside from that, to rebase my installer from NixOS 24.11 to NixOS 25.05, I just changed a number. When setting up a new machine, I can either download the upstream installer and write it to a USB stick, or I can change a number, rebuild (< 2 minutes) and write to a USB stick. Really not much difference.
- jorvi 1y ago
  Declarative management of your OS is in terms of effort basically an inversion of imperative management. With declarative, you frontload an enormous amount of effort: - You have to learn your declarative framework - Then you have to slowly build your configuration base, or copy someone else's and figure out why they did what. - Then you have to figure out workarounds for things that aren't natively managed declaratively. - Then you start writing your own little helper functions and modularize things. At this point, it starts getting very smooth. From there on, adding another package or another machine is very very easy, basically adding a few lines of code. And now your system is mostly reproducible, putting you far ahead of an imperative configuration. Compared to that, doing it imperatively you can just sort of do your thing and roll with it. This let's you do whatever you aim to achieve very quickly, but as time goes on you have to juggle so many balls in terms of tracking and remembering what you configured / what state your config is in that it quickly becomes impossible. Declarative OS management really sticks once you accept that the first few weeks are gonna suck and the first few months are still gonna have friction. But once you get over the hump, the rewards are there to reap.
  - SkiFire13 1y ago
amelius 1y ago
> It does have a really harsh learning curve though. Would it be possible to automatically translate all Nix build scripts into a language that is more ergonomic and fun to work with?
- huimang 1y ago
  The learning curve isn't due to the language, and personally I find writing nix files to be much more pleasant than any other build system I've worked with, and most languages that I've worked with.
  - mikepurvis 1y ago
    Absolutely this. Everyone fixates on the language but the hard part is really the packaging ecosystem and how-do-I-X type questions where Nix has ten answers that are all better than what Debian or Arch can do, but it's not obvious which is the best between them or how they compare. See things like Python packaging, how to make ISOs/installers/containers, how to override a scope, how to maintain a dev environment, how to do package testing, how to set up your own CI with caching and binary delivery, etc.
    - zxexz 1y ago
      Yea, IME the best manual for nixos/nixpkgs is the repo and the manual for git, grep etc. I clone or save every public repo or article or whatnot i find that helps me or seems interesting. These two examples come to mind: the page that made what the config/options system really is [0], and the post that really drive home to me it’s all just configs! A config language all the way down! [1] [0] https://nlewo.github.io/nixos-manual-sphinx/development/replace-modules.xml.html https://nlewo.github.io/nixos-manual-sphinx/development/repl... [1] https://astrid.tech/2022/11/03/0/overlay-nixpkgs-pr/ https://astrid.tech/2022/11/03/0/overlay-nixpkgs-pr/
      - mikepurvis 1y ago
        Yeah, and that's obviously pretty hostile when the best guide is reading the source. I think the deeper problem that maybe isn't always considered in the "Nix needs better docs" discourse is that there are many tasks that simply don't have an optimal workflow in Nix (yet). It can be weird documenting how do some particular thing, but having to frontload that doc with a bunch of caveats about which particular set of tradeoffs the suggested approach is embracing. For example with Python, a huge one is around how much you want to leverage the Python packages already in nixpkgs. If you want to use them, which makes sense if you don't really care about versions or you've got a lot of things with tie-ins to non-Python such as bindings packages, then you probably want the conventional buildPythonPackage workflow, where you manually package any missing deps, perhaps assisted by pip2nix: https://wiki.nixos.org/wiki/Python https://wiki.nixos.org/wiki/Python But if you have a self-contained app that already has everything locked and you just want minimum friction, then you almost certainly want uv2nix: https://github.com/pyproject-nix https://github.com/pyproject-nix A lot of things in Nix are like this. Same story with containers where you've got dockerTools.buildImage but depending on your workflow nix2container is almost certainly the better choice. Nix's limitations around IFD are finally being addressed by https://tvix.dev/ https://tvix.dev/ but that's a rewrite and brings yet another potential split. Nix is the epitome of being perpetually stuck in the 1000 flowers blooming [1] state of things, and in some ways that's beautiful, but it needs people to build a cathedral or two within the bazaar. Determinate [2] is trying, but they've also taken some heat from the community for concerns around OSS and governance. [1]: https://news.ycombinator.com/item?id=10294833 https://news.ycombinator.com/item?id=10294833 / https://gigamonkeys.com/flowers/ https://gigamonkeys.com/flowers/ [2]: https://determinate.systems/ https://determinate.systems/
diggan 1y ago
> I never really feel 100% confident that something is gonna work as I hope until I physically try it I ended up in the same situation too, but discovered relatively quickly that NixOS makes it really easy to build clean VMs from your config that you can run and test against, then when validated, you apply the configuration to the actual hardware. I'm doing this for all my servers managed with NixOS right now, and managed to prevent multiple issues being deployed, including something that would prevent a clean boot and since the host is headless, would have required me to connect monitor and keyboard in order to recover. Really glad NixOS is setup the way it is, although you're right the learning curve is rough. At least I can easily re-install my infrastructure really trivially, which helps me sleep at night.
- zxexz 1y ago
  I’m using that exact feature for a blue/green/another color deploy setup, it’s very nice. The server with the hosted application builds a vm of itself, run some checks. Route traffic to (RR). If it’s all good, send the VM to a secondary house and route to there. On the primary, reboot (usually kexec). Switch back over. Should probably just be using a persistent but this is some pretty heterogenous hardware and…it works
- bjackman 1y ago
  Yeah I make extensive use of this and it's absolutely fantastic. I can write a config, very quickly check it seems correct on a QEMU guest, and then deploy "the same" config to a physical host (slower to boot, harder to debug, annoying to power cycle) and be highly confident it's gonna behave like the VM did. This is incredibly valuable! But by "hard to know if it's gonna work" I was talking more about architecture-level concerns. Not "is my Nix code correct" but "is this thing I'm envisaging a thing that the ecosystem supports?" I usually just have to sit down and try coding it up, and there's always an element of uncertainty about whether I'll succeed. Whereas if I sit down to get something done in Ansible I don't really have any such doubts. (But the result will be dramatically worse).
  - tlavoie 1y ago
    Regarding how a bunch of the pieces go together, I found this blog post from Shopify quite useful: https://shopify.engineering/what-is-nix https://shopify.engineering/what-is-nix
Jhsto 1y ago
Another option is to run it ephemerally from the RAM. I have been doing this for my laptop and servers for years now. You can do so by declaring the following: https://github.com/ponkila/HomestakerOS/blob/main/nixosModules/base/flake.nix#L30-L158 https://github.com/ponkila/HomestakerOS/blob/main/nixosModul... You need to then have a flake which defines a "package" like this: https://github.com/jhvst/nix-config/blob/main/flake.nix#L117-L119 https://github.com/jhvst/nix-config/blob/main/flake.nix#L117... Now you can run 'nix build .#starlabs' which will create you the files needed for kexec / PXE booting. You can also write tests that these images actually boot ok: https://discourse.nixos.org/t/nixostest-with-flake-configurations/11542/8 https://discourse.nixos.org/t/nixostest-with-flake-configura... I started working on this stuff because I needed to somehow reliably update my homeserver. I live abroad 50 weeks a year, so I needed something reliable because I can't assume I have physical access to the computer. Even when the BMC firmware got screwed by ASRock motherboard firmware, I didn't need to sweat. Now for the shameless plug: my company created a PXE server module which also supports flakes that assumes this ephemeral setup. It's described in here: https://github.com/majbacka-labs/nixos.fi https://github.com/majbacka-labs/nixos.fi
- bjackman 1y ago
  Ah yes this also looks fantastic and something I intend to try. At $work we have insane platforms that are extremely hostile to platform development but they do support a (obviously annoyingly custom and limited) PXE-like thing and I'm hoping I can boot NixOS via that and just never even touch the disk (which is full of insane custom $work platform bullshit).
femiagbabiaka 1y ago
> I had _guessed_ that something like the "Building your own installer" section would work, but because of the nature of Nix I never really feel 100% confident that something is gonna work as I hope until I physically try it. Usually it does. One of the most underrated features of Nix imo is the testing story. You absolutely can be confident that something will work! https://nixcademy.com/posts/nixos-integration-tests/ https://nixcademy.com/posts/nixos-integration-tests/
- bjackman 1y ago
  Yea I agree on that front. But I don't mean "it's hard to write correct Nix configs" I mean that without a lot of experience it's hard to design a Nix system in your head and know whether the design is naturally supported by the ecosystem or if you're kinda going off into uncharted territory. It's usually pretty easy to try stuff and I really like the way once you have learned something, you can't ever really forget it because everything is code. I know lots of things say "it's config-as-code!" but very few do hermeticity as well as Nix. In that regard it has some of the benefits of monorepo life, without needing an actual monorepo.
FireBeyond 1y ago
> I have recently adopted Nix and NixOS and it's been truly fantastic. It does have a really harsh learning curve though. Big downsides, but for me the upsides are so huge that it's worth it. It's huge. I tried learning and exploring Nix Darwin. Went through at least half a dozen blog posts with "step by step" instructions. All different. All had some fatal error at some point even on a new install of macOS that was from moderate to impossible to find coherent help on.
- s0l1dsnak3123 1y ago
  I started with Nix darwin, and it's definitely buggier and less well supported compared to nix-proper. I'd recommend trying out building a NixOS VM for a better introduction to Nix.

secure 1y ago

Glad to hear that the article describes exactly what you need :) Try out building an installer and run it in a VM, it only takes a few minutes!

7bit 1y ago

I dtarted my Linux journey 3 weeks ago with Arch and Ansible to create a declarative system. The installing-part however was tricky, because I have a second disk with Windows and I want to use secure boot. And if I wanted to use Ansible, I would have to create a specific ISO. And then I would have to manually define the disk I want to use or run into the risk of formatting the wrong one and lose a lot of data. Then I found NixOS, which is like Ansible, but better, because Ansible only adds information to a system, but NixOS also ensures that anything that is not declared is removed as well. After three weeks, I realized that the effort to declaratively (or automate an imperstively) install the OS is such a lot of work that does not pay off if you're not going to install multiple systems each week or month. How many commands does it take to actually install NixOS? You partition the disk which take 3 commands. Then you format it, which takes 3 commands. Then you mount the disks, which takes 3 commands. Then you install it, download your configuration and apply it, which is another 2-3 commands. It takes 5 minutes vs whatever effort you put into creating a declarative installer and keeping that up to date. I also had to think of the time it would cost me to actually figure out HOW a declarative installation would work and the tools I would require. I reckon that the first 24 system would essentially be free (opposed to the 2 hours or so it would cost me to figure out declarative OS installations). I decided that for me, it is not worth it, although I am the type of personality that just hates not automating things.

secure 1y ago
Welcome to Linux! I agree that through the lens of “how much time do you save?”, automating a NixOS installation is not worth it. As you describe, it’s just a few interactive commands in the upstream installer. But from the perspective of “how much effort is it to spin up a new VM for this new project / task?”, spending the extra few minutes on building the fully automated installation path is well worth it. Also consider the perspective of “how many steps does it take to recover this VM in a disaster scenario?”, where reducing the manual steps to a minimum is very helpful. BTW, the maintenance of the installer is virtually free: The configuration I show is the configuration I use in NixOS as well, so that needs to be updated anyway. Aside from that, to rebase my installer from NixOS 24.11 to NixOS 25.05, I just changed a number. When setting up a new machine, I can either download the upstream installer and write it to a USB stick, or I can change a number, rebuild (< 2 minutes) and write to a USB stick. Really not much difference.
jorvi 1y ago
Declarative management of your OS is in terms of effort basically an inversion of imperative management. With declarative, you frontload an enormous amount of effort: - You have to learn your declarative framework - Then you have to slowly build your configuration base, or copy someone else's and figure out why they did what. - Then you have to figure out workarounds for things that aren't natively managed declaratively. - Then you start writing your own little helper functions and modularize things. At this point, it starts getting very smooth. From there on, adding another package or another machine is very very easy, basically adding a few lines of code. And now your system is mostly reproducible, putting you far ahead of an imperative configuration. Compared to that, doing it imperatively you can just sort of do your thing and roll with it. This let's you do whatever you aim to achieve very quickly, but as time goes on you have to juggle so many balls in terms of tracking and remembering what you configured / what state your config is in that it quickly becomes impossible. Declarative OS management really sticks once you accept that the first few weeks are gonna suck and the first few months are still gonna have friction. But once you get over the hump, the rewards are there to reap.
- SkiFire13 1y ago

amelius 1y ago

> It does have a really harsh learning curve though. Would it be possible to automatically translate all Nix build scripts into a language that is more ergonomic and fun to work with?

huimang 1y ago
The learning curve isn't due to the language, and personally I find writing nix files to be much more pleasant than any other build system I've worked with, and most languages that I've worked with.
- mikepurvis 1y ago
  Absolutely this. Everyone fixates on the language but the hard part is really the packaging ecosystem and how-do-I-X type questions where Nix has ten answers that are all better than what Debian or Arch can do, but it's not obvious which is the best between them or how they compare. See things like Python packaging, how to make ISOs/installers/containers, how to override a scope, how to maintain a dev environment, how to do package testing, how to set up your own CI with caching and binary delivery, etc.
  - zxexz 1y ago
    Yea, IME the best manual for nixos/nixpkgs is the repo and the manual for git, grep etc. I clone or save every public repo or article or whatnot i find that helps me or seems interesting. These two examples come to mind: the page that made what the config/options system really is [0], and the post that really drive home to me it’s all just configs! A config language all the way down! [1] [0] https://nlewo.github.io/nixos-manual-sphinx/development/replace-modules.xml.html https://nlewo.github.io/nixos-manual-sphinx/development/repl... [1] https://astrid.tech/2022/11/03/0/overlay-nixpkgs-pr/ https://astrid.tech/2022/11/03/0/overlay-nixpkgs-pr/
    - mikepurvis 1y ago
      Yeah, and that's obviously pretty hostile when the best guide is reading the source. I think the deeper problem that maybe isn't always considered in the "Nix needs better docs" discourse is that there are many tasks that simply don't have an optimal workflow in Nix (yet). It can be weird documenting how do some particular thing, but having to frontload that doc with a bunch of caveats about which particular set of tradeoffs the suggested approach is embracing. For example with Python, a huge one is around how much you want to leverage the Python packages already in nixpkgs. If you want to use them, which makes sense if you don't really care about versions or you've got a lot of things with tie-ins to non-Python such as bindings packages, then you probably want the conventional buildPythonPackage workflow, where you manually package any missing deps, perhaps assisted by pip2nix: https://wiki.nixos.org/wiki/Python https://wiki.nixos.org/wiki/Python But if you have a self-contained app that already has everything locked and you just want minimum friction, then you almost certainly want uv2nix: https://github.com/pyproject-nix https://github.com/pyproject-nix A lot of things in Nix are like this. Same story with containers where you've got dockerTools.buildImage but depending on your workflow nix2container is almost certainly the better choice. Nix's limitations around IFD are finally being addressed by https://tvix.dev/ https://tvix.dev/ but that's a rewrite and brings yet another potential split. Nix is the epitome of being perpetually stuck in the 1000 flowers blooming [1] state of things, and in some ways that's beautiful, but it needs people to build a cathedral or two within the bazaar. Determinate [2] is trying, but they've also taken some heat from the community for concerns around OSS and governance. [1]: https://news.ycombinator.com/item?id=10294833 https://news.ycombinator.com/item?id=10294833 / https://gigamonkeys.com/flowers/ https://gigamonkeys.com/flowers/ [2]: https://determinate.systems/ https://determinate.systems/

diggan 1y ago

> I never really feel 100% confident that something is gonna work as I hope until I physically try it I ended up in the same situation too, but discovered relatively quickly that NixOS makes it really easy to build clean VMs from your config that you can run and test against, then when validated, you apply the configuration to the actual hardware. I'm doing this for all my servers managed with NixOS right now, and managed to prevent multiple issues being deployed, including something that would prevent a clean boot and since the host is headless, would have required me to connect monitor and keyboard in order to recover. Really glad NixOS is setup the way it is, although you're right the learning curve is rough. At least I can easily re-install my infrastructure really trivially, which helps me sleep at night.

zxexz 1y ago
I’m using that exact feature for a blue/green/another color deploy setup, it’s very nice. The server with the hosted application builds a vm of itself, run some checks. Route traffic to (RR). If it’s all good, send the VM to a secondary house and route to there. On the primary, reboot (usually kexec). Switch back over. Should probably just be using a persistent but this is some pretty heterogenous hardware and…it works
bjackman 1y ago
Yeah I make extensive use of this and it's absolutely fantastic. I can write a config, very quickly check it seems correct on a QEMU guest, and then deploy "the same" config to a physical host (slower to boot, harder to debug, annoying to power cycle) and be highly confident it's gonna behave like the VM did. This is incredibly valuable! But by "hard to know if it's gonna work" I was talking more about architecture-level concerns. Not "is my Nix code correct" but "is this thing I'm envisaging a thing that the ecosystem supports?" I usually just have to sit down and try coding it up, and there's always an element of uncertainty about whether I'll succeed. Whereas if I sit down to get something done in Ansible I don't really have any such doubts. (But the result will be dramatically worse).
- tlavoie 1y ago
  Regarding how a bunch of the pieces go together, I found this blog post from Shopify quite useful: https://shopify.engineering/what-is-nix https://shopify.engineering/what-is-nix

Jhsto 1y ago

Another option is to run it ephemerally from the RAM. I have been doing this for my laptop and servers for years now. You can do so by declaring the following: https://github.com/ponkila/HomestakerOS/blob/main/nixosModules/base/flake.nix#L30-L158 https://github.com/ponkila/HomestakerOS/blob/main/nixosModul... You need to then have a flake which defines a "package" like this: https://github.com/jhvst/nix-config/blob/main/flake.nix#L117-L119 https://github.com/jhvst/nix-config/blob/main/flake.nix#L117... Now you can run 'nix build .#starlabs' which will create you the files needed for kexec / PXE booting. You can also write tests that these images actually boot ok: https://discourse.nixos.org/t/nixostest-with-flake-configurations/11542/8 https://discourse.nixos.org/t/nixostest-with-flake-configura... I started working on this stuff because I needed to somehow reliably update my homeserver. I live abroad 50 weeks a year, so I needed something reliable because I can't assume I have physical access to the computer. Even when the BMC firmware got screwed by ASRock motherboard firmware, I didn't need to sweat. Now for the shameless plug: my company created a PXE server module which also supports flakes that assumes this ephemeral setup. It's described in here: https://github.com/majbacka-labs/nixos.fi https://github.com/majbacka-labs/nixos.fi

bjackman 1y ago
Ah yes this also looks fantastic and something I intend to try. At $work we have insane platforms that are extremely hostile to platform development but they do support a (obviously annoyingly custom and limited) PXE-like thing and I'm hoping I can boot NixOS via that and just never even touch the disk (which is full of insane custom $work platform bullshit).

femiagbabiaka 1y ago

> I had _guessed_ that something like the "Building your own installer" section would work, but because of the nature of Nix I never really feel 100% confident that something is gonna work as I hope until I physically try it. Usually it does. One of the most underrated features of Nix imo is the testing story. You absolutely can be confident that something will work! https://nixcademy.com/posts/nixos-integration-tests/ https://nixcademy.com/posts/nixos-integration-tests/

bjackman 1y ago
Yea I agree on that front. But I don't mean "it's hard to write correct Nix configs" I mean that without a lot of experience it's hard to design a Nix system in your head and know whether the design is naturally supported by the ecosystem or if you're kinda going off into uncharted territory. It's usually pretty easy to try stuff and I really like the way once you have learned something, you can't ever really forget it because everything is code. I know lots of things say "it's config-as-code!" but very few do hermeticity as well as Nix. In that regard it has some of the benefits of monorepo life, without needing an actual monorepo.

FireBeyond 1y ago

> I have recently adopted Nix and NixOS and it's been truly fantastic. It does have a really harsh learning curve though. Big downsides, but for me the upsides are so huge that it's worth it. It's huge. I tried learning and exploring Nix Darwin. Went through at least half a dozen blog posts with "step by step" instructions. All different. All had some fatal error at some point even on a new install of macOS that was from moderate to impossible to find coherent help on.

s0l1dsnak3123 1y ago
I started with Nix darwin, and it's definitely buggier and less well supported compared to nix-proper. I'd recommend trying out building a NixOS VM for a better introduction to Nix.