6 ms·

>Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them. Using pre-compiled binaries means that builds aren't reproducible, a goal

>Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them. Using pre-compiled binaries means that builds aren't reproducible, a goal of both Nix and Guix.

tener 10y ago
How so? You can see the build as a pure function. It consumes a binary blob but it doesn't make it any less deterministic?
- davexunit 10y ago
  The build is a source to binary function. How does one reproduce the binary blob? How does one know that binary hasn't been tampered with?
  - qwertyuiop924 10y ago
    Checksums!
    - davexunit 10y ago
      You're missing the point.
      - qwertyuiop924 10y ago
        Well, yes, but I read some newer comments, and I get what you mean. I don't necesarily agree with your decision, but I understand it. M-x passive-agressive-mode And now, I'll go upgrade my NVIDIA drivers, and load up Psychonauts on Steam.
  - corysama 10y ago
    How does one reproduce a .c file? By copying the file. Either way, you know the bits of both the .c and the .so have not been tampered with because you can verify their hashes. Again, it's a philosophical distinction, not a technical one.
    - davexunit 10y ago
      It is both a technical and social problem. Please read: https://reproducible-builds.org/ https://reproducible-builds.org/
      - corysama 10y ago
        The title of that project is "Reproducible Builds". But, that is only a step towards their goal of "Verifiable Builds". Thus we end up in this frustrating semantic mismatch between the two of us. Guix demands source-verifiable builds. Nix does not. Both enable reproducible builds equally well.
  - tener 10y ago
    And how do you know the source code hasn't been tampered with? The same way: cryptographic signatures and checksums.
  - fizzbatter 10y ago
    Can't trust the source either, if you're worried about it being tampered with right? At some point you have to trust something, likely from a central location.. either a checksum, blob, source, or etc.
- chriswarbo 10y ago
  Yes, using binaries is a different issue to software freedom. For example, the Haskell toolchain in nixpkgs downloads pre-compiled binaries of old GHC versions (7.0.4 and 7.4.2) which it uses to bootstrap the newer versions. The binaries are checksummed to ensure reproducibility.
rdtsc 10y ago
Not knowing the practicalities and details of how either one works, and talking in general, I don't see how binaries would make things not-reproducible. One can take a hash of firmware blob just as well as a hash of a source file.
- davexunit 10y ago
  "Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers." https://reproducible-builds.org/ https://reproducible-builds.org/
dbcurtis 10y ago
So, Nix refers to every blob that gets built using an MD5. I should think it would be pretty easy to tell if you have the same binary that somebody else does. And if you can walk a tree of MD5's, you should be able to assert that system A is configured the same as system B.
SwellJoe 10y ago
That doesn't make sense. A reproducible build means that a build done in two different places results in the same binary. It has nothing to do with whether the vendor distributes binaries (with optional source) or source alone. The binary is what matters. i.g., if I build this package myself, will it result in the exact same binary that I download from the vendor? Binaries can be signed to prove that the chain of trust is unbroken between the vendor (who maybe you trust enough to run their software on your systems) and you. In the case of a system with reproducible builds, that signature also says, "if you were to build this yourself, you'd end up with the same binary I am sending you." Edit: I am beginning to realize that when davexunit says "pre-compiled binaries" they are not talking about an OS vendor (like Guix) distributing a binary package (with source available). They are talking about binary blobs provided by third parties, and in a form that is not reproducible, such as an nvidia driver kernel blob. This has led to me assuming davexunit is nuts, but apparently it is just that neither of us has been speaking very clearly to each other, and thus we've seemingly been talking past each other.
- davexunit 10y ago
  The intent of reproducible builds, as defined by the reproducible builds project[0], is to have the entire dependency tree built from the complete, corresponding source code of the many projects in that tree, starting from a minimal set of "bootstrap binaries"[1]. Using precompiled binaries, without a doubt, invalidates that goal. Reproducible builds are an ongoing, unsolved problem. In Guix, some things are reproducible, some things aren't, but our goal remains to maximize reproducibility. [0] https://reproducible-builds.org/ https://reproducible-builds.org/ [1] https://www.gnu.org/software/guix/manual/html_node/Bootstrapping.html https://www.gnu.org/software/guix/manual/html_node/Bootstrap...
  - edude03 10y ago
    I'm pretty sure the goal of reproducible builds is to be able to get the same binary as made somewhere from the source code. Arguably binaries are a form of memoizing / caching if you look at compilation as a pure functional problem. For example, if I have build system that says "with file a hash = 1234 and file b with hash = 4321 I should get a binary with hash = 9876 you can save time compelling that package to check its hash by simply asking the binary repo for a package with hash 9876.

>Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them. Using pre-compiled binaries means that builds aren't reproducible, a goal of both Nix and Guix.

tener 10y ago

How so? You can see the build as a pure function. It consumes a binary blob but it doesn't make it any less deterministic?

davexunit 10y ago
The build is a source to binary function. How does one reproduce the binary blob? How does one know that binary hasn't been tampered with?
- qwertyuiop924 10y ago
  Checksums!
  - davexunit 10y ago
    You're missing the point.
    - qwertyuiop924 10y ago
      Well, yes, but I read some newer comments, and I get what you mean. I don't necesarily agree with your decision, but I understand it. M-x passive-agressive-mode And now, I'll go upgrade my NVIDIA drivers, and load up Psychonauts on Steam.
- corysama 10y ago
  How does one reproduce a .c file? By copying the file. Either way, you know the bits of both the .c and the .so have not been tampered with because you can verify their hashes. Again, it's a philosophical distinction, not a technical one.
  - davexunit 10y ago
    It is both a technical and social problem. Please read: https://reproducible-builds.org/ https://reproducible-builds.org/
    - corysama 10y ago
      The title of that project is "Reproducible Builds". But, that is only a step towards their goal of "Verifiable Builds". Thus we end up in this frustrating semantic mismatch between the two of us. Guix demands source-verifiable builds. Nix does not. Both enable reproducible builds equally well.
- tener 10y ago
  And how do you know the source code hasn't been tampered with? The same way: cryptographic signatures and checksums.
- fizzbatter 10y ago
  Can't trust the source either, if you're worried about it being tampered with right? At some point you have to trust something, likely from a central location.. either a checksum, blob, source, or etc.
chriswarbo 10y ago
Yes, using binaries is a different issue to software freedom. For example, the Haskell toolchain in nixpkgs downloads pre-compiled binaries of old GHC versions (7.0.4 and 7.4.2) which it uses to bootstrap the newer versions. The binaries are checksummed to ensure reproducibility.

rdtsc 10y ago

Not knowing the practicalities and details of how either one works, and talking in general, I don't see how binaries would make things not-reproducible. One can take a hash of firmware blob just as well as a hash of a source file.

davexunit 10y ago
"Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers." https://reproducible-builds.org/ https://reproducible-builds.org/

dbcurtis 10y ago

So, Nix refers to every blob that gets built using an MD5. I should think it would be pretty easy to tell if you have the same binary that somebody else does. And if you can walk a tree of MD5's, you should be able to assert that system A is configured the same as system B.

SwellJoe 10y ago

That doesn't make sense. A reproducible build means that a build done in two different places results in the same binary. It has nothing to do with whether the vendor distributes binaries (with optional source) or source alone. The binary is what matters. i.g., if I build this package myself, will it result in the exact same binary that I download from the vendor? Binaries can be signed to prove that the chain of trust is unbroken between the vendor (who maybe you trust enough to run their software on your systems) and you. In the case of a system with reproducible builds, that signature also says, "if you were to build this yourself, you'd end up with the same binary I am sending you." Edit: I am beginning to realize that when davexunit says "pre-compiled binaries" they are not talking about an OS vendor (like Guix) distributing a binary package (with source available). They are talking about binary blobs provided by third parties, and in a form that is not reproducible, such as an nvidia driver kernel blob. This has led to me assuming davexunit is nuts, but apparently it is just that neither of us has been speaking very clearly to each other, and thus we've seemingly been talking past each other.

davexunit 10y ago
The intent of reproducible builds, as defined by the reproducible builds project[0], is to have the entire dependency tree built from the complete, corresponding source code of the many projects in that tree, starting from a minimal set of "bootstrap binaries"[1]. Using precompiled binaries, without a doubt, invalidates that goal. Reproducible builds are an ongoing, unsolved problem. In Guix, some things are reproducible, some things aren't, but our goal remains to maximize reproducibility. [0] https://reproducible-builds.org/ https://reproducible-builds.org/ [1] https://www.gnu.org/software/guix/manual/html_node/Bootstrapping.html https://www.gnu.org/software/guix/manual/html_node/Bootstrap...
- edude03 10y ago
  I'm pretty sure the goal of reproducible builds is to be able to get the same binary as made somewhere from the source code. Arguably binaries are a form of memoizing / caching if you look at compilation as a pure functional problem. For example, if I have build system that says "with file a hash = 1234 and file b with hash = 4321 I should get a binary with hash = 9876 you can save time compelling that package to check its hash by simply asking the binary repo for a package with hash 9876.