[HN Gopher] NixOS 25.11 released
       ___________________________________________________________________
        
       NixOS 25.11 released
        
       Author : trulyrandom
       Score  : 128 points
       Date   : 2025-11-30 18:21 UTC (4 hours ago)
        
 (HTM) web link (nixos.org)
 (TXT) w3m dump (nixos.org)
        
       | dayjah wrote:
       | 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.
        
         | tstrimple wrote:
         | 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.
        
           | dayjah wrote:
           | 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.
        
             | sestep wrote:
             | 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
        
               | dayjah wrote:
               | 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.
        
         | irusensei wrote:
         | 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.
        
         | xyzzy_plugh wrote:
         | 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.
        
           | arianvanp wrote:
           | They do have and apparently the scale of the repo is actively
           | breaking things: https://discourse.nixos.org/t/nixpkgs-core-
           | team-update-2025-...
        
           | dayjah wrote:
           | 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.
        
         | viraptor wrote:
         | > period nix-darwin and nixpkgs would fall out of sync
         | 
         | What do you mean? Those should be fairly independent in
         | practice.
        
           | dayjah wrote:
           | 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.
        
         | gouggoug wrote:
         | 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...
        
           | xyzzy_plugh wrote:
           | 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.
        
           | evil-olive wrote:
           | > 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
        
           | undeveloper wrote:
           | 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.
        
           | landr0id wrote:
           | 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.
        
           | gf000 wrote:
           | > 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)
        
             | nothrabannosir wrote:
             | 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
        
         | sestep wrote:
         | (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
        
         | hamandcheese wrote:
         | 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.
        
       | foxheadman wrote:
       | 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!
        
         | rkomorn wrote:
         | 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.
        
         | viraptor wrote:
         | 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).
        
           | foxheadman wrote:
           | Yes, it's worth having ~hourly snapshots of your machine,
           | using something like: https://github.com/digint/btrbk
        
           | exe34 wrote:
           | You can still roll-forward specific apps - use the up to date
           | ones if you really need to.
        
         | telotortium wrote:
         | 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."
        
       | digdugdirk wrote:
       | 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.
        
         | para_parolu wrote:
         | 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?"
        
         | wocram wrote:
         | 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.
        
         | endgame wrote:
         | 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 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).
        
         | evil-olive wrote:
         | 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...
        
       | kubafu wrote:
       | 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!
        
       | johnisgood wrote:
       | > 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.
        
       ___________________________________________________________________
       (page generated 2025-11-30 23:00 UTC)