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 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 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 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 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 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.