From: Andreas Enge <andreas@enge.fr>
To: Christine Lemmer-Webber <cwebber@dustycloud.org>
Cc: "Jonathan Frederickson" <jonathan@terracrypt.net>,
"Sergio Pastor Pérez" <sergio.pastorperez@outlook.es>,
"Marek Paśnikowski" <marek@marekpasnikowski.pl>,
"Ludovic Courtès" <ludo@gnu.org>,
guix-devel@gnu.org, guix-sysadmin <guix-sysadmin@gnu.org>
Subject: Re: P2P Guix package building and distribution
Date: Thu, 22 Aug 2024 11:05:45 +0200 [thread overview]
Message-ID: <Zsb_aYhnicRsQCn2@jurong> (raw)
In-Reply-To: <87msl5o7gh.fsf@dustycloud.org>
Hello Christine,
Am Wed, Aug 21, 2024 at 06:07:58PM -0400 schrieb Christine Lemmer-Webber:
> > 1. Buying and hosting hardware:
> > 250k€ for hardware
> > 3k€/month (36k€/year)
> So I am guessing bandwith costs are significant but the 250k EUR for
> hardware indicates this is especially a build farm issue rather than a
> content distribution / bandwith issue. (Do I have that right?)
to explain the figures, we counted 30 machines times 100€/month for
hosting, which is maybe what we could obtain if Aquilenet hosts them more
or less at cost for us. This includes bandwidth and electricity; from
what I understood, electricity is the major block, and it is directly
proportional to the number of machines. Bandwidth seems to be less of an
issue. First of all, it is computed somewhat strangely, like
"95% of the time you need to be below 1Gb/s, the remaining 5% you can be
above"; with bandwidth requirements for building coming in bursts
(sometimes inputs are downloaded, sometimes outputs are uploaded,
in-between there is computation without communication) adding a machine
might have the effect of smoothing out the distribution through the
law of large numbers without actually moving the 95-percentile.
And bandwidth is priced degressively.
This concerns bandwidth for building. Bandwidth for distribution is
proportional to the number of users, but so far has not been a bottleneck.
(Of course this will change when we get closer to world domination.)
> Okay, but what if instead I had the option to download something signed
> off by *all of* the MegaCloud build service and two "Guix Builders", and
> they all came to the same hash?
Would this not suppose that all these build instances are completely
disjoint from each other (like bordeaux or ci), and thus will have to
build everything from scratch? Since if a "Guix Builder" uses a MegaCloud
input, every build from then on is no more secure than a MegaCloud build.
Given the effort (in money and administrators' time) to run one build farm,
it does not look realistic that several people start their own build farm
at home.
Andreas
next prev parent reply other threads:[~2024-08-22 9:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 14:24 Sustainable funding and maintenance for our infrastructure Ludovic Courtès
2024-07-03 1:13 ` indieterminacy
2024-07-04 16:37 ` Simon Tournier
2024-07-08 12:02 ` Ricardo Wurmus
2024-07-09 14:49 ` Simon Tournier
2024-07-11 9:23 ` Ludovic Courtès
2024-07-08 15:46 ` Vagrant Cascadian
2024-07-08 18:28 ` Vincent Legoll
2024-07-09 9:47 ` Tomas Volf
2024-07-11 10:33 ` Andreas Enge
2024-07-11 20:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-11 9:38 ` Ludovic Courtès
2024-07-12 10:44 ` Simon Tournier
2024-07-21 12:52 ` Ludovic Courtès
2024-07-08 16:27 ` Efraim Flashner
2024-07-08 17:21 ` Enrico Schwass
2024-07-11 10:48 ` Andreas Enge
2024-07-11 9:28 ` Ludovic Courtès
2024-08-01 22:11 ` Marek Paśnikowski
2024-08-13 2:53 ` Jonathan Frederickson
2024-08-13 16:23 ` Sergio Pastor Pérez
2024-08-13 23:38 ` Jonathan Frederickson
2024-08-14 13:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-08-24 23:15 ` Jonathan Frederickson
2024-08-21 22:07 ` P2P Guix package building and distribution Christine Lemmer-Webber
2024-08-22 9:05 ` Andreas Enge [this message]
2024-08-22 21:57 ` Samuel Christie via Development of GNU Guix and the GNU System distribution.
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=Zsb_aYhnicRsQCn2@jurong \
--to=andreas@enge.fr \
--cc=cwebber@dustycloud.org \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=jonathan@terracrypt.net \
--cc=ludo@gnu.org \
--cc=marek@marekpasnikowski.pl \
--cc=sergio.pastorperez@outlook.es \
/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.