5 ms·

The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be con

The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town. I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on. Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS. I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up. So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."

sshine 7mo ago
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows. But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success. What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope. So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are. Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
- piyh 7mo ago
  I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
  - sshine 6mo ago
    If you're using Hugo or a similar static site generator, you might like my blog series: https://simonshine.dk/articles/hugo-static-site-setup/ https://simonshine.dk/articles/hugo-static-site-setup/ https://simonshine.dk/articles/vendoring-hugo-themes-with-nix-and-git/ https://simonshine.dk/articles/vendoring-hugo-themes-with-ni... My blog is deployed here: https://github.com/sshine/nix/blob/main/services/nginx.nix#L88 https://github.com/sshine/nix/blob/main/services/nginx.nix#L...
  - xmcqdpt2 6mo ago
    I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process. I'm sure Nix is better, I just haven't needed it yet.
    - sshine 6mo ago
      > it requires discipline (you have to make sure you never do manual steps basically) Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases). Nix requires fewer assumptions. > my entire ansible playbook makes server creation a 3 min process I'm a big fan of Ansible, and everything has its use. I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance. In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
bojo 6mo ago
That's a solid point. I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me. My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
aquariusDue 6mo ago
Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).
christophilus 6mo ago
Wouldn’t any immutable OS accomplish this goal?
- wasting_time 6mo ago
  No. To gain that level of control you need a declarative distro. Immutability and rollbacks are merely nice side effects of the Nix model.
cjbgkagh 6mo ago
I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet. Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
flkiwi 6mo ago
I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them. I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement. Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments. And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually). Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
- mikepurvis 6mo ago
  NixOS's greatest weakness historically has been bad/missing docs, especially docs of the "I have X how do I do Y?" nature. This led to a situation where thousands of users asked those questions on forums and received answers covering a spectrum of possible paths forward. The other path was to spend a bunch of time trolling through module sources to find the options you need and understand what they were going to do and how they would interact with each other. Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
- JamesSwift 6mo ago
  I was already happy with my big ball of nix config for various servers, but claude does shave off a bunch of rough edges and make it more pleasant to interact with. I also resolved a couple nagging issues that had been around for a while. It does tend to hallucinate but thats the great thing about nix... if it builds its probably right!
arikrahman 6mo ago
I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.
- JamesSwift 6mo ago
  Just a note that if you are on nixOS you can configure things to run in an FHS compatible wrapper (https://ryantm.github.io/nixpkgs/builders/special/fhs-environments/ https://ryantm.github.io/nixpkgs/builders/special/fhs-enviro...)
tacon 6mo ago
I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"
wasting_time 6mo ago
> it's the only game in town Hey now, LLMs are pretty good at Guix, too.
- ews 6mo ago
  LLMs are game changers for guix, gemini was able to create manifests for absolutely anything I asked for with very few iterations.
geddawm 6mo ago
It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro. Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised. It's so nice! Underrated for sure.
- mikepurvis 6mo ago
  And if you watch what it's actually doing during a session like that, it's basically exactly what a human would do: run the build, find the error, google the error, consider 2-3 possible fixes, pick one and apply it, repeat. Afterward, look at the various patches and fixups and decide if a refactor is necessary.
Iron_Ninja5 6mo ago
This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.
- riquito 6mo ago
  I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
  - wasting_time 6mo ago
    You can just install Nix on Fedora and grab it from there.
- wasting_time 6mo ago
  The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating. Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration. Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs. Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
  - squiggleblaz 6mo ago
    While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce. Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
charlieflowers 6mo ago
Tell me if I'm understanding you correctly. I summarize this in my head as, "This person loves NixOS because it gave him GitOps for his OS."
- squiggleblaz 6mo ago
  I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system. But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
- orbital-decay 6mo ago
  Yes. That's why I'm using NixOS as well, despite all the terrible jank it has. Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.
nullbyte808 6mo ago
I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos https://github.com/leonewt0n/nixos
vim-guru 6mo ago
There's also GUIX.
woile 6mo ago
Same, I've been playing with kernel settings for AMD, and it's really easy to revert in case things blow up
jak0 6mo ago
[dead]
conradev 6mo ago
I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate. Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you. I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure. In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost. The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.

sshine 7mo ago

As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows. But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success. What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope. So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are. Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.

piyh 7mo ago
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
- sshine 6mo ago
  If you're using Hugo or a similar static site generator, you might like my blog series: https://simonshine.dk/articles/hugo-static-site-setup/ https://simonshine.dk/articles/hugo-static-site-setup/ https://simonshine.dk/articles/vendoring-hugo-themes-with-nix-and-git/ https://simonshine.dk/articles/vendoring-hugo-themes-with-ni... My blog is deployed here: https://github.com/sshine/nix/blob/main/services/nginx.nix#L88 https://github.com/sshine/nix/blob/main/services/nginx.nix#L...
- xmcqdpt2 6mo ago
  I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process. I'm sure Nix is better, I just haven't needed it yet.
  - sshine 6mo ago
    > it requires discipline (you have to make sure you never do manual steps basically) Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases). Nix requires fewer assumptions. > my entire ansible playbook makes server creation a 3 min process I'm a big fan of Ansible, and everything has its use. I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance. In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).

