6 ms·

I think Nix/NixOS is a great idea. But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. Sin

by ylyn 6y ago

I think Nix/NixOS is a great idea. But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. Since GCC isn't really meant to work with headers spread across a varying set of directories, you end up with this wrapper for every GCC invocation: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... And this just doesn't sit well with me: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

jchw 6y ago
I agree there’s a lot of hacks and maybe the current model of Nix as it is today won’t survive. However, I think several aspects of the Nix concept are highly novel and worth pursuing, and there’s no way to get there without large intermediary steps. NixOS and GuixSD represent, to me, some of the most exciting OS research not aimed squarely at security. It’s difficult to fully appreciate until you’ve really exploited it well. The hacks that are needed today, indeed, are a bit of a turn off, but I do still find a remarkable amount of stuff ends up working well in the model. As a personal example, NixOS not managing dotfiles feels like it would be a huge deal, but actually it isn’t as big of a deal because you can just manage system level configs; for example, my SwayWM config is stored at /etc/sway/config and so forth, and I can neatly provide Nix store paths in my config files through substitution, allowing me to keep my global namespace cleaner. (Various approaches for per user config can then be applied as needed, such as referencing global configs from dotfiles, or wrapper scripts that have logic.) My opinion is that it’s unlikely NixOS or Nix are the stable, hermetic utopia we’re looking for, but they or a successor may very well become it, and the exploration done today is an important part of the necessary research. I’m already excited by things you can do today that are not well documented, like cross compiling to other platforms almost seamlessly (for example, MinGW has worked quite well in my experience.)
- mlinksva 6y ago
  There also is a NixOS derivative OS project "aimed squarely at security" https://spectrum-os.org/ https://spectrum-os.org/
eeh 6y ago
As a user of NixOS I have not been bitten by any such hacks. As a contributor to NixOS, I have barely noticed this. That said, I mostly apply contributions to applications, not to toolchains.
IshKebab 6y ago
That is definitely unfortunate, but Nix is such an obvious improvement on the standard Unix way of "Just mix all the files into one big /usr soup" that it seems silly to not do it because some programs need a bit of hackery to get them to work. Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.
- ironmagma 6y ago
  Having just learned about Nix a few weeks ago, and after an (admittedly cursory) glance at the language and documentation, my main intuition for why it hasn’t been adopted is that it could be more standard. For example why not use an established language instead of creating one from scratch? The syntax and features of the language look similar to Nim for instance. The benefits would be network effect as well as developer tooling support for newcomers.
  - sparkie 6y ago
    Guix has partly answered that question. Scheme (Guile) is used for nearly everything - package recipes, build instructions, service configuration, OS configuration, etc.
  - danieldk 6y ago
    I guess the reason is that part of the benefits come from being a (largely) pure functional language. The property that an expression must always evaluate to the same value does wonders to reproducibility. I agree that adoption would probably be larger if the language was not Nix or Scheme (Guix).
  - eeh 6y ago
    I agree Nix being new/odd is a barrier, and that NixOS be more popular if the language was more popular. Guix System partly answers this by using Scheme, but ultimately Scheme is unpopular too. A NixOS built on a no-side-effects JS/Python (e.g. Skylark, used in Bazel) would be possible. The build output, a derivation, is just a data type (~ JSON object), and so interoperability between NixOS and something else is possible.
progval 6y ago
> But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. You might have said the same thing about the Reproducible Builds project [1] early on. It was a project inside Debian, that required a modified toolchain (gcc, autotools, etc.) on top of Debian Unstable; and many individual Debian packages needed patches as well. Years later, these toolchain changes are now merged not only in main Debian, but also in other distributions and in upstream software. [1] https://reproducible-builds.org/ https://reproducible-builds.org/

by ylyn 6y ago

jchw 6y ago

I agree there’s a lot of hacks and maybe the current model of Nix as it is today won’t survive. However, I think several aspects of the Nix concept are highly novel and worth pursuing, and there’s no way to get there without large intermediary steps. NixOS and GuixSD represent, to me, some of the most exciting OS research not aimed squarely at security. It’s difficult to fully appreciate until you’ve really exploited it well. The hacks that are needed today, indeed, are a bit of a turn off, but I do still find a remarkable amount of stuff ends up working well in the model. As a personal example, NixOS not managing dotfiles feels like it would be a huge deal, but actually it isn’t as big of a deal because you can just manage system level configs; for example, my SwayWM config is stored at /etc/sway/config and so forth, and I can neatly provide Nix store paths in my config files through substitution, allowing me to keep my global namespace cleaner. (Various approaches for per user config can then be applied as needed, such as referencing global configs from dotfiles, or wrapper scripts that have logic.) My opinion is that it’s unlikely NixOS or Nix are the stable, hermetic utopia we’re looking for, but they or a successor may very well become it, and the exploration done today is an important part of the necessary research. I’m already excited by things you can do today that are not well documented, like cross compiling to other platforms almost seamlessly (for example, MinGW has worked quite well in my experience.)

mlinksva 6y ago
There also is a NixOS derivative OS project "aimed squarely at security" https://spectrum-os.org/ https://spectrum-os.org/

eeh 6y ago

As a user of NixOS I have not been bitten by any such hacks. As a contributor to NixOS, I have barely noticed this. That said, I mostly apply contributions to applications, not to toolchains.

IshKebab 6y ago

That is definitely unfortunate, but Nix is such an obvious improvement on the standard Unix way of "Just mix all the files into one big /usr soup" that it seems silly to not do it because some programs need a bit of hackery to get them to work. Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.

ironmagma 6y ago
Having just learned about Nix a few weeks ago, and after an (admittedly cursory) glance at the language and documentation, my main intuition for why it hasn’t been adopted is that it could be more standard. For example why not use an established language instead of creating one from scratch? The syntax and features of the language look similar to Nim for instance. The benefits would be network effect as well as developer tooling support for newcomers.
- sparkie 6y ago
  Guix has partly answered that question. Scheme (Guile) is used for nearly everything - package recipes, build instructions, service configuration, OS configuration, etc.
- danieldk 6y ago
  I guess the reason is that part of the benefits come from being a (largely) pure functional language. The property that an expression must always evaluate to the same value does wonders to reproducibility. I agree that adoption would probably be larger if the language was not Nix or Scheme (Guix).
- eeh 6y ago
  I agree Nix being new/odd is a barrier, and that NixOS be more popular if the language was more popular. Guix System partly answers this by using Scheme, but ultimately Scheme is unpopular too. A NixOS built on a no-side-effects JS/Python (e.g. Skylark, used in Bazel) would be possible. The build output, a derivation, is just a data type (~ JSON object), and so interoperability between NixOS and something else is possible.

progval 6y ago

> But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. You might have said the same thing about the Reproducible Builds project [1] early on. It was a project inside Debian, that required a modified toolchain (gcc, autotools, etc.) on top of Debian Unstable; and many individual Debian packages needed patches as well. Years later, these toolchain changes are now merged not only in main Debian, but also in other distributions and in upstream software. [1] https://reproducible-builds.org/ https://reproducible-builds.org/