16 ms·

As someone out of the loop on this, why is Nix so popular right now? What does it do and why are people installing it on everything? Is this something to pay at

As someone out of the loop on this, why is Nix so popular right now? What does it do and why are people installing it on everything? Is this something to pay attention to or is it a rehash of the 'I put linux on my toaster' 2000s-era stunts?

yjftsjthsd-h 4y ago
Two things (not exhaustive). First, as the article notes, nixpgs has a lot of packages. Second, nix matches Gentoo's customizability but with good binary caching for common builds. (Kind of; that's very approximate) Edit: I should amend: nixpkgs is already huge, and with flakes you can trivially get packages from anybody you trust (like Arch's AUR but distributed and easier), which covers even more packages.
- filmor 4y ago
  It still doesn't have a concept akin to use-flags, which is what distinguishes Gentoo from Linux from Scratch, see https://github.com/NixOS/nixpkgs/issues/12877 https://github.com/NixOS/nixpkgs/issues/12877. The fact that Nix doesn't have these is also one reason why it's easier to cache than Gentoo packages.
  - yjftsjthsd-h 4y ago
    Agreed that there is nothing quite so unified and easy as USE flags for compile time options, although nix happily lets you ex. override build options per-package, and I think overlays let you do large scale changes.
    - Reventlov 4y ago
      On this regard, Guix is better than Nix imo : you can rewrite expressions quite easily in a programmatic manner thanks to Guile, which is also used for package definitions ( https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html https://guix.gnu.org/manual/en/html_node/Defining-Package-Va... or https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html https://guix.gnu.org/manual/en/html_node/Package-Transformat... )
      - kaba0 4y ago
        How is it different from nix overrides?
  - kaba0 4y ago
    Well, it doesn’t have global ones, but you can very trivially override attributes for a specific package if you want. Flags are a great concept, but basically will exponentially increase the required build cache size, and imo having everything in the binary cache and optionally compile only some specific package is a great tradeoff.
  - pxc 4y ago
    Someone announced a fork of NixOS to add USE flags and remove Systemd ages ago on the mailing list, before the Nix community added Discourse. They called what they were starting 'The Church of Suckless NixOS'. I never saw a sign of them after the initial announcement.
mikepurvis 4y ago
I'm deploying Nix to real ROS robots right now at my day job. We're switching to it because it solves real problems associated with scaling the codebase and development team, particularly for domains adjacent to scientific computing.
- lrvick 4y ago
  I would strongly suggest you not use Nix for mission critical computing. It is suitable only for hobby use cases unless you are prepared to review 100% of all code yourself, because no one else is. For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway.
  - mikepurvis 4y ago
    Bit of an odd take, to hold Nix to that standard when other systems happily pull the entire world down from pypi, npm, cargo, and other sites of unknown review-status. I actually find it easier to audit my dependencies and their patches, build logs, etc under Nix than I ever did under Ubuntu. > For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway. This might have been true in 2005, but it is IMO not aligned to modern realities, where: - You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow. - You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like. - You rely on the fault isolation and self-monitoring/healing of a multi-process architecture. - You need to cgroup portions of the system that are critical vs being more spectulative. - You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized. - You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes. None of these requirements will be met by a single binary and init shim solution.
    - lrvick 4y ago
      I would never suggest trusting pypi, npm, cargo, etc. Those are all effectively remote code execution as a service. Those tools save you some time -writing- code but you still are on the hook to review it all just as you would review code from a peer. Why would strangers be trusted more than peers? Operating systems should have a higher standard than random dev libraries. You should be able to trust they already have had a strict cryptographically enforced review process. Distros like Debian and Arch actually have a maintainer application and review process that includes verifying the maintainers cryptographic signing keys. We can cryptographically prove who authored any given package, who approved it, and who approved the approvers. When your threat model includes supply chain attacks, the only answer is to get really really specific about what you -need- to run your target jobs and ensure it comes from well signed and reviewed sources... then review the edge cases yourself. As for your other points... > - You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow. Those could be statically and deterministically compiled into your target application binary, or at a minimum the final build artifacts included in the cpio initramfs which in turn can be statically linked into the kernel. You do not need a full package manager, init system, or even a shell. > - You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like. Sure. An init shim can do insmod to load custom kernel modules as needed in your initramfs. > - You rely on the fault isolation and self-monitoring/healing of a multi-process architecture. Nobody said you have to have a single process. Your pid1 binary can spin off any other processes or threads you need and run reapers for them. A few lines of code in most languages. > - You need to cgroup portions of the system that are critical vs being more spectulative. cgroup system calls are very simple to perform in most programming languages > - You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized. You can include any syslog binary you want for this shipped in your initramfs, or have everything bundle into the kernel stdout over a network where something external does the parsing. I do not know your requirements but there are many many ways to do that. I do not see what NixOS gives you that buildroot, busybox, or a single explicit choice of log collecting daemon cant. > - You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes. If the entire OS is just a lean bzImage with everything you need statically linked into it, then a new one is downloaded to /boot, and then you reboot or kexec pivot. If boot fails roll back. No need for a read/write filesytem other than some fixed directories you can mount in for cache/logs. I realize a lot of this feels like handwaiving, but I have been doing embedded linux systems for over a decade and have found there is always a path to a super lean, immutable, and deterministic/reproducible unikernels with nothing more than a few easily understood makefiles and dockerfiles. If you ever want to chat about this stuff feel free to drop in #!:matrix.org Lot of talk about embedded linux approaches for satellites and hsms in recent weeks.
diffeomorphism 4y ago
It is "just" another package manager, but with quite a few cool features. E.g. easily install different package versions in parallel, got new computer->just copy over the configuration and nix takes care of the rest, want to make a docker container out of this app-> here you go. Neat, hence popular.
- kaba0 4y ago
  Well, it is “just” a package manager in that all previous ones couldn’t really be called that as they were fundamentally faulty. Nix is the first package manager that actually solves dependency hell properly.
  - diffeomorphism 4y ago
    Nah, not really. Neither the first, nor properly, e.g grafting. Not saying it is not good at that, but not even nixOS claims this as a main selling point.
  - lrvick 4y ago
    But it makes dependency trust far worse since there is no code signing, review signing, or maintainer approval process.
    - kaba0 4y ago
      The binary cache works by signing, not sure if this is what you mean? By default you get the “upstream” channels as a trusted store, but you are free to add new ones and only ones that you added their keys of. Pretty sinilar to PPAs.
      - lrvick 4y ago
        Nix does blind automated signing of binaries which only helps prevent the cache from being mutated between builds. It does not ensure the code that went into those builds was accurate. See rejected RFC for more details: https://github.com/NixOS/rfcs/pull/34 https://github.com/NixOS/rfcs/pull/34
Reventlov 4y ago
Because Nix is a functional package manager, and functional package managers are the future of package managing (whether nix, guix, or something we don't have right now). It makes it easier to deal with supply-chain, to deal with rollback on your software updates, to distribute the same configuration everywhere… I found NixOS (the OS centered around Nix) having similarities, in the way you configure things, with how you configure stuff in the networking world (with options that do some stuff behind the scenes you don't really care about). The difference is that with NixOS, you can dig in if you want to. Also, once you used NixOS for a little while, it's very hard to go back to, let's say, Debian, Ubuntu, or Archlinux : manually configuring things in multiple configuration files in /etc seems really primitive.
- rgoulter 4y ago
  > Because Nix is a functional package manager... I'd explain "functional package manager" as "package manager where packages are declared as a function of their inputs". e.g. a package's inputs would be the compiler used to build it, and the source code. One motivation for doing this is ensuring that a package's behaviour is reproducible. There are all sorts of neat benefits this ends up allowing.
  - bogwog 4y ago
    While not designed to be a system package manager, Conan works in a very similar way for C/C++ package management, and it's great. All binary packages live in the cache folder, identified by a hash of the particular permutation of inputs used to build it. It even supports recipe revisions, so if the recipe (build script) changes, you don't have to worry about changes in the generated binary since you can use a lock file to keep using the specific revision of that build script that you know works.
    - pxc 4y ago
      pnpm for Node packages also has a similar design. Once upon a time, it cited Nix as a source of inspiration in its docs! I hope that basic design continues to propagate. Better-behaved package management for language ecosystems is easier to work with for Linux distros, including NixOS. :)
pjmlp 4y ago
I only see it on HN posts, everyone keeps using SLES, Red-Hat and Ubuntu around here.
- vq 4y ago
  I've used nix on Ubuntu and AlmaLinux. I'm betting that nix works on all the distros you listed.
  - pjmlp 4y ago
    It might, still haven't seen it being used.
    - kaba0 4y ago
      It is still the only proper solution to a problem basically every project has. Either it, or some later implementation of the same idea will spread. It is basically the git of binaries.
      - bronson 4y ago
        This is a good analogy, right down to Git's painful UX. Nix is powerful and difficult to understand. Often you'll find yourself in a spot where either you need to take hours or days to understand some fundamental component, or you can just paste a magic incantaion you found soewhere and move on. Good luck googling, it's almost as if they designed the Nix language to be unsearchable. When you do find an answer, it's often 3 years old and completely obsolete. Definitely recommend having a chat window open with other Nix users while working with it. When starting a meaningful project with Nix, make sure you're not on a deadline. I like Nix, a lot. But I'd currently recommend it for a pretty narrow type of user/use case. Like Git.
        kaba0 4y ago
        I have to agree regarding the UX, though I would like to add that it is the language per se that is complex, but its standard lib/“nixpkgs” lib. Also, not sure I can see where would you not recommend git? Is that a typo? It sure has a bad UX, but it is the lingua franca of version management either way, that even junior devs will have to fight to understand to become even remotely useful. And this might well be the case with nix as well.
fulafel 4y ago
For others curious about the popularity levels, it does show approximately a doubling in Google Trends over the last year: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fg%2F11bw4cknm7 https://trends.google.com/trends/explore?date=today%205-y&q=...
- PurpleRamen 4y ago
  Interesting how popular it's in china. Significant more than in other countries. Though, bad that these are only relative numbers, not absolute.
esjeon 4y ago
HN is biased in its own ways, and Nix is one of such topics. It’s way more over-represented here, and I barely hear anything Nix outside. Also, Nix (the tool) has always been independent of NixOS, so running it on something else isn’t a stunt at all.
xcdzvyn 4y ago
These aren't precisely the specified goals of Nix, but things I appreciate as a consequence of its design: (1) If a build works on any machine, it will work on yours. Package builds are isolated and reproducible. For example, setting up Plasma is as simple as `services.xserver.desktopEnvironment.plasma5.enable = true;`, every time, in every environment. (2) Environment configurations are declarative. You will always know what a given host or shell has installed because you have to write it down. (3) Nixpkgs is _by far_ the largest package repository of any package manager, and packages are updated very quickly. (4) With home-manager, software can also be configured declaratively; my preferred tmux configuration will always stay in sync across all of my machines because it's managed by Nix, not ~/.tmux.conf. Following (1) and (2), executing[1] $ git clone https://github.com/xyz/nix $ nixos-rebuild switch --flake ~/nix#host On a fresh NixOS install will create an environment identical to that given host. [1] Don't quote me on the specific syntax. But it's roughly this simple :) Addendum: And as a consequence of Nix being separate from NixOS, if a package builds in Nix, it will work on any distro.
- lrvick 4y ago
  Nixpkgs is the largest repository only because they let anyone throw anything they want in there with minimal accountability. Nixpkgs is the NPM of Linux. While I love the determinism of NixOS, their refusal to mandate strict code review, code signing, and package signing makes it unsuitable for non-hobby use cases. I do hope to see a fork of NixOS with the supply chain integrity of OpenBSD or at the very least that of Debian or Arch.
  - xyzzy_plugh 4y ago
    This is absolutely not true in my experience. Could you expand on those points? Specifically, what do you want to see for code or package signing? Has there been opposition to this before? It should be trivial to sign a trusted derivation, but the signed artifact is either an out-of-band signature that has to be verified, or a new signed derivation is produced which creates problems for anything consuming the non-signed derivation.
    - 4y ago
rgoulter 4y ago
Nix deals with software packages really well. Which makes it well suited for "put in effort now, to save effort later". My favourite use case for Nix is using it to declare what tools/libraries a project needs. Nix can make a bunch of packages available on PATH, without conflicting with what's already installed. -- This is like tools like Node Version Manager, or asdf. Another feature I like is the command "nix run ...", which is similar to "docker run ..." in that it doesn't change what's installed system-wide, but runs the command on the host (and not inside a container). The nix-based operating system NixOS allows for declaring the system configuration, and safely rolling back from changes to the system configuration. > Is this something to pay attention to... Right now, the learning curve is quite steep. It used to be that threads mentioning Nix would attract many "I tried it, but it's too hard" comments.
- teekert 4y ago
  I’ve tried it and it’s too hard ;) I’m saving it for when I have time, it deserves a sustained level of motivation to get up that learning curve.
