Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packages.
Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.
I have tried NixOS and the out of the box experience isn't bad, neither on my main VM nor my notebook. Everybody points you to flakes and flakes point you do use the unstable branch of nixos and that is where I say no. Then you learn a bunch of things along the way like upgrading replaces your stuff and you have to start again.
I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.
Flakes and the unstable branch of NixOS (the `nixos-unstable` branch of Nixpkgs) are unrelated.
Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago.
Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes.
Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.
Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it.
If it was a function call you could just go-to-definition.
Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.
Its not that practical. I cr#ated a nix file to roll a new jellyfinmediaplayer client in nix and it worked until s(me update broke it but the audio and a few other things needed finding obscure nonsense and specifying it to work passably. Its been replaced by fi e sentences remnding me what to click installing bazzite and it works rock solid for very mnimal additiobal setup time
I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.
Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1].
In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype).
I guess relentlessly dylibbed software like AppImage is the elephant in the room. Nix struggles to handle those types of programs, but they tend to work fine in Flatpak or with a special tool (eg. appimage-run or steam-run).
Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace.
When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort.
Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.
My servers don’t have that many dotfiles because most server software can be configured in /etc (zsh, vim), while my work computers have a lot of dotfiles symlinked into ~/.config/ via Nix, e.g. VSCodium, ghostty, …
Most people prefer to Nix up their dotfiles, which provides some advantages (e.g. universal styling via Stylix), but the main drawback that I’m not buying is: I can’t share my app-specific config with non-Nix users.
I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean.
For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those config changes I tried for nouveau still affecting my system? Has all that mucking around left my GPU forever in a suboptimal state?
With Nix, it might take just as much tinkering to get the GPU to work. But once I'm done, I know that my system is exactly as I've defined it in configuration.nix. Anything else I tried along the way will just sit inertly in /nix/store until the garbage collector wipes it away.
I don’t know. My concept for reproducibility with Debian is a backup of /etc and the list of installed packages (the output of `dpkg --get-selections`). It’s also not difficult to diff one’s /etc with a pristine version, though I haven’t actually needed that in many years.
If that scratches the itch, great. Backups of /etc can't be combined in a way that lets you reliably uncombine them later though, so you're going to be limited in how modular you can make it.
I believe 'dpkg --get-selections' lists all packages, not just the ones the user installed. So if I installed some package foo that had a dependency bar, this method would have me carrying around bar even if foo updated to stop depending on it.
This article felt like a strong argument against Nix rather than in favor of it. The complexity it brings is just not worth the gains for the majority of people that I know. No, most people won't be happy that Nix breaks dynamic linking.
Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit simpler to them now.
Ubuntu user of 15 years here (+ a couple years of tinkering with RedHat, Arch & Gentoo before that).
I tried to learn Nix (the language) a couple years ago, didn't like it and got nowhere. Now, two months ago I heard I would be getting a Windows machine at my new client, so I really wanted a way to deterministically generate a Linux VM that worked & felt exactly the same as my usual setup. So I thought back to Nix(OS) and this time I skipped trying to learn Nix and just tried to absorb it from examples and code snippets I would find online (very reminiscent of my experience with Emacs many years ago). Often I would also ask Gemini to explain things to me. Only a few afternoons later I had a working VM[0] that looked and felt exactly as the desktop environment I have carefully curated over 15 years. Now, several weeks later, I also have built a live CD image with that same config and will soon roll out my Nix config to all my Ubuntu machines & Debian servers. I won't look back.
I won't deny, though: I still don't like the language too much and I think it is tied too much to building an OS, as opposed to anything else. Documentation is sparse and mediocre at best. But overall it's alright! Things are usually not that complicated, and most of the time they just work! (And if they don't, it's surprisingly easy to navigate the nixpkgs source code and look up what's happening under the hood.) In any case, my new Nix config is so much better than the set of bespoke Bash scripts I've written over the years to (reproducibly?) configure my Ubuntu desktop with i3wm for me.
[0]: nixos-generators is magical when you first try it! https://github.com/nix-community/nixos-generators (Fine print: Of course with the benefit of hindsight I now know that it's merely a dumb wrapper around things that Nix provides out of the box but oh well.)
Just NixOS. When building the VM / live CD I copy my dotfiles into the Nix store and then during first boot-up I copy them into my home dir and set up symlinks.
The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.)
Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.
My recent experience being tech support for family and trying to make available some sort of digitized preservation of family photos/history, has been impressing upon me the need to get away from Rube Goldberg systems that only I could possibly understand and modify. My primary filesystem being ZFS already makes having my stuff be accessible to others after my death a bit unrealistic. (Part of my strategy, will be physical redundancy with archival disks and HDDs, and even paper for text information)
I’m forever intrigued by the promises of nix, but I have finally accepted that I am not the target audience for what they have built. The nix language is fundamentally at odds with general purpose usability. Even using the package manger on other distros is fraught with gotchas.
On an off topic note, I find it fascinating how both my father and grandfather, who are/were quite technically competent, seem to become increasingly and possibly willfully helpless about computers as they get older. I find myself wondering if at some point I will also experience exhaustion of whatever internal energy is needed to fuel technical fluency.
The nix language is fundamentally at odds with general purpose usability.
I have contributed or tried to contribute to many distributions (heck, I even worked for a commercial Linux distribution when I was young) and contributing to nixpkgs was an order of magnitude easier than other distributions. Part of it was the GitHub/PR-centered workflow, but the other part is that Nix is a small functional language and the package definitions are not in some arcane weird format like RPM spec files or Debian rules. Also, Nix makes it much easier to refine a derivation/package without actually having to install it on your system.
I want to second this experience. I've never actually submitted my contributions upstream for other distros, but I've maintained repositories for personal use for Ubuntu, openSUSE, Arch, Gentoo, CentOS and Fedora.
Writing a new package from scratch based on Nixpkgs is far easier than for other distros, and easy packaging tasks are much easier with Nixpkgs than with other distributions.
(It's also much easier to distribute packages without standing up new infrastructure with Nix, since it's source-based and will fall back to source-based builds if you have no established mechanism for distributing binaries.)
What is the supply chain security story with Nix packages?
I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.
As I see it there are three components of software supply chain security:
- is this actually the binary that comes from that code?
- is that code trustworthy?
- is this binary trustworthy?
Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to, but it forces them to act in the open where they're more likely to get caught--anybody can verify that the correspondence between code and binary doesn't hold.
So if you're worried that one dark day, `curl whoever.com/whatever.sh | bash` will suddenly contain malware when it didn't before, using nix instead will protect you... until you manually approve the malicious update. It's up to you to come up with reasons why you should or shouldn't do that, but at least there will be a commit in your code where things went bad.
If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you.
Personally, I think that solving the latter problems without a robust solution to the first problem is sort of a band-aid solution. So I'm a big fan of the nix approach to supply chain security, but it's important to be aware of what you're not getting, which is a promise that any bits are trustworthy in the first place.
Thanks for that detailed argument, especially for pointing out the three necessary components.
I agree even with the following paragraph in principle:
"If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you."
For me it is not so much about what the council of elders says, but more about when FAANG and Co. are OK to run a binary I think needn't worry about the rest.
Or to think this further, they should care more about Nix than I should.
The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed".
For example, you can see where the xz sources get pulled from in the src section here:
As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK).
But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment.
The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version:
https://reproducible.nixos.org/nixos-iso-gnome-r13y/
> All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment.
In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do?
An unexpected benefit of nix for me was CI caching. It’s easy to set up S3 as a binary cache, and then anything you can express as a nix derivation can be cached so that if nothing has changed, it avoids a build.
One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds some test data, runs some tests, and then saves the data directory into $out. CI jobs can then load the DB by building that derivation and copying the data files into a local directory. If no migrations or other dependencies have changed, this is virtually instantaneous.
My last gig was at a place where a guy basically wrote his own job security by reducing a 1hr 40min JS build pipeline down to 2 minutes with Nix caching.
Interesting, I have my own hacked together caches to greatly speed up docker setup, having a cache at this level may speed things up further in a cleaner more maintainable way.
Readit News
Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.
I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.
Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago.
Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes.
Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.
If it was a function call you could just go-to-definition.
Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.
I am trying to create a tool to help see exactly where and by which program any environment variable was set/exported since boot.
This is still in the conceptual phase but I'm looking into linux' ftrace to achieve this. Any ideas or pointers are welcome.
In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype).
[1] https://nix.dev/tutorials/nix-language.html
When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.
Most of the benefit of nix for me is maintaining a configuration for a couple computers in a way that's easy to backup, upgrade, and recover with.
Mine has been going on since 2016, what am I doing wrong?
Here’s a very small example:
https://github.com/sshine/nix/blob/main/shared/home-manager....
My servers don’t have that many dotfiles because most server software can be configured in /etc (zsh, vim), while my work computers have a lot of dotfiles symlinked into ~/.config/ via Nix, e.g. VSCodium, ghostty, …
Most people prefer to Nix up their dotfiles, which provides some advantages (e.g. universal styling via Stylix), but the main drawback that I’m not buying is: I can’t share my app-specific config with non-Nix users.
But if you’re looking for a cheaper (in terms of complexity) dotfiles manager: https://github.com/yarlson/lnk
For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those config changes I tried for nouveau still affecting my system? Has all that mucking around left my GPU forever in a suboptimal state?
With Nix, it might take just as much tinkering to get the GPU to work. But once I'm done, I know that my system is exactly as I've defined it in configuration.nix. Anything else I tried along the way will just sit inertly in /nix/store until the garbage collector wipes it away.
Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit simpler to them now.
True. In my case I just enabled nix-ld[0,1] and now everything works flawlessly.
[0]: https://github.com/nix-community/nix-ld
[1]: https://wiki.nixos.org/wiki/Nix-ld
I wish Nix-ld was just bundled into Nix
I tried to learn Nix (the language) a couple years ago, didn't like it and got nowhere. Now, two months ago I heard I would be getting a Windows machine at my new client, so I really wanted a way to deterministically generate a Linux VM that worked & felt exactly the same as my usual setup. So I thought back to Nix(OS) and this time I skipped trying to learn Nix and just tried to absorb it from examples and code snippets I would find online (very reminiscent of my experience with Emacs many years ago). Often I would also ask Gemini to explain things to me. Only a few afternoons later I had a working VM[0] that looked and felt exactly as the desktop environment I have carefully curated over 15 years. Now, several weeks later, I also have built a live CD image with that same config and will soon roll out my Nix config to all my Ubuntu machines & Debian servers. I won't look back.
I won't deny, though: I still don't like the language too much and I think it is tied too much to building an OS, as opposed to anything else. Documentation is sparse and mediocre at best. But overall it's alright! Things are usually not that complicated, and most of the time they just work! (And if they don't, it's surprisingly easy to navigate the nixpkgs source code and look up what's happening under the hood.) In any case, my new Nix config is so much better than the set of bespoke Bash scripts I've written over the years to (reproducibly?) configure my Ubuntu desktop with i3wm for me.
[0]: nixos-generators is magical when you first try it! https://github.com/nix-community/nixos-generators (Fine print: Of course with the benefit of hindsight I now know that it's merely a dumb wrapper around things that Nix provides out of the box but oh well.)
The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.)
Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.
I’m forever intrigued by the promises of nix, but I have finally accepted that I am not the target audience for what they have built. The nix language is fundamentally at odds with general purpose usability. Even using the package manger on other distros is fraught with gotchas.
On an off topic note, I find it fascinating how both my father and grandfather, who are/were quite technically competent, seem to become increasingly and possibly willfully helpless about computers as they get older. I find myself wondering if at some point I will also experience exhaustion of whatever internal energy is needed to fuel technical fluency.
I have contributed or tried to contribute to many distributions (heck, I even worked for a commercial Linux distribution when I was young) and contributing to nixpkgs was an order of magnitude easier than other distributions. Part of it was the GitHub/PR-centered workflow, but the other part is that Nix is a small functional language and the package definitions are not in some arcane weird format like RPM spec files or Debian rules. Also, Nix makes it much easier to refine a derivation/package without actually having to install it on your system.
Writing a new package from scratch based on Nixpkgs is far easier than for other distros, and easy packaging tasks are much easier with Nixpkgs than with other distributions.
(It's also much easier to distribute packages without standing up new infrastructure with Nix, since it's source-based and will fall back to source-based builds if you have no established mechanism for distributing binaries.)
I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.
- is this actually the binary that comes from that code?
- is that code trustworthy?
- is this binary trustworthy?
Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to, but it forces them to act in the open where they're more likely to get caught--anybody can verify that the correspondence between code and binary doesn't hold.
So if you're worried that one dark day, `curl whoever.com/whatever.sh | bash` will suddenly contain malware when it didn't before, using nix instead will protect you... until you manually approve the malicious update. It's up to you to come up with reasons why you should or shouldn't do that, but at least there will be a commit in your code where things went bad.
If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you.
Personally, I think that solving the latter problems without a robust solution to the first problem is sort of a band-aid solution. So I'm a big fan of the nix approach to supply chain security, but it's important to be aware of what you're not getting, which is a promise that any bits are trustworthy in the first place.
I agree even with the following paragraph in principle:
"If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you."
For me it is not so much about what the council of elders says, but more about when FAANG and Co. are OK to run a binary I think needn't worry about the rest. Or to think this further, they should care more about Nix than I should.
For example, you can see where the xz sources get pulled from in the src section here:
https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools...
As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK).
But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment.
The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version: https://reproducible.nixos.org/nixos-iso-gnome-r13y/
In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do?
https://www.debian.org/events/keysigning
One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds some test data, runs some tests, and then saves the data directory into $out. CI jobs can then load the DB by building that derivation and copying the data files into a local directory. If no migrations or other dependencies have changed, this is virtually instantaneous.