ChanServ changed the topic of #nixos-ruby to: Everything about using Nix & Ruby. Logs at https://logs.nix.samueldr.com/nixos-ruby/
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-ruby
zarel has quit [Ping timeout: 260 seconds]
zarel has joined #nixos-ruby
<{\_\}> N​obbZ[discord]: @setheron it is reproducible if the result is the same with the same inputs, though as I said, once you change the compiler, because you want to use clang for the GNUless November instead of GCC, then a FOD will likely fail. If you want to use GCC 8 instead of 7, a FOD will likely fail.
<{\_\}> N​obbZ[discord]:
<{\_\}> N​obbZ[discord]: Still, the derivation is reproducible, as it won't change as long as you don't change something.
<{\_\}> N​obbZ[discord]: The FOD mechanism in nix is to break out of the sandbox for some operations that are inherently irreproducible, like network access. Not to say, "hey look this is a reproducible build"
<simpson> Yes. This is one of the senses in which Nix is not truly a package-capability system, but merely transitional.
<{\_\}> z​imbatm[discord]: there are some issues with the terminology
<{\_\}> z​imbatm[discord]: "reproducible" is not a great term because it conflates a number of meaning
<{\_\}> z​imbatm[discord]: our interest here is to get bit-reproducible outputs, in the sense that two or more machines can generate the same output
<{\_\}> z​imbatm[discord]: aka: independently verifiable
<{\_\}> z​imbatm[discord]: the property here is that two systems can independently verify that the output is the same
<{\_\}> z​imbatm[discord]: the interest is that is changes the trust model and we can have independent actors verify that what is stored in cache.nixos.org hasn't been tampered with
<{\_\}> z​imbatm[discord]: FOD is interesting but it serves a different purpose
<{\_\}> z​imbatm[discord]: the main interest of FOD is to allow for early cut-offs in a rebuild chain
<{\_\}> z​imbatm[discord]: and to minimize the amount of compute necessary when changing some build recipe
<{\_\}> z​imbatm[discord]: both notions are linked since FOD also requires bit-reproducible outputs, but reaching bit-reproducible outputs is also interesting on its own
<{\_\}> z​imbatm[discord]: that's how I see things at the moment
<{\_\}> s​etheron[discord]: Aren't FOD the signal that a derivation is reproducible though @zimbatm ; otherwise there's no enforcement.
<{\_\}> s​etheron[discord]: I'm free to edit the scripts without caring much about whether i'm violating the invariant.
<{\_\}> s​etheron[discord]:
<{\_\}> s​etheron[discord]: I get the headache of having to update the SHA but that seems to be the point of even working towards making something bit-reproducible.
<{\_\}> N​obbZ[discord]: As we tried to explain already. FOD is not to enforce the same output each time. It is to lift restrictions of the sandbox while retaining guarantees.
<{\_\}> s​etheron[discord]: I see I get the difference although there is overlap.
<{\_\}> s​etheron[discord]: It must also be bit-reproducible in order to be FOD (as discussed)
<{\_\}> N​obbZ[discord]: Yeah, though you try to avoid inputs which could change the outcome.
<{\_\}> N​obbZ[discord]:
<{\_\}> N​obbZ[discord]: In my case I now had to temporarily make something a FOD as something changed in how deps are handled in upstream. I quickly made it a FOD and used upstream tooling to download deps in a `preBuild`, though I'm aware that it will break once I update the compiler, therefore I have to dig the issue down later today and fix the underlying issue.
<simpson> I grok setheron's point, though; like, it's *frustrating* that we have these informal proofs of reproducibility and that Nix doesn't have a way to let us formalize them.
<{\_\}> N​obbZ[discord]: Setheron?
<simpson> Sorry, the message appears over here like: 10:45 <{\_\}> s​etheron[discord]: I see I get the difference although there is overlap.
<{\_\}> N​obbZ[discord]: Okay, I see them as fzakaria ;)
<{\_\}> N​obbZ[discord]: I still think that dependency injection and a formal proof of reproducibility are contrary to each other, if not mutually exclusive, unless of course I have to also inject the proof of reproducibility with each set of dependencies.
<simpson> Dependency injection is just function application; it just means that reproducibility requires the same input *and* the same function.
<{\_\}> N​obbZ[discord]: Exactly, that's why having a sha256 as proof in the mkDerivation which is in the `callPackage` called function a bad idea
<{\_\}> N​obbZ[discord]: As I'm on mobile it's hard to properly get my thoughts into sentences and keystrokes...
<simpson> No worries, no rush.
<{\_\}> N​obbZ[discord]: Any hardcoded proof within the function might break evaluation when you do a override. To circumvent that, you'd have to pass it with the overrides and the function actually needs to implement it in a way to take the proof from the argset.
<{\_\}> N​obbZ[discord]:
<{\_\}> N​obbZ[discord]: It's even worse when you have a huge set of packages which you can do with a set of different runtimes or compilers like the python or beam ecosystem. How many proofs have I to provide on a `pkgs.beam.packagesWith pkgs.erlangR22`?
<simpson> Yeah, totally, it's not actually easy to specify a toolchain this way.
<{\_\}> z​imbatm[discord]: it's quite difficult to establish the FOD correspondence without running the computation, this is quite inherent to the domain space
<{\_\}> z​imbatm[discord]: for simpler things like git hashes, it might be possible to create that proof, but it would require to change the underlying data model
<{\_\}> z​imbatm[discord]: by saying that the git sha1 is trusted it would be possible to not have to provide the second hash
<{\_\}> z​imbatm[discord]: by doing that, it also introduces a risk of weakening the purity of the model so it would have to be done carefully
<{\_\}> z​imbatm[discord]: the second use-case for FOD is when fetching a bundle of dependencies like get all the cargo packages of a project
<{\_\}> z​imbatm[discord]: in that case, the best thing to do is to split that big chunk into per-package derivations
<{\_\}> z​imbatm[discord]: another aspect that might make things better is if Nix was able to replace the hash in the source code automatically
<{\_\}> z​imbatm[discord]: then it would reduce the overhead of copy-pasting the hashes around
<{\_\}> z​imbatm[discord]: but guaranteeing the output to be stable is a tricky business
<{\_\}> z​imbatm[discord]: most tools don't guarantee that the disk representation is the same, even if they are careful with pulling things from the Internet