baby 4y ago
We started using it on the project I work on because there’s no good build or dev tooling like cargo/go for OCaml.
mudrockbestgirl 4y ago
A few things that are nice about it once you've "nixified" your project - Locally reproducible CI builds and tests - Sharable developer environments/shells - Extremely fast and efficient Docker image generation - Composability with other projects that use Nix. It's trivial to add dependencies. - Not dealing with VMs like you do with Docker There is a lot more if you use NixOS and make your whole operating system functional and declarative, but I think that's more of a niche. Why is it popular now? I'm not sure. It still has a steep learning curve (and rough edges) but over the last 1-2 years it has perhaps gotten to a point where the documentation and examples are plentiful enough that more people are willing to try it out. Also, MacOS support has improved (but still kind of sucks) and the new flake system is more intuitive than the old nix files.
kahnclusions 4y ago
Nix makes it really simple and easy to manage several machines. Builds are declarative and reproducible. For my homelab I’ve setup a git repo with config for several VMs: Plex, Bitwarden, torrents, Samba shares, etc. Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host. NixOS builds in “generations”. This morning I managed to screw up something and it bricked a VM. No worries, just restart the VM, boot into the previous working generation. Fix my Nix config, commit and push, rebuild again. Easy. I love it for managing my personal stuff. What I don’t like about Nix? The Nix language kind of sucks, has a steep learning curve, and lacks decent language tooling (LSP etc). If you’re on the beaten path everything is rosy, but as soon as you need to configure something or build a package that no one else has done before, it feels like you need to reverse-engineer Nix just to figure out how to do fairly basic tasks.
- oever 4y ago
  > Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host. Or you can forgo /etc/nixos and push from your current machine with nixos-rebuild switch -v --target-host machine2 --flake .#machine2
  - xyzzy_plugh 4y ago
    This works sometimes but cross arch builds can be problematic. I use Nix on macOS so I have to use a remote build host (or a VM).
    - oever 4y ago
      It's possible to push from x86_64 to aarch by setting this in the system configuration: boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; With that setting pushing from e.g. laptop to raspberry works. Nix on macOS does not have that setting, but perhaps there's an equivalent.
  - kahnclusions 4y ago
    This is true, if you have nixos-rebuild available on your current machine. I just use a script to run the command remotely via ssh and point to the flake in git.
