6 ms·

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "vi

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user packages on any Linux or macOS. I've been sharing like 70% of my system config between Linux and macOS, and I don't know of any other tool that can do that. 4. Programmability: package definitions and config are extensible and composable. Yes, learning an ad hoc language to do this is a pain, but once I learned it I got a higher-level and better-abstracted way to define and combine packages than any other tool I've used. It's like going from C to OCaml. At this point I've started hating Dockerfiles because they can't easily be composed and don't provide any real facilities for abstraction. Ultimately, Nix took system management from feeling like an operational activity—maintaining and changing a bunch of mutable state to run the system—to declarative programming. Learning curve aside, making system management a reproducible programming activity with no system state to worry about has been a massive improvement.

dimsuz 5y ago
Whenever Nix/NixOS gets discussed I always see same points being brought up again and again. And again. I've never seen anything which is discussing solutions or the roadmap (however distant) to solve those issues. Can it be that nothing is happening in this regard or is that really so that people only list same cons over and over again? :)
- otabdeveloper4 5y ago
  It's like complaining about C++. It will always be there. Ignore it, it's just people venting about the fact that solving hard problems is hard.
mikepurvis 5y ago
"... with no system state to worry about" I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had to be carefully volumed-out with those data containers being protected and versioned and carried forward independent of the throwaway Dockerfile-defined "application" containers. So far my experience of NixOS is that it doesn't particularly offer a new solution here, but at least it doesn't pretend anything. The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home or /var, so that's on you to back up, migrate, whatever.
- tikhonj 5y ago
  That's true. I guess I see it as the difference between the system and what I'm doing with the system—it's like having a database system where I'd want the config for the database to be totally reproducible and immutable, but I'd expect to manage the data itself separately. And, as a practical benefit, I found setting up borg backups for /home on NixOS a lot easier than I expected :)
- throwamon 5y ago
  > The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager > or /var, so that's on you to back up, migrate, whatever. https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings https://github.com/nix-community/impermanence https://github.com/nix-community/impermanence
- tomberek 5y ago
  You can't get rid of all state. The pros/cons of a Nix approach is that it is far more explicit about what is pure/impure. This experience is similar to going from a dynamically typed language to a stronger type system; it can be frustrating to be told that something is not allowed. Nix's usability difficulties often come from trying to build or use software that violates purity in some way (reading HOME directories during compilation, using the network in some way, assuming a dependency will "just be there"); it prevents these mistakes at the cost of forcing the person doing the packaging to fix these issues. This is a huge benefit in the long-term, but can annoy short-term uses.
  - mikepurvis 5y ago
    Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105 https://github.com/pocoproject/poco/pull/3105
throwaway894345 5y ago
I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixpkgs is huge for those who don't know) for invocations to find the variable that gets passed into that function and then grepping around the repo for the function that produces that variable and so on until you get to the source type. Things have awful names and documentation is sparse. I'm a big believer in Nix as an abstract concept, but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences. I would think I'm doing something wrong, but so many people have corroborated my experiences and when I bring specific issues to experienced Nix users they also get stuck. Ultimately, I've reluctantly gone back to dealing with Docker and system package managers because their failure modes are rarer, more predictable, and more easily worked around. EDIT: and I haven’t touched on the problems associated with using Nix in an organization. It seems like invariably one or two people become “the Nix experts” and they become the bottleneck for the whole organization, every team needs to coordinate virtually every interesting activity with them, etc.
- utdemir 5y ago
  As someone who is using NixOS for 8+ years, I do agree with both your problems. (1) I do find that it's very rare having to implement a low level transitive dependency from scratch (most low-level system dependencies are already there, and for dependencies of a specific programming-language ecosystem you'd usually auto-generate them from things like `yarn2nix` or `poetry2nix`). However, I agree that once you need to do that for non-trivial library it quickly becomes painful and require intimate knowledge of both the build system and Nix environment. (2) This is my main issue. My workflow is also having a local `nixpkgs` clone, and go find the function and the parameters I can use every time I don't remember how to use it. I also think that it is sustainable. There are many exciting improvements going on with the new CLI, so hopefully we will get nicer error messages and better tooling support in near future. > but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences. There are pain points, but the advantages for me were indispensable. Being able to pin dependencies accurately, reproduce an exact development environment deterministically, and use the single language to define applications, configurations, and even entire system images is a great benefit that I would need to use 10+ tools with individual quirks otherwise.
