[Nix-dev] Ideas for a NixOS-related bachelors thesis?

[William Kennington]

Even just implementing ipfs as a source mirroring system would be
incredibly useful since some packages have incredibly unreliable mirrors.
It should be easy to generalize to all of the types of fetches, but you
might have to modify the current hashing scheme to match multihash for it
to be seamless.
On Sun, Nov 1, 2015 at 1:16 PM Ericson, John <john_ericson at brown.edu> wrote:

> Point taken. I find IPFS + Intentional store more elegant, but IPFS +
> extensional store is a step in the right direction, both in terms of
> conception and implementation work.
>
> On Sun, Nov 1, 2015 at 10:51 AM, Nicolas Pierron <
> nicolas.b.pierron at gmail.com> wrote:
>
>> On the other hand, if we want to go to a model where the cache is not
>> built by a central authority, which sounds a bit more interesting and
>> challenging, then we would need a way to map a derivation to the output.
>>
>
> Hmm either way we map drv->output, just with extensional store the store
> hash != the NAR hash. Also I can't think of easier way to verify the
> drv->build mapping other than re-performing the build oneself, so I don't
> think we can do better than a system based on trust.
>
>
>> Note, that the intentional would not help in any way.  The intentional
>> model compute hashes after moving the self-references hash to be indexes,
>> which means that you effectively got a different hash than just blindly
>> hashing the content.
>>
>
> If I recall Eelco's thesis correctly, the derivation is built in a
> temporary location, the build is hashed, and then the binary is mangled so
> the temp path is replaced with the proper /path/to/store/hash/ path. Well
> if we just stick the data in IPFS before the path replacement, and let the
> other side do the mangling we dodge that problem.
>
> N.B. I'll admit that neither my above plan nor Eelco's original plan are
> very satisfactory---say the path strings are compressed in the binary for
> example, then the mangling will fail. I was once thinking about about an
> alternate solution of mounting `/self/` or something per-process to avoid
> needing mangling at all. But that will break with at least dynamically
> linked libraries and probably other things.
>
>>
>> Also, you probably don't want to upload nar files as-is, even if nothing
>> prevents you from doing so, because you probably want to take advantage of
>> the merkle-dag for sharing similar files, in the same way as we optimize
>> the nix-store with hard links.
>>
>
> Yes! This + normalizing "${mDrv}/sub/path" to a hash of the subdirectory
> could reduce/eliminate the need for multiple-output derivations.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151101/354cf978/attachment.html