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.
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.
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.)
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.
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.
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.
I use Nix and Home manager to keep a consistent terminal development environment (Neovim and friends) across my personal computers and on the HPC cluster. I never used NixOS. It took me a while to craft a working and flexible config, but since then I rarely touch it and only update packages once in a while. It works great for my needs.
It is possible to use nix simply as a better Homebrew—one where you can update packages without all of your system potentially breaking from package updates. That has happened to many people with brew and it no longer happens to me.
That means `nix-env -iA <packagename>`.
Is this approach using the full power of nix? No. But in a “worse-is-better” kind of way, just doing this has given me a more stable system than I had with Homebrew. And that’s all I wanted from nix. Flakes and nix-shell are just additional things that I’ve gotten some benefit from over time.
Something I have always wondered about is how Nix interacts with my editor and language servers.
I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things extra complex, note that I often work on multiple interdependent projects concurrently; I imagine that makes things even gnarlier.
Is there a sane way to manage this sort of thing? Do I end up managing a per-project installation of emacs??
I tried to give Nix a chance but I never figured out how to package dependencies that didn't already have a derivation written for them.
Particularly since I do a lot of ML work - I never figured out how to handle mixed Python/C++ code with dependencies on CUDA.
It's just way easier, even if not reproducible, to build an environment imperatively in Docker.
Nix falls into the camp in my mind that includes Rust: great idea that I just don't have time for right now.
Reproducibility is the holy grail, IMO. It is so valuable that any system that actually achieves it will find some longevity and eventually be hammered into a useable form. I believed in the promise when AWS was all about amis. Then I believed in the promise with docker. It seems something like Nix is a natural next step in this evolution.
I want it to succeed enough that it gets easy enough for me to use. But for now I'll stick with macOS for my laptop and docker with alpine for my deployments.
Clutter reduction and version-controlled build/packaging is where Nix wins big-time. With Direnv you can automatically enter a developer shell as soon as you CD into the directory, which is another helpful timesaver.
I was so excited to give Nix a chance, but I'd prefer to program in Guile rather than Nix, so now I'm excited to give Guix a chance lol. Going to install it this Wednesday on new laptop, wish me luck
Yes, but:
du -sh /nix
I’ve tried a few times now, it’s great when you don’t have to actually write nix yourself. At scale though the typeless dictionary style parameter approach is so impossibly unreadable, constantly hunting down some nixos helper and its underspecified parameters is painful. Its honestly a lot of the same pain yaml has at scale. Lack of typing means more burden on me to remember everything, except nix adds to this a really tough debugging story as it’s lazy and the error messages aren’t usually that helpful.
I recently had to switch back from Nix, as the way it operated clashed with the corporate IT security controls on my work laptop and prevented me from using it.
I just went back to Bash and it honestly works just fine, any rough edges probably don't outweigh how inscrutable Nix tends to be: https://github.com/dbalatero/dotfiles/blob/main/apply
> These hashes are computed using SHA-256
Not so fast! The hash story is actually much more complex than that, as this recent article showed: https://bernsteinbear.com/blog/nix-by-hand/
Regardless, the hash function is irrelevant to end-users, I just thought it was interesting that they cooked up such a convoluted scheme.
Nix + flakes & direnv is the perfect dev environment, run it on the Mac and everybody in team can setup any project in seconds. We also have a makefile that sets up Postgres / init,start,stop with a local file socket - so every project instance has it’s own db instance. Very jummy.
That said I wish it was easier to be able to pick a specific build of for example ruby like ruby-3.3.7-p123.
For me it is another Gentoo.
I had my time trying every new distro that would be popping up on Linux related magazines CD/DVDs up to the mid-2000's (they still do in some European countries), unless it comes on a laptop I can get at the mall computer store, or some customer imposes it on our delivery contract, not really something I want to give a chance to.
Nix is great but the user interface is ugly and cryptic. Debugging dependency issues (what depends on this package of particular hash), installing a particular version of a package is just more trouble than something you would get from the likes of npm or cargo.
Would I use nix for my servers? Yes. Would I also use nix personally to keep my systems in sync? Yes. Will I recommend nix to others? Absolutely not.
What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies?
Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?
Honestly it's not been worth my time. I spent more time shoving things into Nix than I did shipping.
The time to “give Nix a chance” was already years ago.
interesting that the author blames "the modern developer tooling ecosystem" for the issue of not being able to reproduce builds, it's still a problem of course but in my experience it was way worse in the past, with most ecosystems i've used adopting some kind of passable package manager now.
For someone wanting to use nix for the premise of the article (dev environment management), I'd encourage you to checkout Coder[0] which I'm self-hosting personally for my company, but will prove useful once I hire.
[0]: https://coder.com
Nix is still waiting for its GitHub moment. It's possible to live a strictly better life (as an individual or company) via Nix and NixOS but there's still a ton of lore and inside baseball that requires a pressing need to justify learning it all. If there's a serious Nix person in your company or friend group it's time, otherwise be ready for a learning curve that's only worth it if you have one of the problems it solves (if Docker is starting to be a weird init system or devs are finding excuses to go around it). It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that).
Nix is in a bit of a split/argument/fork-prone thing at the moment but it looks like this will settle into a practical/purist thing where everyone can be happy, so go in knowing which crowd is your people.
I'm not a purist so listen to one of them if you are. That said:
- flakes aren't optional or experimental, they're the default, its a small clique holding it up for years and its getting forked around by everyone serious
- flake parts is looking like a lock for the de facto flake standard, something else might come along but the leet stuff is congregating around it
- Cachix devenv is a good gateway drug: its better than Docker and easier to graduate from when it gets serious on that component
- nix-ld and FHS envs aren't a sin, they fix most all the friction bilugs and should be the default design, I overlay the shebang thing and all the unfree restrictions and all of it: the incompatible by design people are aging out, this will all work flawlessly in a year or two and you can do it today but its inside baseball
If you need to support Mac and Linux without the limitations of a strict all-OCI flow it's your best option, if you need a chance in hell against serious supply-chain attacks its your best starting point. If you need to run on a mix of metal and cloud and/or double-virtualizing is an issue its The Way.
The best super accessible resource to go from zero to "holy shit computers can do that" is vimjoyer's YouTube.
Use sops.nix and your secrets management is solved. Also by Mic92 is nixos-generators, that is basically infinitely portable to anything. juspay's GitHub, srid's GitHub, pretty much all the nixos-asia stuff is galaxy brain next level. It all works great on MacOS if you're not over it yet with the telemetry.
(sidebar: telemetry is your biggest computer problem now and your phone addiction is part of the telemetry deal. Linux and Graphene and NextDNS and Proton and stuff are worth it even for Grandma finally. I'm glad the purists do their thing, its an act of service).
> More importantly, Docker containers themselves aren’t reproducible—running apt-get update or pip install requests at different times can yield different results, even with the same Dockerfile.
apt-get install <package name>=<version>
> And frankly, no one really needs Kubernetes, they just have it because everyone and their grandma has it. I digress, that’s a topic for another day.
Oh grow up, ffs.
p oo de n nn d but vvjjfc. A b
[flagged]
Wow.
1) you can python environment with dependencies! (can do that without nix)
2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc)
If you can't make reproducible dev environment in 2025 - it is 100% skill issue.
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.