The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town.
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows.
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.
I've been trying to get nixd LSP to work with Claude Code but I got stuck as they gatekeep it behind their "plugin" system and you can't just configure it in settings.json to point to a nix store path like mcps :(
My usual solution is to just clone whatever I need. e.g. in this case just clone nixpkgs and put in your instructions that it should do a git pull to make sure it's up to date and then refer to that whenever doing anything with nix. Agents are really good at using grep to explore repos even for something completely internal. Then you don't need any config or special tools. e.g. for work I just have a directory with like 30 repos cloned and my base AGENTS file I use says to refer to either them or live system state for ground truth. I basically never encounter hallucinations.
Same goes for the harness itself. Want to know how Codex works or whether it can be configured in some way? Clone it and ask it to look at itself.
This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.
The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating.
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
> As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id.
> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.
How would "bit-identical" or "free of side effects" make an actual difference in practice?
Rollback is already very easy with filesystem snapshots.
Configs are already tracked by etckeeper.
New laptop: either copy the whole drive or the package list and dotfiles. Also, how often do you have to get new laptops for this to be relevant ?
The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk.
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that:
(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)
(2) Make destructive changes like install a new windows manager, some drivers etc.
(3) If everything worked out well, continue
(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before
This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.
Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.
A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code.
There is no distinction between package maintainers and end users. They have the same power.
In the meantime i dont expect Debian users to ever write a package themselves or to modify one.
Arch Linux also has a long history of people writing their own package specs (AUR) and is relatively simple too of course.
Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.
This has benefits and downsides. Benefit is that everyone is treated as a power user. Downside is that power users are horrible at writing docs and this philosophy is my main theory why NixOS docs are so .... Bad
Fedora (and RHEL) end user and developer docs are written for quite different audiences
Yes I just replied to your other comment with the same observation. It reminds me of an article by Paul Graham, I forget which, who expressed the difficulty of explaining to programmers who lack an abstraction just how good the abstraction is. Anything you can do with NixOS, you can do with any distribution, because it isn't magic. But somehow, more stuff becomes possible because it gives you a better way to think.
(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)
yes i think you've hit the nail on the head. I tend to view NixOS not as a distribution, but as a distribution framework. The system configuration is the sources for an immutable distribution as much as it as system configuration.
You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.
Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.
But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
That’s a great way to get one of the benefits of nix. But you still can check that snapshot into version control, share it with all your machines, etc.
You're right ... you cant check that snapshot into version control and share with your machines etc. When you need that level of control and need to scale your configuration to other machines NixOS sounds like the right choice. If it's for your own machine and you just want to try out a new windows manager non-destructively use snapshots.
Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.
Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.
I use Nix for my homelab servers, and I'm using AI to be my IT support staff essentially. I don't need to ask AI for help installing hyperland, that is trivial as you say, but setting up nginx port forwarding? samba configs? k3s or k8s? Yeah individually any one of those things isn't very hard. But instead of spending 30 minutes reading through config examples and figuring out where it's setup I can instead spend 30 seconds just telling AI what I want, skimming the output to see if it's looks reasonable, and then doing a good ol' `git commit` of the config file & kicking off the "now go do it" nix build command.
And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
I think they just mean that the fat that they can do it this way says a lot about the os. No need to get into the weeds on exactly how to install hyprland. It was an example.
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
That would be Ubuntu and Docker. With Guix you can set everything for under a config.scm file in a reproducible way, you can even export a guix recipe as a Docker container, appimage or even as a standalone package for non-guix systems. That's unvaluable for scientific environments where the contrainsts must be set inmutable and unchanging.
But keep bitching about obsolete barely-GNU/Linux distros (the don't even use Linux-Libre) made to copycat NT with the registry, svchost.exe, MSI packages, DISM. (Gnome/OSTree/SystemD/Flatpak). Aka IBM's attempt to pick up RedHat and create another AIX but leeching everything from the community.
With Guix you can even crosscompile and export software to Win32 (for instance, Icecat, VLC...) and you don't need to nasty incantations with flatpaks.
If you want to live in 1993, go on. I already moved past Unix with 9front (my main machine, a n270 netbook, I code in C for expersite, rc/AWK for automation and EForth for fun) and Guix (sadly non-Guix because of wireless until I can afford a compatible laptop with ath9k and Intel).
9front it's my 'brain detox' machine, it's not Unix, it's even simpler than Unix. No wayland, no flatpak, no crap. Build once, run it again as it's a static binary. Guix it's to deal with corporate crap because of $JOB. You know, today they requiere docker and similar crap and with a guix environment I'm free to deploy at home everything at want.
For Go code I can just use 9front modulo some expecial cases (Yggdrasil-go needs a tun/tap interface, but with 9front you can just open() /net/ether/ files and you are free to inject whatever you want.
I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them.
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
NixOS's greatest weakness historically has been bad/missing docs, especially docs of the "I have X how do I do Y?" nature. This led to a situation where thousands of users asked those questions on forums and received answers covering a spectrum of possible paths forward. The other path was to spend a bunch of time trolling through module sources to find the options you need and understand what they were going to do and how they would interact with each other.
Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
I was already happy with my big ball of nix config for various servers, but claude does shave off a bunch of rough edges and make it more pleasant to interact with. I also resolved a couple nagging issues that had been around for a while.
It does tend to hallucinate but thats the great thing about nix... if it builds its probably right!
I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet.
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro.
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised.
It's so nice! Underrated for sure.
And if you watch what it's actually doing during a session like that, it's basically exactly what a human would do: run the build, find the error, google the error, consider 2-3 possible fixes, pick one and apply it, repeat. Afterward, look at the various patches and fixups and decide if a refactor is necessary.
I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"
Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).
I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate.
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.
I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system.
But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
Yes. That's why I'm using NixOS as well, despite all the terrible jank it has.
Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.
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.
Can you do those ad-hoc though? I was looking into this too. I feel like it requires a system config change, apply, and then you need to do container start + machinectl login to actually get a shell.
That's definitely what I want... most of the time.
* declarative mode, where your guest config is defined within your host config, or
* imperative mode, where your guest NixOS config is defined in a separate file. You can choose to reuse config between host and guest config files, of course.
> 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".
NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.
There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.
If containers are safe enough for ur use case then just use nixos containers they just a few more lines to setup in a regular nixos config
If it isn't enough
there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
That's hard given most apps have dependencies and often share them.
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
Not only is it composable, but it is generalizable. So yes there is also chef, ansible, apt, uv, nodeenv, etc... or there is just nix. It is able to be the "one tool" to rule them all, often with better reproducibility guarantees.
I almost switched back to Fedora Bazzite to get a working gamescope, but realized I can get HDR in sway and its actually more stable than Valve's mess of gamescope. Even though I have to use "--unsupported-gpu" flag, my Nvidia card works wonders in Sway, where as gamescope gives me a blinking cursor and segfaults.
Not the greatest fan of python, but when I've got to run a python script, I do `nix-shell -p 'python3.withPackages (ps: [ps.requests])' --command 'python3 your-script.py'` Note that there is one argument to -p and one argument to --command -- both are quoted. The argument to -p is a nix expression that will provide a python3 command, referring to a python3 with the requests package. The argument to --command is a bash script that will run python3 with the argument "your-script.py" i.e. it will run your-script.py with the python3 that has the requests package.
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier.
Easier and largely compatible with the rest of the world. Solving problems with "If we all switched to NixOS..." is a non-starter in most organizations.
My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!
In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.
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.
You know, I used to agree, but what I realized, is I am a software engineer, and I'm used to working in large projects with source-code as the only documentation.
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
> I'm used to working in large projects with source-code as the only documentation.
As a software engineer I have an opposing attitude towards this. I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
There are significant alternatives to NixOS like bootable containers and OSTree which are more useful and better documented. If Nix project really cares about being competitive and adopt users, they have to document their stuff. They are already going against the grain and ain't nobody has time to put up with their weird language and their subpar documentation.
> I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
I mean, I'd argue there is significant potential, but really, for me it's just easy because I've been doing it for 20 years, and documentation is always fundamentally worse than code in some important ways.
> If Nix project really cares about being competitive and adopt users, they have to document their stuff.
This is one of the good/bad things about OSS.. most users don't provide positive value to the project. So do they really want to adopt users? Shrugs but the project is certainly competitive.
> for me it's just easy because I've been doing it for 20 years
C’mon, just drop the “greybeard” act. Nix not having proper documentation is bad practice, period. No ifs buts or howevers, it’s just an objective fact. Good documentation is always (ALWAYS) a net positive, and this is an OS with it’s own unique mindset and way of doing things, good documentation is essential. End of.
no thank you, there are things I do not want Claude to have rwx on. like my entire f*cking system. I run llms in a docker container with just the folder I'm working in.
If you grant access to the Nix daemon socket but not writing outside the current directory, that's an effective sandbox. It allows evaluating derivations but not actually installing them.
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 do, but it somehow tends to forget how to do things right now and then - despite having notes in memories system - and starts to do them in its own weird ways.
I’m going to experiment with skills next, or maybe make it build a few helper scripts for itself to quickly get some module source from nixpkgs matching flake.lock without having to think of it all. I’m positive about Claude for nix management, merely saying it’s not something that “just works” for now and reading nix code is still on the human part of the tandem.
This said, to be fair - when it gets the approach right, it excels. I was setting up Ente for photos backup and sharing, and it produced a nice overlay with custom patches for my needs from just “figure out why /shared-albums/ redirects wrong and fix”. Found the module, the package, pulled source, analyzed it, proposed a patch (settings weren’t enough), did it - I only had to test, and only because I haven’t provided it with a browser. Felt amazing.
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.
The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just in time through daily exposure like anything else.
Coming from Ansible with hand-written config templates this was honestly a friction point for me - I felt like NixOS is trying to actively hide what it's actually going to configure. It's gotten better now that I read some nixpkg service sources but from time to time I still feel the urge to just directly manage my systemd units, sshd configs and whatnot. Like, sure it simplifies the setup but at the same time also puts another abstraction between me and the software I'm using.
You always have the option to do your own custom thing like use nix config to manage /etc/iptables.rules.
NixOS does you one thing better by giving you the option to configure things without caring about the underlying implementation, like whether the firewall uses iptables or nftables or something else.
I agree with the many levels of abstraction, but at the same time, directly managing systemd units is also so much easier with Nix then any other distro I've tried.
Nothing about this changes with Nix nor AI agents.
You can read documentation on an as-needed basis or to your heart's content.
The point is that the majority of the day to day changes I make to my desktop environment aren't so critical that I need to do more than read an AI agent's proposed changes to my config and accept them when they look reasonable.
And I don't think looking up the exact config options to NixOS' networking system does anything to increase my knowledge of the OS. It's just a triviality.
You hate that I couldn't remember whether nix has array delimiters on the spot?
Jeez, tough crowd.
Though it also kinda represents this pride over triviality that some people latch on to in the AI world which is odd since it's also only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker, I would have spared you the negative emotional reaction.
In the pre-AI world, you would have probably not been so harsh since it's understandable that someone make that mistake with such an idiosyncratic language like nix that almost nobody writes full-time. Yet in the AI world, you demand more from humans.
> [..] only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker [..]
That's true, and I should've been less rude in my previous comment. Sorry.
(Though note `nix eval` would've sufficed, no need for the probabilistic kind of clanker)
> Yet in the AI world, you demand more from humans.
But this isn't true. In my opinion `learning >> depending on an LLM` and my gripe is that it seems like the former is being displaced by the latter. In the pre-AI world I would've known that the person making the mistake wasn't making it because they outsourced their skill.
So I'm not, in fact, demanding anything more than in the pre-AI world.
The other poster is being a jerk, but your point doesn’t really refute theirs: if you can’t even be bothered to check for an array delimiter, instead passing that on to an AI, how will you ever learn?
People are being more demanding of humans because humans are taking knowledge and learning for granted. All this abstraction has a cost, and the cost is you.
Things are falling out of your memory all the time as a function of how often or seldom you do something, how trivial or superficial the information is, and how minor the difference between other tools you use regularly.
Despite many years of experience, I still sometimes get this wrong in Python or its equivalent in the other languages I regularly switch between:
from math import sqrt as s
import sqrt as s from math
import sqrt from sqrt as s
The difference here is that, because I admitted to using AI, I don't get the grace of making the most trivial mistake in a forum comment.
And suddenly we pretend that had I just written it by hand a few more times, I would never err again in forum comments, despite making similar errors this week in languages I've used to write millions of lines of code across decades.
Well, there's layers. When I started using nixOS I read through the guide and wiki but I also used LLM assistance to help create a stable starting point. Then over time I've incrementally added new things to my configuration through a mix of LLM assistance and reading online material.
I think the initial migration towards nixOS is the hardest point, since it requires learning a bunch of new things all at once in order to get the system into a usable state that matches your expectations and preferences. The key benefit of using an LLM is that it makes it really easy to get your system into a useful initial state, and then you can safely learn and experiment incrementally with a mix of tools.
When I started off I didn't understand everything, but at this point I feel I have a very good understanding of everything in my configuration file.
I'm glad that I'm not the only one. I don't want to move from "Microsoft knows best" to "Claude knows best but hey, at least you review the output by looking up the not so good documentation".
Kind of an interesting thing here where if this is how you view it, it kind shows in itself why you don't actually need it.
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
The upside of Nix config is that it's the state of my system in a declarative config file.
I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ...
This is difference between me and a non-nix user, not whether we can rattle off the exact state of our live system from memory.
The non-nix user has to query live system state, if such query tools even exist for their question, and I get to read a config file. And I get to maintain my system config in git, and I get to deploy my config on all of my machines.
But if you are not reading or comprehending the config file, why does it make any difference? You ask AI to purge ffmpeg from your system, it will probably know more about doing that with apt than with nix, right? And if the input on your end is "remove ffmpeg from my system" or whatever either way, what's the need for nix? You will be much happier just editing /etc files and such in the standard way, rather than hoping your AI knows the (sometimes sadly inconsistent) way nixos handles the particular module/service/whatever you are dealing with.
For me, the difference is that there is no way in hell that I want to give an AI assistant full access to configure my system live. With a declarative config, the only access it needs is to an isolated git repo.
But if the declaritive file is not read/understood, what is the difference? At some point, you're gonna run sudo nixos-rebuild, and that is the whole system on the line.
This whole thing has been about explicitly using LLM instead of learning nix. So sure, definitely agree with about the niceness of using nix in general if that is all you are saying, but also not sure what you are trying to argue for anymore.
HN: AI coding is still coding because you need the domain knowledge to steer AI in the right direction, read the code, understand it and fix it when necessary.
Also HN: No idea how this OS works, screw writing proper documentation, just ask Claude to do it! Wee!
On the contrary, the model doesn't actually add any lock-in. When GP wants to switch to free model the config files are still there. There's no lock-in, as I see it.
It is not about lock-in, it is about free software being usable without resorting to non-free software. One of the free models is usable for this would be a better shift and that might be workable but I'm not sure about how well they'd work.
I tried NixOS a few months ago, when I had to choose a new OS for my laptop.
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
I can completely understand how you were driven away. If you ever want to give it a go again:
> there's "Flakes" which I never quite understood
Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).
On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.
What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone
As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.
> manually edited /etc files.
You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].
Yep, i am doing the same. I have a central remote flake repo where all my machines, services, etc are defined and they all run tweaked autoupdaters to periodically do full updates. I push commits and wait and forget. It feels like maintaining your distro everywhere, no matter where you ssh in. And soon, i will migrate that repo off a central platform (github) into radicle or something and turn some of my machines into seeders. Then, with offsite data backups, my house could burn down and github go dark, i could still recover, maybe in the future even bootstrap from my smartphone. A big step towards digital sovereignity.
> Hi, I just wanted to know, where can I find the documentation to know more about this contrib.lib.file.mkOutOfStoreSymlink option ?
> Well, since is a very simple function, no documentation is really needed.
I've been gradually transitioning everything to NixOS, starting with my homelab mini PC, then my Framework laptop, and now my daily driver desktop. It's hard to imagine going back because the pros are so strong compared to the cons, but the docs situation is truly dire.
That’s my feeling when reading nixos forums. People are willing to help but don’t realize how little newbies know about nix when asking for help. The first month of nixos was a massive uphill climb for me, and that knowledge doesn’t stick well because I get to interact with nix every few months to tweak things, not weekly or daily.
It’s a solid os, and I’m enjoying it, and I love that I can’t break things while tweaking. But the docs are and discussion threads are not written for beginners (it’s really hard to write for beginners).
Sibling comment does a good job of going into flakes, but to answer this
> Do you install a package or a service
A package is like the raw software installation. So eg the bash package is just a wrapper around building bash from source (theoretically from source at least... you can also define a package as being a binary distribution as long as you specify the content hash). The service (actually the _module_) is for everything else around software installation. So, eg, the bash _package_ will build bash and have it available for you to put in your path but the bash _module_ might also configure your .bashrc and set it up as your users shell. It would also generally refer to the bash _package_ so you can do all that plumbing but specify a certain version of bash you want to use.
Another common example: a plex package would again build the plex software but a plex module would perhaps create a plex user, setup systemd units, open your firewall, and create a media directory.
EDIT: the next layer of confusion is that modules (which sort of are a secret-sauce of nix and so naturally you will want to use them a bunch) are specific implementation details of multiple subsystems in nix. Meaning, nixOS and home-manager and nix-darwin all have "modules" but they are not compatible. Each has its own "idea" of what modules are and nix itself doesnt provide this natively. That means things get a little more complicated/involved when you use those ecosystems together. Its not too bad but it is annoying.
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.
My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.
If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.
Such a pity that the article didnt touch on running rust nightly or the sometimes statefull nature of user configs of some programs. The 5% painful part was just around the corner.
Fair point but I've stopped trying to declaratively manage stuff in nix that has its own idiosyncratic state management. That way youre just using nix to run an installer.
Yeah, I've been using Unixey stuff for almost twenty years now (most of it Linux, and fell for the siren song of macOS for about four of them).
I liked Arch and Ubuntu and Mint and OpenSUSE well enough when I used them first, but once I actually tried NixOS it felt so obviously correct that it started to bother me that it's not the default for everything.
Being able to temporarily install things with nix-shell is game changing, and being able to trivially see what's actually installed on my computer by quickly looking at my configuration.nix is so nice. "Uninstalling" things boils down to "remove from configuration.nix and rebuild".
The automatic snapshots upon each build allows me to be a lot "braver" when playing with configurations than I was with Arch. I was always afraid to mess with video card or wifi drivers, because if I screwed something up and if I didn't know how to get back to where I was, I might be stuck reinstalling to get back to a happy state. This didn't happen that often but often enough to have made me a bit weary about futzing with boot parameters or kernel modules. Because of the automatic snapshots with NixOS, it's much easier (and more fun) to poke with the lower level stuff, because if I do break something in a way that I don't know how to fix, the worst case scenario is that I reboot and choose an older generation.
This is a bigger deal than it sounds. For example, with my current laptop, there was a weird quirk with my USB devices having to "wake up" after not being used for more than thirty seconds, meaning that I might start typing and the first three or four words wouldn't go through. After some digging, I found out that the solution is to add "usbcore.autosuspend=-1" to the kernel params. I did that and it worked.
If I had still been running Arch or Ubuntu, I probably would have just learned to put up with it, because I would have been afraid to edit kernel parameters because of the risk of breaking things in a way that I don't know how to fix.
I love NixOS. I have no desire to leave, or at least I have no desire to abandon the model. I've considered changing to GNU Guix System since I like Lisp more than I like the Nix language, but those FSF-approved distros can be a real headache for people who actually have to use their computers.
> those FSF-approved distros can be a real headache for people who actually have to use their computers.
This is now a tired discussion; the use of nonguix (https://gitlab.com/nonguix/nonguix) is well documented, there is no practical difference after initial setup between using a regular distro and one of “those FSF-approved distros”
I am sure you don't do it on purpose, but could you stop spreading FUD? (specially given you acknowledge “ I've considered changing to GNU Guix System”, so you're here relaying 3rd party opinions, not your own)
> like with apt/brew + 20 handwritten bash scripts
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
I've been using apt for 20 years too and was never a fan of it, canonical repos are never up-to-date and managing ppas is a pain. Yes I'm very hype about nixOS (and that's a rare thing for me), but it is just really really good.
I understand that "just check it out" is not the best advice because the setup cost to using nixOS is really high, and the learning curve is really steep, so it's not like you can give it a whirl for a few hours to experience the workflow. But believe me, once you are used to it, it just so so much more convenient. I'm currently managing my dev laptop, home PC, a WSL, and a hetzner server all in the same repository (allowing for a lot of code reuse). Everything is super orderly and split into modules, everything is declarative, I can roll back to a previous build of my system if I mess up installing nvidia drivers or iwd or bluetooth etc.
It's also not like installing software is harder than with apt (oftentimes it is easer, `programs.firefox.enable = true`) so after you've paid the setup cost there is just no downside. It's a bit like react vs jQuery, or Kubernetes vs hand-written deployment scripts.
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.
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.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.
Doesn't that pin me to a particular versions of nixpkgs? That's fine if I only care about nodejs, but if I want to maintain particular versions of different tools, it won't work.
Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned ways.
I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.)
I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.
You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different _exact versions_ (or likewise, in CI it also will be the exact same). And in general thats what people are trying to achieve on teams by pinning to full semver. So thats what I mean by its generally not needed on nix.
However, to actually address your question it would be something like this (with ruby also added for comparison of whats possible depending on the language ecosystem you are using)
Pinning by version number isn’t a crutch; it’s more a question of mental models. Most people find it more intuitive to identify a world by describing the things in it than to fix the states of the things by identifying the world where they have those states. Nix sometimes feels as if someone read Kripke and missed the passage about possible worlds being a figure of speech.
In other words, many of us don’t think that version numbers are a crutch to be used in the absence of a totalizing hash of the entire state of the universe. We actually think that version numbers are, for many practical purposes, better than that.
I dont mean to imply its a crutch. Im merely pointing out that even though people say they want to "pin to a specific version", there are usually two different motivations:
- one group of people who want guarantees that what they install on their machine matches on their colleague/CI/prod machines. For this group, the nix happy path basically serves all their needs really well. It can capture nearly any sort of software dependency they have regardless of ecosystem and it pins to actual content hashes in most cases. They only care that the high level versioning is met, because again its reproducibility that they care about
- one group of people want guarantees of specific software versions. Nix still handles this, but its "more work" because nix is by default a snapshot of the entire world, of which your target software is only a slice of. And most nix snapshots of the world are "what were the most recent versions of each software package at this point in time". So you generally need to compose together multiple snapshots of the world. It works fine, its just more work (and more disk space).
In practice, again, I think most teams are served better by being in group one, but dipping into group two when they either need an "unreleased" version for software they depend on or when they need an older/unsupported version of software they depend on (or a nix release breaks their workflow). Then nix shines by being able to mix and match between different snapshots in composable/reproducible ways.
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
The UX is the big benefit, especially on teams who may not even know what nix is. I held off on exposing my nix setups for a long time, but devenv has made it possible to check things in without losing a ton of time to tech support.
“Needed” is too strong, but this does not provide services, does not provide project-specific scripts, does not setup LSP, does not setup git hooks, can't automatically dockerize your build, does not support multiple profiles (e.g. local and CI), etc.
Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).
That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.
devenv also has tasks/services. For example you need to start redis, then your db, then seed it, and only then start the server. All of that could be aliases, yeah, but if you define them as aliases you can have them all up with `devenv up`. It even supports dependencies between tasks ("only run the db after migrations ran")
home-manager manages your whole user's environment & desktop.
devenv does not do any user-level change (you will not be able to make it configure your WM), but works at the directory level.
For instance I'm currently working on a Rust + C++ project, and my devenv, whenever I enter this project folder: make CMake/g++/cargo/cbindgen available, enable a couple scripts to longer CMake invokations, set-up everything required for C++ and Rust LSPs, and create a couple git hooks to validate formatting etc.
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?
+1, Guix is quite good with some tricks up it's sleeve compared to Nix.
I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.
On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.
I mean it's pretty wild to take s-expressions and not call them extremely terrible to read. The nix language sucks really badly, but I gladly take it over writing S-expressions.
It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.
> you're going to be writing the (name value) form for 99% of it.
That's exactly the part that is wrong with Guix, and Scheme in general. Scheme has associated lists, they are written as '((name . value) ...), but since that's too ugly everybody makes macro wrappers around them to get them down to just (name value). But that means you aren't dealing with an obvious data type anymore, but with whatever the macro produces and if you want to manipulate that you need special tools yet again. And then you have record-type and named arguments which are different things yet again, but all serve the same name->value function as an associated list. Names themselves are sometimes symbols, sometimes keywords, and sometimes actual values. Same with lambda, sometimes you need to supply a function, other times there is a macro that allows you to supply a block of code.
It's like the opposite of the Zen of Python, there are always three different ways to do a thing and none of them as any real advantage over the other, they are just different for no good reason and intermixed in the same code base.
I have never seen anything else use the (name value) syntax. You do deal with obvious data types, the REPL tells you exactly what those data types are (records, in the case of Guix). Schemes outside of Guile don't even have keywords, much less named arguments.
Are you complaining that a language has both associative containers and structs? Which one do you advocate for removing in Python to keep up the precious "Zen"?
Lisp programmers have used editors that count the parens for them for decades. Many use something like paredit that simply automatically adds the final paren. I've written significant amounts of Lisp and you simply don't see the parens. You might as well complain about French having all those accents. It's just a different language. Learn it and you'll see why.
I can write lisp. That a lot of lisp programmers require special editors to handle it should tell you enough. It's not that the language is unworkable. You can definitely write stuff in it. The point is that it is quite far from something that should be written by people, in my opinion.
Are you really going to argue that a good programming language is one where you can construct it character by character, by hand? Emacs has existed for decades and it runs basically anywhere. Nobody is programming in ed (well, apart from Dave Beazley[0]). With LLMs the world is finally catching up to the fact that programming isn't typing characters one by one. Lisp programmers have been at this for decades.
I consider it essential for a programming language for people that it is easy to understand things by looking at things locally. Requiring/strongly encouraging extremely deep nesting is not conducive to that.
This is not some weird opinion I have. There is a reason "flat is better than nested" is part of the pretty popular zen of Python.
Most code is read much more than it is written, at least I read much more code than I write. So for me code should be optimized to be read as plain text as that is basically what every tool uses. Requiring a separate tool to get basic readability is not really acceptable. I can't do that on github, I can't do that with the various diff tools, I can't just quickly cat a file or use the countless other tools that are designed to present plain text.
If I then can choose between guix and a language that doesn't require these hoops and extreme quality trade off the choice is not hard.
Anyway if you think guix is better than nix, than nothing stops you from using it.
I just have a hard time taking such a comment seriously, because I have made it myself. Many times even. My second comment on Slashdot in 1999 was a comment just like yours. I try to tell myself it is ok because I was still a teenager.
7 years later I had to write common lisp and I think the parens were a problem for about a week. Since then I have written many thousand lines of lisp code. I usually go back and forth on what I like the most. ML (ocaml mostly) or (guile) scheme. In just about every other language (except maybe factor) I miss the macros (even syntax rules ones) way more than I like the extra expressiveness of, say, Haskell. [0]
Wisp is a part of guile. So you can write your own config using it. It is not completely straightforward, but if you really hate parentheses it is a way. Or you continue the wonderful string gluing of Nix. Whatever floats your boat.
[0]: I do miss typing sometimes in scheme though. I have thought about vibe coding a prototype of an s-expr language that compiles to f# AST.
This isn’t about whether someone can get used to parentheses. Obviously they can. I don’t doubt your extensive experience there. The question is what the language optimizes for by default.
My argument is that S-expressions optimize for structural uniformity and macro power, but they do so at the expense of plain-text readability without tooling. And that trade-off matters in contexts where code is frequently read outside of a fully configured editor, code reviews, diffs, quick inspection, etc.
Saying “editors solve this” doesn’t really address that, it just shifts the burden to tooling. In contrast, many other languages aim to be reasonably legible even in minimal environments.
So I’m not arguing that Lisp is unusable. I’m saying it makes a different set of trade-offs, and for my use case where I spend much more time reading other peoples code in some web portal and with basic terminal tools those trade-offs are a net negative. I would expect this trade off holds for most code produced.
> This is not a language that is optimizing for being written by humans
I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation.
The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. Seems to me like you deliberately searched for the most atypical example, that you're now misrepresenting as 'regular', when it is highly atypical.
And honestly, what would that look like in some 'more normal' language?
);
}
);
];
};
)()();
Better?
I will never understand this fear response some people have to seeing `(fn a b)` instead of `fn(a, b)`.
I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently.
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.
> Something that happens in 4.5k lines twice is hardly rare.
Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?
Looking at a lot of nix package expression: Quite a bit. Besides, just taking a way a single brace gives 7 hits. Still a ridiculous level of nesting. So I don't go with your reasoning that these are some kind of super special cases. If something happens so often in 4500 lines of code you cease the right to claim it is special.
It happens 1/2290 (0.04%) of the time. You are significantly more likely to guess a stranger's birthday totally at random (0.27%) twice in a row (0.07%). If you don't consider that exceedingly rare, then you and I need to hit up Vegas immediately.
You are projecting a programming style onto Lisps that's quite alien to them. Lisps tend towards small, discrete functions that are composed together. It is the ordinary languages that tend towards deep branching and nesting; Lisps generally favour recursion and function composition instead.
There are 101 `(package` definitions and 58 out of them have more than 6 nest level, which I would consider more than excessive. That's an incidence of over 50%.
Beside I don't think I'm alien to the functional way of writing things. I write mostly Haskell professionally. But Haskell doesn't casually suffer from making insane expression nesting the default.
You may not be a stranger to the functional style, but you do seem a stranger to the Lisp style, which is closely allied. A lot of FP originated in Schemes and Lisps - Haskell is greatly influenced by the ML family, which is itself greatly influenced by Lisp. Modern FP is a style that would be recognisable to a Lisp programmer fifty years ago, when everyone else was writing imperative soup.
I don't think there's much anyone can say that's going to change your mind. You're strongly coming off as though you've formed a view, based on little experience, and will now Ctrl-F cherry-picked examples to sustain it rather than listen to any contrary information. I respectfully suggest greater open-mindedness and a willingness to reserve conclusions in the absence of data.
I personally don't use Lisp too much, so I'm not particularly invested in this exchange, but I know from experience it's not even remotely what you're describing it as. Everything about Lisps tends towards minimal nesting, from the use of paredit to edit expressions through REPL-based workflows.
The only thing this exchange has done, as someone who programs in FP exclusively, is make me reminisce about and yearn for Lisp. It's a wonderful language for FP.
That link isn't working for me (something about AI detection), but as a point of accuracy, those aren't derivations, they're simple source files. Derivations are generated out of them.
As for the closing braces, would it be better if you had a newline between each?
I liked NixOS pre-LLM era, since it allowed me to manage a couple of servers in a reproducible way. Ability to reboot back to a stable configuration felt like magic.
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
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.
Nix isn't really much of a hobby. It does require some learning because it's different, and front-loading the work to build your config, but after that it's amazingly reliable and easily extendable. You can keep everything up to date with a single command.
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
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.
I feel the same way about Guix with nonguix channel enabled. NixOS is awesome but I prefer Guile to Nix's language and I enjoy the docs more. But definitely sister OSes.
There's nowhere near enough love for Guix. I don't understand it. It has far better foundations. I would never invest time into some "config language". Using a real programming language has huge benefits, and it's a good one (Scheme).
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.
> 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
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.
One thing I love about NixOS is how easy it is to run packages from different sources. For example, I needed an old package that's been removed from nixpkgs several years ago. To run it I just had to add an old release of nixpkgs as input to my flake.nix and add the package from this input. It pulls all its dependencies from that old release and there's zero conflict with the other packages.
I still really wish there was a NixOS, but without the quirky filesystem/linking setup.
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
i've been tempted by NixOS for servers but keep going back to Debian. the reproducibility is amazing in theory, but when you need to debug a DKMS kernel module build at 2am on a VPS, having "just apt install" is worth a lot. maybe NixOS for dev workstations, Debian for production VPS is the right split.
The reproducibility is amazing in reality: you either just run the misbehaving server’s config in a VM (one command) or spin up a throwaway VPS and apply the config to that (one command and about 60s). One of the major benefits of reproducibility is not having to poke at production machines because that’s the one place you can manifest the issue, now you can reproduce the in-production issues in a safe environment and fix them there.
I think the most interesting use case I have seen so far was for computers that control industrial equipment where you want identical installs on potentially dozens of machines.
> I can specify the whole OS including the packages I need and the configuration in one declarative setup. That one place aspect matters to me more than it might sound at first.
It took me less than a day of experimenting with it to learn that it is one place only in theory.
The second you start googling „how do I install xyz“ you discover there are also flakes. And others have some sort of convoluted git like method. And there is a package manager thing. And the direct config file editing like in this article. And a disposable temp install of some sort. And naturally software guides don’t give you instructions for all - they’re opinionated.
Felt a lot like being on Debian and the software only comes in .rpm
That really took the wind out of my sails because like OP I liked the basic config file part
I see your point about there being different ways to install a package, but I think I can clarify a bit by explaining how I use NixOS.
If I'm running a package on a server that means I want to install it declaratively, so I find the name of the package in Nixpkgs and put it in my `configuration.nix` file. I'm using flakes, but the configuration is exactly the same, I just put the package in the output section of the flake. Any instructions you see to install a package just boils down to finding the name of the package. To me this is as simple as finding the name of a Debian package and running `apt` to install it.
If you want additional features there are other optional ways to install packages, but these are features other distros don't offer, so if you just ignore them then there's no extra complexity compared to Debian for example.
I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup.
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
I’ve been driving Bluefin DX for a year or two. On the plus side, it works absolutely flawlessly. This is the longest I’ve ever run a Linux distro without a Nvidia driver update causing the whole thing to explode. It truly is the year of Linux on the desktop.
But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)
I think next time I’ll just go with vanilla Fedora.
I tried fedora silverblue for a while, but the way it works is that it builds a new root fs image whenever you change the installed packages, this makes system package changes take comparatively long vs a traditional os. They suggest installing most apps via flatpak, which is okay as long as you can deal with flatpak idiosyncrasies.
I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
I feel like if you want to learn Nix with some hand-holding, resist the urge to use Claude Code or Codex, but instead just use the chatbot in the browser or something. Ask it questions, explicitly copy and paste in errors as they come up, and manually copy and paste out the generated stuff.
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
I've recently switched to nix as a way to encode my environment across my server and work / private devices a bit more than just having some Brewfiles. I know it's not worth it for the computer switch every few years but having a somewhat opinionated place to centralize my config is worth it over regular dot files.
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.
I really want to like NixOS (and I mostly do) but the weirdness of the split between NixOS and HomeManager (and the fact that without HomeManager, you need another solution to manage your user-level configs) made it come up a bit short for me.
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'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 generate 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.
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.
Flakes are the defacto standard and you're leaving one huge point out. Flake files come with flake lock files. You cannot get lockfiles without using flakes.
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.
There are so many people complaining about the Nix language while offering zero constructive criticism. I was a little skeptical about them using a custom language at first. But then as I used it more it grew on me and I understand why it is the way it is.
People just seem to want to complain because it doesn't look like any of their favorite languages and they aren't familiar with functional languages. At this point, I can't imagine using any other language in place of Nix. The code would have so much noise and be much harder to read.
You know, I'm not going to say I'm enamored with the language, but I think the Stockholm Syndrome has kicked in because I really don't hate the language so much anymore.
I mean, I'm only ever using it for configurations, and I think I'd still prefer writing Nix than YAML. I probably wouldn't like writing a full "program" with Nix, but I don't think anyone does that?
Sounds like every programming language on the planet. Just skip the "i'm unfamiliar with it, so i hate it" phase, and everything will be fine. People spend more time repeating that simple POV, using thousands of varying words, than is healthy. Just shut up, and do the work. And if you're not going to put in the work, just shut up, and let everyone else get to work.
I mean I don't know that I agree with that completely. Languages can still be actively awful even if you do learn them.
I have written a lot of PHP. In order to learn it I bought several books, I've done a dozen or so projects with it at various jobs, I've written both trivial and non-trivial things, and I have come to the conclusion that PHP is an actively terrible language [1]. It's inconsistent and hard to write in any kind of maintainable way with an ugly syntax and generally-crappy performance for any kind of logic beyond CRUD.
[1] At least version 5, which is the last version I've used. I've heard 7 is better but I'll never know because I swore an oath in blood that I would not do PHP again for less than a million dollars a year.
Nix is a really good good good approach to manage packages. I've configured an entire asahi setup with for my m2 and can't be happier. It's not without it's quirks and nixlang itself is a bit cumbersome to express what you want.
However, AI is a great fit to write flakes. You can easily understand the generated code and it gives a power to "review" the changes before applying them.
And while nixos is amazing, I think nixpkgs are a bit overhyped; I've encountered many packages that are abandoned and outdated.
Definitely interested! I've reinstalled Fedora Asahi Remix several times on my old M1 after fiddling my way into a broken state. NixOS sounds like a tinkerer's dream but getting started is a bit intimidating.
I keep going in circles with thinking about trying NixOS.
I see an article like this about how great it is, think I might try it, then go down a rabbit hole of all the horror stories, and then give up before starting.
This comment thread highlights an issue that Nix has...some people love it personally, some love it professionally. Some are software engineers, others are hackers.
Most of the comments here seem to be from people using NixOS on a laptop. NixOS as a production OS in the cloud or on a robot is a game changer.
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
I'm just curious what your motivation for the patch is, because I too use atuin and see the space-prefix as a feature. It's been around for a while (longer than atuin) to keep certain commands out of my history on purpose, like when running some one-off command with credentials as an arg.
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
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.
For a single machine? Yeah, NixOS' cost surely outweighs the benefits if you're not familiar with Nix.
Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.
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 versoining and ability roll back is game changing for SRE Agents and preventing their ability to royally take down services, being able to audit and go back to the previous good known state is gold
I love NixOS and nix-darwing too. Specially now that I can use it without having to learn a bunch of stuff before even getting started. My coding agent is great at it.
NixOS kind of extends the idea of reproducible builds. Any snapshot could be a guarantee that things just work. This can also be extended onto the user base - if one user has solved a problem, it should be solved for all of them. So we can jump from guarantee to guarantee here.
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
dont know. you can create a config package with most distribution. i do config packages for debian. ai can help you on it. you tag it as config-smthg. you save it . you can create a config with a possible rollback organically by just uninstalling it or installing version-x.
with this you get atomic changes.
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
Why? Most people’s system configurations are publicly accessible on GitHub. Stuff like Omarchy only makes sense* when the system must be configured imperatively and there is a cost to trying things (accumulation of application residue). When you build your system declaratively you can just copy the bits you like from other people’s configs, or even just run their config as-is.
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
That binary feels forced when plenty bounce off it, return six months later, and only get it after a third round of pain. You need to be comfortable reading stack traces. If you want things 'just working' out of the box, Nix still has a talent for making you debug other people's build scripts for an hour, swear at it, and then come back anyway.
Yes, for me it was 2 or 3 rounds of "its just not clicking" before it did and then there was no looking back. Ive heard the same anecdote from lots of others as well.
This is a simple reflection of the fact that Nix has a steep learning curve. People who persist generally have deep-enough interest or a compelling-enough use case to power through.
I feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
I'm the inbetween. I stuck with it for a couple of months, but ended up dropping it. It's just too slow and incurs a massive complexity penalty that I'm not happy about. I'd rather just deal with tarball rootfses and union mounts if I want an immutable system (and overwhelmingly I do not.) The reproducible builds are nice and all, but I'm not in a position to really take advantage of it. I'm sure Nix is killer for a modern sysadmin.
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
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 love my kitchen knife and I love Emacs. More love is a good thing. Unless you're the kind of person who thinks not loving is better because you've got nothing to lose.
To me, loving inanimate "trivial" things diminishes the value of love. I love my girlfriend and my pets. I like my kitchen knife and my car. To bunch up both into the same category confuses things into "which one do I love the most", some sort of spectrum of love.
In the case of a fire, I'm sure you wouldn't prioritize your laptop with NixOS over your cat (let's imagine that the only backup is in the house that's on fire).
Yes, but you can also reclaim your space. I've configured nix to only store two latest revisions and have a ./switch.sh file that automatically clears everything up after applying nix.
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
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 author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town.
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows.
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
If you're using Hugo or a similar static site generator, you might like my blog series:
https://simonshine.dk/articles/hugo-static-site-setup/
https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...
My blog is deployed here:
https://github.com/sshine/nix/blob/main/services/nginx.nix#L...
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
also the AI hallucinating nix options. I have to constantly check https://search.nixos.org/packages?channel=unstable
oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.
I'm overwhelmingly surprised about Claude's ability to know the package.
But the cut-off point in model / harness quality before it hallucinates everything but the general Nix syntax is staggeringly low.
Try https://github.com/utensils/mcp-nixos
I've been trying to get nixd LSP to work with Claude Code but I got stuck as they gatekeep it behind their "plugin" system and you can't just configure it in settings.json to point to a nix store path like mcps :(
My usual solution is to just clone whatever I need. e.g. in this case just clone nixpkgs and put in your instructions that it should do a git pull to make sure it's up to date and then refer to that whenever doing anything with nix. Agents are really good at using grep to explore repos even for something completely internal. Then you don't need any config or special tools. e.g. for work I just have a directory with like 30 repos cloned and my base AGENTS file I use says to refer to either them or live system state for ground truth. I basically never encounter hallucinations.
Same goes for the harness itself. Want to know how Codex works or whether it can be configured in some way? Clone it and ask it to look at itself.
There’s a NixOS MCP, it’s pretty good
This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.
The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating.
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
> As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id.
One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.
> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Impermanence: https://github.com/nix-community/impermanence.
To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.
`One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.`
That doesn't help. Mutable users is about the lifecycle of the /etc/passwd file. What's I'm referring to is /var/lib/nixos/uid-map.
How would "bit-identical" or "free of side effects" make an actual difference in practice?
Rollback is already very easy with filesystem snapshots. Configs are already tracked by etckeeper. New laptop: either copy the whole drive or the package list and dotfiles. Also, how often do you have to get new laptops for this to be relevant ?
The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk.
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that:
(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)
(2) Make destructive changes like install a new windows manager, some drivers etc.
(3) If everything worked out well, continue
(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before
This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.
Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.
It’s like saying you don’t need a version control system for coding, as you can just make a copy of your sources before making important changes.
A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code.
There is no distinction between package maintainers and end users. They have the same power.
In the meantime i dont expect Debian users to ever write a package themselves or to modify one.
In nixOS you do it all the time
FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes:
# clone the package definition
$ fedpkg clone -a <name of package>
$ cd <name of package>
# install build dependencies
$ sudo dnf builddep ./nameofpackage.spec
# Now add your patches or modifications
# now build the package locally
$ fedpkg local
# install locally modified package
$ sudo dnf install ./the-locally-built-package.rpm
Arch Linux also has a long history of people writing their own package specs (AUR) and is relatively simple too of course.
Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.
This has benefits and downsides. Benefit is that everyone is treated as a power user. Downside is that power users are horrible at writing docs and this philosophy is my main theory why NixOS docs are so .... Bad
Fedora (and RHEL) end user and developer docs are written for quite different audiences
Yes I just replied to your other comment with the same observation. It reminds me of an article by Paul Graham, I forget which, who expressed the difficulty of explaining to programmers who lack an abstraction just how good the abstraction is. Anything you can do with NixOS, you can do with any distribution, because it isn't magic. But somehow, more stuff becomes possible because it gives you a better way to think.
(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)
Bye bye getting automatic upgrades to that package.
yes i think you've hit the nail on the head. I tend to view NixOS not as a distribution, but as a distribution framework. The system configuration is the sources for an immutable distribution as much as it as system configuration.
You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.
Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.
I like your analogy and it does make sense.
But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
That’s a great way to get one of the benefits of nix. But you still can check that snapshot into version control, share it with all your machines, etc.
You're right ... you cant check that snapshot into version control and share with your machines etc. When you need that level of control and need to scale your configuration to other machines NixOS sounds like the right choice. If it's for your own machine and you just want to try out a new windows manager non-destructively use snapshots.
Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.
Actually desktop environments are entirely modular and even audio stacks are just a few packages and enabling a few services
Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.
I use Nix for my homelab servers, and I'm using AI to be my IT support staff essentially. I don't need to ask AI for help installing hyperland, that is trivial as you say, but setting up nginx port forwarding? samba configs? k3s or k8s? Yeah individually any one of those things isn't very hard. But instead of spending 30 minutes reading through config examples and figuring out where it's setup I can instead spend 30 seconds just telling AI what I want, skimming the output to see if it's looks reasonable, and then doing a good ol' `git commit` of the config file & kicking off the "now go do it" nix build command.
And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
You can just install Nix on Fedora and grab it from there.
Well,
programs.hyperland.enable = true
is your dnf equivalent on nix. But nix also lets you declare all your key bindings, load Noctalia with systemd, etc.
I think they just mean that the fat that they can do it this way says a lot about the os. No need to get into the weeds on exactly how to install hyprland. It was an example.
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
Some things are not that simple and nix options come in handy automating other packages and services needed.
[flagged]
That would be Ubuntu and Docker. With Guix you can set everything for under a config.scm file in a reproducible way, you can even export a guix recipe as a Docker container, appimage or even as a standalone package for non-guix systems. That's unvaluable for scientific environments where the contrainsts must be set inmutable and unchanging.
But keep bitching about obsolete barely-GNU/Linux distros (the don't even use Linux-Libre) made to copycat NT with the registry, svchost.exe, MSI packages, DISM. (Gnome/OSTree/SystemD/Flatpak). Aka IBM's attempt to pick up RedHat and create another AIX but leeching everything from the community.
With Guix you can even crosscompile and export software to Win32 (for instance, Icecat, VLC...) and you don't need to nasty incantations with flatpaks.
If you want to live in 1993, go on. I already moved past Unix with 9front (my main machine, a n270 netbook, I code in C for expersite, rc/AWK for automation and EForth for fun) and Guix (sadly non-Guix because of wireless until I can afford a compatible laptop with ath9k and Intel).
9front it's my 'brain detox' machine, it's not Unix, it's even simpler than Unix. No wayland, no flatpak, no crap. Build once, run it again as it's a static binary. Guix it's to deal with corporate crap because of $JOB. You know, today they requiere docker and similar crap and with a guix environment I'm free to deploy at home everything at want.
For Go code I can just use 9front modulo some expecial cases (Yggdrasil-go needs a tun/tap interface, but with 9front you can just open() /net/ether/ files and you are free to inject whatever you want.
I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them.
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
NixOS's greatest weakness historically has been bad/missing docs, especially docs of the "I have X how do I do Y?" nature. This led to a situation where thousands of users asked those questions on forums and received answers covering a spectrum of possible paths forward. The other path was to spend a bunch of time trolling through module sources to find the options you need and understand what they were going to do and how they would interact with each other.
Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
I was already happy with my big ball of nix config for various servers, but claude does shave off a bunch of rough edges and make it more pleasant to interact with. I also resolved a couple nagging issues that had been around for a while.
It does tend to hallucinate but thats the great thing about nix... if it builds its probably right!
I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet.
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro.
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised. It's so nice! Underrated for sure.
And if you watch what it's actually doing during a session like that, it's basically exactly what a human would do: run the build, find the error, google the error, consider 2-3 possible fixes, pick one and apply it, repeat. Afterward, look at the various patches and fixups and decide if a refactor is necessary.
> it's the only game in town
Hey now, LLMs are pretty good at Guix, too.
LLMs are game changers for guix, gemini was able to create manifests for absolutely anything I asked for with very few iterations.
I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"
Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).
I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate.
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.
Just a note that if you are on nixOS you can configure things to run in an FHS compatible wrapper (https://ryantm.github.io/nixpkgs/builders/special/fhs-enviro...)
I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos
That's a solid point.
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
Tell me if I'm understanding you correctly. I summarize this in my head as, "This person loves NixOS because it gave him GitOps for his OS."
I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system.
But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
Yes. That's why I'm using NixOS as well, despite all the terrible jank it has.
Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.
Same, I've been playing with kernel settings for AMD, and it's really easy to revert in case things blow up
Wouldn’t any immutable OS accomplish this goal?
No. To gain that level of control you need a declarative distro.
Immutability and rollbacks are merely nice side effects of the Nix model.
There's also GUIX.
[dead]
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.
You mean like https://wiki.nixos.org/wiki/NixOS_Containers ?
There is also https://microvm-nix.github.io/microvm.nix/ if you want increased isolation.
I can recommend MicroVM.nix, since it allows for multiple VM runtimes like QEMU, Firecracker, etc.
There's also nixos-shell for ad-hoc virtual machines: https://github.com/mic92/nixos-shell
Can you do those ad-hoc though? I was looking into this too. I feel like it requires a system config change, apply, and then you need to do container start + machinectl login to actually get a shell.
That's definitely what I want... most of the time.
Yes, NixOS containers can be run in:
* declarative mode, where your guest config is defined within your host config, or
* imperative mode, where your guest NixOS config is defined in a separate file. You can choose to reuse config between host and guest config files, of course.
It sounds like you want imperative containers. Here's the docs: https://nixos.org/manual/nixos/stable/#sec-imperative-contai...
Oh I totally missed that!
sounds like you want qubes os https://www.qubes-os.org/
> 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".
NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.
There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.
https://spectrum-os.org/ is trying to marry QubesOS (everything runs inside a VM) with Nix. It's still very much in development, though.
If containers are safe enough for ur use case then just use nixos containers they just a few more lines to setup in a regular nixos config
If it isn't enough there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
Sounds like Ghaf might be what you're after: https://ghaf.tii.ae/ghaf/overview
depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
That's hard given most apps have dependencies and often share them.
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
> Nix is just another chef, ansible, cfengine, apt, pacman
No, because Nix code is actually composable. These other tools aren't.
Not only is it composable, but it is generalizable. So yes there is also chef, ansible, apt, uv, nodeenv, etc... or there is just nix. It is able to be the "one tool" to rule them all, often with better reproducibility guarantees.
I almost switched back to Fedora Bazzite to get a working gamescope, but realized I can get HDR in sway and its actually more stable than Valve's mess of gamescope. Even though I have to use "--unsupported-gpu" flag, my Nvidia card works wonders in Sway, where as gamescope gives me a blinking cursor and segfaults.
Can you share some good examples of how you use nix shells with python for one off scripts? I am still figuring out how python interacts with nixos :(
Not the greatest fan of python, but when I've got to run a python script, I do `nix-shell -p 'python3.withPackages (ps: [ps.requests])' --command 'python3 your-script.py'` Note that there is one argument to -p and one argument to --command -- both are quoted. The argument to -p is a nix expression that will provide a python3 command, referring to a python3 with the requests package. The argument to --command is a bash script that will run python3 with the argument "your-script.py" i.e. it will run your-script.py with the python3 that has the requests package.
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier.
[0]: https://mynixos.com/nixpkgs/option/programs.nix-ld.enable
Easier and largely compatible with the rest of the world. Solving problems with "If we all switched to NixOS..." is a non-starter in most organizations.
My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!
In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.
I'd love NixOS more if they had any decent documentation.
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)".
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.
nixos.org is the official wiki. It will take time for search ranking to beat the old one.
You know, I used to agree, but what I realized, is I am a software engineer, and I'm used to working in large projects with source-code as the only documentation.
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
> I'm used to working in large projects with source-code as the only documentation.
As a software engineer I have an opposing attitude towards this. I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
There are significant alternatives to NixOS like bootable containers and OSTree which are more useful and better documented. If Nix project really cares about being competitive and adopt users, they have to document their stuff. They are already going against the grain and ain't nobody has time to put up with their weird language and their subpar documentation.
> I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
I mean, I'd argue there is significant potential, but really, for me it's just easy because I've been doing it for 20 years, and documentation is always fundamentally worse than code in some important ways.
> If Nix project really cares about being competitive and adopt users, they have to document their stuff.
This is one of the good/bad things about OSS.. most users don't provide positive value to the project. So do they really want to adopt users? Shrugs but the project is certainly competitive.
> for me it's just easy because I've been doing it for 20 years
C’mon, just drop the “greybeard” act. Nix not having proper documentation is bad practice, period. No ifs buts or howevers, it’s just an objective fact. Good documentation is always (ALWAYS) a net positive, and this is an OS with it’s own unique mindset and way of doing things, good documentation is essential. End of.
+1. I would also recommend using Github search to look for existing examples.
And actually to add, I've been finding myself going to nixpkgs first for reference on how to build and/or configure packages even outside of nix.
In a world of LLMs and agentic coding, I think documentation is less important.
ChatGPT is very good at pulling it together to give you working code. Not on the first try, but on the third try it usually works.
Pasting the generally horrible error messages is also quite effective!
Pasting? Give Claude/codex the ability to go fix it itself and have it deal with it directly.
no thank you, there are things I do not want Claude to have rwx on. like my entire f*cking system. I run llms in a docker container with just the folder I'm working in.
If you grant access to the Nix daemon socket but not writing outside the current directory, that's an effective sandbox. It allows evaluating derivations but not actually installing them.
haha technologie is moving so fast ;p
my entire system is configured using a flake i built with coding agent and skills to tell it how to configure things in nixos heh
A lot of us use NixOS/nix yet haven't read any documentation nor hand-written nix ourself. That's Claude Code's job.
If only.
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 do, but it somehow tends to forget how to do things right now and then - despite having notes in memories system - and starts to do them in its own weird ways.
I’m going to experiment with skills next, or maybe make it build a few helper scripts for itself to quickly get some module source from nixpkgs matching flake.lock without having to think of it all. I’m positive about Claude for nix management, merely saying it’s not something that “just works” for now and reading nix code is still on the human part of the tandem.
This said, to be fair - when it gets the approach right, it excels. I was setting up Ente for photos backup and sharing, and it produced a nice overlay with custom patches for my needs from just “figure out why /shared-albums/ redirects wrong and fix”. Found the module, the package, pulled source, analyzed it, proposed a patch (settings weren’t enough), did it - I only had to test, and only because I haven’t provided it with a browser. Felt amazing.
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.
NixOS is high-level declarative, so you're reading high-level config diffs when the AI agent is pitching changes.
Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.
You can probably guess what this does:
The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just in time through daily exposure like anything else.Coming from Ansible with hand-written config templates this was honestly a friction point for me - I felt like NixOS is trying to actively hide what it's actually going to configure. It's gotten better now that I read some nixpkg service sources but from time to time I still feel the urge to just directly manage my systemd units, sshd configs and whatnot. Like, sure it simplifies the setup but at the same time also puts another abstraction between me and the software I'm using.
You always have the option to do your own custom thing like use nix config to manage /etc/iptables.rules.
NixOS does you one thing better by giving you the option to configure things without caring about the underlying implementation, like whether the firewall uses iptables or nftables or something else.
I agree with the many levels of abstraction, but at the same time, directly managing systemd units is also so much easier with Nix then any other distro I've tried.
> Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.
I am not brand new - and I don't know what the heck the config is doing.
That is why I rely on documentation.
The "code is self-explanatory" is always an attempt to not have useful documentation and try to rationalise that problem away.
Nothing about this changes with Nix nor AI agents.
You can read documentation on an as-needed basis or to your heart's content.
The point is that the majority of the day to day changes I make to my desktop environment aren't so critical that I need to do more than read an AI agent's proposed changes to my config and accept them when they look reasonable.
And I don't think looking up the exact config options to NixOS' networking system does anything to increase my knowledge of the OS. It's just a triviality.
> [ 8080, 9000 ]
Fails to parse is what it does...
Are we really living in times where people can't write a single (syntactically) well-formed line of code in a programming language they use?
I understand this doesn't really matter when just using NixOS Slop Edition™ but man I hate it.
You hate that I couldn't remember whether nix has array delimiters on the spot?
Jeez, tough crowd.
Though it also kinda represents this pride over triviality that some people latch on to in the AI world which is odd since it's also only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker, I would have spared you the negative emotional reaction.
In the pre-AI world, you would have probably not been so harsh since it's understandable that someone make that mistake with such an idiosyncratic language like nix that almost nobody writes full-time. Yet in the AI world, you demand more from humans.
Something interesting, there.
> [..] only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker [..]
That's true, and I should've been less rude in my previous comment. Sorry.
(Though note `nix eval` would've sufficed, no need for the probabilistic kind of clanker)
> Yet in the AI world, you demand more from humans.
But this isn't true. In my opinion `learning >> depending on an LLM` and my gripe is that it seems like the former is being displaced by the latter. In the pre-AI world I would've known that the person making the mistake wasn't making it because they outsourced their skill.
So I'm not, in fact, demanding anything more than in the pre-AI world.
The other poster is being a jerk, but your point doesn’t really refute theirs: if you can’t even be bothered to check for an array delimiter, instead passing that on to an AI, how will you ever learn?
People are being more demanding of humans because humans are taking knowledge and learning for granted. All this abstraction has a cost, and the cost is you.
Things are falling out of your memory all the time as a function of how often or seldom you do something, how trivial or superficial the information is, and how minor the difference between other tools you use regularly.
Despite many years of experience, I still sometimes get this wrong in Python or its equivalent in the other languages I regularly switch between:
The difference here is that, because I admitted to using AI, I don't get the grace of making the most trivial mistake in a forum comment.And suddenly we pretend that had I just written it by hand a few more times, I would never err again in forum comments, despite making similar errors this week in languages I've used to write millions of lines of code across decades.
Well, there's layers. When I started using nixOS I read through the guide and wiki but I also used LLM assistance to help create a stable starting point. Then over time I've incrementally added new things to my configuration through a mix of LLM assistance and reading online material.
I think the initial migration towards nixOS is the hardest point, since it requires learning a bunch of new things all at once in order to get the system into a usable state that matches your expectations and preferences. The key benefit of using an LLM is that it makes it really easy to get your system into a useful initial state, and then you can safely learn and experiment incrementally with a mix of tools.
When I started off I didn't understand everything, but at this point I feel I have a very good understanding of everything in my configuration file.
I'm glad that I'm not the only one. I don't want to move from "Microsoft knows best" to "Claude knows best but hey, at least you review the output by looking up the not so good documentation".
Kind of an interesting thing here where if this is how you view it, it kind shows in itself why you don't actually need it.
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
The upside of Nix config is that it's the state of my system in a declarative config file.
I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ...
This is difference between me and a non-nix user, not whether we can rattle off the exact state of our live system from memory.
The non-nix user has to query live system state, if such query tools even exist for their question, and I get to read a config file. And I get to maintain my system config in git, and I get to deploy my config on all of my machines.
But if you are not reading or comprehending the config file, why does it make any difference? You ask AI to purge ffmpeg from your system, it will probably know more about doing that with apt than with nix, right? And if the input on your end is "remove ffmpeg from my system" or whatever either way, what's the need for nix? You will be much happier just editing /etc files and such in the standard way, rather than hoping your AI knows the (sometimes sadly inconsistent) way nixos handles the particular module/service/whatever you are dealing with.
For me, the difference is that there is no way in hell that I want to give an AI assistant full access to configure my system live. With a declarative config, the only access it needs is to an isolated git repo.
But if the declaritive file is not read/understood, what is the difference? At some point, you're gonna run sudo nixos-rebuild, and that is the whole system on the line.
> But if the declaritive file is not read/understood, what is the difference?
Well the main difference is precisely that I have a clear opportunity to read and understand the declarative file.
But even if something were to sneak in there, rolling back is now trivial.
This whole thing has been about explicitly using LLM instead of learning nix. So sure, definitely agree with about the niceness of using nix in general if that is all you are saying, but also not sure what you are trying to argue for anymore.
My point is that nix is a big enabler for me to use AI to configure my system, because it provides a safer environment in which to do so.
Very cool!
HN: AI coding is still coding because you need the domain knowledge to steer AI in the right direction, read the code, understand it and fix it when necessary.
Also HN: No idea how this OS works, screw writing proper documentation, just ask Claude to do it! Wee!
You AI babies seriously need to pick a lane.
So relying on closed source code using a closed model to configure a free OS. That's a step back.
On the contrary, the model doesn't actually add any lock-in. When GP wants to switch to free model the config files are still there. There's no lock-in, as I see it.
It is not about lock-in, it is about free software being usable without resorting to non-free software. One of the free models is usable for this would be a better shift and that might be workable but I'm not sure about how well they'd work.
I tried NixOS a few months ago, when I had to choose a new OS for my laptop.
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
I can completely understand how you were driven away. If you ever want to give it a go again:
> there's "Flakes" which I never quite understood
Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).
On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.
What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone
As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.
> manually edited /etc files.
You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].
[1]: https://search.nixos.org/options?channel=unstable&query=envi... [2]: https://home-manager-options.extranix.com/?query=xdg.configF...
Yep, i am doing the same. I have a central remote flake repo where all my machines, services, etc are defined and they all run tweaked autoupdaters to periodically do full updates. I push commits and wait and forget. It feels like maintaining your distro everywhere, no matter where you ssh in. And soon, i will migrate that repo off a central platform (github) into radicle or something and turn some of my machines into seeders. Then, with offsite data backups, my house could burn down and github go dark, i could still recover, maybe in the future even bootstrap from my smartphone. A big step towards digital sovereignity.
Great comment -- thank you!
The most NixOS comment I've seen yet was when I was trying to find out about `mkOutOfStoreSymlink`, which lead me to this thread:
https://discourse.nixos.org/t/how-to-manage-dotfiles-with-ho...
> Hi, I just wanted to know, where can I find the documentation to know more about this contrib.lib.file.mkOutOfStoreSymlink option ?
> Well, since is a very simple function, no documentation is really needed.
I've been gradually transitioning everything to NixOS, starting with my homelab mini PC, then my Framework laptop, and now my daily driver desktop. It's hard to imagine going back because the pros are so strong compared to the cons, but the docs situation is truly dire.
That’s my feeling when reading nixos forums. People are willing to help but don’t realize how little newbies know about nix when asking for help. The first month of nixos was a massive uphill climb for me, and that knowledge doesn’t stick well because I get to interact with nix every few months to tweak things, not weekly or daily.
It’s a solid os, and I’m enjoying it, and I love that I can’t break things while tweaking. But the docs are and discussion threads are not written for beginners (it’s really hard to write for beginners).
> Then there's "Flakes" which I never quite understood
Flakes do 2 things:
1. Declaration of the inputs and outputs of some Nix codebase. 2. Pinning the versions of this input sources.
The dependency pinning is similar to package.json/package.lock etc. which are common in language-specific package managers.
Sibling comment does a good job of going into flakes, but to answer this
> Do you install a package or a service
A package is like the raw software installation. So eg the bash package is just a wrapper around building bash from source (theoretically from source at least... you can also define a package as being a binary distribution as long as you specify the content hash). The service (actually the _module_) is for everything else around software installation. So, eg, the bash _package_ will build bash and have it available for you to put in your path but the bash _module_ might also configure your .bashrc and set it up as your users shell. It would also generally refer to the bash _package_ so you can do all that plumbing but specify a certain version of bash you want to use.
Another common example: a plex package would again build the plex software but a plex module would perhaps create a plex user, setup systemd units, open your firewall, and create a media directory.
EDIT: the next layer of confusion is that modules (which sort of are a secret-sauce of nix and so naturally you will want to use them a bunch) are specific implementation details of multiple subsystems in nix. Meaning, nixOS and home-manager and nix-darwin all have "modules" but they are not compatible. Each has its own "idea" of what modules are and nix itself doesnt provide this natively. That means things get a little more complicated/involved when you use those ecosystems together. Its not too bad but it is annoying.
I’m surprised nobody has bothered improving at least the documentation with a few LLM iterations.
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.
> nix is superior in every single way.
My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.
If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.
With NixOS, you pay all the complexity up front.
Such a pity that the article didnt touch on running rust nightly or the sometimes statefull nature of user configs of some programs. The 5% painful part was just around the corner.
Fair point but I've stopped trying to declaratively manage stuff in nix that has its own idiosyncratic state management. That way youre just using nix to run an installer.
Yeah, I've been using Unixey stuff for almost twenty years now (most of it Linux, and fell for the siren song of macOS for about four of them).
I liked Arch and Ubuntu and Mint and OpenSUSE well enough when I used them first, but once I actually tried NixOS it felt so obviously correct that it started to bother me that it's not the default for everything.
Being able to temporarily install things with nix-shell is game changing, and being able to trivially see what's actually installed on my computer by quickly looking at my configuration.nix is so nice. "Uninstalling" things boils down to "remove from configuration.nix and rebuild".
The automatic snapshots upon each build allows me to be a lot "braver" when playing with configurations than I was with Arch. I was always afraid to mess with video card or wifi drivers, because if I screwed something up and if I didn't know how to get back to where I was, I might be stuck reinstalling to get back to a happy state. This didn't happen that often but often enough to have made me a bit weary about futzing with boot parameters or kernel modules. Because of the automatic snapshots with NixOS, it's much easier (and more fun) to poke with the lower level stuff, because if I do break something in a way that I don't know how to fix, the worst case scenario is that I reboot and choose an older generation.
This is a bigger deal than it sounds. For example, with my current laptop, there was a weird quirk with my USB devices having to "wake up" after not being used for more than thirty seconds, meaning that I might start typing and the first three or four words wouldn't go through. After some digging, I found out that the solution is to add "usbcore.autosuspend=-1" to the kernel params. I did that and it worked.
If I had still been running Arch or Ubuntu, I probably would have just learned to put up with it, because I would have been afraid to edit kernel parameters because of the risk of breaking things in a way that I don't know how to fix.
I love NixOS. I have no desire to leave, or at least I have no desire to abandon the model. I've considered changing to GNU Guix System since I like Lisp more than I like the Nix language, but those FSF-approved distros can be a real headache for people who actually have to use their computers.
> those FSF-approved distros can be a real headache for people who actually have to use their computers.
This is now a tired discussion; the use of nonguix (https://gitlab.com/nonguix/nonguix) is well documented, there is no practical difference after initial setup between using a regular distro and one of “those FSF-approved distros”
I am sure you don't do it on purpose, but could you stop spreading FUD? (specially given you acknowledge “ I've considered changing to GNU Guix System”, so you're here relaying 3rd party opinions, not your own)
> like with apt/brew + 20 handwritten bash scripts
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
I've been using apt for 20 years too and was never a fan of it, canonical repos are never up-to-date and managing ppas is a pain. Yes I'm very hype about nixOS (and that's a rare thing for me), but it is just really really good.
I understand that "just check it out" is not the best advice because the setup cost to using nixOS is really high, and the learning curve is really steep, so it's not like you can give it a whirl for a few hours to experience the workflow. But believe me, once you are used to it, it just so so much more convenient. I'm currently managing my dev laptop, home PC, a WSL, and a hetzner server all in the same repository (allowing for a lot of code reuse). Everything is super orderly and split into modules, everything is declarative, I can roll back to a previous build of my system if I mess up installing nvidia drivers or iwd or bluetooth etc.
It's also not like installing software is harder than with apt (oftentimes it is easer, `programs.firefox.enable = true`) so after you've paid the setup cost there is just no downside. It's a bit like react vs jQuery, or Kubernetes vs hand-written deployment scripts.
What I like most about nixos is that you can have deterministically cached packages you don't need to rebuild every time in your ci.
It's also simple to setup dev environments with nix.
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.
This is exactly why I made https://nix-ci.com/ And it supports Forgejo, GitHub, and GitLab.
I use https://garnix.io/ for all my Nix CI, works great.
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.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
Ok, but I guess a more concrete version of my question is the following:
> How do I set up my development environment using devenv.sh to pin nodejs to 24.14.0?
If I understand your response correctly, I can't do this in any very practical way.
Generally something like
24 != 24.14.0
If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
But that doesn’t pin to a specific version?
It does, in combination with a pinned nixpkgs commit, which you can find like this:
It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.
Doesn't that pin me to a particular versions of nixpkgs? That's fine if I only care about nodejs, but if I want to maintain particular versions of different tools, it won't work.
Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned ways.
I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.)
I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.
You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different _exact versions_ (or likewise, in CI it also will be the exact same). And in general thats what people are trying to achieve on teams by pinning to full semver. So thats what I mean by its generally not needed on nix.
However, to actually address your question it would be something like this (with ruby also added for comparison of whats possible depending on the language ecosystem you are using)
Thanks for the code.
Pinning by version number isn’t a crutch; it’s more a question of mental models. Most people find it more intuitive to identify a world by describing the things in it than to fix the states of the things by identifying the world where they have those states. Nix sometimes feels as if someone read Kripke and missed the passage about possible worlds being a figure of speech.
In other words, many of us don’t think that version numbers are a crutch to be used in the absence of a totalizing hash of the entire state of the universe. We actually think that version numbers are, for many practical purposes, better than that.
I dont mean to imply its a crutch. Im merely pointing out that even though people say they want to "pin to a specific version", there are usually two different motivations:
- one group of people who want guarantees that what they install on their machine matches on their colleague/CI/prod machines. For this group, the nix happy path basically serves all their needs really well. It can capture nearly any sort of software dependency they have regardless of ecosystem and it pins to actual content hashes in most cases. They only care that the high level versioning is met, because again its reproducibility that they care about
- one group of people want guarantees of specific software versions. Nix still handles this, but its "more work" because nix is by default a snapshot of the entire world, of which your target software is only a slice of. And most nix snapshots of the world are "what were the most recent versions of each software package at this point in time". So you generally need to compose together multiple snapshots of the world. It works fine, its just more work (and more disk space).
In practice, again, I think most teams are served better by being in group one, but dipping into group two when they either need an "unreleased" version for software they depend on or when they need an older/unsupported version of software they depend on (or a nix release breaks their workflow). Then nix shines by being able to mix and match between different snapshots in composable/reproducible ways.
It's one of my complaints too.
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
[1] https://lazamar.co.uk/nix-versions/
Can you help me understand why devenv is needed instead of a shell like this/what is gained?
It is a more user friendly abstraction on top of Nix. Most people don’t want or need to understand the specifics of Nix or the Nix language.
Btw, I say this as a huge fan and heavy user of both Nix and NixOS.
The UX is the big benefit, especially on teams who may not even know what nix is. I held off on exposing my nix setups for a long time, but devenv has made it possible to check things in without losing a ton of time to tech support.
To be honest, I don’t know. I just enjoy the simplicity of devenv. It’s the right amount of user friendly.
“Needed” is too strong, but this does not provide services, does not provide project-specific scripts, does not setup LSP, does not setup git hooks, can't automatically dockerize your build, does not support multiple profiles (e.g. local and CI), etc.
devenv lets you express shells as modules.
Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).
That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.
devenv also has tasks/services. For example you need to start redis, then your db, then seed it, and only then start the server. All of that could be aliases, yeah, but if you define them as aliases you can have them all up with `devenv up`. It even supports dependencies between tasks ("only run the db after migrations ran")
Hm. How it's different from home-manager?
home-manager manages your whole user's environment & desktop.
devenv does not do any user-level change (you will not be able to make it configure your WM), but works at the directory level.
For instance I'm currently working on a Rust + C++ project, and my devenv, whenever I enter this project folder: make CMake/g++/cargo/cbindgen available, enable a couple scripts to longer CMake invokations, set-up everything required for C++ and Rust LSPs, and create a couple git hooks to validate formatting etc.
[dead]
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?
guix would like a word
+1, Guix is quite good with some tricks up it's sleeve compared to Nix.
I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.
On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.
Does guix have a flake equivalent yet?
different ui. you can pull in different commits of channels (packages repos) and take packages from them. but it’s opt-in, no lock-file snapshots.
https://guix.gnu.org/manual/1.5.0/en/html_node/Inferiors.htm...
The lock file is the major feature I'm missing.
I mean it's pretty wild to take s-expressions and not call them extremely terrible to read. The nix language sucks really badly, but I gladly take it over writing S-expressions.
It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.
> you're going to be writing the (name value) form for 99% of it.
That's exactly the part that is wrong with Guix, and Scheme in general. Scheme has associated lists, they are written as '((name . value) ...), but since that's too ugly everybody makes macro wrappers around them to get them down to just (name value). But that means you aren't dealing with an obvious data type anymore, but with whatever the macro produces and if you want to manipulate that you need special tools yet again. And then you have record-type and named arguments which are different things yet again, but all serve the same name->value function as an associated list. Names themselves are sometimes symbols, sometimes keywords, and sometimes actual values. Same with lambda, sometimes you need to supply a function, other times there is a macro that allows you to supply a block of code.
It's like the opposite of the Zen of Python, there are always three different ways to do a thing and none of them as any real advantage over the other, they are just different for no good reason and intermixed in the same code base.
I have never seen anything else use the (name value) syntax. You do deal with obvious data types, the REPL tells you exactly what those data types are (records, in the case of Guix). Schemes outside of Guile don't even have keywords, much less named arguments.
Are you complaining that a language has both associative containers and structs? Which one do you advocate for removing in Python to keep up the precious "Zen"?
I don't agree at all. Just look at these derivations: https://codeberg.org/guix/guix/src/branch/master/gnu/package...
I counted and you regularly see this: "))))))))))" at the end. This is not a language that is optimizing for being written by humans.
Lisp programmers have used editors that count the parens for them for decades. Many use something like paredit that simply automatically adds the final paren. I've written significant amounts of Lisp and you simply don't see the parens. You might as well complain about French having all those accents. It's just a different language. Learn it and you'll see why.
I can write lisp. That a lot of lisp programmers require special editors to handle it should tell you enough. It's not that the language is unworkable. You can definitely write stuff in it. The point is that it is quite far from something that should be written by people, in my opinion.
Are you really going to argue that a good programming language is one where you can construct it character by character, by hand? Emacs has existed for decades and it runs basically anywhere. Nobody is programming in ed (well, apart from Dave Beazley[0]). With LLMs the world is finally catching up to the fact that programming isn't typing characters one by one. Lisp programmers have been at this for decades.
[0] https://www.youtube.com/watch?v=Rou26TpUG0Y
I consider it essential for a programming language for people that it is easy to understand things by looking at things locally. Requiring/strongly encouraging extremely deep nesting is not conducive to that.
This is not some weird opinion I have. There is a reason "flat is better than nested" is part of the pretty popular zen of Python.
Which is the most tired critique of lisp ever. Even the text editor on my phone can keep parens balanced for me.
S-expressions were supposed to be replaced by a more user friendly syntax. The trade offs were not worth it and every try to replace sexprs failed.
If it is such a problem you can use wisp to write your packages.
https://www.gnu.org/software/guile/manual/html_node/SRFI_002...
Most code is read much more than it is written, at least I read much more code than I write. So for me code should be optimized to be read as plain text as that is basically what every tool uses. Requiring a separate tool to get basic readability is not really acceptable. I can't do that on github, I can't do that with the various diff tools, I can't just quickly cat a file or use the countless other tools that are designed to present plain text.
If I then can choose between guix and a language that doesn't require these hoops and extreme quality trade off the choice is not hard.
Anyway if you think guix is better than nix, than nothing stops you from using it.
I just have a hard time taking such a comment seriously, because I have made it myself. Many times even. My second comment on Slashdot in 1999 was a comment just like yours. I try to tell myself it is ok because I was still a teenager.
7 years later I had to write common lisp and I think the parens were a problem for about a week. Since then I have written many thousand lines of lisp code. I usually go back and forth on what I like the most. ML (ocaml mostly) or (guile) scheme. In just about every other language (except maybe factor) I miss the macros (even syntax rules ones) way more than I like the extra expressiveness of, say, Haskell. [0]
Wisp is a part of guile. So you can write your own config using it. It is not completely straightforward, but if you really hate parentheses it is a way. Or you continue the wonderful string gluing of Nix. Whatever floats your boat.
[0]: I do miss typing sometimes in scheme though. I have thought about vibe coding a prototype of an s-expr language that compiles to f# AST.
I think you’re misunderstanding my point.
This isn’t about whether someone can get used to parentheses. Obviously they can. I don’t doubt your extensive experience there. The question is what the language optimizes for by default.
My argument is that S-expressions optimize for structural uniformity and macro power, but they do so at the expense of plain-text readability without tooling. And that trade-off matters in contexts where code is frequently read outside of a fully configured editor, code reviews, diffs, quick inspection, etc.
Saying “editors solve this” doesn’t really address that, it just shifts the burden to tooling. In contrast, many other languages aim to be reasonably legible even in minimal environments.
So I’m not arguing that Lisp is unusable. I’m saying it makes a different set of trade-offs, and for my use case where I spend much more time reading other peoples code in some web portal and with basic terminal tools those trade-offs are a net negative. I would expect this trade off holds for most code produced.
> This is not a language that is optimizing for being written by humans
I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation.
The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. Seems to me like you deliberately searched for the most atypical example, that you're now misrepresenting as 'regular', when it is highly atypical.
And honestly, what would that look like in some 'more normal' language?
Better?I will never understand this fear response some people have to seeing `(fn a b)` instead of `fn(a, b)`.
I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently.
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.
> Something that happens in 4.5k lines twice is hardly rare.
Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?
Looking at a lot of nix package expression: Quite a bit. Besides, just taking a way a single brace gives 7 hits. Still a ridiculous level of nesting. So I don't go with your reasoning that these are some kind of super special cases. If something happens so often in 4500 lines of code you cease the right to claim it is special.
It happens 1/2290 (0.04%) of the time. You are significantly more likely to guess a stranger's birthday totally at random (0.27%) twice in a row (0.07%). If you don't consider that exceedingly rare, then you and I need to hit up Vegas immediately.
You are projecting a programming style onto Lisps that's quite alien to them. Lisps tend towards small, discrete functions that are composed together. It is the ordinary languages that tend towards deep branching and nesting; Lisps generally favour recursion and function composition instead.
There are 101 `(package` definitions and 58 out of them have more than 6 nest level, which I would consider more than excessive. That's an incidence of over 50%.
Beside I don't think I'm alien to the functional way of writing things. I write mostly Haskell professionally. But Haskell doesn't casually suffer from making insane expression nesting the default.
You may not be a stranger to the functional style, but you do seem a stranger to the Lisp style, which is closely allied. A lot of FP originated in Schemes and Lisps - Haskell is greatly influenced by the ML family, which is itself greatly influenced by Lisp. Modern FP is a style that would be recognisable to a Lisp programmer fifty years ago, when everyone else was writing imperative soup.
I don't think there's much anyone can say that's going to change your mind. You're strongly coming off as though you've formed a view, based on little experience, and will now Ctrl-F cherry-picked examples to sustain it rather than listen to any contrary information. I respectfully suggest greater open-mindedness and a willingness to reserve conclusions in the absence of data.
I personally don't use Lisp too much, so I'm not particularly invested in this exchange, but I know from experience it's not even remotely what you're describing it as. Everything about Lisps tends towards minimal nesting, from the use of paredit to edit expressions through REPL-based workflows.
The only thing this exchange has done, as someone who programs in FP exclusively, is make me reminisce about and yearn for Lisp. It's a wonderful language for FP.
That link isn't working for me (something about AI detection), but as a point of accuracy, those aren't derivations, they're simple source files. Derivations are generated out of them.
As for the closing braces, would it be better if you had a newline between each?
I liked NixOS pre-LLM era, since it allowed me to manage a couple of servers in a reproducible way. Ability to reboot back to a stable configuration felt like magic.
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
5 minutes later it came back.
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.
Nix isn't really much of a hobby. It does require some learning because it's different, and front-loading the work to build your config, but after that it's amazingly reliable and easily extendable. You can keep everything up to date with a single command.
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
The configuration system is way more stable than it seems. You write it once and then pretty much never touch it again.
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.
I feel the same way about Guix with nonguix channel enabled. NixOS is awesome but I prefer Guile to Nix's language and I enjoy the docs more. But definitely sister OSes.
There's nowhere near enough love for Guix. I don't understand it. It has far better foundations. I would never invest time into some "config language". Using a real programming language has huge benefits, and it's a good one (Scheme).
It also has very slow rebuild times.
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.
This is a really helpful explanation - thank you!
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
No there’s a nerd who will obsessively submit the latest version of any popular software that does that to nixpkgs. Or suggest you use the flatpak.
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
I generally use flatpak for things that are important to keep extremely updated, e.g. my browser for vulnerability reasons.
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.
Usually u can run almost any binary by setting up once a fhs. Or using steam-run
And there's also nix alien and similar tools as alternative
But indeed usually you end up using patchelf , tell the inputs of a binary n just make a regular nix package from it
> 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
You can: https://github.com/nix-community/nix-ld
really good question.
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.
One thing I love about NixOS is how easy it is to run packages from different sources. For example, I needed an old package that's been removed from nixpkgs several years ago. To run it I just had to add an old release of nixpkgs as input to my flake.nix and add the package from this input. It pulls all its dependencies from that old release and there's zero conflict with the other packages.
I still really wish there was a NixOS, but without the quirky filesystem/linking setup.
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
My love for NixOS really became clear when I realized I never have to write Nix again by hand.
A WIP NixOS config for working with agents:
https://github.com/dangirsh/tsurf
Same. I have a full homelab and multiple macs, can’t say I’ve written a line of real Nix code by hand.
If you’re itching to try Nix, now is the time.
Same.
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.
Not to mention the non-idempotent python + bash + ssh hell of Ansible, or awful DSLs such as Salt, Puppet, Chef, etc.
i've been tempted by NixOS for servers but keep going back to Debian. the reproducibility is amazing in theory, but when you need to debug a DKMS kernel module build at 2am on a VPS, having "just apt install" is worth a lot. maybe NixOS for dev workstations, Debian for production VPS is the right split.
The reproducibility is amazing in reality: you either just run the misbehaving server’s config in a VM (one command) or spin up a throwaway VPS and apply the config to that (one command and about 60s). One of the major benefits of reproducibility is not having to poke at production machines because that’s the one place you can manifest the issue, now you can reproduce the in-production issues in a safe environment and fix them there.
I think the most interesting use case I have seen so far was for computers that control industrial equipment where you want identical installs on potentially dozens of machines.
> I can specify the whole OS including the packages I need and the configuration in one declarative setup. That one place aspect matters to me more than it might sound at first.
It took me less than a day of experimenting with it to learn that it is one place only in theory.
The second you start googling „how do I install xyz“ you discover there are also flakes. And others have some sort of convoluted git like method. And there is a package manager thing. And the direct config file editing like in this article. And a disposable temp install of some sort. And naturally software guides don’t give you instructions for all - they’re opinionated.
Felt a lot like being on Debian and the software only comes in .rpm
That really took the wind out of my sails because like OP I liked the basic config file part
I see your point about there being different ways to install a package, but I think I can clarify a bit by explaining how I use NixOS.
If I'm running a package on a server that means I want to install it declaratively, so I find the name of the package in Nixpkgs and put it in my `configuration.nix` file. I'm using flakes, but the configuration is exactly the same, I just put the package in the output section of the flake. Any instructions you see to install a package just boils down to finding the name of the package. To me this is as simple as finding the name of a Debian package and running `apt` to install it.
If you want additional features there are other optional ways to install packages, but these are features other distros don't offer, so if you just ignore them then there's no extra complexity compared to Debian for example.
I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup.
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
I’ve been driving Bluefin DX for a year or two. On the plus side, it works absolutely flawlessly. This is the longest I’ve ever run a Linux distro without a Nvidia driver update causing the whole thing to explode. It truly is the year of Linux on the desktop.
But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)
I think next time I’ll just go with vanilla Fedora.
I tried fedora silverblue for a while, but the way it works is that it builds a new root fs image whenever you change the installed packages, this makes system package changes take comparatively long vs a traditional os. They suggest installing most apps via flatpak, which is okay as long as you can deal with flatpak idiosyncrasies.
I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.
In all fairness, Nix is similarly slow.
[From the article "Why I love NixOS"]
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
I feel like if you want to learn Nix with some hand-holding, resist the urge to use Claude Code or Codex, but instead just use the chatbot in the browser or something. Ask it questions, explicitly copy and paste in errors as they come up, and manually copy and paste out the generated stuff.
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
I've recently switched to nix as a way to encode my environment across my server and work / private devices a bit more than just having some Brewfiles. I know it's not worth it for the computer switch every few years but having a somewhat opinionated place to centralize my config is worth it over regular dot files.
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.
I just make my terminal history infinite and ctrl+r "flake".
Add `nix-darwin` to your path (it probably already is on it) and run it while in the directory of the flake: "nix-darwin switch --flake .#private"
I really want to like NixOS (and I mostly do) but the weirdness of the split between NixOS and HomeManager (and the fact that without HomeManager, you need another solution to manage your user-level configs) made it come up a bit short for me.
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'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.
[0]: https://nixos-and-flakes.thiscute.world
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 generate 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.
>I haven’t given it a shot in the LLM age
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.
LLMs are a real gamechanger for Nix, highly recommend giving it a go again.
Flakes are the defacto standard and you're leaving one huge point out. Flake files come with flake lock files. You cannot get lockfiles without using flakes.
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.
NixOS is great. Nix the language is just awful. I still use it for my Dev laptop and for Home Manager on all my devices.
There are so many people complaining about the Nix language while offering zero constructive criticism. I was a little skeptical about them using a custom language at first. But then as I used it more it grew on me and I understand why it is the way it is.
People just seem to want to complain because it doesn't look like any of their favorite languages and they aren't familiar with functional languages. At this point, I can't imagine using any other language in place of Nix. The code would have so much noise and be much harder to read.
You know, I'm not going to say I'm enamored with the language, but I think the Stockholm Syndrome has kicked in because I really don't hate the language so much anymore.
I mean, I'm only ever using it for configurations, and I think I'd still prefer writing Nix than YAML. I probably wouldn't like writing a full "program" with Nix, but I don't think anyone does that?
Sounds like every programming language on the planet. Just skip the "i'm unfamiliar with it, so i hate it" phase, and everything will be fine. People spend more time repeating that simple POV, using thousands of varying words, than is healthy. Just shut up, and do the work. And if you're not going to put in the work, just shut up, and let everyone else get to work.
I mean I don't know that I agree with that completely. Languages can still be actively awful even if you do learn them.
I have written a lot of PHP. In order to learn it I bought several books, I've done a dozen or so projects with it at various jobs, I've written both trivial and non-trivial things, and I have come to the conclusion that PHP is an actively terrible language [1]. It's inconsistent and hard to write in any kind of maintainable way with an ugly syntax and generally-crappy performance for any kind of logic beyond CRUD.
[1] At least version 5, which is the last version I've used. I've heard 7 is better but I'll never know because I swore an oath in blood that I would not do PHP again for less than a million dollars a year.
Nix is a really good good good approach to manage packages. I've configured an entire asahi setup with for my m2 and can't be happier. It's not without it's quirks and nixlang itself is a bit cumbersome to express what you want.
However, AI is a great fit to write flakes. You can easily understand the generated code and it gives a power to "review" the changes before applying them.
And while nixos is amazing, I think nixpkgs are a bit overhyped; I've encountered many packages that are abandoned and outdated.
I can share my configs if anyone is interested.
Definitely interested! I've reinstalled Fedora Asahi Remix several times on my old M1 after fiddling my way into a broken state. NixOS sounds like a tinkerer's dream but getting started is a bit intimidating.
I keep going in circles with thinking about trying NixOS.
I see an article like this about how great it is, think I might try it, then go down a rabbit hole of all the horror stories, and then give up before starting.
This comment thread highlights an issue that Nix has...some people love it personally, some love it professionally. Some are software engineers, others are hackers.
Most of the comments here seem to be from people using NixOS on a laptop. NixOS as a production OS in the cloud or on a robot is a game changer.
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
I'm just curious what your motivation for the patch is, because I too use atuin and see the space-prefix as a feature. It's been around for a while (longer than atuin) to keep certain commands out of my history on purpose, like when running some one-off command with credentials as an arg.
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
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.
All the fun of Terraform with none of the profitability.
For a single machine? Yeah, NixOS' cost surely outweighs the benefits if you're not familiar with Nix.
Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.
> services.desktopManager.gnome.extraGSettingsOverrides =
You can set dconf settings more declaratively: https://tangled.org/jonathan.dickinson.id/nix/blob/7c895ada8...
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 versoining and ability roll back is game changing for SRE Agents and preventing their ability to royally take down services, being able to audit and go back to the previous good known state is gold
I love NixOS and nix-darwing too. Specially now that I can use it without having to learn a bunch of stuff before even getting started. My coding agent is great at it.
NixOS kind of extends the idea of reproducible builds. Any snapshot could be a guarantee that things just work. This can also be extended onto the user base - if one user has solved a problem, it should be solved for all of them. So we can jump from guarantee to guarantee here.
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
dont know. you can create a config package with most distribution. i do config packages for debian. ai can help you on it. you tag it as config-smthg. you save it . you can create a config with a possible rollback organically by just uninstalling it or installing version-x. with this you get atomic changes.
What I'd like to see is Omarchy implemented via the Nix package manager. (Seems like a good project for AI, actually.)
Already exists, although I don’t know how well maintained it is: https://github.com/henrysipp/omarchy-nix
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
Why? Most people’s system configurations are publicly accessible on GitHub. Stuff like Omarchy only makes sense* when the system must be configured imperatively and there is a cost to trying things (accumulation of application residue). When you build your system declaratively you can just copy the bits you like from other people’s configs, or even just run their config as-is.
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
You can point AI to omarchy repo and have it generate a plan and them implement step by step.
My entire config is almost "omarchy", at least visually with hyprland and some other packages.
Most people who try Nix either quit in the first week or never go back to anything else. There is no in between.
That binary feels forced when plenty bounce off it, return six months later, and only get it after a third round of pain. You need to be comfortable reading stack traces. If you want things 'just working' out of the box, Nix still has a talent for making you debug other people's build scripts for an hour, swear at it, and then come back anyway.
Yes, for me it was 2 or 3 rounds of "its just not clicking" before it did and then there was no looking back. Ive heard the same anecdote from lots of others as well.
This is a simple reflection of the fact that Nix has a steep learning curve. People who persist generally have deep-enough interest or a compelling-enough use case to power through.
I feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
There is. Give it a go every few years and decide either Nix is not ready or I am not ready for it.
I'm the inbetween. I stuck with it for a couple of months, but ended up dropping it. It's just too slow and incurs a massive complexity penalty that I'm not happy about. I'd rather just deal with tarball rootfses and union mounts if I want an immutable system (and overwhelmingly I do not.) The reproducible builds are nice and all, but I'm not in a position to really take advantage of it. I'm sure Nix is killer for a modern sysadmin.
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
What would the in between be?
Use it for a month or two and decide it's not for you.
That is in between "use it for very short period of time" and "use it forever"
Gobolinux comes to mind.
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)
Using a regular mutable system and Nix on top using Home Manager for example.
Using it for a year or so and then try another OS is my guess
nixos is love. nixos is life. once you grok it, there's no going back. see you on the other side.
"Loving" any OS is strange to me. It's just a tool. I don't love my kitchen knife, or car. Nor do I love my computer, or any application on it.
Web3, Rust, NixOS. The holy trinity of cult-like appreciation. I do wonder what brings forth such fanaticism.
I love my kitchen knife and I love Emacs. More love is a good thing. Unless you're the kind of person who thinks not loving is better because you've got nothing to lose.
To me, loving inanimate "trivial" things diminishes the value of love. I love my girlfriend and my pets. I like my kitchen knife and my car. To bunch up both into the same category confuses things into "which one do I love the most", some sort of spectrum of love.
In the case of a fire, I'm sure you wouldn't prioritize your laptop with NixOS over your cat (let's imagine that the only backup is in the house that's on fire).
Do you "love" your girlfriend or your pets more? If your girlfriend starts requiring you to view ads before talking, would you still "love" her?
No, you don't have to rank things, there's your mistake. Stop ranking things.
If I say "Girlfriend, I love equally to my operative system" I'm in for a world of trouble.
Don't say it then. Nobody is forcing you to rank anything.
Nix + FreeBSD would be interesting
doesn't it use up a lot of disk space compared to other distros because of the way everything is set up?
Yes. But disk space isn't exactly the most valuable resource you have as a developer/power user
Yes, but you can also reclaim your space. I've configured nix to only store two latest revisions and have a ./switch.sh file that automatically clears everything up after applying nix.
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
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.
Disk space is not an issue as long as you don't try to install the entirety of Texlive.
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.
Use nix.optimise.automatic = true in the config and perform nix-collect-garbage if necessary. With this it doesn't take much.
actually once I garbage collect, nixos actually uses up less disk space for me than other distros
[dead]
[dead]
[dead]