Why I love NixOS

Post by dml2135 » Tue, Mar 24, 2026, 2:30 AM UTC

beepbooptheory wrote: post #287

dml2135 wrote: post #285

Earlier quoted context omitted.

> But if the declaritive file is not read/understood, what is the difference? Well the main difference is precisely that I have a clear opportunity to read and understand the declarative file. But even if something were to sneak in there, rolling back is now trivial.

This whole thing has been about explicitly using LLM instead of learning nix. So sure, definitely agree with about the niceness of using nix in general if that is all you are saying, but also not sure what you are trying to argue for anymore.

Post by schindlabua » Tue, Mar 24, 2026, 7:41 AM UTC

throwawayqqq11 wrote: post #236

rgoulter wrote: post #145

Earlier quoted context omitted.

> nix is superior in every single way. My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful. If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape. With NixOS, you pay all the complexity up front.

Such a pity that the article didnt touch on running rust nightly or the sometimes statefull nature of user configs of some programs. The 5% painful part was just around the corner.

Post by rowanG077 » Tue, Mar 24, 2026, 8:32 AM UTC

bjoli wrote: post #314

rowanG077 wrote: post #307

Earlier quoted context omitted.

Most code is read much more than it is written, at least I read much more code than I write. So for me code should be optimized to be read as plain text as that is basically what every tool uses. Requiring a separate tool to get basic readability is not really acceptable. I can't do that on github, I can't do that with the various diff tools, I can't just quickly cat a file or use the countless other tools that are d…

I just have a hard time taking such a comment seriously, because I have made it myself. Many times even. My second comment on Slashdot in 1999 was a comment just like yours. I try to tell myself it is ok because I was still a teenager. 7 years later I had to write common lisp and I think the parens were a problem for about a week. Since then I have written many thousand lines of lisp code. I usually go back and forth…

Post by JamesSwift » Tue, Mar 24, 2026, 1:27 PM UTC

foldr wrote: post #316

JamesSwift wrote: post #310

Earlier quoted context omitted.

Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned…

I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.) I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.

  ```devenv.yaml```

  inputs:
    nixpkgs:
      url: github:cachix/devenv-nixpkgs/rolling
    nixpkgs-node:
      url: github:nixos/nixpkgs?rev=9c0e2056b3c16190aafe67e4d29e530fc1f8c7c7
    nixpkgs-ruby:
      url: github:bobvanderlinden/nixpkgs-ruby
      inputs:
        nixpkgs:
          follows: nixpkgs

  ```devenv.nix```
  
  { inputs, pkgs, ... }
  
  {
    languages.javascript = {
      enable = true;
      package = inputs.nixpkgs-node.nodejs_24;
    };

    languages.ruby = {
      enable = true;
      versionfile = ./.ruby-version;
      // alternatively
      // version = "3.2.4";
    };
  }

Post by foldr » Tue, Mar 24, 2026, 6:21 PM UTC

JamesSwift wrote: post #317

foldr wrote: post #316

Earlier quoted context omitted.

I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.) I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.

You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different…