For fuck's sake. It's not hard to think how that kind of bloat becomes a show stopper.
Maybe you'd like to install N packages at the same time? That's 64mb * N.
Keeping in mind that storage media doesn't like simultaneous reads or writes, I guess it's fair to say that you'd rarely have N to be more than 1 or 2...
That and Fedora being a bleeding edge distro, it's probably not such a bright idea to install new releases on very low end devices IMO...
Also, having smaller packages does speed up installing (either via local storage or netinstall), so the disadvantage is meaningless compared to the advantage.
I was thinking more about Debian, TFA. I sure hope they don't go packing their debs at those extreme settings.
Fedora yeah, it's been too heavy for that class for years. BTW, what phone has 1gb ram? Most come with half a gig if that.
Does apt even support installing more then one deb at a time?
BTW, the compression / decompression memory for LZMA/LZMA2 (of which Xz is just one implementation) is asymmetrical. It may require several gigs to compress but only a few hundred MB to decompress. And this is per archive with no regard for how big that archive is. So if you have 10 packages and each one is in an archive, and one of them is 512 KB, one of them is 10 MB, and one of them is 60 GB, all of them are going to occupy the same amount of resident program memory during decompression. And because dpkg can only install one package at a time, they won't be decompressing simultaneously. Have you ever watched a large update? It goes through the list "Unpacking" each package in serial (i.e. one at a time). So the amount of memory used by Xz decompression is only going to be about 64 MB total (and that memory will get allocated, then freed, then re-allocated again as each dpkg process unpacks a different archive file).
Originally Posted by GreatEmerald