Hi Denis, On sam., 16 mars 2024 at 02:03, Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> wrote:
> - First and most importantly, running 'guix pull' can fail sometimes, > especially if there is not enough RAM per core. A fix that work is to > lower the number of cores used with 'guix pull -c 1 -M 1' for > instance. > > But the issue is that I'm unsure how much RAM per core is needed. > Maybe 2GiB or 3GiB? Also if users have heavy desktop usage > (browser(s) with a ton of tabs open) could that value change? > > I could ask help from GNU Boot users for testing to find that value > but maybe the Guix community already knows more about this. > > The big downside of my approach here is that if for some reason the > script I made uses a 'memory per core' value that is too low, it > would probably makes things way more difficult for contributors than > having to read the Guix manual upfront in the first place, because it > would fail and they won't understand why. So they'd need to > understand both Guix, the code I wrote, and what caused the issue. > > - If Guix was already installed on a host distribution, I'm not sure > how to handle substitutes. Ideally I'd like to be able to enable them > just for GNU Boot and not change the way they are handled for other > Guix usage. Also if substitutes are not used it probably affect the > amount of RAM per core required. > > One way around here could be to build Guix ourselves and somehow find > a way to have different defaults, but building that Guix could > probably a long time. Well, from my understanding, with or without substitutes is the key here. Without substitutes, yeah we hit the Guile compilation boundaries, especially about RAM. With substitutes, the story is different. :-) The only operation that is expensive is: “Computing Guix derivation”. Then the rest is substitutable. Here, we could also speak network requirements but that’s another story. ;-) I have never measured the RAM requirement of this step. I would be surprised if it’s more than 2GiB… but who know! :-) Your users do not need to run a complete Guix but only something that can be determined beforehand and compliant with the rest of your project. Somehow, you have two choices: + Rely on substitutes from Guix project. The advantage is that you have nothing to do, just invoke the right command with your custom script. The main drawback is that your script is subject to Guix project policy when deleting substitutes. To my knowledge, this policy is clear but the effects are hard to predict. + Serve your own substitutes. The advantage is that you control which substitutes are available. The drawback is that you need to setup “guix publish”. Do not take me wrong about the substitutes. You only need the result of some derivations (see ’compile-guix’ procedure in (guix self) module); the ones that “guix pull” builds. Doing that, your script might pinpoint a specific Guix revision and you also serve the substitute requirements for that revision. Bah the first question is the RAM of “Computing Guix derivation”? Cheers, simon