mindslight 5y ago
I think your reasons are focused on Nix for package management. For NixOS specifically, I would add: 5. It's essentially a source distribution with caching. If you want to add say a kernel patch, or any other type of patch, it's straightforward. Whereas running Debian and finding the solution to some problem is building a modified package, my usual conclusion was just to bear the problem until it was fixed upstream, rather than suffer the maintenance burden. 6. The top-level config is front and center, and stateless. No messing about with update-initramfs, wondering what the heck the initrd is actually doing etc. 7. Taming the complexity of system software's configuration state. For example, there is no mucking with the systemd mess of /etc/systemd vs /lib/systemd and its assorted symlinks, as this configuration is handled at a higher level. And for Nix I'd add 8. Dead simple cross (or emulated) compilation toolchains. Building A Cross Compiler used to be a Big Deal, with Nix it's basically like any other declaration to build an entire cross/emulated environment.
- xorcist 5y ago
  Building packages from scratch for Debian can be a hairy endeavour, lots of tooling and it can be hard to know which one to use. But building packages for Debian is dead simple, it is literally one command. Adding a patch to an existing package, and then rebuilding it, is a common operation.
  - mindslight 5y ago
    I've run Debian for two decades, so I've definitely ended up going down the path more than a few times. Yes, the actual building process wasn't so hard. It was the maintenance burden afterwards. Maybe I just didn't commit hard enough with my own apt repo, pinning, staying ahead of what was coming through backports, etc. But point is that it effectively never stuck long term, the end result was always going back to vanilla upstream. Whereas in Nixos such patches are some lines in the larger config file, which feels a lot more persistently manageable.
kitsunesoba 5y ago
Did they ever fix the need to disable SIP for nix to work on macOS? That made trying it out a nonstarter when I looked into it 2 or 3 years ago.
- theptip 5y ago
  I hit similar issues a while ago, and I think they have this figured out now. The installer Just Works (tested on a MBP2015) as of a few months ago.
- takeda 5y ago
  I started using Nix around 3 years ago, and I actually didn't encounter this issue. The last issue was when Catalina made root read only, there is some hacking to keep /nix in the root. Edit: after searching about it, looks like this was the same issue with /nix in the root, and disabling SIP was one solution at the time. Currently the solution appears to be creating a separate volume and using /etc/fstab and /etc/synthetic.conf to set it up[1]. The installation script does it automatically. https://nixos.org/manual/nix/stable/installation/installing-binary.html#macos-installation-a-namesect-macos-installation-change-store-prefixaa-namesect-macos-installation-encrypted-volumeaa-namesect-macos-installation-symlinkaa-namesect-macos-installation-recommended-notesa https://nixos.org/manual/nix/stable/installation/installing-...
