From owner-freebsd-hackers Mon Mar 13 16:19:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA02615 for hackers-outgoing; Mon, 13 Mar 1995 16:19:47 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA02607 for ; Mon, 13 Mar 1995 16:19:42 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA04007; Mon, 13 Mar 1995 17:23:36 -0700 Date: Mon, 13 Mar 1995 17:23:36 -0700 From: Nate Williams Message-Id: <199503140023.RAA04007@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: install compressed binary patch" (Mar 13, 4:05pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp , kargl@troutmask.apl.washington.edu (Steven G Kargl) Subject: Re: install compressed binary patch Cc: freebsd-hackers@freefall.cdrom.com Sender: hackers-owner@FreeBSD.org Precedence: bulk > > I have added a `-z' option to install. > 2. I'm not sure it makes much sense to do it in the first place. > > Let me explain what I mean. On any machine capable of doing a make world, > you should not need to used gzip bin's on a large scale. Correct, but wouldn't it be nice to have a gzip'd DESTDIR tree for a laptop distribution? It's much nicer to have the install target do it automatically for you. > Wouldn't you gain more diskspace if you told cc(1) about ".gz" files for > instance ? source compress better than binary I'd expect... Ouch. It would be much nicer to have the CDROM have symlink objs on it already which point to a place where you could have writable files. That way you could compile off the CD w/out having to build a big symlink tree. Now THAT'S an easy project which would be fairly trivial to do. > Take a copy of the "nullfs", and call it "gzipfs", and it's perfectly OK > if it can only mount read-only. > The only difference from nullfs should be that if the file > when read contains a "gzip" header, you uncompress it on the fly... > The "inflate" code is already in the kernel... If anyone is interested in this, Jaye Mathisen and I tossed around this idea a couple years ago and have some good ideas on how you might implement this. You wouldn't even need to uncompress the whole file on the fly though you would lose some on the compression by blocking it into more manageable hunks. Nate