NixOS is making me less afraid
39 points by LolPython
39 points by LolPython
Even if you don't go all-in, Nix is excellent when you download stuff from forges, that need pulling in a lot of random dependencies, which it lets you do without polluting your main environment.
That being said, I somehow always keep bouncing off the distro itself. I can't even properly put a finger on it why, it's not lack of use, I've gave it reasonably long periods, but eventually I always go back to the non-declarative distro + Nix as a guest combination. Maybe it's the fact that it's so declarative itself, I like mucking with stuff, even if on the long term it'll lead to tech debt and problems down the line.
The ability for me to define my own package for unpackaged software and have the build process recorded so I can easily update/remove/etc without having to remember "okay, which of these build deps did I only install to get this program to build...?" is so nice.
Can you point me to some good resources on how best to manage that? I'm still pretty new to Nix(OS). Is it "just" a matter of defining derivations in .nix files alongside your configuration.nix that get included?
Yeah, basically. When I'm home I'll copy my setup since there are assorted other tricks to make it so you can e.g. track the upstream source as a flake input rather than manually editing the derivation source.
Here's how I configure my system's installed packages: https://github.com/LightAndLight/personal-configs/blob/main/system/packages.nix
At the end of the file you can see the different ways I've packaged up personal scripts and programs.
I have had a similar experience! Prior to switching to Nix, I had never looked at package definitions before, but now (just a few months after switching) I feel much more comfortable searching for source code to see how packages are defined, and writing my own derivations for software. I have a few scripts and side projects that I've written derivations for in my NixOS configuration, and I've written a few in Flakes for projects where I've needed versions of software that aren't available in Nixpkgs. All of this has been pretty painless, and I definitely understand the lack of docs; it's almost too easy to just find and read source code.
Maybe it's the fact that it's so declarative itself, I like mucking with stuff
The loop of "Change setting in nix -> rebuild system/home configuration -> test thing with new setting" does get old pretty fast.
I found this script (thank you ~kokada) that gets nix out of the way so I can quickly iterate without rebuilding my config over and over. When the settings are to my liking, I put my changes back into nix, rebuild and the file goes back to being a symlink. Of course, it doesn't work with everything, but it's an extremely handy tool to have.
I'm the same, and I'm a nixpkgs maintainer (small time). If I had to put a finger on it, it would be because I don't want to depend on the nix wrappers that can fail or that set too much isolation by default.
NixOS is also making me less afraid to try out new things. Knowing that I can get back to the previous system with a git revert and a rebuild (or by picking an older version from the boot menu in case the system is really broken) is very empowering.
I remember once I nuked my boot setup by copy-pasting config from my old machine (the GUIDs didn't match of course). It completely failed to boot past the menu... so I just booted off the old version and fixed my mistake.
I’ve built these before. It’s satisfying putting (once getting a review, the hard part) to get a module merged in that can abstract away so many of the details from the user for the happy path case—all while still easily exposing all of the bits to be referenced thru the fixed point in other modules or just tweaking the general graph. One of mine set up migrations, set up the DB, set up users, sets up PHP units with sensible resource limits, optimized/precompressed assets + sets CSP for a reverse proxy in Nginx or H2O, & exposes the composer script in a little wrapper.
I have in my own setup for instance a systemd job that manually restarts 2 services once ACME certs are refreshed, I have modified the systemd units to get them to start at the correct times while not touching the other underlying code, & the modules usually expose a package that the user can make final package modifications at the end. The module system isn’t perfect, but it’s been a lot easier to keep my system wrangled & composed with NixOS.
I'm getting a lot of mileage converting all my little VMs and containers over to NixOS. Entirely using AI, Claude Code is remarkably good at creating Nix flakes. The declarative OS is a good match for LLM generation of system specs. No side effects of commands to track, everything testable and reproducible by the agent. And NixOS itself works quite well. Most of the packages I need are there and if something's missing Claude doesn't seem to have any problem making it itself.
Claude Code is remarkably good at creating Nix flakes
Beg to differ. I keep seeing bad patterns in code bases locking what could otherwise be an overlay & stable-friendly code into the experimental flake ecosystem. I’m also seeing weird things like turning on/off overlays in modules, having coupled self code in the system, not exposing overlays… I see some code with vibecoded flakes & it makes the code not usable from my stable Nix system. I can forgive a non-Nix-expert dev coding in such a coupled way without knowing, but the bot I don’t give such a pass.
It just did the statistics on flake vs stable wrt to public usage. E.g. "repos with flake.nix vs those with default.nix" is technically anything but correct, but probably a reasonable and cheap estimate nevertheless.
Any decent llm supports "stable nix"* if you explicitly tell you so. But then it and/or you have to decide on input locking, fetching, output Schema, etc.
With flakes all those decisions are made in a bundle. Which is arguably a huge architectural flaw of them and makes iterative improvement really hard.
But on the flip side it considerably trims the decision tree, that either a human user or an llm has to walk down before starting their actual project.
That may well be an instance of "better is worse", but its neither a fundamental flaw of nix nor of llms. And their ability to produce working flakes of medium complexity is hard to deny on an empirical level from my perspective at least.
No side effects of commands to track
While that's the promise, and I also enjoy LLMs with NixOS, I have found several times this isn't true. One deploys a service with a NixOS package, doesn't like it, removes it, and it leaves around systemd units and so.
Yeah you can’t really fully trust this at all. You have to always verify.
For example, networking.firewall.extraCommands rules do not get cleaned up on configuration switches despite a lot of people (and Opus) suggesting they do. You have to create a custom chain, put all your rules under it, and drop when reconfiguring it to get that functionality. And orphaned firewall rules are really fucking bad.
Anyway, nix lets you get really close to avoiding all such side effects so it’s directionally true.
Impermanence style state whitelisting helps with this, but requires a reboot.
A lot of my services run in microvms with a tmpfs root partition, which achieves something similar.