Fedora 34 Aims To Shrink Its Install Media By Ramping Up Compression

[phoronix]

Phoronix: Fedora 34 Aims To Shrink Its Install Media By Ramping Up Compression

While Fedora 33 hasn't even been released yet, Fedora 34 is already seeing new feature proposals...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-34-Install-Compress

[eydee]

It's interesting that the install time increase is a fixed value regardless of hardware. Time for pocket calculators to shine. The slower the device, the better. If it takes 2 weeks for a "normal" install, 2 weeks + 24 seconds makes no difference. Can't wait to see how it works on my abacus.

[Jabberwocky]

It's interesting that the install time increase is a fixed value regardless of hardware.

Good point. I am also annoyed when there's lack of technical detail on technical matters like this. I'm guessing it's because XZ defaults to a single thread. You can set options via the "XZ_DEFAULTS" variable. I would like to know if there was any investigation on changing this parameter and testing it on "slow" and "fast" machines. Additionally using XZ would increase RAM requirements depending on compression level that was used. Worse case probably 64MB extra RAM required.

Time for pocket calculators to shine. The slower the device, the better. If it takes 2 weeks for a "normal" install, 2 weeks + 24 seconds makes no difference. Can't wait to see how it works on my abacus.

Never go full exaggeration. Michael explicitly mentions the reason. The idea is to save network bandwidth. There's obviously a balance between bandwidth cost and installation time, it's very reasonable to me to save on those costs since it's a free service. The only place where this could hurt is if someone is doing CI where they install multiple times every day. I doubt many people do this, most use cloud images.

[ix900]

It's interesting that the install time increase is a fixed value regardless of hardware.

Good point. I am also annoyed when there's lack of technical detail on technical matters like this. I'm guessing it's because XZ defaults to a single thread...

Didn't read everything but quite sure that's not what was said. The hardware will have to work harder. Its rather simple to understand.

[garegin]

Good point. I am also annoyed when there's lack of technical detail on technical matters like this. I'm guessing it's because XZ defaults to a single thread. You can set options via the "XZ_DEFAULTS" variable. I would like to know if there was any investigation on changing this parameter and testing it on "slow" and "fast" machines. Additionally using XZ would increase RAM requirements depending on compression level that was used. Worse case probably 64MB extra RAM required.




Never go full exaggeration. Michael explicitly mentions the reason. The idea is to save network bandwidth. There's obviously a balance between bandwidth cost and installation time, it's very reasonable to me to save on those costs since it's a free service. The only place where this could hurt is if someone is doing CI where they install multiple times every day. I doubt many people do this, most use cloud images.

Why don’t they cap the regular downloads and direct people in using torrents instead.
and yes, I understand that some corporate networks block torrents.

[skeevy420]

Why don’t they cap the regular downloads and direct people in using torrents instead.
and yes, I understand that some corporate networks block torrents.

You answered your own question. Torrents aren't the most dependable and reliable method of distribution because they're blocked by some providers. HTTP and HTTPS, however, might as well be considered to be universally available for all internet users so that is what they have to optimize their release towards. Going by the numbers I'd prefer Zstd from an end-user doing an install perspective but I totally get their wanting to shave off a couple hundred MB per download perspective.

[rajcina12]

You answered your own question. Torrents aren't the most dependable and reliable method of distribution because they're blocked by some providers. HTTP and HTTPS, however, might as well be considered to be universally available for all internet users so that is what they have to optimize their release towards. Going by the numbers I'd prefer Zstd from an end-user doing an install perspective but I totally get their wanting to shave off a couple hundred MB per download perspective.

But they do not offer a torrent option at all. Also torrent download can be useful on slow or unstable connections because the download is split in chunks and allows resuming. One download via torrent would save 2GB worth of bandwidth instead a couple MB. They could include a simple torrent client in their ISO burner app for novice users. Also it is auto checksummed.

[RahulSundaram]

But they do not offer a torrent option at all.

This is incorrect. Fedora has always from the first release offered torrent downloads

https://torrent.fedoraproject.org/

It is linked from alt downloads in https://getfedora.org/

[Mario Junior]

Just use ZSTD

[RahulSundaram]

Just use ZSTD

If you read the linked change proposal, you would see why this isn't done