| |||||||||||||
Google releases a better compression algorithmGoogle releases a better compression algorithmPosted Mar 2, 2013 8:05 UTC (Sat) by rbrito (subscriber, #66188)Parent article: Google releases a better compression algorithm
One thing that the discussions here seem to be missing is that such a gzip-compatible algorithm that is able to compress more is highly suitable for creating images for embedded devices, where the NVRAM is a hard limit that, in general, cannot be upgraded or something.
When people create images for those devices, to keep the size of, say, the initrd low, it is frequent to cut features from busybox or other utilities.
With a stronger compression that the initial steps can understand, said images can just be not that cut down.
So, given a slower method that is still compatible with what my devices can understand or fewer features, I gladly take the 20x compress-once penalty.
(Log in to post comments)
Google releases a better compression algorithm Posted Mar 4, 2013 4:09 UTC (Mon) by PaulWay (✭ supporter ✭, #45600) [Link]
With the further advantage that one can still use standard gzip during testing on a developer board with more memory to keep updating the image without slowing down the test cycle.
Have fun,
Paul
Google releases a better compression algorithm Posted Mar 4, 2013 17:59 UTC (Mon) by nbd (subscriber, #14393) [Link]
Why bother sticking to gzip compatible, when you can already use LZMA/xz for things like initrd/initramfs or even the full kernel (assuming you have a compatible loader). The compression ratio of xz is much, much better than zopfli
|
|||||||||||||