Hello Ludo’, On Mon Feb 10, 2025 at 9:43 PM CET, Ludovic Courtès wrote: > Juliana Sims <j...@incana.org> skribis: >> For those not at Guix Days: >> >> We have split into groups discussing various topics. Each group is >> collecting notes on its discussion. I am starting this thread as a >> place for these notes, to be distributed as necessary. > > Great initiative. To those who took notes: please send them here.
I hope you won’t regret asking! 😁 So, after many weeks of procrastination, I eventually put some order into my notes. Please find them attached… and remember that they only represent my (poor) understanding of what was said during those meetings and do not engage the responsibility of the persons mentioned. Feel free to (heavily) edit them if you want to publish them. Thanks! -- Tanguy
--- when: 2025-01-31 14:45 who: - Andy - Ludo’ --- # `guix pull` is slow `pull` bootstraps a new Guix: - grabs a source store (depends on Git, no shallow clone, not shared across users) and compiles modules - calls a function to get the derivation of the new Guix - download substitutes Guile is not good for parallel computation. Lot of modules are loaded because modules are interdependent. The derivation computation time could only be improved 4 folds (+/-). We need to **profile** to understand **what** is the problem. The memory consumption of the linking should be improved. "Guix is the most important Guile user" Fixing `guix pull` would also improve the time-machine. The problem comes from the fact that we have a lot of packages. Only loading the `.go` files takes time and memory. Should we have a specific compiler for packages? A specific format? All packages in a single file?! Macros are not designed to be fast… because they where not created for that! Caching could help when using channels and only the channels change. `guix package -A` is faster than `guix search`. Going forward: - Noé volunteers to implement Julien’s idea about derivation caching. - Jelle looks into the time-machine caching. - Janneke looks into the package closure.
--- when: 2025-01-31 who: Efraim --- # Release Management - We should define what is the minimal number of assets to have for a release. Not everything needs to run. * Installer * Guix binary * main manual pointing to the release * … - It would be nice to have a Docker image, with an official Docker account. - It might be nice to have a torrent download. - How to make sure that the ungrafting is done **before** a release? - Guix package manager alone is a good entry point for new users, so the binary should be based on a recent commit. - We should replace `libgit` with `git` - Efraim is the only one doing the release… and volunteers to work on the next one.
--- when: 2025-01-31 11:50 --- "GNU is a project stewarded by the FSF, the line between the two is incredibly blurry!" 2 problems with GNU: - general: it’s a toxic place, because of some **very loud** people - personal: RMS Many GPLed project are **not** associated to GNU. The [GNU Assembly](https://gnu.tools/) tried: - to accept a code of conduct to become a welcoming/safe place - to change the top-down hierarchy (by RMS) … but it was rejected. We, Guix, have to clarify **our** social contract and the "oppose" it to the GNU organization to make them know why we would quit. Yes, we care about the GNU values **and** we care about those other values. Potential GCD: - Start from GNU.tool’s social contract, replace occurrences of GNU with Guix. - Replace all references to GNU "GNU: GNU is Not Unanimous" The installer with non-free Linux kernel could be the only piece of non-free software, to welcome people looking for freedom… while being pragmatic about their hardware.
--- when: 2025-01-30 14:35 who: Janneke --- # The Hurd Jan summarized the last year of the Hurd up to the Hurd (32bits) on bare metal (X60) and the Hurd aware installer. There’s an ongoing work to bring the Hurd to 64bits. It’s not trivial, but if Debian can do it… Jan filled out a grant proposal for that. We need GCC 14 for it to work, but it breaks backward compatibility and we don’t want GCC 14 and 11 in Guix. Work on migration to 14 has been started using `cross gcc`. The other attempts at installing the Hurd on bare metal, failed. Including my attempt on the X200. Nobody is trying to port to a new kernel any more. Quote from a anonymous participant: "even the Hurd on Mach is better than Linux!" Childhurds in the build farm crash, probably because of some filesystem issues. Ideas to move forwards: - open an internship or a summer of code? - look for students to do their master or thesis? - work on porting to Risc V? - drop 32bits support and aim at 64 only? - see if it fits the Spritely’s Plan9ification of Guix? - promote the killer features? (capabilities, translators) * write translators in Guile? * resurrect Ludo’s mbox/tar translator? - implement "throwable" childhurds to offload builds
