8 ms·

It's kind of a mess. Nix is a collection of tools and systems that together form a highly reproducible build system. Nix is also a declarative, largely pure a

by tel 6y ago

It's kind of a mess. Nix is a collection of tools and systems that together form a highly reproducible build system. Nix is also a declarative, largely pure and lazy programming language that you use to design and specify the different build outputs for the Nix build system. Nixpkgs is, more or less, the only project written using Nix (and a lot of shell). It's a collection of many thousands of "derivations", many of the things you'd expect to be able to fetch from brew or apt. Each derivation encodes the steps to use Nix (the build system) to construct that output. NixOS is a Linux distribution built atop Nix, Nix, and Nixpkgs. The basic claim to fame here is "totally declarative system setup" where you write all of the configuration for your system in Nix, using Nixpkgs and some other NixOS specific tooling and libraries, and then "build" the entire system with high repeatability. Then there are a few other related projects such as Hydra (a CI server and binary cache builder—most of the time you don't build with Nix, just download the proper thing from the cache) and NixOps (an extension to NixOS which provisions whole fleets of servers declaratively). Finally, you don't need to run NixOS in order to benefit from Nix. Nix and Nixpkgs are (largely) compatible with MacOS and Linux. That means you can install Nix onto your existing MacOS or Linux system and use it a lot like you'd use brew or apt. That said, the premiere Nix experience is always NixOS.

mehrdadn 6y ago
Thanks! So let's say I start installing Nix packages. What distro's packages would they end up most similar to? Say, maybe Arch (which mostly leaves things unmodified)? Does that mean you basically end up with Arch no matter which distro you're on?
- catern 6y ago
  Trying to put it politely, but your question seems a bit confused. Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages. There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages. But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.
  - mehrdadn 6y ago
    Thanks for explaining. I'm (obviously, I thought) not suggesting distros are only about the patches, but patches are a very significant aspect of their raisons d'être to me. I thought most distro maintainers do things like backporting changes though, for security/stability/etc.? Including RedHat, Canonical, the Debian maintainers, etc.? Arch (and I guess Gentoo, and maybe their derivatives like Manjaro) are the only ones I know that minimize upstream package changes. With other popular distros like Fedora, Ubuntu, SUSE, etc. I fully expect they've made custom modifications to some popular packages, but it's been years since I've touched other flavors. You're saying this is wrong and only Debian derivatives tend to do this?
    - catern 6y ago
      Fedora stays close to upstream: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro... Ubuntu is a Debian derivative, they patch things heavily, just like Debian. SUSE, I don't know about their policy. I assume they're like RHEL, which starts from Fedora, which is close to upstream, and then backports bugfixes from later versions on to stable branches. Many distros maintain stable branches and just update the packages on that branch when they have security issues. Backporting security fixes has (somewhat) gone out of favor, because backports executed by package maintainers that weren't familiar with the code have caused serious security issues in the past. Of course, distros like RHEL and (I guess) SUSE still do backport security fixes to their stable branches. But they start from a base which is close to upstream - it just diverges more and more as their stable branch gets older and older.
- tel 6y ago
  In addition to other answers, I think it's important to note that Nix is comparatively very small (but growing!). To that end, the Nixpkgs policies are still in flux and defined somewhat culturally (at least compared to older, larger distros). There's a release schedule for NixPkgs which is being continuously updated, you mostly subscribe to a fixed "channel" which gives you the default set of derivations. If you need something more fresh then you either modify a derivation yourself (hot-patching the distro) or pull something temporarily from master on NixPkgs. This is hugely facilitated by the way Nix allows you to install multiple package versions in parallel without conflict. Finally, Nix is still sometimes a bit of a research project. The "best" way to manage a distro that's being built using this technology is still being uncovered. For instance, there's an upcoming feature (flakes) which hopes to seriously change the way you talk about and consider versions of NixPkgs and NixOS. Using Nix definitely requires some patience with living on the edge of tech. It can be frustrating and less reliable than other repos due both to the bigger challenge of building a repo using Nix's technology and the smaller contributor base. That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything.
  - takeda 6y ago
    > That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything. It simply delivers what docker was promising to deliver.
- chpatrick 6y ago
  In my experience, nixpkgs packages are modified with the bare minimum to get the upstream code to work.
