Group: Guix/GSoC-2023
(added myself as metor for the distributed substitutes) |
Popcornchief (talk | contribs) |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 37: | Line 37: | ||
'''Mentors''': | '''Mentors''': | ||
− | * pukkamustard | + | * pukkamustard (pukkamustard [at] posteo [dot] net) |
* attila.lendvai (ethswarm.org, scheme) | * attila.lendvai (ethswarm.org, scheme) | ||
+ | |||
+ | '''Time''': 175 hour | ||
+ | |||
+ | '''Difficulty''': medium | ||
+ | |||
+ | '''Contact''': By mail directly to mentors or to the mailing list guix-devel@gnu.org. | ||
+ | |||
+ | == 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) | ||
+ | |||
+ | == Project: Develop a Web interface to configure Guix System == | ||
+ | |||
+ | One of the main blockers to self-hosting, and thus a hindrance to user autonomy, is the fact that deploying a server with the relevant services is difficult. Developers of GNU MediaGoblin realized this and [https://lists.gnu.org/archive/html/mediagoblin-userops/2015-02/msg00001.html coined the term "userops"] do describe an ideal future where users are able to deploy services by themselves. The [https://www.freedombox.org/ FreedomBox] project was born of the same desire to put users in control. To achieve that, [https://yunohost.org/ YunoHost] provides a Web interface that lets anyone configure their server, choosing from a [https://yunohost.org/en/apps?q=%2Fapps large catalog of services]. | ||
+ | |||
+ | In this project, we want to develop a Web interface similar to that of YunoHost, with two differences: the tool would be based on Guix System (instead of Debian), and it would let users see how their choices translate in the actual <code>operating-system</code> declaration, as a means to empower them. The interface should also expose features unique to Guix System but that make a big difference: browsing the list of system generations, rolling back to a previous one, and running the garbage collector. | ||
+ | |||
+ | '''Skills''': Knowledge of Guix and Web technologies | ||
+ | |||
+ | '''Mentors''': | ||
+ | * Ludovic Courtès (civodul) | ||
== Ideas from 2021 == | == Ideas from 2021 == | ||
Line 50: | Line 95: | ||
* [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020#Booting_via_network Booting via network] | * [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020#Booting_via_network Booting via network] | ||
* [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020#Syntax_and_semantics_of_systemd_units_in_the_Shepherd Syntax and semantics of systemd units in the Shepherd] | * [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020#Syntax_and_semantics_of_systemd_units_in_the_Shepherd Syntax and semantics of systemd units in the Shepherd] | ||
− | |||
== Ideas from 2019 == | == Ideas from 2019 == |
Latest revision as of 02:39, 5 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:
- Distributing substitutes over IPFS [2]
- GNUnet integration
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 (pukkamustard [at] posteo [dot] net)
- attila.lendvai (ethswarm.org, scheme)
Time: 175 hour
Difficulty: medium
Contact: By mail directly to mentors or to the mailing list guix-devel@gnu.org.
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)
Project: Develop a Web interface to configure Guix System
One of the main blockers to self-hosting, and thus a hindrance to user autonomy, is the fact that deploying a server with the relevant services is difficult. Developers of GNU MediaGoblin realized this and coined the term "userops" do describe an ideal future where users are able to deploy services by themselves. The FreedomBox project was born of the same desire to put users in control. To achieve that, YunoHost provides a Web interface that lets anyone configure their server, choosing from a large catalog of services.
In this project, we want to develop a Web interface similar to that of YunoHost, with two differences: the tool would be based on Guix System (instead of Debian), and it would let users see how their choices translate in the actual operating-system
declaration, as a means to empower them. The interface should also expose features unique to Guix System but that make a big difference: browsing the list of system generations, rolling back to a previous one, and running the garbage collector.
Skills: Knowledge of Guix and Web technologies
Mentors:
- Ludovic Courtès (civodul)
Ideas from 2021
- Trusted computing: Goblins for GNU Guix
- Guix Data Service revision processing instrumentation and performance
Ideas from 2020
- Guile based build tool
- GNU Guix system monitor
- Booting via network
- Syntax and semantics of systemd units in the Shepherd