CJefferson 4y ago
I think a lot of people love the principles behind Nix -- I love them enough I've tried (and failed miserably) to install and use it as my regular Linux on 3 occasions.
deng 4y ago
> why is Nix so popular right now? Popular where? On HN, because it's functional, and people around here like functional, just as they like Emacs, for instance. It's not popular in the industry, as far as I can see (also, just like Emacs). For the record, I like Nix (and also Emacs), but I would never introduce it in my team. The learning curve is very steep, and the problems that it solves are mostly handled "good enough" by Docker, which I actually dislike, but everyone and their dog know Docker, there's pretty much zero training for new hires needed, introducing Nix simply does not make any business sense. In a small startup team of like-minded functional programming people, sure, but in a large org? I just don't see it.
- whateveracct 4y ago
  It's funny how "not popular in industry" is always overstated. I can't deny it has very small marketshare. And yet, I've had 4 jobs in the last 6 years that have all used Nix. None of them "small startups" either. So you don't need to be popular to have enough for people to get paid to use it. Haskell is the same way. Also, I ignore people openly who try to evaluate "business sense" as if technology decisions can be quantified like that. The biggest benefit of these Nix and Haskell shops is it attracts enthusiasts who in turn train and excite other hires. Which is turn adds more Nix and Haskell lifers to the world. One "bad business decision" at a time. That's my MO at least :)
  - tadfisher 4y ago
    Nix and Haskell? You and I must work at the same place.
    - whateveracct 4y ago
      haha we might - but on the other hand, I haven't worked at a Haskell shop that hasn't used Nix in the last many years