lallysingh 5y ago
The problems are twofold: 1. The language is a significant problem. If you get everything right, it will do what you want. That's the only nice thing I can say about it. Almost every error it will give you will be misleading. I haven't had such a hard time figuring out errors since early C++ template metaprogramming. And frankly, that was easier. It needs real diagnostics, and that frankly, that means it needs real types. But that won't happen. Too much of the informal type system of nix is "whatever keys that library function uses, go look in the source." 2. Half-implemented packages. Try walking out of the golden path on a package, without having to modify its nixpkgs entry. Between the two, it's more nerd-bait than usable platform.
- takeda 5y ago
  Looks like these things are being addressed, although from past of experience it probably will take several years :( (when I started using Nix, 3 years there was a talk about this new thing called flakes, now the version 2.4 already contains it, but it is still locked behind experimental features) 1. https://github.com/tweag/nickel https://github.com/tweag/nickel - it is a typed language, that might in the future replace nix language 2. looks like likely is addressed by flakes
  - klarkc 5y ago
    There is also https://github.com/purenix-org/purenix https://github.com/purenix-org/purenix
    - takeda 5y ago
      That's interesting, looks like it is transpiler that could be used immediately if someone doesn't mind the extra step. Thank you for sharing it. BTW: the Nickel has chance to end up replace Nix language as I saw author of Nix (Eelco) is also contributing to it. I don't think it can transpile to a nix code.
sandgiant 5y ago
This mirrors my (very limited) experiences with Nix. I've so far only dipped my toes in home manager, but being able to share shell config and cli tools declaratively between WSL, linux and MacOS with very little branching has been great!
amelius 5y ago
> Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. Does that mean we get downloadable precompiled binary packages too? If not, why not?
- southerntofu 5y ago
  my understanding is that most nix/guix users don't compile (most) packages themselves but download them from a binary cache. why not would be for obvious security reasons but at least on the guix side there's a subcommand to compare build hashes from various mirrors you trust: https://guix.gnu.org/manual/en/html_node/Invoking-guix-challenge.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
- tikhonj 5y ago
  Yep. The cool thing is that installing a binary version of a source package is totally transparent from Nix's point of view—it's not a different entity, it's solely a matter of caching. If you're building a package that somebody else built and uploaded to a cache that you can access, you'll download the binary instead. There's a public cache, so when you use a standard package set as your base, you'll be getting most things as binaries. But if you make some changes or something else breaks and binaries aren't available, it falls back to building from source transparently—sometimes this can take a loooong time, but it usually doesn't, and I'd rather have the option to do that than not :). The other bonus is that it takes very little effort to share your own binary cache—either privately (so that you or your company only need to build something once) or publicly (so that people installing your open source tool don't have to build from source). There's even a really well-designed commercial service called [Cachix][1] that provides a totally turn-key binary cache, including a free tier for open source projects. [1]: https://www.cachix.org/ https://www.cachix.org/
  - takeda 5y ago
    I use this for building system. Instead of Cachix I just set it up as an S3 bucket (it's a bit involving but also works). I needed to tweak some things but ultimately arrived to satisfying results. The nice thing is that it sped up building by 50% and also extra bonus with things is that with merges, if files didn't change nix will finish building instantaneously. This is similar with nix-shell, where for example with python you enter "virtualenv" like environment almost instantly without downloading dependencies over and over. Yes, you could get close to do that with CI by using some caching, but this is out of the box, due to nix understanding dependencies. Also another great thing is that so far, I never needed to purge cache, which often happens with normal CI caching.

dimsuz 5y ago

Whenever Nix/NixOS gets discussed I always see same points being brought up again and again. And again. I've never seen anything which is discussing solutions or the roadmap (however distant) to solve those issues. Can it be that nothing is happening in this regard or is that really so that people only list same cons over and over again? :)

otabdeveloper4 5y ago
It's like complaining about C++. It will always be there. Ignore it, it's just people venting about the fact that solving hard problems is hard.

mikepurvis 5y ago

"... with no system state to worry about" I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had to be carefully volumed-out with those data containers being protected and versioned and carried forward independent of the throwaway Dockerfile-defined "application" containers. So far my experience of NixOS is that it doesn't particularly offer a new solution here, but at least it doesn't pretend anything. The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home or /var, so that's on you to back up, migrate, whatever.

tikhonj 5y ago
That's true. I guess I see it as the difference between the system and what I'm doing with the system—it's like having a database system where I'd want the config for the database to be totally reproducible and immutable, but I'd expect to manage the data itself separately. And, as a practical benefit, I found setting up borg backups for /home on NixOS a lot easier than I expected :)
throwamon 5y ago
> The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager > or /var, so that's on you to back up, migrate, whatever. https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings https://github.com/nix-community/impermanence https://github.com/nix-community/impermanence
tomberek 5y ago
You can't get rid of all state. The pros/cons of a Nix approach is that it is far more explicit about what is pure/impure. This experience is similar to going from a dynamically typed language to a stronger type system; it can be frustrating to be told that something is not allowed. Nix's usability difficulties often come from trying to build or use software that violates purity in some way (reading HOME directories during compilation, using the network in some way, assuming a dependency will "just be there"); it prevents these mistakes at the cost of forcing the person doing the packaging to fix these issues. This is a huge benefit in the long-term, but can annoy short-term uses.
- mikepurvis 5y ago
  Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105 https://github.com/pocoproject/poco/pull/3105

throwaway894345 5y ago

I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixpkgs is huge for those who don't know) for invocations to find the variable that gets passed into that function and then grepping around the repo for the function that produces that variable and so on until you get to the source type. Things have awful names and documentation is sparse. I'm a big believer in Nix as an abstract concept, but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences. I would think I'm doing something wrong, but so many people have corroborated my experiences and when I bring specific issues to experienced Nix users they also get stuck. Ultimately, I've reluctantly gone back to dealing with Docker and system package managers because their failure modes are rarer, more predictable, and more easily worked around. EDIT: and I haven’t touched on the problems associated with using Nix in an organization. It seems like invariably one or two people become “the Nix experts” and they become the bottleneck for the whole organization, every team needs to coordinate virtually every interesting activity with them, etc.

utdemir 5y ago
As someone who is using NixOS for 8+ years, I do agree with both your problems. (1) I do find that it's very rare having to implement a low level transitive dependency from scratch (most low-level system dependencies are already there, and for dependencies of a specific programming-language ecosystem you'd usually auto-generate them from things like `yarn2nix` or `poetry2nix`). However, I agree that once you need to do that for non-trivial library it quickly becomes painful and require intimate knowledge of both the build system and Nix environment. (2) This is my main issue. My workflow is also having a local `nixpkgs` clone, and go find the function and the parameters I can use every time I don't remember how to use it. I also think that it is sustainable. There are many exciting improvements going on with the new CLI, so hopefully we will get nicer error messages and better tooling support in near future. > but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences. There are pain points, but the advantages for me were indispensable. Being able to pin dependencies accurately, reproduce an exact development environment deterministically, and use the single language to define applications, configurations, and even entire system images is a great benefit that I would need to use 10+ tools with individual quirks otherwise.

mindslight 5y ago

I think your reasons are focused on Nix for package management. For NixOS specifically, I would add: 5. It's essentially a source distribution with caching. If you want to add say a kernel patch, or any other type of patch, it's straightforward. Whereas running Debian and finding the solution to some problem is building a modified package, my usual conclusion was just to bear the problem until it was fixed upstream, rather than suffer the maintenance burden. 6. The top-level config is front and center, and stateless. No messing about with update-initramfs, wondering what the heck the initrd is actually doing etc. 7. Taming the complexity of system software's configuration state. For example, there is no mucking with the systemd mess of /etc/systemd vs /lib/systemd and its assorted symlinks, as this configuration is handled at a higher level. And for Nix I'd add 8. Dead simple cross (or emulated) compilation toolchains. Building A Cross Compiler used to be a Big Deal, with Nix it's basically like any other declaration to build an entire cross/emulated environment.

xorcist 5y ago
Building packages from scratch for Debian can be a hairy endeavour, lots of tooling and it can be hard to know which one to use. But building packages for Debian is dead simple, it is literally one command. Adding a patch to an existing package, and then rebuilding it, is a common operation.
- mindslight 5y ago
  I've run Debian for two decades, so I've definitely ended up going down the path more than a few times. Yes, the actual building process wasn't so hard. It was the maintenance burden afterwards. Maybe I just didn't commit hard enough with my own apt repo, pinning, staying ahead of what was coming through backports, etc. But point is that it effectively never stuck long term, the end result was always going back to vanilla upstream. Whereas in Nixos such patches are some lines in the larger config file, which feels a lot more persistently manageable.

kitsunesoba 5y ago

Did they ever fix the need to disable SIP for nix to work on macOS? That made trying it out a nonstarter when I looked into it 2 or 3 years ago.

theptip 5y ago
I hit similar issues a while ago, and I think they have this figured out now. The installer Just Works (tested on a MBP2015) as of a few months ago.
takeda 5y ago
I started using Nix around 3 years ago, and I actually didn't encounter this issue. The last issue was when Catalina made root read only, there is some hacking to keep /nix in the root. Edit: after searching about it, looks like this was the same issue with /nix in the root, and disabling SIP was one solution at the time. Currently the solution appears to be creating a separate volume and using /etc/fstab and /etc/synthetic.conf to set it up[1]. The installation script does it automatically. https://nixos.org/manual/nix/stable/installation/installing-binary.html#macos-installation-a-namesect-macos-installation-change-store-prefixaa-namesect-macos-installation-encrypted-volumeaa-namesect-macos-installation-symlinkaa-namesect-macos-installation-recommended-notesa https://nixos.org/manual/nix/stable/installation/installing-...

lallysingh 5y ago

The problems are twofold: 1. The language is a significant problem. If you get everything right, it will do what you want. That's the only nice thing I can say about it. Almost every error it will give you will be misleading. I haven't had such a hard time figuring out errors since early C++ template metaprogramming. And frankly, that was easier. It needs real diagnostics, and that frankly, that means it needs real types. But that won't happen. Too much of the informal type system of nix is "whatever keys that library function uses, go look in the source." 2. Half-implemented packages. Try walking out of the golden path on a package, without having to modify its nixpkgs entry. Between the two, it's more nerd-bait than usable platform.

takeda 5y ago
Looks like these things are being addressed, although from past of experience it probably will take several years :( (when I started using Nix, 3 years there was a talk about this new thing called flakes, now the version 2.4 already contains it, but it is still locked behind experimental features) 1. https://github.com/tweag/nickel https://github.com/tweag/nickel - it is a typed language, that might in the future replace nix language 2. looks like likely is addressed by flakes
- klarkc 5y ago
  There is also https://github.com/purenix-org/purenix https://github.com/purenix-org/purenix
  - takeda 5y ago
    That's interesting, looks like it is transpiler that could be used immediately if someone doesn't mind the extra step. Thank you for sharing it. BTW: the Nickel has chance to end up replace Nix language as I saw author of Nix (Eelco) is also contributing to it. I don't think it can transpile to a nix code.

sandgiant 5y ago

This mirrors my (very limited) experiences with Nix. I've so far only dipped my toes in home manager, but being able to share shell config and cli tools declaratively between WSL, linux and MacOS with very little branching has been great!

amelius 5y ago

> Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. Does that mean we get downloadable precompiled binary packages too? If not, why not?

southerntofu 5y ago
my understanding is that most nix/guix users don't compile (most) packages themselves but download them from a binary cache. why not would be for obvious security reasons but at least on the guix side there's a subcommand to compare build hashes from various mirrors you trust: https://guix.gnu.org/manual/en/html_node/Invoking-guix-challenge.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
tikhonj 5y ago
Yep. The cool thing is that installing a binary version of a source package is totally transparent from Nix's point of view—it's not a different entity, it's solely a matter of caching. If you're building a package that somebody else built and uploaded to a cache that you can access, you'll download the binary instead. There's a public cache, so when you use a standard package set as your base, you'll be getting most things as binaries. But if you make some changes or something else breaks and binaries aren't available, it falls back to building from source transparently—sometimes this can take a loooong time, but it usually doesn't, and I'd rather have the option to do that than not :). The other bonus is that it takes very little effort to share your own binary cache—either privately (so that you or your company only need to build something once) or publicly (so that people installing your open source tool don't have to build from source). There's even a really well-designed commercial service called [Cachix][1] that provides a totally turn-key binary cache, including a free tier for open source projects. [1]: https://www.cachix.org/ https://www.cachix.org/
- takeda 5y ago
  I use this for building system. Instead of Cachix I just set it up as an S3 bucket (it's a bit involving but also works). I needed to tweak some things but ultimately arrived to satisfying results. The nice thing is that it sped up building by 50% and also extra bonus with things is that with merges, if files didn't change nix will finish building instantaneously. This is similar with nix-shell, where for example with python you enter "virtualenv" like environment almost instantly without downloading dependencies over and over. Yes, you could get close to do that with CI by using some caching, but this is out of the box, due to nix understanding dependencies. Also another great thing is that so far, I never needed to purge cache, which often happens with normal CI caching.