Re: CDN performance

[Ricardo Wurmus]

Hi Giovanni,

> for this very reason IMHO we should work towards a network of **very
> trusted** build farms directly managed and controlled by the GuixSD
> project sysadmins; if build farms will be able to quickly provide
> substitutes, caching mirrors will be _much more_ effective than today
>
> ... and a network of "automated guix challenge" servers to spot
> not-reproducible software in GuixSD
>
> with a solid infrastructure of "scientifically" trustable build farms,
> there are no reasons not to trust substitutes servers (this implies
> working towards 100% reproducibility of GuixSD)

This sets the bar very high.  I administer berlin.guix.info /
ci.guix.info (same server) and most of the associated build nodes, but I
don’t think people should trust these computers more than their own
computers or those managed by people they personally know.

The build servers do the same work that a user would do who builds
software locally without substitutes; the builders are supposed to
behave just like any other user.  (And we can challenge their authority
with “guix challenge”.)  I want us to keep in mind that build farms
don’t necessarily deserve any more trust than other computers you don’t
control.  Substitute servers are a convenience.

To improve distribution of binaries we are committed to working on
different strategies at the same time:

- improve our processes so that non-critical package changes only hit
  the master branch when we have already built the package and made it
  available for distribution.

- improve availability of the single server berlin.guix.info by hooking
  it up to a CDN via the name ci.guix.info (from which users can easily
  opt out by changing their default substitute server to
  berlin.guix.info).

- improve redundancy by setting up an off-site fail-over for the head of
  the build farm at berlin.guix.info (such as bayfront).

- distribute build artefacts over IPFS without requiring a central
  authority

All of these things can be done in parallel by different people.  This
increases the project’s resilience and the options that users can choose
from.

--
Ricardo