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.
tombert · 2026-06-29 16:06:25 UTC
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.
tryfinally · 2026-06-29 16:09:06 UTC
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).
craftkiller · 2026-06-29 18:00:36 UTC
> 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.
AyanamiKaine · 2026-06-29 18:03:03 UTC
Ohh I didnt know that, but it makes sense that you would be able to create an ISO, good tip!
yesbabyyes · 2026-06-29 19:10:52 UTC
You can similarly create a docker image from a nix config. It's quite beautiful, nix is impressive.
anon291 · 2026-06-30 05:48:33 UTC
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.
hju22_-3 · 2026-06-30 09:01:45 UTC
That sounds fascinating. Do you have public facing configuration you would be willing to share? :)
anon291 · 2026-06-30 15:18:11 UTC
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.
rekoros · 2026-06-29 16:03:06 UTC
After using NixOS for a bit and eventually learning to rely on it, life without it seems inconceivably complex
jon-wood · 2026-06-29 16:14:44 UTC
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.
rekoros · 2026-06-29 16:20:17 UTC
yes, exactly!
1-more · 2026-06-29 16:49:42 UTC
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
data-ottawa · 2026-06-29 21:56:51 UTC
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.
anon291 · 2026-06-30 05:46:07 UTC
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.
tomalaci · 2026-06-29 16:07:01 UTC
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.
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
wrxd · 2026-06-29 16:17:48 UTC
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.
synoptik · 2026-06-29 22:20:28 UTC
Project README.md Install instructions: List of software to install and what those packages are called on different distributions: Just kidding, it just works.
> 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.
paisawalla · 2026-06-29 16:54:45 UTC
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)
rrvsh · 2026-06-30 00:46:54 UTC
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.
spacington · 2026-06-29 16:43:20 UTC
I'm borderline motivated putting Ubuntu onto my parents computers.
Win11 was frustrating ...
beastman82 · 2026-06-29 16:49:36 UTC
Chrome OS Flex has worked out nicely for my mother-in-law's potato
pmarreck · 2026-06-29 16:43:41 UTC
> 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."
yomismoaqui · 2026-06-29 16:11:46 UTC
Let's talk about the important things... how is the drama currently on the Nix community?
MaxikCZ · 2026-06-30 07:22:47 UTC
15 hours later and noone taking that ragebait, seems healthier than most communities to me as a total outsider.
yomismoaqui · 2026-06-30 14:56:36 UTC
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.
evilmonkey19 · 2026-06-29 16:12:06 UTC
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.
LelouBil · 2026-06-29 16:14:02 UTC
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.
reinitctxoffset · 2026-06-29 22:32:20 UTC
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.
chem83 · 2026-06-29 16:14:20 UTC
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
mplanchard · 2026-06-29 16:36:44 UTC
> 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.
spacington · 2026-06-29 16:44:28 UTC
Is devens something else than nix shell?
coffeeindex · 2026-06-30 13:25:24 UTC
devenv is essentially a convenience wrapper around nix shell with some nice tooling
rgoulter · 2026-06-30 14:20:30 UTC
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".
unforgivenpasta · 2026-06-29 16:14:33 UTC
> 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.
wrxd · 2026-06-29 16:20:59 UTC
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.
fuzzy2 · 2026-06-29 16:30:17 UTC
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!
temp0826 · 2026-06-29 16:30:57 UTC
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 :).
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 ?
mrhottakes · 2026-06-29 16:29:13 UTC
It is not common at all
frantathefranta · 2026-06-29 16:38:18 UTC
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.
synoptik · 2026-06-29 22:41:28 UTC
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.
jdiaz5513 · 2026-06-29 17:02:02 UTC
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...
Cyph0n · 2026-06-29 19:26:44 UTC
Jovian is as close as you’ll get. Works like a charm and gives you a SteamOS-like experience on desktop.
ltheanine · 2026-06-30 13:59:30 UTC
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.
LelouBil · 2026-06-30 17:10:47 UTC
Yes I'm using bluebuild for my custom bazzite image.
linsomniac · 2026-06-29 16:18:18 UTC
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.
shevy-java · 2026-06-29 16:30:36 UTC
> entirely configuring it using Claude Code
This scares me. I would not want AI to run my computer systems.
mplanchard · 2026-06-29 16:32:39 UTC
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.
Yiin · 2026-06-29 16:35:44 UTC
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?
spacington · 2026-06-29 16:40:30 UTC
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
pmarreck · 2026-06-29 16:42:03 UTC
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.
Diti · 2026-06-29 20:47:08 UTC
Let’s be honest, most people do not review the full output of Claude Code because of slop fatigue.
joseda-hg · 2026-06-30 16:18:22 UTC
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.
exe34 · 2026-06-29 16:53:38 UTC
It writes into a configuration file that I git diff before applying.
linsomniac · 2026-06-29 19:59:01 UTC
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."
mplanchard · 2026-06-29 16:30:56 UTC
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.
zihotki · 2026-06-29 18:34:46 UTC
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.
willx86 · 2026-06-29 16:32:20 UTC
I eventually gave up using mason and lsp servers and used 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.
willx86 · 2026-06-29 21:19:03 UTC
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)
pmarreck · 2026-06-29 16:46:51 UTC
> 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.
linsomniac · 2026-06-29 19:47:23 UTC
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.
rhco · 2026-06-29 19:06:39 UTC
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!).
linsomniac · 2026-06-29 19:43:24 UTC
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.
linsomniac · 2026-06-29 20:29:55 UTC
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).
hju22_-3 · 2026-06-30 08:56:45 UTC
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.
iLoveOncall · 2026-06-29 16:18:45 UTC
> 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.
wrxd · 2026-06-29 16:25:33 UTC
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
iLoveOncall · 2026-06-29 16:34:04 UTC
Good to know. I am entirely against monorepos but in the very specific case of NixOS I get how it can actually make sense.
coffeeindex · 2026-06-30 13:35:54 UTC
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
rrvsh · 2026-06-30 03:42:02 UTC
1500 commits seems kind of low? that's an average of one commit every two ish days
markatkinson · 2026-06-29 16:25:29 UTC
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.
wrxd · 2026-06-29 16:26:42 UTC
On macOS I settled for Nix + HomeManager rather than going fully nix-darwin
bjtitus · 2026-06-29 16:28:23 UTC
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.
frantathefranta · 2026-06-29 16:35:10 UTC
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.
cedws · 2026-06-30 05:03:58 UTC
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.
shevy-java · 2026-06-29 16:30:04 UTC
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.
rgoulter · 2026-06-30 14:15:38 UTC
> 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.
hombre_fatal · 2026-06-29 16:32:06 UTC
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.
tiffanyh · 2026-06-29 16:35:09 UTC
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?
himata4113 · 2026-06-29 16:44:32 UTC
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.
tiffanyh · 2026-06-29 16:51:56 UTC
Reproducible builds though seem perfect for servers, no?
himata4113 · 2026-06-29 17:08:07 UTC
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.
Comments
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.
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.
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:
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.
(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."
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.
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.
https://github.com/ryanrasti/typenix
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.
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".
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!
[0] https://wiki.t2linux.org/
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...
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.
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
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
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.
Now I have the same setup across my macbook, desktop, and NixOS servers.
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.