71–80 of 323 posts
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?
guix would like a word
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much. Sometimes I even prefer nix-shells over uv for quick one-off Python scripts. I cannot sufficie…
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system". Basically, I want to be able to run completely unverified code off of th…
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much. Sometimes I even prefer nix-shells over uv for quick one-off Python scripts. I cannot sufficie…
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system". Basically, I want to be able to run completely unverified code off of th…
I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup. I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demons…
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much. Sometimes I even prefer nix-shells over uv for quick one-off Python scripts. I cannot sufficie…
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system". Basically, I want to be able to run completely unverified code off of th…
If it isn't enough there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
I'd love NixOS more if they had any decent documentation. Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
A lot of us use NixOS/nix yet haven't read any documentation nor hand-written nix ourself. That's Claude Code's job.
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
Earlier quoted context omitted.
NixOS is high-level declarative, so you're reading high-level config diffs when the AI agent is pitching changes. Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing. You can probably guess what this does: networking.firewall.allowedTCPPorts = [ 8080, 9000 ]; The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just…
> Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing. I am not brand new - and I don't know what the heck the config is doing. That is why I rely on documentation. The "code is self-explanatory" is always an attempt to not have useful documentation and try to rationalise that problem away.
You can read documentation on an as-needed basis or to your heart's content.
The point is that the majority of the day to day changes I make to my desktop environment aren't so critical that I need to do more than read an AI agent's proposed changes to my config and accept them when they look reasonable.
And I don't think looking up the exact config options to NixOS' networking system does anything to increase my knowledge of the OS. It's just a triviality.
Earlier quoted context omitted.
For a personal desktop environment, I just install them normally when there's no up to date nixified option. For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release. I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
I run NixOS and the number of times ive been able to install something 'normally' (not via nixpkgs/flake) is approximately zero. You cant go to a website and download a binary and just run it. Almost every program references a shared library and wont be able to find it. Nixpkgs is very complete in my experience, and in the instances where its not, someone usually has made a flake. The only times ive had to custom-mak…
And there's also nix alien and similar tools as alternative
But indeed usually you end up using patchelf , tell the inputs of a binary n just make a regular nix package from it