help-guix
[Top][All Lists]
Advanced

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

Re: An inquiry into the possibility of donating a beaglebone black.


From: Andreas Enge
Subject: Re: An inquiry into the possibility of donating a beaglebone black.
Date: Wed, 27 Jan 2016 21:58:28 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Zachary!

On Tue, Jan 26, 2016 at 04:44:02PM -0700, Zachary Storer wrote:
> Hello, I have an extra beaglebone black with the case and everything,
> (power cable / sim card, everything). If I donate this board to the
> GuixSD project would it be utilized?

That is a nice suggestion, thank you very much! As pointed out on IRC, it
is not clear whether we could put the machine into use now. 512 MB of
memory is not enough for some of our packages, and we have currently no
way of specifying memory requirements for single packages.

In any case, we would need to wait a few months until the hydra replacement
has been bought and installed; right now, our central server cannot handle
more build machines.

The same centralised approach also means that it would be easier to handle
a few rather powerful build machines instead of many less powerful ones -
and the Beagle board has only one core instead of the four on our current
Novenas. Packages are built by sending all input packages not yet available
there to a build machine; and then the package gets built and the output
sent back. I think this will more or less lead to the central server
sending out the complete distribution to all of the build machines, which
will only be sustainable for a very limited number of builders.

There are a number of approaches how this could be improved. For instance,
instead of having the inputs sent by the central hydra server, the build
machines could fetch them from the nginx cache behind the web interface.
(I wonder if this could not be implemented quickly in the current setting
already. When build machines are just told to run "guix build ..." and
they do not have the necessary inputs, they will fetch them, assuming that
substitutes are enabled.)

Ultimately, we could dream of a fully decentralised approach, where every-
thing is stored in gnunet, and the build machines could look for buildable,
but not yet built packages, reserve them in some way and fed the result
into gnunet (or maybe not reserve them, and duplicate packages could be
used for checking build determinism or to thwart malicious attacks).

Actually, that gives me an idea: You could try to rebuild packages on your
machine and challenge hydra if the output is the same to check for non-
reproducibility in our packages. But in a first step, this would probably
be easier with a more powerful x86 machine.

Andreas




reply via email to

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