Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uunet!aurs01!news
From: news@aurs01.UUCP (news)
Newsgroups: comp.unix.questions
Subject: Re: Backups using compress
Message-ID: <59384@aurs01.UUCP>
Date: 6 Dec 90 18:20:14 GMT
References: <275A875A.3AB0@tct.uucp> <26547:Dec404:51:1690@kramden.acf.nyu.edu>
Organization: Alcatel Network Systems, Raleigh NC.
Lines: 24

<59378@aurs01.UUCP> <11170:Dec507:48:0390@kramden.acf.nyu.edu>
From: throop@aurs01.UUCP (Wayne Throop)
Path: aurs01!throop

> brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
> Maybe your experience differs.

Apparently so.  I've had tapes lost out of a set.  
Also several blocks out of tapes.  And not as rarely as I'd hope.

> Hate to tell you this, but that's a (primitive) error-correcting code.

Hate me not, for I'm eager to learn.  For example, the usage above is
unknown to me: since the error was accomodated instead of corrected,
I'd always called (and heard this type of thing called) error recovery,
not correction.  Just how muddy does common usage make this distinction?

Of course, error-correcting codes (and to a lesser extent
error-recovery codes) and compression are necessarily somewhat at odds,
since the redundant information required for the former conflicts with
the goal of the latter (and is why people settle for error recovery and
less redundancy).

Wayne Throop       ...!mcnc!aurgate!throop