[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Using GNUnet for binary package distribution

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Using GNUnet for binary package distribution
Date: Thu, 21 Mar 2013 19:01:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 03/21/2013 02:02 PM, Ludovic Courtès wrote:
Hello GNUnet!

GNU Guix provides a transparent binary/source deployment model.  A
server can claim: “hey, I have the binary for
/nix/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.2!”, where the
base32 string uniquely identifies a build process.  If you trust that
server to provide genuine binaries, then you can grab them instead of
building Emacs locally.

The “traditional model” has been to have a build farm build and serve
binary packages.  In that model, users trust the build farm to provide
authentic binaries.

I’m interested in providing a /practical/ decentralized distribution
model.  It seems to me that GNUnet’s DHT would be the most appropriate
(as opposed to AFS).  WDYT?

One of the problems to be solved is authentication: users would have to
specify a list of GNUnet pseudonyms of trusted binary providers, or
something like that.  Managing this list would have to be as easy as
possible, to allow the system to scale.

Another issue is privacy: we want to give users an incentive to share
their binaries, but at the same time, they should have control over what
gets shared (for instance, Christian may want to hide the fact that he’s
installed Python and not Guile ;-)).

What do you think of the idea?  Would the DHT retain files long enough
for this to be practical?

Well, the GNUnet DHT expects that the data source periodically refreshes the values by re-issuing the PUT; without that, it cannot work. Furthermore, you need to consider that DHTs are typically only useful for small data pieces (think <= 64k), not for large files. So what you'd store in the DHT is the meta data (where to find the large files), not the actual files.

gnunet-update (svn/gnunet-update/) is a little project where we started to work on a GNUnet installer that is supposed to include an update mechanism that downloads updates via GNUnet --- after all, if you are
using a recent version of GNUnet, sharing your installation binaries
costs you at least no disk space at all, and if censorship kicks in,
having a way to update in a decentralized fashion might become important.

So gnunet-update is planned to provide the means to locate files based on some package description (signatures, meta data) and download them
via the P2P network.  Fundamentally, there is nothing wrong with using
the basic ideas to distribute packages other than GNUnet itself.

Our current approach to package management is essentially to look at ldd and grab all dependencies (unless compatible versions are already
available on the target system, based on libtool versioning info); the
idea was to make it work with 'any' distribution as long as the architecture matches. Naturally, that doesn't mean that in principle a different package manager could not be used/supported.

gnunet-update is not yet finished, we're currently planning to revise some internal part that gnunet-update will depend on (stream); still, help in moving this area along would be of course welcome.

Happy hacking!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]