NixOS 26.05
nixos.org
nixos.org
One unexpected benefit is that both my workstation and my backup laptop have the same setup, so I can run updates on the scratch box before doing my workstation. I decided to run the "latest" rather than 25.11 release, so it's nice to test before I apply (I hit a GDM issue a few weeks ago that left me at a black screen; but not a huge deal, just select the "previous" option in the grub screen).
I've got everything to parity with what I had on my previous Ubuntu workstation. I had anticipated issues with some software that isn't packaged (but NixOS packages a LOT), but that wasn't an issue. Claude was able to do all those things no problem.
The biggest tricky bit was with my vim setup; I've been using AstroVIM and trying to get away from managing my own vim setup. You can't, AFAICT, just apply astrovim in NixOS. So I described the vim setup I wanted to Claude Code, and I now have a ~700 line config that implements everything I wanted: LSP, TreeSitter, a small variety of other things. Unlike Astro/Lunar, where tweaks you want to make are buried in some set of files in this whole giant distro, it is all encoded in this one "neovim.nix" file.
I also set up home-manager and SOPS and so far that has been working just great! I now have home directory settings that are replicated across 2 machines.
I'm still really only using it on one machine, so we'll see how it gets more complicated if I start running it on some servers.
This scares me. I would not want AI to run my computer systems.
Just waiting for the dgx spark style system with proper bandwidth as nd a price point of max 1500 or winning the lottery.
But in 3 years I bet I will have Jarvis.
Told my wife already thatwe need a lab room
I mostly just check the diff, and if nothing looks particularly wrong, I commit it. I mostly care about the final result. Commits are there for eventual auditing, but they're not that important to me.
I (or an LLM) can always clean things up later, and there's plenty of time considering this is the configuration for however many machines I'll be using for the foreseeable future. I used to spend a lot more time tinkering with configs that could be wiped out by a failed Windows Update.
Kind of reminds me of the movie Ronin where the young guy is asking the seasoned CIA guy what gun he likes. "It doesn't matter, it's just a tool, I put it in my toolbox."
I have one github repo with a top-level flake containing system definitions for all of my machines. Much of my config is modularized, so it's easy to take custom stuff from one machine and use it on another.
It's nice to hear that AI tooling is making it more accessible for people.
https://github.com/will-x86/nixos-dotfiles
( ./home/base/nixvim)
My setup right now is a fairly straightforward nix file listing the plugins and associated packages I want, and then an embedded long-ass lua config file, and I think the nixvim would just make that part of it declarative. I think I'll make a branch on my nixos repo and just have Claude try it. No reason not to.
I MOSTLY understood it before Claude Code, but WITH Claude Code it's almost a no-brainer for most people. All the upside with none of the downside.
That's how my devices are configured, and it's amazing - if I need to travel for work, I just pick up my laptop and go. NixOS makes sure the system itself is identical (apps, most of the code configs, etc), then any app-spcific config is handled by Syncthing. It was really magical the first few times I used my laptop on the road!
Also, if you aren't already across it, you should look into remote builds/deployments. Basically, the regular nixos-rebuild command supports deploying over SSH. It's nice because you can do the heavy work (nix evaluation, building non-cached packages, etc) on your grunty workstation, then have them pushed across to the laptop via SSH. Then, when you want to apply that build to your PC, it'll be super fast (since everything is already evaluated & built!).
Going to have to try that remote rebuild, because right now my 10yo T420 takes around an hour to rebuild gitbutler-cli (not yet packaged in NixOS), so that'd be real nice.
I know syncthing has a solid reputation, but I'm a bit reluctant to try it on my home directory (it's super mission critical). Does that interact well with home-manager+SOPS?
Mostly, when I'm away from my workstation, I just connect in from my personal macbook via the "wezterm tmux" feature, since most of what I do is either web or terminal. The need for a "pick up and go" copy is nice but not really necessary. Though in the event my main workstation fails, I should check to see how long an rsync from the restic backup would take. If it takes the better part of a day, that might be compelling to use syncthing, especially as my workstation is a 6+yo laptop.
My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal. This might be because I had some things built and installed through AUR (e.g. latest mpv releases that sometimes broke). Eventually I went back to latest Windows 11 build wanting easy no-bs setup.
Of course, then MS decides to shove down half baked AI integration that somehow used half my RAM and randomly slowed my CPU. I am guessing it was busy indexing, searching or security-scanning something.
Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
Aconfmgr is a good solution (practical trade-off for me). When it feel like "my OS must be dirty at this point", then I spend a couple minutes with this and I'm back to the clean state.
I don't do this more then twice a year, so if you insist on an always clean system, YMMV
Similarly the integration of flakes/devshells and direnv is great to create reproducible development environments. Everything I need and at the correct versions are automatically setup as soon as I `cd` into a project directory.
On my home system I'd do this to switch to a new mpv release:
"gitty mpv"
(This is my alias to check out the latest mpv sources, from github, via git clone URL_HERE.)
Scripts repackage mpv into .tar.xz after this git clone step.
Then I do:
"clangy mpv"
clangy is my alias to compile via clang from llvm; and the specific instructions would be found in my COOKBOOKS_DIRECTORY aka recipes (similar to homebrew, but in .yml files), where all information is gathered from mpv.yml then.
One setting there is:
prefix: f
So the above would, via clang, compile mpv from source (if the git clone worked), into the AppDir prefix. Then it would simply create symlinks and so some more processing, so /usr/bin/mpv would point at /home/Programs/Mpv/Current/bin/mpv, and Current is a Symlink to the current version in use. I can keep old entries of mpv under /home/Programs/Mpv/ so switching is trivial. And cleaning up is also trivial, I remove e. g. an old mpv version there, then call one post-removal script (or I simply pass the name of it, but I find it easier to work via the commandline in two steps here). The benefit of the above is that, for instance compared to your "latest mpv release sometimes broke", this would not affect me, the old mpv versions would work still, and there can not be any outside installation other than the versioned AppDir.
Right now my /home/Programs/ has 499 entries. I'll eventually have all programs there, and work, then I'll switch to a completely custom LFS/BLFS. Right now my base system is manjaro, which works very well as a base system, even though it uses systemd. /lib/ is a symlink on manjaro by default towards /usr/lib/ and so forth. I find this works so much better than e. g. debian.
> Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
Not disagreeing at all, but imo the issue you had with AUR is one that by design could be completely avoided. I am not saying this is your fault, mind you; just pointing out that this may be an assumption by both AUR as well as you, since your expectation is to trust the package manager. Here, my input would be the question whether a package manager would be necessary in the first place or not (I still have scripts to handle that, mind you, but the assumptions made via AUR may be wrong in many areas, including not offering versioned AppDirs by default. I don't understand why all package managers do not offer versioned AppDirs; it would solve so many issues).
I should add that some programs are harder to install from source, but mpv works very well; ffmpeg too, surprisingly enough. LLVM/clang is a bit harder to setup, and by far the worst offender is firefox. Mozilla should be ashamed of mozconfig for life.
(I'm admiring this, not mocking it)
Win11 was frustrating ...
Yeah, that's literally a problem with every single OS that is not NixOS (or, shoutout, Guix, or the other Nix-based variants).
That's also why I am sticking with NixOS. Been at least 5 years now- it's wonderful having a reliable LINUX system as my daily driver (or one of them).
And you can reboot into any old configuration! Even more insurance against fuckups!
> I am finally settling on it be the last OS I need
Same here. As soon as I got everything set up just how I like it in a declarative, reproducible fashion, I had this feeling of... "OK, this is great. I can't see a reason to ever leave this."
The builds are deterministic, unlike on any other linux or other OS, because Nix basically captures a closure of all the possible inputs to a build, which means that the build always "sees" the same things, which means it always builds the same way. Once you grok this, doing it any other way will seem insane.
Truth be told I think I only appreciated it more after having used (and bricked) other Linux distros simply by "installing the wrong thing". This is what i mean by "daily driver". You need something reliable AND reconfigurable for that; NixOS (or nix-darwin on Mac) offers both.
The language is just nothing for a casual Linux user.
Arch? Easy. Gentoo love it. Ubuntu for all my servers.
But nix and nix os, nah.
I have been using Nixos for the past 5 years. And I really use the power of nix/nixos since Codex is doing good code with it.
Setup easily systemd-user unit with podman rootless, backup, writing script during build...
Nix excels at solving real world problems for developers. No more "Well, it worked on my machine". You setup a flake.nix in your code repo along with direnv and even that new junior dev can merely clone the repo and all the dependencies are installed by the flake.nix configuration file. Including the language and IDE configuration for the team. i.e. tabs vs spaces and whatnot. The same flake.nix can be applied to your CI / CD to help with reliable builds. You can also use it to create Kubernetes and other containers or a bare metal NixOS server. Keep all the configs in git and run them straight from the repo.
It's great for ensuring your devs don't break the freaking build by updating something with npm, etc. You should audit anything you install due to the severe threat of supply chain attacks. Recently impacting Node.js and Arch Linux AUR, etc.
Yes, LLMs can write quite a lot of Nix but they don't necessarily get down to the nitty gritty best practices. So you need to be careful with it. You should also audit your configuration for security issues.
Before updating my nvidia driver or something related to my surface I was scared to break something. With NixOS I can just go back to the old working config.
Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
An example I have given before, but there was a weird quirk with my ThinkPad with Linux, where with USB keyboards, if I hadn't been typing for more than a minute, it would have to "wake up" for about four seconds, so I'd lose the first couple words that I was typing.
Fixing this involved playing with a few boot parameters, which can be scary to play with on something like Ubuntu. The issue is annoying, but nothing I can't live with, so if I were on Ubuntu or something I probably would have just tried to live with it, but because it's NixOS, I realized that the worst case scenario is that I reboot and choose an older generation, so I did a few experiments with boot parameters and fixed it.
And similarly, you can generate a bootable ISO of your NixOS config. It's really nice for both testing things out and also as a recovery mechanism. Rather than booting some generic ISO, connecting to the internet, installing whatever recovery tools and filesystem drivers I need, and then doing the recovery, I can boot an ISO that is identical to my main system, with all my favorite recovery tools pre-installed.
Before I deploy I know that all hosts will be able to boot properly from tftp and then communicate and launch kubernetes.
I never ssh into any of my nodes at this point. Amazing. It just works. Once in a while I'll restart them just for funsies.
The two main sticking points IMO are still:
- Development environments are still a pain. devenv.sh is great for web and backend, but not perfect for dependency (package) management and more complicated environments like mobile or embedded
- nixpkgs monorepo doesn't update fast enough IMO. As a consequence, I see a number of flake repositories popping up to more easily package and distribute software not yet on nixpkgs or that don't update often enough (https://github.com/numtide/llm-agents.nix is a good example). This is perhaps by design, but it takes some digging to find the reliable and trustworthy flake repos. I'm increasingly concerned with AUR-like trust issues
Weird, development environments are one of my favorite things about nix. I don't use anything like devenv.sh, just add a `flake.nix` to the repo defining a devShell, and then add `use flake` to `.envrc` and let direnv activate it. Every major and most minor editors have support for direnv, and if they don't, you can just launch them from a shell in that directory. This makes the only system dependencies for a great dev environment nix and direnv.
> I'm increasingly concerned with AUR-like trust issues
Once you've done it a few times, most things are pretty easy to package yourself, and you can just check those derivations into your git repo for your machines and use them. Especially if you're using LLMs, it shouldn't be all that hard to package what you need in most cases. For stuff that's more complicated or difficult, it's more likely there will be some kind of de facto standard flake for it.
devenv brings modularity to development shells.
For example, you could configure your devenv module for the shell you want (which env vars you want set, which packages you want available, etc.), and then re-use this module in other shells.
As such, one of the nice things devenv provides is modules with the compilers/lsp/etc. for different languages, so getting a rust environment is about as simple as `languages.rust.enable = true;`.
I haven't explored using the services/processes aspect of it, but it's got support for things like that to. -- I saw it put somewhere: "oh, like docker-compose, but you can compose the configuration".
Nixos is nice because it just works. When I do a rebuild switch it will take down my affected services gracefully, apply the updates, update my firewall, and start the container all automatically and declaratively.
Plus the owning account and file permissions are explicit so it’s impossible to forget you ran chmod/crown on some script and now your service is over-permissioned.
It’s not magic but it feels like magic because it works so easily and reliably.
Now I have the same setup across my macbook, desktop, and NixOS servers.
I assume that was an autocomplete typo?
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
Another great benefit, is that AI can read my whole OS (good and bad at the same time, I know). This makes the AI way more accurate on giving you a good solution instead of having to scan all of your OS and dig into /etc.
Personally, I really like NixOS. It's hard but definetely worth the try. Probably not for everyone, but worth it if you're a computer scientist or need to maintain hundreds of computers.
Thanks for this! I appreciate the acknowledgement that more software in nixpkgs is not necessarily better.
If you're working on cloud systems it's easy enough to just throw away VMs all the time but you can't really do that with physical hardware that's on a construction site for months on end, where you only have a shared 5G connection. NixOS makes this all manageable!
Understandable with Apple dropping official support but kind of sad as they were selling Intel powered Macs until as recently as 2023 and with Tahoe still continuing to receive security updates until 2028.
How is NixOS on Intel Macs currently? Hopefully Linux can still breathe life into these computers in 10 years time.
I'm probably also going to install it on a 2019 iMac once macOS stops getting security updates but I haven't tried it yet.
There is a snag however: Drivers for the built-in Broadcom Wi-Fi card are unmaintained and bug-ridden. Replacements do not exist either. The driver doesn't work most of the time nowadays and I have to rely on a USB Wi-Fi adapter that is sooo slow.
Maybe more recent Wi-Fi chipsets in Intel Macs are better off. Or maybe you don't need Wi-Fi!
Maybe they should think about increasing their release cycle, that sounds completely unmanageable.
After 10 years in my company I have around 1,500 commits in total, it would take me 390 years to author 60K.
And I was someone who hadn’t been active in NixPkgs at all. The community reviewing these small package updates are active and really care which is how the number of commits can explode
Is this kind of thing common in the NixOS space ? Like configs you can import that manage 99% of the os for you ?
Adding a new domain to my NixOS webserver is a single line of code.
Jovian exists for the Steam Deck and is probably the closest thing right now: https://jovian-experiments.github.io/Jovian-NixOS/
I am tempted to try making a "Nixzite" flake just to see how far it can get to feature parity with Bazzite, but again most of the story with Bazzite is the sizable community working on hardware tuning and kernel modifications. The catch with that flake would be a lot of waiting for the kernel to rebuild if I bring in the Bazzite patches, and that's just not a fun UX...
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
Nirvana
https://wiki.debian.org/ReproducibleBuilds
We could make such a guarantee if we extend NixOS. But until all of that happens, I stick with simplicity and flexibility. It just kind of works better, even if it is nowhere near as sophisticated as NixOS.
I'd characterise it as the opposite:
A unique aspect of NixOS is that it avoids global state as much as possible (& prefers to symlink things). -- By conspicuously avoiding / preventing this global state, everything has to be declared as an input for the 'package'.
For example: the Nix package for "ruby 4.0.5 built with gcc 16.1" would be a different package than "ruby 4.0.5 built with gcc 16.0". -- That afforts a greater level of flexbility. e.g. allows easily having multiple concurrent shells which run different versions of the same program.
Is it because of no LTS?
And is having a LTS somewhat the antithesis of what NixOS represents?
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
Basically, yeah.
A new release every 6 months, and the old release almost immediately stops getting any more updates.
Also, from a vulnerability management perspective, NixOS is terrible. If you have some compliance monkey at your company that demands CVEs get resolved regardless of impact, NixOS is the wrong choice. Yeah, they'll patch CVEs that are truly impacting, but for non-impacting CVEs, they're not nearly as interested at backporting fixes as Debian or Ubuntu. From an actual security standpoint, it's fine, but if compliance requires you to resolve CVEs within a certain period of time, NixOS will fail for you.
Last time I read about Nix there was a BDFL "assassination" and some people mad about Anduril.
Drama is the salt of opensource, a little bit is always fun.