6 ms·

It's like this with a lot of things now. For example, Nix's learning curve used to be a huge barrier to entry. Now with LLMs, I'm using nix-darwin and home-ma

It's like this with a lot of things now. For example, Nix's learning curve used to be a huge barrier to entry. Now with LLMs, I'm using nix-darwin and home-manager for dotfiles, package management, and have individual flakes in all of my projects for cryptographically reproducible builds!

rlt 4mo ago
Nit: there’s nothing “cryptographic” about reproducible builds. “Reproducible build” already usually implies bit-by-bit reproducibility.
- bt1a 4mo ago
  i thought it mainly implied architectural/hardware compatibility and deterministic output
  - aidenn0 4mo ago
    Nix mostly does not guarantee deterministic output. It rather guarantees deterministic inputs, and then sandboxes the system to inhibit the build from accessing the outside world. Deterministic inputs do not always imply deterministic outputs.
    - pabs3 4mo ago
      Indeed, the Reproducible Builds community is working on fixing non-deterministic build output https://reproducible-builds.org/ https://reproducible-builds.org/
- dempedempe 4mo ago
  I meant with Nix you're comparing hashes. With Docker, you're using pinned versions
- illiac786 4mo ago
  “The reproducibility is cryptographically verifiable with hashes“ would be the full sentence, but it’s a mouthful.
  - dekhn 4mo ago
    yes, but it's still not cryptological, it's just verification using hashes.
    - fc417fc802 4mo ago
      The hash being cryptographically secure is significant. In contrast, you could use (for example) md5 to non-cryptographically verify that the full process matched.
      - dekhn 4mo ago
        Sorry, the point I was making is that this isn't cryptography- it's the properties of a cryptographic hash (hard to spoof) that are useful. I don't think any verified build program uses the hash to encrypt data at any point. If I'm wrong on this point, that's fine, but please include a link.
        fc417fc802 4mo ago
        Sure, "verified in a cryptographically secure manner" is technically not equivalent to "cryptographically verified" but the response "it's not cryptographic" is rather ambiguous at best given that it is, in fact, a cryptographically secure manner of verification. The key observation here being that an algorithm or process being "cryptographically secure" does not mean that it is "cryptographic" in nature (ie implements or uses cryptography).
  - pabs3 4mo ago
    Build reproducibility checks usually use bitwise comparison, not hash comparison. The Reproducible Builds project also wrote diffoscope, which goes quite far with helping identify where differences occur and how to fix them. https://reproducible-builds.org/ https://reproducible-builds.org/ https://diffoscope.org/ https://diffoscope.org/ https://try.diffoscope.org/ https://try.diffoscope.org/
pimeys 4mo ago
Nix is also great at work. You keep the server nix code in the same repo and OpenCode can just change and test server config.

rlt 4mo ago

Nit: there’s nothing “cryptographic” about reproducible builds. “Reproducible build” already usually implies bit-by-bit reproducibility.

bt1a 4mo ago
i thought it mainly implied architectural/hardware compatibility and deterministic output
- aidenn0 4mo ago
  Nix mostly does not guarantee deterministic output. It rather guarantees deterministic inputs, and then sandboxes the system to inhibit the build from accessing the outside world. Deterministic inputs do not always imply deterministic outputs.
  - pabs3 4mo ago
    Indeed, the Reproducible Builds community is working on fixing non-deterministic build output https://reproducible-builds.org/ https://reproducible-builds.org/
dempedempe 4mo ago
I meant with Nix you're comparing hashes. With Docker, you're using pinned versions
illiac786 4mo ago
“The reproducibility is cryptographically verifiable with hashes“ would be the full sentence, but it’s a mouthful.
- dekhn 4mo ago
  yes, but it's still not cryptological, it's just verification using hashes.
  - fc417fc802 4mo ago
    The hash being cryptographically secure is significant. In contrast, you could use (for example) md5 to non-cryptographically verify that the full process matched.
    - dekhn 4mo ago
      Sorry, the point I was making is that this isn't cryptography- it's the properties of a cryptographic hash (hard to spoof) that are useful. I don't think any verified build program uses the hash to encrypt data at any point. If I'm wrong on this point, that's fine, but please include a link.
      - fc417fc802 4mo ago
        Sure, "verified in a cryptographically secure manner" is technically not equivalent to "cryptographically verified" but the response "it's not cryptographic" is rather ambiguous at best given that it is, in fact, a cryptographically secure manner of verification. The key observation here being that an algorithm or process being "cryptographically secure" does not mean that it is "cryptographic" in nature (ie implements or uses cryptography).
- pabs3 4mo ago
  Build reproducibility checks usually use bitwise comparison, not hash comparison. The Reproducible Builds project also wrote diffoscope, which goes quite far with helping identify where differences occur and how to fix them. https://reproducible-builds.org/ https://reproducible-builds.org/ https://diffoscope.org/ https://diffoscope.org/ https://try.diffoscope.org/ https://try.diffoscope.org/

pimeys 4mo ago

Nix is also great at work. You keep the server nix code in the same repo and OpenCode can just change and test server config.