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
* <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
