RE: London Guix meetup
Hi, I'm based in Manchester and would like to join but its mid week time not realistic for me. Next time lets group up in Manchester too! Thanks, Oleg
Re: Update on Parameterized Packages
Sarthak Shah writes: > Hello guix-devel! > > I got a bunch of really helpful suggestions from the last thread about my > Google Summer of Code project on bringing Package Parameterization to > Guix. > I've incorporated a lot of those suggestions and tried to address some of the > worries as I've been working on the project. > > Here is a new post covering the work that I've done in the past few weeks: > https://blog.lispy.tech/parameterized-packages-an-update.html > I would appreciate any questions, suggestions or comments! > > Cheers, > Sarthak. Looks very promising!
Re: Maybe a way to get a few more developpers to work on Guix ?
On 2023-06-24, Nicolas Graves via "Development of GNU Guix and the GNU System distribution." wrote: > On 2023-06-24 13:08, Csepp wrote: >> Nicolas Graves via "Development of GNU Guix and the GNU System >> distribution." writes: >> IMHO LLMs for Guix are so damn not worth the effort. It will not fix >> any of the actual issues with Guix, like the huge performance gap >> between it and traditional package managers. > > I've also opened another discussion on the subject on guix-devel > recently. Do you have any benchmark material to back this up? Well, I just ran "apt update" on Debian, and it took approximately 7 seconds, which was mostly spent downloading moderately sized files from Debian mirrors (~1MB). A corresponding "guix pull" took 299 seconds, downloading at least 8MB (from a quick eyeball calculation as guix does not summarize the results for me), and compiling all the various guix-*.drv that make up guix pull. The vast majority of the time was spent compiling derivations. This was also using a local copy of guix.git, so having to update guix.git over the network would take even longer... (and it did even spend a fair amount of time copying from the local guix.git on a fast NVMe device) Obviously, guix pull is doing a lot more, but it is ... doing a lot more! "apt install hello" (~2.3 seconds) and "guix install hello" (~1.5 seconds) were actually in a similar ballpark, which honestly surprised me. Guix is much faster with "guix remove hello" ... although arguably "guix remove hello && guix gc --delete $(guix build hello)" would be a more similar operation, and although I did not time it, it was reasonably fast, too. So, presuming substitutes are available, the main slowness with guix seems to be guix pull? I did not test "guix system reconfigure" ... but in a way, that may be a more real comparison than "guix install" ... although we are starting to get into fundemental differences between apt and guix here. The other big factor in my mind is that even with a single generation of guix with nothing for guix gc to do, there may be multiple copies of some libraries at various versions left around in the store, which is probably not terribly space efficient... there are usually reasons for this (e.g. bootstrapping from a tiny seed, yay!) but nevertheless, those reasons have some cost (and benefits!). live well, vagrant signature.asc Description: PGP signature
Re: Maybe a way to get a few more developpers to work on Guix ?
On 2023-06-24 13:08, Csepp wrote: > Nicolas Graves via "Development of GNU Guix and the GNU System distribution." > writes: > >> https://www.bpifrance.fr/nos-appels-a-projets-concours/appel-a-projets-communs-numeriques-pour-lintelligence-artificielle-generative >> >> Here's a call for proposal in French which could match a Guix project >> with a focus on code generation through LLMs. This could itself help >> Guix generate (and fix) package definitions. > > Mandatory reading for anyone interested in this: > https://limited.systems/articles/climate-cost-of-ai-revolution/ I fully agree on that as well. I don't think training a full-fetched LLM is nowhere worth it, but I've heard that just fine-tuning an open model with quantized weights might get the job done training and energy costs down to a few hundred bucks. > IMHO LLMs for Guix are so damn not worth the effort. It will not fix > any of the actual issues with Guix, like the huge performance gap > between it and traditional package managers. I've also opened another discussion on the subject on guix-devel recently. Do you have any benchmark material to back this up? -- Best regards, Nicolas Graves
Re: Maybe a way to get a few more developpers to work on Guix ?
Nicolas Graves via "Development of GNU Guix and the GNU System distribution." writes: > https://www.bpifrance.fr/nos-appels-a-projets-concours/appel-a-projets-communs-numeriques-pour-lintelligence-artificielle-generative > > Here's a call for proposal in French which could match a Guix project > with a focus on code generation through LLMs. This could itself help > Guix generate (and fix) package definitions. Mandatory reading for anyone interested in this: https://limited.systems/articles/climate-cost-of-ai-revolution/ IMHO LLMs for Guix are so damn not worth the effort. It will not fix any of the actual issues with Guix, like the huge performance gap between it and traditional package managers. But then again, wasteful software is the hot new trend thanks to AI and crptocurrencies, so what do I know. :)
Re: [bug#62047] [PATCH 0/2] '--with-input' & co. no longer replace hidden packages
Hi Greg, Greg Hogan writes: > This has broken, for example, building clang with a newer version of > gcc using package-input-rewriting/spec. What do you think of adding a > hidden? property to enable the old behavior? Since you're mentioning package-input-rewriting/spec, I assume you're doing this in Guile? If so, package-input-rewriting doesn't have that same behavior, and still replaces hidden packages! HTH, -- Josselin Poiret signature.asc Description: PGP signature