- takeda 6y ago
  GuixSD? Only because Guix was build from Nix. Frankly I don't think there's anything else like it. I don't know Arch enough to compare, but there's something also similar to Gentoo, except Nix knows that if source + dependencies + architecture + configuration is the same it will pull compiled version from cache, if something changes it will recompile it. The killer NixOS feature is that it has a single configuration file that's declarative which you can use to describe your OS, so it has something like salt/ansible/chef/puppet built in, and unlike them it's also is truly declarative. For example if you have package installed, to remove it, you just remove it from the list, where in those tools you need to create a state that ensures the package must not be present. Edit: from other comments I see that you meant that packages in arch are not modified, I guess Nix does follow that and only add patches if it absolutely needs them to make application work correctly, but unlike other distros nix also allows user trivially (ignoring the steep curve to learn nix :) to modify a derivation (for example applying patches, changing dependencies, changing ./configure flags) similarly how you would extend a class in OO language. In any other OS to do such customization, you would need to generate a new package, place it in package repo, and worry about your modified package breaking other parts of the system. NixOS will then recompile that package and use it (if you use caching it will pull from cache)
eloff 6y ago
This comment was better than the article at explaining what is nix, thanks!
ninetax 6y ago
Unfortunately there's a pretty annoying bug with MacOS which resulted from Apple making /nix non-writable by default. And since /nix is hard coded in all the cached packages it's not easy to fix. This is one big thing that's preventing us from adopting nix https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925
- geofft 6y ago
  I'm trying to understand why macOS can't use a different path (since it's a different OS anyway, and you can't run Linux Nix binaries on macOS). From the end of the thread, it sounds like > The main consequence of using a separate prefix for macOS is that you can't have Hydra jobsets anymore containing jobs for macOS and Linux. It would also make it harder to deploy from macOS to Linux. i.e., if the same package builds for both Linux and macOS, you can't write a single shell script that runs on both Linux Nix and macOS Nix and calls that package? Maybe I'm misunderstanding how people deploy things, but is that a huge problem in practice? (I don't quite follow the thing about Hydra jobsets. Aren't you building once for Linux and once for macOS anyway? Figuring out how to make the build do that seems like it would subsume any complexity of using /nix vs. /opt/nix.)
  - takeda 6y ago
    From looking at PR seems that it will utilize some extra space (for derivations that aren't really OS specific) and there might be problems wih deploying from os x to linux, but feels like they are planning to go that route ultimately.
  - derefr 6y ago
    Perhaps they hardcode full paths into whatever Nix calls its formula files (which are then, if I understand correctly, referred to by their cryptographic hashes, meaning that a file with a different path would have a different hash, and so break the whole hierarchy of formula-to-formula dependency references above it.)
  - elbear 6y ago
    You can use a different path, but then you don't have access to the binary cache, because of the mismatch between your path and the path found in the cached binaries. That's how I understand it.
illumin8 6y ago
I've had the (dis)pleasure of working with several projects that have been built by developers that have religion around Nix. These projects were contract work where the client paid a significant amount of money, and the final product was really poor quality. One of them is a financial application that has strict security requirements, so having a reproducible build system and some of the other qualities of Nix sounds great, however, the auditor, which is one of the top auditors in this industry had this to say in their report: > Overall, we found the dashboard code to be difficult to review and build. In particular, the manner in which the frontend JavaScript is compiled made it difficult to comprehensively evaluate. Given that this includes the driver code for Ledger devices and handling of user input, we believe this to be an area of concern and poses a significant risk. Building the dashboard took hours on an AWS EC2 VM (with a four-core CPU and 32 GB RAM) and while much of that build time is attributable to Nix's way of building dependencies, the code complexity adds unnecessary risk. We encourage a rework of this area of the project to follow more idiomatic web development practices and patterns. This would make the code more comprehensible and conducive to security evaluations, therefore reducing the risk of vulnerabilities that go unnoticed.
- WatchDog 6y ago
  I haven't used Nix, but I would have thought that builds would be fast, due to how cache-able the dependencies should be.
  - throwaway894345 6y ago
    Sounds like they were building everything from scratch, for some reason.
    - maytc 6y ago
      That’s how nix guarantees reproducibility. The compiled artifacts can be cached but that didnt quite work out of the box
      - throwaway894345 6y ago
mikepurvis 6y ago
Thank you for this thoughtful comment. I was involved in establishing a bunch of build and deployment infrastructure at my org that's currently based around large (300mb+) "bundle" Debian packages, but that bundle package is composed of hundreds of small sub-packages, most of which don't change day to day (it's extremely convenient to ship them all as one big unit for versioning sanity and ABI consistency reasons). Nix seems like it would be a great fit for this use case, but there are a number of things about it which give me pause, particularly when it may be possible to get at least some of its advantages by applying the lessons learned to a system built out of boring, old-school packaging tools.
jariel 6y ago
"Nix is a collection of tools and systems that together form a highly reproducible build system." Wouldn't it have been nice to have that statement at the start of the article?

by tel 6y ago

mehrdadn 6y ago

Thanks! So let's say I start installing Nix packages. What distro's packages would they end up most similar to? Say, maybe Arch (which mostly leaves things unmodified)? Does that mean you basically end up with Arch no matter which distro you're on?

catern 6y ago
Trying to put it politely, but your question seems a bit confused. Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages. There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages. But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.
- mehrdadn 6y ago
  Thanks for explaining. I'm (obviously, I thought) not suggesting distros are only about the patches, but patches are a very significant aspect of their raisons d'être to me. I thought most distro maintainers do things like backporting changes though, for security/stability/etc.? Including RedHat, Canonical, the Debian maintainers, etc.? Arch (and I guess Gentoo, and maybe their derivatives like Manjaro) are the only ones I know that minimize upstream package changes. With other popular distros like Fedora, Ubuntu, SUSE, etc. I fully expect they've made custom modifications to some popular packages, but it's been years since I've touched other flavors. You're saying this is wrong and only Debian derivatives tend to do this?
  - catern 6y ago
    Fedora stays close to upstream: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro... Ubuntu is a Debian derivative, they patch things heavily, just like Debian. SUSE, I don't know about their policy. I assume they're like RHEL, which starts from Fedora, which is close to upstream, and then backports bugfixes from later versions on to stable branches. Many distros maintain stable branches and just update the packages on that branch when they have security issues. Backporting security fixes has (somewhat) gone out of favor, because backports executed by package maintainers that weren't familiar with the code have caused serious security issues in the past. Of course, distros like RHEL and (I guess) SUSE still do backport security fixes to their stable branches. But they start from a base which is close to upstream - it just diverges more and more as their stable branch gets older and older.
tel 6y ago
In addition to other answers, I think it's important to note that Nix is comparatively very small (but growing!). To that end, the Nixpkgs policies are still in flux and defined somewhat culturally (at least compared to older, larger distros). There's a release schedule for NixPkgs which is being continuously updated, you mostly subscribe to a fixed "channel" which gives you the default set of derivations. If you need something more fresh then you either modify a derivation yourself (hot-patching the distro) or pull something temporarily from master on NixPkgs. This is hugely facilitated by the way Nix allows you to install multiple package versions in parallel without conflict. Finally, Nix is still sometimes a bit of a research project. The "best" way to manage a distro that's being built using this technology is still being uncovered. For instance, there's an upcoming feature (flakes) which hopes to seriously change the way you talk about and consider versions of NixPkgs and NixOS. Using Nix definitely requires some patience with living on the edge of tech. It can be frustrating and less reliable than other repos due both to the bigger challenge of building a repo using Nix's technology and the smaller contributor base. That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything.
- takeda 6y ago
  > That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything. It simply delivers what docker was promising to deliver.
chpatrick 6y ago
In my experience, nixpkgs packages are modified with the bare minimum to get the upstream code to work.
takeda 6y ago
GuixSD? Only because Guix was build from Nix. Frankly I don't think there's anything else like it. I don't know Arch enough to compare, but there's something also similar to Gentoo, except Nix knows that if source + dependencies + architecture + configuration is the same it will pull compiled version from cache, if something changes it will recompile it. The killer NixOS feature is that it has a single configuration file that's declarative which you can use to describe your OS, so it has something like salt/ansible/chef/puppet built in, and unlike them it's also is truly declarative. For example if you have package installed, to remove it, you just remove it from the list, where in those tools you need to create a state that ensures the package must not be present. Edit: from other comments I see that you meant that packages in arch are not modified, I guess Nix does follow that and only add patches if it absolutely needs them to make application work correctly, but unlike other distros nix also allows user trivially (ignoring the steep curve to learn nix :) to modify a derivation (for example applying patches, changing dependencies, changing ./configure flags) similarly how you would extend a class in OO language. In any other OS to do such customization, you would need to generate a new package, place it in package repo, and worry about your modified package breaking other parts of the system. NixOS will then recompile that package and use it (if you use caching it will pull from cache)

eloff 6y ago

This comment was better than the article at explaining what is nix, thanks!

ninetax 6y ago

Unfortunately there's a pretty annoying bug with MacOS which resulted from Apple making /nix non-writable by default. And since /nix is hard coded in all the cached packages it's not easy to fix. This is one big thing that's preventing us from adopting nix https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925

geofft 6y ago
I'm trying to understand why macOS can't use a different path (since it's a different OS anyway, and you can't run Linux Nix binaries on macOS). From the end of the thread, it sounds like > The main consequence of using a separate prefix for macOS is that you can't have Hydra jobsets anymore containing jobs for macOS and Linux. It would also make it harder to deploy from macOS to Linux. i.e., if the same package builds for both Linux and macOS, you can't write a single shell script that runs on both Linux Nix and macOS Nix and calls that package? Maybe I'm misunderstanding how people deploy things, but is that a huge problem in practice? (I don't quite follow the thing about Hydra jobsets. Aren't you building once for Linux and once for macOS anyway? Figuring out how to make the build do that seems like it would subsume any complexity of using /nix vs. /opt/nix.)
- takeda 6y ago
  From looking at PR seems that it will utilize some extra space (for derivations that aren't really OS specific) and there might be problems wih deploying from os x to linux, but feels like they are planning to go that route ultimately.
- derefr 6y ago
  Perhaps they hardcode full paths into whatever Nix calls its formula files (which are then, if I understand correctly, referred to by their cryptographic hashes, meaning that a file with a different path would have a different hash, and so break the whole hierarchy of formula-to-formula dependency references above it.)
- elbear 6y ago
  You can use a different path, but then you don't have access to the binary cache, because of the mismatch between your path and the path found in the cached binaries. That's how I understand it.

illumin8 6y ago

I've had the (dis)pleasure of working with several projects that have been built by developers that have religion around Nix. These projects were contract work where the client paid a significant amount of money, and the final product was really poor quality. One of them is a financial application that has strict security requirements, so having a reproducible build system and some of the other qualities of Nix sounds great, however, the auditor, which is one of the top auditors in this industry had this to say in their report: > Overall, we found the dashboard code to be difficult to review and build. In particular, the manner in which the frontend JavaScript is compiled made it difficult to comprehensively evaluate. Given that this includes the driver code for Ledger devices and handling of user input, we believe this to be an area of concern and poses a significant risk. Building the dashboard took hours on an AWS EC2 VM (with a four-core CPU and 32 GB RAM) and while much of that build time is attributable to Nix's way of building dependencies, the code complexity adds unnecessary risk. We encourage a rework of this area of the project to follow more idiomatic web development practices and patterns. This would make the code more comprehensible and conducive to security evaluations, therefore reducing the risk of vulnerabilities that go unnoticed.

WatchDog 6y ago
I haven't used Nix, but I would have thought that builds would be fast, due to how cache-able the dependencies should be.
- throwaway894345 6y ago
  Sounds like they were building everything from scratch, for some reason.
  - maytc 6y ago
    That’s how nix guarantees reproducibility. The compiled artifacts can be cached but that didnt quite work out of the box
    - throwaway894345 6y ago

mikepurvis 6y ago

Thank you for this thoughtful comment. I was involved in establishing a bunch of build and deployment infrastructure at my org that's currently based around large (300mb+) "bundle" Debian packages, but that bundle package is composed of hundreds of small sub-packages, most of which don't change day to day (it's extremely convenient to ship them all as one big unit for versioning sanity and ABI consistency reasons). Nix seems like it would be a great fit for this use case, but there are a number of things about it which give me pause, particularly when it may be possible to get at least some of its advantages by applying the lessons learned to a system built out of boring, old-school packaging tools.

jariel 6y ago

"Nix is a collection of tools and systems that together form a highly reproducible build system." Wouldn't it have been nice to have that statement at the start of the article?