4 ms·

Can you elaborate? Personally I feel like everything else is a dead end compared to Nix

vilunov 4y ago
I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers around existing build tools to move dependencies into nix packages to generate stuff like Cargo.nix. - Not so good handling of content-addressable packages due to historic cruft. - Horrible-horrible way to compute runtime-dependencies of packages [1]. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually. I see a future where a package manager builds a fully-isolated environment with only and only required dependencies for my app, using CAS but not forcing it's style of the filesystem on me. Nix is a good step into that direction, but that's not a usable product in my view, just a research project. [1]: https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Edit: Forgot to add, Nix the language is also not good, but I'd like not to discuss that matter. 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.
- max-privatevoid 4y ago
  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.
- Valodim 4y ago
  The filesystem complaint seems so fundamental, you might as well be complaining that Linux didn't use C:\ as its filesystem root.
  - vilunov 4y ago
    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.
- chriswarbo 4y ago
  > 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.
Rapzid 4y ago
Sure; from an industry adoption point of view. I don't think it will ever gain widespread industry adoption. All signs point to it remaining in niche, even if growing currently, user communities while being a curiosity to the wider IT world. It's not even in the conversation in most of the professional world. A large portion those who use, like it, and write about it say they wouldn't recommend it to anyone.

I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers around existing build tools to move dependencies into nix packages to generate stuff like Cargo.nix. - Not so good handling of content-addressable packages due to historic cruft. - Horrible-horrible way to compute runtime-dependencies of packages [1]. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually. I see a future where a package manager builds a fully-isolated environment with only and only required dependencies for my app, using CAS but not forcing it's style of the filesystem on me. Nix is a good step into that direction, but that's not a usable product in my view, just a research project. [1]: https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Edit: Forgot to add, Nix the language is also not good, but I'd like not to discuss that matter. 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.

max-privatevoid 4y ago
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.
Valodim 4y ago
The filesystem complaint seems so fundamental, you might as well be complaining that Linux didn't use C:\ as its filesystem root.
- vilunov 4y ago
  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.
chriswarbo 4y ago
> 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.

Rapzid 4y ago

Sure; from an industry adoption point of view. I don't think it will ever gain widespread industry adoption. All signs point to it remaining in niche, even if growing currently, user communities while being a curiosity to the wider IT world. It's not even in the conversation in most of the professional world. A large portion those who use, like it, and write about it say they wouldn't recommend it to anyone.