Packages grow, no longer fit on a 💾

Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hello!

Over the course of a few years, the size of our packages has apparently
kept growing.  Example:

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=v1.2.0 -- size emacs 
store item                                                       total    self
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
/gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
/gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
/gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
/gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
[…]
total: 859.7 MiB
$ guix time-machine --commit=v1.3.0 -- size emacs 
store item                                                       total    self
/gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
/gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
/gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
/gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
/gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
[…]
total: 880.5 MiB
$ guix time-machine --commit=v1.4.0 -- size emacs 
store item                                                       total    self
/gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
/gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
/gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
/gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
/gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
/gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
/gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
/gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
[…]
total: 1592.7 MiB
--8<---------------cut here---------------end--------------->8---

I think something went wrong here.  :-)

In particular with Emacs itself (due to JIT + dependency on libgccjit,
Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).

And then MESA and LLVM have always been problematically big.

We should do better.  I mean, it’s just a text editor, isn’t it?

Ludo’.

Re: Packages grow, no longer fit on a 💾

[kiasoc5]

On 1/14/23 17:07, Ludovic Courtès wrote:
> Hello!
> 
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs
> store item                                                       total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs
> store item                                                       total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs
> store item                                                       total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---------------cut here---------------end--------------->8---
> 
> I think something went wrong here.  :-)

Maybe it is Emacs itself growing over time.

> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).

If we look at emacs-next-pgtk, not only does it have JIT and PGTK, it 
also has xwidgets enabled, so it pulls in webkitgtk! Very big.

> And then MESA and LLVM have always been problematically big.
> 
> We should do better.  I mean, it’s just a text editor, isn’t it?
It's an Lisp machine with a text editor! :)

We could have variants for building with the athena/motif toolkit so 
that we don't use GTK.

Re: Packages grow, no longer fit on a 💾

[Liliana Marie Prikler]

Am Samstag, dem 14.01.2023 um 23:07 +0100 schrieb Ludovic Courtès:
> Hello!
> 
> Over the course of a few years, the size of our packages has
> apparently kept growing.  Example:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item                                                      
> total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0           
> 210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7           
> 369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1            
> 859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2           
> 132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20          
> 723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1            
> 110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31             
> 38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item                                                      
> total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0           
> 220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4           
> 389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2            
> 880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2           
> 132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24          
> 744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1            
> 110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31             
> 38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item                                                      
> total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2           
> 1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8           
> 411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0           
> 221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0      
> 244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0         
> 261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0           
> 147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37         
> 126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7           
> 129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30         
> 1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-
> 9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1            
> 110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33             
> 76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---------------cut here---------------end--------------->8---
> 
> I think something went wrong here.  :-)
> 
> In particular with Emacs itself (due to JIT + dependency on
> libgccjit, Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
The effect is even more pronounced with emacs-minimal, as it
gratuitously pulls in libgccjit and binutils.  Compare

/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5  27.2%
/gnu/store/wrzjr2g38f23fqg09rrdcn10va5gc5xl-emacs-minimal-28.2     472.4   110.7  23.4%
/gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4  11.5%
/gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   7.8%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33              38.3    36.6   7.7%
/gnu/store/6d0pl5khj08j3c2619jnypc8bznspgx8-gcc-10.3.0-lib          71.7    33.4   7.1%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib          71.7    33.4   7.1%
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32          91.6    16.4   3.5%
/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619    77.6     5.9   1.3%
/gnu/store/pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0              78.4     4.0   0.9%
/gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23                77.3     2.9   0.6%
/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1               74.4     2.7   0.6%
/gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.8        1.7     1.7   0.4%
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8        1.7     1.7   0.4%
/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8      39.3     1.0   0.2%
/gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.6                73.5     0.8   0.2%
/gnu/store/ba02g5xkqiss6s5z8mbj9cvkal6l7b9g-mpc-1.2.1               78.8     0.4   0.1%
/gnu/store/a38k2v29l6l0iz6pmlk4dmzwdbvl10lq-acl-2.3.1               72.3     0.3   0.1%
/gnu/store/a7ggx0af69gv4k5mr1k617p4vy9kgx2v-libcap-2.62             72.0     0.3   0.1%
/gnu/store/jkjs0inmzhj4vsvclbf08nmh0shm7lrf-attr-2.5.1              71.9     0.2   0.1%
/gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11             71.9     0.2   0.0%
/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10               73.7     0.2   0.0%
Gesamt: 472.4 MiB

and

/gnu/store/7j9jvig1m10zxlhag87fjlmygk5wd779-emacs-minimal-27.2     183.1   105.2  57.4%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7  20.1%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6  17.8%
/gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2             76.9     5.9   3.2%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16       1.6     1.6   0.9%
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16     39.4     1.0   0.6%
Gesamt: 183.1 MiB

This should probably be rectified by removing said inputs from emacs-
minimal, as they aren't actually used.

> And then MESA and LLVM have always been problematically big.
> 
> We should do better.  I mean, it’s just a text editor, isn’t it?
Well, gedit is also "just an editor" which weighs 1GB (compared to
880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think we
ought to look into duplicate references being kept (glibc, gcc), but we
can't really work against packages including more inputs without
reducing their feature set – in some cases we could try alternatives
like mozjs vs. duktape for polkit.

Cheers

Re: Packages grow, no longer fit on a 💾

[Maxim Cournoyer]

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

>> We should do better.  I mean, it’s just a text editor, isn’t it?
> Well, gedit is also "just an editor" which weighs 1GB (compared to
> 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think we
> ought to look into duplicate references being kept (glibc, gcc), but we
> can't really work against packages including more inputs without
> reducing their feature set – in some cases we could try alternatives
> like mozjs vs. duktape for polkit.

mozjs is already using duktape by default on core-updates, so that
particular one is solved.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 💾

[Liliana Marie Prikler]

Am Sonntag, dem 15.01.2023 um 21:09 -0500 schrieb Maxim Cournoyer:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> [...]
> 
> > > We should do better.  I mean, it’s just a text editor, isn’t it?
> > Well, gedit is also "just an editor" which weighs 1GB (compared to
> > 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think
> > we ought to look into duplicate references being kept (glibc, gcc),
> > but we can't really work against packages including more inputs
> > without reducing their feature set – in some cases we could try
> > alternatives like mozjs vs. duktape for polkit.
> 
> mozjs is already using duktape by default on core-updates, so that
> particular one is solved.
s/mozjs/polkit/, right?

Re: Packages grow, no longer fit on a 💾

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Sonntag, dem 15.01.2023 um 21:09 -0500 schrieb Maxim Cournoyer:
>> Hi,
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> [...]
>> 
>> > > We should do better.  I mean, it’s just a text editor, isn’t it?
>> > Well, gedit is also "just an editor" which weighs 1GB (compared to
>> > 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think
>> > we ought to look into duplicate references being kept (glibc, gcc),
>> > but we can't really work against packages including more inputs
>> > without reducing their feature set – in some cases we could try
>> > alternatives like mozjs vs. duktape for polkit.
>> 
>> mozjs is already using duktape by default on core-updates, so that
>> particular one is solved.
> s/mozjs/polkit/, right?

Indeed.  See commit e8f4e1808563eb3c1cd28d419a1f349412af4a0d for the
change.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> [polkit] is already using duktape by default on core-updates, so that
> particular one is solved.

That’s a much welcome improvement!

--8<---------------cut here---------------start------------->8---
$ guix size mozjs | tail -1
total: 264.8 MiB
ludo@ribbon ~/src/guix [env]$ guix size duktape | tail -1
total: 72.4 MiB
--8<---------------cut here---------------end--------------->8---

Ludo’.

Re: Packages grow, no longer fit on a 💾

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3853 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:

Unless the right steps are taken at right time, the size of packages
will reach the largest real number in near future.

>
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
>
> I think something went wrong here.  :-)
>
> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>
> And then MESA and LLVM have always been problematically big.
>
> We should do better.  I mean, it’s just a text editor, isn’t it?
>
> Ludo’.
>

No, Emacs is more than a text editor.
If you need just a text editor, use ED.  ;)
But, well, I must confess, native compilation takes *A LOT* of time.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packages grow, no longer fit on a 💾

[pelzflorian (Florian Pelz)]

Hello all.

Ludovic Courtès <ludo@gnu.org> writes:
> Over the course of a few years, the size of our packages has apparently
> kept growing.

Disregarding dependencies, most store items got slightly bigger.  This
is what I wrote at bug#58760 “Guix System iso too big for cdrom again”
<https://issues.guix.gnu.org/58760>:

> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more. I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f […]).
> The result is that most packages got slightly bigger and this broke
> the camel’s back.

Regards,
Florian

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>> Over the course of a few years, the size of our packages has apparently
>> kept growing.
>
> Disregarding dependencies, most store items got slightly bigger.  This
> is what I wrote at bug#58760 “Guix System iso too big for cdrom again”
> <https://issues.guix.gnu.org/58760>:
>
>> it was possible to burn the Guix System install image to a 700MB CD.
>> But it fits no more. I compared using the du tool (comparison between
>> good old Guix version e427593 and bad new Guix version 3734857f […]).
>> The result is that most packages got slightly bigger and this broke
>> the camel’s back.

There are slight increases of each and every package, and there are also
new big dependencies being pulled in for what, from a distance, doesn’t
really add functionality.

Examples include libgccjit in Emacs and mozjs in polkit.

In a way, that’s the “unavoidable” (?) evolution of software, and the
problem extends largely beyond Guix.

Still, even compared to contemporary distros, we’re doing pretty bad.
Debian most likely does better, and people often cite Alpine as the
distro providing the smallest packages.  Do we have figures?  What can
we learn from them?  What tradeoffs to they make?

I think package size is something we should work on.  I don’t feel good
knowing that ‘bare-bones.tmpl’ yields an OS that’s “equivalent” to
Debian from 20 years ago, yet consumes close to 1 GiB.

Thanks,
Ludo’.

Re: Packages grow, no longer fit on a 💾

[zimoun]

Hi,

On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès <ludo@gnu.org> wrote:

> Examples include libgccjit in Emacs and mozjs in polkit.

Do I miss a point?  How is it possible to have native compilation for
Emacs without libgccjit?

For emacs-minimal, if considered to only bytecompile (.elc) and not
native compile, this libgccgit seems unexpected, indeed.  Well, is
native compilation disabled for emacs-minimal?  I guess not. :-)


> Still, even compared to contemporary distros, we’re doing pretty bad.
> Debian most likely does better, and people often cite Alpine as the
> distro providing the smallest packages.  Do we have figures?  What can
> we learn from them?  What tradeoffs to they make?

I agree we need to improve.  However, I would like to mitigate. :-)

Functional and closure makes apparent what is hard to evaluate on
“contemporary distros”.  I would be curious to know the transitive
closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
which is roughly the equivalent of the Guix package ’emacs’.

Because if you dig a bit [2], for instance it depends on ’libgccjit0’.

If you consider Alpine Linux and give a look at the dependency of the
equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.

These “contemporary distros” rely on version resolver which somehow
hides the costs; when these costs are clearly popping with Guix.

For sure, we need to improve because Docker pack produced by Guix are
really more fat compared to the ones available around and usually
produced with distros as Alpine.

1: <https://packages.debian.org/bookworm/emacs>
2: <https://packages.debian.org/bookworm/emacs-gtk>
3: <https://pkgs.alpinelinux.org/package/edge/community/x86/emacs-gtk3-nativecomp>

Cheers,
simon

Re: Packages grow, no longer fit on a 💾

[zimoun]

On Wed, 18 Jan 2023 at 00:05, zimoun <zimon.toutoune@gmail.com> wrote:

> For emacs-minimal, if considered to only bytecompile (.elc) and not
> native compile, this libgccgit seems unexpected, indeed.  Well, is
> native compilation disabled for emacs-minimal?  I guess not. :-)

The package emacs-minimal is only for bytecompiling and configured
without native compilation, IIUC.  Thus the reference to libgccgit
appears unexpected, then tackled by Josselin and fixed by Liliana in
#60831 [1].

Cool! :-)

1: <http://issues.guix.gnu.org/msgid/f8e96b5d959815f77501beadeaca9139b3fb2d11.camel@gmail.com>


Cheers,
simon

Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾)

[Liliana Marie Prikler]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Am Mittwoch, dem 18.01.2023 um 00:49 +0100 schrieb zimoun:
> 
> On Wed, 18 Jan 2023 at 00:05, zimoun <zimon.toutoune@gmail.com>
> wrote:
> 
> > For emacs-minimal, if considered to only bytecompile (.elc) and not
> > native compile, this libgccgit seems unexpected, indeed.  Well, is
> > native compilation disabled for emacs-minimal?  I guess not. :-)
> 
> The package emacs-minimal is only for bytecompiling and configured
> without native compilation, IIUC.  Thus the reference to libgccgit
> appears unexpected, then tackled by Josselin and fixed by Liliana in
> #60831 [1].
For context, emacs uses a hash digest to more or less uniquely
fingerprint the version (much like guix does), so natively compiling
things with emacs-minimal won't speed up your packages when using emacs
or emacs-next and is thus next to pointless.

I witnessed the same type of bug in wpewebkit, which pulls in the much
larger webkitgtk, probably because the former uses #$output rather than
(assoc-ref outputs "out") in one of its phases – see the attached patch
for my proposed fix.  Note, I'm saying probably, because the build
still runs, but the fact that it started without first running the
webkitgtk build gives me hope that my assumption is correct.  Still
takes ages and huge amounts of RAM tho.

If my hunch is correct, this has some further reaching implications. 
It means, that uses of #$output and #$(this-package-input) – which we
want to promote instead of labels – draw in additional inputs when
combined with inheritance, which in the context of this thread I hope
we can all agree is not good.

So, any ideas on how to tackle this? :)

[-- Attachment #2: 0001-gnu-webkitgtk-Resolve-outputs-at-build-time.patch --]
[-- Type: text/x-patch, Size: 1348 bytes --]

From 7ca54244c2437baf81016eaccb2f175ad9aa4a3b Mon Sep 17 00:00:00 2001
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
Date: Wed, 18 Jan 2023 18:51:18 +0100
Subject: [PATCH] gnu: webkitgtk: Resolve outputs at build time.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/webkit.scm (webkitgtk)[#:phases]<move-doc-files>: Use outputs’
instead of ungexping output.
---
 gnu/packages/webkit.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/webkit.scm b/gnu/packages/webkit.scm
index 35fb5926a3..918fdfb1ab 100644
--- a/gnu/packages/webkit.scm
+++ b/gnu/packages/webkit.scm
@@ -209,9 +209,10 @@ (define-public webkitgtk
                           "FALSE"))))))
           (add-after 'install 'move-doc-files
             (lambda* (#:key outputs #:allow-other-keys)
-              (let ((doc (assoc-ref outputs "doc")))
+              (let ((out (assoc-ref outputs "out"))
+                    (doc (assoc-ref outputs "doc")))
                 (mkdir-p (string-append doc "/share"))
-                (rename-file (string-append #$output "/share/gtk-doc")
+                (rename-file (string-append out "/share/gtk-doc")
                              (string-append doc "/share/gtk-doc"))))))))
     (native-inputs
      (list bison
-- 
2.38.1

Re: Grandfathering store paths considered harmful

[Ludovic Courtès]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> For context, emacs uses a hash digest to more or less uniquely
> fingerprint the version (much like guix does), so natively compiling
> things with emacs-minimal won't speed up your packages when using emacs
> or emacs-next and is thus next to pointless.

If emacs-minimal lacks JIT support anyway, there’s nothing it can
compile?  Or am I missing something?

(It’s called “JIT” but we keep talking about things that need to be done
ahead-of-time, this is confusing.  :-))

> I witnessed the same type of bug in wpewebkit, which pulls in the much
> larger webkitgtk, probably because the former uses #$output rather than
> (assoc-ref outputs "out") in one of its phases – see the attached patch
> for my proposed fix.

I believe the attached patch has no effect.  #$output expands to (getenv
"out"), where "out" is an automatic environment variable of the
derivation.

> If my hunch is correct, this has some further reaching implications. 
> It means, that uses of #$output and #$(this-package-input) – which we
> want to promote instead of labels – draw in additional inputs when
> combined with inheritance, which in the context of this thread I hope
> we can all agree is not good.

‘this-package-input’ is different from #$output because it’s a purely
host-side feature.  It refers to inputs of the package in which it
appears; thus, if you define a package B that inherits from A, and the
‘arguments’ of A contain (this-package-input "whatever"), that is fine:
B’s ‘arguments’ will refer to its own “whatever”¹.

Now, independent of that, it’s easy to make mistakes when using
inheritance heavily.  The only good solution to that IMO is to avoid
factorizing too much.  That is, in some cases, it may be more robust to
be explicit in inherited packages—e.g., explicitly providing ‘inputs’
and ‘arguments’ fields—than to inherit all the fields from some distant
parent package.

I hope that makes sense!

Ludo’.

¹ See the bit about self-referential records in
  <https://guix.gnu.org/en/blog/2021/the-big-change/>.

Re: Grandfathering store paths considered harmful

[Liliana Marie Prikler]

Am Donnerstag, dem 19.01.2023 um 15:28 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> 
> > For context, emacs uses a hash digest to more or less uniquely
> > fingerprint the version (much like guix does), so natively
> > compiling things with emacs-minimal won't speed up your packages
> > when using emacs or emacs-next and is thus next to pointless.
> 
> If emacs-minimal lacks JIT support anyway, there’s nothing it can
> compile?  Or am I missing something?
> 
> (It’s called “JIT” but we keep talking about things that need to be
> done ahead-of-time, this is confusing.  :-))
You can still do bytecode compilation, but no native code compilation.
And yes, the JIT vs. AOT distinction in Emacs is very annoying. 
Basically, we want to compile packages to native code ahead of time
using libgccjit baked into Emacs.

> > I witnessed the same type of bug in wpewebkit, which pulls in the
> > much larger webkitgtk, probably because the former uses #$output
> > rather than (assoc-ref outputs "out") in one of its phases – see
> > the attached patch for my proposed fix.
> 
> I believe the attached patch has no effect.  #$output expands to
> (getenv "out"), where "out" is an automatic environment variable of
> the derivation.
Hmm, you're right, turns out I was mistaken.  

> > If my hunch is correct, this has some further reaching
> > implications.  It means, that uses of #$output and #$(this-package-
> > input) – which we want to promote instead of labels – draw in
> > additional inputs when combined with inheritance, which in the
> > context of this thread I hope we can all agree is not good.
> 
> ‘this-package-input’ is different from #$output because it’s a purely
> host-side feature.  It refers to inputs of the package in which it
> appears; thus, if you define a package B that inherits from A, and
> the ‘arguments’ of A contain (this-package-input "whatever"), that is
> fine: B’s ‘arguments’ will refer to its own “whatever”¹.
This doesn't appear to always work, though, see bug#60831.  emacs-
minimal should really have raised an error due to missing libgccjit,
but didn't.

> Now, independent of that, it’s easy to make mistakes when using
> inheritance heavily.  The only good solution to that IMO is to avoid
> factorizing too much.  That is, in some cases, it may be more robust
> to be explicit in inherited packages—e.g., explicitly providing
> ‘inputs’ and ‘arguments’ fields—than to inherit all the fields from
> some distant parent package.
That does defeat the purposes of inheritance however.  Plus note, how
our inheritance trees are usually rather small, with one or two levels
at most.  (But of course it also affects the big compiler bootstraps
with 50 levels.)


Cheers

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Examples include libgccjit in Emacs and mozjs in polkit.
>
> Do I miss a point?  How is it possible to have native compilation for
> Emacs without libgccjit?

I wrote:

> there are also new big dependencies being pulled in for what, from a
> distance, doesn’t really add functionality.

To me, Emacs is still Emacs, with or without libgccjit.  Of course JIT
is an improvement, I don’t deny that, but what I mean is that I still
use Emacs for the very same activities.  This is even more true for
polkit, because I don’t interact directly with it.

> For emacs-minimal, if considered to only bytecompile (.elc) and not
> native compile, this libgccgit seems unexpected, indeed.  Well, is
> native compilation disabled for emacs-minimal?  I guess not. :-)

It should probably be disabled, yes.

>> Still, even compared to contemporary distros, we’re doing pretty bad.
>> Debian most likely does better, and people often cite Alpine as the
>> distro providing the smallest packages.  Do we have figures?  What can
>> we learn from them?  What tradeoffs to they make?
>
> I agree we need to improve.  However, I would like to mitigate. :-)
>
> Functional and closure makes apparent what is hard to evaluate on
> “contemporary distros”.  I would be curious to know the transitive
> closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
> which is roughly the equivalent of the Guix package ’emacs’.

Yes, that’s the kind of figures we need.

> Because if you dig a bit [2], for instance it depends on ’libgccjit0’.
>
> If you consider Alpine Linux and give a look at the dependency of the
> equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.
>
> These “contemporary distros” rely on version resolver which somehow
> hides the costs; when these costs are clearly popping with Guix.
>
> For sure, we need to improve because Docker pack produced by Guix are
> really more fat compared to the ones available around and usually
> produced with distros as Alpine.

Right, and reportedly, Alpine-based images for things like Python are
smaller than what we do.  There’s no cheating here: images are
self-contained.

Maybe a good topic for a sub-group at the Guix Days?  :-)

Ludo’.

Re: Packages grow, no longer fit on a 💾

[Simon Tournier]

Hi Ludo,

On jeu., 19 janv. 2023 at 15:14, Ludovic Courtès <ludo@gnu.org> wrote:

> To me, Emacs is still Emacs, with or without libgccjit.  Of course JIT
> is an improvement, I don’t deny that, but what I mean is that I still
> use Emacs for the very same activities.  This is even more true for
> polkit, because I don’t interact directly with it.

