all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* An inquiry into the possibility of donating a beaglebone black.
@ 2016-01-26 23:44 Zachary Storer
  2016-01-27 20:58 ` Andreas Enge
  0 siblings, 1 reply; 2+ messages in thread
From: Zachary Storer @ 2016-01-26 23:44 UTC (permalink / raw)
  To: help-guix

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?

Thanks,

Zachary Storer

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: An inquiry into the possibility of donating a beaglebone black.
  2016-01-26 23:44 An inquiry into the possibility of donating a beaglebone black Zachary Storer
@ 2016-01-27 20:58 ` Andreas Enge
  0 siblings, 0 replies; 2+ messages in thread
From: Andreas Enge @ 2016-01-27 20:58 UTC (permalink / raw)
  To: Zachary Storer; +Cc: help-guix

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-01-27 20:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-26 23:44 An inquiry into the possibility of donating a beaglebone black Zachary Storer
2016-01-27 20:58 ` Andreas Enge

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.