> On Thu, Jun 6, 2013 at 11:48 AM, Theo de Raadt <dera...@cvs.openbsd.org> > wrote: > [...] > > If anyone thinks using this for the install or boot media is going to > > help, don't say a word until you can prove it on all platforms. > > Has anyone looked at zopfli[1] for the install media? It's a (apache > 2 licensed) slightly better but much slower gzip compressor that still > produces gzip-compatible output. > > For an amd64 ramdiskA it makes a bsd.gz that's 48k smaller than gzip > (in ~16 seconds) and should compatible with the bootloader. I tried > it once in a vm and it booted ok. > > $ time gzip -9cn bsd.strip >bsd.gz > real 0m0.648s > user 0m0.610s > sys 0m0.000s > > $ time zopfli -c bsd.strip >bsd.zopfli.gz > real 0m17.409s > user 0m16.810s > sys 0m0.580s > > $ ls -l bsd.gz bsd.zopfli.gz > -rw-r--r-- 1 dtucker wsrc 1349508 Jun 6 15:40 bsd.gz > -rw-r--r-- 1 dtucker wsrc 1310302 Jun 6 15:42 bsd.zopfli.gz > > [1] https://code.google.com/p/zopfli/
I don't know where we'd put it in the tree. If we did add it, it would only benefit the fast architectures, since the others cannot afford the additional build time. Developers would use up the space gains quickly. Right now a few architectures are neck and neck regarding which install media are close to full. Older architectures would hit full install media issues first. A smaller contingent of developers who take care of those architectures would have to deal with the fallout, creating further "friction"... I understand where the suggestion comes from, but also seea more downsides than benefits.