Yeah, there is a trade-off for the maintenance between packages that the
most of us want and specialized packages for user’s own needs.

This reminds me past discussions about parameterized packages. ;-)

Well, for instance the scientific package ’gmsh’ is built full featured
– with GUI using ’fltk’.  That’s a feature that requires big
dependencies; when I mainly use it without GUI.

Another example, git-annex is built full featured – able to run the
WebApp for instance.  That’s a feature that requires a increase of 5%;
when I mainly use a very restricted set of Git-Annex features.

Another instance, the closure of Guix increases a lot from 1.2 to 1.4.
Of course the new version provides many improvements, I do not deny
that, but I still use Guix for the very same activities as I am doing
since version 1.2. ;-)

The tacit policy with Guix packages is that the packages are usually by
default “feature maximalist” or specifically named « <foo>-minimal » …

> Right, and reportedly, Alpine-based images for things like Python are
> smaller than what we do.  There’s no cheating here: images are
> self-contained.

…contrary to Alpine where the packages are usually by default “feature
minimalist” or specifically named « <foo>-<with-feature> ».

Consider the package Emacs [1] and give a look at the recipe for the
package named ’emacs’ [2].  Well, this Alpine package ’emacs’ looks like
the Guix package named ’emacs-minimal’, and then Alpine provides these
variants (subpackages):

    emacs-doc
    emacs-gtk3
    emacs-gtk3-nativecomp
    emacs-nox
    emacs-x11
    emacs-x11-nativecomp

1: <https://pkgs.alpinelinux.org/package/edge/community/x86/emacs>
2: <https://git.alpinelinux.org/aports/tree/community/emacs/APKBUILD>

> Maybe a good topic for a sub-group at the Guix Days?  :-)

Yeah for sure. :-) Although, from my point of view, the main issue is
about a policy for package inclusion; I mean there is no secret: light
images means images with less features. :-)

My personal and biased opinion is that Guix should follow minimalist
packages as default packages and provides more variants.  But the
maintenance cost is not free, IMHO. :-)

Cheers,
simon

Re: Packages grow, no longer fit on a 💾

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> Yeah for sure. :-) Although, from my point of view, the main issue is
> about a policy for package inclusion; I mean there is no secret: light
> images means images with less features. :-)
>
> My personal and biased opinion is that Guix should follow minimalist
> packages as default packages and provides more variants.  But the
> maintenance cost is not free, IMHO. :-)

My personal take on this would be to start with fixing *bugs* like
#25235 (Wrapped python programs get native-inputs in PYTHONPATH) that
surely contributes to larger graphs, pulling purely build time
dependencies in the graph (there's a fix proposed in the same thread).
This one is for Python, but the same must apply to other scripting
languages that rely on wrap phases.  The pulling of large debug outputs
just to graft locally is also annoying, but that wouldn't end up in the
image produced, right?

I don't think deduplication is turned on for all the images produced by
guix pack such as Docker, which would mean grafts have a heavy cost
there.

Other idea: move the static libraries detected to a static output
automatically when a "static" output is declared, else remove them, in
the gnu-build-system standard phases.

While I agree we can do better, in general I don't think we can compete
with Alpine, which appears to aim for minimalism at the expense of
features.  I don't think GNU Guix is about that kind of minimalism; it
aims to empower its users through full-featured and well documented
packages.  I also think it's nice to ship at least the info/man pages
documentation in the main output in general, even if it makes our
packages slightly larger than on Alpine, and stripping include files in
a different output seems a pain to deal with, from a user perspective.

I guess what I'm saying is that there seems to be larger and lower
hanging fruits to collect before we start micro-managing package
outputs.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 💾

[kiasoc5]

On 1/17/23 11:25, Ludovic Courtès wrote:
>
> There are slight increases of each and every package, and there are also
> new big dependencies being pulled in for what, from a distance, doesn’t
> really add functionality.
> 
> Examples include libgccjit in Emacs and mozjs in polkit.
> 
> In a way, that’s the “unavoidable” (?) evolution of software, and the
> problem extends largely beyond Guix.
> 
> Still, even compared to contemporary distros, we’re doing pretty bad.
> Debian most likely does better, and people often cite Alpine as the
> distro providing the smallest packages.  Do we have figures?  What can
> we learn from them?  What tradeoffs to they make?

We can achieve smaller packages by splitting them more. Here is my guess 
of the amount of package splitting by some distros, from least to most:

Slackware < Arch < Fedora < Debian < Alpine

- Slackware I believe does not split anything, everything is included.
- Arch splits packages on a case by case basis (QEMU for example)
- Fedora typically splits packages into package X and package X-devel, 
where X contains development headers, but usually not more.
- Debian splits packages more aggressively. For example libreoffice is 
split into 6 packages, 1 for each suite (draw, write, etc). And programs 
may be separated from their outputs (eg zstd and libzstd are split)
- Alpine splits even more aggressively, they also split out man pages 
and shell completions.

We may wish to utilize multiple package outputs to a greater extent. 
Some Guix packages already have bin, doc, and lib outputs. We could make 
it a policy to split this for all packages.

I also wonder how much of the space is taken by debug output. Would 
making graft derivations substitutable help?

https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html

Re: Packages grow, no longer fit on a 💾

[indieterminacy]

On 18-01-2023 03:41, kiasoc5 wrote:
> On 1/17/23 11:25, Ludovic Courtès wrote:
>> 
>> There are slight increases of each and every package, and there are 
>> also
>> new big dependencies being pulled in for what, from a distance, 
>> doesn’t
>> really add functionality.
>> 
>> Examples include libgccjit in Emacs and mozjs in polkit.
>> 
>> In a way, that’s the “unavoidable” (?) evolution of software, and the
>> problem extends largely beyond Guix.
>> 
>> Still, even compared to contemporary distros, we’re doing pretty bad.
>> Debian most likely does better, and people often cite Alpine as the
>> distro providing the smallest packages.  Do we have figures?  What can
>> we learn from them?  What tradeoffs to they make?
> 
> We can achieve smaller packages by splitting them more. Here is my 
> guess of the amount of package splitting by some distros, from least to 
> most:
> 
> Slackware < Arch < Fedora < Debian < Alpine
> 
> - Slackware I believe does not split anything, everything is included.
> - Arch splits packages on a case by case basis (QEMU for example)
> - Fedora typically splits packages into package X and package X-devel, 
> where X contains development headers, but usually not more.
> - Debian splits packages more aggressively. For example libreoffice is 
> split into 6 packages, 1 for each suite (draw, write, etc). And 
> programs may be separated from their outputs (eg zstd and libzstd are 
> split)
> - Alpine splits even more aggressively, they also split out man pages 
> and shell completions.
> 
> We may wish to utilize multiple package outputs to a greater extent. 
> Some Guix packages already have bin, doc, and lib outputs. We could 
> make it a policy to split this for all packages.
> 
> I also wonder how much of the space is taken by debug output. Would 
> making graft derivations substitutable help?
> 
> https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html

I think Guix is missing a trick here.

All this effort to chain everything with inputs and yet we are using 
conventional 'package-boxes'.

Why not 'Dutch Auction' it and set a maximum amount of inheritants 
within one package file and then iteratively lower the threshhold (over 
time!) until there are noises in the guix-devel ML
that this principal is being taken far.

The outcome could allow more of a layers and multifaceted representation 
of tools and applications that give more of a distinction between lower 
level utilities and applications.


-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hi,

kiasoc5 <kiasoc5@disroot.org> skribis:

> We may wish to utilize multiple package outputs to a greater
> extent. Some Guix packages already have bin, doc, and lib outputs. We
> could make it a policy to split this for all packages.

There’s some a policy already, though maybe not universally followed;
see point 8 at
<https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html>.

> I also wonder how much of the space is taken by debug output. Would
> making graft derivations substitutable help?

Graft derivations are not substitutable because it’s usually faster to
“build” them locally than to download them (it depends on package size,
hard disk performance, and network performance; my experience with an
SSD is that grafting is always faster than downloading, even over FTTH.)

Ludo’.

Re: Packages grow, no longer fit on a 💾

[Simon Tournier]

Hi,

On jeu., 19 janv. 2023 at 15:32, Ludovic Courtès <ludo@gnu.org> wrote:

>> I also wonder how much of the space is taken by debug output. Would
>> making graft derivations substitutable help?
>
> Graft derivations are not substitutable because it’s usually faster to
> “build” them locally than to download them (it depends on package size,
> hard disk performance, and network performance; my experience with an
> SSD is that grafting is always faster than downloading, even over FTTH.)

Recently, I built a large profile with oulà many many grafts and my
machine spent some time for that.

Would it be possible to substitute the result after applying grafts?


Cheers,
simon

Re: Packages grow, no longer fit on a 💾

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 6536 bytes --]

