d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Spelling.

Browse Source
This commit is contained in:
charnier 2002-10-16 12:42:15 +00:00
parent c106559170
commit 591fe004dc
2 changed files with 32 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
usr.bin/compress/doc/NOTES
View File

@ -1,3 +1,6 @@
$FreeBSD$
From: James A. Woods <jaw@eos.arc.nasa.gov>
>From vn Fri Dec 2 18:05:27 1988
@ -71,48 +74,48 @@ as I recall.)
into glass. although there are restrictions on patenting equations,
the "embedded systems" seem to fly past the legal gauntlets.
anyway, i'm still learning about intellectual property law after
several conversations from a unisys (nee sperry) lawyer re 'compress'.
anyway, I'm still learning about intellectual property law after
several conversations from a Unisys (nee sperry) lawyer re 'compress'.
it's more complicated than this, but they're letting (oral
communication only) software versions of 'compress' slide
as far as licensing fees go. this includes 'arc', 'stuffit',
and other commercial wrappers for 'compress'. yet they are
signing up licensees for hardware chips. hewlett-packard
supposedly has an active vlsi project, and unisys has
board-level lzw-based tape controllers. (to build lzw into
signing up licensees for hardware chips. Hewlett-Packard
supposedly has an active vlsi project, and Unisys has
board-level LZW-based tape controllers. (to build LZW into
a disk controller would be strange, as you'd have to build
in a filesystem too!)
it's byzantine
that unisys is in a tiff with hp regarding the patents,
that Unisys is in a tiff with HP regarding the patents,
after discovering some sort of "compress" button on some
hp terminal product. why? well, professor abraham lempel jumped
HP terminal product. why? well, professor Abraham Lempel jumped
from being department chairman of computer science at technion in
israel to sperry (where he got the first patent), but then to work
at hewlett-packard on sabbatical. the second welch patent
Israel to sperry (where he got the first patent), but then to work
at Hewlett-Packard on sabbatical. the second Welch patent
is only weakly derivative of the first, so they want chip
licenses and hp relented. however, everyone agrees something
like the current unix implementation is the way to go with
software, so hp (and ucb) long ago asked spencer thomas and i to sign
licenses and HP relented. however, everyone agrees something
like the current Unix implementation is the way to go with
software, so HP (and UCB) long ago asked spencer Thomas and i to sign
off on copyright permission (although they didn't need to, it being pd).
lempel, hp, and unisys grumbles they can't make money off the
Lempel, HP, and Unisys grumbles they can't make money off the
software since a good free implementation (not the best --
i have more ideas!) escaped via usenet. (lempel's own pascal
i have more ideas!) escaped via Usenet. (Lempel's own pascal
code was apparently horribly slow.)
i don't follow the ibm 'arc' legal bickering; my impression
i don't follow the IBM 'arc' legal bickering; my impression
is that the pc folks are making money off the archiver/wrapper
look/feel of the thing [if ms-dos can be said to have a look and feel].
now where is telebit with the compress firmware? in a limbo
netherworld, probably, with sperry still welcoming outfits
to sign patent licenses, a common tactic to bring other small fry
into the fold. the guy who crammed 12-bit compess into the modem
into the fold. the guy who crammed 12-bit compress into the modem
there left. also what is transpiring with 'compress' and sys 5 rel 4?
beats me, but if sperry got a hold of them on these issues,
at&t would likely re-implement another algorithm if they
thought 'compress' infringes. needful to say, i don't think
it does after the abovementioned legal conversation.
it does after the above mentioned legal conversation.
my own beliefs on whether algorithms should be patentable at all
change with the weather. if the courts finally nail down
patent protection for algorithms, academic publication in
@ -120,9 +123,9 @@ as I recall.)
where the textbook codes will simply be a big tease to get
money into the patent holder coffers...
oh, if you implement lzw from the patent, you won't get
oh, if you implement LZW from the patent, you won't get
good rates because it doesn't mention adaptive table reset,
lack thereof being *the* serious deficiency of thomas' first version.
lack thereof being *the* serious deficiency of Thomas' first version.
now i know that patent law generally protects against independent
re-invention (like the 'xor' hash function pleasantly mentioned
@ -130,9 +133,9 @@ as I recall.)
but the upshot is that if anyone ever wanted to sue us,
we're partially covered with
independently-developed twists, plus the fact that some of us work
in a bureacratic morass (as contractor to a public agency in my case).
in a bureaucratic morass (as contractor to a public agency in my case).
quite a mess, huh? i've wanted to tell someone this stuff
quite a mess, huh? I've wanted to tell someone this stuff
for a long time, for posterity if nothing else.
james

15
usr.bin/compress/doc/README
View File

@ -1,5 +1,6 @@
@(#)README 8.1 (Berkeley) 6/9/93
$FreeBSD$
Compress version 4.0 improvements over 3.0:
o compress() speedup (10-50%) by changing division hash to xor
@ -21,13 +22,13 @@ Compress version 4.0 improvements over 3.0:
The "usermem" script attempts to determine the maximum process size. Some
editing of the script may be necessary (see the comments). [It should work
fine on 4.3 bsd.] If you can't get it to work at all, just create file
fine on 4.3 BSD.] If you can't get it to work at all, just create file
"USERMEM" containing the maximum process size in decimal.
The following preprocessor symbols control the compilation of "compress.c":
o USERMEM Maximum process memory on the system
o SACREDMEM Amount to reserve for other proceses
o SACREDMEM Amount to reserve for other processes
o SIGNED_COMPARE_SLOW Unsigned compare instructions are faster
o NO_UCHAR Don't use "unsigned char" types
o BITS Overrules default set by USERMEM-SACREDMEM
@ -53,7 +54,7 @@ memory: at least BITS
The default is BITS=16.
The maximum bits can be overrulled by specifying "-DBITS=bits" at
The maximum bits can be overruled by specifying "-DBITS=bits" at
compilation time.
WARNING: files compressed on a large machine with more bits than allowed by
@ -172,8 +173,8 @@ Organization: CADLINC, Inc. @ Menlo Park, CA
In the compress 3.0 source recently posted to mod.sources, there is a
#define variable which can be set for optimum performance on a machine
with a large amount of memory. A program (usermem) to calculate the
useable amount of physical user memory is enclosed, as well as a sample
4.2bsd Vax Makefile for compress.
usable amount of physical user memory is enclosed, as well as a sample
4.2BSD Vax Makefile for compress.
Here is the README file from the previous version of compress (2.0):
@ -189,7 +190,7 @@ Here is the README file from the previous version of compress (2.0):
> compiler. The original posting has a bug which I fixed,
> causing incompatible files. I recommend you NOT to use this
> option unless you already have a lot of packed files from
> the original posting by thomas.
> the original posting by Thomas.
>2. The exit status is not well defined (on some machines) causing the
> scripts to fail.
> The exit status is now 0,1 or 2 and is documented in
@ -253,7 +254,7 @@ Here is the README file from the previous version of compress (2.0):
>>>blinding speed and good compression ratios. It's certainly faster than
>>>compact (but, then, what wouldn't be), but it's also the same speed as
>>>pack, and gets better compression than both of them. On 350K bytes of
>>>unix-wizards, compact took about 8 minutes of CPU, pack took about 80
>>>Unix-wizards, compact took about 8 minutes of CPU, pack took about 80
>>>seconds, and compress (herein) also took 80 seconds. But, compact and
>>>pack got about 30% compression, whereas compress got over 50%. So, I
>>>decided I had something, and that others might be interested, too.