Date: Tue, 30 Mar 1999 14:25:31 -0800 (PST) From: asami@FreeBSD.ORG (Satoshi - the Wraith - Asami) To: dillon@apollo.backplane.com Cc: obrien@NUXI.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: ports/news/tin Makefile ports/news/tin/files md5 Message-ID: <199903302225.OAA41075@silvia.hip.berkeley.edu> In-Reply-To: <199903300812.AAA37985@apollo.backplane.com> (message from Matthew Dillon on Tue, 30 Mar 1999 00:12:53 -0800 (PST)) References: <19990327085310.A87737@relay.nuxi.com> <14490.922553771@critter.freebsd.dk> <19990329232243.A79481@dragon.nuxi.com> <199903300759.XAA37851@apollo.backplane.com> <19990330000135.A20563@relay.nuxi.com> <199903300812.AAA37985@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Matthew Dillon <dillon@apollo.backplane.com> * There's an old axiom in computer science about things filling all * available space. Believe me, bzip2 is not going to solve this sort * of problem. I know about that, but that doesn't stop us from going to a more efficient compressing algorithm (assuming the speed/memory consumption problem is not too bad). The savings are proportional to the total size of the collection, and that's a good 10% saved any day. On the other hand, I don't see much point in the "should we mark the gimp PS manual NO_CDROM" debate. The amount saved is fixed, and the old axiom applies. We already have Steve trimming things out as (un)necessary, you should just leave this stuff to him. Setting it NO_CDROM is going to remove any possibility of it showing up for future releases even if we have enough space (hey Jordan, when are we going to that 10-CD set?) -W To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903302225.OAA41075>