For my first few years of NixOS I didn't understand the point of the NixOS stable releases, since even on "nixos-unstable" I found that if my nix config evaluates, then it'll work. And in the very rare case things broke, I could easily rollback.
NixOS stable, for me, provides API stability. I can leave a machine auto-updating, and be confident that my nix config will continue to be compatible, and thus build.
Thanks to the release managers for the work that goes into this!
There's still the data migration issue. If you follow unstable all the time, an app may update its data files or databases at startup. Then, you can still roll back the binaries, but they'll just refuse to work (best case) or corrupt the unknown data format (worst case).
Does Secure Boot with NixOS even make sense? In an ordinary Secure Boot setup, you get the kernel/initrd/etc. with signatures from a trusted vendor, but with NixOS it is going to obviously sign everything locally. That means that you are not protected against bootkits and a root compromise is still just as bad as ever.
I suppose in combination with LUKS you could at least prevent evil maid attacks, to the extent that your machine's firmware is actually secure, but it seems like a lot of work for just that...
Following up on this, has anyone tried this and seen how well it works in practice?
“ Speedify, a proprietary VPN which allows combining multiple internet connections (Wi-Fi, 4G, 5G, Ethernet, Starlink, Satellite, and more) to improve the stability, speed, and security of online experiences. Available as services.speedify.”
I’m about 18mos into managing my macOS hardware with Nix. And I’m conflicted. It’s clearly a powerful system, and I’m still very noob at it. It’s not clear to me that it’s the right solution for macOS. I’ve not felt comfortable enough with it to roll it to Linux hosts yet. Or use its docker image maker.
Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result. It’s amazing that rolling back is as easy as it is, and that’s huge, but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
As time has gone on, more and more of my system is managed via nix-homebrew … effectively producing a Brewfile for the vast majority of my package needs. Why not just use Brewfile directly?
I really want to advocate for nix, but it feels like I lose the “why not x?” conversations with myself, I can’t fathom winning them against a less invested peer.
This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.
Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.
I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.
The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.
I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).
That being said, I'll probably give it another try this month...
> The nix language is also really unpalatable to me.
yeah, I wish I could give you some "it gets better" good news, but...
I've used NixOS as my daily driver for ~10 years, including the laptop I'm typing this on.
I love NixOS-the-OS, I love nixpkgs-the-ecosystem. but I still hate Nix-the-language.
it's like Perl and Haskell had a drunken hookup that produced a child. and then abandoned that child in the forest where it was raised by wolves and didn't have contact with another human until it was fully grown.
(to answer the inevitable replies, yes I understand functional programming in general, and yes I am aware that Guix exists)
for simple NixOS administration, you can get pretty far with treating configuration.nix as "just" a config file, rather than a program written in a Turing-complete functional language.
writing your own modules or flakes, or re-using flakes published by other people, is strictly optional. make friends with The Big Options Page [0] - anything you find there can be dropped into your configuration.nix without really needing to understand Nix-the-language.
> The nix language is also really unpalatable to me.
It may not really help the case, but I firmly believe that it is not the language, but the ecosystem, and is more of a fundamental issue. But maybe putting the blame elsewhere could help accept the situation.
So anyways, the language is pretty much a lazily evaluated JSON. But even if it were something else (insert your favourite language), the problem ultimately is that packaging software is complex especially in a non-standard way, with endless edge cases, requires whole libraries and conventions and this is simply not a well-trodden path. Most programs simply hard-code "traditional" Linux file system conventions and those have to be patched in some way.
So the hard thing is not "is this really a function application here", when writing new Nix code the hard thing is simply knowing that for python there already exist this abstraction in nixpkgs, but to use it you need this folder structure and this build tool, etc. Especially when there are multiple abstractions for the same thing because it's an absolutely huge repository with countless packages.
But the benefits absolutely make up for it big time - there is simply no going back from Nix imo. I would honestly feel constantly "dirty" with any other traditional package manager, it's like file "versioning" before version control.
(PS: just grep for use cases of a function you are looking for. Also, find a "blueprint" package and start from there, e.g. another program written in python with a few native deps)
I've used Nix for at least seven years, and I firmly believe that the language is a large part of the problem. Yes, the Nix language is "just another lazily-evaluated pure FP language in the ML tradition" and "it's like a lazily-evaluated JSON", but it has several large footguns. The biggest one is that spaces are use to separate elements in list literals as well as for function application. The second is the lack of a usable type system, in the sense that the programmer cannot assert the types of values in a useful way. Instead, you have to rely on comments and convention to know what a function's arguments are.
These two design warts also interact with each other really badly: If you try to put a function application into a list and forget to enclose it in parentheses, you instead insert the function as one element in the list and its arguments as successive elements. The usual result is "expected an X but got a function" error in some completely unrelated part of the code.
It is the language. The module system is both semantically indispensable and a second class citizen. It's another language, implemented on top of Nix. Once you have a userland "if" reimplemented in your language you know you're in a bad place. (`mkIf`)
Maybe lazy evaluated attrsets can help make a dent, but still the lack of static types for module code is beyond painful. It's hostile.
I believe Nix is worth it in spite of this, and I'll advise anyone to learn it, it truly is the way forward, but by god do I hope it's not the last step on this journey. Please, Lord, please don't let nixlang be the final iteration XD
I read the same complaint about the language from people I follow who love and actively promote Nix. So it's not just you.
Sorry for adding to your frustration of "just follow what someone else did" but I recently went all-in on managing my Mac (programs, dotfiles, configs, etc) via Nix* when setting up a new machine recently. https://github.com/landaire/config/tree/main/modules
*Nix + homebrew, mostly because Homebrew packages more macOS applications.
I've been on a similar journey this past month, although it sounds like mine went a little more successfully. I've managed to get a repo setup which contains a nix flake with nix-darwin configuration, and it also calls into some home-manager modules which I also use on a linux device as well. I do agree, the nix language isn't particularly to my taste either.
I know you're hoping to go from first principals but I'm happy to share the repo if you want (email in my profile).
Aside from that, what issues did you run into? I'm keen to know if I've just not gone deep enough and will soon hit something.
I had the same reaction my first year. I found the NixOS documentation to be very poor and the lack of a single set of best practices (e.g., imperative, declarative, home config, flakes) to be frustrating.
I switched a couple devices to Guix and was at first encouraged by their much better docs, but the lack of features and battle testing has been a problem with longer use.
I've mostly been happy to go back to NixOS thanks to LLMs. Even a year ago, AI was very good at updating Nix configs and fixing any errors. Ideally Nix would have better docs and a more intuitive unified config system, but LLMs have made it usable and the best solution for now.
I struggled with this too and it took me a while to accept that there is no right way. There are many ways, and there is a lot of legacy style out there, but ultimately you have to do what works for your own productivity/sanity.
you should look into learning how to write modules. nix-darwin at its core is a somewhat underbaked port of nixos to mac OS with the same very useful module system. otherwise look into just getting home-manager working and working your way up.
I'm not conflicted. Nothing compares to nix. I've been using it on macOS, for Linux hosts, for years now, and it's been incredibly rock solid. I stopped using homebrew years ago and I couldn't be happier about that.
> Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result.
I find using a singular nixpkgs version is almost always a recipe for things breaking if you are on unstable. I usually end up juggling multiple nixpkg versions, for example you might want to pin the input to nix-darwin separately.
This is squarely a nixpkgs problem. It's the largest most active package repository known to man. I am pretty sure GitHub has special-cased infrastructure just for it to even function. Things are much more stable in release branches. If that causes you pain because you want the latest and greatest, it's worth considering that you'd experience the same problem with other package repositories (e.g. Debian), and then asking yourself what it is you are actually trying to accomplish. There's a reason they call it unstable.
> but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
If mise works for you then great, use it. When I squint and reason, they do not solve the same issue. I don't know how you come to the same conclusion either. Why are you using nix-darwin at all? What is the overlap between nix-darwin and mise? I don't see it.
If all you want is dev environments, I recommend flox.
At the end of the day I'll continue using nix, and especially nix-darwin, _solely_ because it let me set up a new machine in under 5 minutes and hit the ground running. Nothing else compares.
I got here through devenv, I was fully bought in on its proposal and once I found its edges I started peeking under the covers to understand how it worked.
At that point I was pretty deep in mise for everything that wasn’t using devenv. This perhaps help frame why I see them solving the same problem.
I definitely had my “aha!” and ditched mise because nix seemed it had solved my problems. But now, in a new gig, I’m running into lots of edge cases that mise could solve at the drop of a hat and nix (/ my poor understanding of the fundamentals) struggles with.
So, with that all said, I suppose my point is that you get a lot of overlap between the two, and mise is easier to use and get buy-in on. There are certainly elements I find appealing about nix which mise doesn’t touch (promise of repeatable builds, the entire package ecosystem, etc), however.
I similarly found `nix flake update` frustrating for a while, especially when using unstable Nixpkgs. I wrote a tool called `npc` that basically solved the problem for me by letting me bisect whatever Nixpkgs channel(s) I have in my flake inputs: https://github.com/samestep/npc
I've only barely used Nix on OSX to manage packages and I thought it felt awkward at the time. But I had also barely used NixOS at that time. Today I'm happily running NixOS on my NAS and my "gaming" desktop. My son is running it for his desktop as well. What feels awkward and fragile on OSX is far more stable on NixOS. But you do have to learn some of the Nix syntax and ways of doing things which it sounds like you're already getting some of on OSX. The reason I'm going to use it on OSX again is mostly to get consistent HOME configuration and tooling across all of my devices. I'll manage my OSX home dir and tools with the exact same file across multiple computers.
My principle of adoption was essentially this but in reverse; use it on the system I use the most (macOS), learn, and then use my niche knowledge to apply it to less frequently used computers like my gaming rig.
Along the way I acquired enough talent that use at work seemed reasonable.
As time has gone on, however, I have found things like the stringent need for everything to be built results in archaic packages versions in nixpkgs, etc., while core waits to bump the rustc version. Thus my return to using brew for almost everything albeit managed via nix-homebrew.
Case in point: I use zed, which relies on cutting edge rust features, which nix cannot deploy because of stability concerns. Everyone is right in this situation, but that left me with an archaic version of zed until I moved to the homebrew version.
Could you clarify what you mean regarding Zed? I checked just now and it looks like Nixpkgs had the latest version 0.214.7 within 24 hours of its release: https://github.com/NixOS/nixpkgs/pull/466449
About 4mos ago I moved to using brew for zed because at the time there was some hard block on updating rustc in nixpkgs-stable to a version which included some feature that zed relied upon.
I have both Nixos and Macs so I appreciate I can control everything through a single repo. I have a single flake with nixosConfigurations, darwinConfigurations and home manager pointing to different nixpkgs and other weird stuff such as jovian for my gaming pc and a special repo for my rpi5.
In practice nix-darwin relies on being a drop in, which means maintaining compatibility with api surface which in the proper nixpkgs world is a closed loop. There are several cases of this breaking since 2020 or so.
Notes on how I worked around it for the time it was broken:
> To work around it on myside I tried various things. Fundamentally I rolled back to nixpkgs-24.11-darwin which needed corresponding changes to nix-darwin (nix-darwin-24.11) and home-manager (release-24.11) to get everything working.
I've been using Nix and NixOS for about 5 or 6 years now, extremely thankful for the project. It was my gateway to open source and Linux, and has been pivotal to my career (I work on internal developer experience and environments + CI infrastructure).
It's certainly not for everyone, but for anyone who's full time job involves managing runtime environments it is second to none.
Does anyone have a good resource for a quickstart/high-level overview of just the terminology required to understand Nix? Flakes/overlays/nixpkgs/etc. I start wading in to try and understand it, and instead run into arguments and disagreements.
Unfortunately, without a base level understanding of the entire ecosystem, I stay lost.
yeah, the "entry-level" documentation is definitely one of the weak points of the Nix ecosystem. I'd compare it to trying to learn how to do oil changes on your car and only finding "car guy" web forums full of posts about transmission rebuilds and 3D printing your own carburetors.
my recommendation (as I said elsewhere in this thread, I'm a 10+ year NixOS user) would be to install NixOS on a VM or spare laptop and tinker with configuring it. you can follow the breadcrumbs, for example enabling sshd [0] has a "declared in" link to [1] where you can read the Nix source code of what that NixOS option actually does on your system.
flakes, modules, and overlays are all relatively "advanced" parts of the ecosystem, you don't need to know them as a new user. in particular, you will find many blog posts telling you to use flakes right from the beginning. that's an option, but not at all required.
I started playing with nix few months ago. Youtube videos from Vimjoyer helped a lot.
On top of that Claude Code is very good at understanding/explaining/updating config.
Regarding features: so far for my home setup (few vms on proxmox) I only needed flakes. They age good at organizing multihost config.
But besides it it works smoothly. And I constantly have thought “wait, why we didn’t always do it this way?”
This article and video might be good for you, but they are more about a conceptual overview of what the fundamental parts of Nix are and how they interact.
Flakes are a dependency-pinning and hermetic evaluation feature baked into the Nix tool itself.
Overlays are an idiom that uses lazy evaluation to build up larger attribute sets in a modular and composable way (e.g., package collections for a particular programming language).
For certain people i think "entry level" for nix means trying to re-read tutorials every couple of years and it never ever feeling comfortable or memorable... but somehow it still itches in the back of your mind that this is how things are suppose to be done. But why is it so... different?
You don't need flakes or some fundamental understanding for a quick start. I simply add programs that I use to configuration.nix. This covers 95% of my use cases. For everything else I use containers. This may be not the nix way, but works super reliably and without much trouble.
No, but I can empathize. I never understood the Nix language. It's impenetrable to me. I hate it so much.
I keep checking back every year or so secretly hoping they'll have upgraded the language. It's fascinating how successful Nix is given how utterly opaque the language is.
Instability is one of the biggest but perhaps also the least understood downsides of NixOS, IMHO.
Contrary to the name, even the stable branch of NixOS can have problems while installing routine updates with `nixos-rebuild switch --upgrade`. In fairness, at least with NixOS you can normally roll back to a previous working configuration where you can try to fix or work around the problem if that does happen. It’s still painful if you have to do that, though.
Even if your routine updates all go smoothly, as you mentioned, each stable release is only supported for a very limited time window after the next one is out. NixOS doesn’t have any long-term support branch in the sense that some distros do. Again, you can overcome this to a degree by customising your configuration if you need specific versions of certain packages, but in doing so you’re moving back towards manually setting things up and resolving your own compatibility issues rather than having a distro with compatible packages you can install in whatever combination you want, which reduces the value of using a distro with a package repository in the first place.
To be clear, I’m a big fan of NixOS. I run it as my daily driver on a workstation where I do a lot of work on different projects for different clients. Its ability to have a clean, declarative description of what’s currently installed globally or for any given user or even when working in any given project directory for any given user is extremely valuable to me.
But it’s also fair to say that NixOS is not for everyone. It has been by far the least stable Linux distro I have ever used, in the sense of “If I turn my computer on and install the latest updates from the stable branch, will my computer still work afterwards?”. If you’re looking for a distro you can deploy and then maintain with little more than semi-automatic routine updates for a period of years then, at least for now, it is not the distro for you.
Very interesting to read this. I've never had breakage, but now I'm questioning whether this is the exception, not the rule.
On ubuntu, every new version broke something, sometimes updates make the computer boot to a blank screen... it was a terrible experince for early-days linux users. This was many years ago, but it made me distrust most distros I tried. Except for nixos.
I can only speak anecdotally, so it’s entirely possible that I’ve just been unlucky with this particular box, but I’ve seen a few quite serious issues going back over the past few years since I switched to NixOS as my primary OS.
Not so long ago there was some sort of problem with Hydra builds for a recent version of Node. That seemed to result in trying to build the whole thing locally on every update, taking a huge amount of time and then typically failing there as well.
I’ve seen things with Nvidia drivers vs Linux kernel versions as well. We did have a specific reason for choosing Nvidia for that particular workstation, but otherwise, I’d agree with popular advice to get AMD if you’re building a Linux box, just based on the frequency and severity of Nvidia driver issues we’ve seen here.
I’ve seen a few issues with Ubuntu upgrades over the years as well, and wouldn’t necessarily rate that much higher for stability. That’s always surprised me because IME Debian Stable is the gold standard — something I’ve trusted with our production servers for well over a decade now, from unattended upgrades to several major new releases, and barely seen a flicker of a hint of anything breaking in all that time. To be fair, I haven’t used Debian much on workstations, so I don’t know whether the kinds of issues I’ve experienced with NixOS and Ubuntu would have been more common if I had.
NixOS is mostly a rolling-release distro, like Arch, but it rolls a bit more slowly. You can opt into full rolling release with the "unstable" branch, which is very common. There's not a lot of benefit to "stable" IMO.
Er, no it isn't? Yes, unstable is rolling, but otherwise it has releases, like 25.11, which contain breaking changes. It cuts new releases quite quickly and drops old ones fast, but that doesn't make it a rolling distro.
I am excited for having a new version of NixOS. Few days ago I realized that November is almost gone and went looking for when I can expect the new release. And right on schedule it popped out (was checking throughout the day). Big props to the release managers (and of course the maintainers)
I use nix via flakes on my own machines (via NixOS), in my projects (with direnv), on my infrastructure/servers (NixOS deploying with colmena) and at work (nix-darwin and projects). So far the upgrade have gone painlessly, the only change I needed to make is how git is configured in home manager. I continue to be amazed how well NixOS works.
Edit: The only place I still struggle in adopting nix is on my phone. Last time I tried nix-on-droid it didn't even run, but I plan to try that again. Still new to Android (and GrapheneOS)
The only linux distro where I've never experienced disruption whatsoever when a new version comes in. A testament to the validity of the approach they are using (immutability). They also have a simple way to package things, and this produced the largest repository of packages of any linux distro. If something works, it stays working, breakage after updating is unheard of. The unofficial motto is "nixos fixes that."
Forgot to mention Nvidia CUDA is now a first-class citizen. Nix becomes a support target for Nvidia. How times have changed, thanks to Google scaring the bejezus of Nvidia by running Gemini on their TPUs. Nvidia may finally get their act together on linux
This will be another upgrade for my dev machine running NixOS since 17.something times. Thanks to all maintaines and release managers over the years for such solid work!
> Added nixos-init, a Rust-based bashless initialization system for systemd initrd
Rust is such a heavy dependency though, is it not? Is it worth it? Additionally, what does it add as a new project / software (disregard Rust here)? What was wrong with the previous one and/or what does this fix or add that justifies adding a heavy dependency? Seems like most of these projects are written in Rust though.
Previous version was in bash. With this change you can build a nixos image not containing bash or any shell whatsoever.
Not having interpreted languages on the system at all is an effective hardening technique combined with verity store containing all your executables as it makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors.
I'm glad to see boot security prioritisation, and to see some of the fundamentals revisited, and scripts replaced with languages that contributors want to write in (NixOS leans heavy towards Rust).
As the project doc notes:
> This radical solution is only really feasible and/or interesting for appliances (i.e. non-interactive) systems.
Can you explain a bit more about this? Is the idea that verity protects the integrity of the nix store, and then the boot process only runs binaries that don't expose any sort of arbitrary code functionality?
> makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors
If you have code execution - any kind - you have code execution. It really doesn't matter if a shell is available or not, you're always an open(2), write(2), and execve(2) away from creating and invoking a new executable, or just mmap(2)ing a new executable region in the current process. Yes, most exploits leverage a shell because it's convenient, so you're making it a little bit more annoying by having to first write an executable, but it really doesn't stop attacks like this.
Much more effective measures are those that prevent program takeover in the first place (SSP, ASLR), and things like W^X.
Reading the NixOS release notes every 6 months is how I learn about new software that I might want to try: https://nixos.org/manual/nixos/stable/release-notes#sec-rele...
For my first few years of NixOS I didn't understand the point of the NixOS stable releases, since even on "nixos-unstable" I found that if my nix config evaluates, then it'll work. And in the very rare case things broke, I could easily rollback.
NixOS stable, for me, provides API stability. I can leave a machine auto-updating, and be confident that my nix config will continue to be compatible, and thus build.
Thanks to the release managers for the work that goes into this!
There's still the data migration issue. If you follow unstable all the time, an app may update its data files or databases at startup. Then, you can still roll back the binaries, but they'll just refuse to work (best case) or corrupt the unknown data format (worst case).
Yes, it's worth having ~hourly snapshots of your machine, using something like: https://github.com/digint/btrbk
You can still roll-forward specific apps - use the up to date ones if you really need to.
Indeed.
As soon as lanzaboote works with stable, I'll go back to stable (but I think that is not the case yet, sadly).
Lowkey plug for lanzaboote though. Getting secure boot working went pretty well for me thanks to it.
Does Secure Boot with NixOS even make sense? In an ordinary Secure Boot setup, you get the kernel/initrd/etc. with signatures from a trusted vendor, but with NixOS it is going to obviously sign everything locally. That means that you are not protected against bootkits and a root compromise is still just as bad as ever.
I suppose in combination with LUKS you could at least prevent evil maid attacks, to the extent that your machine's firmware is actually secure, but it seems like a lot of work for just that...
To be honest, for me it boiled down to "I don't have to type in my LUKS password by hand" combined with some intellectual curiosity.
I didn't have some strong security-driven mindset behind it.
That said I did also lock down my BIOS with a password (to prevent disabling secure boot).
+1.
I'm keen for secure boot and TPM FDE, and would like to see lanzaboote in nixpkgs.
Following up on this, has anyone tried this and seen how well it works in practice?
“ Speedify, a proprietary VPN which allows combining multiple internet connections (Wi-Fi, 4G, 5G, Ethernet, Starlink, Satellite, and more) to improve the stability, speed, and security of online experiences. Available as services.speedify.”
I’m about 18mos into managing my macOS hardware with Nix. And I’m conflicted. It’s clearly a powerful system, and I’m still very noob at it. It’s not clear to me that it’s the right solution for macOS. I’ve not felt comfortable enough with it to roll it to Linux hosts yet. Or use its docker image maker.
Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result. It’s amazing that rolling back is as easy as it is, and that’s huge, but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
As time has gone on, more and more of my system is managed via nix-homebrew … effectively producing a Brewfile for the vast majority of my package needs. Why not just use Brewfile directly?
I really want to advocate for nix, but it feels like I lose the “why not x?” conversations with myself, I can’t fathom winning them against a less invested peer.
This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.
Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.
I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.
The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.
I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).
That being said, I'll probably give it another try this month...
> The nix language is also really unpalatable to me.
yeah, I wish I could give you some "it gets better" good news, but...
I've used NixOS as my daily driver for ~10 years, including the laptop I'm typing this on.
I love NixOS-the-OS, I love nixpkgs-the-ecosystem. but I still hate Nix-the-language.
it's like Perl and Haskell had a drunken hookup that produced a child. and then abandoned that child in the forest where it was raised by wolves and didn't have contact with another human until it was fully grown.
(to answer the inevitable replies, yes I understand functional programming in general, and yes I am aware that Guix exists)
for simple NixOS administration, you can get pretty far with treating configuration.nix as "just" a config file, rather than a program written in a Turing-complete functional language.
writing your own modules or flakes, or re-using flakes published by other people, is strictly optional. make friends with The Big Options Page [0] - anything you find there can be dropped into your configuration.nix without really needing to understand Nix-the-language.
0: https://search.nixos.org/options?channel=25.11
Which part of the nix language looks like Perl?
I actually find the language simple and easy to learn: It's just untyped lambda calculus with dicts and lists.
(I, too, would like static types though.)
I'm not them, but TIMTOWTDI is a bad thing, and Nix suffers from it. That's the main Perl-ism I can think of.
> The nix language is also really unpalatable to me.
It may not really help the case, but I firmly believe that it is not the language, but the ecosystem, and is more of a fundamental issue. But maybe putting the blame elsewhere could help accept the situation.
So anyways, the language is pretty much a lazily evaluated JSON. But even if it were something else (insert your favourite language), the problem ultimately is that packaging software is complex especially in a non-standard way, with endless edge cases, requires whole libraries and conventions and this is simply not a well-trodden path. Most programs simply hard-code "traditional" Linux file system conventions and those have to be patched in some way.
So the hard thing is not "is this really a function application here", when writing new Nix code the hard thing is simply knowing that for python there already exist this abstraction in nixpkgs, but to use it you need this folder structure and this build tool, etc. Especially when there are multiple abstractions for the same thing because it's an absolutely huge repository with countless packages.
But the benefits absolutely make up for it big time - there is simply no going back from Nix imo. I would honestly feel constantly "dirty" with any other traditional package manager, it's like file "versioning" before version control.
(PS: just grep for use cases of a function you are looking for. Also, find a "blueprint" package and start from there, e.g. another program written in python with a few native deps)
I've used Nix for at least seven years, and I firmly believe that the language is a large part of the problem. Yes, the Nix language is "just another lazily-evaluated pure FP language in the ML tradition" and "it's like a lazily-evaluated JSON", but it has several large footguns. The biggest one is that spaces are use to separate elements in list literals as well as for function application. The second is the lack of a usable type system, in the sense that the programmer cannot assert the types of values in a useful way. Instead, you have to rely on comments and convention to know what a function's arguments are.
These two design warts also interact with each other really badly: If you try to put a function application into a list and forget to enclose it in parentheses, you instead insert the function as one element in the list and its arguments as successive elements. The usual result is "expected an X but got a function" error in some completely unrelated part of the code.
It is the language. The module system is both semantically indispensable and a second class citizen. It's another language, implemented on top of Nix. Once you have a userland "if" reimplemented in your language you know you're in a bad place. (`mkIf`)
Maybe lazy evaluated attrsets can help make a dent, but still the lack of static types for module code is beyond painful. It's hostile.
I believe Nix is worth it in spite of this, and I'll advise anyone to learn it, it truly is the way forward, but by god do I hope it's not the last step on this journey. Please, Lord, please don't let nixlang be the final iteration XD
I read the same complaint about the language from people I follow who love and actively promote Nix. So it's not just you.
Sorry for adding to your frustration of "just follow what someone else did" but I recently went all-in on managing my Mac (programs, dotfiles, configs, etc) via Nix* when setting up a new machine recently. https://github.com/landaire/config/tree/main/modules
*Nix + homebrew, mostly because Homebrew packages more macOS applications.
I've been on a similar journey this past month, although it sounds like mine went a little more successfully. I've managed to get a repo setup which contains a nix flake with nix-darwin configuration, and it also calls into some home-manager modules which I also use on a linux device as well. I do agree, the nix language isn't particularly to my taste either.
I know you're hoping to go from first principals but I'm happy to share the repo if you want (email in my profile).
Aside from that, what issues did you run into? I'm keen to know if I've just not gone deep enough and will soon hit something.
I had the same reaction my first year. I found the NixOS documentation to be very poor and the lack of a single set of best practices (e.g., imperative, declarative, home config, flakes) to be frustrating.
I switched a couple devices to Guix and was at first encouraged by their much better docs, but the lack of features and battle testing has been a problem with longer use.
I've mostly been happy to go back to NixOS thanks to LLMs. Even a year ago, AI was very good at updating Nix configs and fixing any errors. Ideally Nix would have better docs and a more intuitive unified config system, but LLMs have made it usable and the best solution for now.
I struggled with this too and it took me a while to accept that there is no right way. There are many ways, and there is a lot of legacy style out there, but ultimately you have to do what works for your own productivity/sanity.
you should look into learning how to write modules. nix-darwin at its core is a somewhat underbaked port of nixos to mac OS with the same very useful module system. otherwise look into just getting home-manager working and working your way up.
I'm not conflicted. Nothing compares to nix. I've been using it on macOS, for Linux hosts, for years now, and it's been incredibly rock solid. I stopped using homebrew years ago and I couldn't be happier about that.
> Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result.
I find using a singular nixpkgs version is almost always a recipe for things breaking if you are on unstable. I usually end up juggling multiple nixpkg versions, for example you might want to pin the input to nix-darwin separately.
This is squarely a nixpkgs problem. It's the largest most active package repository known to man. I am pretty sure GitHub has special-cased infrastructure just for it to even function. Things are much more stable in release branches. If that causes you pain because you want the latest and greatest, it's worth considering that you'd experience the same problem with other package repositories (e.g. Debian), and then asking yourself what it is you are actually trying to accomplish. There's a reason they call it unstable.
> but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
If mise works for you then great, use it. When I squint and reason, they do not solve the same issue. I don't know how you come to the same conclusion either. Why are you using nix-darwin at all? What is the overlap between nix-darwin and mise? I don't see it.
If all you want is dev environments, I recommend flox.
At the end of the day I'll continue using nix, and especially nix-darwin, _solely_ because it let me set up a new machine in under 5 minutes and hit the ground running. Nothing else compares.
They do have and apparently the scale of the repo is actively breaking things: https://discourse.nixos.org/t/nixpkgs-core-team-update-2025-...
This is all great feedback, thanks!
I got here through devenv, I was fully bought in on its proposal and once I found its edges I started peeking under the covers to understand how it worked.
At that point I was pretty deep in mise for everything that wasn’t using devenv. This perhaps help frame why I see them solving the same problem.
I definitely had my “aha!” and ditched mise because nix seemed it had solved my problems. But now, in a new gig, I’m running into lots of edge cases that mise could solve at the drop of a hat and nix (/ my poor understanding of the fundamentals) struggles with.
So, with that all said, I suppose my point is that you get a lot of overlap between the two, and mise is easier to use and get buy-in on. There are certainly elements I find appealing about nix which mise doesn’t touch (promise of repeatable builds, the entire package ecosystem, etc), however.
mise will be a better mise than nix will. You should use mise.
Especially because installing Nix is still a pain for most users.
(disclaimer: self-plug)
I similarly found `nix flake update` frustrating for a while, especially when using unstable Nixpkgs. I wrote a tool called `npc` that basically solved the problem for me by letting me bisect whatever Nixpkgs channel(s) I have in my flake inputs: https://github.com/samestep/npc
I've only barely used Nix on OSX to manage packages and I thought it felt awkward at the time. But I had also barely used NixOS at that time. Today I'm happily running NixOS on my NAS and my "gaming" desktop. My son is running it for his desktop as well. What feels awkward and fragile on OSX is far more stable on NixOS. But you do have to learn some of the Nix syntax and ways of doing things which it sounds like you're already getting some of on OSX. The reason I'm going to use it on OSX again is mostly to get consistent HOME configuration and tooling across all of my devices. I'll manage my OSX home dir and tools with the exact same file across multiple computers.
My principle of adoption was essentially this but in reverse; use it on the system I use the most (macOS), learn, and then use my niche knowledge to apply it to less frequently used computers like my gaming rig.
Along the way I acquired enough talent that use at work seemed reasonable.
As time has gone on, however, I have found things like the stringent need for everything to be built results in archaic packages versions in nixpkgs, etc., while core waits to bump the rustc version. Thus my return to using brew for almost everything albeit managed via nix-homebrew.
Case in point: I use zed, which relies on cutting edge rust features, which nix cannot deploy because of stability concerns. Everyone is right in this situation, but that left me with an archaic version of zed until I moved to the homebrew version.
Could you clarify what you mean regarding Zed? I checked just now and it looks like Nixpkgs had the latest version 0.214.7 within 24 hours of its release: https://github.com/NixOS/nixpkgs/pull/466449
That’s great to know! There are plenty of issues which are reasonably well documented in the zed repo.
https://github.com/zed-industries/zed/issues/26277
About 4mos ago I moved to using brew for zed because at the time there was some hard block on updating rustc in nixpkgs-stable to a version which included some feature that zed relied upon.
Have been down this path and just realised: I get the same result and a lot less of a hassle by just using bash scripts and brewfile etc.
Making a change with home manager became a whole thing.
Now I’m back on the happy path and it’s great. The LLMs can also move things over very fast.
My remaining uses of nix are just devbox which is a very palatable wrapper and nicer to use than flakes.
I have both Nixos and Macs so I appreciate I can control everything through a single repo. I have a single flake with nixosConfigurations, darwinConfigurations and home manager pointing to different nixpkgs and other weird stuff such as jovian for my gaming pc and a special repo for my rpi5.
I very much do not recommend nix-darwin.
I do very much recommend home-manager, which will manage your dot-files and cli packages, and is portable between macOS and Linux.
> period nix-darwin and nixpkgs would fall out of sync
What do you mean? Those should be fairly independent in practice.
In practice nix-darwin relies on being a drop in, which means maintaining compatibility with api surface which in the proper nixpkgs world is a closed loop. There are several cases of this breaking since 2020 or so.
But did that happen while updating from the same stable channel? I get things could change when switching releases.
Pretty sure I just ran a nix flake update.
Here are the links from my journal:
This went into nixpkgs: https://github.com/NixOS/nixpkgs/pull/376988
Which then changed the api between and broke this: https://github.com/LnL7/nix-darwin/blob/master/modules/nix/n...
The fix took a few hours, I happened to be one of the first folks bit by it: https://github.com/LnL7/nix-darwin/pull/1318
I also have in my notes that Emilazy is a super star: https://github.com/emilazy
Notes on how I worked around it for the time it was broken:
> To work around it on myside I tried various things. Fundamentally I rolled back to nixpkgs-24.11-darwin which needed corresponding changes to nix-darwin (nix-darwin-24.11) and home-manager (release-24.11) to get everything working.
I've been using Nix and NixOS for about 5 or 6 years now, extremely thankful for the project. It was my gateway to open source and Linux, and has been pivotal to my career (I work on internal developer experience and environments + CI infrastructure).
It's certainly not for everyone, but for anyone who's full time job involves managing runtime environments it is second to none.
Does anyone have a good resource for a quickstart/high-level overview of just the terminology required to understand Nix? Flakes/overlays/nixpkgs/etc. I start wading in to try and understand it, and instead run into arguments and disagreements.
Unfortunately, without a base level understanding of the entire ecosystem, I stay lost.
yeah, the "entry-level" documentation is definitely one of the weak points of the Nix ecosystem. I'd compare it to trying to learn how to do oil changes on your car and only finding "car guy" web forums full of posts about transmission rebuilds and 3D printing your own carburetors.
my recommendation (as I said elsewhere in this thread, I'm a 10+ year NixOS user) would be to install NixOS on a VM or spare laptop and tinker with configuring it. you can follow the breadcrumbs, for example enabling sshd [0] has a "declared in" link to [1] where you can read the Nix source code of what that NixOS option actually does on your system.
flakes, modules, and overlays are all relatively "advanced" parts of the ecosystem, you don't need to know them as a new user. in particular, you will find many blog posts telling you to use flakes right from the beginning. that's an option, but not at all required.
0: https://search.nixos.org/options?channel=25.11&show=services...
1: https://github.com/NixOS/nixpkgs/blob/nixos-25.11/nixos/modu...
I started playing with nix few months ago. Youtube videos from Vimjoyer helped a lot. On top of that Claude Code is very good at understanding/explaining/updating config.
Regarding features: so far for my home setup (few vms on proxmox) I only needed flakes. They age good at organizing multihost config.
But besides it it works smoothly. And I constantly have thought “wait, why we didn’t always do it this way?”
This article and video might be good for you, but they are more about a conceptual overview of what the fundamental parts of Nix are and how they interact.
https://shopify.engineering/shipit-presents-how-shopify-uses...
https://www.youtube.com/watch?v=6iVXaqUfHi4
Flakes are a dependency-pinning and hermetic evaluation feature baked into the Nix tool itself.
Overlays are an idiom that uses lazy evaluation to build up larger attribute sets in a modular and composable way (e.g., package collections for a particular programming language).
https://nixos-and-flakes.thiscute.world/ is a great guide to Nix with Flakes.
This was the Nix config that helped it 'click' for me: https://github.com/eh8/chenglab that mentions this guide.
I based my own config off of it https://github.com/richardgill/nix
For certain people i think "entry level" for nix means trying to re-read tutorials every couple of years and it never ever feeling comfortable or memorable... but somehow it still itches in the back of your mind that this is how things are suppose to be done. But why is it so... different?
You don't need flakes or some fundamental understanding for a quick start. I simply add programs that I use to configuration.nix. This covers 95% of my use cases. For everything else I use containers. This may be not the nix way, but works super reliably and without much trouble.
Level 1 is using nix to install packages, which you can do by writing a flake like.
The arguments probably come from the fact that flakes are 'experimental', but de facto widely used.
No, but I can empathize. I never understood the Nix language. It's impenetrable to me. I hate it so much.
I keep checking back every year or so secretly hoping they'll have upgraded the language. It's fascinating how successful Nix is given how utterly opaque the language is.
Apparently not
> The old release 25.05 “Warbler” is now officially deprecated and will reach its end-of-life and stop receiving security updates after 2025-12-31.
What, one month to upgrade to keep receiving security updates? How can you force 1-month upgrade windows every 6 months and who would go for that?
Instability is one of the biggest but perhaps also the least understood downsides of NixOS, IMHO.
Contrary to the name, even the stable branch of NixOS can have problems while installing routine updates with `nixos-rebuild switch --upgrade`. In fairness, at least with NixOS you can normally roll back to a previous working configuration where you can try to fix or work around the problem if that does happen. It’s still painful if you have to do that, though.
Even if your routine updates all go smoothly, as you mentioned, each stable release is only supported for a very limited time window after the next one is out. NixOS doesn’t have any long-term support branch in the sense that some distros do. Again, you can overcome this to a degree by customising your configuration if you need specific versions of certain packages, but in doing so you’re moving back towards manually setting things up and resolving your own compatibility issues rather than having a distro with compatible packages you can install in whatever combination you want, which reduces the value of using a distro with a package repository in the first place.
To be clear, I’m a big fan of NixOS. I run it as my daily driver on a workstation where I do a lot of work on different projects for different clients. Its ability to have a clean, declarative description of what’s currently installed globally or for any given user or even when working in any given project directory for any given user is extremely valuable to me.
But it’s also fair to say that NixOS is not for everyone. It has been by far the least stable Linux distro I have ever used, in the sense of “If I turn my computer on and install the latest updates from the stable branch, will my computer still work afterwards?”. If you’re looking for a distro you can deploy and then maintain with little more than semi-automatic routine updates for a period of years then, at least for now, it is not the distro for you.
Very interesting to read this. I've never had breakage, but now I'm questioning whether this is the exception, not the rule.
On ubuntu, every new version broke something, sometimes updates make the computer boot to a blank screen... it was a terrible experince for early-days linux users. This was many years ago, but it made me distrust most distros I tried. Except for nixos.
I can only speak anecdotally, so it’s entirely possible that I’ve just been unlucky with this particular box, but I’ve seen a few quite serious issues going back over the past few years since I switched to NixOS as my primary OS.
Not so long ago there was some sort of problem with Hydra builds for a recent version of Node. That seemed to result in trying to build the whole thing locally on every update, taking a huge amount of time and then typically failing there as well.
I’ve seen things with Nvidia drivers vs Linux kernel versions as well. We did have a specific reason for choosing Nvidia for that particular workstation, but otherwise, I’d agree with popular advice to get AMD if you’re building a Linux box, just based on the frequency and severity of Nvidia driver issues we’ve seen here.
I’ve seen a few issues with Ubuntu upgrades over the years as well, and wouldn’t necessarily rate that much higher for stability. That’s always surprised me because IME Debian Stable is the gold standard — something I’ve trusted with our production servers for well over a decade now, from unattended upgrades to several major new releases, and barely seen a flicker of a hint of anything breaking in all that time. To be fair, I haven’t used Debian much on workstations, so I don’t know whether the kinds of issues I’ve experienced with NixOS and Ubuntu would have been more common if I had.
NixOS is mostly a rolling-release distro, like Arch, but it rolls a bit more slowly. You can opt into full rolling release with the "unstable" branch, which is very common. There's not a lot of benefit to "stable" IMO.
Er, no it isn't? Yes, unstable is rolling, but otherwise it has releases, like 25.11, which contain breaking changes. It cuts new releases quite quickly and drops old ones fast, but that doesn't make it a rolling distro.
I am excited for having a new version of NixOS. Few days ago I realized that November is almost gone and went looking for when I can expect the new release. And right on schedule it popped out (was checking throughout the day). Big props to the release managers (and of course the maintainers)
I use nix via flakes on my own machines (via NixOS), in my projects (with direnv), on my infrastructure/servers (NixOS deploying with colmena) and at work (nix-darwin and projects). So far the upgrade have gone painlessly, the only change I needed to make is how git is configured in home manager. I continue to be amazed how well NixOS works.
Edit: The only place I still struggle in adopting nix is on my phone. Last time I tried nix-on-droid it didn't even run, but I plan to try that again. Still new to Android (and GrapheneOS)
The only linux distro where I've never experienced disruption whatsoever when a new version comes in. A testament to the validity of the approach they are using (immutability). They also have a simple way to package things, and this produced the largest repository of packages of any linux distro. If something works, it stays working, breakage after updating is unheard of. The unofficial motto is "nixos fixes that."
Forgot to mention Nvidia CUDA is now a first-class citizen. Nix becomes a support target for Nvidia. How times have changed, thanks to Google scaring the bejezus of Nvidia by running Gemini on their TPUs. Nvidia may finally get their act together on linux
NixOS is the only distro that may tempt me away from Slackware one day.
This will be another upgrade for my dev machine running NixOS since 17.something times. Thanks to all maintaines and release managers over the years for such solid work!
[dead]
> Added nixos-init, a Rust-based bashless initialization system for systemd initrd
Rust is such a heavy dependency though, is it not? Is it worth it? Additionally, what does it add as a new project / software (disregard Rust here)? What was wrong with the previous one and/or what does this fix or add that justifies adding a heavy dependency? Seems like most of these projects are written in Rust though.
Previous version was in bash. With this change you can build a nixos image not containing bash or any shell whatsoever. Not having interpreted languages on the system at all is an effective hardening technique combined with verity store containing all your executables as it makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors.
You can read about the project here: https://github.com/NixOS/nixpkgs/issues/428908
I'm glad to see boot security prioritisation, and to see some of the fundamentals revisited, and scripts replaced with languages that contributors want to write in (NixOS leans heavy towards Rust).
As the project doc notes:
> This radical solution is only really feasible and/or interesting for appliances (i.e. non-interactive) systems.
https://pad.lassul.us/nixos-perlless-activation
> stops almost all attack vectors
Can you explain a bit more about this? Is the idea that verity protects the integrity of the nix store, and then the boot process only runs binaries that don't expose any sort of arbitrary code functionality?
I agree with https://github.com/NixOS/nixpkgs/issues/267982#issuecomment-... that the MITRE attack vector link doesn't help understanding much. Is the right idea: removing attack vectors is useful? (I agree.)
> makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors
If you have code execution - any kind - you have code execution. It really doesn't matter if a shell is available or not, you're always an open(2), write(2), and execve(2) away from creating and invoking a new executable, or just mmap(2)ing a new executable region in the current process. Yes, most exploits leverage a shell because it's convenient, so you're making it a little bit more annoying by having to first write an executable, but it really doesn't stop attacks like this.
Much more effective measures are those that prevent program takeover in the first place (SSP, ASLR), and things like W^X.