nvarsj 4y ago
I actually dropped NixOS after using it for 2 years. It's just not practical for day to day work unless you want to be messing around with Nix config or fighting shared lib issues all the time. I'm using OpenSUSE atm and couldn't be happier - yeah it's a lot more click ops, but I get to work so much faster and everything just works. Fedora is another good option. (If you want to know, the breaking point for me was trying to get QtCreator working properly on NixOS which I sunk about 2 hours into before giving up - but took me about 5 mins on OpenSUSE to install). Nix, the package manager, is _amazing_ though, despite the wonky language. I use it for providing hermetic/reproducible environments for my dev projects. You create a shell.nix, auto load it with direnv, and the development environment is 100% replicated for everyone doing dev in that repo. Hook it into your CI too and now you have an identical dev environment everywhere. It's like virtualenv on steroids for any kind of project/tooling.
f0e4c2f7 4y ago
Nix allows for composability in the OS, which is nice for automation and reproducibility. Recently a new and even bigger advantage to composability has appeared. ChatGPT. If you can think up a configuration of an OS you can ask ChatGPT to create it with Nix (or other frameworks for other relevant cases) and then nearly all the work is already done for you. I find this workflow to be even better than GitHub Copilot. Steam deck is interesting here because it leaves me wondering about what I could ask Nix to configure on it. I don't know very much about steamos.

