[dietr1ch]

> Ditto `nix-ld` being necessary, it's a great piece of work but the dynamic linker should be in the normal place and know about all the libraries on the system by default.

Isn't that part of the point of having NixOS? Dynamic linking into whatever seems best from the nix-store sounds handy until you realise it's just going back to a regular mutable distro where the state is whatever and build instructions start looking like "install all these libraries and cross your fingers just in case" and "works on my machine"™ reigns.

[benreesman]

There's a range of options on this and numerous good mental models for it: flakes are "dirty", Haskell does things in a very granular regime of mutability bounded context combinators, NixOS has to cope with changing hardware (NixOS modules at the absolute apex of "official"-ness escape hatch it, you have to be pretty explicit to get a reliable pin of the kernel, I'm running `linuxPackages_testing` on this machine I'm typing from because I'm setting up a 5090 and need "the newest one" on everything: 2 months ago? 6.16-rc3, today: I think it's 6.17-rc1 or something, haven't looked).

So, much like a `nix flake check` might fail and you want your CI to flag that, a `nh home switch .` might be necessary to get the editor you need to fix the fail. Functional programming has decades of consensus on every possible variation of this.

There are any number of things you could do here (and the message linking you to the `nix-ld` website is an improvement over `libstdc++.so.6 not found blah`). But breaking a library that statically links everything NVIDIA ever wrote precisely so that it will run anywhere because you have a canonical `CC` in your own `NIX_` environment variable prefix set and you just refuse to let grubby ubuntu software see it?

That's incompatible by design. // hypermodern // nixos has a principle that I realize isn't in the `README.md`: it's never incompatible by design for no upside.