Group: Guix/GSoC-2023

From LibrePlanet
Jump to: navigation, search
(added myself as metor for the distributed substitutes)
Line 39: Line 39:
 
* pukkamustard
 
* pukkamustard
 
* attila.lendvai (ethswarm.org, scheme)
 
* attila.lendvai (ethswarm.org, scheme)
 +
 +
== Project: Robustify long-term support for Reproducible Research ==
 +
 +
Guix has an almost unique feature: <code>guix time-machine</code>.  It allows to jump to any Guix revision and run Guix as it was at this very specific revision.  For instance <code>guix time-machine --commit=v1.1.0 -- shell hello</code> spawns a new shell containing the program <code>hello</code> exactly as it was built back in 2020 at the time of the release of v1.1.0.  Obviously, "''exactly''" assumes the build is fully deterministic and reproducible.
 +
 +
This feature is highly interesting in the context of Reproducible Research as one solution for the replication crisis [https://en.wikipedia.org/wiki/Replication_crisis].  If researcher specifies one revision via the file <code>channels.scm</code> and one manifest file via the file <code>manifest.scm</code>, then the hope is to reduce the burden for re-generating later the same computionnal environment using <code>guix time-machine -C channels.scm -- shell -m manifest.scm</code>.
 +
 +
The temporal window size of this "later" is unknown.  Guix has most of the machinery for jumping to any Guix revision starting with v1.0.0 released in 2019.  We have now a window of almost 4 years for experimenting with the assumptions:
 +
 +
1. Avaibility of *all* the source code
 +
2. Backward compatibility of the Linux kernel
 +
3. Compatibility with the hardware
 +
4. Time-depend features such as tests or certificates
 +
 +
We are specifically focused on #1 and #4.  About #1, the current solution relies on Software Heritage [https://www.softwareheritage.org/] and Disarchive [https://ngyro.com/software/disarchive.html].  Previous efforts [https://ngyro.com/pog-reports/latest/] are paying off although some work remains, among others automatize the reporting which spots the defects and, corollary, fix them.  Some previous manual investigations are here [https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00398.html][https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00007.html].  Similarly, tools for detecting time-bomb as #4 are lacking.
 +
 +
Well, there are many opportunities for contributing to this effort. Some ideas include:
 +
 +
* improve Disarchive [https://ngyro.com/software/disarchive.html]
 +
* improve Software Heritage bridges and reporting coverage
 +
* package transformation or else for detecting time-bomb
 +
 +
We value contributions in advance of GSoC, even if they're just little ones. During the application period we expect interaction with us, so do not leave it to the last minute.
 +
 +
'''Skills''': Interest in time-travel :-)
 +
 +
'''Mentors''':
 +
* Simon Tournier (zimoun)
  
 
== Ideas from 2021 ==
 
== Ideas from 2021 ==

Revision as of 11:06, 1 March 2023

GNU Guix Google Summer of Code ideas page for 2023

Project: Decentralized substitute distribution

Guix supports transparent source/binary deployment, which means that it can either build things locally, or download pre-built items from a server, or both. We call these pre-built items substitutes—they are substitutes for local build results. In many cases, downloading a substitute is much faster than building things locally.

The two default sources for substitutes are the front-ends of the official build farms: ci.guix.gnu.org and bordeaux.guix.gnu.org. Although Guix allows more substitute servers to be configured [1], the two official build farms remain the primary source for many users - and also the primary points of failure.

We would like to increase the robustness of substitute distribution by using a more decentralized approach. Substitutes should be downloadable from a much larger set of servers and peers that are potentially automatically discovered. Advantages of such an approach might include:

  • Increase reliability of substitute downloading by relying on a larger set of servers/peers.
  • Reduce load on build farm
  • Reduce network usage by being able to use substitutes available closer (e.g. on local network)
  • Allow air-gaped substitute distribution via USB sticks or similar

Previous work on decentralized substitute distribution includes:

More recently, there has been a proposal to use ERIS [3]: This allows multiple transport protocols (e.g HTTP, CoAP [4], IPFS, GNUnet) to be used for downloading substitutes.

There are many opportunities for contributing to this effort. Some ideas include:

  • Improving the user experience and integration
  • Adding more transport protocols (e.g. GNUnet or automatically detected portable media)
  • Conducting performance evaluations

We value contributions in advance of GSoC, even if they're just little ones. During the application period we expect interaction with us, so do not leave it to the last minute.

For more information see:

  • Decentralized substitute distribution with ERIS [5]
  • The Encoding for Robust Immutable Storage (ERIS) [6]

Skills: Interest in decentralized protocols and networks.

Mentors:

  • pukkamustard
  • attila.lendvai (ethswarm.org, scheme)

Project: Robustify long-term support for Reproducible Research

Guix has an almost unique feature: guix time-machine. It allows to jump to any Guix revision and run Guix as it was at this very specific revision. For instance guix time-machine --commit=v1.1.0 -- shell hello spawns a new shell containing the program hello exactly as it was built back in 2020 at the time of the release of v1.1.0. Obviously, "exactly" assumes the build is fully deterministic and reproducible.

This feature is highly interesting in the context of Reproducible Research as one solution for the replication crisis [7]. If researcher specifies one revision via the file channels.scm and one manifest file via the file manifest.scm, then the hope is to reduce the burden for re-generating later the same computionnal environment using guix time-machine -C channels.scm -- shell -m manifest.scm.

The temporal window size of this "later" is unknown. Guix has most of the machinery for jumping to any Guix revision starting with v1.0.0 released in 2019. We have now a window of almost 4 years for experimenting with the assumptions:

1. Avaibility of *all* the source code
2. Backward compatibility of the Linux kernel
3. Compatibility with the hardware
4. Time-depend features such as tests or certificates

We are specifically focused on #1 and #4. About #1, the current solution relies on Software Heritage [8] and Disarchive [9]. Previous efforts [10] are paying off although some work remains, among others automatize the reporting which spots the defects and, corollary, fix them. Some previous manual investigations are here [11][12]. Similarly, tools for detecting time-bomb as #4 are lacking.

Well, there are many opportunities for contributing to this effort. Some ideas include:

  • improve Disarchive [13]
  • improve Software Heritage bridges and reporting coverage
  • package transformation or else for detecting time-bomb

We value contributions in advance of GSoC, even if they're just little ones. During the application period we expect interaction with us, so do not leave it to the last minute.

Skills: Interest in time-travel :-)

Mentors:

  • Simon Tournier (zimoun)

Ideas from 2021

Ideas from 2020

Ideas from 2019

Ideas from 2018