my uucp (Really: Unix System V Rel. 2 with Paging)

[Guy Harris]

> The major features that came along with this release are:
> 	paging
> 		handles multiple swap areas and allows deletion of swap areas.

As did 4.1BSD.

> 		faster fork()

This is done with copy-on-write; there is a bug in the 11/750 that can
cause problems with copy-on-write - it can't recover from a write-protection
error on a page, so you can't copy the page, turn on write permission, and
retry the instruction, under certain circumstances.  I don't remember what
the circumstances are, so it may be possible to avoid them by not using
copy-on-write in all cases (it may have failed if the write-protected page
was a stack page, so it may only do copy-on-write on the data area).

> 	loader enhancements
> 		a new magic number for directly pageable files.

Magic number 0413, to be precise; I wonder why they chose that number? :-)
:-) :-) :-) :-)

> 	improved Fortran 77
> 		better optimization

The "Product Overview" doesn't go into much detail; the only thing it
mentions about optimizing is that "f77" now "properly invokes the processor
control interface (PCI) when using the -O option", and later says that
it now forbids "-O" and "-g" being specified together.  Is this *real*
optimization, of the sort people expect from Fortran compilers?

> 		lockf() - the /usr/group standard, but permissive rather
> 			  than mandatory locks (i.e. the function tells you the
> 			  record/file is locked but you can ignore that and
> 			  write over it anyway.)

Considering OS/360 and all its successors, and VMS, and, I suspect, lots
of other OSes, only provide permissive locking, I think AT&T made the
right decision.  Implementing mandatory locks is equivalent to walking
around with a large "KICK ME" sign taped to your back; the only way to
prevent J. Random Cracker from locking "/etc/passwd" is to require write
access on a file in order to lock it, which means a process which only
needs (and only has) read access can't prevent a record from being written
on while it's reading it.  They say they'll implement the "enforced lock"
feature of the "/usr/group" standard later - the 12/83 draft says that
this is enabled by turning on the "S_ENFMT" bit for the file, and implies
that most systems will rip off the set-GID bit and use it as the "enforced
locking" bit for non-executable files.

The documentation also says that they've bundled all the encryption/
decryption facilities, as used by "crypt(1)", the "crypt(3)" functions,
and the various editors ("ed" and "ex/vi") into a library, and split off
the source for that library, the "crypt(1)" command, and the encryption
code for the editors.  It implies that the encryption stuff is stubbed out
in the standard C library.  All this is due to the Wise and Powerful U.S.
Government (may they be buried with their feet in the air like a turnip),
State Department (according to the AT&T Product Overview) issuing "regulations
restricting encryption/decryption software to customers in the U.S.A.".
Lordy, they're even afraid of the dumb old "crypt(1)" algorithm that the
editors also use, but which has been broken (see the latest UNIX issue of
the BSTJ)!  Anybody think that the term "intelligence" in the phrase
"intelligence establishment" is inappropriate?

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy