On ke, 2007-12-19 at 13:34 -0500, Mackenzie Morgan wrote:
I upgrade a between 2 days and 2 weeks before release to avoid waiting
4 hours for the upgrade to download on release day, like I did with
Edgy.
For releases, one can almost certainly wait a few days for the worst
rush to be over.
For
Let me add my 2 cents' worth. I don't know what algorithm is used by
lzma, but I think there are other factors than CPU speed and size
that matters. Namely memory.
As an example, I can tell you that in the past we have experienced
problems with the quite serious memory requirements of
Apologies if I don't understand this correctly. I have a few questions.
How will this affect users dist-upgrading? Does 7.10 + 6.06 both have LZMA
already installed to allow the upgrade?
Will this add a step for Ubuntu developers to make packages for Debian?
I like this idea as it looks like
I did some experimentation with my Wine package. Here's the filesize of
the latest .deb passing different options to dpkg-deb:
11081456 default
10090930 bzip2
7682608 lzma
That's over a 30% reduction in bandwidth for me and my humble third
party repository.
I've heard that lzma will be
Scott Ritchie napisał(a):
I did some experimentation with my Wine package. Here's the filesize of
the latest .deb passing different options to dpkg-deb:
11081456 default
10090930 bzip2
7682608 lzma
That's over a 30% reduction in bandwidth for me and my humble third
party repository.
Krzysztof Lichota wrote:
Scott Ritchie napisał(a):
I did some experimentation with my Wine package. Here's the filesize of
the latest .deb passing different options to dpkg-deb:
11081456 default
10090930 bzip2
7682608 lzma
That's over a 30% reduction in bandwidth for me and my humble
Scott Ritchie napisał(a):
It's been shown that lzma is, in general, much better. If we happen to
find a specific case where it's not, then we can always set that package
to a non-default by tweaking the dh_builddeb line.
I couldn't find any paper about lzma. But you are right, if it can be
Krzysztof Lichota wrote the following on 17.12.2007 13:05
recently i also tried 7z for my backups and in comparation to bz2 it seems to
take a bit longer during compressing but is faster on extraction.
Also the compressed file with 7z is ~30% compared to a bz2 one.
/snip
It is hard to judge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott Ritchie wrote:
I believe lzma has a fairly efficient decompression time. We should
note, however, that package installation time is one of the least
important places to optimize CPU usage - it's not user-interactive,
and is very frequently
We are talking about a 10x increase in the time it takes to create
DEBs if moving from gz - lzma. Is this acceptable? Also, it is more
than doubling the work placed on the installer's CPU. This may be
acceptable moving forward, if that's what the community and developers
decide. However, just
On Mon, Dec 17, 2007 at 01:05:26PM +0100, Krzysztof Lichota wrote:
I've heard that lzma will be included by default in main for Hardy.
This is a very good idea. Changing package build scripts to manually
pass lzma compression using dh_builddeb -- -Z lzma would be very
tedious, however.
Kristian Erik Hermansen wrote the following on 17.12.2007 23:56
We are talking about a 10x increase in the time it takes to create
DEBs if moving from gz - lzma. Is this acceptable?
deb creation aka compression shouldn´t bother us as much as installing aka
extraction.
buildds should have
On Dec 18, 2007 9:09 AM, Thilo Six wrote:
comparation of a whole install (download time + extract time):
download time gz (39084/384)= 101.78s + 14.278s = 116.06s
download time 7z (27358/384)= 71.24s + 143.783s = 215.02s
Comparisons like this have far too many factors (as you mentioned
On ma, 2007-12-17 at 13:05 +0100, Krzysztof Lichota wrote:
It is hard to judge best compression using only one package.
On a lark, I ran a little script that re-compresses the components of
a .deb with the desired compression program, and reports results:
bzip2:
Packages, total count: 22485
On Tue, 2007-12-18 at 01:09 +0100, Thilo Six wrote:
~30% less download time
A while ago I read about changing apt/dpkg to allow for the handling of
security updates through binary patches. Does anyone know what came out
of this?
It seems to me that for slower connections, binary patches are
15 matches
Mail list logo
