* Jeffrey J. Mountin ([EMAIL PROTECTED]) [000315 17:35]:
However, if you consider the size of the file and the possibility of
corruption, then it should be archived with gzip and forget the compression
(gzip -1). Now it can be checked for errors.
Isn't there a CHECKSUMS.MD5 file in the
Out of the ether, James FitzGibbon spewed forth the following bits:
It might be nice if there were a utility that could pull the ISO in small
slices just like any distribution and then put it back together. For that
matter, couldn't the ISO image be made into a distribution that sysinstall
On Wed, Mar 15, 2000 at 11:59:29AM -0600, Jeffrey J. Mountin wrote:
However, if you consider the size of the file and the possibility of
corruption, then it should be archived with gzip and forget the compression
(gzip -1). Now it can be checked for errors.
MD5 checksums are more compact
I tend to agree with this. 650MB is way too much - perhaps the images could
be broken up according to the portion of the system (i.e., bin, sbin,
usr.bin, usr.sbin, etc, et cetera).
This is all beginning to smell a lot like a FTP install.
Kelly
--
Kelly Yancey - [EMAIL PROTECTED]
On Fri, Mar 17, 2000 at 10:00:44AM -0500, Kelly Yancey wrote:
This is all beginning to smell a lot like a FTP install.
Exactly. Only thing is, an FTP install requires a usable internet
connection on intended box, which is not always available. ;-)
--
Will Andrews [EMAIL PROTECTED]
GCS/E/S
Had
the file been split and a checksum computed for each piece, I could have
grabbed only the affected portion of the ISO.
This is screaming for an FTP server mod similar to the wuftpd code that will
automatically run tar|gzip. That is, given a file "foo", serve "foo.aa" to be
the first
At 9:46 AM -0500 2000/3/17, Will Andrews wrote:
I tend to agree with this. 650MB is way too much - perhaps the images could
be broken up according to the portion of the system (i.e., bin, sbin,
usr.bin, usr.sbin, etc, et cetera).
I think the entire point of the ISO images is to
At 09:46 AM 3/17/00 -0500, Will Andrews wrote:
On Wed, Mar 15, 2000 at 11:59:29AM -0600, Jeffrey J. Mountin wrote:
However, if you consider the size of the file and the possibility of
corruption, then it should be archived with gzip and forget the
compression
(gzip -1). Now it can be
At 10:12 AM 3/17/00 -0500, Will Andrews wrote:
On Fri, Mar 17, 2000 at 10:00:44AM -0500, Kelly Yancey wrote:
This is all beginning to smell a lot like a FTP install.
Exactly. Only thing is, an FTP install requires a usable internet
connection on intended box, which is not always available.
On Fri, 17 Mar 2000, Will Andrews wrote:
Exactly. Only thing is, an FTP install requires a usable internet
connection on intended box, which is not always available. ;-)
No it doesn't.
Download the binary installation files onto another machine, and burn a CD
with them (you must have a
On Fri, Mar 17, 2000 at 11:42:43AM -0800, Kris Kennaway wrote:
No it doesn't.
Download the binary installation files onto another machine, and burn a CD
with them (you must have a mechanism to burn a CD if you were intending to
burn an ISO image of one). Then use this CD as the media to
On Wed, Mar 15, 2000 at 12:11:48PM -0800, Darryl Okahata wrote:
While you are right about the download/gunzip times, compression
doesn't help that much. As has been mentioned in -hackers, the ISO
images only compress by 3% or so, or around ~20MB. So, instead of a
640MB ISO image, you
At 11:09 PM 3/15/00 +0100, Oliver Fromme wrote:
That's true. Most of the files in the ISO images are already
compressed, so trying to gzip it saves only a few percent.
Also take into account that many people are downloading and
recoding the images on Windows boxes, which don't have gzip
by
On Thu, Mar 16, 2000 at 01:12:39PM -0600, Jeffrey J. Mountin wrote:
Also take into account that many people are downloading and
recoding the images on Windows boxes, which don't have gzip
by default.
And then they can xfer it over to their FBSD system, etc..
You're suggesting that folks
Mar 2000, Matthew Hunt wrote:
: Date: Thu, 16 Mar 2000 14:24:42 -0500
: From: Matthew Hunt [EMAIL PROTECTED]
: To: Jeffrey J. Mountin [EMAIL PROTECTED]
: Cc: [EMAIL PROTECTED]
: Subject: Re: Why not gzip iso images?
:
: On Thu, Mar 16, 2000 at 01:12:39PM -0600, Jeffrey J. Mountin wrote:
:
: Also
After reading the announcement...
Congratulations to the FreeBSD community
another milestone!
A great OS...
But for the ISO images... IS it a problem to gzip
them
They take less space on the master site and the mirror
sites and they take less bandwidth!
Shouldn't be a problem I think!
]
: To: [EMAIL PROTECTED]
: Subject: Why not gzip iso images?
:
: After reading the announcement...
: Congratulations to the FreeBSD community
: another milestone!
: A great OS...
:
: But for the ISO images... IS it a problem to gzip
: them
: They take less space on the master site and the mirror
Matt Heckaman wrote:
It's been my experience that gzipping an ISO (or other compression tools)
do not make enough different to justify the time it takes to both compress
and uncompress these things. For example, the time needed to un-gzip the
ISO could be longer than the time it would take to
* Kai Voigt [EMAIL PROTECTED] [000315 05:47] wrote:
Matt Heckaman wrote:
It's been my experience that gzipping an ISO (or other compression tools)
do not make enough different to justify the time it takes to both compress
and uncompress these things. For example, the time needed to un-gzip
On Wed, 15 Mar 2000, Alfred Perlstein wrote:
I feel pretty confident assuming that most people that burn ISOs probably
keep enough disk space free to hold one and not much more, going from
a requirement of ~650MB to ~1.2GB wouldn't be a smart move imo.
fetch -o - ftp://path/to/iso.gz |
On Wed, Mar 15, 2000 at 08:14:37AM -0500, Matt Heckaman wrote:
It's been my experience that gzipping an ISO (or other compression tools)
do not make enough different to justify the time it takes to both compress
and uncompress these things. For example, the time needed to un-gzip the
ISO
At 05:53 AM 3/15/00 -0800, Alfred Perlstein wrote:
* Kai Voigt [EMAIL PROTECTED] [000315 05:47] wrote:
Matt Heckaman wrote:
It's been my experience that gzipping an ISO (or other compression tools)
do not make enough different to justify the time it takes to both
compress
and
Anatoly Vorobey [EMAIL PROTECTED] wrote:
On Wed, Mar 15, 2000 at 08:14:37AM -0500, Matt Heckaman wrote:
It's been my experience that gzipping an ISO (or other compression tools)
do not make enough different to justify the time it takes to both compress
and uncompress these things. For
Jeffrey J. Mountin [EMAIL PROTECTED] wrote in list.freebsd-current:
AFAICR, the one time that a gzip and bzip version were available the size
was not all that significant and there were promptly removed.
That's true. Most of the files in the ISO images are already
compressed, so trying to
On Wed, 15 Mar 2000, Anatoly Vorobey wrote:
Alas, that is just not true for many of us who are in bandwidth-poor
countries. Over here, it can take 3 to BIGNUM hours to download an ISO
image (there aren't any up-to-date local mirrors), depending on time of
day and the phase of the moon. I
| Alas, that is just not true for many of us who are in bandwidth-poor
| countries. Over here, it can take 3 to BIGNUM hours to download an ISO
| image (there aren't any up-to-date local mirrors), depending on time of
| day and the phase of the moon. I think compression would definitely
On Mar 15, 9:03am, Kris Kennaway wrote:
} Subject: Re: Why not gzip iso images?
} On Wed, 15 Mar 2000, Alfred Perlstein wrote:
}
} I feel pretty confident assuming that most people that burn ISOs probably
} keep enough disk space free to hold one and not much more, going from
} a requirement
But for the ISO images... IS it a problem to gzip
them
They take less space on the master site and the mirror
sites and they take less bandwidth!
Since almost the entire content of the ISO image is already gzipped, the
size savings works out to be a percent or two, or at least did when
28 matches
Mail list logo
