🚀 go-pugleaf

If your short on space, wouldn't it make sense to just host bz2?

On 4 Jan 1999 23:16:57 GMT, in aus.computers.linux jason@dstc.edu.au (jason
andrade) wrote:

>mirror.aarnet.edu.au is now an official mirror for the
>linux kernel archive in australia at:
>
>ftp://ftp.au.kernel.org/pub/linux/
>ftp://ftp.au.kernel.org/pub/software/
>
>http://www.au.kernel.org/pub/linux/
>http://www.au.kernel.org/pub/software/
>
>we're currently hosting the complete .gz archive, (no bzip2)
>but hope to add bz2 support once some disk space issues are
>sorted out.
>
>the mirror is updated every 2 hours, in an effort to be
>as up to date as possible, from the master distribution
>site at kernel.org.
>
>please try and use a local mirror first as ftp.kernel.org
>is heavily loaded.
>
>comments/queries/feedback to mirror@mirror.aarnet.edu.au
>
>-jason


--
Steven Blunt
spblunt@ozemail.com.au
http://enterfornone.simplenet.com/

On Tue, 05 Jan 1999 13:53:28 GMT, Steven Blunt <spblunt@ozemail.com.au> wrote:
>If your short on space, wouldn't it make sense to just host bz2?
>

Based on my (single) observation, I think that .gz is the better
choice.  Uncompressing .bz2 files appears to be a real memory hog.  I
once made the mistake of downloading a large .bz2 compressed file to a
machine with 8MByte memory.  Uncompressing it caused the machine to
swap like crazy; from memory, it took nearly an hour to complete the
uncompressing.

-- 
-----------------------------------------------------------------------------
Bill Metzenthen        | See http://www.suburbia.net/~billm/ for information
billm@melbpc.org.au    | on an 80x87 FPU emulator, using floating point
billm@suburbia.net     | (particularly on Linux), and code for manipulating
Melbourne, Australia   | the floating point environment on 80x86 Linux.
-----------------------------------------------------------------------------

spblunt@ozemail.com.au (Steven Blunt) writes:

>If your short on space, wouldn't it make sense to just host bz2?

there is a minimal difference between the total size of the .gz files
and the .bz2 files (about 400M).

given that the vast majority of users are using .gz, i'm extremely
reluctant to not be able to provide the files in .gz format.  it's
also assumed that .bz2 aware users can easily use .gz files.  the
"short on space" problem arises if you maintain a full archive
of both .gz and .bz2 which requires almost twice the disk as
just one of them.

-jason
--
 jason andrade       dstc pty ltd               jason@dstc.edu.au
 senior sysadmin     level 7, GPS Building 78   i just wanna be         
 phn +61-7-33654307  university of queensland   bluemisty
 fax +61-7-33654311  queensland 4072 australia  and barefooted  

billm@melbpc.org.au (Bill Metzenthen) writes:

>Based on my (single) observation, I think that .gz is the better
>choice.  Uncompressing .bz2 files appears to be a real memory hog.  I
>once made the mistake of downloading a large .bz2 compressed file to a
>machine with 8MByte memory.  Uncompressing it caused the machine to
>swap like crazy; from memory, it took nearly an hour to complete the
>uncompressing.

it's not just memory.. i saw some benchmarks that show it's also
far more cpu intensive than .gz is for linux kernel files.

comparing gzip -9 (not the default) and bzip2, you can get between
12-40% byte savings, but it can take 2-5 times as long to compress
and decompress files.

-jason
--
 jason andrade       dstc pty ltd               jason@dstc.edu.au
 senior sysadmin     level 7, GPS Building 78   i just wanna be         
 phn +61-7-33654307  university of queensland   bluemisty
 fax +61-7-33654311  queensland 4072 australia  and barefooted