Carsten Hey dixit:
>IIRC bzip2 had a better compression. Compressing dpkg's changelog on
>stable seems confirm this:
xz’s default compression level -6 is not good for files
smaller than 8 MiB. Try -2 instead, maybe -2e (slower).
Besides, it decompresses a lot faster than bzip2, so even
in case o
#include
* Colin Watson [Mon, Aug 22 2011, 09:35:14PM]:
> On Mon, Aug 22, 2011 at 03:49:04PM +0200, Eduard Bloch wrote:
> > #include
> > * Colin Watson [Mon, Aug 22 2011, 09:27:25AM]:
> > > I don't want to add more linkage, especially in light of Adam's point
> > > about xz not being worth it for
On Mon, Aug 22, 2011 at 03:49:04PM +0200, Eduard Bloch wrote:
> #include
> * Colin Watson [Mon, Aug 22 2011, 09:27:25AM]:
> > I don't want to add more linkage, especially in light of Adam's point
> > about xz not being worth it for most manual pages anyway.
>
> Would you consider additional linka
#include
* Colin Watson [Mon, Aug 22 2011, 09:27:25AM]:
> On Sun, Aug 21, 2011 at 05:39:08PM +0200, Iustin Pop wrote:
> > Since liblzmaX exists, would it be a simple matter of using it in order
> > to make mandb handle such compressed man pages without having to fork?
>
> I don't want to add more
On Mon, Aug 22, 2011 at 09:27:25AM +0100, Colin Watson wrote:
> On Sun, Aug 21, 2011 at 05:39:08PM +0200, Iustin Pop wrote:
> > Since liblzmaX exists, would it be a simple matter of using it in order
> > to make mandb handle such compressed man pages without having to fork?
>
> I don't want to add
On Sun, Aug 21, 2011 at 05:39:08PM +0200, Iustin Pop wrote:
> Since liblzmaX exists, would it be a simple matter of using it in order
> to make mandb handle such compressed man pages without having to fork?
I don't want to add more linkage, especially in light of Adam's point
about xz not being wo
On Sun, Aug 21, 2011 at 09:39:55PM +0200, Adam Borowski wrote:
> Man pages tend to be smaller than that: out of 94752 man pages in main,
> 71966(!) are smaller with gzip, and 94088 have gzip < 110% of xz.
>
> Thus, just as I strongly recommend using xz everywhere for .deb files, let's
> use gzip e
On Sun, Aug 21, 2011 at 04:03:57PM +0100, Colin Watson wrote:
> On Sat, Aug 20, 2011 at 08:30:24PM +0100, Darren Salt wrote:
> > It's worth mentioning that man-db has had xz support since March last year
> > (upstream). This is available in testing.
>
> Although I'd also like to mention that I exp
On Fri, 19 Aug 2011 22:50:47 +0200, Guillem Jover
wrote:
>If you mean doing that at unpack time,
Yes, that's what I mean.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
M
On Sun, Aug 21, 2011 at 04:03:57PM +0100, Colin Watson wrote:
> On Sat, Aug 20, 2011 at 08:30:24PM +0100, Darren Salt wrote:
> > It's worth mentioning that man-db has had xz support since March last year
> > (upstream). This is available in testing.
>
> Although I'd also like to mention that I exp
On Sat, Aug 20, 2011 at 08:30:24PM +0100, Darren Salt wrote:
> It's worth mentioning that man-db has had xz support since March last year
> (upstream). This is available in testing.
Although I'd also like to mention that I expect that it would take
rather longer for mandb to process /usr/share/man
I demand that Adam Borowski may or may not have written...
[snip]
> There's a patch in #572228 (and at least one fool just wrote a duplicate
> before checking for existing ones), but the patch is rotting in the BTS.
I'd forgotten that I'd written that patch. It's still sufficiently cleanly
applic
I demand that James Vega may or may not have written...
> On Tue, Aug 16, 2011 at 01:06:34PM +1000, Russell Coker wrote:
>> On Tue, 16 Aug 2011, Chris Knadle wrote:
[snip; *zless]
>>> Right now these functions are spread across 4 different binaries, each of
>>> which is in a different package.
>>
On Fri, 2011-08-19 at 19:55:12 +0200, Marc Haber wrote:
> On Mon, 15 Aug 2011 18:33:48 +0100, Lars Wirzenius wrote:
> >On the other hand, many computers now have an SSD drive, for speed,
> >which is relatively small. Further, most users will likely need files in
> >/usr/share/doc rarely, if ever,
On Mon, 15 Aug 2011 18:33:48 +0100, Lars Wirzenius wrote:
>On the other hand, many computers now have an SSD drive, for speed,
>which is relatively small. Further, most users will likely need files in
>/usr/share/doc rarely, if ever, so not compressing things risks wasting
>a bunch of disk space f
On Tue, Aug 16, 2011 at 10:43:04AM +1000, Russell Coker wrote:
> On Tue, 16 Aug 2011, Iustin Pop wrote:
> > There is also information on Wikipedia about various compression
> > benchmarks, but IMHO if we want to switch from gzip then bzip2
> > doesn't make sense for /usr/share/doc.
>
> I'd like t
Ben Hutchings wrote:
> Russ Allbery wrote:
> > Are people who are proposing that we change these programs proposing we
> > build a new package with binaries of those same names and use
> > alternatives? That Debian fork gzip? Something else?
>
> I propose that we provide a separate package cont
On 16/08/11 00:10, Carsten Hey wrote:
> bzip2 has a better compression on average for some filetypes, xz[1] has
> a better compression on average for others:
>
>gzip bzip2 xz bzip2+xz[3]
> text files[2] 94312922 73496587 77783076 73496587
> other files
#include
* Adam Borowski [Tue, Aug 16 2011, 12:18:40PM]:
> "zcat" already supports multiple formats: gzip and compress, it's just that
> support for uncompressing the latter is included in gzip's binary. Since
> it's not called "gzcat" but generic "zcat", I think that's a better idea
> than prol
* Adam Borowski , 2011-08-16, 12:18:
zcat and zless are nothing but thin shell wrappers over "gzip -cd",
without loads of extra functionality lesspipe has. I'd turn them into a
C program linked against zlib (priority: required), liblzma2 (priority:
required) and libbz2 (priority: important, mig
On Tue, Aug 16, 2011 at 10:51:30AM -0700, Russ Allbery wrote:
> Adam Borowski writes:
>
> > On the other hand, zcat and zless are nothing but thin shell wrappers
> > over "gzip -cd", without loads of extra functionality lesspipe has. I'd
> > turn them into a C program linked against zlib (priori
Adam Borowski writes:
> On the other hand, zcat and zless are nothing but thin shell wrappers
> over "gzip -cd", without loads of extra functionality lesspipe has. I'd
> turn them into a C program linked against zlib (priority: required),
> liblzma2 (priority: required) and libbz2 (priority: imp
Hi there!
On Tue, 16 Aug 2011 12:43:39 +0200, Vincent Lefevre wrote:
> On 2011-08-15 23:29:17 -0400, James Vega wrote:
>> You mean like lesspipe(1)? Seems like it might need to be updated to
>> handle *.xz, but other than that looks like it fits the bill.
>
> lesspipe(1) from the less package is
On 2011-08-15 23:29:17 -0400, James Vega wrote:
> You mean like lesspipe(1)? Seems like it might need to be updated to
> handle *.xz, but other than that looks like it fits the bill.
lesspipe(1) from the less package is a bit primitive. How about using
Wolfgang Friebel's version, which already su
On Tue, Aug 16, 2011 at 11:50:49AM +0200, Luca Capello wrote:
> On Tue, 16 Aug 2011 10:08:45 +0200, Alexander Reichle-Schmehl wrote:
> > FWIW, if you the following in your bashrc:
> >
> > if [ -f /usr/bin/lesspipe ]; then
>
> I would use the -x expression instead ;-)
>
> And I would also say that
On Tue, Aug 16, 2011 at 04:44:07PM +0800, Chow Loong Jin wrote:
> > Am 16.08.2011 02:43, schrieb Russell Coker:
> >> I'd like to see zless work transparently with bzip and xz compressed
> >> files.
> >> There's really no need for three different wrapper programs when the zless
> >> program can
Hi there!
On Tue, 16 Aug 2011 10:08:45 +0200, Alexander Reichle-Schmehl wrote:
> Am 16.08.2011 02:43, schrieb Russell Coker:
>
>> I'd like to see zless work transparently with bzip and xz compressed files.
>> There's really no need for three different wrapper programs when the zless
>> program
On Tue, Aug 16, 2011 at 10:08:45AM +0200, Alexander Reichle-Schmehl wrote:
> Am 16.08.2011 02:43, schrieb Russell Coker:
>
> > I'd like to see zless work transparently with bzip and xz compressed files.
> >
> > There's really no need for three different wrapper programs when the zless
> > prog
On 16/08/2011 16:08, Alexander Reichle-Schmehl wrote:
> Hi!
>
> Am 16.08.2011 02:43, schrieb Russell Coker:
>
>> I'd like to see zless work transparently with bzip and xz compressed files.
>> There's really no need for three different wrapper programs when the zless
>> program can just consult
Hi!
Am 16.08.2011 02:43, schrieb Russell Coker:
> I'd like to see zless work transparently with bzip and xz compressed files.
> There's really no need for three different wrapper programs when the zless
> program can just consult the magic db to determine which decompression
> program
> to u
On Monday, August 15, 2011, Russell Coker wrote:
> On Tue, 16 Aug 2011, Chris Knadle wrote:
> > > After all, it isn't called gzless.
> >
> > Actually, that's not far off. Right now these functions are
> > spread across 4 different binaries, each of which is in a
> > different package.
>
> Proba
On Tue, Aug 16, 2011 at 01:06:34PM +1000, Russell Coker wrote:
> On Tue, 16 Aug 2011, Chris Knadle wrote:
> > > After all, it isn't called gzless.
> >
> > Actually, that's not far off. Right now these functions are spread
> > across 4 different binaries, each of which is in a different package.
On Tue, 16 Aug 2011, Chris Knadle wrote:
> > After all, it isn't called gzless.
>
> Actually, that's not far off. Right now these functions are spread
> across 4 different binaries, each of which is in a different package.
Probably the best thing to do would be to just incorporate the function
On Monday, August 15, 2011, Ben Hutchings wrote:
> On Tue, 2011-08-16 at 10:43 +1000, Russell Coker wrote:
> > On Tue, 16 Aug 2011, Iustin Pop wrote:
> > > There is also information on Wikipedia about various
> > > compression benchmarks, but IMHO if we want to switch from
> > > gzip then bzip2 do
On Tue, 2011-08-16 at 10:43 +1000, Russell Coker wrote:
> On Tue, 16 Aug 2011, Iustin Pop wrote:
> > There is also information on Wikipedia about various compression
> > benchmarks, but IMHO if we want to switch from gzip then bzip2
> > doesn't make sense for /usr/share/doc.
>
> I'd like to see z
On Tue, 16 Aug 2011, Iustin Pop wrote:
> There is also information on Wikipedia about various compression
> benchmarks, but IMHO if we want to switch from gzip then bzip2
> doesn't make sense for /usr/share/doc.
I'd like to see zless work transparently with bzip and xz compressed files.
There's
* Andreas Barth [2011-08-15 23:59 +0200]:
> * Lars Wirzenius (l...@liw.fi) [110815 23:27]:
> > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote:
> > > * Lars Wirzenius [2011-08-15 18:33 +0100]:
> > > > raw gz xz
> > > > 584163 134 file sizes (MiB)
> > > >
On Mon, Aug 15, 2011 at 11:59:07PM +0200, Andreas Barth wrote:
> * Lars Wirzenius (l...@liw.fi) [110815 23:27]:
> > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote:
> > > * Lars Wirzenius [2011-08-15 18:33 +0100]:
> > > > raw gz xz
> > > > 584163 134 file
* Lars Wirzenius (l...@liw.fi) [110815 23:27]:
> On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote:
> > * Lars Wirzenius [2011-08-15 18:33 +0100]:
> > > raw gz xz
> > > 584163 134 file sizes (MiB)
> > >0421 450 savings compared to raw (Mi
On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote:
> * Lars Wirzenius [2011-08-15 18:33 +0100]:
> > raw gz xz
> > 584163 134 file sizes (MiB)
> >0421 450 savings compared to raw (MiB)
> > -421 0 29 savings compared to cu
* Lars Wirzenius [2011-08-15 18:33 +0100]:
> raw gz xz
> 584163 134 file sizes (MiB)
>0421 450 savings compared to raw (MiB)
> -421 0 29 savings compared to current gz (MiB)
Years ago I compared sizes of compressed files in /usr/
On 15/08/11 at 19:41 +0200, Andreas Barth wrote:
> * Lars Wirzenius (l...@liw.fi) [110815 19:36]:
> > 584163 134 file sizes (MiB)
>
> Thanks for comparing these numbers. That tells me that at least in the
> average case we just can continue with gz, and not care much about the
> r
* Lars Wirzenius (l...@liw.fi) [110815 19:36]:
> 584163 134 file sizes (MiB)
Thanks for comparing these numbers. That tells me that at least in the
average case we just can continue with gz, and not care much about the
relativly small difference to xz.
Andi
--
To UNSUBSCRIBE,
On Mon, Aug 15, 2011 at 05:16:55PM +0900, Charles Plessy wrote:
> Le Mon, Aug 15, 2011 at 01:48:50AM +0200, Adam Borowski a écrit :
> >
> > * A year ago, I repacked CD1, .xz took 66% space needed by .gz. This time,
> > on the whole archive, gains are somewhat smaller: 72%. I guess that CD1
> >
44 matches
Mail list logo
