Re: Let's shrink Packages.xz
On Wed, Jul 16, 2014, at 19:28, Russ Allbery wrote:
> Ondřej Surý <ondrej@sury.org> writes:
> > On Mon, Jul 14, 2014, at 18:25, Jakub Wilk wrote:
>
> >> Food for thought:
> >> Which fields take up most space in Packages.xz[0]?
>
> > I am still lost - what problem are we trying to solve here?
> > Could we at least define it to see if the problem exists?
>
> I'm fairly sure Jakub's message was in response to the recent discussion
> about small Node.js packages and the frequent complaints that we should
> not introduce small packages into the archive because it bloats our
> metadata.
>
> Reducing the size of Packages.xz by 11% or 22% would leave room for quite
> a lot of small packages while not making the problem any worse than it is
> today.
Ok, that makes much more sense now. Still is the main problem the
download
size or the size on the disk (I can guess that it can be a problem on
embedded
archs). Or both?
Dropping md5+sha1 or even introducing sha-224 instead of sha-256 would
help
in this case.
Having the fallback mechanism leaves open door for stripping+downgrade
attacks
anyway.
Switching to an optimized binary format isn't an option? But I guess it
won't
be probably that much better than a good compression algorithm.
O.
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: