🚀 go-pugleaf

>From JSOL@USC-ECLB Thu Jan 21 03:27:46 1982
Works Digest	        Thursday, 21 Jan 1982       Volume 2 : Issue 10

Today's Topics:		    Page Tables
                    Transparent, Automatic Backups
                    Humor - What Is A WorkStation
          WorkStation and Main CPU - Must They Share Memory?
   Call for Papers - ACM Conference on Security, Audit and Control
               Newsweek: 256K Bit Chips From Bell Labs
                            Virtual Memory
                        OCR For Laser Printer
----------------------------------------------------------------------

Date: 18 Jan 1982 11:28 PST
From: Deutsch at PARC-MAXC
Re:   Page tables

All this business about gigantic page tables is a red herring.  The
Berkeley Computer Corporation machine used a hash table for the page
table.  Its size is proportional to the size of REAL memory.  In other
words, if you have a 1M word real memory divided into 1K word pages,
the in-core-page table contains a maximum of 1000 occupied entries,
regardless of the size of the address space.  The page table is hashed
on the disk address (or unique ID or whatever you like) of the page.
This scheme requires a hardware map that is associative rather than
indexed, but that is no big deal -- it's just like a memory cache.

------------------------------

Date:  19 January 1982 08:11 est
From:  Frankston.SoftArts at MIT-Multics
Subject:  Re: Dave Reed's questions

To agree with Dan Weinreb, backup should be automatic and
transparent.  This requires a network connection and continuous
listening.

What we need here are PROTOCOLS to define a standard backup
server.  This is independent of the particular flavor of
workstation.  I don't expect workstations to be fully
successful until you can plug an arbitrary one into your LAN
that also provides standard file and backup servers.  Also it
would provide automatic communications with other LANs in the
sense that there would be LAN-LAN protocols.  The LAN-LAN
protocols do not need to be especially highspeed except that an
offsite backup capability is requirement for any nontrivial
system.  In fact, such a backup capability is a major selling
point -- the equivalent of a fireproof safe.  (Of course, the
ability to keep data from going offsite nonencrypted is also a
requirement).

 ---(1)---


------------------------------

Date: 19 Jan 1982 0912-PST
From: Silverberg at SRI-KL (Brad A. Silverberg)
Subject: what is a workstation?

I noticed in the Heathkit catalog I recently received that Heath is
now offering a Computer Work Station, part # HD-12.  This is in
addition to the H-19, H-89, etc. they already offer.  The price is
incredible: $395.00!  It comes with a formica top, a rack enclosure,
and 2 adjustable shelves.  Order yours now.

Brad

------------------------------

Date: 19 January 1982 1837-EST (Tuesday)
From: George.Coulouris at CMU-10A
To: Robert Elton Maas <REM at MIT-MC>
Subject:  Re: What is a workstation? / Must works&display and main-cpu
        share memory?


 Accepting your thesis that we should restrict set of symbols used in
displaying 'the state of the system model' to a relatively small
number, with rotation and scaling for each symbol, let's do some
worst-case calculations:

    We surely need more symbols than there are in the ASCII set.
    (Do different fonts count as
    separate symbols?), lets say 1000 different symbols = 9 bits

    Screen position requires 2 10-bit coordinate = 20 bits

    Rotation = 8 bits
    Scale = 5 bits

So we would need to send 42 bits to the workstation to specify each
new symbol.

My argument was that for a 'natural' user interface, the workstation
should maintain a smoothly animated display of the current state of
the model as it changes. This includes not just changes to the
contents of small windows on the screen, but the display of new
windows in response to commands, and the re-ordering and
re-positioning of windows that may overlie each other.  In the worst
case, most of the screen may change in one update.  The update should
nevertheless appear to happen all at once (e.g. when a new window
containing text is brought to the screen). A high-resolution screen
could have up to 10,000 symbols on it, and the update needs to happen
in less than 1/20 of a second.

    i.e. the data rate is of the order of 42x10000x20 = 84M bits/sec.

Of course there are some optimisations that can be done, but they
mostly fail in some important cases - consider the problem of making a
window glide smoothly over whatever windows are underneath it.  Even
with optimisation, there is no way that the data rate required is
gonig to be less than a megabit per second or so.

------------------------------

Date: 19 Jan 1982 1356-EST
From: Paul A. Karger <KARGER at DEC-MARLBORO>
Subject: Call for Papers - ACM Conference on Security, Audit and Control

                      CALL FOR PAPERS

                  First ACM Conference on
       SECURITY, AUDIT AND CONTROL IN OFFICE SYSTEMS

                     October 7-8, 1982
                  Marriott Pavilion Hotel
                    St. Louis, Missouri



This conference, jointly sponsored by ACM  Special  Interest
Groups  (SIGs)  in  Business  Data  Processing (BDP), Office
Automation (OA) and Security, Audit and Control (SAC),  will
focus on the design considerations for secure systems in the
automated office.  Topics appropriate  for  this  conference
include:

      *  Local Area Network Security
          -  workstation security
          -  applications of encryption
          -  authentication

      *  Application of Trusted Computing Systems
          -  security enhanced systems
          -  security kernels

      *  Security Applications
          -  electronic mail
          -  electronic publishing

      *  Software Security Policies
          -  access lists
          -  defaults
          -  manditory policies
          -  integrity policies

      *  Systems Auditability
          -  audit trails
          -  interpretation of audit information
          -  monitoring

