Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.internals
Subject: Re: Compressed executables
Message-ID: <1079@mwtech.UUCP>
Date: 31 Jan 91 11:59:11 GMT
References: <1991Jan15.204849@IASTATE.EDU> <118868@uunet.UU.NET> <3977@skye.ed.ac.uk> <1991Jan23.123808.22159@grep.co.uk> <4001@skye.ed.ac.
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 18

In article <1991Jan30.123119.15448@chvax.uucp> rheiger@chvax.UUCP (Eiger Richard) writes:
:In article <5453@bwdls58.UUCP> hwt@bwdlh490.BNR.CA (Henry Troup) writes:
:>Of course, if you can implement compression in special hardware between the 
:>disk and the CPU, you can do this with no impact on CPU performance.
:>
:I thought of the exact same thing. While we're at it, why not put
:hardware compressing onto the drives? This could be implemented using
:schemes that are used successfully in image processing systems. One of
:the problems I can think of however is the need to be able to access raw
:data directly on the disk. Comments? Experiences?

Some other problem: You can never be sure how much free space you
have on disk. Worse, even if a file remains the same size (or slightly
shrinks) it may occupy more space than before and the disk space is
no more sufficient. (Of course, for disks which contain more or less
"read-only"-stuff this may be no big problem).
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83