Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2. This can make an installation much quicker,
especially when the complete system is installed or
Hello,
On 28/11/2010 22:12, Goran Tal wrote:
> Now that the base system supports xz compression, it should be used as
> the default compression for packages.
>
> Files compressed with xz are smaller and decompress faster than those
> compressed with bzip2. This can make an installation much quick
On Sun, 28 Nov 2010 16:12:48 -0500
Goran Tal wrote:
> Now that the base system supports xz compression, it should be used as
> the default compression for packages.
>
> Files compressed with xz are smaller and decompress faster than those
> compressed with bzip2. This can make an installation mu
Am 28.11.2010 22:12, schrieb Goran Tal:
> Now that the base system supports xz compression, it should be used as
> the default compression for packages.
>
> Files compressed with xz are smaller and decompress faster than those
> compressed with bzip2. This can make an installation much quicker,
>
On 11/29/2010 06:24, Matthias Andree wrote:
> Am 28.11.2010 22:12, schrieb Goran Tal:
>> Now that the base system supports xz compression, it should be used as
>> the default compression for packages.
>>
>> Files compressed with xz are smaller and decompress faster than those
>> compressed with bzi
On Mon, 29 Nov 2010 13:31:10 -0500
jhell wrote:
> On 11/29/2010 06:24, Matthias Andree wrote:
> > Am 28.11.2010 22:12, schrieb Goran Tal:
> >> Now that the base system supports xz compression, it should be
> >> used as the default compression for packages.
> >>
> >> Files compressed with xz are s
Am 29.11.2010 19:31, schrieb jhell:
> Adding to this, as the manual says... The decompressing host will need
> to have at minimal 5% -> 20% of memory 'available' for decompression of
> what the compressing host had. Seeing as FreeBSD still runs on systems
> with memory as little as 200MB "~20% of
On Tue, Nov 30, 2010 at 12:40:33AM +0100, Matthias Andree wrote:
> Yes, would be nice. I doubt it will happen soon.
It's actually being looked at.
As part of the extensive rework of the pointyhat scripts I did this
summer, I attempted to factor out all the magic constants, including
the definiti
On 11/29/2010 18:40, Matthias Andree wrote:
> Am 29.11.2010 19:31, schrieb jhell:
>
>> Adding to this, as the manual says... The decompressing host will need
>> to have at minimal 5% -> 20% of memory 'available' for decompression of
>> what the compressing host had. Seeing as FreeBSD still runs on
On 11/29/2010 23:40, Matthias Andree wrote:
You can specify limits during compression, so the question is should we do that
so that hosts with N MB of RAM can decompress packages? Do we retain the
compression ratio over bzip2 if we limit compression memory to 512 MB so that
decompression would b
Ion-Mihai Tetcu wrote:
> > It would be nice to support xz(1) compression for large selective
> > packages like firefox or openoffice as those will never run on
> > smaller systems.
>
> Trouble is it ain't no way (CPU, space, banhdwidth on our side and
> space,bandwidth on our mirrors side) we cou
30.11.2010 04:40, Julien Laffaye wrote:
You can specify limits during compression, so the question is should we do that
so that hosts with N MB of RAM can decompress packages? Do we retain the
compression ratio over bzip2 if we limit compression memory to 512 MB so that
decompression would be po
On 30 Nov 2010, at 03:16, jhell wrote:
> Agreed. Soon can be quantified by actual need and of which there is not
> much need except for larger packages but adding this would just add
> unneeded complication to the system that is already in place.
We are running out of diskspace on event the FTP
On Sat, Dec 04, 2010 at 11:19:21PM +0100, Simon L. B. Nielsen wrote:
>
> On 30 Nov 2010, at 03:16, jhell wrote:
>
> > Agreed. Soon can be quantified by actual need and of which there is not
> > much need except for larger packages but adding this would just add
> > unneeded complication to the sy
On Fri, 03 Dec 2010 23:07:51 +0200
Volodymyr Kostyrko wrote:
> 30.11.2010 04:40, Julien Laffaye wrote:
> > You can specify limits during compression, so the question is
> > should we do that so that hosts with N MB of RAM can decompress
> > packages? Do we retain the compression ratio over bzip2
> The biggest package that can be produced by a port it's a bit over 10G.
>
Curious - which one?
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebs
Eitan Adler writes:
> > The biggest package that can be produced by a port it's a bit over 10G.
>
> Curious - which one?
OpenOffice(-3)?
Robert Huff
___
freebsd-ports@freebsd.org mailing list
http://lists.
>>
>> Curious - which one?
>
> OpenOffice(-3)?
He told me on IRC - something in games/
$grep -R "NO_PACKAGE" /usr/ports/games :-)
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-port
On Sun, 5 Dec 2010 11:41:29 -0500
Eitan Adler wrote:
> >>
> >> Curious - which one?
> >
> > OpenOffice(-3)?
>
> He told me on IRC - something in games/
>
> $grep -R "NO_PACKAGE" /usr/ports/games :-)
Hum, looks like either they got smaller or QAT doesn't have all the
games packages buil
05.12.2010 18:03, Ion-Mihai Tetcu wrote:
And those ones are all empty at start. So say, if you are compressing
something really huge trying to use 4G of memory you end using that
much memory between 2G - 3G of source data. And we will need 512MB to
decompress that hunk of data.
Are the packages
20 matches
Mail list logo