ChanServ changed the topic of #nixos-ruby to: Everything about using Nix & Ruby. Logs at https://logs.nix.samueldr.com/nixos-ruby/
zarel_ has quit [Ping timeout: 260 seconds]
zarel has joined #nixos-ruby
<{\_\}> s​etheron[discord]: cool
<{\_\}> s​etheron[discord]: do the derivations that are reproducible change to fixed output ?
<{\_\}> s​etheron[discord]: (intensional store)
<{\_\}> N​obbZ[discord]: Why would you make them FOD? That would only increase the burden of maintanence when updating.
<{\_\}> s​etheron[discord]: Isn't that the point of reproducible builds ?
<{\_\}> s​etheron[discord]: Without seeing a FOD, I would expect the derivation is not reproducible.
<{\_\}> s​etheron[discord]: The benefit is also all the stuff laid out in the intensional store; you can avoid rebuilding deep chains when you make minor changes to dependencies
<qyliss> FODs are horrible
<qyliss> you have no way of knowing when the hash needs to be changed
<qyliss> but they're orthogonal to the intensional store
<simpson> Yes. I've asked a bunch of questions, all basically unanswered over the years, which have boiled down to: I'm building a language and toolchain. How do I make my language interact well with Nix, given that I *know*, and we *prove* automatically, that certain code artifacts are reproducible.
<simpson> And there's not yet been a good answer. FODs are a terrible answer.
<{\_\}> s​etheron[discord]: Why are FOD a terrible answer ?
<{\_\}> s​etheron[discord]: I think they make sense; they are very explicit about what the output hash is -- that must be stored somewhere.
<{\_\}> s​etheron[discord]: otherwise ... it's not guaranteed reproducible lol.
<{\_\}> s​etheron[discord]: The fact that certain artifacts double store it (i.e. rubygems) is meaningless; that's the problem bundix solves
<{\_\}> N​obbZ[discord]: A god might break once you bump injected dependencies, as they might change how bytecode is generated. Therefore it will break any override or overrideAtrrs you might want to throw at something. Therefore you don't make things FOD unless you really have to, to circumvent the sandbox
<{\_\}> N​obbZ[discord]: A FOD might break once you bump injected dependencies, as they might change how bytecode is generated. Therefore it will break any override or overrideAtrrs you might want to throw at something. Therefore you don't make things FOD unless you really have to, to circumvent the sandbox
<simpson> Right. It's not *that* hard to prove that the compiler function from source code to bytecode is pure, but Nix doesn't understand what that proof is trying to say.
<{\_\}> s​etheron[discord]: i mean it's not reproducible if the bytecode is changing lol
<{\_\}> s​etheron[discord]: FOD should be for **reproducible** builds
<{\_\}> s​etheron[discord]: 🙂
<simpson> But, *is* the bytecode changing? I think that it's relatively common, at least in principle, to have bytecode compilers which only depend on the source code and the compiler; they don't require any true randomness from the OS or etc.
<simpson> I agree with qyliss that the problem is mostly Nix-side ergonomics.
zarel has quit [Quit: ZNC 1.7.5 - https://znc.in]
zarel has joined #nixos-ruby