Many areas where you can help, with different time commitments and prerequisites: funding & spending, hardware hosting, system administration, and coding.
Video of the interview with #guix founder @civodul is available. A great chat about the #nix deployment model, his interested in #guile and #free software. Lots of interesting chat about motivation in #freesoftware, #gnu and #linux - as well as the Plan9-ification of Guix!!
In « Source Code Archiving to the Rescue of Reproducible Deployment » we describe the #GNU#Guix / @swheritage integration to ensure the reproducibility of scientific environments.
I wonder if there are any #guix maintainers willing to take a look at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70112 . I tried asking in #guix room few times, not much luck. There are already new versions available, and I would prefer not to rebase it (again), testing it is quite annoying due to differences between podman 4 and 5...
I ran an experiment yesterday, and found the package with the largest number of dependencies in #guix using this little command: guix package -A | awk '{print $1}' | parallel 'echo -n {}; echo -n " "; guix size {} 2>/dev/null | tail -n +3 | wc -l' | sort -n -k 2 | tee ~/Documents/sorted_packages.txt. The whole thing took 6 hours to run at about 90% CPU utilisation.
Result: pigx has the most dependencies at 968, with most of the runner ups being scientific analysis tools too. Cool!
I love how #guix allows you to inspect all of the dependencies of a package in detail. Running guix graph foo | xdot - on some package and combing through the massive dependency graph that results is fascinating, but also a little terrifying.
It's a wonder anything works at all.
@khleedril I’m afraid we can’t: sooner or later, the innermost ring starts depending on some outer ring (glibc depending on Python, librsvg on Rust, etc.), and you end up with a single ring.
Coming from Debian to Guix, having "everything" in a single repository is perhaps one of my favorite practical features.
Debian has no "central" location for VCS repositories, every single package defines a custom location, which could be entirely outside of Debian infrastructure, or no proper VCS at all!
Guix having everything in a monorepo enables searching for packages with "git grep" and also cargo-culting, er, borrowing from other packages much more easily.
Consider: #Guix / #Nix shared hosting where the cost of storing a store item is shared between the users that depend on it.
Maybe with the new Shepherd on Goblins integration a shared guix-daemon could work.
@csepp That is a cool idea. Maybe a step further - users of such a network could volunteer to build new packages. Because the focus is reproducible packages, peers do not even need to trust each other -- N>1 peers build the same package and get the same hash, it's good. It's like a distributed version of Cuirass, and then the nodes can also act as mini substitute servers like your idea.
A distributed ledger where package builds are the PoW? Maybe too ick for some but, possibly useful?
@shtwzrd Yeah, it definitely should not be turned into another cryptocurrency.
Spot-checking builds is a good idea though.
Offloading doesn't make sense in a shared hosting environment, since the provider already owns all the compute resources. But sharing compute costs for builds could work.
I've been trying to figure out how to do that though. Maybe bill users at the end of the month and divide the cost a build among the users who requested it.
@passthejoe I've tried using Guix a few times. It makes a lot of sense to me as a system you can spin up by specifying a few parameters in a deployment management script. It seems less suited for a personal desktop system that I'd work with daily.
Try #guix on Debian as a package manager: this will let you figure out if the packages you need are there.
I really like the shell feature of Guix: you can very easily deploy virtual environments for any language/tool--think of Docker without any of the complexities.
@chfkch@passthejoe@solene ethically I would only suggest nonguix in case of an emergency in order to get a working internet connection due to propietary firmware.
For everything else you can modify 'base-firmware' I think to purge down every other crap.
@mntmn, @daviwil
Do you guys see a way to have a reform next with #guix as pre-installed system? It would be awesome! But I wonder how is the #guix support on ARM... 🤔
Looking for some Friday #guix reading? How about the next step in the #packaging tutorial? Overview of the build-system concept, and how to provide arguments. We meet the #guile#scheme repl (guix repl) to discuss when to use 'quote' and 'quasiquote' in package definitions.
