Re: bzip2 in src tree
John LoVerso wrote: Again, lemmie get on my soap box, and ask have you looked at the man page, and compared the memory required when using -s to the memory required by gzip? Actually, lemmie get on my soap box and ask have you measured the time that bunzip2 takes to run? While it does give better compression in many cases, it is just too SLOW. Using "-s" on decompression just makes it slower. I played on a test machine (PII 233MHz 192Mb, spare ST34502LW disk) with some large package binaries: [...] A decompression time of 13 seconds vs. 67 seconds (or 125 seconds with "-s). Given that ports and packages need a multi-CD anyway, I don't think the speed penalty of bzip2 is worth it. All this apply only when download cost is not considered. IMHO it is clean that CPU time nowadays is much less expensive than the online time, at least for dialup connections. Also you should take into consideration that usually you packing package ONCE, while number of users downloading this package could be very huge, so online costs savings from decreased download time multiplied by the number of downloads and divided by the costs associated with required CPU time increase will be considerable. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
Again, lemmie get on my soap box, and ask have you looked at the man page, and compared the memory required when using -s to the memory required by gzip? Actually, lemmie get on my soap box and ask have you measured the time that bunzip2 takes to run? While it does give better compression in many cases, it is just too SLOW. Using "-s" on decompression just makes it slower. I played on a test machine (PII 233MHz 192Mb, spare ST34502LW disk) with some large package binaries: 17991680 netscape-communicator-4.08.tar 19660800 netscape-communicator-4.61.tar 21934080 netscape-communicator-4.7.tar time gzip *tar 80.284u 1.608s 1:23.66 97.8%113+616k 3+528io 0pf+0w time gunzip *gz 7.984u 1.392s 0:12.84 72.9% 115+674k 498+971io 0pf+0w time bzip2 *tar 220.777u 1.718s 3:44.74 98.9% 61+8531k 936+471io 0pf+0w time bunzip2 *bz2 64.601u 1.928s 1:07.30 98.8%61+4855k 4+964io 0pf+0w time bzip2 -s *tar 205.854u 1.938s 3:32.95 97.5% 61+2388k 1012+492io 1pf+0w time bunzip2 -s *tar 121.860u 2.054s 2:05.65 98.6% 61+3167k 2+965io 0pf+0w A decompression time of 13 seconds vs. 67 seconds (or 125 seconds with "-s). Given that ports and packages need a multi-CD anyway, I don't think the speed penalty of bzip2 is worth it. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
David O'Brien [EMAIL PROTECTED] wrote in list.freebsd-current: 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??? Include another CD-ROM. Go look how many port distribution files on your last CDROM set were in bzip2 format -- there is a reason for that. I think that's because some people -- especially Linux people, as it seems -- think that bzip is ``new and cool''. :-) (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. Then it would have taken even longer. Sometimes you have deadlines, and waiting a few hours longer is just not an option. (In this case I finally decided to not even gzip the stuff, because it saved only a few percent of space.) But this is getting off-topic. I think everyone is entitled to his own opinion about the usefulness of bzip2. But I have yet to hear a good reason why it should replace gzip in the base system of FreeBSD. Not that my opinion matters, though. :-) Using bzip2 for the FreeBSD distribution sets would increase the minimum memory requirement by 4 Mbyte (or about 2.5 Mbyte using the -s option of bunzip2, but which doubles decompression time). 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
At 12:16 PM +0100 2000/1/24, Oliver Fromme wrote: Using bzip2 for the FreeBSD distribution sets would increase the minimum memory requirement by 4 Mbyte (or about 2.5 Mbyte using the -s option of bunzip2, but which doubles decompression time). I really don't see what everyone is getting all worked up about. Okay, we believe that bzip2 is probably going to be somewhat better at compressing the ports tarballs (and presumably other tarballs), but it takes longer to run (both to compress and uncompress?), and presumably requires both more memory and more CPU. But gzip is the established standard, and of all the vendors I know of, only Sun is stupid enough to ship an OS that doesn't have gzip installed on their base system. It's certainly the most backwards compatible, and likely to be the best solution for an install floppy or for running on an older machine. Can't we do both? Use gzip on the install floppy, but include bzip2 in /usr/src, and make sure that all the various programs that deal with tarballs and gzip'ed tarballs can also deal with bzip2 tarballs (including in the ports system)? I mean, if it's in /usr/src, and we have both gzip bzip2 installed on the system, it's up to the user to choose which they prefer and use most of the time, right? And the only cost is the slight expansion of the amount of disk space required to store the source code in /usr/src and the binaries in /usr/bin, as opposed to most people having the port for it installed, with the binaries resident in /usr/local/bin? This can be a win-win situation, can't it? -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. 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 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
On Mon, Jan 24, 2000 at 12:16:32PM +0100, Oliver Fromme wrote: And just how do I increase the space on a CDROM??? Include another CD-ROM. You are missing the point. The installation CDROM only shows you the packages on that CDROM, this gives newbies the impression we don't have very many packages. -- -- 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
On Mon, 24 Jan 2000, Brad Knowles wrote: And the only cost is the slight expansion of the amount of disk space required to store the source code in /usr/src and the binaries in /usr/bin [...] And the time and disk space required to make world. No thank you. Remember that the only win here is if bzip is used in an infrastructural capacity (e.g. for packages and other install stuff), and it has been pointed out that the savings on disk space are offset by the additional memory requirements. If it won't be used for infrastructure, then why can't it stay in ports? -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. 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 bzi
On 23-Jan-00 Rod Taylor wrote: 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... :) The new install system is probably going to use zip rather than bzip2. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.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: Addbzi
At 2:01 PM -0500 2000/1/24, John Baldwin wrote: The new install system is probably going to use zip rather than bzip2. I'm curious as to how a choice like this gets made. Could you elaborate? -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
At 1:17 PM -0500 2000/1/24, Ben Rosengart wrote: And the time and disk space required to make world. No thank you. What is the time disk space requirements without bzip2? I recall multiple hours to do this, and hundreds of MB, but then maybe I'm mis-remembering things. What does bzip2 add to this mix? Doing `cd /usr/ports/archivers/bzip2; /usr/bin/time -alp make` results in the following: real 18.35 user 5.49 sys 8.24 Hmm. Under eighteen seconds to get the port, check the signature, untar it, apply any necessary patches, and build it. Not bad! Certainly not something I'd write home complaining about. 2376 maximum resident set size 318 average shared memory size 280 average unshared data size 130 average unshared stack size 73059 page reclaims 77 page faults 0 swaps 112 block input operations 200 block output operations 0 messages sent 0 messages received 0 signals received 3618 voluntary context switches 7822 involuntary context switches This on a rather busy Freenix Top 100 news peering server (running 3.2-RELEASE, so it's probably not as fast as it could be, especially with the VM changes in -CURRENT). Granted, it is a dual PIII@450 w/ 1MB L2 cache per processor and 1GB RAM, but that doesn't mean that this machine isn't pretty heavily loaded. What is the percentage of additional time and disk space required? I calculate that the additional disk space required is right around 2MB in /usr/ports/archivers/bzip2. This doesn't seem to be a whole lot to me. Remember that the only win here is if bzip is used in an infrastructural capacity (e.g. for packages and other install stuff), and it has been pointed out that the savings on disk space are offset by the additional memory requirements. If it won't be used for infrastructure, then why can't it stay in ports? Actually, I think it would be useful in an infrastructural capacity. In particular, I believe that it would be worthwhile to compress the tarballs used for ports and packages with bzip2, or at least make that an option so that the CD-ROMs we produce can have more ports and packages on that first CD (which appears to be the only thing some morons look at). -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. 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 bzi
At 2:01 PM -0500 2000/1/24, John Baldwin wrote: The new install system is probably going to use zip rather than bzip2. I'm curious as to how a choice like this gets made. Could you elaborate? Zip was selected because it's one of the few compressed bundle formats that allows for random access within the bundle. All of the stream-compressed tape archive variants require you to start at the beginning of the stream and decompress all the way up to the file you want, which is highly undesirable in several of the cases that we care about. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [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 bzi
On 24-Jan-00 Brad Knowles wrote: At 2:01 PM -0500 2000/1/24, John Baldwin wrote: The new install system is probably going to use zip rather than bzip2. I'm curious as to how a choice like this gets made. Could you elaborate? I did not make the choice personally, I believe that was done by Jordan. If I remember correctly, the primary reason is that an archive format that easily and efficiently allows for a subset of the files contained within to be extracted. [bg]zip'd tarballs require you to uncompress and extract the entire tarball and then throw away the data you don't use. Since zip integrates the compression and archiving in one file format, you can look in the zip header, find the file you want, and then extract and uncompress just its data. This functionality is key in the design of the new packaging system as packages will be responsible for extracting themselves in the new system. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
On Mon, 24 Jan 2000, Ben Rosengart wrote: And the time and disk space required to make world. No thank you. Remember that the only win here is if bzip is used in an infrastructural capacity (e.g. for packages and other install stuff), and it has been pointed out that the savings on disk space are offset by the additional memory requirements. If it won't be used for infrastructure, then why can't it stay in ports? Again, lemmie get on my soap box, and ask have you looked at the man page, and compared the memory required when using -s to the memory required by gzip? - alex 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: Addbzi
On Mon, 24 Jan 2000 21:42:45 +0100, Brad Knowles [EMAIL PROTECTED] said: I'm curious as to how a choice like this gets made. Could you elaborate? Other people have answered with the why but not the how. Choices (like this one about archive formats) get made when people sit down and actually do the work to improve FreeBSD. People with commit bits are generally (but not completely) trusted to have an understanding of software-system aesthetics and of the sorts of choices developers might reasonably make on their own. The more effort one is personally willing to put into the project, the greater latitute one has in design. -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 bzip2support for distribution patches)
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. Regards, -- 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)
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 bzip2support for distribution patches)
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? Regards, 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 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 bzip2support for distribution patches)
On Sun, 23 Jan 2000, Chuck Robey wrote: 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. Have you looked at the memory usage when you use the -s flag? - alex 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 bzip2support for distribution patches)
On Sun, 23 Jan 2000, Alex Zepeda wrote: On Sun, 23 Jan 2000, Chuck Robey wrote: 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. Have you looked at the memory usage when you use the -s flag? 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. It's stupid not to have it in a larger system, but *that's the reason for ports*. Ports are optional, right? - alex 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 bzi
On 24-Jan-00 David O'Brien wrote: running Winloose, so I actually *CAN* run this in the background. I certainly was not idle while Bzip2 was compressing. Its pretty annoying waiting for something to compress if you want to do other things that depend on it being compressed.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum 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 bzi
On Mon, 24 Jan 2000, Daniel O'Connor wrote: On 24-Jan-00 David O'Brien wrote: running Winloose, so I actually *CAN* run this in the background. I certainly was not idle while Bzip2 was compressing. Its pretty annoying waiting for something to compress if you want to do other things that depend on it being compressed.. tail -f? *vbg* - alex 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 bzip2support for distribution patches)
On Sat, 22 Jan 2000, Will Andrews wrote: 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. You guys better understand, having software be legally *able* to be in the source tree is a *very* far way from needing it in the source tree. A very strong case would have to be built that we cannot really do without it. Seeing as gzip fills the requirement with undeniably maximum compatibility, the mere fact that bzip2 compresses smaller doesn't sound like a good reason in of and itself. We would not be able to get rid of gzip anyhow (for compatibility reasons) so we'd end up having to have two tools where one does the job well enough now. 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. 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)
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 bzip2support for distribution patches)
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. - alex 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 bzip2support for distribution patches)
On Sat, 22 Jan 2000, Don Lewis wrote: 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. man bzip2, and then look at the memory management section. I'm sure bzip2 takes more memory to encode/decode but I wonder how it compares when using -s. FWIW, I think that there are already problems with installing with less than 12mb ram in the first place (or so I've heard). - alex 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 bzip2support for distribution patches)
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. -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)
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
