Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 would have no other programs to work with it. :-) best; gjvc -- [gjvc] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 files to meet an immediate need, and actually care how long it takes since whatever they're doing is blocked until the compression completes. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 will remain with us for a long time. For those of us who eschew bloatware, it continues to be entirely adequate. 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 nowadays, but upgrading to a CPU that is 10 times faster is not. (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 went into the trash can.) I'd vote for keeping things as they are: bzip2 is fine as a port. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 nowadays, but upgrading to a CPU that is 10 times faster is not. But when one compresses a file with bzip2 and prepare a smaller distribution, hundreds of people can save their download time. That's why we compress things. I'd focus on the receivers' side. Of course a necessary manner is preparing also a gzip'ed file for those who prefer gzip's less memory usage rather than bzip2's higher compression. And still, a standard is a standard. (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 went into the trash can.) Not everyone wants/needs to compress such a big stuff with bzip2 to waste time. But having bzip2/bunzip2 gives us an option. I'd vote for keeping things as they are: bzip2 is fine as a port. Despite all of above, I have to agree that, since whether having bzip2 is already an option thanks to the port. :) -- / /__ __ / ) ) ) ) / http://www.idaemons.org/knu/ Akinori MUSHA aka / (_ / ( (__( mailto:[EMAIL PROTECTED] "We are but hungry.. Associated Ita-meshi Daemons!" http://www.idaemons.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #77: Thu Dec 30 12:49:51 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 gzip. Having bzip2 as a port is enough IMO. Not only is it slower (and more memory-hungry), but it was designed and optimized for compressing text. The less text-like the input is, the worse bzip2 fares; in my tests, when compressing the output of /dev/urandom, it runs seven times slower than gzip, and produces a slightly larger output file: des@des ~/test% dd if=/dev/urandom of=random bs=1024 count=$((16*1024)) 16384+0 records in 16384+0 records out 16777216 bytes transferred in 21.406185 secs (783756 bytes/sec) des@des ~/test% time gzip -c random random.gz gzip -c random random.gz 12.62s user 0.63s system 88% cpu 14.997 total des@des ~/test% time bzip2 -c random random.bz bzip2 -c random random.bz 83.16s user 1.02s system 80% cpu 1:44.42 total des@des ~/test% ll total 49256 -rw-r--r-- 1 des des 16777216 Jan 23 18:48 random -rw-r--r-- 1 des des 16850433 Jan 23 18:54 random.bz -rw-r--r-- 1 des des 16779801 Jan 23 18:52 random.gz Of course, this is a worst-case scenario for both gzip and bzip2. Let's see how they fare with a tarball of the -CURRENT kernel tree: des@des ~/test% lcvs co sys /dev/null 21 des@des ~/test% tar cf sys.tar sys des@des ~/test% rm -rf sys des@des ~/test% time gzip -c sys.tar sys.tar.gz gzip -c sys.tar sys.tar.gz 37.46s user 1.04s system 89% cpu 43.062 total des@des ~/test% time bzip2 -c sys.tar sys.tar.bz bzip2 -c sys.tar sys.tar.bz 140.02s user 1.21s system 96% cpu 2:26.18 total des@des ~/test% ll total 59360 -rw-r--r-- 1 des des 43673600 Jan 23 19:10 sys.tar -rw-r--r-- 1 des des 7492474 Jan 23 19:22 sys.tar.bz -rw-r--r-- 1 des des 9554566 Jan 23 19:15 sys.tar.gz des@des ~/test% echo $((7492474*100/9554566)) 78 Much better! a 22% improvement over gzip - but it took nearly four times as long... How about my mail archive? des@des ~/test% tar cf mail.tar ~/Mail tar: Removing leading / from absolute path names in the archive. des@des ~/test% time gzip -c mail.tar mail.tar.gz gzip -c mail.tar mail.tar.gz 10.99s user 0.80s system 93% cpu 12.665 total des@des ~/test% time bzip2 -c mail.tar mail.tar.bz bzip2 -c mail.tar mail.tar.bz 64.16s user 0.77s system 92% cpu 1:10.40 total des@des ~/test% ll total 31048 -rw-r--r-- 1 des des 26204160 Jan 23 19:33 mail.tar -rw-r--r-- 1 des des 2329178 Jan 23 19:36 mail.tar.bz -rw-r--r-- 1 des des 3210845 Jan 23 19:34 mail.tar.gz des@des ~/test% echo $((2329178*100/3210845)) 72 Even better than source code, yet even slower. Mail is less repetitive than source code, but the repeated strings are longer - source code has much more punctuation (including operators) than text. This is the kind of data bzip2 excels at. How about a kernel? des@des ~/test% cp /kernel . des@des ~/test% time gzip -c kernel kernel.gz gzip -c kernel kernel.gz 2.02s user 0.02s system 98% cpu 2.068 total des@des ~/test% time bzip2 -c kernel kernel.bz bzip2 -c kernel kernel.bz 4.62s user 0.09s system 98% cpu 4.766 total des@des ~/test% ll total 2936 -r-xr-xr-x 1 des des 1597538 Jan 23 19:42 kernel* -rw-r--r-- 1 des des 669729 Jan 23 19:42 kernel.bz -rw-r--r-- 1 des des 696809 Jan 23 19:42 kernel.gz des@des ~/test% echo $((669729*100/1597538)) 41 des@des ~/test% echo $((696809*100/1597538)) 43 des@des ~/test% echo $((669729*100/696809)) 96 Very little improvement, and a fairly large time penalty, though the sample is too small for the comparison to make much sense (we don't know enough about overhead). Let's strip the kernel: des@des ~/test% strip kernel des@des ~/test% time gzip -c kernel kernel.gz gzip -c kernel kernel.gz 1.77s user 0.04s system 96% cpu 1.884 total des@des ~/test% time bzip2 -c kernel kernel.bz bzip2 -c kernel kernel.bz 5.80s user 0.04s system 97% cpu 5.989 total des@des ~/test% ll total 2488 -r-xr-xr-x 1 des des 1328176 Jan 23 19:44 kernel* -rw-r--r-- 1 des des 575566 Jan 23 19:45 kernel.bz -rw-r--r-- 1 des des 605411 Jan 23 19:44 kernel.gz des@des ~/test% echo $((575566*100/1328176)) 43 des@des ~/test% echo $((605411*100/1328176)) 45 des@des ~/test% echo $((575566*100/605411)) 95 Both gzip and bzip2 do worse with a stripped kernel than with an unstripped one, because what we stripped away (function and variable names) is repetitive and covers a small portion of the alphabet, and therefore compresses well. Now, here's the killer: a 2.5 MB text file which gzip compresses significantly better than bzip2: des@des ~/test% cp /usr/share/dict/web2 . des@des ~/test% time gzip -c web2 web2.gz gzip -c web2 web2.gz 4.25s user 0.06s system 99% cpu 4.319 total des@des ~/test% time bzip2 -c web2 web2.bz bzip2 -c web2 web2.bz 5.86s user 0.07s system 98% cpu 5.998 total des@des ~/test% ll
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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, emacs is a fine port too, but it'll never get into the base system. Very true, but i can actually think of one thing were bzip2 would really be useful: to better compress the kernel on install floppies so you could keep more things in it. (like ptys and pass which would make fixit more useful, or pppoe which was thrown out too recently if i'm not mistaken.) Btw you could probably also kgzip the loader, that would free up some space too. Juergen Lock: It's Better! Chuck:Better doesn't count, only need, functionality and compatibility. Juergen Lock: It's Better! How come I get the feeling that you didn't read the post? Oh, the original poster wasn't me. And how `critical' the capabilities of the kernel on the install floppy are is debatable i'd say. (Of course you probably could make a seperate one for pppoe installs by leaving out other things in that, and for fixit just make your own boot floppy... but both of these at least make things more complicated for the newbies.) Regard, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 look how many port distribution files on your last CDROM set were in bzip2 format -- there is a reason for that. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 went into the trash can.) Am I the only one that uses UNIX as a multitasking OS? nice the bzip2 process by 20 and background it. Geez. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 just how do I increase the space on a CDROM??? Go look how many port distribution files on your last CDROM set were in bzip2 format -- there is a reason for that. David, no one is arguing if bzip2 is or is not a good tool, nor are they arguing if it's good for ports. The answer to both those arguments is very obviously "yes". The argument was whether, currently, bzip2 should be placed in the source tree for the base system. We *don't* need two compressors, and (again currently) gzip is overwhelmingly more popular at ftp sites than bzip2. Furthermore bzip2 has drawbacks for running on the core system, most especially for small ones. I don't need to go over those, you already know them. Lifting those restrictions is not necessary for the base system, seeing as it would have fatal drawbacks for small systems which would see no help from bzip2 (small systems don't have ports). It is a very good thing to have bzip2 on your system, but it's *not* a requirement. Like I said before, most of the same arguments apply to, say, emacs. You'd have to be nuts (if you ran a good sized system) not to have bzip2, but it's just not a requirement. Having a compressor at all is the requirement, and gzip currently is better for that. Ask me again in 18 months, maybe bzip2 will use less memory and be faster, and it's quite likely that it will be far more popular at ftp sites. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 if it took longer, I enjoy the better compression and I'm not running Winloose, so I actually *CAN* run this in the background. I certainly was not idle while Bzip2 was compressing. Using it for one-shot compression (e.g. compressing backup archives, or in a gather-compress-transfer-decompress-process pipeline to save bandwidth) is downright stupid unless the cost of storing or transferring the compressed data is unusually high. Feh. Your opinion. Why is it stupid? When is the cost of transfer not high? Most at home only have 53Kbps download speed. I can start the compression of what I want to take home before I leave the lab, by the time I'm home, it is done and I start the download. I Bzip2 *everything*. When I moved to Bzip2 a year ago, I bzip2'ed and gzip'ed every to keep the smaller of the two. Only 2% of my bzip2'ed files were larger. I don't ever bother comparing anymore. Not only is it slower (and more memory-hungry), but it was designed and optimized for compressing text. The less text-like the input is, the worse bzip2 fares; Lets look at the Ports distfiles on the FreeBSD CDROM: I grabbed a few -- the kde stuff, GCC, qt, rxvt, tin, xchat: the BZIP'ed versions = 35625 Kbytes the GZIP'ed versions = 47593 Kbytes a savings of 11MB on a small sample size. The 3.1 CDROM set had 946M of packages. If these had been bzip2'ed, it would have taken 843M. [ BTW, while downloading the KDE files looks like I was saving significant download time (and this was over 10Mbit Ethernet over an OC3 pipe to the Internet)] kdeadmin-1.1.2.tar.bz2: 722195 bytes received in 26.38 seconds, 26.73 kB/s. kdeadmin-1.1.2.tar.gz: 1175621 bytes received in 44.44 seconds, 25.84 kB/s. kdebase-1.1.2.tar.bz2: 7181379 bytes received in 219.63 seconds, 31.93 kB/s. kdebase-1.1.2.tar.gz: 9178899 bytes received in 416.31 seconds, 21.53 kB/s. kdegames-1.1.2.tar.bz2: 2268814 bytes received in 82.58 seconds, 26.83 kB/s. kdegames-1.1.2.tar.gz: 2965071 bytes received in 136.58 seconds, 21.20 kB/s. kdegraphics-1.1.2.tar.bz2: 1759634 bytes received in 69.06 seconds, 24.88 kB/s. kdegraphics-1.1.2.tar.gz: 2595697 bytes received in 92.14 seconds, 27.51 kB/s. kdelibs-1.1.2.tar.bz2: 1436365 bytes received in 44.88 seconds, 31.26 kB/s. kdelibs-1.1.2.tar.gz: 2001196 bytes received in 69.84 seconds, 27.98 kB/s. kdemultimedia-1.1.2.tar.bz2: 1543683 bytes received in 46.02 seconds, 32.76 kB/ kdemultimedia-1.1.2.tar.gz: 2034164 bytes received in 61.22 seconds, 32.45 kB/s kdenetwork-1.1.2.tar.bz2: 2926118 bytes received in 95.69 seconds, 29.86 kB/s. kdenetwork-1.1.2.tar.gz: 4515573 bytes received in 154.57 seconds, 28.53 kB/s. kdesupport-1.1.2.tar.bz2: 979489 bytes received in 34.06 seconds, 28.08 kB/s. kdesupport-1.1.2.tar.gz: 1209234 bytes received in 30.06 seconds, 39.29 kB/s. kdetoys-1.1.2.tar.bz2: 318167 bytes received in 16.68 seconds, 18.63 kB/s. kdetoys-1.1.2.tar.gz: 378929 bytes received in 9.23 seconds, 40.09 kB/s. kdeutils-1.1.2.tar.bz2: 1603520 bytes received in 41.20 seconds, 38.01 kB/s. kdeutils-1.1.2.tar.gz: 2409082 bytes received in 63.95 seconds, 36.79 kB/s. korganizer-1.1.2.tar.bz2: 737251 bytes received in 27.96 seconds, 25.75 kB/s. korganizer-1.1.2.tar.gz: 922786 bytes received in 19.96 seconds, 45.14 kB/s. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 distribution, we'd be able to fit more Packages on the 1st CDROM, and that is a BIG win. With it in the base system, we could also make pkg_add understand bzip2'ed packages -- again a BIG win as we could then fit more packages on the 1st CDROM. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 /usr/ports/archivers/bzip2]% cat pkg/DESCR This is bzip2, a advanced block-sorting file compressor. It is believed to be free from any patents. WWW: http://sourceware.cygnus.com/bzip2/ 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. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 bzip2 format is actually less effective than gzip? It depends on what you're compressing. For some things, gzip is better, and for yet other stuff, bzip2 gives much better compression. I think it would be neat to incorporate both gzip and and bzip2 into one executable, and have the compression program determine which algorithm is best. And then, when uncompressing, the program would autodetect which method (bzip2 or gzip) was used to compress the file. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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... seems NetBSD folks already have bzip2 in their source tree, while OpenBSD folks not. Then how about us? IMHO, bzip2 tarballs are increasing in number out there because each software is growing bigger and bigger nowadays, and thus in great demand is the better compression: i.e. bzip2 rather than gzip. I don't think we should compress everything with bzip2 instead of gzip, however, I believe we'd better have bunzip2 by default as there are many software which both *.gz and *.bz2 are provided for download, such as Lynx, WindowMaker, GIMP, KDE and Linux kernel. Yes, they are pretty big enough to see the difference between two... .tar.bz2.tar.gz lynx2.8.2rel11.4MB 1.8MB WindowMaeker 0.61.1 1.6MB 1.9MB gimp-1.1.13 6.2MB 8.0MB kdebase-1.1.27.0MB 8.9MB linux-2.2.1412.3MB 15.2MB It's crystal clear bzip2 wins in these cases. and far enough. -- / /__ __ / ) ) ) ) / http://www.idaemons.org/knu/ Akinori MUSHA aka / (_ / ( (__( mailto:[EMAIL PROTECTED] "We are but hungry.. Associated Ita-meshi Daemons!" http://www.idaemons.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 never get into the base system. I don't think we should compress everything with bzip2 instead of gzip, however, I believe we'd better have bunzip2 by default as there When the port compressed with bzip2 is installed, the extraction mechanism is downloaded and installed on the fly. Thats more than enough. 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 FreeBSD installs, I'm willing to let it 'auto-install itself'. -- Rod Taylor Partner of Zort (zort.on.ca) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
-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 6.2MB 8.0MB kdebase-1.1.2 7.0MB 8.9MB linux-2.2.14 12.3MB 15.2MB It's crystal clear bzip2 wins in these cases. and far enough. Then look at the memory overhead caused by bzipping versus gzipping and you'll loose. Anyways, we have had this discussion a few times in the past. Lets consult the archives and see what the reason was why we didn't do it back then. I am in favor with Chuck here. Its fine as it is, as a port. -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Ain't gonna spend the rest of my Life, quietly fading away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 FreeBSD installs, I'm willing to let it 'auto-install itself'. What if we began to use bzip2 instead of gzip for things like man pages, or releases, etc? I think gzip is somewhat like compress, in that it might never go away completely, but it's generally been superceded by (IMO) bzip2. Agreed, then it'd be useful. I also noticed a message Jordan sent through the list oneday mentioning the possible use of Bzip2 for a new package structure. I do believe that the system should have bzip in it, but because it's being used by freebsd internals itself, not because a person may use it at one point. Make gzip the port in 5.0, and bzip the root compressor... :) -- Rod Taylor Partner of Zort (zort.on.ca) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
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 thats installed. Unless bzip is used } by 99.9% of the FreeBSD installs, I'm willing to let it } 'auto-install itself'. } } What if we began to use bzip2 instead of gzip for things like man pages, } or releases, etc? I did that (for man pages) out of curiosity a year or two ago, and the difference was negligible. bzip2 seems to do better on bigger files as a (very) general rule than on smaller ones. } I think gzip is somewhat like compress, in that it might never go away } completely, but it's generally been superceded by (IMO) bzip2. I don't agree at all, and all you have to do is visit a few web sites and ftp sites' download areas to see why. It's just not ubiquitous, or even close. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
