Aucbvax.5888
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Thu Jan 21 03:31:50 1982
WorkS Digest V2 #10
>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 MIT-MC AT>
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 MIT-MC AT>
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 MIT-MC AT>
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
*******************
-------
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
