Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sun, 2023-09-17 at 22:16 +0200, Joerg Jaspert wrote:
>
> I do not think wasting space is any good idea.
>
> > ## More bandwidth
> > According to https://www.speedtest.net/global-index, broadband
> > bandwidth
> > in Nicaragua becomes almost 10x
>
> And elsewhere it may have gone up a different factor.
> Still, there are MANY places where its still bad.
I fully agree. I forgot to mention this point in my other response
in the thread.
The thing is, while the average bandwidth do increase as time goes
by, the bottom-1% will not likely increase like that.
In many corners in the world, people are still using poor and
expensive network. Those networks might be even metered.
Significantly bloating up the mirror size will directly increase
the metered network bill for those people. I was one of them.
It will also increase the pressure on mirror hosting.
Some universities host linux mirrors on their own. Debian is always
the most bulky repository to mirror. They are not always commercially
supported -- sometimes supported only by volunteer's funds.
A significantly bloated up debian mirrors can make their life more
difficult. Things can be worse if they the uploading bandwidth is
limited of even metered. I was one of such hosts.
I know, this is a difficult trade-off between Debian's accessibilty
and software performance.
> > 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.
>
> In ideal conditions, maybe, but still, thats the first (to me) good
> reason. IMO not good enough to actually do it.
>
> > - Not sure how repository size will be, need an experiment
>
> And keep in mind the repository is mirrored a trillion times, stored
> in
> snapshots, burned into images here and there, so any "small" increase
> in
> size actually means a *huge* waste in the end.
>
> If we switch formats, going to something that's at least as good as
> the
> one we currently have should be the goal. (And I do not mean
> something
> like "its code/algorithm is bad", really, that argument is dead
> before
> it begins even).
>
> Now, thats for .debs. There might be a better argument when talking
> about the index files in dists/, they are read so much more often, it
> *may* make more sense there.
>
Reply to: