* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
@ 2023-01-15 5:51 ` kiasoc5
2023-01-15 8:07 ` Liliana Marie Prikler
` (5 subsequent siblings)
6 siblings, 0 replies; 38+ messages in thread
From: kiasoc5 @ 2023-01-15 5:51 UTC (permalink / raw)
To: Ludovic Courtès, guix-devel
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.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
2023-01-15 5:51 ` kiasoc5
@ 2023-01-15 8:07 ` Liliana Marie Prikler
2023-01-16 2:09 ` Maxim Cournoyer
2023-01-15 12:56 ` Akib Azmain Turja
` (4 subsequent siblings)
6 siblings, 1 reply; 38+ messages in thread
From: Liliana Marie Prikler @ 2023-01-15 8:07 UTC (permalink / raw)
To: Ludovic Courtès, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-15 8:07 ` Liliana Marie Prikler
@ 2023-01-16 2:09 ` Maxim Cournoyer
2023-01-16 5:17 ` Liliana Marie Prikler
2023-01-17 16:15 ` Ludovic Courtès
0 siblings, 2 replies; 38+ messages in thread
From: Maxim Cournoyer @ 2023-01-16 2:09 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: Ludovic Courtès, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-16 2:09 ` Maxim Cournoyer
@ 2023-01-16 5:17 ` Liliana Marie Prikler
2023-01-16 13:27 ` Maxim Cournoyer
2023-01-17 16:15 ` Ludovic Courtès
1 sibling, 1 reply; 38+ messages in thread
From: Liliana Marie Prikler @ 2023-01-16 5:17 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Ludovic Courtès, guix-devel
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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-16 5:17 ` Liliana Marie Prikler
@ 2023-01-16 13:27 ` Maxim Cournoyer
0 siblings, 0 replies; 38+ messages in thread
From: Maxim Cournoyer @ 2023-01-16 13:27 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: Ludovic Courtès, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-16 2:09 ` Maxim Cournoyer
2023-01-16 5:17 ` Liliana Marie Prikler
@ 2023-01-17 16:15 ` Ludovic Courtès
1 sibling, 0 replies; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-17 16:15 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Liliana Marie Prikler, guix-devel
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
2023-01-15 5:51 ` kiasoc5
2023-01-15 8:07 ` Liliana Marie Prikler
@ 2023-01-15 12:56 ` Akib Azmain Turja
2023-01-15 17:00 ` pelzflorian (Florian Pelz)
` (3 subsequent siblings)
6 siblings, 0 replies; 38+ messages in thread
From: Akib Azmain Turja @ 2023-01-15 12:56 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
` (2 preceding siblings ...)
2023-01-15 12:56 ` Akib Azmain Turja
@ 2023-01-15 17:00 ` pelzflorian (Florian Pelz)
2023-01-17 16:25 ` Ludovic Courtès
2023-01-17 8:06 ` Efraim Flashner
` (2 subsequent siblings)
6 siblings, 1 reply; 38+ messages in thread
From: pelzflorian (Florian Pelz) @ 2023-01-15 17:00 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-15 17:00 ` pelzflorian (Florian Pelz)
@ 2023-01-17 16:25 ` Ludovic Courtès
2023-01-17 23:05 ` zimoun
2023-01-18 2:41 ` kiasoc5
0 siblings, 2 replies; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-17 16:25 UTC (permalink / raw)
To: pelzflorian (Florian Pelz); +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 16:25 ` Ludovic Courtès
@ 2023-01-17 23:05 ` zimoun
2023-01-17 23:49 ` zimoun
2023-01-19 14:14 ` Packages grow, no longer fit on a 💾 Ludovic Courtès
2023-01-18 2:41 ` kiasoc5
1 sibling, 2 replies; 38+ messages in thread
From: zimoun @ 2023-01-17 23:05 UTC (permalink / raw)
To: Ludovic Courtès, pelzflorian (Florian Pelz); +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 23:05 ` zimoun
@ 2023-01-17 23:49 ` zimoun
2023-01-18 21:04 ` Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾) Liliana Marie Prikler
2023-01-19 14:14 ` Packages grow, no longer fit on a 💾 Ludovic Courtès
1 sibling, 1 reply; 38+ messages in thread
From: zimoun @ 2023-01-17 23:49 UTC (permalink / raw)
To: Ludovic Courtès, pelzflorian (Florian Pelz); +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾)
2023-01-17 23:49 ` zimoun
@ 2023-01-18 21:04 ` Liliana Marie Prikler
2023-01-19 14:28 ` Grandfathering store paths considered harmful Ludovic Courtès
0 siblings, 1 reply; 38+ messages in thread
From: Liliana Marie Prikler @ 2023-01-18 21:04 UTC (permalink / raw)
To: zimoun, Ludovic Courtès, pelzflorian (Florian Pelz); +Cc: guix-devel
[-- 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
^ permalink raw reply related [flat|nested] 38+ messages in thread* Re: Grandfathering store paths considered harmful
2023-01-18 21:04 ` Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾) Liliana Marie Prikler
@ 2023-01-19 14:28 ` Ludovic Courtès
2023-01-19 18:10 ` Liliana Marie Prikler
0 siblings, 1 reply; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-19 14:28 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: zimoun, pelzflorian (Florian Pelz), guix-devel
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/>.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Grandfathering store paths considered harmful
2023-01-19 14:28 ` Grandfathering store paths considered harmful Ludovic Courtès
@ 2023-01-19 18:10 ` Liliana Marie Prikler
0 siblings, 0 replies; 38+ messages in thread
From: Liliana Marie Prikler @ 2023-01-19 18:10 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: zimoun, pelzflorian (Florian Pelz), guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 23:05 ` zimoun
2023-01-17 23:49 ` zimoun
@ 2023-01-19 14:14 ` Ludovic Courtès
2023-01-20 10:51 ` Simon Tournier
1 sibling, 1 reply; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-19 14:14 UTC (permalink / raw)
To: zimoun; +Cc: pelzflorian (Florian Pelz), guix-devel
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-19 14:14 ` Packages grow, no longer fit on a 💾 Ludovic Courtès
@ 2023-01-20 10:51 ` Simon Tournier
2023-01-20 14:54 ` Maxim Cournoyer
0 siblings, 1 reply; 38+ messages in thread
From: Simon Tournier @ 2023-01-20 10:51 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: pelzflorian (Florian Pelz), guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-20 10:51 ` Simon Tournier
@ 2023-01-20 14:54 ` Maxim Cournoyer
0 siblings, 0 replies; 38+ messages in thread
From: Maxim Cournoyer @ 2023-01-20 14:54 UTC (permalink / raw)
To: Simon Tournier
Cc: Ludovic Courtès, pelzflorian (Florian Pelz), guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 16:25 ` Ludovic Courtès
2023-01-17 23:05 ` zimoun
@ 2023-01-18 2:41 ` kiasoc5
2023-01-18 8:43 ` indieterminacy
2023-01-19 14:32 ` Ludovic Courtès
1 sibling, 2 replies; 38+ messages in thread
From: kiasoc5 @ 2023-01-18 2:41 UTC (permalink / raw)
To: Ludovic Courtès, pelzflorian (Florian Pelz); +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-18 2:41 ` kiasoc5
@ 2023-01-18 8:43 ` indieterminacy
2023-01-19 14:32 ` Ludovic Courtès
1 sibling, 0 replies; 38+ messages in thread
From: indieterminacy @ 2023-01-18 8:43 UTC (permalink / raw)
To: kiasoc5; +Cc: Ludovic Courtès, pelzflorian (Florian Pelz), guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-18 2:41 ` kiasoc5
2023-01-18 8:43 ` indieterminacy
@ 2023-01-19 14:32 ` Ludovic Courtès
2023-01-20 11:06 ` Simon Tournier
1 sibling, 1 reply; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-19 14:32 UTC (permalink / raw)
To: kiasoc5; +Cc: pelzflorian (Florian Pelz), guix-devel
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-19 14:32 ` Ludovic Courtès
@ 2023-01-20 11:06 ` Simon Tournier
0 siblings, 0 replies; 38+ messages in thread
From: Simon Tournier @ 2023-01-20 11:06 UTC (permalink / raw)
To: Ludovic Courtès, kiasoc5; +Cc: pelzflorian (Florian Pelz), guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
` (3 preceding siblings ...)
2023-01-15 17:00 ` pelzflorian (Florian Pelz)
@ 2023-01-17 8:06 ` Efraim Flashner
2023-01-17 16:18 ` Ludovic Courtès
2023-01-17 15:06 ` Simon Tournier
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
6 siblings, 1 reply; 38+ messages in thread
From: Efraim Flashner @ 2023-01-17 8:06 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-17 8:06 ` Efraim Flashner
@ 2023-01-17 16:18 ` Ludovic Courtès
2023-01-17 21:54 ` John Kehayias
0 siblings, 1 reply; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-17 16:18 UTC (permalink / raw)
To: guix-devel
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 16:18 ` Ludovic Courtès
@ 2023-01-17 21:54 ` John Kehayias
2023-01-19 15:30 ` Katherine Cox-Buday
0 siblings, 1 reply; 38+ messages in thread
From: John Kehayias @ 2023-01-17 21:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Efraim Flashner, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-17 21:54 ` John Kehayias
@ 2023-01-19 15:30 ` Katherine Cox-Buday
0 siblings, 0 replies; 38+ messages in thread
From: Katherine Cox-Buday @ 2023-01-19 15:30 UTC (permalink / raw)
To: John Kehayias; +Cc: Ludovic Courtès, Efraim Flashner, guix-devel
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
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
` (4 preceding siblings ...)
2023-01-17 8:06 ` Efraim Flashner
@ 2023-01-17 15:06 ` Simon Tournier
2023-01-19 14:34 ` Ludovic Courtès
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
6 siblings, 1 reply; 38+ messages in thread
From: Simon Tournier @ 2023-01-17 15:06 UTC (permalink / raw)
To: Ludovic Courtès, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
` (5 preceding siblings ...)
2023-01-17 15:06 ` Simon Tournier
@ 2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
2023-01-19 13:04 ` Joshua Branson
` (3 more replies)
6 siblings, 4 replies; 38+ messages in thread
From: Paul Jewell via Development of GNU Guix and the GNU System distribution. @ 2023-01-18 20:44 UTC (permalink / raw)
To: guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
@ 2023-01-19 13:04 ` Joshua Branson
2023-01-19 14:37 ` Ludovic Courtès
` (2 subsequent siblings)
3 siblings, 0 replies; 38+ messages in thread
From: Joshua Branson @ 2023-01-19 13:04 UTC (permalink / raw)
To: Paul Jewell via Development of GNU Guix and the GNU System distribution.
Cc: Paul Jewell
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
2023-01-19 13:04 ` Joshua Branson
@ 2023-01-19 14:37 ` Ludovic Courtès
2023-01-19 16:12 ` Katherine Cox-Buday
2023-01-19 18:07 ` Akib Azmain Turja
2023-01-20 12:11 ` Simon Tournier
3 siblings, 1 reply; 38+ messages in thread
From: Ludovic Courtès @ 2023-01-19 14:37 UTC (permalink / raw)
To: Paul Jewell via Development of GNU Guix and the GNU System distribution.
Cc: Paul Jewell
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’.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
2023-01-19 13:04 ` Joshua Branson
2023-01-19 14:37 ` Ludovic Courtès
@ 2023-01-19 18:07 ` Akib Azmain Turja
2023-01-20 15:30 ` Csepp
2023-01-20 12:11 ` Simon Tournier
3 siblings, 1 reply; 38+ messages in thread
From: Akib Azmain Turja @ 2023-01-19 18:07 UTC (permalink / raw)
To: Paul Jewell via Development of GNU Guix and the GNU System distribution.
Cc: Paul Jewell
[-- 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 --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-19 18:07 ` Akib Azmain Turja
@ 2023-01-20 15:30 ` Csepp
2023-01-20 17:34 ` Akib Azmain Turja
0 siblings, 1 reply; 38+ messages in thread
From: Csepp @ 2023-01-20 15:30 UTC (permalink / raw)
To: Akib Azmain Turja; +Cc: Paul Jewell, guix-devel
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. :)
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-20 15:30 ` Csepp
@ 2023-01-20 17:34 ` Akib Azmain Turja
2023-01-21 12:29 ` bokr
0 siblings, 1 reply; 38+ messages in thread
From: Akib Azmain Turja @ 2023-01-20 17:34 UTC (permalink / raw)
To: Csepp; +Cc: Paul Jewell, guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-20 17:34 ` Akib Azmain Turja
@ 2023-01-21 12:29 ` bokr
2023-01-21 15:55 ` Akib Azmain Turja
0 siblings, 1 reply; 38+ messages in thread
From: bokr @ 2023-01-21 12:29 UTC (permalink / raw)
To: Akib Azmain Turja; +Cc: Csepp, Paul Jewell, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: Packages grow, no longer fit on a 💾
2023-01-21 12:29 ` bokr
@ 2023-01-21 15:55 ` Akib Azmain Turja
0 siblings, 0 replies; 38+ messages in thread
From: Akib Azmain Turja @ 2023-01-21 15:55 UTC (permalink / raw)
To: bokr; +Cc: Csepp, Paul Jewell, guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Packages grow, no longer fit on a 💾
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
` (2 preceding siblings ...)
2023-01-19 18:07 ` Akib Azmain Turja
@ 2023-01-20 12:11 ` Simon Tournier
3 siblings, 0 replies; 38+ messages in thread
From: Simon Tournier @ 2023-01-20 12:11 UTC (permalink / raw)
To: Paul Jewell, guix-devel
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
^ permalink raw reply [flat|nested] 38+ messages in thread