yjftsjthsd-h 4y ago

Two things (not exhaustive). First, as the article notes, nixpgs has a lot of packages. Second, nix matches Gentoo's customizability but with good binary caching for common builds. (Kind of; that's very approximate) Edit: I should amend: nixpkgs is already huge, and with flakes you can trivially get packages from anybody you trust (like Arch's AUR but distributed and easier), which covers even more packages.

filmor 4y ago
It still doesn't have a concept akin to use-flags, which is what distinguishes Gentoo from Linux from Scratch, see https://github.com/NixOS/nixpkgs/issues/12877 https://github.com/NixOS/nixpkgs/issues/12877. The fact that Nix doesn't have these is also one reason why it's easier to cache than Gentoo packages.
- yjftsjthsd-h 4y ago
  Agreed that there is nothing quite so unified and easy as USE flags for compile time options, although nix happily lets you ex. override build options per-package, and I think overlays let you do large scale changes.
  - Reventlov 4y ago
    On this regard, Guix is better than Nix imo : you can rewrite expressions quite easily in a programmatic manner thanks to Guile, which is also used for package definitions ( https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html https://guix.gnu.org/manual/en/html_node/Defining-Package-Va... or https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html https://guix.gnu.org/manual/en/html_node/Package-Transformat... )
    - kaba0 4y ago
      How is it different from nix overrides?
- kaba0 4y ago
  Well, it doesn’t have global ones, but you can very trivially override attributes for a specific package if you want. Flags are a great concept, but basically will exponentially increase the required build cache size, and imo having everything in the binary cache and optionally compile only some specific package is a great tradeoff.
- pxc 4y ago
  Someone announced a fork of NixOS to add USE flags and remove Systemd ages ago on the mailing list, before the Nix community added Discourse. They called what they were starting 'The Church of Suckless NixOS'. I never saw a sign of them after the initial announcement.

mikepurvis 4y ago

I'm deploying Nix to real ROS robots right now at my day job. We're switching to it because it solves real problems associated with scaling the codebase and development team, particularly for domains adjacent to scientific computing.

lrvick 4y ago
I would strongly suggest you not use Nix for mission critical computing. It is suitable only for hobby use cases unless you are prepared to review 100% of all code yourself, because no one else is. For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway.
- mikepurvis 4y ago
  Bit of an odd take, to hold Nix to that standard when other systems happily pull the entire world down from pypi, npm, cargo, and other sites of unknown review-status. I actually find it easier to audit my dependencies and their patches, build logs, etc under Nix than I ever did under Ubuntu. > For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway. This might have been true in 2005, but it is IMO not aligned to modern realities, where: - You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow. - You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like. - You rely on the fault isolation and self-monitoring/healing of a multi-process architecture. - You need to cgroup portions of the system that are critical vs being more spectulative. - You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized. - You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes. None of these requirements will be met by a single binary and init shim solution.
  - lrvick 4y ago
    I would never suggest trusting pypi, npm, cargo, etc. Those are all effectively remote code execution as a service. Those tools save you some time -writing- code but you still are on the hook to review it all just as you would review code from a peer. Why would strangers be trusted more than peers? Operating systems should have a higher standard than random dev libraries. You should be able to trust they already have had a strict cryptographically enforced review process. Distros like Debian and Arch actually have a maintainer application and review process that includes verifying the maintainers cryptographic signing keys. We can cryptographically prove who authored any given package, who approved it, and who approved the approvers. When your threat model includes supply chain attacks, the only answer is to get really really specific about what you -need- to run your target jobs and ensure it comes from well signed and reviewed sources... then review the edge cases yourself. As for your other points... > - You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow. Those could be statically and deterministically compiled into your target application binary, or at a minimum the final build artifacts included in the cpio initramfs which in turn can be statically linked into the kernel. You do not need a full package manager, init system, or even a shell. > - You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like. Sure. An init shim can do insmod to load custom kernel modules as needed in your initramfs. > - You rely on the fault isolation and self-monitoring/healing of a multi-process architecture. Nobody said you have to have a single process. Your pid1 binary can spin off any other processes or threads you need and run reapers for them. A few lines of code in most languages. > - You need to cgroup portions of the system that are critical vs being more spectulative. cgroup system calls are very simple to perform in most programming languages > - You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized. You can include any syslog binary you want for this shipped in your initramfs, or have everything bundle into the kernel stdout over a network where something external does the parsing. I do not know your requirements but there are many many ways to do that. I do not see what NixOS gives you that buildroot, busybox, or a single explicit choice of log collecting daemon cant. > - You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes. If the entire OS is just a lean bzImage with everything you need statically linked into it, then a new one is downloaded to /boot, and then you reboot or kexec pivot. If boot fails roll back. No need for a read/write filesytem other than some fixed directories you can mount in for cache/logs. I realize a lot of this feels like handwaiving, but I have been doing embedded linux systems for over a decade and have found there is always a path to a super lean, immutable, and deterministic/reproducible unikernels with nothing more than a few easily understood makefiles and dockerfiles. If you ever want to chat about this stuff feel free to drop in #!:matrix.org Lot of talk about embedded linux approaches for satellites and hsms in recent weeks.

diffeomorphism 4y ago

It is "just" another package manager, but with quite a few cool features. E.g. easily install different package versions in parallel, got new computer->just copy over the configuration and nix takes care of the rest, want to make a docker container out of this app-> here you go. Neat, hence popular.

kaba0 4y ago
Well, it is “just” a package manager in that all previous ones couldn’t really be called that as they were fundamentally faulty. Nix is the first package manager that actually solves dependency hell properly.
- diffeomorphism 4y ago
  Nah, not really. Neither the first, nor properly, e.g grafting. Not saying it is not good at that, but not even nixOS claims this as a main selling point.
- lrvick 4y ago
  But it makes dependency trust far worse since there is no code signing, review signing, or maintainer approval process.
  - kaba0 4y ago
    The binary cache works by signing, not sure if this is what you mean? By default you get the “upstream” channels as a trusted store, but you are free to add new ones and only ones that you added their keys of. Pretty sinilar to PPAs.
    - lrvick 4y ago
      Nix does blind automated signing of binaries which only helps prevent the cache from being mutated between builds. It does not ensure the code that went into those builds was accurate. See rejected RFC for more details: https://github.com/NixOS/rfcs/pull/34 https://github.com/NixOS/rfcs/pull/34

Reventlov 4y ago

Because Nix is a functional package manager, and functional package managers are the future of package managing (whether nix, guix, or something we don't have right now). It makes it easier to deal with supply-chain, to deal with rollback on your software updates, to distribute the same configuration everywhere… I found NixOS (the OS centered around Nix) having similarities, in the way you configure things, with how you configure stuff in the networking world (with options that do some stuff behind the scenes you don't really care about). The difference is that with NixOS, you can dig in if you want to. Also, once you used NixOS for a little while, it's very hard to go back to, let's say, Debian, Ubuntu, or Archlinux : manually configuring things in multiple configuration files in /etc seems really primitive.

rgoulter 4y ago
> Because Nix is a functional package manager... I'd explain "functional package manager" as "package manager where packages are declared as a function of their inputs". e.g. a package's inputs would be the compiler used to build it, and the source code. One motivation for doing this is ensuring that a package's behaviour is reproducible. There are all sorts of neat benefits this ends up allowing.
- bogwog 4y ago
  While not designed to be a system package manager, Conan works in a very similar way for C/C++ package management, and it's great. All binary packages live in the cache folder, identified by a hash of the particular permutation of inputs used to build it. It even supports recipe revisions, so if the recipe (build script) changes, you don't have to worry about changes in the generated binary since you can use a lock file to keep using the specific revision of that build script that you know works.
  - pxc 4y ago
    pnpm for Node packages also has a similar design. Once upon a time, it cited Nix as a source of inspiration in its docs! I hope that basic design continues to propagate. Better-behaved package management for language ecosystems is easier to work with for Linux distros, including NixOS. :)

pjmlp 4y ago

I only see it on HN posts, everyone keeps using SLES, Red-Hat and Ubuntu around here.

vq 4y ago
I've used nix on Ubuntu and AlmaLinux. I'm betting that nix works on all the distros you listed.
- pjmlp 4y ago
  It might, still haven't seen it being used.
  - kaba0 4y ago
    It is still the only proper solution to a problem basically every project has. Either it, or some later implementation of the same idea will spread. It is basically the git of binaries.
    - bronson 4y ago
      This is a good analogy, right down to Git's painful UX. Nix is powerful and difficult to understand. Often you'll find yourself in a spot where either you need to take hours or days to understand some fundamental component, or you can just paste a magic incantaion you found soewhere and move on. Good luck googling, it's almost as if they designed the Nix language to be unsearchable. When you do find an answer, it's often 3 years old and completely obsolete. Definitely recommend having a chat window open with other Nix users while working with it. When starting a meaningful project with Nix, make sure you're not on a deadline. I like Nix, a lot. But I'd currently recommend it for a pretty narrow type of user/use case. Like Git.
      - kaba0 4y ago
        I have to agree regarding the UX, though I would like to add that it is the language per se that is complex, but its standard lib/“nixpkgs” lib. Also, not sure I can see where would you not recommend git? Is that a typo? It sure has a bad UX, but it is the lingua franca of version management either way, that even junior devs will have to fight to understand to become even remotely useful. And this might well be the case with nix as well.

fulafel 4y ago

For others curious about the popularity levels, it does show approximately a doubling in Google Trends over the last year: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fg%2F11bw4cknm7 https://trends.google.com/trends/explore?date=today%205-y&q=...

PurpleRamen 4y ago
Interesting how popular it's in china. Significant more than in other countries. Though, bad that these are only relative numbers, not absolute.

esjeon 4y ago

HN is biased in its own ways, and Nix is one of such topics. It’s way more over-represented here, and I barely hear anything Nix outside. Also, Nix (the tool) has always been independent of NixOS, so running it on something else isn’t a stunt at all.

xcdzvyn 4y ago

These aren't precisely the specified goals of Nix, but things I appreciate as a consequence of its design: (1) If a build works on any machine, it will work on yours. Package builds are isolated and reproducible. For example, setting up Plasma is as simple as `services.xserver.desktopEnvironment.plasma5.enable = true;`, every time, in every environment. (2) Environment configurations are declarative. You will always know what a given host or shell has installed because you have to write it down. (3) Nixpkgs is _by far_ the largest package repository of any package manager, and packages are updated very quickly. (4) With home-manager, software can also be configured declaratively; my preferred tmux configuration will always stay in sync across all of my machines because it's managed by Nix, not ~/.tmux.conf. Following (1) and (2), executing[1] $ git clone https://github.com/xyz/nix $ nixos-rebuild switch --flake ~/nix#host On a fresh NixOS install will create an environment identical to that given host. [1] Don't quote me on the specific syntax. But it's roughly this simple :) Addendum: And as a consequence of Nix being separate from NixOS, if a package builds in Nix, it will work on any distro.

lrvick 4y ago
Nixpkgs is the largest repository only because they let anyone throw anything they want in there with minimal accountability. Nixpkgs is the NPM of Linux. While I love the determinism of NixOS, their refusal to mandate strict code review, code signing, and package signing makes it unsuitable for non-hobby use cases. I do hope to see a fork of NixOS with the supply chain integrity of OpenBSD or at the very least that of Debian or Arch.
- xyzzy_plugh 4y ago
  This is absolutely not true in my experience. Could you expand on those points? Specifically, what do you want to see for code or package signing? Has there been opposition to this before? It should be trivial to sign a trusted derivation, but the signed artifact is either an out-of-band signature that has to be verified, or a new signed derivation is produced which creates problems for anything consuming the non-signed derivation.
  - 4y ago

rgoulter 4y ago

Nix deals with software packages really well. Which makes it well suited for "put in effort now, to save effort later". My favourite use case for Nix is using it to declare what tools/libraries a project needs. Nix can make a bunch of packages available on PATH, without conflicting with what's already installed. -- This is like tools like Node Version Manager, or asdf. Another feature I like is the command "nix run ...", which is similar to "docker run ..." in that it doesn't change what's installed system-wide, but runs the command on the host (and not inside a container). The nix-based operating system NixOS allows for declaring the system configuration, and safely rolling back from changes to the system configuration. > Is this something to pay attention to... Right now, the learning curve is quite steep. It used to be that threads mentioning Nix would attract many "I tried it, but it's too hard" comments.

teekert 4y ago
I’ve tried it and it’s too hard ;) I’m saving it for when I have time, it deserves a sustained level of motivation to get up that learning curve.

