I switched my workstation over to NixOS ~6 weeks ago and it's been really good, I'm a total convert. The thing that really got me over the hump was entirely configuring it using Claude Code.
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.
I'm on year 6 and still feel the same way, using NixOS for all my machines, and also for my homelab servers (building on the main machine and then deploying over SSH). Everything else feels primitive by comparison. Rolling back is incredible.
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.
That is really interesting, thanks for the pointer. I came across it a while ago when I was researching how to manually set up AstroVIM on NixOS and doing manually was a bit of a stretch for me at the time.
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 converted with claude
Use my repo for lsp.nix as neovims new v10 has a new way of configuring lsp's as lspconfig is depreciated, so I used the new lsp configuration method but went doc hunting to find out I need lspconfig for proper completions! ( I'll give it a push now to ensure it's my latest version)
You could take this one step further using Syncthing to sync important data between the workstation and laptop.
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.
Answer about syncthing: I probably would set it up on only a portion of my home directory, not the whole thing, so it wouldn't impact home-manager/SOPS. However, Claude pointed out this potential issue: the bulk of my "projects" directory (my most active directory) is git repos, and (a) those are likely to conflict on both ends (a git pull on both ends), and (b) much of that syncing git can handle (except, of course, uncommitted changes).
As a small note against Syncthing, despite how much praise it gets, it's conflict resolution sucks. Enough so that it is easier to nuke it and set it up again instead. If you never have conflicts, it works fine though, but I find that rather unrealistic.
Agreed, that's where I was as well. I had been dabbling in manual NixOS configs for ~2 years. I mostly felt like I understood it. But as you say, all upside.
I'm no AI booster by any stretch of the imagination, but it's not "run[ning] ... computer systems" in this case. Your NixOS setup is defined by declarative config files, and nix builds or updates a working system from them. AI in this case is just writing the config files, which you'd then (hopefully) read and at least vaguely understand before applying them.
It generates a config file. You can read it before applying it. While Nix may be nigh intractable to write for some people, it is quite a bit easier to read, and any shenanigans would immediately be noticed.
On NixOS in particular, unless it's something so esoteric that I know it's worth documenting (or so obscure that it's pointless to remember), things tend to be pretty self-descriptive and most changes are relatively small.
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.
I'm a 35-year professional sys admin, so you'd think I'd have really strong opinions about how exactly it sets the system up. Or maybe I have enough experience that I can just eyeball what it's doing and feel comfortable? I'm not sure.
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 had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.
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.
I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.
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.
Project README.md Install instructions: List of software to install and what those packages are called on different distributions: Just kidding, it just works.
> My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal
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."
Not a Nix user yet, so i'm wondering if you can describe a little more about the "reproducibility" aspect which implies that you are often "reproducing" stuff. What needs reproducing? What is a basic daily-driver use case for whatever we are "reproducing"?
The entire system configuration is one file or a small set of files. If you copy it to a different machine, you can "run" it and get pretty much the same machine. If you screw up the config, the system tells you before it even tries to apply it. If something breaks while applying it (which is rare), NOTHING is broken because the entire system still points at the old instance, since cutover is atomic. This is already different from pretty much every other system out there. And if you reboot and things are STILL messed up, you can boot into a previously-known-good instance and repair things from there, without using a bootable USB key.
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.
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
> installed through AUR (e.g. latest mpv releases that sometimes broke)
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
This means "non-traditional prefix", aka "AppDir" prefix. AppDir
prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/
(I keep the dd.mm.yyyy notation, but this can be toggled; on my home
system I use /home/Programs/ though rather than /Programs/ for historic
reasons, and also as I want to backup my /home/ directory, including
all programs).
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.
You might be interested to note that what you have written is basically the same paradigm that Nix uses, except with a content addressable store in /nix that the binaries are compiled from source to. All packages (read: binaries, libraries, configuration files) are symlinked from the store to wherever they are needed e.g. PATH, another package's environment, etc.
God bless Hacker News, where "just start building your own package management system, like I did" is an earnest comment, including a sketched out implementation.
I love seeing all these posts from NixOS newcomers! It seems anecdotally like LLMs have really given it a boost recently, I guess by reducing the intimidation factor of the language and the unfamiliarity? Of all the positive and negative outcomes I have imagined from LLMs, NixOS becoming popular was not one of them, but I'll take it.
BTW, there is a NixOS.wsl for Win11 and Nix-Darwin for macOS and the Nix package manager runs on any Linux. You could run Fedora and configure somethings with Nix.
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.
I really love NixOS for my two devices, one surface laptop (lol), and my nvidia pc. It reduced my headaches with drivers so much.
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.
Yep, exactly the same experience as me. The fact that everything is declarative and revertible means that I'm much "braver" than I would be with virtually any other Linux.
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.
I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
I self host my own stuff in a data center with a bunch of computers. I have a virtualized setup all in nix defining nixos setups for all hosts. Switches are virtualized using open v switch and everything is made so that the nix expression generates a launch script to test the whole set up.
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.
It's a bit messy and gives away too many details of my setup (including IP addresses and such). I'll see if I can eventually release something like it. I've thought of developing a tool that lets you auto-generate network topologies and such. My main use case is testing failovers with switches.
> Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
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.
NixOS has been my daily driver since 2022/2023 and I have greatly improved the management of my 2 computers and few VMs since. Because of LLMs, I now understand the language much better, but even if I didn't want to write Nix directly, describing the config to AI usually produces good results.
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
> Development environments are still a pain. devenv.sh is great for web and backend
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.
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".
I love the slightly weird learning curve on NixOS where initially it seems incredibly complex writing this weird functional programming language for every change you want to apply to your system, then over time it clicks and you end up in a place where any operating system that doesn't define everything in a weird functional programming language seems incredibly complex. I read blog posts about doing things on other distros now and I'm left thinking that an 800 word set of instructions would be 25 lines of Nix expressions.
When I started self hosting last year it seemed insane that hosting a service required separately managing the imperative firewall state, vpn, container runner, systemd, and reverse proxy.
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.
I've find my email on simple-nixos-mailserver for almost a half decade... So easy, less than 25 lines of code and a command line to update every few months.
it's like reading instructions for using a GUI program (open this dialog, click this checkbox, fill in this value) vs copying and pasting a complex FFMpeg command
One of the best things about Nix, aside from LLMs being able to manage your config, is having a monorepo that contains the config across all machines (shared and machine-unique), like hosts/{nas,macbook}/{configuration.nix,home.nix,modules/}.
Now I have the same setup across my macbook, desktop, and NixOS servers.
I post this on every post about Nix I encounter, but I sincerely hope that it gets static electricity typing one day. I have yet to try typenix (a fork of the typescript compiler applying the typescript type system to nix)
Adding TS types to Nix would make it so much easier to write Nix code. Which string do I need here? Oh the type system knows, the language server shows it inline - I don't have to look at the source. I've used NixOS since 2018 and written nixpkgs derivations and it would've saved me so much time.
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
I'm fairly close to releasing something called nix-compile, which is a type inferring Hindley-Milner compiler that unifies across nixlang and bash. It finds a lot of bugs. Because it has a very complete view of your project, it can do cute stuff like precise go to definition across modules, annotate code with types in the comments, it's cool.
I decided to move to NixOS a few months ago. In terms of OS, it was one of the best decisions I've made so far. It's awesome to have the rollback experience, upgrade whenever you want and also being able to experiment without being afraid of breaking already working stuff.
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.
We use NixOS for all of our robots and servers at https://www.monumental.co, hard to imagine how we would do constant updates of our robot fleet without it.
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!
Cool company! Do you guys hire only local to the Netherlands? I see some roles I might be a good fit for (experience w/ Rust, cpp, nix), but dont wanna waste your time
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've been using t2linux[0] patched distros on an Intel MBP for a while now. While I applaud the efforts, it is not without sharp edges, and I do occasionally have to boot into macOS to do some things. I gave up on trying to use the onboard or bluetooth audio (onboard can cause it to crash in weird ways, and bluetooth can break depending on if wifi is in 2.4 pr 5ghz mode? I don't know, I use a USB DAC now and it's fantastic). Trying to use the webcam causes a hard crash. Sleep is weird (but that's a given for most linux things I think). The maintainers do a good job of getting all their little hacks included...but I'd probably be frustrated with it all if I didn't have 25+ years of experience with linux and be able to fix things myself. The MBP was a gift and my only machine at the moment so I won't complain much personally :).
It's great. It's complicated. I have a MacBook Pro Late 2013 – very old. NixOS runs totally great! Even the proprietary hardware just works, with the nixos-hardware channel. Battery life is awesome, 4 hours of office work.
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!
The majority of these commits are to keep packages up to date. Easy to get an incredibly high number of commits when nixpkgs is a monorepo containing the definition of 140000 packages
Anecdote: I was trying out a new editor at some point that had just had a huge update. I installed it on NixOS and noticed the new update had not been pushed onto NixPkgs. I went through their contribution guide and found how to update the package. I opened a PR and immediately a couple previous contributors & a specific maintainer were on the PR and left me some helpful comments and questions and I got it merged a few days later.
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
What makes Bazzite-like uncommon is the degree of hardware testing and kernel tuning required to get some of the more exotic hardware fully working and stable.
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...
Not the same thing but you can go in the other direction using https://blue-build.org/reference/recipe/. You can have a nixos-style bazzite distribution where you import the bazzite base image and layer your custom config on top of it.
There are templates for deploying NixOS but almost all that I've encountered are heavily opinionated and thus only kinda work for specific people (usually the ones that designed them). Then when you want to customize them it's almost always easier to start from scratch.
NixOS is very much a toolkit for building operating systems. You in modules that set up parts of the system with overridable defaults, and you focus on the parts that matter. Sometimes that is the disk layout, other times it is the dot files, yet other times it is the services.
Adding a new domain to my NixOS webserver is a single line of code.
I tried nix-darwin (with plenty of LLM assistance) but struggled to get it to work in the way I wanted. I couldn’t get it to manage my dock, and it was fiddly bootstrapping my two main users from an admin user.
I've used this set up for 3 or 4 years now and love it. I used to hit bottlenecks having to edit some nix files once or twice a month and forgetting the language but LLMs dramatically reduce that barrier.
I've run nixos for ten years now without ever having to reinstall... Just continuous updates and my dev environments are nice and segregated and one command line away from being identical on all my computers.
NixOS is a pretty cool idea in theory. In actual practice
I found it too complicated to manage. Immutability is kind
of cool too, but it creates an obstacle to solving even
trivial task in my daily life using Linux. And I don't want
to really use such a domain specific language like Nix, for
things that really should not need a programming language
per se. For instance, I like ruby, but I don't want configuration
stuff to be kept in .rb files; that's also one gripe I have
with homebrew, even if the idea to HAVE a recipe in a .rb
file, is not bad per se. I am just too used to e. g. yaml
files or any other simple format for literally everything.
All my RC files and ENV data and aliases for shells is kept
in .yml files; ruby then just autogenerates any target
format I need for different shells/terminals, and so on and
so forth. Also, NixOS is not very flexible. I prefer e. g.
/Programs/Ruby/4.0.5/ rather than a hashed directory name.
It's not a bad idea here either, and there would be many
workarounds for that (see GoboHide on GoboLinux, for instance),
but at the end of the day it felt as if I was fighting NixOS
too much than getting real work done. There is something to
be said about simplicity at all times, even if the ideas in
NixOS are still great. For instance, we could guarantee that
every snapshot would work, so people having the same hardware
could just re-use configuration and have things work, without
needing to know how to change the system precisely. That would
not be needed because NixOS could make a guarantee about ALL
possible stable snapshots in time. I don't think NixOS goes
that far, so far, but it would be a very logical extension.
Same with immutable packages / reproducible packages:
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.
> Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/
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.
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.
The same reason you don't use arch linux on servers. Some distros are simply better suited for servers. We do have talosos for k8s and we (used) to have clearlinux.
rather than being theoretically better, it's simply the standard way of running servers. Nobody stops you from using nix or even arch on servers, but nearly all of installations, enterprise packaging and "officially" supported distros are debian/ubuntu/centos and has been like that for a really long time.
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
I switched my workstation over to NixOS ~6 weeks ago and it's been really good, I'm a total convert. The thing that really got me over the hump was entirely configuring it using Claude Code.
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.
I'm on year 6 and still feel the same way, using NixOS for all my machines, and also for my homelab servers (building on the main machine and then deploying over SSH). Everything else feels primitive by comparison. Rolling back is incredible.
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.
I'm building a homelab as well and fully second the ode. It feels incredible to do the setup via llm, like they are the perfect fit.
I eventually gave up using mason and lsp servers and used nixvim
https://github.com/will-x86/nixos-dotfiles
( ./home/base/nixvim)
That is really interesting, thanks for the pointer. I came across it a while ago when I was researching how to manually set up AstroVIM on NixOS and doing manually was a bit of a stretch for me at the time.
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 converted with claude Use my repo for lsp.nix as neovims new v10 has a new way of configuring lsp's as lspconfig is depreciated, so I used the new lsp configuration method but went doc hunting to find out I need lspconfig for proper completions! ( I'll give it a push now to ensure it's my latest version)
You could take this one step further using Syncthing to sync important data between the workstation and laptop.
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!).
Really solid advice.
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.
Answer about syncthing: I probably would set it up on only a portion of my home directory, not the whole thing, so it wouldn't impact home-manager/SOPS. However, Claude pointed out this potential issue: the bulk of my "projects" directory (my most active directory) is git repos, and (a) those are likely to conflict on both ends (a git pull on both ends), and (b) much of that syncing git can handle (except, of course, uncommitted changes).
As a small note against Syncthing, despite how much praise it gets, it's conflict resolution sucks. Enough so that it is easier to nuke it and set it up again instead. If you never have conflicts, it works fine though, but I find that rather unrealistic.
> The thing that really got me over the hump was entirely configuring it using Claude Code.
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.
Agreed, that's where I was as well. I had been dabbling in manual NixOS configs for ~2 years. I mostly felt like I understood it. But as you say, all upside.
> entirely configuring it using Claude Code
This scares me. I would not want AI to run my computer systems.
I'm no AI booster by any stretch of the imagination, but it's not "run[ning] ... computer systems" in this case. Your NixOS setup is defined by declarative config files, and nix builds or updates a working system from them. AI in this case is just writing the config files, which you'd then (hopefully) read and at least vaguely understand before applying them.
It generates a config file. You can read it before applying it. While Nix may be nigh intractable to write for some people, it is quite a bit easier to read, and any shenanigans would immediately be noticed.
Let’s be honest, most people do not review the full output of Claude Code because of slop fatigue.
On NixOS in particular, unless it's something so esoteric that I know it's worth documenting (or so obscure that it's pointless to remember), things tend to be pretty self-descriptive and most changes are relatively small.
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.
I'm a 35-year professional sys admin, so you'd think I'd have really strong opinions about how exactly it sets the system up. Or maybe I have enough experience that I can just eyeball what it's doing and feel comfortable? I'm not sure.
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."
It writes into a configuration file that I git diff before applying.
that's quite interesting because I would love for AI to run my systems, given it is capable enough (and it is given right tools). Jarvis anyone?
Yep!
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 had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.
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.
I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.
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.
https://github.com/nix-community/comma
Project README.md Install instructions: List of software to install and what those packages are called on different distributions: Just kidding, it just works.
> My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal
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."
Not a Nix user yet, so i'm wondering if you can describe a little more about the "reproducibility" aspect which implies that you are often "reproducing" stuff. What needs reproducing? What is a basic daily-driver use case for whatever we are "reproducing"?
The entire system configuration is one file or a small set of files. If you copy it to a different machine, you can "run" it and get pretty much the same machine. If you screw up the config, the system tells you before it even tries to apply it. If something breaks while applying it (which is rare), NOTHING is broken because the entire system still points at the old instance, since cutover is atomic. This is already different from pretty much every other system out there. And if you reboot and things are STILL messed up, you can boot into a previously-known-good instance and repair things from there, without using a bootable USB key.
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.
https://github.com/CyberShadow/aconfmgr
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
I'm borderline motivated putting Ubuntu onto my parents computers.
Win11 was frustrating ...
Chrome OS Flex has worked out nicely for my mother-in-law's potato
> installed through AUR (e.g. latest mpv releases that sometimes broke)
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:
This means "non-traditional prefix", aka "AppDir" prefix. AppDir prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/ (I keep the dd.mm.yyyy notation, but this can be toggled; on my home system I use /home/Programs/ though rather than /Programs/ for historic reasons, and also as I want to backup my /home/ directory, including all programs).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.
You might be interested to note that what you have written is basically the same paradigm that Nix uses, except with a content addressable store in /nix that the binaries are compiled from source to. All packages (read: binaries, libraries, configuration files) are symlinked from the store to wherever they are needed e.g. PATH, another package's environment, etc.
God bless Hacker News, where "just start building your own package management system, like I did" is an earnest comment, including a sketched out implementation.
(I'm admiring this, not mocking it)
I love seeing all these posts from NixOS newcomers! It seems anecdotally like LLMs have really given it a boost recently, I guess by reducing the intimidation factor of the language and the unfamiliarity? Of all the positive and negative outcomes I have imagined from LLMs, NixOS becoming popular was not one of them, but I'll take it.
> It seems anecdotally like LLMs have really given it a boost recently
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...
Absolutely.
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.
BTW, there is a NixOS.wsl for Win11 and Nix-Darwin for macOS and the Nix package manager runs on any Linux. You could run Fedora and configure somethings with Nix.
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.
I really love NixOS for my two devices, one surface laptop (lol), and my nvidia pc. It reduced my headaches with drivers so much.
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.
Yep, exactly the same experience as me. The fact that everything is declarative and revertible means that I'm much "braver" than I would be with virtually any other Linux.
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.
I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
I self host my own stuff in a data center with a bunch of computers. I have a virtualized setup all in nix defining nixos setups for all hosts. Switches are virtualized using open v switch and everything is made so that the nix expression generates a launch script to test the whole set up.
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.
That sounds fascinating. Do you have public facing configuration you would be willing to share? :)
It's a bit messy and gives away too many details of my setup (including IP addresses and such). I'll see if I can eventually release something like it. I've thought of developing a tool that lets you auto-generate network topologies and such. My main use case is testing failovers with switches.
> Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
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.
Ohh I didnt know that, but it makes sense that you would be able to create an ISO, good tip!
You can similarly create a docker image from a nix config. It's quite beautiful, nix is impressive.
NixOS has been my daily driver since 2022/2023 and I have greatly improved the management of my 2 computers and few VMs since. Because of LLMs, I now understand the language much better, but even if I didn't want to write Nix directly, describing the config to AI usually produces good results.
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
> Development environments are still a pain. devenv.sh is great for web and backend
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.
Is devens something else than nix shell?
devenv is really nice.
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".
devenv is essentially a convenience wrapper around nix shell with some nice tooling
After using NixOS for a bit and eventually learning to rely on it, life without it seems inconceivably complex
I love the slightly weird learning curve on NixOS where initially it seems incredibly complex writing this weird functional programming language for every change you want to apply to your system, then over time it clicks and you end up in a place where any operating system that doesn't define everything in a weird functional programming language seems incredibly complex. I read blog posts about doing things on other distros now and I'm left thinking that an 800 word set of instructions would be 25 lines of Nix expressions.
When I started self hosting last year it seemed insane that hosting a service required separately managing the imperative firewall state, vpn, container runner, systemd, and reverse proxy.
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.
I've find my email on simple-nixos-mailserver for almost a half decade... So easy, less than 25 lines of code and a command line to update every few months.
This is the concept of Simple vs Easy https://news.ycombinator.com/item?id=38768107
yes, exactly!
it's like reading instructions for using a GUI program (open this dialog, click this checkbox, fill in this value) vs copying and pasting a complex FFMpeg command
One of the best things about Nix, aside from LLMs being able to manage your config, is having a monorepo that contains the config across all machines (shared and machine-unique), like hosts/{nas,macbook}/{configuration.nix,home.nix,modules/}.
Now I have the same setup across my macbook, desktop, and NixOS servers.
I post this on every post about Nix I encounter, but I sincerely hope that it gets static electricity typing one day. I have yet to try typenix (a fork of the typescript compiler applying the typescript type system to nix)
https://github.com/ryanrasti/typenix
Adding TS types to Nix would make it so much easier to write Nix code. Which string do I need here? Oh the type system knows, the language server shows it inline - I don't have to look at the source. I've used NixOS since 2018 and written nixpkgs derivations and it would've saved me so much time.
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
I'm fairly close to releasing something called nix-compile, which is a type inferring Hindley-Milner compiler that unifies across nixlang and bash. It finds a lot of bugs. Because it has a very complete view of your project, it can do cute stuff like precise go to definition across modules, annotate code with types in the comments, it's cool.
> static electricity typing
I assume that was an autocomplete typo?
Lol yes
I decided to move to NixOS a few months ago. In terms of OS, it was one of the best decisions I've made so far. It's awesome to have the rollback experience, upgrade whenever you want and also being able to experiment without being afraid of breaking already working stuff.
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.
> Removed 17532 outdated packages, in an effort to keep the package set maintainable and secure.
Thanks for this! I appreciate the acknowledgement that more software in nixpkgs is not necessarily better.
We use NixOS for all of our robots and servers at https://www.monumental.co, hard to imagine how we would do constant updates of our robot fleet without it.
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!
Cool company! Do you guys hire only local to the Netherlands? I see some roles I might be a good fit for (experience w/ Rust, cpp, nix), but dont wanna waste your time
> Deprecation of x86_64-darwin
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've been using t2linux[0] patched distros on an Intel MBP for a while now. While I applaud the efforts, it is not without sharp edges, and I do occasionally have to boot into macOS to do some things. I gave up on trying to use the onboard or bluetooth audio (onboard can cause it to crash in weird ways, and bluetooth can break depending on if wifi is in 2.4 pr 5ghz mode? I don't know, I use a USB DAC now and it's fantastic). Trying to use the webcam causes a hard crash. Sleep is weird (but that's a given for most linux things I think). The maintainers do a good job of getting all their little hacks included...but I'd probably be frustrated with it all if I didn't have 25+ years of experience with linux and be able to fix things myself. The MBP was a gift and my only machine at the moment so I won't complain much personally :).
[0] https://wiki.t2linux.org/
It's great. It's complicated. I have a MacBook Pro Late 2013 – very old. NixOS runs totally great! Even the proprietary hardware just works, with the nixos-hardware channel. Battery life is awesome, 4 hours of office work.
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!
I have NixOS installed on a 2009 MacBook Pro and it works well enough every time I pick it up.
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.
> The 26.05 release was made possible due to the efforts of 2842 contributors, who authored 59703 commits since the previous release.
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.
The majority of these commits are to keep packages up to date. Easy to get an incredibly high number of commits when nixpkgs is a monorepo containing the definition of 140000 packages
Good to know. I am entirely against monorepos but in the very specific case of NixOS I get how it can actually make sense.
Anecdote: I was trying out a new editor at some point that had just had a huge update. I installed it on NixOS and noticed the new update had not been pushed onto NixPkgs. I went through their contribution guide and found how to update the package. I opened a PR and immediately a couple previous contributors & a specific maintainer were on the PR and left me some helpful comments and questions and I got it merged a few days later.
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
1500 commits seems kind of low? that's an average of one commit every two ish days
I would love a Bazzite-style nixos distribution. Like batteries-included for gaming.
Is this kind of thing common in the NixOS space ? Like configs you can import that manage 99% of the os for you ?
What makes Bazzite-like uncommon is the degree of hardware testing and kernel tuning required to get some of the more exotic hardware fully working and stable.
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...
Not the same thing but you can go in the other direction using https://blue-build.org/reference/recipe/. You can have a nixos-style bazzite distribution where you import the bazzite base image and layer your custom config on top of it.
Yes I'm using bluebuild for my custom bazzite image.
Jovian is as close as you’ll get. Works like a charm and gives you a SteamOS-like experience on desktop.
There are templates for deploying NixOS but almost all that I've encountered are heavily opinionated and thus only kinda work for specific people (usually the ones that designed them). Then when you want to customize them it's almost always easier to start from scratch.
NixOS is very much a toolkit for building operating systems. You in modules that set up parts of the system with overridable defaults, and you focus on the parts that matter. Sometimes that is the disk layout, other times it is the dot files, yet other times it is the services.
Adding a new domain to my NixOS webserver is a single line of code.
It is not common at all
I'd love to try NixOS but I still have PTSD from trying to run/use Nix on MacOS, across two separate profiles on the same physical device too.
On macOS I settled for Nix + HomeManager rather than going fully nix-darwin
I tried nix-darwin (with plenty of LLM assistance) but struggled to get it to work in the way I wanted. I couldn’t get it to manage my dock, and it was fiddly bootstrapping my two main users from an admin user.
I wonder how common this set-up is, but it's what I settled on as well (my flake contains 8 other NixOS hosts with common home-manager config).
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
I've used this set up for 3 or 4 years now and love it. I used to hit bottlenecks having to edit some nix files once or twice a month and forgetting the language but LLMs dramatically reduce that barrier.
I've run nixos for ten years now without ever having to reinstall... Just continuous updates and my dev environments are nice and segregated and one command line away from being identical on all my computers.
Nirvana
NixOS is a pretty cool idea in theory. In actual practice I found it too complicated to manage. Immutability is kind of cool too, but it creates an obstacle to solving even trivial task in my daily life using Linux. And I don't want to really use such a domain specific language like Nix, for things that really should not need a programming language per se. For instance, I like ruby, but I don't want configuration stuff to be kept in .rb files; that's also one gripe I have with homebrew, even if the idea to HAVE a recipe in a .rb file, is not bad per se. I am just too used to e. g. yaml files or any other simple format for literally everything. All my RC files and ENV data and aliases for shells is kept in .yml files; ruby then just autogenerates any target format I need for different shells/terminals, and so on and so forth. Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/ rather than a hashed directory name. It's not a bad idea here either, and there would be many workarounds for that (see GoboHide on GoboLinux, for instance), but at the end of the day it felt as if I was fighting NixOS too much than getting real work done. There is something to be said about simplicity at all times, even if the ideas in NixOS are still great. For instance, we could guarantee that every snapshot would work, so people having the same hardware could just re-use configuration and have things work, without needing to know how to change the system precisely. That would not be needed because NixOS could make a guarantee about ALL possible stable snapshots in time. I don't think NixOS goes that far, so far, but it would be a very logical extension. Same with immutable packages / reproducible packages:
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.
> Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/
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.
Why don’t more people use NixOS on servers?
Is it because of no LTS?
And is having a LTS somewhat the antithesis of what NixOS represents?
> Is it because of no LTS?
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.
The same reason you don't use arch linux on servers. Some distros are simply better suited for servers. We do have talosos for k8s and we (used) to have clearlinux.
Reproducible builds though seem perfect for servers, no?
rather than being theoretically better, it's simply the standard way of running servers. Nobody stops you from using nix or even arch on servers, but nearly all of installations, enterprise packaging and "officially" supported distros are debian/ubuntu/centos and has been like that for a really long time.
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
I do use nixos on my (limited) servers. I self host everything. Ama.
Let's talk about the important things... how is the drama currently on the Nix community?
15 hours later and noone taking that ragebait, seems healthier than most communities to me as a total outsider.
More of a gossipbait to be honest.
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.
Systemd wins...is that good or bad?