unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Samuel Christie via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Andreas Enge <andreas@enge.fr>
Cc: "Christine Lemmer-Webber" <cwebber@dustycloud.org>,
	"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 17:57:36 -0400	[thread overview]
Message-ID: <875xrsw78v.fsf@sdf.org> (raw)
In-Reply-To: <Zsb_aYhnicRsQCn2@jurong> (Andreas Enge's message of "Thu, 22 Aug 2024 11:05:45 +0200")

Andreas Enge <andreas@enge.fr> writes: 
> Am Wed, Aug 21, 2024 at 06:07:58PM -0400 schrieb Christine 
> Lemmer-Webber: 
>> 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.

Yes; every step needs to be validated to ensure the final result 
is correct. That doesn't mean all builders need to validate the 
full tree, just one non-colluding party for each output.

Maybe one solution is to have the community perform the primary 
builds, with "official" builders arbitrating when there's a 
disagreement over the hash. As long as each package is built by at 
least one non-colluding peer, any deviations will be caught. This 
would be simpler than a full consensus protocol, but still avoid 
most conflicts and ensure correctness. Repeat offenders should 
eventually be ignored or banned somehow, but in the worst case it 
devolves to the system we have now of official servers building 
everything.

> 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.

Ideally, the software would be as simple as turning on a service 
to participate. And they shouldn't have to be "full" build farms, 
just share some of the load.

Since packages are already built locally if no substitutes are
available, it might be interesting to simply let the first few computers
that install the package build and share it. Then only ~2 people have to
build new packages (for minimal verification) instead of making everyone
do it until an official substitute exists.


      reply	other threads:[~2024-08-22 21:58 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
2024-08-22 21:57             ` Samuel Christie via Development of GNU Guix and the GNU System distribution. [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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xrsw78v.fsf@sdf.org \
    --to=guix-devel@gnu.org \
    --cc=andreas@enge.fr \
    --cc=cwebber@dustycloud.org \
    --cc=guix-sysadmin@gnu.org \
    --cc=jonathan@terracrypt.net \
    --cc=ludo@gnu.org \
    --cc=marek@marekpasnikowski.pl \
    --cc=sergio.pastorperez@outlook.es \
    --cc=shcv@sdf.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).