4 ms·

Oh, I assure you, it's hard to escape knowing about Nix if you write about this sort of thing. Someone will be along almost immediately to inform you about it.

by jzb 1y ago

Oh, I assure you, it's hard to escape knowing about Nix if you write about this sort of thing. Someone will be along almost immediately to inform you about it. Nix wasn't mentioned (I'm the author) because it really isn't relevant here -- the comparable distributions, when discussing what Fedora is doing, are Debian and other distributions that use similar packaging schemes and such.

__MatrixMan__ 1y ago
I agree that NixOS/nixpkgs would not be a good a basis for comparison. Do you have an opinion about the use of nix by app devs to specify their builds, i.e. as a make alternative, not as a Fedora alternative? Quoting the article: > Irreproducible bits in packages are quite often "caused by an error or sloppiness in the code". For example, dependence on hardware architecture in architecture-independent (noarch) packages is "almost always unwanted and/or a bug", and reproducibility tests can uncover those bugs. This is the sort of thing that nix is good at guarding against, and it's convenient that it doesn't require users to engage with the underlying toolchain if they're unfamiliar with it. For instance I can use the command below to build helix at a certain commit without even knowing that it's a rust package. Although it doesn't guarantee all aspects of repeatability, it will fail if the build depends on any bits for which a hash is not known ahead of time, which gets you half way there I think. nix build github:helix-editor/helix/340934db92aea902a61b9f79b9e6f4bd15111044 Used in this way, can nix help Fedora's reproducibility efforts? Or does it appear to Fedora as a superfluous layer to be stripped away so that they can plug into cargo more directly?
- microtonal 1y ago
  Used in this way, can nix help Fedora's reproducibility efforts? Or does it appear to Fedora as a superfluous layer to be stripped away so that they can plug into cargo more directly? A lot of Nix-based package builds will burn Nix store paths directly into the binary. If you are lucky it's only the rpath and you can strip it, but in some cases other Nix store paths end up in the binary. Seems pretty useless to Fedora. Besides many of the difficult issues are not solved by Nix either. (E.g. build non-determinism by ordering differences due to the use of a hashmap somewhere in the build.)
  - __MatrixMan__ 1y ago
    > A lot of Nix-based package builds will burn Nix store paths directly into the binary I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build. I'd still think that by refusing to build things with unspecified inputs, nix prunes a whole category of problems away which then don't bite the distro maintainers, but maybe that's wishful thinking. I'll continue to use it because it's nice to come to a project I haven't worked on in a few years and not have to think about whether it's going to now work on this machine or figure out what the underlying language-specific commands are--but if there were ways to tweak things so that others have this feeling also, I'd like to know them.
    - microtonal 1y ago
      I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build. It's a feature. E.g. if a binary needs to load data files, it needs to know the full path, or you are back to an FHS filesystem layout (which has a lot of issues that Nix tries to solve). I'd still think that by refusing to build things with unspecified inputs, I haven't followed development of traditional Linux distributions, but I am pretty sure that they also build in minimal sandboxes that only contain specified dependencies. See e.g. Mock: https://github.com/rpm-software-management/mock https://github.com/rpm-software-management/mock
      - __MatrixMan__ 1y ago
        Oh I'm sure they do build in sandboxes... my point is that those builds are more likely to succeed on the first try if the app dev also built in a sandbox. If you let nix scold you for tempting fate and relying on the output of an unchecked curl, that's one fewer headache for whoever later tries to sandbox your stuff.

by jzb 1y ago

__MatrixMan__ 1y ago

I agree that NixOS/nixpkgs would not be a good a basis for comparison. Do you have an opinion about the use of nix by app devs to specify their builds, i.e. as a make alternative, not as a Fedora alternative? Quoting the article: > Irreproducible bits in packages are quite often "caused by an error or sloppiness in the code". For example, dependence on hardware architecture in architecture-independent (noarch) packages is "almost always unwanted and/or a bug", and reproducibility tests can uncover those bugs. This is the sort of thing that nix is good at guarding against, and it's convenient that it doesn't require users to engage with the underlying toolchain if they're unfamiliar with it. For instance I can use the command below to build helix at a certain commit without even knowing that it's a rust package. Although it doesn't guarantee all aspects of repeatability, it will fail if the build depends on any bits for which a hash is not known ahead of time, which gets you half way there I think. nix build github:helix-editor/helix/340934db92aea902a61b9f79b9e6f4bd15111044 Used in this way, can nix help Fedora's reproducibility efforts? Or does it appear to Fedora as a superfluous layer to be stripped away so that they can plug into cargo more directly?

microtonal 1y ago
Used in this way, can nix help Fedora's reproducibility efforts? Or does it appear to Fedora as a superfluous layer to be stripped away so that they can plug into cargo more directly? A lot of Nix-based package builds will burn Nix store paths directly into the binary. If you are lucky it's only the rpath and you can strip it, but in some cases other Nix store paths end up in the binary. Seems pretty useless to Fedora. Besides many of the difficult issues are not solved by Nix either. (E.g. build non-determinism by ordering differences due to the use of a hashmap somewhere in the build.)
- __MatrixMan__ 1y ago
  > A lot of Nix-based package builds will burn Nix store paths directly into the binary I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build. I'd still think that by refusing to build things with unspecified inputs, nix prunes a whole category of problems away which then don't bite the distro maintainers, but maybe that's wishful thinking. I'll continue to use it because it's nice to come to a project I haven't worked on in a few years and not have to think about whether it's going to now work on this machine or figure out what the underlying language-specific commands are--but if there were ways to tweak things so that others have this feeling also, I'd like to know them.
  - microtonal 1y ago
    I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build. It's a feature. E.g. if a binary needs to load data files, it needs to know the full path, or you are back to an FHS filesystem layout (which has a lot of issues that Nix tries to solve). I'd still think that by refusing to build things with unspecified inputs, I haven't followed development of traditional Linux distributions, but I am pretty sure that they also build in minimal sandboxes that only contain specified dependencies. See e.g. Mock: https://github.com/rpm-software-management/mock https://github.com/rpm-software-management/mock
    - __MatrixMan__ 1y ago
      Oh I'm sure they do build in sandboxes... my point is that those builds are more likely to succeed on the first try if the app dev also built in a sandbox. If you let nix scold you for tempting fate and relying on the output of an unchecked curl, that's one fewer headache for whoever later tries to sandbox your stuff.