> but that's surely a fault with those tools Honestly I don't think so, in modern Linux namespaces it's perfectly possible to run them in isolated filesystems

> but that's surely a fault with those tools Honestly I don't think so, in modern Linux namespaces it's perfectly possible to run them in isolated filesystems and to provide whatever they want at whatever paths they want without patches and workarounds. Instead Nix forces it's way up at the build level, so whatever artifact you get as a result of Nix derivation is suitable for running in a Nix system alone. I'd rather build a generic artifact that could be run in a traditional Linux system and let the user decide how it want to store it, instead of forcing the Nix way. > I've never experienced a problem with it There are problems with gcc-compiled binaries for example, and they are solved with a post-compilation patch. This is a workaround which does not scale and shouldn't be there in the first place, but that's mainly not gcc's problem in my eyes (although it could've done a better job too). > The Nix store provides quite a nice separation between the "definition" side and the "building" side. Somewhere deep inside it indeed does, there is no Nix the lang in final derivations. Nevertheless, I had too much trouble working at that level.