Nix in CI seems like a really excellent match. I don’t care much about the ATproto space - but Tangled has built their CI system on Nix and I find that really compelling. CI Caching is just awful with GitHub actions - so it made me disappointed that Forgejo went that route.
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?
After having done the switch to nixOS, I can confidently say that managing a system any other way (like with apt/brew + 20 handwritten bash scripts) really is neanderthal technology and nix is superior in every single way.
It's also great for the AI era, copilot is really good with that stuff.
It doesn't help that there are two NixOS wikis. nixos.wiki and wiki.nixos.org.
wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
Claude Code has to be actively steered, because while it knows some nixpkgs it surely doesn’t know it enough. E.g. it was absolutely incapable of fixing lldap settings after system upgrade from 25.05 to 25.11. It just prodded around blindly, producing meaningless configs instead learning how the module works.
NixOS docs work for me, but I tend to just go for the nixpkgs source instead. Manuals document options but not how those are actually plumbed through, nor what remains behind the scenes like all systemd unit settings). Claude can do this too, but it goes quite weird roundabout ways with a lot of weird `find /nix/store` and `nix eval`s to get to it, slow and token-hungry (and not always accurate).
This said, Claude is very helpful at checking logs and providing a picture of what’s going on - saves ton of time this way. Plus it can speed up iterating on changes after it’s fed enough knowledge (but don’t expect it to do things right, that’s still on you). It has breadth of it, but not the depth, and that shows at almost any non-trivial task.
You don't have Claude Code git clone nixpkgs and home-manager for local reference?
I feel you on the nix store + nix eval death loop, though it gleans real info. If I weren't on the Claude Max plan I'd probably feel more of the pain. And context is now 1MM tokens which means you're not running out just as it's starting to piece things together, heh.
I would have never become a power user of Linux were I used LLM to do the installation of Gentoo once upon a time. :( So do you guys not know much about the distro you are using, or how does this work? I honestly thought your comment was sarcasm, but apparently it is not.
I don’t any experience with Nix - but how does it handle software which runs its own updating processes outside the package manager? Specifically thinking about software like Discord, Slack, Docker Desktop, Jetbrains Toolbox, etc.
Is the Nix-ism to just reject using such software?
So Discord, and quite a lot of software like this has actually two layers of updates. There's updates of the web page (which is basically writing a bunch of JS to the home directory) which NixOS does nothing to prevent, and then there's updates of the host program (i.e. Electron) which NixOS disables.
Jetbrains Toolbox is in a sort of different category with tools like Rustup, since it's a package manager of its own. If you manage your IDEs with Toolbox, then your IDE versions are "outside Nix" and not managed by Nix. It's just packaged into its own pretend FHS environment and then doesn't know anything about it being on Nix. That said, updates of Toolbox itself will need to happen through your package manager.
As a last comment, why run Docker Desktop on Linux at all? Like I understand on Windows and Mac - docker is inherently tied to Linux so the Windows/Mac apps abstract away the fact that it's running a VM and doing a bunch of port mapping and filesystem mounting under the hood so you can pretend it's not running on a VM, but on Linux I've always just installed docker straight onto the host.
There’s more to Docker Desktop than just “oh it’s just docker underneath”
1. Unified experience across Windows, Mac, Linux
2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying.
3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
Regarding Docker Desktop on Linux - yeah definitely not strictly necessary. Sometimes it’s just convenient to have a UI instead of fumbling around trying to remember some cli incantation to check for dangling volumes or what-have-you. I think ideally I want to move to Podman anyways - but I’m using pop_os as my dev distro at the moment and am stuck on an older version which doesn’t have their native `podman compose` implementation yet
Except if you go look at nixpkgs half of the technologies grandparent listed are either missing entirely or in a hilariously broken state.
The true answer is that there is just some software that is antithetical to the philosophy of nix. It’s not necessarily nix’s fault that this is the case, but their purism towards resisting opaque binary blobs going into the store reflects on the actual state of what’s available in nix.
You need some impure, nonreproducible way of managing that software. So on nix Darwin I let these opaque binary blobs manage themselves via homebrew and use nix for every other case possible
That's not much different than other distros, because the way auto-update usually works, is it can't use root permissions or the system package manager (in any distro), so it has to install the newer version in $HOME. Once the update is installed, the system package becomes a trampoline to that.
I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.
For a personal desktop environment, I just install them normally when there's no up to date nixified option.
For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release.
I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
I run NixOS and the number of times ive been able to install something 'normally' (not via nixpkgs/flake) is approximately zero. You cant go to a website and download a binary and just run it. Almost every program references a shared library and wont be able to find it.
Nixpkgs is very complete in my experience, and in the instances where its not, someone usually has made a flake. The only times ive had to custom-make a flake were extremely new programs, or extremely old ones. Often the newer programs had PRs waiting on nixpkgs anyway, and were only a few days away from building properly in nixos-unstable.
They said Nix, so I was thinking about macOS + nix-darwin when I wrote that.
You're right. When I tried using NixOS as my main desktop experience for a few months, I ended up with a custom derivation for various apps I used. That's probably why I made the claude code and cursor modules in the first place.
But I'm also remembering I made my own keepassxc module because keepassxc wants to be able to write to its config file, but I also want to configure it from nix, so I had to make my module use an activation-time script to merge nix config into the keepassxc config file.
I lost interest in NixOS for day to day personal computing, though vibe-coding modules like that wasn't as big of a dealbreaker as there being almost zero laptops that compete with a Macbook.
The other pain is Linux desktop environment stuff in general like dealing with interactions between a Steam game, wayland, and wayland-satellite. Though NixOS helped there since it was easy for an AI agent to investigate the issue, inspect the nix config, and make a targeted, commented patch that shows up in git.
right now I have bought into the Nix koolaid a bit.
I have NixOS Linux machines and then nix-darwin on my Mac.
I use Nix to install Brew and then Brew to manage casks for things like Chrome what I'm sure updates itself. So the "flake.lock" probably isn't super accurate for the apps you described.
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demonstrate pinning of tools/packages to specific versions.
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
I love Nixos. Having a deterministic system is such a great way to know what your system is capable of. The only thing that bothers me is that when I rebuild my system after updating the lock file, if a package is broken the whole upgrade become impossible.
The idea is so good it’s as close to platonic as it gets. The user experience of writing your own nix expressions is so bad that it makes me angry every time I try. Not only that, but at some point the beginner help (!) meta became »use flakes, don’t do what the existing tutorials tell you, yes flakes are unstable beta and there are no tutorials but use it I beg you«. No, please, let me choose my own way to learn!
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
I haven't tried it in almost a year, but using Claude Code for setting up my nix config back then worked amazingly well. I've only dabbled in NixOS, and I'm very tempted to it for my workstation when I reinstall it in the next month.
Given how much Claude Code + Opus have improved in the last year, I'd give it a fighting chance to make a nice Nix config. I'll probably start setting up a spare laptop to get the base configs dialed in before switching over to it.
I'm not sure if I live in some kind of parallel world, because I never had any problems grokking Nix or NixOS. I started with this book[0] and haven't ever really been confused.
Flakes are de facto standard at this point. Expressions are easy once you get used to them - in fact the Nix language grows on many of us, including myself, once you internalize it.
Using AI to general Nix config is a superpower. Because the entire system is declared in a single set of config, you can basically spell cast any system you want. I one-shotted a Linux distro with custom branding for boot, installation screen, and login screen, and VPN and dev tools installed and configured by default, at a fortune 500 tech company.
Obligatory Guix plug. I've found it way easier to understand, but it has teething issues that NixOS doesn't (latest for me was a few problems with DMs). And according to an acquaintance of mine, it works reasonably well with an LLM.
This is niche and HN is full of these back and forth comments. One thing which a particular type of crowd will appreciate is being able to apply simple patches to constantly-up-to-date packages.
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
Same but with kernel. What lead me to nixos: company gave me a laptop with iGPU that wasn't supported by any released linux kernel. There were patches waiting to be merged, with nixOS making an installer image that supports my machine was simple.
If you don't mind a very limited set of software, the way tinycorelinux is setup can also allow multiple different tcz installed
These two Linux distros essentially allow two different versions of same software/libraries (glibc/python whatever) installed
(Gobolinux explicitly states that whereas I find it to be an unintended but elegant consequence for tinycorelinux but I recommend taking a look at Gobolinux)
Yep disk space and learning curve are the two major downsides to Nix. The former has never been a problem for me in practice, just run garbage collection once a month. The latter was a big problem, but is now mitigated for most people by LLMs.
Yes, however the space is not „used up” in a classic sense. It’s a cache, so you can give up some of it and reclaim your space. Fresh after a full cleanup it won’t take much more than a regular distro.
The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.
For me, it's the difference between taking your medicine a bit at a time on your own schedule or taking it all at once as an unwelcome surprise. Sure, setting up file system mounts or adding udev entries is easier to do once in Ubuntu than in NixOS, but I only need to do it the one time with NixOS. Thereafter, the config serves as both documentation and backup. For a hobby self hoster like me who occasionally shoots himself in the foot and has to rebuild a system, it is ideal. I don't know if it really saves me time, but I do know it saves my sanity.
I am no nix whiz, but it's the only OS I run outside of containers. Anything I can't easily get with my nix config I shove into a container, run it as a quadlet, and call it good.
Imo it's the opposite. Since the system is defined in config files, an AI agent can look at live system state/errors vs. the config file and do all the work of figuring out the issue.
Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level.
Maybe nix is a downgrade for what you do. But I loved nix so much that I also migrated to nix on macOS (nix-darwin). No more homebrew.
nixos updates tend to be a lot less eventful than others distro, in fact the way it largely prevent system borking when updating, is spiritually freeing.
It's also simple to setup dev environments with nix.
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
It's also great for the AI era, copilot is really good with that stuff.
Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
Claude Code has to be actively steered, because while it knows some nixpkgs it surely doesn’t know it enough. E.g. it was absolutely incapable of fixing lldap settings after system upgrade from 25.05 to 25.11. It just prodded around blindly, producing meaningless configs instead learning how the module works.
NixOS docs work for me, but I tend to just go for the nixpkgs source instead. Manuals document options but not how those are actually plumbed through, nor what remains behind the scenes like all systemd unit settings). Claude can do this too, but it goes quite weird roundabout ways with a lot of weird `find /nix/store` and `nix eval`s to get to it, slow and token-hungry (and not always accurate).
This said, Claude is very helpful at checking logs and providing a picture of what’s going on - saves ton of time this way. Plus it can speed up iterating on changes after it’s fed enough knowledge (but don’t expect it to do things right, that’s still on you). It has breadth of it, but not the depth, and that shows at almost any non-trivial task.
I feel you on the nix store + nix eval death loop, though it gleans real info. If I weren't on the Claude Max plan I'd probably feel more of the pain. And context is now 1MM tokens which means you're not running out just as it's starting to piece things together, heh.
Is the Nix-ism to just reject using such software?
Jetbrains Toolbox is in a sort of different category with tools like Rustup, since it's a package manager of its own. If you manage your IDEs with Toolbox, then your IDE versions are "outside Nix" and not managed by Nix. It's just packaged into its own pretend FHS environment and then doesn't know anything about it being on Nix. That said, updates of Toolbox itself will need to happen through your package manager.
As a last comment, why run Docker Desktop on Linux at all? Like I understand on Windows and Mac - docker is inherently tied to Linux so the Windows/Mac apps abstract away the fact that it's running a VM and doing a bunch of port mapping and filesystem mounting under the hood so you can pretend it's not running on a VM, but on Linux I've always just installed docker straight onto the host.
1. Unified experience across Windows, Mac, Linux
2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying.
3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
Regarding Docker Desktop on Linux - yeah definitely not strictly necessary. Sometimes it’s just convenient to have a UI instead of fumbling around trying to remember some cli incantation to check for dangling volumes or what-have-you. I think ideally I want to move to Podman anyways - but I’m using pop_os as my dev distro at the moment and am stuck on an older version which doesn’t have their native `podman compose` implementation yet
The true answer is that there is just some software that is antithetical to the philosophy of nix. It’s not necessarily nix’s fault that this is the case, but their purism towards resisting opaque binary blobs going into the store reflects on the actual state of what’s available in nix.
You need some impure, nonreproducible way of managing that software. So on nix Darwin I let these opaque binary blobs manage themselves via homebrew and use nix for every other case possible
I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.
For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release.
I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
Nixpkgs is very complete in my experience, and in the instances where its not, someone usually has made a flake. The only times ive had to custom-make a flake were extremely new programs, or extremely old ones. Often the newer programs had PRs waiting on nixpkgs anyway, and were only a few days away from building properly in nixos-unstable.
You're right. When I tried using NixOS as my main desktop experience for a few months, I ended up with a custom derivation for various apps I used. That's probably why I made the claude code and cursor modules in the first place.
But I'm also remembering I made my own keepassxc module because keepassxc wants to be able to write to its config file, but I also want to configure it from nix, so I had to make my module use an activation-time script to merge nix config into the keepassxc config file.
I lost interest in NixOS for day to day personal computing, though vibe-coding modules like that wasn't as big of a dealbreaker as there being almost zero laptops that compete with a Macbook.
The other pain is Linux desktop environment stuff in general like dealing with interactions between a Steam game, wayland, and wayland-satellite. Though NixOS helped there since it was easy for an AI agent to investigate the issue, inspect the nix config, and make a targeted, commented patch that shows up in git.
right now I have bought into the Nix koolaid a bit.
I have NixOS Linux machines and then nix-darwin on my Mac.
I use Nix to install Brew and then Brew to manage casks for things like Chrome what I'm sure updates itself. So the "flake.lock" probably isn't super accurate for the apps you described.
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
A WIP NixOS config for working with agents:
https://github.com/dangirsh/tsurf
If you’re itching to try Nix, now is the time.
Can't imagine going back to the status quo where my system is the accumulation of terminal commands over time instead of a config file.
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
I haven't tried it in almost a year, but using Claude Code for setting up my nix config back then worked amazingly well. I've only dabbled in NixOS, and I'm very tempted to it for my workstation when I reinstall it in the next month.
Given how much Claude Code + Opus have improved in the last year, I'd give it a fighting chance to make a nice Nix config. I'll probably start setting up a spare laptop to get the base configs dialed in before switching over to it.
[0]: https://nixos-and-flakes.thiscute.world
Using AI to general Nix config is a superpower. Because the entire system is declared in a single set of config, you can basically spell cast any system you want. I one-shotted a Linux distro with custom branding for boot, installation screen, and login screen, and VPN and dev tools installed and configured by default, at a fortune 500 tech company.
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
That is in between "use it for very short period of time" and "use it forever"
If you don't mind a very limited set of software, the way tinycorelinux is setup can also allow multiple different tcz installed
These two Linux distros essentially allow two different versions of same software/libraries (glibc/python whatever) installed
(Gobolinux explicitly states that whereas I find it to be an unintended but elegant consequence for tinycorelinux but I recommend taking a look at Gobolinux)
I am no nix whiz, but it's the only OS I run outside of containers. Anything I can't easily get with my nix config I shove into a container, run it as a quadlet, and call it good.
Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level.
Maybe nix is a downgrade for what you do. But I loved nix so much that I also migrated to nix on macOS (nix-darwin). No more homebrew.