Hi Ludo, all, On Fri, 26 May 2023 at 18:05, Ludovic Courtès <l...@gnu.org> wrote:
> 2023-05-26 17:59:41 (75.0 MB/s) - ‘/dev/null’ saved [208615205/208615205] > 2023-05-26 18:01:16 (16.1 MB/s) - ‘/dev/null’ saved [208615205/208615205] > 2023-05-26 18:02:49 (5.88 MB/s) - ‘/dev/null’ saved [208615205/208615205] Arf, I understand why Guix is not frugal. ;-) In the worst case, considering you need all the 610MB of the closure, when you run “guix pull”, it’s less than 10 seconds. Using my network at home, the same is about 20 minutes. (And that leads to some vicious circles: because it needs some time and because I do not have the guarantee that the packages I need will build, so I run “guix pull” very barely on this laptop and thus it means the next “guix pull” will probably take longer. And I do not speak about other I/O bounds or CPU power. :-)) As I said elsewhere, Guix is becoming unusable for me with my 8 years laptop at home with some non-fiber network. Bah, an opportunity to turn off and do something else? ;-) And as I also said elsewhere, the ROADMAP for the next 10 years of Guix is to tackle all these inefficiencies – from suboptimal designs to specific optimizations. Well, I run Guix on the top of Debian on this laptop, and I do not experiment the same annoyances with APT, really not. The thread, How many bytes do we add (closure of guix) when adding one new package? Thu, 25 May 2023 20:24:30 +0200 id:87r0r4uv4x....@gmail.com https://yhetil.org/guix/87r0r4uv4x....@gmail.com is an attempt to discuss the suboptimality by design of “guix pull”. I do not have a clear idea of the solution, that’s why I have opened the discussion. :-) Another example is the “Git pulling twice” when installing, e.g., as pointed by Pierre in this thread: Install `guix pull'ed Guix to target partition on system install Sun, 20 Dec 2020 10:12:42 +0100 id:87ft403kol....@ambrevar.xyz https://yhetil.org/guix/87ft403kol....@ambrevar.xyz For sure, we need to make Guix do more with less resources. That’s the future. Cheers, simon