On Sat, Jan 14, 2023 at 11:07:23PM +0100, Ludovic Courtès wrote:
> Hello!
> 
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item                                                       total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---------------cut here---------------end--------------->8---
> 
> I think something went wrong here.  :-)
> 
> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
> 
> And then MESA and LLVM have always been problematically big.
> 
> We should do better.  I mean, it’s just a text editor, isn’t it?

I've made some progress on LLVM and I think I have a working LLVM that
can be used as an input for mesa.

(ins)efraim@3900XT ~$ du -sch /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
3.9M    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
8.0K    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
21M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
67M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
16K     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
92M     total

(define llvm-for-mesa
  (package/inherit llvm-11
    ;; If we can separate out the include directory we'd save another 21MB.
    (outputs (list "out"))
    (arguments
     (substitute-keyword-arguments (package-arguments llvm-11)
       ((#:configure-flags cf ''())
        ;; AMDGPU is needed by the vulkan drivers.
        `(list ,(string-append "-DLLVM_TARGETS_TO_BUILD="
                                (system->llvm-target) ";AMDGPU")
               "-DLLVM_BUILD_TOOLS=NO"
               "-DLLVM_BUILD_LLVM_DYLIB=YES"
               "-DLLVM_LINK_LLVM_DYLIB=YES"))
       ((#:phases phases)
        `(modify-phases ,phases
           (add-after 'install 'delete-static-libraries
             (lambda* (#:key outputs #:allow-other-keys)
               (for-each delete-file
                         (find-files (string-append
                                       (assoc-ref outputs "out") "/lib")
                                     "\\.a$"))))
           (replace 'install-opt-viewer
             (lambda* (#:key outputs #:allow-other-keys)
               (let ((out (assoc-ref outputs "out")))
                 (delete-file-recursively
                   (string-append out "/share/opt-viewer")))))
           (add-after 'install 'build-and-install-llvm-config
             (lambda* (#:key outputs #:allow-other-keys)
               (let ((out (assoc-ref outputs "out")))
                 (substitute*
                   "tools/llvm-config/CMakeFiles/llvm-config.dir/link.txt"
                   (("/tmp/guix-build-llvm-11.0.0.drv-0/build/lib")
                    (string-append out "/lib")))
                 (invoke "make" "llvm-config")
                 (install-file "bin/llvm-config"
                               (string-append out "/bin")))))))))))

In addition to what I have below I found that nix has a patch to make
llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
the include directory to another output, saving another 21MB, bringing
llvm-for-mesa down to 71MB. Another possibility would be to have
llvm-for-mesa use llvm as an input, and then to use some configure-flags
to tell llvm-for-mesa to use the includes from llvm (the input).


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

> I've made some progress on LLVM and I think I have a working LLVM that
> can be used as an input for mesa.
>
> (ins)efraim@3900XT ~$ du -sch /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
> 3.9M    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
> 8.0K    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
> 21M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
> 67M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
> 16K     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
> 92M     total
>
> (define llvm-for-mesa
>   (package/inherit llvm-11

Yay, great news!  Let’s have that in ‘core-updates’.

> In addition to what I have below I found that nix has a patch to make
> llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
> the include directory to another output, saving another 21MB, bringing
> llvm-for-mesa down to 71MB. Another possibility would be to have
> llvm-for-mesa use llvm as an input, and then to use some configure-flags
> to tell llvm-for-mesa to use the includes from llvm (the input).

Good.  We can make these changes incrementally, but having
‘llvm-for-mesa’ would already be a noticeable improvement.

Thanks!

Ludo’.

Re: Packages grow, no longer fit on a 💾

[John Kehayias]

Hi all,

On Tue, Jan 17, 2023 at 05:18 PM, Ludovic Courtès wrote:

> Hi,
>
> Efraim Flashner <efraim@flashner.co.il> skribis:
>
>> I've made some progress on LLVM and I think I have a working LLVM that
>> can be used as an input for mesa.
>>
>> (ins)efraim@3900XT ~$ du -sch /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
>> 3.9M    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
>> 8.0K    /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
>> 21M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
>> 67M     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
>> 16K     /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
>> 92M     total
>>
>> (define llvm-for-mesa
>>   (package/inherit llvm-11
>
> Yay, great news!  Let’s have that in ‘core-updates’.
>

Yes, very nice!

A note that after some debugging that latest mesa (22.2.3 as of today, to be updated on
core-updates) seems to want newer LLVM, namely llvm-15. Fortunately we have this LLVM
version thanks to other's hard work on this front.

I don't think there were any errors in building mesa with older LLVM, but on current
hardware (unfortunately brings in non-free considerations) this was necessary. I believe
this is the summary: <https://www.phoronix.com/news/LLVM-15-Branched>

Props to katco on IRC for going through some long building and debugging to track this
down. The end result is that mesa 22.2.x with llvm-15 gave proper support for current gen
hardware, both parts (and current kernel) being needed.

So, I'd vote for having llvm-for-mesa to be at the latest LLVM version as well as Mesa. As
per the discussion on another thread, this could make sense for a feature branch and to
get thorough testing. Seeing as how LLVM seems pretty core to what Mesa does these days, I
would feel better having that tested across different hardware and use cases. Again, I
think a singular feature branch works well for this and I'm happy to help out on that
front. But I'll leave those discussions to the other thread.

>> In addition to what I have below I found that nix has a patch to make
>> llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
>> the include directory to another output, saving another 21MB, bringing
>> llvm-for-mesa down to 71MB. Another possibility would be to have
>> llvm-for-mesa use llvm as an input, and then to use some configure-flags
>> to tell llvm-for-mesa to use the includes from llvm (the input).
>
> Good.  We can make these changes incrementally, but having
> ‘llvm-for-mesa’ would already be a noticeable improvement.
>
> Thanks!
>
> Ludo’.

Thanks all, I'm here for smaller closures!
John

Re: Packages grow, no longer fit on a 💾

[Katherine Cox-Buday]

John Kehayias <john.kehayias@protonmail.com> writes:

>>> Efraim Flashner <efraim@flashner.co.il> skribis:
>>>
>>> I've made some progress on LLVM and I think I have a working LLVM
>>> that can be used as an input for mesa.

This is awesome! Thank you Efraim!

> I don't think there were any errors in building mesa with older LLVM,
> but on current hardware (unfortunately brings in non-free
> considerations) this was necessary. I believe this is the summary:
> <https://www.phoronix.com/news/LLVM-15-Branched>

I can confirm that 3D acceleration would not work until LLVM-15 was
used. I don't understand the entire rendering pipeline anymore, but I
think it had something to do with Vulkan.

> Props to katco on IRC for going through some long building and
> debugging to track this down.

Thanks, John!

Part of the reason this was difficult to test (aside from having to
discover the LLVM part) was discovering that the XORG_DRI_DRIVER_PATH
environment variable wasn't being set correctly despite doing package
rewriting to use a different version of Mesa.

I ended up doing this:

--8<---------------cut here---------------start------------->8---
(define-public (xorg-with-mesa xorg-server mesa)
  "Returns an xorg-server package which will wrap the call to Xorg to include the
correct XORG_DRI_DRIVER_PATH for the mesa package provided."
  (package
   (inherit xorg-server)
   (arguments
    (substitute-keyword-arguments
     (package-arguments xorg-server)
     ((#:phases child-phases '%standard-phases)
      #~(modify-phases #$child-phases
                       (add-after 'install 'wrap
                                  (lambda* (#:key outputs #:allow-other-keys)
                                    (let* ((out (assoc-ref outputs "out"))
                                           (bin (string-append out "/bin"))
                                           (xorg (string-append bin "/Xorg")))
                                      (wrap-program xorg
                                                    '("XORG_DRI_DRIVER_PATH" ":" = (#$(file-append mesa "/lib/dri")))))))))))))
--8<---------------cut here---------------end--------------->8---

But something like this (I'm sure I've gotten the gexps wrong) would have been made it much easier:

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 5f073d05d3..d626e87073 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -196,7 +196,9 @@ (define-record-type* <xorg-configuration>
   (server           xorg-configuration-server     ;file-like
                     (default xorg-server))
   (server-arguments xorg-configuration-server-arguments ;list of strings
-                    (default %default-xorg-server-arguments)))
+                    (default %default-xorg-server-arguments))
+  (mesa             xorg-configuration-mesa ; package
+                    (default mesa)))
 
 (define (xorg-configuration->file config)
   "Compute an Xorg configuration file corresponding to CONFIG, an
@@ -362,7 +364,7 @@ (define* (xorg-wrapper #:optional (config (xorg-configuration)))
   (define exp
     ;; Write a small wrapper around the X server.
     #~(begin
-        (setenv "XORG_DRI_DRIVER_PATH" (string-append #$mesa "/lib/dri"))
+        (setenv "XORG_DRI_DRIVER_PATH" (string-append #$(xorg-configuration-mesa config) "/lib/dri"))
         (setenv "XKB_BINDIR" (string-append #$xkbcomp "/bin"))
 
         (let ((X (string-append #$(xorg-configuration-server config) "/bin/X")))
--8<---------------cut here---------------end--------------->8---

--
Katherine

Re: Packages grow, no longer fit on a 💾

[Simon Tournier]

Hi,

On sam., 14 janv. 2023 at 23:07, Ludovic Courtès <ludo@gnu.org> wrote:

> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 

[...]

> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 

[...]

> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 

[...]

> total: 1592.7 MiB
> --8<---------------cut here---------------end--------------->8---
>
> I think something went wrong here.  :-)

[...]

> We should do better.  I mean, it’s just a text editor, isn’t it?

Just to note to Guix itself significantly grows. :-)

--8<---------------cut here---------------start------------->8---
$ for i in 2 3 4; do guix time-machine --commit=v1.$i.0 -- size guix --sort=self ;done
store item                                                       total    self
/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af   496.0   244.5  49.3%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2  10.7%
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4            131.4    51.9  10.5%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   7.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6   6.6%
/gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.31    13.9    13.9   2.8%

[...]

total: 496.0 MiB
store item                                                       total    self
/gnu/store/9r4954qlv3pszpb8g3h5q2yn1xkda8vm-guix-1.3.0rc2-1.566982b   564.8   263.9  46.7%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   9.4%
/gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5            131.7    52.1   9.2%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   6.5%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6   5.8%
/gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6            110.3    14.7   2.6%
/gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.31    13.9    13.9   2.5%

[...]

total: 564.8 MiB
store item                                                       total    self
/gnu/store/9nvx97hr8kkr26gzwni2fblfn0yq0xjw-guix-1.4.0rc2          637.2   330.1  51.8%
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8            130.0    53.0   8.3%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   8.2%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33              38.3    36.6   5.7%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib          71.7    33.4   5.2%
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2             98.1    15.3   2.4%
/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.33    13.9    13.9   2.2%

[...]

total: 637.2 MiB
--8<---------------cut here---------------end--------------->8---


Cheers,
simon

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Just to note to Guix itself significantly grows. :-)

Yes!  There’s a lot of .scm and .go files in there, neither of which is
compact.

Ludo’.

Re: Packages grow, no longer fit on a 💾

[Paul Jewell via Development of GNU Guix and the GNU System distribution.]

Evening all,

On 14/01/2023 23:07, Ludovic Courtès wrote:
> Hello!
> 
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs
> store item                                                       total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs
> store item                                                       total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs
> store item                                                       total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---------------cut here---------------end--------------->8---
> 
> I think something went wrong here.  :-)
> 
> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
> 
> And then MESA and LLVM have always been problematically big.
> 
> We should do better.  I mean, it’s just a text editor, isn’t it?
> 
> Ludo’.
> 

Please forgive my ignorance if I have missed anything but:

- does anyone actually install from a CD these days?
- Can an ISO be bigger than a CD then be installed on a memory stick?

It strikes me that this is like King Canute holding back the tide. 
Package size growth is pretty inevitable, and even if work now can bring 
the size down to that of a CD, the same problem will occur in the not 
too distant future.

Is it really a problem? Please educate me! :)

--
Paul

Re: Packages grow, no longer fit on a 💾

[Joshua Branson]

Paul Jewell via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:

> Evening all,
>
>
> Please forgive my ignorance if I have missed anything but:
>
> - does anyone actually install from a CD these days?
> - Can an ISO be bigger than a CD then be installed on a memory stick?
>
> It strikes me that this is like King Canute holding back the tide. Package size
> growth is pretty inevitable, and even if work now can bring the size down to
> that of a CD, the same problem will occur in the not too distant future.
>
> Is it really a problem? Please educate me! :)
>

Well if GNU Guix/Hurd System ever becomes a thing, you will need a CD to
install the Hurd.  The Hurd currently does not have usb support.  Though
work is ongoing to fix this.  Also the current Debian GNU/Hurd requires
a CD to install in real hardware.

>
> --
> Paul

Re: Packages grow, no longer fit on a 💾

[Ludovic Courtès]

Hi,

Paul Jewell via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> skribis:

> - Can an ISO be bigger than a CD then be installed on a memory stick?

Yes, it can be installed from a memory stick, that’s probably what
everybody does.

> It strikes me that this is like King Canute holding back the
> tide. Package size growth is pretty inevitable, and even if work now
> can bring the size down to that of a CD, the same problem will occur
> in the not too distant future.

I’d like to question the extent to which this is inevitable, or at least
see what we can learn from others to try and mitigate disk usage growth.

Even from a purely practical perspective, it’s not convenient when ‘guix
pack’ creates big images that you have to carry around and your
colleague laughs at you because their Alpine image of “the same thing”
(quotes!) is half the size.  ;-)

Ludo’.

Re: Packages grow, no longer fit on a 💾

[Katherine Cox-Buday]

Ludovic Courtès <ludo@gnu.org> writes:

> Even from a purely practical perspective, it’s not convenient when
> ‘guix pack’ creates big images that you have to carry around and your
> colleague laughs at you because their Alpine image of “the same thing”
> (quotes!) is half the size. ;-)

I know this pain!

-- 
Katherine

Re: Packages grow, no longer fit on a 💾

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 6388 bytes --]

Paul Jewell via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:

> Evening all,
>
> On 14/01/2023 23:07, Ludovic Courtès wrote:
>> Hello!
>> Over the course of a few years, the size of our packages has
>> apparently
>> kept growing.  Example:
>> --8<---------------cut here---------------start------------->8---
>> $ guix time-machine --commit=v1.2.0 -- size emacs
>> store item                                                       total    self
>> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
>> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
>> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
>> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
>> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
>> […]
>> total: 859.7 MiB
>> $ guix time-machine --commit=v1.3.0 -- size emacs
>> store item                                                       total    self
>> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
>> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
>> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
>> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
>> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
>> […]
>> total: 880.5 MiB
>> $ guix time-machine --commit=v1.4.0 -- size emacs
>> store item                                                       total    self
>> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
>> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
>> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
>> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
>> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
>> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
>> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
>> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
>> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
>> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
>> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
>> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
>> […]
>> total: 1592.7 MiB
>> --8<---------------cut here---------------end--------------->8---
>> I think something went wrong here.  :-)
>> In particular with Emacs itself (due to JIT + dependency on
>> libgccjit,
>> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>> And then MESA and LLVM have always been problematically big.
>> We should do better.  I mean, it’s just a text editor, isn’t it?
>> Ludo’.
>> 
>
> Please forgive my ignorance if I have missed anything but:
>
> - does anyone actually install from a CD these days?

I don't know, but I'd just use a pendrive if I need an external storage.
(If I don't need, I'd just use a 2 GB HDD partition, which I made just
for very purpose.  ;)  )

> - Can an ISO be bigger than a CD then be installed on a memory stick?

Yes.

>
> It strikes me that this is like King Canute holding back the
> tide. Package size growth is pretty inevitable, and even if work now
> can bring the size down to that of a CD, the same problem will occur
> in the not too distant future.
>

But we should really try to keep them low.

> Is it really a problem?

YES!!!!!!!!!

Big packages means, it takes more space.  If a package grows by 700 MB,
installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
could use that precious storage to save your dad's photo, your favorite
music, your child's video calling you "daddy/mummy" for the first time,
etc.  You would need to get more storage for that storing those
invaluable things, so you would need more storage devices.  When you buy
more storage, the demand of increases, and therefore the manufacturing
of storage devices increase.  The more devices are manufactured, the
more carbon dioxide and other greenhouse gas emission.

Again, if the packages is downloaded 100 times every day, ~70 GB (70000
MB) of bandwidth is wasted every day.  Someone on the network could use
that to do some more important thing, like video calling a relative
living far away.  Moreover, it takes time to get the extra 700 MB for
everyone.  Assuming it takes 8 minutes on average, ~13.33 hours (800
minutes) of time is wasted everyday.  We have limited time in our lives,
we shouldn't waste the time.  This extra ~70 GB of transmission means
more load on the network, more load on the network devices, and
therefore more power consumption.  The more power consumption, the more
greenhouse gas emission, since we're fossil fuel dependent.  If your
country uses nuclear power, the extra nuclear waste is a threat for the
environment.

The more greenhouse gas, the more greenhouse effect, the more global
warming, the more climate change.  You will just destroy the earth for
future yourself and the future generation.  What will you answer to
them?

> Please educate me! :)

It's my pleasure to make someone aware.
I hope this was enough.  :)
If not, just ask!

>
> --
> Paul
>
>

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packages grow, no longer fit on a 💾

[Csepp]

Akib Azmain Turja <akib@disroot.org> writes:

> [[PGP Signed Part:Undecided]]
> Paul Jewell via "Development of GNU Guix and the GNU System
> distribution." <guix-devel@gnu.org> writes:
>
>> Evening all,
>>
>> On 14/01/2023 23:07, Ludovic Courtès wrote:
>>> Hello!
>>> Over the course of a few years, the size of our packages has
>>> apparently
>>> kept growing.  Example:
>>> --8<---------------cut here---------------start------------->8---
>>> $ guix time-machine --commit=v1.2.0 -- size emacs
>>> store item                                                       total    self
>>> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
>>> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
>>> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1             859.7   106.2  12.4%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
>>> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
>>> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
>>> […]
>>> total: 859.7 MiB
>>> $ guix time-machine --commit=v1.3.0 -- size emacs
>>> store item                                                       total    self
>>> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0            220.0   148.6  16.9%
>>> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4            389.1   141.6  16.1%
>>> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2             880.5   106.4  12.1%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.0%
>>> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24           744.3    49.1   5.6%
>>> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1             110.2    38.1   4.3%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.2%
>>> […]
>>> total: 880.5 MiB
>>> $ guix time-machine --commit=v1.4.0 -- size emacs
>>> store item                                                       total    self
>>> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2            1592.7   250.6  15.7%
>>> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8            411.6   169.6  10.6%
>>> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0            221.5   149.5   9.4%
>>> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0       244.8   128.5   8.1%
>>> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0          261.2    65.4   4.1%
>>> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0            147.7    58.6   3.7%
>>> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37          126.0    54.4   3.4%
>>> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   3.3%
>>> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30          1002.2    48.6   3.1%
>>> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   219.1    39.1   2.5%
>>> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1             110.7    38.0   2.4%
>>> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33              76.6    36.6   2.3%
>>> […]
>>> total: 1592.7 MiB
>>> --8<---------------cut here---------------end--------------->8---
>>> I think something went wrong here.  :-)
>>> In particular with Emacs itself (due to JIT + dependency on
>>> libgccjit,
>>> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>>> And then MESA and LLVM have always been problematically big.
>>> We should do better.  I mean, it’s just a text editor, isn’t it?
>>> Ludo’.
>>> 
>>
>> Please forgive my ignorance if I have missed anything but:
>>
>> - does anyone actually install from a CD these days?
>
> I don't know, but I'd just use a pendrive if I need an external storage.
> (If I don't need, I'd just use a 2 GB HDD partition, which I made just
> for very purpose.  ;)  )
>
>> - Can an ISO be bigger than a CD then be installed on a memory stick?
>
> Yes.
>
>>
>> It strikes me that this is like King Canute holding back the
>> tide. Package size growth is pretty inevitable, and even if work now
>> can bring the size down to that of a CD, the same problem will occur
>> in the not too distant future.
>>
>
> But we should really try to keep them low.
>
>> Is it really a problem?
>
> YES!!!!!!!!!
>
> Big packages means, it takes more space.  If a package grows by 700 MB,
> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
> could use that precious storage to save your dad's photo, your favorite
> music, your child's video calling you "daddy/mummy" for the first time,
> etc.  You would need to get more storage for that storing those
> invaluable things, so you would need more storage devices.  When you buy
> more storage, the demand of increases, and therefore the manufacturing
> of storage devices increase.  The more devices are manufactured, the
> more carbon dioxide and other greenhouse gas emission.
>
> Again, if the packages is downloaded 100 times every day, ~70 GB (70000
> MB) of bandwidth is wasted every day.  Someone on the network could use
> that to do some more important thing, like video calling a relative
> living far away.  Moreover, it takes time to get the extra 700 MB for
> everyone.  Assuming it takes 8 minutes on average, ~13.33 hours (800
> minutes) of time is wasted everyday.  We have limited time in our lives,
> we shouldn't waste the time.  This extra ~70 GB of transmission means
> more load on the network, more load on the network devices, and
> therefore more power consumption.  The more power consumption, the more
> greenhouse gas emission, since we're fossil fuel dependent.  If your
> country uses nuclear power, the extra nuclear waste is a threat for the
> environment.
>
> The more greenhouse gas, the more greenhouse effect, the more global
> warming, the more climate change.  You will just destroy the earth for
> future yourself and the future generation.  What will you answer to
> them?
>
>> Please educate me! :)
>
> It's my pleasure to make someone aware.
> I hope this was enough.  :)
> If not, just ask!
>
>>
>> --
>> Paul
>>
>>

Well said.  Gonna add to this that developers are overwhelmingly from
privileged backgrounds.  Just because we don't have a lot of users on
the mailing list who have to use satellite internet on ancient laptops
does not mean those (potential) users are not out there and wouldn't
benefit from our distro not being a bloated mess.  Which sadly it kind
of is currently.  I wholeheartedly recommend trying to use it on an old
netbook or an armhf device from time to time.
Like others have said: if you want to develop efficient software, use a
slow machine.  :)

Re: Packages grow, no longer fit on a 💾

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]

Csepp <raingloom@riseup.net> writes:

[...]

>>> It strikes me that this is like King Canute holding back the
>>> tide. Package size growth is pretty inevitable, and even if work now
>>> can bring the size down to that of a CD, the same problem will occur
>>> in the not too distant future.
>>>
>>
>> But we should really try to keep them low.
>>
>>> Is it really a problem?
>>
>> YES!!!!!!!!!
>>
>> Big packages means, it takes more space.  If a package grows by 700 MB,
>> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
>> could use that precious storage to save your dad's photo, your favorite
>> music, your child's video calling you "daddy/mummy" for the first time,
>> etc.  You would need to get more storage for that storing those
>> invaluable things, so you would need more storage devices.  When you buy
>> more storage, the demand of increases, and therefore the manufacturing
>> of storage devices increase.  The more devices are manufactured, the
>> more carbon dioxide and other greenhouse gas emission.
>>
>> Again, if the packages is downloaded 100 times every day, ~70 GB (70000
>> MB) of bandwidth is wasted every day.  Someone on the network could use
>> that to do some more important thing, like video calling a relative
>> living far away.  Moreover, it takes time to get the extra 700 MB for
>> everyone.  Assuming it takes 8 minutes on average, ~13.33 hours (800
>> minutes) of time is wasted everyday.  We have limited time in our lives,
>> we shouldn't waste the time.  This extra ~70 GB of transmission means
>> more load on the network, more load on the network devices, and
>> therefore more power consumption.  The more power consumption, the more
>> greenhouse gas emission, since we're fossil fuel dependent.  If your
>> country uses nuclear power, the extra nuclear waste is a threat for the
>> environment.
>>
>> The more greenhouse gas, the more greenhouse effect, the more global
>> warming, the more climate change.  You will just destroy the earth for
>> future yourself and the future generation.  What will you answer to
>> them?
>>
>>> Please educate me! :)
>>
>> It's my pleasure to make someone aware.
>> I hope this was enough.  :)
>> If not, just ask!
>>
>>>
>>> --
>>> Paul
>>>
>>>
>
> Well said.  Gonna add to this that developers are overwhelmingly from
> privileged backgrounds.  Just because we don't have a lot of users on
> the mailing list who have to use satellite internet on ancient laptops
> does not mean those (potential) users are not out there and wouldn't
> benefit from our distro not being a bloated mess.  Which sadly it kind
> of is currently.  I wholeheartedly recommend trying to use it on an old
> netbook or an armhf device from time to time.
> Like others have said: if you want to develop efficient software, use a
> slow machine.  :)

I have a slow machine from about 10 years ago, and I'm really happy with
it.  (I'm writing from this machine.)  I also have a slow unstable
internet connection, so I understand the pain of download hundreds of
MB of data without pause and resume support.  (I couldn't download the
latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
8-10 times.)

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packages grow, no longer fit on a 💾

[bokr]

On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
> Csepp <raingloom@riseup.net> writes:
> 
> I have a slow machine from about 10 years ago, and I'm really happy with
> it.  (I'm writing from this machine.)  I also have a slow unstable
> internet connection, so I understand the pain of download hundreds of
> MB of data without pause and resume support.  (I couldn't download the
> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
> 8-10 times.)
>

Could you somehow use
    wget -c <url>
to continue an interrupted download?
Or does the source not support that?

(see wget --help |less -- and scroll down to Download: section)

> -- 
> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
> Fediverse: akib@hostux.social
> Codeberg: akib
> emailselfdefense.fsf.org | "Nothing can be secure without encryption."

--
Regards,
Bengt Richter

Re: Packages grow, no longer fit on a 💾

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

bokr@bokr.com writes:

> On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
>> Csepp <raingloom@riseup.net> writes:
>> 
>> I have a slow machine from about 10 years ago, and I'm really happy with
>> it.  (I'm writing from this machine.)  I also have a slow unstable
>> internet connection, so I understand the pain of download hundreds of
>> MB of data without pause and resume support.  (I couldn't download the
>> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
>> 8-10 times.)
>>
>
> Could you somehow use
>     wget -c <url>
> to continue an interrupted download?
> Or does the source not support that?

Yes, the infamous https://ci.guix.gnu.org server.

>
> (see wget --help |less -- and scroll down to Download: section)
>
>> -- 
>> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
>> Fediverse: akib@hostux.social
>> Codeberg: akib
>> emailselfdefense.fsf.org | "Nothing can be secure without encryption."
>
> --
> Regards,
> Bengt Richter

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packages grow, no longer fit on a 💾

[Simon Tournier]

Hi,

On mer., 18 janv. 2023 at 21:44, Paul Jewell via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:

> - does anyone actually install from a CD these days?
> - Can an ISO be bigger than a CD then be installed on a memory stick?

Florian reported an example in [1], quoting:

        my laptop doesn’t boot from USB, I have more CD/Rs than DVD/Rs
        and I guess they are cheaper than DVD.

1: <https://issues.guix.gnu.org/58760>


> It strikes me that this is like King Canute holding back the tide. 
> Package size growth is pretty inevitable, and even if work now can bring 
> the size down to that of a CD, the same problem will occur in the not 
> too distant future.
>
> Is it really a problem? Please educate me! :)

From my point of view, yes this increases is an issue, especially for
the not too distant future.  In the short term, we have to save
resources because in this not too distant future, we will have to do
the same (or more) using less.


Cheers,
simon