Guix days 2025 notes

[Jurij <jurij@kompot.si>]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Hey,

I am sharing some notes from this year's guix days.
They are not super complete but could help in summarizing the sessions I 
attended.

Maybe next year we could start an emacs CRDT server for collective, 
collaborative note taking, I'm pretty sure that would be a convenient 
method of documentation for many if not most attendants.

Thank you for organizing / being present.

Kind regards,
Jurij

[-- Attachment #2: guix-days-2025.org --]
[-- Type: text/org, Size: 4884 bytes --]

* <2025-01-30 čet 14:37> Distributed substitutes
** 1. problem
Are we talking about private substitutes?
Or are we talking about distributed public substitutes?
*** "participatory" substitutes (peer-to-peer)
**** building the substitutes
**** distributing the substitutes
- distribute the source
- distribute the (built) substitute
** 2. solution
- faster
- more economic
- more resilient
** 3. resources
what is the cost of organisational resources?
** 4. challenges
- you must build the source to find out the hash
- you *trust* a substitute server (→ trust the build farm)
  - once you have package signatures (from a trusted source), you can load the packages from unstrusted subtitute servers
- christine suggests that if we agree that we can trust a hash, it's just a matter of serving content addressable sources/packages
- could IPFS be used?
  - is it inefficient?
- even if you have the hash, you would need to receive a whole (large) file before you can hash it and check validity
  - some newer hashing algorithms are solving this problem
- the ~guix-publish~ service makes substitutes available over a (local) network
  - is that secure? what about private builds?
  - you cannot download substitutes for packages that are unknown
  - publishing subtitutes could expose system configuration, some people would not like to do that
  - "your privacy model is not neccessarily someone else's privacy model"
** practicalities or more theory?
*** theory: how to trust hashes?
*** 

* guix forge

- Should guix migrate repositories to forgejo / some other forge?
- Team support is a +
  - not all contributors are developers
  - still want limited number of commiters
  - better overlook/visibility for team members on what is happening
  
* GNU question
- some people not here because of GNU
- GNU has legacy of tools, values, ...
- not questioning commitment to user freedom
  - that is not on the table
- set aside FSF / GNU distinction
- it's much better to keep a pure free software core and add proprietary software than the other way around
- Gnome project moved away from GNU/FSF some years ago (april 2021)
- GNU is toxic - it's not possible to address harassment issues, because opening such discussions is seen as an attack on GNU itself (many have tried, many have failed)
- is it similar to people keeping away from GPL because of GNU association?
  - a lot of GPL software is not organisationally associated with GNU
- Debian also slid away (now involves non-free software)
- GNU Guix → GNU/Guix is like a coherent or complete GNU OS
- a numbre of people do not use Guix because of GNU affiliation (there seem to be a lot on the fediverse)
- GNU tools / GNU assembly → proposal to set up a safe space with values of the GNU project. it was rejected (goal was to move away from rms dictatorship)
  - Social contract: https://gnu.tools/en/documents/social-contract/
  - Code of conduct: https://gnu.tools/en/documents/code-of-conduct/
- hard to stay in GNU but break away
- we need to state new values / how to change
- GNU ← GNU's Not Unanimous?
- Room is in agreement with
  - adding gnu.tools document
  - breaking off from GNU by removing mention (weaker concensus)

* RDE
- "spacemacs for everything"
- layers for things to easily configure stuff for you
- layers can work with eachother
  - one layer enables funcionality in another layer
  - enabling the ~prolog~ layer can give you a jupyter like experience if you have the ~emacs-org~ layer
- it is opinionated (which is a good thing)

* guix pull slow
- ludo not sure why guix pull is so slow, really
- bootstraps new guix
  - old guix → new guix
  - 1. git pull ← takes a while
  - 2. it needs to *compute* the derivation (very slow!)
  - 3. substitute the derivation (build or download)
- it would be great to be able to reuse
  - another user on same machine
  - another machine on the network
  - keep the same git repository (no redundant copies)
  - keep an already computed derivation (!!)
- the computation of a derivation could itself be a derivation
  - for now it's not possible (with guix daemon) to compute another derivation when computing a derivation
  - nix did that but it's very complicated
  - there could be a messy workaround?
- andy wingo is working on a new GC implementation that should be faster, but is at least 3-6 months away from first results
- trusted binary guix alternative?
  - best to improve derivations and solutions
- what if guix pull pulls a certain version instead of the latest git?
  - weird to make default
  - could be useful to add CLI option to make it easier to pull specific commit/tag/branch (not having to write a channel definition)
- guix package -A /package/ shows alternative version (architectures, ...) of packages. it does that quickly due to being loaded from a vectorized serialization containing only that information on packages