baby 4y ago

We started using it on the project I work on because there’s no good build or dev tooling like cargo/go for OCaml.

mudrockbestgirl 4y ago

A few things that are nice about it once you've "nixified" your project - Locally reproducible CI builds and tests - Sharable developer environments/shells - Extremely fast and efficient Docker image generation - Composability with other projects that use Nix. It's trivial to add dependencies. - Not dealing with VMs like you do with Docker There is a lot more if you use NixOS and make your whole operating system functional and declarative, but I think that's more of a niche. Why is it popular now? I'm not sure. It still has a steep learning curve (and rough edges) but over the last 1-2 years it has perhaps gotten to a point where the documentation and examples are plentiful enough that more people are willing to try it out. Also, MacOS support has improved (but still kind of sucks) and the new flake system is more intuitive than the old nix files.

kahnclusions 4y ago

Nix makes it really simple and easy to manage several machines. Builds are declarative and reproducible. For my homelab I’ve setup a git repo with config for several VMs: Plex, Bitwarden, torrents, Samba shares, etc. Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host. NixOS builds in “generations”. This morning I managed to screw up something and it bricked a VM. No worries, just restart the VM, boot into the previous working generation. Fix my Nix config, commit and push, rebuild again. Easy. I love it for managing my personal stuff. What I don’t like about Nix? The Nix language kind of sucks, has a steep learning curve, and lacks decent language tooling (LSP etc). If you’re on the beaten path everything is rosy, but as soon as you need to configure something or build a package that no one else has done before, it feels like you need to reverse-engineer Nix just to figure out how to do fairly basic tasks.

