Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-24 Thread George Cox
On 23/01 22:36, David O'Brien wrote: BUT, if we bzip2'ed the base system distribution, we'd be able to fit more Packages on the 1st CDROM, and that is a BIG win. With it in the This would indeed be good. Let's also remember that 'tar' has built-in support for bzip2 so it's not as if it

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-24 Thread Garrett Wollman
On Sun, 23 Jan 2000 19:46:47 -0800, "David O'Brien" [EMAIL PROTECTED] said: Am I the only one that uses UNIX as a multitasking OS? nice the bzip2 process by 20 and background it. Geez. Perhaps you're the only one who compresses files just for the hell of it. Most people normally compress

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Oliver Fromme
Garrett Wollman [EMAIL PROTECTED] wrote in list.freebsd-current: If I may inject some possibly-irrelevant fact into this discussion... gzip (or rather, the ``deflate'' compression algorithm and the libz file format) has been adopted into a number of formal standards. It's likely that it

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Akinori MUSHA aka knu
At Sun, 23 Jan 2000 10:26:48 +0100 (CET), Oliver Fromme [EMAIL PROTECTED] wrote: I don't like bzip2 for the sole fact that it takes _ages_ to compress files, compared to gzip. Saving 10% or 20% on disk space is not worth wasting = 10 times more CPU time than gzip. Disk space is cheap

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Ollivier Robert
According to Don Lewis: Doesn't bzip2 require a lot more memory for decompression? As I recall, someone mentioned that this would cause problems for installing releases on machines with only a small amount of RAM. Yes and is much slower than gzip. Having bzip2 as a port is enough IMO. --

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Dag-Erling Smorgrav
Ollivier Robert [EMAIL PROTECTED] writes: According to Don Lewis: Doesn't bzip2 require a lot more memory for decompression? As I recall, someone mentioned that this would cause problems for installing releases on machines with only a small amount of RAM. Yes and is much slower than

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Juergen Lock
On Sun, Jan 23, 2000 at 03:01:23PM -0500, Chuck Robey wrote: On Sun, 23 Jan 2000, Juergen Lock wrote: In article [EMAIL PROTECTED] you write: ... A case would have to be built that bzip2 does something critical that cannot be done without bzip2. Else, it stays as a fine port. Heck,

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread David O'Brien
On Sun, Jan 23, 2000 at 10:26:48AM +0100, Oliver Fromme wrote: Saving 10% or 20% on disk space is not worth wasting = 10 times more CPU time than gzip. Disk space is cheap nowadays, but upgrading to a CPU that is 10 times faster is not. And just how do I increase the space on a CDROM??? Go

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread David O'Brien
On Sun, Jan 23, 2000 at 10:26:48AM +0100, Oliver Fromme wrote: (I once tried to compress our FreeBSD ISO images with bzip2, just to compare the space savings with gzip. I aborted the experiment after 6 hours (!). gzip took about 30 minutes. Consequently, bzip2 was considered unusable and

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread Chuck Robey
On Sun, 23 Jan 2000, David O'Brien wrote: On Sun, Jan 23, 2000 at 10:26:48AM +0100, Oliver Fromme wrote: Saving 10% or 20% on disk space is not worth wasting = 10 times more CPU time than gzip. Disk space is cheap nowadays, but upgrading to a CPU that is 10 times faster is not. And

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread David O'Brien
On Sun, Jan 23, 2000 at 08:21:12PM +0100, Dag-Erling Smorgrav wrote: Taking my 243662 KB ~/Mail: gzip -9 every file: 80420 KB bzip2 -9 every file:70034 KB tar ~/Mail and gzip -9: 78840 KB(4m37s) tar ~/Mail and bzip2 -9:68960 KB(14m29s) Who cares

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-23 Thread David O'Brien
On Mon, Jan 24, 2000 at 01:19:32AM -0500, Chuck Robey wrote: No, I said ask me again in 18 months, not NOW. Even if it didn't have the memory problem, gzip has greater compatibility and does the minimum job. It's not required for the base system. BUT, if we bzip2'ed the base system

bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Will Andrews
On Sun, Jan 23, 2000 at 12:44:46AM +0900, [EMAIL PROTECTED] wrote: Truely, I wish to import bzip2 to -current src tree. :) Is there a problem about some restriction for distributing bzip2? # I'm sorry I don't know about that. 2 5003-0 (00-01-22 12:27:37) [will@shadow

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Donn Miller
Will Andrews wrote: Nope - looks like it could be a candidate for importing to the source tree. However, I'm not sure everyone on current@ is going to agree, since we already have something for compression (gzip) that is pretty standard around the world. Ever notice how on some occasions

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Akinori MUSHA aka knu
At Sat, 22 Jan 2000 12:42:55 -0500 (EST), Chuck Robey [EMAIL PROTECTED] wrote: A case would have to be built that bzip2 does something critical that cannot be done without bzip2. Else, it stays as a fine port. Heck, emacs is a fine port too, but it'll never get into the base system. Hmm...

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Rod Taylor
On Sat, 22 Jan 2000, you wrote: At Sat, 22 Jan 2000 12:42:55 -0500 (EST), Chuck Robey [EMAIL PROTECTED] wrote: A case would have to be built that bzip2 does something critical that cannot be done without bzip2. Else, it stays as a fine port. Heck, emacs is a fine port too, but it'll

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Jeroen Ruigrok/Asmodai
-On [2123 00:01], Akinori MUSHA aka knu ([EMAIL PROTECTED]) wrote: Yes, they are pretty big enough to see the difference between two... .tar.bz2.tar.gz lynx2.8.2rel1 1.4MB 1.8MB WindowMaeker 0.61.1 1.6MB 1.9MB gimp-1.1.13

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Rod Taylor
On Sat, 22 Jan 2000, you wrote: On Sat, 22 Jan 2000, Rod Taylor wrote: Personally, I'd like to see less stuff in the system source for smaller installs and lower compile time leaving it up to me to customize the individual stuff thats installed. Unless bzip is used by 99.9% of the

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Don Lewis
On Jan 22, 5:04pm, Alex Zepeda wrote: } Subject: Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip } What if we began to use bzip2 instead of gzip for things like man pages, } or releases, etc? Doesn't bzip2 require a lot more memory for decompression? As I recall, someone

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

2000-01-22 Thread Jon Hamilton
In message Pine.BSF.4.21.0001221703020.4454-10@localhost, Alex Zepeda wro te: } On Sat, 22 Jan 2000, Rod Taylor wrote: } } Personally, I'd like to see less stuff in the system source for } smaller installs and lower compile time leaving it up to me to } customize the individual stuff