Authors with technical papers or descriptions of  successful
applications  in  the above or related topics are encouraged
to submit their work for consideration.  Papers should be  a
maximum  of  20  double spaced, typewritten pages (including
abstract and references) for  inclusion  in  the  conference
proceedings.

Dates:  Completed papers due (3 copies)     April 1, 1982
        Notification of acceptance          May 30, 1982
        Camera-ready manuscript due         July 1, 1982

Note:  Authors of accepted papers will be required to sign a
copyright release form.

Abstracts, papers, and questions should be addressed to:
     David R. Callaghan
     Babson College
     Babson Park (Wellesley), MA 02157
     (617) 235-1200

Contributions or questions may also be  sent  electronically
to:
     Paul A. Karger
     Digital Equipment Corporation
     77 Reed Road (HL2-3/M08)
     Hudson, MA 01749
     (617) 568-5813
     ARPAnet address:  KARGER at DEC-Marlboro


------------------------------

Date: 19 Jan 1982 19:39:34-PST
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: 256K bit chips from Bell Labs

The latest Newsweek (Jan 25) says that Bell will release a 256Kb chip
next month.  On the other hand, the same story (about Bell Labs) also
says that ACS was secret before the divestiture agreement....

------------------------------

Date: 20 January 1982 0727-EST (Wednesday)
From: George.Coulouris at CMU-10A
To: Robert Elton Maas <REM at MIT-MC>
Subject:  arithmetic error: for 84M bits/sec read 8.4M bits/sec

In my last message, the decimal point slipped from my calculation.
However, my argument was based on the correct calculation and
remains unchanged.

------------------------------

Date: 20 Jan 1982 12:00:08-PST
From: decvax!duke!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
Subject: Virtual Memory

As has been pointed out by many folks, VM is a wonderful mechanism for
hiding the actual size of main memory.  Programs do tend to be
simpler, and the loss in performance is often quite small, especially
since page fault-initiated I/O is often much faster than ordinary file
I/O.  But virtual memories work well *only* if the program has
suitable locality of reference, i.e., if the working set is a
reasonably small fraction of the total memory allocated.  If the
program is going to access most of its address space without any
particular clumping, performance will badly.  Not that explicit I/O
would make it any better -- but at least the programmer would be aware
of what's happening, and would be warned that perhaps a different
algorithm might be appropriate.  The best example I can think of is
sorting:  anyone who tries to sort a large number of records using,
say, shell sort, is in for a rude suprise if the program is run in a
virtual memory environment.

Another point:  all the world is not in main memory.  In particular,
my terminal isn't.  One can write Multics-style programs to deal with
files, or one can write UNIX-style programs, in which all the world,
including my terminal, is a file.  I don't know which approach is
better.

In short:  VM, and memory-based file I/O schemes are not panaceas.  I
like both -- in particular I *don't* like systems without VM -- but
there is a tradeoff; perhaps the workstation designer would be well
advised not to spend the extra bits on address space that can't be
efficiently used by the maximum real memory likely to be available.
(And then add a few more bits because such predictions are always
wrong....)

------------------------------

Date: Wednesday, 20 January 1982  22:17-PST
From: Robert Elton Maas <REM at MIT-MC>
To:   Frankston at MIT-MULTICS
Re:   WorkStations? / OCR for laser printer??

Although I'm adament about hooking up all workstations and other
workstation-like things (MIT-MC etc.) into a worldwide network,
and avoiding use of paper as much as possible, there are several
reasons for occasionally making hardcopy:
 (1) Although I edit online and get 95% of the typographic errors
  eliminated online, when I see my document in hardcopy I always
  catch a few more errors that somehow escaped online scrutiny;
 (2) Occasionally I need to give a listing to somebody who isn't
  yet on "the net";
 (3) I'd like to make hardcopy on microfiche and keep in a safe place
  so that if we have a nuclear war it'll be possible to recover that
  information later (magnifying glasses are sure to be re-invented if
  our species survives, but ASCII will probably be lost and magnetic
  media probably won't even be suspected of containing coded
  information);
 (4) Sometimes the current generation of visual displays can't quite
  do justice to graphics and other "pretty" effects like hardcopy can,
  especially if you consider that when 99% of the world's population
  has word-processing only 80% will have the very best graphic
  terminals, the remaining 19% will have something that is suitable
  for editing but not for showing the full beauty of the document
  being edited (I'm just throwing those percentages out for example, I
  don't intend them to any more than ballpark guesses).
I see no use whatsoever for printing on hardcopy and then trying to
machine-read it back into a computer on a different network, since all
networks will be tied together. But producing hardcopy output for
its own sake as an end product will still have occasional use.

------------------------------

End of WorkS Digest
*******************
-------