Date: Mon, 13 Mar 1995 17:23:36 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: Poul-Henning Kamp <phk@ref.tfs.com>, kargl@troutmask.apl.washington.edu (Steven G Kargl) Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: install compressed binary patch Message-ID: <199503140023.RAA04007@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp <phk@ref.tfs.com> "Re: install compressed binary patch" (Mar 13, 4:05pm)
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503140023.RAA04007>