NixOS 25.11 released
73 points by Tenzer
73 points by Tenzer
From a darwin maintainer's perspective, it's amazing how much we have progressed in the last two years thanks to the work of Randy and Emily. Nixpkgs on darwin is in a really good place now, and Vulkan applications looking to port to darwin are in for a treat with KosmicKrisp possibly landing in 26.05. That and Swift 6 are certainly something to look forward to in the next release.
KosmicKrisp will depend on how well it works. If they haven’t closed the gap with feature support compared to MoltenVK, it will be made available when Mesa is updated in nixpkgs, but it probably won’t be made the default for 26.05. (My litmus test is whether I can use it in place of MoltenVK with DXVK 1.10.3. Currently, it can’t be.)
Swift 6 is finally coming to nixpkgs? I was so excited to try it recently and then found out NixOS was on 5.8 or something...
It was updated to 5.10.1 by samasaur for 25.11. Swift 5.8.1 needed the 13.3 SDK, which was removed for 25.11. Unfortunately, Swift 5.8.1 wouldn’t build with the 14.4 SDK, but Swift 5.10.1 does.
I was working on a rewrite of Swift support that would have added Swift 6.1.1 in addition to 5.10.1 (because Swift 6.1.1 requires a Swift compiler to bootstrap), but I got busy with life stuff and hadn’t been able to work on it since July. Fortunately, I’m able to work on it again. Swift 6.2 can be bootstrapped only with a C++ compiler, but I plan to keep the improvements because they were also done to improve ergonomics and make Swift easier to use.
I’m trying to keep things compatible, but there are a few technically breaking changes (notably, Swift is no longer wrapped), so it won’t be backported to 25.11.
Yes, Randy is aiming for an inclusion in nixpkgs 26.05 as far as I'm aware, so you might get to try it in unstable next spring.
Hey, this is the first release that includes nixos-rebuild-ng by default, that is the result of my work from the last 2 release cycles.
Not sure if people are interested, but happy to answer any questions.
Thanks for your work on this!
I'm a NixOS user, but I don't follow NixOS development. Could you share some details about what nixos-rebuild-ng is and how it differs from the previous nixos-rebuild?
Sure.
nixos-rebuild was written in Bash and after a more than a decade of work on it the code was a huge mess. There wasn't any code structure and all the features were bolted on each other. Also there was no linters like Shellcheck running on its code base, mostly because the code was messy so every time someone tried to implement a linter it would break something. The fact that also there was no unit tests (there was some integration tests written with the NixOSVMTest framework but they were slow and curbersome to write, so only the absolute critical features had tests) made the code brittle and it was common for new features and fixes to break someone workflow.
nixos-rebuild-ng was born from those frustrations. Now using Python as a base language thanks to its scripting powers, the code was also written with mypy/unit tests from the start to avoid regressions. Lots of bugs in the original implementation were fixed. For the user itself, the major advantage of the new implementation is having more ways to debug, like the new --debug flag that enables the debug log that makes life much easier when things go wrong.
nixos-rebuild was written in Bash... no linters like Shellcheck ... no unit tests
Whoa, terrifying!
Thanks for taming that mess!
Did -ng totally replace the Bash version in 25.11 or are there still places where the Bash version exists? If I run nixos-rebuild, is it now running your code?
From 25.11 release nixos-rebuild should point to nixos-rebuild-ng in a NixOS configuration. If you're referencing the nixos-rebuild derivation directly (e.g., nix-shell -p nixos-rebuild), this will still point to the old version though (in those cases use nix-shell -p nixos-rebuild-ng instead).
There are this PR removing nixos-rebuild for good and making an alias nixos-rebuild = nixos-rebuild-ng, but this will not be backported to 25.11.
I am asking here because I constantly hear I am using Nix but fail to talk a living nixos user.
I"d appreciate if someone can give me a sentence or two so I can explore nixos as alternative
I don't really know what you're asking. I've used NixOS since 2014, and I've used nixpkgs dockerTools images in many production services. The images which I create are smaller than most Alpine based images.
I don't know want to ask because i've never used nixos, I am happy with macos/debian/arch but system reinstallation is pain in the neck, which is why NixOS gets a spotlight
The images which I create are smaller than most Alpine based images.
I guess you have to control packages included manually or there is a list of ready to use images somewhere which I can compare to popular alpine/debian setups
I guess you have to control packages included manually or there is a list of ready to use images somewhere which I can compare to popular alpine/debian setups
It sounds like there's some mixup/confusion happening in this thread. It sounds like you're asking about "(docker) images of NixOS", i.e. images which contain a full Linux operating system. But most of the replies are talking about "(docker) images built using Nix". Those are not the same thing!
"Nix" is a build tool: it essentially just executes commands, with arguments and environment variables which are made immutable by putting hashes in filenames. Nix can be used for many things. It officially supports running on Linux (any distribution) and macOS, though I think there are experimental versions for other OSes too.
One thing that Nix is used for is Nixpkgs, which is a huge collection of Nix build recipes, for all sorts of software. For example, Nixpkgs contains a recipe for the jq program, so we can get jq by giving that recipe to Nix, e.g. like this (on any Linux distro or macOS which has Nix installed):
$ nix-build -E '(import (fetchTarball { url = "https://github.com/NixOS/nixpkgs/archive/871b9fd269ff6246794583ce4ee1031e1da71895.tar.gz"; sha256 = "sha256:1zn1lsafn62sz6azx6j735fh4vwwghj8cc9x91g5sx2nrg23ap9k"; }) {}).jq'
/nix/store/qvbwz06cqra3cmlra40v0adw75j6j7wm-jq-1.8.1-bin
$ /nix/store/qvbwz06cqra3cmlra40v0adw75j6j7wm-jq-1.8.1-bin/bin/jq -n '{"hello":"world"}'
{
"hello": "world"
}
Nixpkgs also contains recipes for creating Docker images; e.g. we can create a Docker image containing jq (and its dependencies):
$ nix-build -E 'with import (fetchTarball { url = "https://github.com/NixOS/nixpkgs/archive/871b9fd269ff6246794583ce4ee1031e1da71895.tar.gz"; sha256 = "sha256:1zn1lsafn62sz6azx6j735fh4vwwghj8cc9x91g5sx2nrg23ap9k"; }) {}; dockerTools.buildLayeredImage { name = "demo"; contents = [ jq ]; config.Cmd = "${jq}/bin/jq"; }'
/nix/store/2n1wg0i2xdfb7kxy85myfil2kjwahiy0-demo.tar.gz
Note that:
buildLayeredImage from Nixpkgs instead.A different thing that Nix is used for is "NixOS", which is a Linux operating system. NixOS provides Nix build recipes which will create all the things required by a Linux system, like /etc, /var, /home, etc. NixOS works by defining the whole system inside a folder, then using symlinks and scripts to make sure everything's pointing at the right place. The applications and services that NixOS uses are taken from Nixpkgs.
It's possible to create a Docker image of NixOS, if you like. However, most people using Nix do not use such NixOS Docker images. Instead:
buildLayeredImage approach, or something like it, to make images which only contain specific programs; without any accompanying OS.thank you for an extensive answer, I was looking for Nixpkgs recipies, that's the keyword. This way I can look up best practices.
By comparing with docker images I wanted to see the difference in packages between let's say golang app running on nix and golang app running in docker. I know how to make the latter in many ways, but have no idea what it looks like with nix package maneger
I've got my answers, don't want to make a non-topic flood
nixpkgs dockerTools is how you can have full control over an image in a Nix environment.
Alternatively, there are some ready-to-use images for you to check out:
docker pull nixery.dev/shell/git/htop.At bevuta every single employee (even non-developers) uses NixOS on their work-issued laptop. We also use it on our servers and for CI. It's great for reproducibility and package pinning in dev environments with direnv. We don't wrap it in Docker mostly because Nix serves most practical needs one would use Docker for. I think we use Nix inside Docker in CI but I'm not exactly sure why.
madness, glad it works out for you guys :)
do you manage non-developers machines manually or you have some kind of a tool to do that remotely/in bulk?
AFAIK we have a Nix module that sets some sane defaults (I'm not using it myself), but other than that it's just manual stuff. The laptops are set up by our ops team before it's sent to a new member. We have a tech support Mattermost channel for people needing help. That doesn't happen that often, AFAICT - Nix is very hands-off and typically "just works". And if you manage to hose your system somehow, you can just boot into a previous full system state.
Hi, I'm glad you asked.
Our average project comes just with a Nix devshell that offers everything for interactive development, and with a bunch of derivations to build the stuff reliably with a single command. We often pair this up with devenv to get semi automatically into the devshell.
A good example: https://github.com/dlr-ft/wasm-interpreter
I constantly hear I am using Nix but fail to talk a living nixos user.
Maybe look up if there's a Nix meetup in your area! I've been to one recently and got to help some people who were just starting out.
Do you use Nix for the main development machine?
Yes, and I try to use Nix shells for every project that I work on. Sometimes I still need to use Docker because getting some things to work in Nix requires a bit more work than I want to put in :P (recently I've had trouble with cross-compilation, though I know it can be done with some effort).
If you want to package software to build and run on NixOS you're gonna need some level of knowledge of Nix (the language) and nixpkgs (the package repository, which also contains tools to build packages). The documentation is a bit sparse so you'll probably need to dig into nixpkgs to see how similar things are packaged.
Do you still wrap nixos in docker? And if yes, what about size, does it bother you comparing to alpine linux
I personally don't but I've spoken with people who build OCI images with Nix and they had good experiences with it. There's some functions in nixpkgs that can build OCI images. I just tried building a simple image that only contains a hello world in C and it turned out to be 32.9MB unpacked. Most of the space is taken up by glibc, but if you want you could build one that uses musl. Generally images built with Nix are quite small because they only contain the binary/program in the entrypoint and its dependencies, in this case you don't even get /bin/sh! This is the script that I used, you can build it with nix-build script.nix:
{ pkgs ? import <nixpkgs> {} }:
pkgs.dockerTools.buildLayeredImage {
name = "hello";
tag = "latest";
contents = [
pkgs.hello
];
config.Cmd = "${pkgs.hello}/bin/hello";
}
thank you for reply and ideas, haven't been to meetups for a long time
I don't know much about nixos, and replies like yours help to wrap my head around it, appreciate it
Yes, I use Nix on my development machine. I originally started Nix as a configuration/deployment manager (basically seeking a better Puppet/Chef/Ansible) (https://kevincox.ca/2015/12/13/nixos-managed-system/). Then after a handful of years loving it on the server I started using it on my desktops as well (https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/).
The tradeoffs are much more apparent in desktop usage IMHO. It can be difficult to "just do something" as many parts of the system are immutable (and even when there are easy workarounds many users are inclined to waste more time doing it "properly" than it is always worth, myself included) and more software will be confused by the differences. But I'm still very happy about it. For example having different dependency sets for each project rather than installing globally is very nice, especially if you need different versions of the same tool in different projects. Additionally as I have a desktop, laptop and now my wife's desktop to manage it is nice that they all have the same settings and software (unless I explicitly customize them differently of course). It also makes installing a new machine a wonderful process as the vast majority of my software and settings is just ready to go after installation. (Although admittedly this is something that happens every few years at most so is minor in the grand scheme of things.)
I am using NixOS on my home/personal Linux laptop, and at work I have a company-issued Macbook and a company-issued Dell running Ubuntu. On the company devices, I use Nix with home-manager to get a reproducible setup of my core configuration and essential tools. I have been introducing Nix flakes into the repositories I work with at work, so most of the development tooling I need per project is defined in this manner, so I get a somewhat reproducible setup. The rest of the developers are not all-in on Nix yet, so most of the software packaging is still in per-language package definitions (poetry, uv, Maven) rather than having everything defined in the flake, as I would prefer it.
Our main deployment target is Docker images; at the moment, none of them are produced using Nix, they're all traditional Dockerfile setups that do not reference Nix. I have done some exploratory work here and found that Nix-generated images are produced much faster and much smaller (half the size, in my test case). But to really make this work, the entire package needs to be defined by Nix rather than a mixture of Nix and per-language packaging, and we're not quite ready for that.
In my experience, the Alpine base image is very tiny, which is great, but if I'm doing a Python-based application that has any dependencies on an extension written in C or Rust, the development infrastructure needed to get the dependencies installed will bloat the image to where it's about the same size as starting from an Ubuntu image or whatever. With a Nix-created image (not NixOS-based image), the development tools don't wind up in the image unless they are actually needed at runtime, so the resulting images are smaller. You can get the same benefit with vanilla Docker by using build stages, but it's manual labor, you better know which things you actually need since the system doesn't suss it out for you as Nix does, and of course it makes the build take even longer.
I use NixOS on my router and my NAS. I have tried other Linux distros and FreeBSD, but I prefer NixOS on the router because of being able to manage my config declaratively and because systemd-networkd is very nice.
I use it on my Mac to manage my configs. I have a FFXIV derivation I maintain that I use to play, which is what motivates a lot of my contributions to nixpkgs. I also use it for dev shells. I don’t use the Homebrew integration.
router, lol, which router and system do you use?
I’m using a 2-port Protectli Vault firewall appliance. NixOS is running bare metal.
I originally switched because my previous router could not reliably support IPv6. systemd-networkd makes setting that up pretty easy. Now I prefer it for the control it gives me over my network.
Router config is here.
I'm using a raspberry 4 compute module with a network hat. I have dhcpcd, dnsmasq, unbound all configured and enriched via nix. Also got tinc, authelia, nginx and some of my internal websites running on that thing. I am quite happy with this setup.
Outside of Proxmox, iOS, and android all family laptops, desktops, and a tablet run NixOS. Add to that a handful of VMs for home - like media, game streaming, etc. - and another handful for work.
In my startup we use nix for all projects, making cross-platform work on the same projects a breeze.
I avoid OCI images like the plague, so that I can keep a safe distance to the madness that is docker/podman networking. Greatly puzzled why I'd want to opt into their bloat amyway. Where I use containers I in stead reach for systemd ones - passing network interfaces straight to them and relying on regular sane network conf to dictate connectivity.