●About
●About LibrePlanet
●Mission Statement
●Founding documents
●Support this Community
●Code of Conduct
●Anti-harassment policy
●Teams
●Activists
●Wiki Helpers
●LibrePlanet Artists
●FSF Community Team
●Local & Student Teams
●Conferences
●LibrePlanet Conference
●Non-official
●Get involved
●Participate
●Discussion channels
●Events
●Login
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:
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:
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:
Skills: Interest in decentralized protocols and networks.
Mentors:
Time: 175 hour
Difficulty: medium
Contact: By mail directly to mentors or to the mailing list guix-devel@gnu.org.
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:
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:
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:
The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom.
We defend the rights of all software users. (Read more)