The author <i>almost</i> 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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>I'm sure Nix is better, I just haven't needed it yet.
If you're using Hugo or a similar static site generator, you might like my blog series:<p><a href="https://simonshine.dk/articles/hugo-static-site-setup/" rel="nofollow">https://simonshine.dk/articles/hugo-static-site-setup/</a><p><a href="https://simonshine.dk/articles/vendoring-hugo-themes-with-nix-and-git/" rel="nofollow">https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...</a><p>My blog is deployed here:<p><a href="https://github.com/sshine/nix/blob/main/services/nginx.nix#L88" rel="nofollow">https://github.com/sshine/nix/blob/main/services/nginx.nix#L...</a>
also the AI hallucinating nix options. I have to constantly check <a href="https://search.nixos.org/packages?channel=unstable" rel="nofollow">https://search.nixos.org/packages?channel=unstable</a>
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 :(
Try <a href="https://github.com/utensils/mcp-nixos" rel="nofollow">https://github.com/utensils/mcp-nixos</a>
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.
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.<p>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.<p>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.<p>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.<p>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.<p>One reason to set `mutableUsers = false`: <a href="https://mynixos.com/nixpkgs/option/users.mutableUsers" rel="nofollow">https://mynixos.com/nixpkgs/option/users.mutableUsers</a>.<p>> 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.<p>Impermanence: <a href="https://github.com/nix-community/impermanence" rel="nofollow">https://github.com/nix-community/impermanence</a>.<p>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?<p>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.<p>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:<p>(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)<p>(2) Make destructive changes like install a new windows manager, some drivers etc.<p>(3) If everything worked out well, continue<p>(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before<p>This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.<p>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.<p>There is no distinction between package maintainers and end users. They have the same power.<p>In the meantime i dont expect Debian users to ever write a package themselves or to modify one.<p>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:<p># clone the package definition<p>$ fedpkg clone -a <name of package><p>$ cd <name of package><p># install build dependencies<p>$ sudo dnf builddep ./nameofpackage.spec<p># Now add your patches or modifications<p># now build the package locally<p>$ fedpkg local<p># install locally modified package<p>$ 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.<p>Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.<p>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<p>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.<p>(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.<p>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.<p>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.<p>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."
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.
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.
Actually desktop environments are entirely modular and even audio stacks are just a few packages and enabling a few services
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
Well,<p>programs.hyperland.enable = true<p>is your dnf equivalent on nix. But nix also lets you declare all your key bindings, load Noctalia with systemd, etc.
Some things are not that simple and nix options come in handy automating other packages and services needed.
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.<p>People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
[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.<p>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.<p>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.<p>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).<p>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.<p>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<i>/</i> files and you are free to inject whatever you want.
I totally share the author's view. I posted my experience a while a go to get HN feedback with the title "ClaudeOS - What if Claude Code managed your operating system?", but i didn't specify actually that in the title that ClaudeOS = NixOS + Flakes + Claude Code.<p>My experience so far has been amazing. I'm managing the configuration of different machines with 'Business profiles' that have claude code settings directly managed by me. I set up the repos i want them to have in their machine, clone them with activation scripts, settings, a 'company level' claude.md declared in home manager. I'm seriously considering to use NixOS as the only OS of my company.
Of course just to manage your expectations and give you context. I've been building my startup and we are so far me an my 'Business' cofounder and i don't know yet how to scale it but i definitely want to give it a try. I was shocked that he's using NixOS as daily driver coming from Windows and basically barely knowing what linux is...<p>This setup allow to share CC best practices and settings at speed of light. Skills and plugins are centralized and automatically installed at every build so my colleague basically doesn't even need to know what is a skill.<p>I'm also managing declatively hardware settings of all the different machines, from an old HP to my brand new Framework 16..<p>If you want more details on my config is public on github here <a href="https://github.com/jacopone/nixos-config" rel="nofollow">https://github.com/jacopone/nixos-config</a> would love to have feedback !
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.<p>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.<p>Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.<p>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).<p>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 <i>trust</i> 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.<p>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 <i>and</i> it's endlessly patient when it comes to just figuring everything out from the source code.
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.<p>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.<p>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>it's the only game in town</i><p>Hey now, LLMs are pretty good at Guix, too.
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 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: <a href="https://github.com/leonewt0n/nixos" rel="nofollow">https://github.com/leonewt0n/nixos</a>
Same, I've been playing with kernel settings for AMD, and it's really easy to revert in case things blow up
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.
There's also GUIX.
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.<p>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.<p>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.
That's a solid point.<p>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.<p>My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
Wouldn’t any immutable OS accomplish this goal?
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".<p>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.<p>I feel like NixOS, is one path toward getting to that future.
> 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".<p>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.<p>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 <i>copying</i> those files into the container image instead of just mapping them as a volume.
You mean like <a href="https://wiki.nixos.org/wiki/NixOS_Containers" rel="nofollow">https://wiki.nixos.org/wiki/NixOS_Containers</a> ?
There is also <a href="https://microvm-nix.github.io/microvm.nix/" rel="nofollow">https://microvm-nix.github.io/microvm.nix/</a> if you want increased isolation.
I can recommend MicroVM.nix, since it allows for multiple VM runtimes like QEMU, Firecracker, etc.<p>There's also nixos-shell for ad-hoc virtual machines: <a href="https://github.com/mic92/nixos-shell" rel="nofollow">https://github.com/mic92/nixos-shell</a>
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.<p>That's definitely what I want... most of the time.
Yes, NixOS containers can be run in:<p>* declarative mode, where your guest config is defined within your host config, or<p>* 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.<p>It sounds like you want imperative containers. Here's the docs: <a href="https://nixos.org/manual/nixos/stable/#sec-imperative-containers" rel="nofollow">https://nixos.org/manual/nixos/stable/#sec-imperative-contai...</a>
sounds like you want qubes os <a href="https://www.qubes-os.org/" rel="nofollow">https://www.qubes-os.org/</a>
Sounds like Ghaf might be what you're after: <a href="https://ghaf.tii.ae/ghaf/overview" rel="nofollow">https://ghaf.tii.ae/ghaf/overview</a>
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<p>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.<p>It will always look like curl is available or bash or something<p>What's wrong with another user account for such isolation?<p>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.<p>Every OS already ships with tools for control users access to memory, disk, cpu and network.<p>Nix is just another chef, ansible, cfengine, apt, pacman<p>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.<p>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<p>No, because Nix code is actually composable. These other tools aren't.
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.<p>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.
I still really wish there was a NixOS, but without the quirky filesystem/linking setup.<p>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.<p>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.<p>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.<p>I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
I tried NixOS a few months ago, when I had to choose a new OS for my laptop.<p>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.<p>On the other hand, the current implementation is still a bit of a shit-show.<p>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.<p>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.<p>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.<p>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.<p>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:<p>> there's "Flakes" which I never quite understood<p>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).<p>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.<p>What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake <a href="https://github.com/.../repo.git" rel="nofollow">https://github.com/.../repo.git</a>. I manage <i>all</i> of my system config out of /home/$user/$clone<p>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 <i>many</i> program modules. You can even declare home-level systemd units and whatnot.<p>> manually edited /etc files.<p>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].<p>[1]: <a href="https://search.nixos.org/options?channel=unstable&query=environment.etc&show=environment.etc" rel="nofollow">https://search.nixos.org/options?channel=unstable&query=envi...</a>
[2]: <a href="https://home-manager-options.extranix.com/?query=xdg.configFile&release=release-25.11" rel="nofollow">https://home-manager-options.extranix.com/?query=xdg.configF...</a>
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:<p><a href="https://discourse.nixos.org/t/how-to-manage-dotfiles-with-home-manager/30576/7" rel="nofollow">https://discourse.nixos.org/t/how-to-manage-dotfiles-with-ho...</a><p>> Hi, I just wanted to know, where can I find the documentation to know more about this contrib.lib.file.mkOutOfStoreSymlink option ?<p>> Well, since is a very simple function, no documentation is really needed.<p>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.<p>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<p>Flakes do 2 things:<p>1. Declaration of the inputs and outputs of some Nix codebase.
2. Pinning the versions of this input sources.<p>The dependency pinning is similar to package.json/package.lock etc. which are common in language-specific package managers.
I’m surprised nobody has bothered improving at least the documentation with a few LLM iterations.
I'd love NixOS more if they had any decent documentation.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>> If Nix project really cares about being competitive and adopt users, they have to document their stuff.<p>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? <i>Shrugs</i> but the project is certainly competitive.
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.
+1. I would also recommend using Github search to look for existing examples.
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.
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.<p>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.<p>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).<p>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?<p>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.<p>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.<p>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.<p>Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.<p>You can probably guess what this does:<p><pre><code> networking.firewall.allowedTCPPorts = [ 8080, 9000 ];
</code></pre>
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.
> [ 8080, 9000 ]<p>Fails to parse is what it does...<p>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?<p>I understand this doesn't really matter when just using NixOS Slop Edition™ but man I hate it.
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.
> Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.<p>I am not brand new - and I don't know what the heck the config is doing.<p>That is why I rely on documentation.<p>The "code is self-explanatory" is always an attempt to not have useful documentation and try to rationalise that problem away.
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.<p>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.<p>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".
So relying on closed source code using a closed model to configure a free OS. That's a step back.
Kind of an interesting thing here where if this is how you view it, it kind shows in itself why you don't actually <i>need</i> it.<p>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.<p>The idea is you can keep configuration "in your head" such that you can reason and iterate and fully <i>know</i> 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.<p>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 ...<p>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.<p>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 <i>either way</i>, 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.
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.<p>Nowadays I love it, since I can let Codex manage the servers for me.<p>“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”<p>5 minutes later it came back.
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.<p>It's also simple to setup dev environments with nix.
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.<p>It's also great for the AI era, copilot is really good with that stuff.
> nix is superior in every single way.<p>My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.<p>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.<p>With NixOS, you pay all the complexity up front.
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).<p>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 <i>obviously correct</i> that it started to bother me that it's not the default for everything.<p>Being able to temporarily install things with nix-shell is game changing, and being able to trivially see what's <i>actually</i> 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".<p>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 <i>that</i> 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 <i>do</i> 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.<p>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.<p>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.<p>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.
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using <a href="https://devenv.sh/" rel="nofollow">https://devenv.sh/</a> 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.<p>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.<p>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.<p>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:<p>> How do I set up my development environment using devenv.sh to pin nodejs to 24.14.0?<p>If I understand your response correctly, I can't do this in any very practical way.
It's one of my complaints too.<p>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.<p>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.<p>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.<p>[1] <a href="https://lazamar.co.uk/nix-versions/" rel="nofollow">https://lazamar.co.uk/nix-versions/</a>
Hm. How it's different from home-manager?
home-manager manages your whole user's environment & desktop.<p>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.<p>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.
Can you help me understand why devenv is needed instead of a shell like this/what is gained?<p><pre><code> { pkgs }:
pkgs.mkShell {
nativeBuildInputs = with pkgs; [
# build tools
cmake
ninja
gnumake
pkg-config
];
buildInputs = with pkgs; [
# java
jdk8
# compilers
gcc
clang
llvmPackages.libcxx
# libraries
capstone
icu
openssl_3
libusb1
libftdi
zlib
# scripting
(python3.withPackages (ps: with ps; [
requests
pyelftools
]))
];
# capstone headers are in include/capstone/ but blutter expects include/
shellHook = ''
export CPATH="${pkgs.capstone}/include/capstone:$CPATH"
export CPLUS_INCLUDE_PATH="${pkgs.capstone}/include/capstone:$CPLUS_INCLUDE_PATH"
'';
}</code></pre>
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.<p>Btw, I say this as a huge fan and heavy user of both Nix and NixOS.
“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.
To be honest, I don’t know. I just enjoy the simplicity of devenv. It’s the right amount of user friendly.
devenv lets you express shells as modules.<p>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).<p>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")
[dead]
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.
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.<p>I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.<p>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.<p><a href="https://guix.gnu.org/manual/1.5.0/en/html_node/Inferiors.html" rel="nofollow">https://guix.gnu.org/manual/1.5.0/en/html_node/Inferiors.htm...</a>
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.
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.<p>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.<p>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.<p>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”<p>1. Unified experience across Windows, Mac, Linux<p>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.<p>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!<p>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.<p>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.<p>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 <i>any</i> distro), so it has to install the newer version in $HOME. Once the update is installed, the system package becomes a trampoline to that.<p>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.<p>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.<p>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.<p>Nixpkgs is <i>very</i> complete in my experience, and in the instances where its not, <i>someone</i> usually has made a flake. The only times ive had to custom-make a flake were <i>extremely</i> new programs, or <i>extremely</i> 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.
> 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<p>You can: <a href="https://github.com/nix-community/nix-ld" rel="nofollow">https://github.com/nix-community/nix-ld</a>
They said Nix, so I was thinking about macOS + nix-darwin when I wrote that.<p>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.<p>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.<p>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.<p>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<p>And there's also nix alien and similar tools as alternative<p>But indeed usually you end up using patchelf , tell the inputs of a binary n just make a regular nix package from it
really good question.<p>right now I have bought into the Nix koolaid a bit.<p>I have NixOS Linux machines and then nix-darwin on my Mac.<p>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.
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 <i>reality</i>: 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 keep going in circles with thinking about trying NixOS.<p>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.
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.<p>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.<p>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)<p>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.<p>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.
My love for NixOS really became clear when I realized I never have to write Nix again by hand.<p>A WIP NixOS config for working with agents:<p><a href="https://github.com/dangirsh/tsurf" rel="nofollow">https://github.com/dangirsh/tsurf</a>
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.<p>My first impression after a week of using:<p>- I really dislike the complexity of terraform, and this is very similar<p>- 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<p>- 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".<p>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 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.<p>It took me less than a day of experimenting with it to learn that it is one place only in theory.<p>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.<p>Felt a lot like being on Debian and the software only comes in .rpm<p>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.<p>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.<p>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.
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.
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
> services.desktopManager.gnome.extraGSettingsOverrides =<p>You can set dconf settings more declaratively: <a href="https://tangled.org/jonathan.dickinson.id/nix/blob/7c895ada8889f05cf440cd527fb7d2af2f6571ff/home/common/gnome.nix" rel="nofollow">https://tangled.org/jonathan.dickinson.id/nix/blob/7c895ada8...</a>
[From the article "Why I love NixOS"]<p>> There is also community-maintained support for FreeBSD, though I have not used it personally<p>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.<p>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 !
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!<p>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.<p>What I <i>can</i> 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.<p>[0]: <a href="https://nixos-and-flakes.thiscute.world" rel="nofollow">https://nixos-and-flakes.thiscute.world</a>
>I haven’t given it a shot in the LLM age<p>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.<p>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.
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.
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.<p>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.
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.
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.<p>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).<p>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
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.
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.<p>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 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.
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.<p>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.
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.<p>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.<p>The advantages:<p>- 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 <i>config</i>, not a timestamped blob of snowflake state.<p>- 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.<p>- If you manage multiple machines the benefits are compounding.<p>- 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.<p>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.<p>Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level.<p>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.
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.<p>Web3, Rust, NixOS. The holy trinity of cult-like appreciation. I do wonder what brings forth such fanaticism.
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
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.
actually once I garbage collect, nixos actually uses up less disk space for me than other distros
Use nix.optimise.automatic = true in the config and perform nix-collect-garbage if necessary. With this it doesn't take much.
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: <a href="https://github.com/henrysipp/omarchy-nix" rel="nofollow">https://github.com/henrysipp/omarchy-nix</a><p>Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is <i>way</i> 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.
Most people who try Nix either quit in the first week or never go back to anything else. There is no in between.
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.<p>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.
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.
There is. Give it a go every few years and decide either Nix is not ready or I am not ready for it.
What would the in between be?
Use it for a month or two and decide it's not for you.<p>That is in between "use it for very short period of time" and "use it forever"
Using a regular mutable system and Nix on top using Home Manager for example.
Gobolinux comes to mind.<p>If you don't mind a very limited set of software, the way tinycorelinux is setup can also allow multiple different tcz installed<p>These two Linux distros essentially allow two different versions of same software/libraries (glibc/python whatever) installed<p>(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 it for a year or so and then try another OS is my guess
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.<p>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.<p>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.<p>Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
[dead]
[dead]