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

[Ericson, John]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151101/48f73d6d/attachment.html