bojo 6mo ago

That's a solid point. I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me. My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.

aquariusDue 6mo ago

Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).

christophilus 6mo ago

Wouldn’t any immutable OS accomplish this goal?

wasting_time 6mo ago
No. To gain that level of control you need a declarative distro. Immutability and rollbacks are merely nice side effects of the Nix model.

cjbgkagh 6mo ago

I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet. Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.

flkiwi 6mo ago

I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them. I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement. Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments. And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually). Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.

mikepurvis 6mo ago
NixOS's greatest weakness historically has been bad/missing docs, especially docs of the "I have X how do I do Y?" nature. This led to a situation where thousands of users asked those questions on forums and received answers covering a spectrum of possible paths forward. The other path was to spend a bunch of time trolling through module sources to find the options you need and understand what they were going to do and how they would interact with each other. Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
JamesSwift 6mo ago
I was already happy with my big ball of nix config for various servers, but claude does shave off a bunch of rough edges and make it more pleasant to interact with. I also resolved a couple nagging issues that had been around for a while. It does tend to hallucinate but thats the great thing about nix... if it builds its probably right!

arikrahman 6mo ago

I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.

JamesSwift 6mo ago
Just a note that if you are on nixOS you can configure things to run in an FHS compatible wrapper (https://ryantm.github.io/nixpkgs/builders/special/fhs-environments/ https://ryantm.github.io/nixpkgs/builders/special/fhs-enviro...)

tacon 6mo ago

I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"

wasting_time 6mo ago

> it's the only game in town Hey now, LLMs are pretty good at Guix, too.

ews 6mo ago
LLMs are game changers for guix, gemini was able to create manifests for absolutely anything I asked for with very few iterations.

geddawm 6mo ago

It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro. Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised. It's so nice! Underrated for sure.

mikepurvis 6mo ago
And if you watch what it's actually doing during a session like that, it's basically exactly what a human would do: run the build, find the error, google the error, consider 2-3 possible fixes, pick one and apply it, repeat. Afterward, look at the various patches and fixups and decide if a refactor is necessary.

Iron_Ninja5 6mo ago

This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.

riquito 6mo ago
I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
- wasting_time 6mo ago
  You can just install Nix on Fedora and grab it from there.
wasting_time 6mo ago
The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating. Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration. Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs. Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
- squiggleblaz 6mo ago
  While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce. Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.

charlieflowers 6mo ago

Tell me if I'm understanding you correctly. I summarize this in my head as, "This person loves NixOS because it gave him GitOps for his OS."

squiggleblaz 6mo ago
I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system. But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
orbital-decay 6mo ago
Yes. That's why I'm using NixOS as well, despite all the terrible jank it has. Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.

nullbyte808 6mo ago

I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos https://github.com/leonewt0n/nixos

vim-guru 6mo ago

There's also GUIX.

woile 6mo ago

Same, I've been playing with kernel settings for AMD, and it's really easy to revert in case things blow up

jak0 6mo ago

[dead]

conradev 6mo ago

I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate. Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you. I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure. In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost. The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.