[Nix-dev] Sidestepping the community builds trust issue?

[Shea Levy]

I have no opinion on this feature specifically, but re #3: avoiding a feature in order to keep things in a poor enough state so that users care about the issues you think they should care about is highly patronizing and a terrible way for developers to relate to users. It is incidentally ridiculous to think that this particular community will ever stop caring about solving this particular problem, but more importantly if you can't convince users to care about something without artificially limiting the usefulness of their tools then perhaps that thing is not actually worth caring about.

> On Dec 25, 2015, at 6:21 AM, Jonn Mostovoy <jm at memorici.de> wrote:
> 
> As Nicolas pointed out after we have presented our plan of attacking
> this problem (and as it was mentioned by Dan here), builds are only
> locally-reproducible.
> There is no guarantee that a build built by my machine and your
> machine will yield the same hash.
> 
> It got me thinking -
> 
> 1. Did anybody measure deviation in output hashes we'll face if we
> are to try to "simply" distribute the builds?
> 2. Do you think that asking companies / individuals to contribute
> standard hardware with standard nixos configuration would reduce the
> deviation in output hashes?
> 
> Regarding proposed approach -
> 
> 1. Priorities in distributed systems make Joe Armstrong sad.
> 2. We're increasing distribution at a cost of bigger decentralization.
> 3. Even if this workaround works, it's still a hack. It will lead to
> community not perceiving what is a problem as a problem. I say we
> should avoid success at all costs and deliver the correct solution to
> the problem of distributed builds.
> —
> Kindest regards,
> ¬Σ
> 
> 
> On Fri, Dec 25, 2015 at 10:57 AM, Michael Raskin <7c6f434c at mail.ru> wrote:
>>> A web-of-trust type approach is what I have previously heard discussed. In
>>> the context of such an approach, I have three things to say in support of
>>> my proposal.
>> 
>>> 3. In those first two points, I claim some advantage relative to a
>>> web-of-trust style approach. However, both ideas are fully compatible.
>>> Precisely because my suggestion makes no changes to the current trust
>>> model, it would be just as easy (or difficult) to add in a web-of-trust
>>> style mechanism afterwards. However, of the two, it seems to me that this
>>> idea has significantly lower barriers to full implementation in the short
>>> term, which is why I bring it up.
>> 
>> I think that web-of-trust model allows to get some benefits even when
>> Nix builds are only a part of the computer's load. In that sense it gets
>> lower barrier of entry for contributors. But maybe there are enough
>> teams who do have full-time Nix build slaves…
>> 
>> 
>> 
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev