From: Andreas Enge <andreas@enge.fr>
To: Zachary Storer <zacts.3.14159@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: An inquiry into the possibility of donating a beaglebone black.
Date: Wed, 27 Jan 2016 21:58:28 +0100 [thread overview]
Message-ID: <20160127205828.GA4366@debian> (raw)
In-Reply-To: <CAAehmOEiJVr3YM0NvRfy+R1aeJdnKwwitp1R_Jygw_cd+as5Qw@mail.gmail.com>
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
prev parent reply other threads:[~2016-01-27 20:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 23:44 An inquiry into the possibility of donating a beaglebone black Zachary Storer
2016-01-27 20:58 ` Andreas Enge [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160127205828.GA4366@debian \
--to=andreas@enge.fr \
--cc=help-guix@gnu.org \
--cc=zacts.3.14159@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.