oever 4y ago
> Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host. Or you can forgo /etc/nixos and push from your current machine with nixos-rebuild switch -v --target-host machine2 --flake .#machine2
- xyzzy_plugh 4y ago
  This works sometimes but cross arch builds can be problematic. I use Nix on macOS so I have to use a remote build host (or a VM).
  - oever 4y ago
    It's possible to push from x86_64 to aarch by setting this in the system configuration: boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; With that setting pushing from e.g. laptop to raspberry works. Nix on macOS does not have that setting, but perhaps there's an equivalent.
- kahnclusions 4y ago
  This is true, if you have nixos-rebuild available on your current machine. I just use a script to run the command remotely via ssh and point to the flake in git.

CJefferson 4y ago

I think a lot of people love the principles behind Nix -- I love them enough I've tried (and failed miserably) to install and use it as my regular Linux on 3 occasions.

deng 4y ago

> why is Nix so popular right now? Popular where? On HN, because it's functional, and people around here like functional, just as they like Emacs, for instance. It's not popular in the industry, as far as I can see (also, just like Emacs). For the record, I like Nix (and also Emacs), but I would never introduce it in my team. The learning curve is very steep, and the problems that it solves are mostly handled "good enough" by Docker, which I actually dislike, but everyone and their dog know Docker, there's pretty much zero training for new hires needed, introducing Nix simply does not make any business sense. In a small startup team of like-minded functional programming people, sure, but in a large org? I just don't see it.

