2 ms·

> uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. I'm confused; Nix mostly works by passi

> uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. I'm confused; Nix mostly works by passing the '--prefix' argument to standard, off-the-shelf configure scripts. Some build/packaging tools don't seem to work with a user-chosen prefix, and hence need some sort of workarounds; but that's surely a fault with those tools. > Horrible-horrible way to compute runtime-dependencies of packages. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually. I completely agree with this one. I've never experienced a problem with it; but that surprises me ;) > This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is. The Nix store provides quite a nice separation between the "definition" side (where the Nix language lives), and the "building" side. In principle you can avoid the Nix language, e.g. the way Guix uses Guile Scheme. The only reason I use the Nix language is due to all of the definitions provided by Nixpkgs ;)

vilunov 4y ago
> 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.

vilunov 4y ago

> 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.