Hallo,
* Hideki Yamane [Sat, Sep 16 2023, 10:31:20AM]:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
I tend to agree but...
> # Compared to past change to xz proposal (in DebConf12)
>
> There are reasons why I propose this
>
> * More bandwidth
You mean more _network_ bandwidth.
> * More CPUs
You mean more _cores_ (but not necessarily faster cores).
> According to https://www.speedtest.net/global-index, broadband bandwidth
> in Nicaragua becomes almost 10x
Yes, the question of "10 times more CPU burning vs. saving 10 percent of
data size" has become not so easy nowadays.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
> And, xz cannot use multi core CPUs for decompression but zstd can.
> It means that if we use xz, we just get 2x CPU power, but change to zst,
> we can get more than 10x CPU power than 2012.
>
> It reduces a lot of time for package installation.
When the network bandwith is cheap then it surely is. But something I do
not like in this trade-off is the question of energy consumption resp.
CO2 emissions. What exactly does the faster processing mean in terms of
the environment impact mean, and how much (i.e. delays) can we expect
from our users here?
Anyway, my overall gut feeling after dealing with compression issues
(and wearing my "unp" and "apt-cacher-ng" upstream hat) is that Zstd is
a slightly better default option for compression for typical binary
files. There are a some special cases in certain contexts where other
compressor (even bzip* for source code) can be more sensible, so those
option should remain available. But as rule of thumb, Zstd looks like
the better way to go.
Best regards,
Eduard.
Attachment:
signature.asc
Description: PGP signature