[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming FTPMaster meeting



On Sat, Feb 12, 2011 at 01:15:47PM +0000, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane <henrich@debian.or.jp> wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog <hertzog@debian.org> wrote:
> >> I have not seen any word about XZ support.

> >  I want XZ support too, at least it reduce size for some font packages.
> >  e.g.

The numbers you quoted (1/3 reduction) are actually on the small side --
although consistent with my estimates for the archive as a whole.  You can
expect 50% gains on most packages, it's some bulky data ones that are
incompressible that jack down the average.

> Do we have an idea how much more memory xz needs for decompression?  I guess
> it wouldn't be feasible to switch dpkg's default on package builds on those
> architectures where we assume some more beefyness?

On ARM, it's 90MB, I guess MIPS should be similar.
The man page says 65MB even in -9, but I guess they didn't count in the
code, libc, buffers and the likes.

Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
type that are going to run stock Debian are chroots on n900, which, with
256MB, can handle all the phony stuff together with decompression just fine.
If you allow for everything but the decompression to be swapped out, even
128MB would work reasonably.

Anything lower and you go into emdebian, which repacks all the packages
anyway.

Thus, I think there are no problems with enabling XZ on all architectures.

> I'd imagine that our CD1s would also get more useful if we'd compress those
> in any case.  But then that probably also concerns our core packages where
> memory usage might matter.

Memory during upgrades, not during actual operation.

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.


Reply to: