Hacker News Reader

Absolute, immutable store paths are the main reason why Nix is so good in the first place. The key assertion is that FHS sucks. Using complicated and brittle namespace tricks to construct virtual FHS's everywhere is nothing more than shoving the problem under the carpet. It severely limits the places where Nix can be useful. You usually can't create nested namespaces inside a Docker container, so you couldn't use "Namespace-Nix" programs there. You're also destroying the ability to compose packages and environments. Using multiple versions of the same package within one environment - another goal of Nix - becomes impossible. Implementing NixOS in such a paradigm would be a nightmare, and the result would be very limited compared to what NixOS can do now.

Yes, having to clean up RPATH after compiling a program sucks. Yes, having to implement workarounds to make build tools that desperately cling to their FHS traditions work sucks. These are effectively bugs and/or design errors in those tools. Packages are supposed to be installable into various different prefixes, Nix or not. That's why ./configure --prefix= exists.

The wheel needed to be reinvented because the old one was square.

> 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 ;)

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

The filesystem complaint seems so fundamental, you might as well be complaining that Linux didn't use C:\ as its filesystem root.

The main problem is that there are decades of software developed for the classical filesystem, and Nix proposes just to patch that software so that it would be compatible with the "new" way. This is a radical and unneeded change. It would be better to just run software in separate namespaces and just provide whatever filesystem it wants, instead of forcing your own true way.