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

Reply via email to