whateveracct 4y ago
It's funny how "not popular in industry" is always overstated. I can't deny it has very small marketshare. And yet, I've had 4 jobs in the last 6 years that have all used Nix. None of them "small startups" either. So you don't need to be popular to have enough for people to get paid to use it. Haskell is the same way. Also, I ignore people openly who try to evaluate "business sense" as if technology decisions can be quantified like that. The biggest benefit of these Nix and Haskell shops is it attracts enthusiasts who in turn train and excite other hires. Which is turn adds more Nix and Haskell lifers to the world. One "bad business decision" at a time. That's my MO at least :)
- tadfisher 4y ago
  Nix and Haskell? You and I must work at the same place.
  - whateveracct 4y ago
    haha we might - but on the other hand, I haven't worked at a Haskell shop that hasn't used Nix in the last many years

nvarsj 4y ago

I actually dropped NixOS after using it for 2 years. It's just not practical for day to day work unless you want to be messing around with Nix config or fighting shared lib issues all the time. I'm using OpenSUSE atm and couldn't be happier - yeah it's a lot more click ops, but I get to work so much faster and everything just works. Fedora is another good option. (If you want to know, the breaking point for me was trying to get QtCreator working properly on NixOS which I sunk about 2 hours into before giving up - but took me about 5 mins on OpenSUSE to install). Nix, the package manager, is _amazing_ though, despite the wonky language. I use it for providing hermetic/reproducible environments for my dev projects. You create a shell.nix, auto load it with direnv, and the development environment is 100% replicated for everyone doing dev in that repo. Hook it into your CI too and now you have an identical dev environment everywhere. It's like virtualenv on steroids for any kind of project/tooling.

f0e4c2f7 4y ago

Nix allows for composability in the OS, which is nice for automation and reproducibility. Recently a new and even bigger advantage to composability has appeared. ChatGPT. If you can think up a configuration of an OS you can ask ChatGPT to create it with Nix (or other frameworks for other relevant cases) and then nearly all the work is already done for you. I find this workflow to be even better than GitHub Copilot. Steam deck is interesting here because it leaves me wondering about what I could ask Nix to configure on it. I don't know very much about steamos.