perm filename WORKS.MSG[UP,DOC]28 blob
sn#693431 filedate 1982-12-30 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00340 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00032 00002 Subject: Welcome to APOLLO
C00036 00003 Subject: Themes for discussion
C00039 00004 Subject: Preliminary results from the personal workstations survey
C00046 00005 Subject: personal computer economics
C00048 00006 Subject: Re: Another Xerox workstation.
C00050 00007 Subject: SAM/Worm/820
C00052 00008 Subject: personal computer economics
C00056 00009 Subject: personal computer economics
C00058 00010 Subject: Subjective value of Personal Workstations
C00061 00011 Subject: Star/Mesa
C00063 00012 Subject: Star
C00066 00013 [Subj: Mesa language, PDP10, etc]
C00068 00014 Subject: Re: Speaking up Xerox!
C00070 00015 Subject: Workstations, and their posts.
C00074 00016 Subject: correction on dlw's message
C00077 00017 Subject: Acquiring personal computers
C00082 00018 Subject: Arpanet usage
C00085 00019 Subject: Stars in the sky
C00089 00020 Subject: Productivity gains without using workstations
C00092 00021 Subject: Star Info
C00094 00022 Subject: Re: Apollo Network
C00100 00023 Subject: Quick overview/summary: The Apollo-I (Domain) computer.
C00103 00024 Subject: Re: Star Info
C00106 00025 Subject: Re: Star Info/Smalltalk
C00108 00026 Subject: Re: Smalltalk
C00110 00027 Subject: Chromatics
C00116 00028 Subject: Burroughs OFIS products
C00120 00029 Subject: Re: Works: Re RIvanciw: OA Architecture
C00124 00030 Subject: Apollo files and network
C00126 00031 Subject: Comment on note on Apollo Network
C00128 00032 Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
C00130 00033 Subject: APOLLO net
C00133 00034 Subject: My CT system configuration and Chromatics
C00136 00035 Subject: Re: Personal Workstations -- who for?
C00142 00036 Subject: Interupting a workstation session
C00146 00037 Subject: Shades of Nicholas Negroponte
C00148 00038 Subject: Tools for personal workstations
C00151 00039 Subject: Languages for Distributed Workstations
C00157 00040 Subject: system architecture
C00160 00041 Subject: Mini/Micro Systems June 1981
C00161 00042 Subject: Re: Xerox Dolphin (alias 1100?)
C00167 00043 Subject: Personal Workstations
C00170 00044 Subject: The Economics of Workstations
C00177 00045 Subject: Interupting a workstation session
C00180 00046 Subject: Re: Tools for personal workstations
C00181 00047 Subject: frisbees and floppies...
C00183 00048 Subject: Addressing and File Accessing
C00186 00049 Subject: Re: el.POBox 19 Jun 81 7:36-EDT
C00187 00050 Subject: Multiple Levels Of State
C00191 00051 Subject: Re: Tools for personal workstations
C00195 00052 Subject: On productive text editors, suggested reading includes
C00196 00053 Subject: ALANTHUS System 1000 workstation
C00198 00054 Subject: Re: Xerox Dolphin (alias 1100?)
C00200 00055 Subject: Xerox 1100 (Dolphin)
C00202 00056 Subject: ALANTHUS System 1000 workstation
C00204 00057 Subject: Clarifications about interrupting workstaions
C00207 00058 Subject: Re: Multiple Levels Of State
C00209 00059 Subject: Question to field: Bit Mapped displays
C00210 00060 Subject: Addressing and File Accessing
C00212 00061 Subject: Re: File accessing?
C00213 00062 Subject: Re: Addressing and File Accessing
C00217 00063 Subject: Errata on Barns message "Addressing and File Accessing"
C00221 00064 Subject: Storage Question Restated
C00226 00065 Subject: Re: Addressing and File Accessing
C00229 00066 Subject: Re: Question to field: Bit Mapped displays
C00233 00067 Subject: capability machines
C00235 00068 Subject: Re: Addressing and File Accessing
C00239 00069 Subject: Re: Addressing and File Accessing
C00243 00070 Subject: Xerox 820 Ethernet compatability
C00245 00071 Subject: EMACS -vs- UNIX
C00252 00072 Subject: CMU Workstation milestone
C00253 00073 Subject: Re: Ethernet capabilities of 820 and STAR
C00261 00074 Subject: Switching tasks and context
C00265 00075 Subject: Multiple Levels of State
C00268 00076 Subject: Spatial design for a workstation
C00279 00077 Subject: Ivanciw's ideas &c: comments
C00284 00078 Subject: Re: Tools for personal workstations
C00286 00079 Subject: Re: capability machines
C00288 00080 Subject: Re: Spatial design for a workstation
C00290 00081 Subject: Contexts as Icons
C00294 00082 Subject: Multiple Levels of State
C00296 00083 Subject: Re: Switching tasks and context
C00300 00084 Subject: not putting phone messages into electronic mail files
C00302 00085 Subject: Re: A Quibble or two
C00306 00086 Subject: Re: not putting phone messages into electronic mail files
C00309 00087 Subject: Re: not putting phone messages into electronic mail files
C00312 00088 Subject: speaking of touch panels...
C00313 00089 Subject: Re: Spatial design for a workstation
C00315 00090 Subject: Context Managers
C00319 00091 Subject: Re: Re: Tools for personal workstations
C00320 00092 Subject: Re: Contexts as Icons
C00322 00093 Subject: Unfinished tasks, intra-office mail, and system death
C00326 00094 Subject: Re: A Quibble or two
C00328 00095 Subject: Reliability
C00332 00096 Subject: Re: JWalker comments on working at home, on planes, etc.
C00336 00097 Subject: Working at home
C00340 00098 Subject: Office of Tomorrow, where is it?
C00343 00099 [Subj: Bravo/Hypertext]
C00345 00100 Subject: Workstation Reliability and Redundancy
C00351 00101 Subject: Automated desk
C00354 00102 Subject: Re: Context Managers
C00355 00103 Subject: Icons
C00357 00104 Subject: Re: Reliability
C00361 00105 Subject: Touchpanels
C00365 00106 Subject: Re: Touchpanels
C00379 00107 Subject: Picture vs. Window names
C00386 00108 [Subj: more on icons]
C00388 00109 Subject: Re: Unfinished tasks, intra-office mail, and system death
C00390 00110 Subject: Reliablity
C00392 00111 Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
C00398 00112 Subject: SUN Workstation
C00400 00113 Subject: Collected Responses on Touchpanels II
C00415 00114 Subject: Re: Picture vs. Window names
C00417 00115 Subject: pukcba ekortsyek
C00419 00116 Subject: Making paper go away
C00424 00117 Subject: Programming by example
C00432 00118 Subject: Re: Reliablity
C00434 00119 Subject: PIE reports from PARC
C00435 00120 Subject: Quickie poll
C00436 00121 Subject: Re: Making paper go away
C00439 00122 Subject: Re: Making paper go away
C00443 00123 Subject: Making paper go away
C00447 00124 Subject: Re: Office of Tomorrow, where is it?
C00451 00125 Subject: Icons and analogy
C00455 00126 Subject: Redefining the art
C00457 00127 Subject: Re: Re: A Quibble or two
C00461 00128 Subject: Re: Spatial design for a workstation
C00468 00129 Subject: Re: Spatial design for a workstation
C00472 00130 Subject: Collected responses on terminal input devices
C00484 00131 Subject: Bell Labs "writers workbench"
C00485 00132 Subject: writing aids
C00486 00133 Subject: Realtime proofreaders
C00489 00134 Subject: Configuration
C00493 00135 Subject: [don: EP]
C00496 00136 Subject: Alternatives to making paper go away
C00499 00137 Subject: Re: Making paper go away
C00503 00138 Subject: Scanning structured text
C00505 00139 Subject: Editing
C00509 00140 Subject: Writing English
C00512 00141 Subject: Ideal word-processor
C00516 00142 ["Automate the Business Office--How and When"]
C00519 00143 Subject: Talking Workstations, that elusive 'external device'.
C00521 00144 Subject: mice,balls,touch-plates,pens.
C00524 00145 Subject: Re: Configuration
C00529 00146 Subject: Collected Responses on Terminal Input Devices
C00542 00147 Subject: terminals versus comp centers
C00545 00148 Subject: Collected responses on terminal input devices
C00566 00149 Subject: WorkS problems
C00570 00150 Subject: Realtime proofreaders
C00574 00151 Subject: File Backup
C00579 00152 Subject: Collected responses on terminal input devices
C00591 00153 Subject: More on configuration
C00597 00154 Subject: WorkS Software.
C00600 00155 Subject: Collected responses on useable systems
C00607 00156 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00613 00157 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00619 00158 ∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
C00627 00159 Subject: "mundane" systems
C00632 00160 Subject: re: REM' s remarks on Global configurations
C00637 00161 Subject: apollo s/w release 2.0
C00641 00162 Subject: Mouse Guts
C00647 00163 Subject: Big AND Small
C00655 00164 Subject: Keystroke Monitoring
C00658 00165 Subject: WorkS Digest V1 #1
C00669 00166 Subject: WorkS Digest V1 #3
C00680 00167 Subject: WorkS Digest V1 #4
C00683 00168 Subject: WorkS Digest V1 #5
C00701 00169 Subject: WorkS Digest V1 #6
C00710 00170 Subject: WorkS Digest V1 #7
C00717 00171 Subject: WorkS Digest V1 #8
C00724 00172 Subject: WorkS Digest V1 #9
C00733 00173 Subject: WorkS Digest V1 #10
C00743 00174 Subject: WorkS Digest V1 #11
C00751 00175 Subject: WorkS Digest V1 #13
C00760 00176 Subject: WorkS Digest V1 #13
C00766 00177 Subject: WorkS Digest V1 #14
C00769 00178 Subject: WorkS Digest V1 #16
C00775 00179 Subject: WorkS Digest V1 #17
C00782 00180 Subject: WorkS Digest V1 #18
C00784 00181 Subject: WorkS Digest V1 #19
C00789 00182 Subject: WORKS Digest V1 #20
C00804 00183 Subject: WORKS Digest V1 #21
C00810 00184 Subject: WORKS Digest V1 #23
C00818 00185 Subject: WORKS Digest V1 #24
C00830 00186 Subject: WORKS Digest V1 #25
C00834 00187 Subject: WorkS Digest V1 #26
C00841 00188 Subject: WORKS Digest V1 #27
C00851 00189 Subject: WORKS Digest V1 #28
C00882 00190 Subject: WorkS Digest V1 #29
C00898 00191 Subject: WorkS Digest V1 #30
C00902 00192 Subject: WorkS Digest V1 #31
C00911 00193 Subject: WorkS Digest V1 #32
C00922 00194 Subject: Works Digest V1 #33
C00931 00195 Subject: WorkS Digest V1 #34
C00943 00196 Subject: WorkS Digest V1 #35
C00956 00197 Subject: WorkS Digest V1 #36
C00965 00198 Subject: WorkS Digest V1 #37
C00971 00199 Subject: WorkS Digest V1 #38
C00977 00200 Subject: WORKS Digest V1 #22
C00981 00201 Subject: WorkS Digest V1 #39
C00985 00202 Subject: WorkS Digest V1 #40
C00998 00203 Subject: WorkS Digest V1 #41
C01005 00204 Subject: WorkS Digest V1 #42
C01009 00205 Subject: WorkS Digest V1 #43
C01013 00206 Subject: WorkS Digest V1 #45
C01022 00207 Subject: WorkS Digest V1 #46
C01030 00208 Subject: WorkS Digest V1 #47
C01037 00209 Subject: WorkS Digest V2 #1
C01045 00210 Subject: WorkS Digest V2 #2
C01063 00211 Subject: WorkS Digest V2 #3
C01073 00212 Subject: WorkS Digest V2 #4
C01088 00213 Subject: WorkS Digest V2 #5
C01106 00214 Subject: WorkS Digest V2 #6
C01129 00215 Subject: WorkS Digest V2 #7
C01145 00216 Subject: WorkS Digest V2 #8
C01151 00217 Subject: WorkS Digest V2 #9
C01161 00218 Subject: WorkS Digest V2 #10
C01181 00219 Subject: WorkS Digest V2 #11
C01186 00220 Subject: WorkS Digest V2 #12
C01191 00221 Subject: WorkS Digest V2 #13
C01207 00222 ∂23-Feb-82 2344 AVB WorkS Digest V2 #14
C01213 00223 ∂23-Feb-82 2345 AVB Perceived Complexity of computer and/or text editing systems
C01216 00224 ∂23-Feb-82 2345 AVB Test and archive
C01218 00225 ∂23-Feb-82 2359 AVB Workstations and multiprocessing
C01222 00226 ∂24-Feb-82 0004 AVB Fortune 32:16
C01231 00227 ∂24-Feb-82 0008 AVB Re: UNIX & Workstations & Networking ...
C01234 00228 ∂28-Feb-82 1126 AVB Re: Works archive...
C01237 00229 ∂28-Feb-82 1126 AVB General Works comments
C01246 00230 ∂28-Feb-82 1128 AVB Bit-map for the Wicat
C01250 00231 ∂28-Feb-82 1143 AVB Wicat Graphics
C01254 00232 ∂28-Feb-82 1144 AVB Re: Wicat Graphics
C01256 00233 ∂28-Feb-82 1145 AVB Window Management
C01259 00234 ∂28-Feb-82 1149 AVB Re: Wicat Graphics
C01261 00235 ∂28-Feb-82 2322 AVB
C01262 00236 ∂28-Feb-82 2322 AVB Victor Workstation
C01265 00237 ∂28-Feb-82 2322 AVB where's the innovation
C01267 00238 ∂28-Feb-82 2322 AVB
C01268 00239 ∂28-Feb-82 2323 AVB victor 9000
C01275 00240 ∂28-Feb-82 2323 AVB IBM PC Review
C01282 00241 ∂01-Mar-82 1223 AVB IBM PC Review
C01286 00242 ∂01-Mar-82 1223 AVB IBM PC Review
C01291 00243 ∂01-Mar-82 1225 AVB Re: Window Management
C01294 00244 ∂01-Mar-82 1226 AVB WorkS Now both DIGEST and Direct distribution
C01297 00245 ∂01-Mar-82 1226 AVB
C01299 00246 ∂01-Mar-82 1228 AVB IBM PC comments
C01304 00247 ∂04-Mar-82 2156 AVB Re: where's the innovation
C01307 00248 ∂04-Mar-82 2157 AVB Re: IBM PC Bus Extensionts)
C01309 00249 ∂04-Mar-82 2158 AVB
C01310 00250 ∂04-Mar-82 2159 AVB IBM PC Bus Extension
C01313 00251 ∂04-Mar-82 2200 AVB Innovation...
C01315 00252 ∂04-Mar-82 2209 AVB 68000 wait states
C01318 00253 ∂04-Mar-82 2345 AVB 68000 system performance
C01322 00254 ∂06-Mar-82 1203 AVB Innovation
C01325 00255 ∂06-Mar-82 1203 AVB re: 68000 wait states
C01326 00256 ∂06-Mar-82 1703 AVB Re: Innovation
C01330 00257 ∂08-Mar-82 2148 AVB Apollo system software
C01345 00258 ∂08-Mar-82 2148 AVB Ethernet Doomed?
C01347 00259 ∂08-Mar-82 2156 AVB Electronic Newsroom Info Request
C01349 00260 ∂09-Mar-82 1044 AVB Re: Ethernet Doomed?
C01351 00261 ∂11-Mar-82 1215 AVB Perqs, Accent, and Spice
C01354 00262 ∂11-Mar-82 1216 AVB
C01359 00263 ∂11-Mar-82 1216 AVB Re: Ethernet Doomed?
C01363 00264 ∂11-Mar-82 1217 AVB Administrivia - Archives.
C01367 00265 ∂11-Mar-82 1217 AVB Re: Ethernet Doomed?
C01373 00266 ∂11-Mar-82 1217 AVB Apollo
C01376 00267 ∂11-Mar-82 1218 AVB Ethernet Doomed?
C01379 00268 ∂11-Mar-82 1219 AVB Hardware Driven?
C01383 00269 ∂11-Mar-82 1219 AVB Re: WORKS Digest V2 #19
C01385 00270 ∂11-Mar-82 1220 AVB Mike O'Dell and Ethernet
C01388 00271 ∂11-Mar-82 1221 AVB Is UNIX really the answer ?
C01394 00272 ∂11-Mar-82 1221 AVB Re: is unix really the answer?
C01398 00273 ∂11-Mar-82 1222 AVB Re: is unix really the answer?
C01400 00274 ∂11-Mar-82 1223 AVB Re: Mail headers
C01402 00275 ∂11-Mar-82 1224 AVB Unix really isn't the answer
C01405 00276 ∂11-Mar-82 1225 AVB UNIX & "the" Answer
C01408 00277 ∂11-Mar-82 1226 AVB Ethernet Doomed?
C01410 00278 ∂11-Mar-82 1227 AVB ethernet, unix
C01415 00279 ∂11-Mar-82 1228 AVB TOPS-20 EXEC
C01418 00280 ∂11-Mar-82 1245 AVB Re: UNIX & "the" Answer
C01421 00281 ∂11-Mar-82 1652 AVB Re: Ethernet Doomed?
C01423 00282 ∂11-Mar-82 1653 AVB Re: Re: UNIX & "the" Answer
C01425 00283 ∂11-Mar-82 1653 AVB Someone's Theory
C01427 00284 ∂11-Mar-82 1930 AVB Re: Unix really isn't the answer
C01432 00285 ∂13-Mar-82 0958 AVB Opinions & Biases
C01437 00286 ∂13-Mar-82 0959 AVB UNIX as a working environment
C01443 00287 ∂13-Mar-82 0959 AVB Unix, IBM, humankind, Smalltalk, animation, parallelism
C01448 00288 ∂13-Mar-82 1000 AVB software releases
C01451 00289 ∂13-Mar-82 1001 AVB A minor point...
C01453 00290 ∂17-Mar-82 1139 AVB WORKS Digest V2 #24
C01480 00291 ∂20-Mar-82 1009 AVB WORKS Digest V2 #25
C01490 00292 ∂20-Mar-82 1010 AVB WORKS Digest V2 #26
C01497 00293 ∂22-Mar-82 0820 AVB WORKS Digest V2 #27
C01520 00294 ∂22-Mar-82 2216 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #28
C01529 00295 ∂23-Mar-82 2212 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #29
C01537 00296 ∂24-Mar-82 2318 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #30
C01560 00297 ∂26-Mar-82 2100 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #31
C01571 00298 ∂29-Mar-82 2342 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #34
C01578 00299 ∂30-Mar-82 2244 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #35
C01590 00300 ∂04-Apr-82 0100 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #38
C01603 00301 ∂05-Apr-82 2253 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #39
C01611 00302 ∂06-Apr-82 2254 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #40
C01622 00303 ∂02-Apr-82 0055 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #37
C01629 00304 ∂08-Apr-82 0211 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #41
C01640 00305 ∂09-Apr-82 0028 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #42
C01658 00306 ∂10-Apr-82 1457 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #43
C01675 00307 ∂11-Apr-82 1706 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #44
C01695 00308 ∂16-Apr-82 0033 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #45
C01701 00309 ∂17-Apr-82 0159 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #46
C01707 00310 ∂21-Apr-82 0045 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #47
C01711 00311 ∂24-Apr-82 0007 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #48
C01732 00312 ∂25-Apr-82 1943 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #49
C01742 00313 ∂27-Apr-82 2333 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #50
C01747 00314 ∂02-May-82 2345 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #51
C01763 00315 ∂06-May-82 2306 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #52
C01777 00316 ∂09-May-82 0014 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #53
C01787 00317 ∂11-Mar-82 1920 George.Coulouris at Cmu-10a Re: Unix really isn't the answer
C01792 00318 ∂29-Mar-82 0013 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #33
C01800 00319 ∂01-Apr-82 0041 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #36
C01806 00320 ∂18-May-82 0144 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #55
C01823 00321 ∂16-May-82 0717 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #54
C01828 00322 ∂21-May-82 0041 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #56
C01842 00323 ∂21-Sep-82 1825 AVB WORKS Digest V2 #59
C01850 00324 ∂20-Jun-82 0206 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #61
C01857 00325 ∂08-Jul-82 0005 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #63
C01870 00326 ∂10-Jul-82 2118 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #64
C01880 00327 ∂20-Jul-82 2236 AVB WORKS Digest V2 #64
C01892 00328 ∂23-Jul-82 1156 AVB WORKS Digest V2 #65
C01904 00329 ∂24-Jul-82 1036 AVB WORKS Digest V2 #66
C01923 00330 ∂01-Aug-82 1513 AVB WORKS Digest V2 #67
C01933 00331 ∂03-Aug-82 1204 AVB WORKS Digest V2 #68
C01950 00332 ∂07-Aug-82 1252 AVB WORKS Digest V2 #70
C01957 00333 ∂07-Aug-82 1402 AVB WORKS Digest V2 #69
C01976 00334 ∂10-Aug-82 2143 AVB WORKS Digest V2 #71
C01995 00335 ∂11-Aug-82 1313 AVB WORKS Digest V2 #72
C02008 00336 ∂16-Aug-82 1005 AVB WORKS Digest V2 #74
C02014 00337 ∂18-Aug-82 2239 AVB WORKS Digest V2 #73
C02028 00338 ∂23-Aug-82 0545 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #75
C02036 00339 ∂19-Sep-82 1453 AVB WORKS Digest V2 #77
C02046 00340 ∂21-Sep-82 1815 AVB WORKS Digest V2 #57
C02066 ENDMK
C⊗;
Subject: Welcome to APOLLO
∂05-Jun-81 2215 DUFFEY at MIT-AI (Roger D. Duffey, II) Welcome to APOLLO
Date: 6 JUN 1981 0115-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: New APOLLO Subscribers
Hello,
Welcome to the APOLLO mailing list. APOLLO discusses personal
work station computers, like the APOLLO work station computer,
BBN's Jericho, the Three Rivers Corporation PERC, or the newly
announced Xerox STAR. APOLLO provides a way for interested
members of the ARPAnet community to discuss what is wrong with
these machines, compare notes on work in progress, and share
useful insights about these kinds of systems. The list is
managed by Hank Dreifus <Dreifus at WHARTON>.
APOLLO is currently discussing initial reactions to the Xerox
Star Workstation. Sandor Schoichet <SROSS at MIT-XX> has been
conducting an informal survey about the Star. The current
results are available in the file DUFFEY;APOLLO STARMS on MIT-AI
and the file <SROSS>STAR.MSS on MIT-XX. Please note that you do
not need to login to FTP the file from MIT-AI. People who cannot
obtain copies of the file themselves may request a copy of the
file by sending mail to APOLLO-REQUEST@AI.
Hank Dreifus <Dreifus at WHARTON> is conducting an initial
survey about the personal workstations people on this list
are using and/or developing. He would like to send him a
brief message describing the OA machine you use and why
(or why not). He will collect the responses and distribute
a final summary to the list.
A complete record of the APOLLO discussions will be maintained
in the file AI:DUFFEY;APOLLO ARCHIV. The archive is small now
because APOLLO is only a few days old. However, this will
change rapidly.
Comments in the ongoing discussions should be addressed to
APOLLO@MIT-AI. Administrative requests (eg. a message asking
to add someone to the mailing list) or questions about the
goals of this list should be addressed to APOLLO-REQUEST@MIT-AI.
Lastly, welcome to APOLLO. I trust you will enjoy being part of
these discussions.
Cheers,
Roger
Subject: Themes for discussion
∂11-Jun-81 0714 DREIFU at WHARTON-10 (Henry Dreifus) Themes for discussion
Date: 11 Jun 1981 (Thursday) 0915-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Some of the topics I would like to see discussed by this discussion
list are:
o Definition of a personal workstation.
o The IDEAL personal workstation.
o Technical review of all participating machines
where some accurate knowledge of the machine
can be presented.
o The introduction of personal workstations into large
business. The question of operational logistics,
transferring an application to a small machine.
o Is the right answer to make the small workstation
look like a very slow version of a large mainframe?
o Example applications.
o Trade offs in networking the workstations. Performance
weighed against cost and overhead.
o Some of the plans for introducing workstations in
operational areas.
o End user(s) of workstations, the application skewed
machines.
o User interfaces, factors.
------------------------------
There are but a few ideas. However one caveat. Facts are better
than Flames. Please no flaming, that is the one thing this list
is better off without.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: Preliminary results from the personal workstations survey
∂11-Jun-81 0735 DREIFU at WHARTON-10 (Henry Dreifus) Preliminary results from the personal workstations survey
Date: 11 Jun 1981 (Thursday) 0920-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Below is a condensed version of the various systems that people
have made an attempt to respond to. The interesting point(s)
that I have noticed are:
o Everyone's view of Personal Workstations is different.
o The machine(s) selected are wide ranged and apparently
well suited for each application chosen.
o There is no wrong Personal Workstation machine.
o The technology of Personal Workstations is not well
established as of yet.
o There is a demonstrated need for this technology,
it appears to be one year away from general use.
o Most have:
Large address space (or VM).
Networking capabilities.
Very good display hardware.
Large local storage capacity.
Micro-processor based.
Contain an external locator type input device.
o Most are missing:
Software tools to round out system.
Market recognition.
Gateway access, no gateway specifications.
Too many parts, development schedules are
full, revision schedules are bare.
Consistency. This is a result of different
definitions of what a personal workstation
is supposed to be.
------------------------------
Below is a summary of the survey responses. Eventually, each
machine will be examined in greater detail. The intention is
to educate ourselves about personal workstations. They sound
neat, but what they are under the surface is still a hot topic.
Machine Reason/Use Comments
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Perq Spice Project 15
Spice means: Scientific Personal Integrated Computing Environment.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Jericho BBN - Lisp machines 30
need large address
space and powerful
LISP processing.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
CTI For Alanthus. 16 workstations per
cluster capability.
(no numbers)
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
DEC-20/Ts computer Large Scale OA proj. 20
Interesting for discussion purposes.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Apollo Test/soft devt. 2 - max curr config.
existing in field
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Xerox Xerox Corp devt. 50-60
MIT, and others:
experimentation.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Nu's MIT Workstation 15-25
prototype
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Wang WPS-25 Experiment 1-4
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Extending the survey:
Each technical group that has a machine; eg Xerox PARC,
please designate one person to introduce their machine(s)
with references in the literature. For each agency or
sponsored group, list the application and the reasons and
any other relevant information about their specific problem,
eg: general Office Management, or some application. This
should provide a good beginning in opening the discussions.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: personal computer economics
∂11-Jun-81 0759 Hank Walker at CMU-10A (C410DW60) personal computer economics
Date: 11 June 1981 1025-EDT (Thursday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Most of the comments on the Xerox Star that have appearred in the paper say
something like "very nice...for half the price". VERY few companies have
computer capitalization that exceeds $10,000 per person. That's roughly
what it is at DEC (internal transfer cost), and the average outside company
would have to spend a lot more to reach the same level, which I consider
just adequate (terminal at home, one at work, access to several group
machines). The comments that I have heard from people in marketing are
that they don't think that large numbers of the Star will be sold to peons,
but rather to management types, who can use it as a status symbol.
So one requirement of a personal workstation that you are going to give
to everybody, including the secretaries, is a price of less than $10,000
including overhead from network, printer, file servers, etc. Also including
software.
Subject: Re: Another Xerox workstation.
∂11-Jun-81 1213 Charles B. Weinstock <Weinstock at SRI-KL> Re: Another Xerox workstation.
Date: 11 Jun 1981 1123-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
To: TAW at SU-AI
cc: apollo at MIT-AI
In-Reply-To: Your message of 11-Jun-81 0918-PDT
The 820 (or Worm) is a 64k Z80 based machine that (at 3k) has a
keyboard, display, two mini-floppies, and can run either CP/M or
a Xerox hacked over Wordstar (this from the local representative).
The only current Ethernet capability is through a RS232 interface
(which means that an Apple or a Osborne has the same capability).
Xerox will have some sort of a real Ethernet available eventually.
According the the San Jose News of last night, the 820 has no
graphics capability. The main thing this @i[appears] to have going
for it is the Xerox name--many companies would rather deal with a
Xerox or an IBM than an Apple or a Radio Shack or a ...
The above is based on information gleaned from talking to various Xerox
people and is no doubt incomplete. I imagine there are Xeroxers on
this mailing list. Perhaps they can fill us in more.
-------
Subject: SAM/Worm/820
∂11-Jun-81 1241 Tom Wadlow <TAW at SU-AI> SAM/Worm/820
Date: 11 Jun 1981 1131-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
Hopefully, Xerox will provide the software for the 820 to speak with Star
systems. That is where the 820 could have the advantage over the Apple
or Osbourne machines. I think that a lot of people who would like to
go into office automation are cringing at the price of the Star (when they
think of all the people that they would want on their office network).
If the 820 provides a thoughtfully designed subset of Star capabilities
(and I don't know whether it will or not) at a fraction of the price
it could be a wonderful bootstrapping mechanism for getting Ethernet
based systems into the offices. And you can always unplug the 820
and plug in a Star at a later date (perhaps allowing the employees
to take them home for telecommuting purposes).
Subject: personal computer economics
∂11-Jun-81 2242 Steven T. Kirsch <SK at MIT-MC> personal computer economics
Date: 12 June 1981 01:34-EDT
From: Steven T. Kirsch <SK at MIT-MC>
To: Hank Walker at CMU-10A
cc: apollo at MIT-AI
I think your argument is a little incomplete.
Suppose I make you the following deal: if you give me $10,000 today, I
will give you at least $5,000 every year for the next 5 years. I
think you will accept my deal, right?
Ok, now let's look at Star and suppose I can prove to you that it
makes me 10% more effective (this is hard to prove) or that it saves
me 10% of my time. My time actually costs the company $60,000 a year.
And I am but a lowly engineer making under $30K/year. So if the
if I do my work 10% faster, the company in some way, "saves"
$6,000/yr. (the savings could be in hiring less engineers or by
getting more work done per unit time or by getting the job done more
effectively).
In fact, the Booz-Allen study on the potential of office
automation (a very thorough case study of over 40 companies) concluded
the AVERAGE ROI on OA equipment was 86% annually and could be over
200% in some companies.
I think it is foolish to measure a system on cost. You measure on
price/performance or ROI. If Xerox can prove a high ROI, they will win.
I must work for one of those "VERY few" companies who spend over
$10,000 on computer equipment for engineers. It costs us $60,000 to
provide a computer port into our Data General Eclipse.
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
Subject: personal computer economics
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: personal computer economics
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: Subjective value of Personal Workstations
∂12-Jun-81 0447 Brian P. Lloyd <LLOYD at MIT-AI> Subjective value of Personal Workstations
Date: 12 June 1981 07:39-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: APOLLO at MIT-AI
Regardless of the arguments for and against the economic value of the
Personal Workstation (PW), the numbers are beginning to tell. I work
for Alanthus Data Communications and we market the Convergent
Technologies system to end users. Our marketing strategy is to point
out how the system provides OA, communications, and user
programmability in one box.
The response is overwhelming! The average configuration seems to be
going out at about $20,000 including software. Granted, at this point
in time people are buying development systems, but the availablity of
OA software (WP, mail, etc.) has been a driving point in almost every
sale.
Obviously people believe in the PW concept and the market is still
growing. Since people rarely exhibit rational behavior (except in a
negative [fiscal] sense), I don't expect rational decisions either way
on the subject. We all realize that OA and PWs are coming and noone
is going to stop it.
Since we all tend to be in areas of development for OA products, let
us now discuss what the needs of the user really are. Perhaps we can
decide what Office Automation and Personal Workstation really means.
Brian
Subject: Star/Mesa
∂12-Jun-81 0841 LYNCH at USC-ISIB Star/Mesa
Date: 12 Jun 1981 0819-PDT
From: LYNCH at USC-ISIB
To: Apollo at MIT-AI
The Star is almost useless to any of us who are doing computer
science R&D unless we can program it as we see fit. The applications
that Xerox has seen fit to release at this time are indeed quite nice
but do not justify the cost ($20K with software if you buy 50 or more
of them in a year's time -- they give a nice discount for volume
buys (about 25% off)). We asked Xerox to include Mesa.
They said OK. They have not yet quoted a price to us however.
We also asked for the microcode. Thye said Not at this time.
The Mesa release was contigent upon us buying a lot of them
(like 50-100). They are still confused about where their marketplace
is. If commerical orders do not flow in rapidly in the next
few months then they might be much more interested in
turning it into a "programmer's workstation" that would suit us.
WEe have also asked them to include much more memory on the Star.
They admit it can be done but that they are trying to build even
smaller confiturations of it (it currently comes with 384 MB).
Dan
-------
Subject: Star
∂12-Jun-81 0940 Tom Wadlow <TAW at SU-AI> Star
Date: 12 Jun 1981 0917-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
As I understand it, the Star comes with a somewhat low-power programming
language called CUSP. This is the only programming facility available to
the user. Rumor has it (and it would not surprise me) that there is an
extensive Mesa development system that could be run on the Star, but is
destined to never leave the hallowed halls of Xerox. (If I am wrong
on any of this I will cheerfully accept correct information from our
friends at Xerox who are reading this)
Apparently the reasoning behind this involves consistancy in system
software. If you don't give the users (who aren't supposed to be
programmers to begin with) access to the system programming language,
and armor-plate the language that you do give them, they can't
do themselves or the system any harm. Also, if you want a new
system application, you must ask Xerox to make it for you. Thus
it will be written properly (I am not being sarcastic here. There
is a lot to be said for this approach when your target market is
composed of non-programmers). Xerox doesn't want to find themselves
in the position of supporting outside software, because outsiders
don't have the information and the methodology to write that
software in a consistant manner with the rest of the Star system.
[Subj: Mesa language, PDP10, etc]
∂12-Jun-81 2016 Ian H. Merritt <MERRITT at USC-ISIB>
Date: 12 Jun 1981 1529-PDT
From: Ian H. Merritt <MERRITT at USC-ISIB>
To: CSVAX.fateman at BERKELEY
cc: apollo at MIT-AI, MERRITT at USC-ISIB
In-Reply-To: Your message of 12-Jun-81 0736-PDT
The major problem we have encountered at ISI is not the hardware costs, but
unwillingness of Xerox to supply us with the facilities to write our own
system software. The eventual availability of the Mesa language has been
discussed, but we need all the system software in order to configure the
system to be useful for our applications.
Another consideration is the internet protocols which are (as I am led to
believe) currently not supported.
The idea of using PDP-10s as 'glorified file servers' has been discussed
and seems to be the best way to proceed, since there is currently no part
of the product line which will afford us the massive storage and archival
system we require.
<>IHM<>
-------
Subject: Re: Speaking up Xerox!
∂12-Jun-81 2037 Hamilton.ES at PARC-MAXC Re: Speaking up Xerox!
Date: 12-Jun-81 16:32:59 PDT (Friday)
From: Hamilton.ES at PARC-MAXC
In-reply-to: GEOFF's message of 12 Jun 1981 1421-PDT, <[SRI-CSL]12-Jun-81 14:21:10.GEOFF>
To: Geoff at SRI-CSL
cc: Apollo@AI, Hamilton.ES
We (Xeroids) have been informed that "according to Xerox management,
Xerox policy is to send NO information on Xerox products over the
Arpanet. Thus, APOLLO should be considered to be one-way (inward
only) with regard to Xerox products."
I'm just a low man on the totem pole, so I speak only for myself,
but I suspect that there are two concerns here. One is that we
don't want to do anything that could be construed as "selling"
(even if only as a passive response to people's technical questions)
over the net. The other is that we insiders tend to lose track
of what's officially announced and what isn't, and what's part of
our product as opposed to our development environment.
I certainly encourage other Arpanet sites to share their perceptions
and expectations of Star. Doubtless such reactions will be one of
many valuable sources of input to determine the product's future.
--Bruce
Subject: Workstations, and their posts.
∂12-Jun-81 2244 DREIFU at WHARTON-10 (Henry Dreifus) Workstations, and their posts.
Date: 12 Jun 1981 (Friday) 2233-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: apollo at MIT-AI
User interface, how important?
The Apollo has nothing right at the moment, as compared to the Star, in
which almost the total software engineering effort has been skewed.
Building a powerful user interface is ''nice'', but what is left
with respect to processor cycles is not so ''nice''. The questions of
priorities for any given application is not clear.
Example:
o Personal workstations are purchased because;
(a) Small application program needs to be run off mainframe
(b) Office - management systems need more sophistication
(c) Need for specialized computing has grown
(d) Corporations can no longer shell out vast sums of
money on computing, when distributing is available.
o What personalities should personal workstations have?
In answering this, there are basically 2, a truely split
personality:
Consider:
System FOO runs on giant IBM-303x and can really be run on
lots of distributed perscoms [from G. Steckel].
Systems people would like to see a very interactive and
totally controllable system, perhaps right down to the
micro-code. The full power, memory management right through
to the disk-I/O routines. Engineering a product right is
as equivalent to engineering it well.
Management would want to see just the pretty pictures, the
finished product, none of the rough edges, that the software
engineers love to play with. All they want is a black box with
none of the 'hassles' of low level code.
A split personality indeed.
Most systems are geared towards the management. The fact that
few provisions have been made for the systems types is indeed a
potential tragedy. Much of the insulation is hindering a good job for
the programmer. Remember these things are nothing more powerful than
your Apple computer, doing a major application in-efficiently will hurt
the perscoms in the long run.
Opinions?
/Hank
Subject: correction on dlw's message
∂13-Jun-81 1122 CSVAX.halbert at Berkeley correction on dlw's message
Date: 13 Jun 1981 10:32:20-PDT
From: CSVAX.halbert at Berkeley
To: apollo@mit-ai
The Xerox Star does have virtual memory; it does page.
--Dan
∂13-Jun-81 1151 LYNCH at USC-ISIB Re: correction on dlw's message
Date: 13 Jun 1981 1144-PDT
From: LYNCH at USC-ISIB
Subject: Re: correction on dlw's message
To: CSVAX.halbert at BERKELEY, apollo at MIT-AI
cc: LYNCH
In response to the message sent 13 Jun 1981 10:32:20-PDT from CSVAX.halbert@Berkeley
But I have heard the paging on the Star is a terrible crock:
it does it by double lookup on every memory reference way down
in the microcode. At this time it has no hardware to assist
paging (like associative memory for the TLAs) or even a
kludge like KL-10s have. The (mis)feature makes it tough
to imaging the STar as a LISP machine host.
Dan
-------
∂13-Jun-81 1236 mike at RAND-UNIX MESA on Star
Date: Saturday, 13 Jun 1981 12:18-PDT
To: apollo at MIT-AI
Subject: MESA on Star
From: mike at RAND-UNIX
I have heard a rumor, from a source I trust, that MESA will be
available to those who buy 50 or more Star's. I do not know if there
will be a heavy price, nor do I know if this is a special deal to non-
profit or educational institutions or special in some other way.
There is someone on this list -- you know who you are -- who can
confirm or deny this rumor authoritatively if he chooses to.
In any case, I believe that MESA is a good systems programming
language, but you can certainly kiss portability goodbye!
Subject: Acquiring personal computers
∂13-Jun-81 1415 Sam.Harbison at CMU-10A Acquiring personal computers
Date: 13 June 1981 1534-EDT (Saturday)
From: Sam.Harbison at CMU-10A
To: apollo at mit-mc
Message-Id: <13Jun81 153417 SH01@CMU-10A>
There's been a lot of discussion about the pro's and con's of various personal
computers/personal workstations. Let me give a brief summary of some decisions
taken at CMU.
About two years ago, the CS department decided that our long-term computing
needs would be best met by a network of personal computers in offices, and
plans were made to embark on a research project (Spice) that would give us by
1985 the kind of software necessary for such an facility (including Lisp and
Ada programming environments, document production environments, and multi-media
communication). We thought that it would be 1985 before personal computers
appeared with the right power and cost. Because we did not want to do any
hardware design, we began to canvas manufacturers to see 1) what was available
now to start with, and 2) what might be available in 1985.
The machines close enough to what we wanted to act as a prototype were Perqs,
Apollos, Lisp Machines, Nu Machines, and Xerox D-machines (Dolphin, Dorado, and
the Star computer). Our principal criteria were that the machine had to have
all the basic features of a 'real' machine (display, net, etc.) and be flexible
enough to allow us to develop software for the 1985 machines now. Furthermore,
it was important that we be able to distribute our software to other people.
To make a long story short, Apollos and Nus did not have the writable
microstore that we considered critical, and their microprocessors did not seem
to be able to support the kind of multiprogramming we wanted. Lisp Machines
were too expensive and production (then) uncertain. Xerox and their machines
were philosophically close to us, but the Dolphin/Dorado were not commercial
products, and Xerox would not commit to releasing Mesa, meaning that we might
find it difficult to distribute a system built in Mesa. We finally chose to
begin with Perqs, which on paper are at least equal in performance to any of
the others except the Dorado and Lisp Machine. (And which can be
microprogrammed to be very much like the machine we really want, except for
performance.) The Star's advantage quoted by others is, I think, due to
software refinement. We now have fifteen Perqs at CMU, and work on Spice is
proceeding rapidly. We continue to be on the lookout for new hardware that can
be used in the Spice system in years to come.
Our criteria for machines may not be the same as other people's; we are heavily
committed to "high-end" personal computers, and the software available was
relatively unimportant to us. However, if Mesa and its compilers were freely
available the Xerox machines would have been very attractive.
Subject: Arpanet usage
∂17-Jun-81 0551 Liddle at PARC-MAXC Arpanet usage
Date: 16 Jun 1981 17:45 PDT
From: Liddle at PARC-MAXC
To: AllDLOS↑.DLOS, AllEOS↑.EOS, AllES↑.ES, AllHENR↑.HENR, AllPA↑.PA,
AllWBST↑.WBST, AllXRCC↑.XRCC
cc: Apollo at MIT-AI, Liddle
Many of you in Xerox are aware of a newly created Arpanet distribution list
named Apollo. It was established to promote discussion of personal workstation
computers. As you might expect, much of the recent discussion has involved the
Xerox 8010 Star information system. Because many of the messages ask for
information about this product and its associated development software, you may
feel tempted to reply to some of them.
It is ARPA policy that the Arpanet be used only for government supported
research and development. It is against Xerox policy to use the Arpanet to discuss
products. It is completely inappropriate to use the Arpanet in a way that may be
construed as selling or promoting a Xerox product (or future product). Xerox
employees use the Arpanet for ARPA related research purposes only, not for
answering questions or distributing information about our products.
Questions from potential customers about the Xerox 8010 and other OPD products
should be referred to Arnold Palmer, Field Sales Manager, Xerox Corporation,
1341 West Mockingbird Lane, Dallas, Texas 75247, phone (214) 689-6689.
David E. Liddle
Vice President
Office Products Division
Subject: Stars in the sky
∂19-Jun-81 0555 mo at LBL-UNIX (Mike O'Dell) Stars in the sky
Date: 17 Jun 1981 09:15:54-PDT
From: mo at LBL-UNIX (Mike O'Dell)
To: info-micro at mit-ai
Redistributed-To: WorkS at AI
Redistributed-By: GEOFF at SRI-CSL
Redistributed-Date: 17 Jun 1981
Last week we had a briefing on the Star, so I will relate what was said.
The processor is a D3 machine, and is claimed to run Mesa about
3 times faster than a D0 or a Dolphin. The D3 is a 32-bit, virtual
memory design. The Star only has about 200kb
of memory on it, expandable to about .5 megs, but there is every
reason to believe it can have a lot more than that on it. The
office automation software is all written in Mesa and the base of
the machine is Pilot, but you can't get to any of this. The is a lot
of discussion about making the Mesa environment available, but so
far there is a negative corporate attitude. If they would just
realize how neat that would be.... Anyway, the office software is
pretty classy, but their pricing is repressive. By the time you
license all the software (math editor, graphics, spelling corrector, etc),
which must be done for EACH machine, you add about $5K to the price.
The killer, however, is software maintenance for that machine will
be close to $500 per month!!!!! The pricing structure allows hardware
quantity levels to count the various servers (com, file, print, etc)
as well as Stars because they all use the same CPU box, but
quantity levels for software count only Stars. Software for the
other servers is priced the same way. The basic file server does NOT
come with the electronic mail facility. That handy option costs extra.
Rumors abound pertaining to the transport of Smalltalk and Interlisp
to the machine, but like with Mesa, Xerox doesn't see any demand for
user programmable machines. Moreover, if they can continually
squeeze money out of you for software, it is to their advantage
that no one else can build software for it. (Personal comment)
If any mere mortal (other than MIT, CMU, and Stanford) can
shake Mesa out of Xerox, let me know.
-Mike
Subject: Productivity gains without using workstations
∂24-Jun-81 0511 DPR at MIT-XX Productivity gains without using workstations
Date: Tuesday, 23 June 1981 10:02-EDT
From: DPR at MIT-XX
To: WORKS at MIT-MC
Kirsch has an extremely valid point. The fundamental question is what
leverage does computerization provide in doing a function. However, let's
not be miserly--even Xerox STAR's are incredibly cheap as an investment,
so the amount of leverage they must provide is small.
Personally, I think companies with cash to invest ought to invest it
in ecnomic sectors of maximum productivity gain--however, there are
immense barriers to this. Most companies restrict themselves to internal
reinvestment of their funds. Since our largest and least productive
companies have the higher percentages of funds to invest, and since they
are largely white-collar offices, there is a great move toward
office automation, even though productivity gains are slim in most
office applications.
The sterling exception to this observation about the utility of workstations
lies in tools of high leverage like VisiCalc--which make order of magnitude
changes in labor required to do a task. The Star seems to be able to do this
with the production of business graphics--but I am not sure that they
will be largely used in this domain, or if the graphics thus produced
would have been produced had there not been a Star.
Subject: Star Info
∂24-Jun-81 0533 UOFILLINOIS at WPAFB-AFWAL Star Info
Date: 23 Jun 1981 (Tuesday) 1419-EDT
From: UOFILLINOIS at WPAFB-AFWAL
To: works at MIT-AI
cc: gdh at MIT-AI
The STAR people came here to talk today.
Here's some facts/rumors that were new
to me:
o Mesa will probably be released for
the STAR either the 4th quarter of
this year or the 2nd quarter of next
year.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
o A personal computer called the "inch-
worm" will apparently be announced
soon. It is about book-sized, has
a bitmapped display, and measures
about an inch thick (hence the name).
Could this be a first pass at the
Dynabook?
o They won't sell just one STAR until
next year
-geo
Subject: Re: Apollo Network
∂24-Jun-81 0554 mike at RAND-UNIX Re: Apollo Network
Date: Tuesday, 23 Jun 1981 10:39-PDT
To: Eric Benson <BENSON at UTAH-20>
Cc: WorkS at MIT-ML, DLW at MIT-AI
In-reply-to: Your message of 22 Jun 1981 1043-MDT.
From: mike at RAND-UNIX
You say that the 'apollo software is another story'.
Well, OK, what's the story?
When I was visiting Apollo, it was clear that the hardware was close
to working and that they had no idea just how hard the software they
were planning was going to be to write. Either they didnt know or
they were trying to tell me a story.
Specifically, they intended to write a truly network distributed file
system: with paging, swapping and file transfers all completely
independant of the local machine which might or might not have a disk
drive. When I asked them what file names would look like, to get an
idea of whether the file name would contain the name of the root file
system (location) or whether the location would be 'hidden' from the
user: they had no idea. They had never even thought of the question.
It is possible that there was someone in the building who knew
something about software, but I didnt have the opportunity to meet
them.
I was also not overwhelmed with their desire to build a non-standard
network. But their attitude seemed to be: this is what Prime is doing
and we are really from Prime so this is what we are doing.
Update ??
∂24-Jun-81 0606 Dave Crocker <dcrocker@udel> Apollo gatewaying
Date: 23 Jun 81 11:11:25-EDT (Tue)
From: Dave Crocker <dcrocker@udel>
To: Works at Mit-Ai
Subject: Apollo gatewaying
We had an Apollo presentation, given by Dave Nelson, one of
their Development VPs. He said that a gateway (to unspecified
other networks) was planned. Guess I would expect the initial
one to be to others of their (Domain) rings.
It was my impression that the basic network environment is
strictly message/packet oriented, without connections or other
efficiency mechanisms. Nelson pointedly stated (it was too
affirmative to class as an "admission") that they were not
oriented toward file transfers . Such things can and are done,
but the environment is not tuned to them.
Dave
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Re: Star Info
∂24-Jun-81 1838 Deutsch at PARC-MAXC Re: Star Info
Date: 24 Jun 1981 10:17 PDT
From: Deutsch at PARC-MAXC
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
To: UOFILLINOIS at WPAFB-AFWAL
cc: works at MIT-AI, gdh at MIT-AI
I would like to correct some erroneous information about Smalltalk and the Star.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
The truth is that LRG, a group within PARC, has licensed Smalltalk-80 (the only
Xerox-authorized version of Smalltalk to be released) to a number of micro- and
mini-computer manufacturers. The release consists of detailed specifications for
the machine-dependent kernel, plus a mag tape containing the rest of the system
(windows, editor, compiler, file system, etc., etc.) Several of these manufacturers
have made excellent progress on implementing the system, to the point of having
windows appear on their displays. I can't comment on the specific list of
manufacturers, since we prefer to let them make their own announcements. The
Star marketing people have not exerted any pressure in either direction with
respect to this; the release/license process was properly cleared with our legal
department and all relevant product organizations within Xerox, and we are
currently working out ways to license the system to manufacturers (and
universities) beyond the original group. I can't comment on the availability of
Smalltalk for the Star, except to say that the Star hardware is definitely powerful
enough to support Smalltalk.
Subject: Re: Star Info/Smalltalk
∂24-Jun-81 1911 Ron Newman <Newman.es@Parc-Maxc> Re: Star Info/Smalltalk
Sender: Newman.ES at PARC-MAXC
Date: 24-Jun-81 9:48:22 PDT (Wednesday)
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
From: Ron Newman <Newman.es@Parc-Maxc>
To: UOFILLINOIS at WPAFB-AFWAL
cc: Newman.es, works at MIT-AI, gdh at MIT-AI
Who were "the STAR people" that came to talk to you?
Smalltalk IS being released by PARC this summer. There was a big presentation
on the subject at this year's NCC. Apple, DEC, HP and other companies are
doing research into implementing it on their machines. (In fact, one of the
primary Smalltalk implementors, Larry Tesler, is now at Apple and was one of
the speakers at NCC.) A huge article on the subject will appear in the
August issue of BYTE.
The deal is that PARC gives you an "image" file on a tape, whichcontains
all of Smalltalk ready to run. To run it, you have to implement an
interpreter on your machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
(I don't think anyone at Xerox will beat up on me for this message; all of
it comes from strictly public sources.)
/Ron
Subject: Re: Smalltalk
∂24-Jun-81 1951 mike at RAND-UNIX Re: Smalltalk
Date: Wednesday, 24 Jun 1981 11:45-PDT
To: WorkS at MIT-AI
From: mike at RAND-UNIX
Forgetting for a moment about Xerox marketting, Xerox intends to
release a book on Smalltalk called Smalltalk 80. This version of
Smalltalk is intended to be easily portable. There was some
discussion within Xerox legal about whether the Smalltalk virtual
image would be released. But the book which describes the interpreter
plus the virtual image would result in a very easily portable
language.
One could then port it to the machine of your choice, including the
STAR, assuming that you could PROGRAM the STAR. When MESA gets
released you will be able to implement it in that: but a better place
is microcode. I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation) for Smalltalk.
Xerox marketing wasn't trying to mislead, I'm sure. They have no
interest in marketing Smalltalk; just word processing.
Michael
Subject: Chromatics
∂24-Jun-81 2036 cfh at CCA-UNIX (Christopher Herot) Chromatics
Date: 24 Jun 1981 10:39:46-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
I saw the Chromatics CGC 7900 "Color Graphics Computer" at
the National Computer Graphics Association show last week.
It's hardware is:
Motorola 68000
1024 x 768 x 8 bit color display w/24 bit lookup table
10Mb Winchester disk
Dual Floppies
Light Pen
Joy Stick
151 (I'm not kidding) Key Keyboard
Prices range from $25,000 to $50,000 depending on how much memory
and other options you buy. It doesn't have virtual memory like
the Apollo but can take quite a bit (at least a meg) of real memory.
They plan on supporting IDRIS, a UNIX clone, sometime soon.
Address:
Chromatics, Inc.
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
404-493-7000
∂24-Jun-81 2052 guyton at RAND-UNIX Re: Chromatics Personal Workstation
Date: Wednesday, 24 Jun 1981 16:13-PDT
To: PRSPOOL at RUTGERS
Cc: WorkS at MIT-AI
Subject: Re: Chromatics Personal Workstation
In-reply-to: Your message of 23 Jun 1981 1139-EDT.
From: guyton at RAND-UNIX
The Chromatic 7900 workstation has been announced for a while now and they
had one at the Chicago NCC. Their address/phone:
Chromatics
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
(404)493-7000
Here a few facts off their CGC 7900 literature:
16-Bit processor (MC68000)
19" color monitor
1024x768 viewable bitmap (in a 1024x1024 bitmap memory)
Up to 256 simultaneously displayed colors
Palette of over 16 million colors (i.e. 8-bit DAC for RGB)
10MB Fixed Winchester Disk (8.4 MB formatted)
Dual floppies
light pen, joystick
Maximum of 16-bitmap planes (no more than 8 displayed at once)
Maximum of 2MB of processor memory
Rand reviewed this machine last year and might have purchased one if it
hadn't been quite so new (at the time they had not delivered any, and we
needed a mature system). When I priced it, a useful system was running
around $60K.
Oh yes, they're planning on running the 68000 unix look-alike.
Jim
∂24-Jun-81 2109 Robert A. Morris <RAM at MIT-MC> Chromatics Personal Workstation
Date: 24 June 1981 18:57-EDT
From: Robert A. Morris <RAM at MIT-MC>
Subject: Chromatics Personal Workstation
To: PRSPOOL at RUTGERS
cc: WorkS at MIT-AI
According to a sales engineer I spoke to in Atlanta las week, the software is
IDRIS, Whitesmith's UNIX look alike, none of which had yet been
dleivered to them (or any one else???), nor could he say when an
order placed for the IDRIS software for Chromatics be filled.
If color isn't mandatory and if you are willing to think about systems
with not yet ready software, ask Three Rivers whether/when the Tom Duff
port of Coherent, the Mark WIlliams company version 7 unix look-alike,
will be sold for PERQ's
--bob morris
p.s. A great deal of the Apollo software is also "not quite ready" but
they at least don't advertise it. It's just that Apollo's will presently
do much less than the world of WorkS expects them to. I will flame
after some less biased view of this week's Brown University
Apollo Users workshop appears in this forum.
Subject: Burroughs OFIS products
∂25-Jun-81 0537 Mike Leavitt <LEAVITT at USC-ISI> Burroughs OFIS products
Date: 24 Jun 1981 1748-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI]24-Jun-81 17:48:50.LEAVITT>
The following is an excerpt from the New York Times, 6/23/81,
p. D5
"The Burroughs Corporation moved more aggressively into the
market for the automated office yesterday with the introduction
of a new type of information processing system that can be used
by managers and other professionals with no computer training.
"The system, called OFIS 1 Information Systems, connects
various electronic office machines together and allows them to
communicate. It includes such functions as word processing,
automatic filing and retrieval of business information and
electronic mail communications. . . .
"The system competes head-on with automated office systems
introduced in recent months by IBM, the Datapoint Corporation
and Xerox, and will be compatible with electronic equipment
made by other manufacturers. One shortcoming, according to
some analysts, is that the new system will not be able to
generate and display graphics. But the analysts were unable
to provide detailed comparisons with the competitors' systems.
. . .
"The most important innovation is a component of the OFIS
1 system called OFISfile, which permits up to 80,000 [Sic]
pages of text to be filed automatically and retrieved on
demand. OFISfile was designed to locate any document or group of
related documents with nothing more than an instruction phrased
in common English and containing a name, date, or other words in
the text being sought. . . .
"The basic OFISfile sells for $59,400, while prices for
the OFISdirector, the information processor that permits
system components to communicate with each other, starts at
$33,500. The company said that initial deliveries for the new
system are scheduled for this fall."
Burroughs?????
Mike
Subject: Re: Works: Re RIvanciw: OA Architecture
∂25-Jun-81 0600 Rivanciw at Darcom-HQ Re: Works: Re RIvanciw: OA Architecture
Date: 24 Jun 81 15:52:56-EDT (Wed)
From: Rivanciw at Darcom-HQ
To: Barns at Office-2
cc: Works at Mit-Ml, Barns at Office-2,
cc: UDel.POBox; 17 Jun 81 9:16-EDT at Office-2
Via: Darcom-HQ; 25 Jun 81 0:01-EDT
I will restate my case for the development of a systems architecture
as an early step in addressing the issue of office automation.
I will restate my position with some real world truths here at DARCOM.
It is possible at DARCOM to have office automation services for a
one time cost as low as $5634.00. That full purchase price for 100%
availability on a micro computer. Since most folks currently operate
in a timesharing mode with a multitude of user via for available ports
on a given machine, 100% availability is a step up. This price will
continue to drop as technology moves forward.
That system is based on an 8 user micro supporting 8 users. There are
8 ports on that micro so every user can run her/his office tools
whenever they want. They can currently run a host of tools including
a word processor, 3 different mail systems, a calendar system, a suspense
tool, a tickler system, a conference scheduler, a phone directory, a
reminder services, automated weekly activity reporting, and a couple
of other tools integral to the office.
Since most folks entering the realm of office automation do not use
their system for 8 hours a day, it is most acceptable that a micro with
8 user ports could easily support 16 office workers. Thus the cost
of that system is now $2817.00 one time purchase cost. On a lease that
price would be somewhere around $1000.00 or less a year cost per user
for full office automation tool usage. Now even the most pessimistic
predictions about the field of office automation would conclude that
a grand/year is very, very cost effective.
We are able to offer these cost effective systems because we have an
architecture.
As for being limited to 64K core, what micros are you looking at? The
last one I took delivery on had 1MB core. It was running a full
version 7 of UNIX plus all the software I mentioned above with 8 users.
Randy Ivanciw
Subject: Apollo files and network
∂25-Jun-81 0730 cfh at CCA-UNIX (Christopher Herot) Apollo files and network
Date: 24 Jun 1981 10:14:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
When I last played with an Apollo a few weeks ago, it appeared
to have a hierarchical file structure very similar to UNIX.
The operating system treats local files and files on other
nodes of the ring net identically, e.g. you can copy a file
from one machine to another by typing
copy //mike/foo/bar //mary/foo/bar
and can do any file operation without respect to which machine
the file lives on. As I recall, a single slash at the beginning
of a file name indicated a pathname relative to the local node,
while two slashes indicated a pathname rooted in some master node
for the entire network. Hopefully someone at MIT, Harvard, or
Brown can elaborate (or correct).
Apollo claims that local and network file access are within
a factor of two of each other in speed. Neither appeared
particularly fast in the preliminary version I saw.
Subject: Comment on note on Apollo Network
∂25-Jun-81 0754 Dave Farber <farber@udel> Comment on note on Apollo Network
Date: 25 Jun 81 5:35:03-EDT (Thu)
From: Dave Farber <farber@udel>
To: works at Mit-Ai
The Apollo network is a token network as stated. However the
Cambridge folk are not the originators of the token ring idea. In
fact the Cambridge ring is NOT a token ring. It is a slotted ring
with small slot size.
Tokens rings come via Newhall/Farmer - the DCS process addressed
ring (the first with a real token) - the LNI/MIT LCS I ring with
the Prime ring being derived from the DCS instance.
Dave
Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
∂25-Jun-81 0822 SHOCH at PARC-MAXC Re: Quick overview/summary: The Apollo-I (Domain) computer.
Date: 24 JUN 1981 1730-PDT
From: SHOCH at PARC-MAXC
To: DREIFU at WHARTON-10, WorkS at MIT-AI
cc: SHOCH
In response to the message sent 23 Jun 1981 (Tuesday) 2308-EDT from DREIFU@WHARTON-10
One fine point on local networks:
a) The ring produced by Prime Computer is a "token passing" design,
and it appears that the Apollo system follows this design.
Token passing systems trace their roots back to the work of
Newhall and Farmer at Bell Labs.
b) A recent message suggested that the Cambridge Ring
was also in this family; however, that design would more properly
be described as an "empty slot" ring. The empty slot systems trace
their roots back to the work of Pierce, et al., also at Bell Labs.
John Shoch
[PS: For more than you ever wanted to know on this subject, interested
readers might like to consult the "Annotated bibliography on local
computer networks, third edition," April 1980, Xerox Parc Report
SSL 80-2. Also available as IFIP Working Group 6.4 Working Paper 80-12.]
Subject: APOLLO net
∂25-Jun-81 1602 Griss at UTAH-20 (Martin.Griss) APOLLO net
Date: 25 Jun 1981 1021-MDT
From: Griss at UTAH-20 (Martin.Griss)
To: WORKS at MIT-AI
cc: griss at UTAH-20
I have seen a two node configuration of Apollo's working (Mountain View
Branch), and was able to see a file shipped from one node to the other,
and to compare the times required to count the number of lines
in the local copy and also in the remote copy, accessed via "//<host>file..".
It was interesting that in the first test, the times local and remote
were essentially; after a reboot, the remote time increased slightly
(about 5%). This was explained as an effect of the Unique global ID; in
the first test, the system "knew" the local and remote file by the same
Global ID, and also that the local copy was in the Memory space.
I do not recall the exact number of lines (it was a LARGE file), and the
time was about 1minute. The timing was done by submitting to the
SHell the concatenated commands:
time; countlines //host/... ; time; (This is NOT verbatim).
We also saw the multiple INPUT/OUTPUT windows and PADs working, the
various Display Manager options, the ability to Grow and Shrink windows,
the ability to run separate processes in each Window (in this case,
it was Edit in one, LIST in the other, as I recall).
We were not able to see any real graphics (ie line drawing), tho a small
program was demonstrated that was able to BLT screen areas around.
Martin Griss
-------
Subject: My CT system configuration and Chromatics
∂25-Jun-81 1657 Brian P. Lloyd <LLOYD at MIT-AI> My CT system configuration and Chromatics
Date: 25 June 1981 08:29-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Bruce Daniels wrote asking about the configuration of my CT system at
home. Here is what I have:
Workstation with 256Kb RAM, 5Mhz 8086, 2xRS-232, Centronics
printer port
10Mb 8" winchester (Shugart 1004 drive)
0.5Mb 8" floppy (single side, double density Shugart 800
drive)
Soon to be added (awaiting delivery only):
Additional Workstation to be clustered on the first using CT's
local network (multi-drop, 615Kbaud, half-duplex, RS-422 line)
GE 510 300lpm printer
For software I have:
CTOS multi-task, real-time OS
Pascal
FORTRAN
Word Processor
ISAM
Forms
Sort/Merge
Multiple-window Screen-oriented text editor
Basic
and several programs of my and others design...
For those of you used to home computer prices you may find things just
a bit steep, but if you compare performance per dollar it seems to be
a fairly good deal. Price for a 128K dual floppy system is $13,300 in
unit quantities. The 256K winchester system comes in at about $21,000.
All stand-alone systems include OS (linker, assembler, screen-oriented
editor, and asynchronous terminal emulator). Additional workstations
go for $6,490 for a 128K version or $7,900 for a 256K version.
I like the system a lot. It is easier to use/develop software for
than my PDP-11/23 with RSTS/E was (I know most of you are UNIX hackers
but you have to take what you can get).
Brian
Subject: Re: Personal Workstations -- who for?
∂26-Jun-81 0604 Rivanciw.DHQ at UDel Re: Personal Workstations -- who for?
Date: 25 Jun 81 8:26:40-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: JWALKER at Bbna
cc: WorkS at Mit-Ai
Subject: el.POBox; 19 Jun 81 7:36-EDT
Via: Darcom-HQ; 25 Jun 81 8:26-EDT
I agree wholeheartedly with the comments put forth in JWALKER's
message on Personal Workstations -- who for?
There currently seems to be one of two approaches taken in
applications for office automation:
(1) Develop an application that answers a specific
functional requirement. For example, a budget
preparation tool or a project management (pert)
tool. JWALKER is very right in stating that all
to often these applications are written FOR the
functional and indeed do narrowly define the scope
and processes of usually complex functions. What
results is an application that does not quite do the
job and is too inflexible to mold to the nuances
of the functional task which it attempts to address.
Bottom line is that the functional user must adapt
the way she/he does business to the application.
(2) Develop a general tool (or set of tools) that can
be used in a wide range of functional applications.
Here I am speaking of a message system, and editor,
a suspense tool, etc. While these give the functional
user much more flexibility on how she/he will use
the tool in his/he job, often this adaptation is
cumbersome. Many time we have given a message system
to a user with the response being "What can I use this
for in my job?" Then we explain how and they ask why
and we explain more and they ask how and why and....
Thus we seem once again to be telling them how to do
their business.
The folks here in are branch spent an entire day discussing this
very problem last week. What we came up with was that there is
a need for general tools AND a need for specific applications.
The problem really is that we are addressing office automation
as a tool or an application and it is really much richer than
a single tool (or set) or a single application.
What we are planning to do is to develop an office automation
system which puts emphasis on the work ENVIRONMENT. We are
going to try to structure the user's terminal like a desk.
For example, when they reach for their inbox they will end
up in the mail system. If they suddenly get a call in the middle
of reading their inbox they will not have to exit the
mail system to get to their telephone pad or calendar or whatever.
They will simply reach for it. The system will suspend processing
in the inbox and move to the telephone pad or whatever the user
wants. At the conclusion of the telephone call the user will
say something like "continue" (or hit a button) and the system
will remember where he/she was in the inbox.
In this type of environment tools and applications are transparent
to the user. They are called into use by the system, not the user.
I would really appreciate any comments or suggestions on what this user
environment should look like or include.
Randy Ivanciw
Subject: Interupting a workstation session
∂27-Jun-81 1006 Steven H. Gutfreund <SHG at MIT-AI> Interupting a workstation session
Date: 26 June 1981 14:13-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: Rivanciw.DHQ at UDEL
I would like to comment on one part of Randy Ivanciw's letter about
the need for an integrated environment for workstations. (Which I
believe much of the world is coming around to endorsing even if they
do not know how to do).
Randy gives the example where one is reading a mail inbox and gets a call
on the phone. It would be very useful to be able to drop the mail, pick
up the phone, answer the call, and then return to one's mail.
With iconographic systems (such as STAR or SMALLTALK-80) this would be
quite simple. One would use the mouse to drag the cursor away from
the current icon (be it editor window, mail inbox, virtual terminal)
and position the cursor to the telephone icon. There one would
expand the telephone icon and answer the phone. Later one could return
to the old mail inbox icon.
However, there is a problem here that several Human Factor's people
have pointed out. That is, one could easily have quite a few "pushed"
windows, each one deep in some command dialog. The Human Factor's
people have pointed out that humans have a real scarcity of short
term memory (about 4-7 chunks). Clearly, we humans are going
to have a real problem understanding what was going on in our
workstations after a couple of interruptions.
Therefore, I would like to propogate, to designers of workstations,
a user interface folk theorem that I heard recently: NEVER HAVE
MULTIPLE LEVELS OF STATE ENCODED INTO A DISPLAY.
Naturally, I am curious as to what others feel this restriction will
do to programming a user interface. I would also be interested in
collecting other folk theorems.
- Steven Gutfreund
Subject: Shades of Nicholas Negroponte
∂27-Jun-81 1022 PRSPOOL at RUTGERS Shades of Nicholas Negroponte
Date: 26 Jun 1981 1406-EDT
From: PRSPOOL at RUTGERS
To: Rivanciw.DHQ at UDEL
cc: WorkS at MIT-AI
The second part of Rivanciw's recent comments on Personal Workstations
sound very much like the DATALAND concept of Nicholas Negroponte of the
Architecture Department at MIT. Negroponte's ideas have progressed to a
somewhat more grandiose scale. He has built a special room containing a
wall-size screen and an armchair with input controls on both the arms.
His basic concept is that people often organize themselves SPATIALLY
rather than with the alphabetic keys by which ordinary random data files
are sometimes accessed. He has described the organization of a person's
desk at the office in such SPATIAL terms.
--Peter R. Spool
-------
Subject: Tools for personal workstations
∂27-Jun-81 1040 Eric Benson <BENSON at UTAH-20> Tools for personal workstations
Date: 26 Jun 1981 1103-MDT
From: Eric Benson <BENSON at UTAH-20>
To: Rivanciw.DHQ at UDEL, JWalker at BBNA
cc: WorkS at MIT-ML
One thing we should avoid in designing tools for use by non-programmers is
condescension. Elegance of design, yes, but simple-mindedness, no. There are
three aspects I see to this:
1. It should be possible in a short period of time (perhaps less than a day,
depending on the application) to learn enough about it to be productive.
2. The expert user should be able to make maximal use of the features available
without being hampered by the requirements for (1).
3. A smooth transition from (1) to (2) should be possible.
An excellent example of this is the Tops-20 command language (EXEC). I
assume most of you are familiar with it. By combining command completion
(recognition), abbreviation and menu-on-demand, the needs of expert and
novice are served equally well.
Another example is the Emacs text editor. It is used by nearly everyone
here, including administrators and secretaries. It is possible to learn
enough in an hour to make productive use of it, then acquire facility in
advanced features (editing modes, TAGS, word abbreviations, etc.) to make
it a powerful tool. In addition, since it is programmable (all key
definitions are soft), a wizard can add features for specialized
applications. (Admittedly, no one in their right mind would use TECO as a
programming language; that was a design error not likely to be repeated.)
We don't have to choose between programs that are continually asking
Do you want to pick your nose (Answer YES or NO)?
and the arcana of Unix command names. We can have the best of both worlds.
-- Eric
-------
Subject: Languages for Distributed Workstations
∂27-Jun-81 1101 Steven H. Gutfreund <SHG at MIT-AI> Languages for Distributed Workstations
Date: 26 June 1981 12:15-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: SHG at MIT-AI
As a researcher in local-area networks I have been quite puzzled by the
rash of comments in this digest about MESA. Many people seem to feel
that having MESA will solve their programming problems.
Personally I have found MESA to be just another member of the new class of
operating system / user environment / system programming language that is
coming on the scene. I have seen nothing that especially recommends it
for local area distributed processing (either closely coupled or loosely)
and it certainly does not have the graphics or user customizability that
a language such as Smalltalk-80 has.
I believe that the choice of which language to run on a distributed
workstation is probably the most imporant one that a workstation
ARCHITECT will make. Especially since this new class of programming
languages not only define a programmer interface, but since they
are so expansive in character and tend to want to run stand-alone
and replace the exec, they also define: the user interface, the performance
of the exec, the higher level flow control protocols, the network
wide naming conventions...
The PARC group has certainly done outstanding work in many of the
areas of research in local area network languages: name servers,
flow control, metaphors for network communication, resource allocation,
distributed file systems (Woodstock), and network servers. However,
I encourage serious students of these issues to look at what other
fine researches have done:
EPL - Experimental Programming Language, Developed at the
University of Warwick, An Actor based language, currently
in use at the University of Conn. by Ed Balkovitch.
CPascal Concurrent Pascal, Per Brinch Hansen's Language for easily
building concurrent programs such as SOLO, a simple O.S.
CSP - Communicating Sequential Processes, CAR Hoare seminal work
on abstractions for distributed parallel computing.
Aug 1978, CACM
CLU - Barabara Liskov's (MIT) concurrent programming language, intro-
duces the idea of Guardians, currently in use at MIT by
Micheal Hammer's group working on the NU machine.
?? - Distributed Processes, another Brinch Hansen lanaguage for
concurrent distributed. Nov 1978 CACM
Act1 - One of the numerous Actor Languages from Carl Hewitt (MIT)
Edison Per Brinch Hansen's latest language on for multi-computer
systems.
*Mod - Modula based language being used at University of WISC in
their distributed programming project.
Actors Viewing Control Structures as Patterns of Passing Messages,
MIT AI Memo 410. Carl Hewitt's paper on Actors, Some of the
most difficult reading to be found.
DC-Pascal Distributed Concurrent Pascal, this is a language I developed,
which tries to be a fusion of the above mentioned languages.
I have not even begun to cover the full scope of literature. Clearly
this is an active area for reseach, and clearly there will be more
papers since there are plenty open areas for research.
- Steven Gutfreund
Subject: system architecture
∂27-Jun-81 1124 Rivanciw.DHQ at UDel system architecture
Date: 26 Jun 81 15:20:27-EDT (Fri)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 26 Jun 81 16:29-EDT
Peter Deutsch requested that I send along a short summation of
DARCOM's system architecture for OA (in particular hardware, software)
so here goes.
The software that DARCOM is running in its OA architecture is UNIX.
Right now we have some v6, some pwb, and some v7. We will standarize
on the latest release of UNIX from BELL. Our tools are currently all
in the public domain except for an office package that we have running
on our HQ machine called OPUS. The public domain software includes
NED, ED, MSG, MS, and (I think its public) XMSG, as well as some
home grown tools such as a suspense program (which is really a shell
routine) and an automated weekly activity report.
The hardware for our architecture is simply any machine that runs
UNIX. Currently we have 11/70s and ONYXs operational. We are
looking into the C machine from BBN. Of course we are interested in
the latest announcement on ZENIX (Unix look alike for any 16-bit
micro).
Randy
Subject: Mini/Micro Systems June 1981
∂27-Jun-81 1138 KESSLER at UTAH-20 (Robert R. Kessler) Mini/Micro Systems June 1981
Date: 26 Jun 1981 0743-MDT
From: KESSLER at UTAH-20 (Robert R. Kessler)
To: Works at MIT-AI
Two possibly useful articles:
"Xerox 'Star' shines on professionals", page 23 and
"Novell's Nexus addresses work-station market", page 99.
Bob.
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂27-Jun-81 1151 Chris Ryland <RYLAND at SRI-KL> Re: Xerox Dolphin (alias 1100⊗?)
Date: 26 Jun 1981 1200-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: TEITELBAUM at RUTGERS
In-Reply-To: Your message of 25-Jun-81 1836-PDT
Yes, the Dolphin is being sold by XEROX EOS as the 1100 "Interlisp Machine."
It is about $60K, last I heard (someone at Rand or ISI correct me here.)
It is also about 3 times as slow as the Dandelion (what's inside the Star),
according to very reliable people at PARC; that is surprising, since the
Star costs little by comparison ($6K in parts costs, I've heard.)
Also, XEROX is now putting up Smalltalk on the Star, for internal use.
I have no idea, and I suppose neither does XEROX, if they'll ever release
it.
-------
∂27-Jun-81 1204 Newman.ES at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 26-Jun-81 12:12:38 PDT (Friday)
From: Newman.ES at PARC-MAXC
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Looks like a true rumor to me. The following is excerpted from a PARC Forum
announcement sent to all users of the Xerox message system. It was an open
forum, so this is public information.
-----
The Xerox 1100 Scientific Information Processor, currently being marketed by
Xerox EOS to the research community, is a Dolphin processor running
Interlisp-D. Not only does this configuration provide comfortable
interactive performance, but the availability of Interlisp on such a low cost
machine makes economically viable the widespread use of knowledge based
technology, such as the deployment of intelligent servers in a distributed
network environment.
-----
(Xerox EOS = Xerox Electro-Optical Systems of Pasadena, Calif.)
The "Dolphin" is the same processor used in the Xerox 5700 laser printer.
This is NOT the "Dandelion" processor used in the Xerox Star.
/Ron
∂27-Jun-81 1221 mike at RAND-UNIX Re: Xerox Dolphin (alias 1100⊗?)
Date: Friday, 26 Jun 1981 11:10-PDT
To: TEITELBAUM at RUTGERS
Cc: works at MIT-MC, archer at SU-SCORE
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: Your message of 25 Jun 1981 2136-EDT.
From: mike at RAND-UNIX
The Xerox SIP 1100 (Scientific Information Processor 1100) is really
going to be marketed by Xerox EOS (Electro Optical Systems). Here's
the deal:
It will sell for $60,000 a copy
It will have Interlisp. It will not have Mesa. It will not
have Smalltalk. (Maybe later it will, but they are not
promising it today).
It will have the 3mbit Ethernet. 10mbit later, but not this
year.
They wont sell any unless they get 'some minimum number of
orders'. The number that is most often mentioned is 40. (That
is, 40 altogether, nationwide. Not from one customer.)
The kind of maintenance available depends on where you live.
If you are not in LA or Palo Alto, then you will probably have
to do maintenance by paying time, materials and travel. The
other possibility is to stock spare parts and swap boards.
XEOS is considering, and would prefer, to have a complete
maintenance organization if there is the interest and enough
Dolphins in one place.
This deal is taking place because, among other reasons, ARPA
is looking for a way to get personal, networked Interlisp
machines to some of their researchers.
Xerox is accepting purchase orders now.
Let me know if you want a phone number for a Xerox contact. Your
local sales organization will probably not be of any help.
Michael
Subject: Personal Workstations
∂27-Jun-81 1240 Rivanciw.DHQ at UDel Personal Workstations
Date: 25 Jun 81 9:08:01-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 25 Jun 81 9:01-EDT
In Kevin Dowling's message of 18 June he mentioned that "the
people on this list are probably not the market that Xerox is
aiming for (as opposed to the business community)". This makes
me wonder - who are the people on the personal workstation
mailing list? It might be a good idea to kind of introduce
ourselves to each other. Like the quote goes:
"Where a man stands usually depends on where he sits"
I am Randy Ivanciw, a computer specialist with the US Army
Development and Readiness Command (DARCOM). My major duties
include long range and short range planning for office automation.
I work at DARCOM headquarters (I am a civilian) as a member of
a 7 person staff dealing with the use, planning, implementation]
and other nasties of office automation.
Randy
[ If you would like to put in a brief description of who you
are and what your professional interest in this list is, we
will be happy to organize the responses for distribution in
an appropriate manner. A special mailbox has been established
to simplify the problem of collecting this material. Please
address your descriptions to WorkS-Census@MIT-AI. Thank you. ]
Subject: The Economics of Workstations
∂29-Jun-81 0747 WMACGREGOR at BBNA The Economics of Workstations
Date: 29 Jun 1981 0905-EDT
From: WMACGREGOR at BBNA
To: works at MIT-AI
cc: BTHOMAS at BBND, SCHANTZ at BBND
The commercial success of the personal workstation is largely a
matter of economics. Irrespective of the technical merits of the
various machines, they complicate installation planning by introducing
a new type of capital expenditure which typically cannot be financed
the same way as large, centralized computing centers of the past.
This may be an advantage or a disadvantage, depending on your point of
view.
On the negative side, the incremental cost of placing one new
user on a personal workstation is very large--the cost of the
workstation plus a local network interface and cabling, at least. For
centralized systems, the cost of adding one user to the community is
the price of a terminal and a terminal port (which is often dial-up,
and amortized over many users). Certainly there are many hidden costs
involved in either case, for example, the degradation of performance
of the centralized system as the user community expands; nonetheless
the capital expense of the physical equipment represents a fundamental
barrier, an "activation potential" if you will, for new users.
Are we making good use of the technology? From one point of
view, the development of personal workstations has been directed
towards increasing the computing power available to individual users
(the "KA-10 in your office" philosophy), at roughly constant or even
increasing capital cost per user. Can comparison shopping in the
small systems marketplace, a highly competitive part of the economy,
be a better idea in some cases?
In particular, I remember one reader of this list commenting to
the effect that he wasn't interested in small systems (e.g., micros
with 16-bit address spaces). I use an H89 (Z80 based system, 48K
bytes of RAM, 5" floppies) at home, and for the sake of comparison I
ran the Baskett test on this machine. I transliterated the program
into C for the C/80 compiler as directly as possible (almost token for
token), and even on the "small" system the object code is only of
modest size. The execution time was 542 seconds, as opposed to about
40 seconds for the Perq. This Z80 machine runs at a 2 MHz. clock,
which can easily be doubled to 4 MHz. reducing the run time to 270
seconds, about 6 times slower than the Perq.
I do not mean to suggest that we should all be using CP/M and
8-bit micros. But neither does it seem wise to pass over these "small
workstations" as being insufficiently powerful; they can be extremely
cost effective. The question is not whether these systems should be
used at all, but how they might be integrated into larger
environments. Suppose a user can afford to pay $3000 (about twice the
cost of a terminal) for a VT-103 (a VT-100 terminal plus LSI-11
processor). What functions can we place in this device to improve
performance? How should it be integrated into the network of personal
machines and shared hosts? Could we, for instance, support a window
package for the VT-100? (In fact, we can; examples already exist.)
From my experiences at BBN, it is clear that the economics of
personal workstations can be very complicated. Two troubling effects
that may be general phenomena are the sharing of one "personal"
machine by several people (and corresponding problems of data
security, authentication, etc., which have been pretty much ignored in
the "personal" workstation model), and the inability of low budget
projects to get into the game at all (it is difficult for people on
different projects to share the same machine, for many reasons).
I would be interested to learn how others are resolving these
issues, whether in software or by direct administrative control.
- Bill
-------
Subject: Interupting a workstation session
∂29-Jun-81 0825 Daniel L. Weinreb <dlw at MIT-AI> Interupting a workstation session
Date: 28 June 1981 22:11-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SHG at MIT-AI, WORKS at MIT-AI
I agree that it is hard for a user to keep track of a stack of
interruptions. Having to maintain a mental model of such a stack, and
having to remember what "exit this command level" will do, is a real
pain. Most interactive systems I have used have suffered from this
problem. The Lisp Machine solves the problem by having all of the
user's activities be at the same "level". There isn't any command
processor that "calls" programs which then "return" to the command
processor; you just move "sideways" from one thing to another. No
stacks are involved. (Actually there are still a few stacks in the
system, but they are being removed.) (There are some commands that mean
"switch back to the previous thing I was doing", which you sometimes
want, but nothing forces you to use these commands. (If you gives such a
"previous thing" command over and over, it switches between the same two
things, in case you were wondering.))
Not only is this easier to use, but it is more powerful. If you are
reading your mail and you are interrupted by a phone call, you can go
handle the phone call, and then put the caller on "hold" and go back to
reading your mail, and then get back to the phone call. That is, you
need not maintain a last-in first-our ordering among your actitivies.
This is one of the things I think is most valuable about the Lisp
Machine's overall user interface structure.
Subject: Re: Tools for personal workstations
∂29-Jun-81 0848 mike at RAND-UNIX Re: Tools for personal workstations
Date: Saturday, 27 Jun 1981 12:19-PDT
From: mike at RAND-UNIX
To: Eric Benson <BENSON at UTAH-20>
Cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
In-reply-to: Your message of 26 Jun 1981 1103-MDT.
Eric Benson's message implicitly compares the Emacs design with UNIX.
In his words, Emacs is elegant, UNIX arcane.
And that Emacs should be a guide for future designers !
And a merry,
CONTROL META SHIFT FOO
to all of you, too.
Michael
Subject: frisbees and floppies...
∂29-Jun-81 0911 Daniel L. Weinreb <dlw at MIT-AI> frisbees and floppies...
Date: 28 June 1981 21:15-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SK at MIT-MC
cc: WORKS at MIT-AI
You asked, "The instantaneous bandwidth of such a transmission system is
very high. So who needs a Chaosnet?" This was presumably in reference
to the use of floppy disks for inter-workstation file transfer.
While the instantaneous bandwidth may be the same, the overall bandwidth,
counting the playing with the physical disks, is much lower.
Furthermore, the net is superior because (1) you can't do remote login
over floppy disks, nor asking what time it is, nor asking who is logged
in, nor anything else besides file transfer, and (2) it is very clumsy,
especially if the other machine is across the street or down the block.
Direct and easy access to a shared file server is important.
Subject: Addressing and File Accessing
∂30-Jun-81 0205 Barns at OFFICE Addressing and File Accessing
Date: 29 Jun 1981 0544-PDT
From: Barns at OFFICE
To: WorkS at MIT-ML
cc: Barns
The recent discussions of address space size, remote file access, etc.,
brought back to my mind the IBM System 38 - specifically the notion of
only one kind of addressing (48 bits in that machine) which is used
to access "main memory" or data on secondary storage - rather than
having files, there is the notion of various "access paths" possibly
existing through a great heap/swamp/"data base" of bits and bytes.
As far as I know the machines under discussion generally belong to the
Multics/Tenex/Unix school of thought that on the one hand, there is
memory, and on the other hand, there are files. All sorts of nasty things
like networks, terminals, users, etc., are mapped into one of the two
(usually files). But it seems to me more desirable (in principle at least)
to have only one kind of thing ala S/38, with various notions of access
paths, objects, classes of objects, etc.
I for one would be interested in knowing if my feeling is shared by
others, and also whether there are any plans on the part of the research
groups or other entrepreneurs to build such machine/software combinations
for those of us who would rather not program in RPG.
Bill Barns
-------
Subject: Re: el.POBox; 19 Jun 81 7:36-EDT
∂30-Jun-81 0222 Deutsch at PARC-MAXC Re: el.POBox; 19 Jun 81 7:36-EDT
Date: 29 Jun 1981 09:58 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 25 Jun 81 8:26:40-EDT (Thu)
To: Rivanciw.DHQ at UDel
cc: JWALKER at Bbna, WorkS at Mit-Ai
The Xerox Star terminal interface is structured exactly the way
you suggest -- it gives you a "desktop" of capabilities which
(subject to the space limitations of the screen) you can "reach
for" at any time.
Subject: Multiple Levels Of State
∂30-Jun-81 0244 Rivanciw.DHQ at UDel Multiple Levels Of State
Date: 29 Jun 81 9:41:58-EDT (Mon)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 29 Jun 81 12:27-EDT
In Steven Gutfreund's recent message on user environments he mentioned
that it would be best to "NEVER HAVE MULTIPLE LEVELS OF STATE
ENCODED INTO A DISPLAY". I am not quite sure what Steve is really
going for here - does this mean never to have more than one level
on a screen at any given time? or does this mean not to have the
system track where and what a use was doing? I am not sure.
My thought are that in my work environment I am constantly being
interupted by phone calls, urgent messages (electronics as well
as paper), and drop in visits. Often times I can not remember
where I was or what I was doing (Steve mentions this problem in
his message). It was my hopes that an office system could help
me keep track of where I was and what I was doing.
For example, right now I am composing a message to the WORKS
mailbox. Suddenly an urgent electronic message header comes up
on my screen that I must answer right now. I abort this message
(naturally saving the draft) and read the new message, check other
files (calendar, saved messages, suspenses, etc) and compose a
reply. That might take 15 minutes. In the meantime my phone
rings or I have to make a call that requires me to divert my
attention elsewhere. Then someone stops by my desk to tell me
about their weekend or talk about some configuration.
Bottom line is that I forget all about this message. I simply
did not remember where I was or what I was doing. Several days
from now I'll see a file named DRAFT-WORKS and wonder what it
is. I'll read the file into the editor and suddenly remember
what I was doing, but by then the reply may not be worthwhile.
In a very rich user system, the system would keep trach of where
I am so that when I said continue it would take me back to this
message reply and I can finish it. I feel that this tracking
would have to go at least 3 or 4 levels deep.
What are some other thoughts?
Randy Ivanciw
Subject: Re: Tools for personal workstations
∂30-Jun-81 0303 Eric Benson <BENSON at UTAH-20> Re: Tools for personal workstations
Date: 29 Jun 1981 1232-MDT
From: Eric Benson <BENSON at UTAH-20>
To: mike at RAND-UNIX
cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
Mike's response (more like a Bronx cheer) forces me to clarify some of the
points I was trying to make:
First, I could not say that the design of Unix is not simple, clean and
well-integrated from top to bottom. In fact, I only objected to one thing,
certainly not a central point, which is the cryptic command names (cat, mv,
rm, sh, ls, grep). These are almost as mnemonic as PDP-10 opcode names.
(Jrst enough for some, I suppose.)
Second, Emacs is no Mies van der Rohe creation. The implementation is at
three levels, MIDAS, TECO, and Emacs keyboard input, the first two of which
are incompatible with each other and sane human beings. The single
character commands are also cryptic, but there is readily accesible online
documentation for them. Common editing commands are often used in rapid
succesion, necessitating brevity. (Although I believe I saw an editor
described in Software P & E using the Tops-20 COMND JSYS which looked
somewhat interesting for novices.) Mike (apparently) objects to the use of
extra shift keys for commands. This is required because there is no
"insert mode" in Emacs; what you see is what you get. That is what
distinguises it from every other editor I have used, and is the most
important aspect of its design. Also, by not requiring special editing
keys or other input devices such as a mouse, a good typist can remain in
registration when entering commands.
Unix was designed when CPU power, memory, address space and terminal
bandwidth were scarce resources. Its popularity (in academic circles) is
due to its accessibility, portability and malleability. I only hope
in extolling its virtues we do not overlook its shortcomings.
-- Eric
P.S. Sorry for getting a little off the topic of personal workstations per
se, but I believe this is relevant to system design.
-------
Subject: On productive text editors, suggested reading includes
∂30-Jun-81 0319 DREIFU at WHARTON-10 (Henry Dreifus) On productive text editors, suggested reading includes
Date: 29 Jun 1981 (Monday) 1448-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
this month's SIGPLAN (#6) on the Text-Manipulation conference conducted
earlier this year. It goes into some detail (Yale's "Z" envr for exmpl)
on how some systems were put together, and what benefits they provide to
the work-area.
Hank
Subject: ALANTHUS System 1000 workstation
∂30-Jun-81 0330 Edward Kozel <EKozel at SRI-KL> ALANTHUS System 1000 workstation
Date: 28 Jun 1981 1236-PDT
From: Edward Kozel <EKozel at SRI-KL>
To: WorkS at MIT-AI
I have some literature on the ALANTHUS System 1000 workstation. It is
a 16-bit machine with high resolution display (15"), up to 1M of RAM,
and a set of either twin 8" floppies or a winchester drive. It is
configured in an interesting manner, with the "guts" (RAM, controller,
etc.) in a chassis sitting upright on the desk with a clipboard on
the3 side to disguise the box. This allows the entire system to be
off the floor (excepting mass store, which can be across the room).
They claim the desktop units can be lined together via a high speed
LAN, providing multi-station access to shared resources. They are
on the Federal Supply Schedule, which (I assume) lends some
respectability to the enterprise. They use both the Intel 8086
and 8088 in their various configurations.
Sounds like they are using Convergent Tech gear. Does anybody know
otherwise?
Ed Kozel
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂30-Jun-81 0353 Deutsch at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 29 Jun 1981 09:55 PDT
From: Deutsch at PARC-MAXC
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Your information is correct. The Xerox 1100 is a Dolphin with
Interlisp. Its speed is approximately 1/2 KA-10 equivalent,
assuming you buy enough memory (~ 1 MByte) so that paging doesn't
kill you. It comes with a 600 x 800 bitmap display, a 28 Mb
non-removable disk, and a mouse; I'm sure some flavor of Ethernet
will also be available. I have no information on purchase price,
delivery schedule, etc. as yet.
Subject: Xerox 1100 (Dolphin)
∂01-Jul-81 0257 DEUTSCH at PARC-MAXC Xerox 1100 (Dolphin)
Date: 30 JUN 1981 1335-PDT
From: DEUTSCH at PARC-MAXC
To: WORKS at MIT-AI
I inadvertently quoted the 1100 speed for Interlisp as 1/2 KA-10.
The correct figure is 2 KA-10. The standard configuration being sold
includes roughly 1.2 MByte memory and a network connection.
For further details (including price, availability, options, etc.),
people should contact Marcel Pahlavan in Xerox EOS at (213)351-2351.
Some people in Xerox management are understandably a little concerned
that some busybody might narrow-mindedly disapprove of the use of the
ARPANet for discussion of a commercia\ product, although I don't see
how an informed discussion of personal workstations can proceed in the
absence of quite detailed information (technical and`otherwise).
Subject: ALANTHUS System 1000 workstation
∂01-Jul-81 0321 Brian P. Lloyd <LLOYD at MIT-AI> ALANTHUS System 1000 workstation
Date: 30 June 1981 08:45-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Alanthus is indeed selling the Convergent Technologies system. There
are now three flavors of workstation: the Integrated Workstation
(IWS), the Monitor Workstation, and the Applications Workstation. The
IWS and MWS are electrically identical with the difference being that
the processor is remoted into a box like the mass storage. Only the
display and keyboard remain on the desktop. The Application
Workstation (AWS) is the "low cost" workstation and physically
resembles the IWS. The AWS is based on the 8088 (instead of the
8086), has fewer bells and whistles (no serial/parallel I/O, font
fixed in ROM, etc.), and has no Multifus expansion. The advantage of
the AWS is that it is about half the cost of the IWS and suddenly the
cost-per-workstation falls into the $5,000 range. The AWS can run all
of Convergent's software with the exception of the Font Designer.
Brian
Subject: Clarifications about interrupting workstaions
∂01-Jul-81 0334 Steven H. Gutfreund <SHG at MIT-AI> Clarifications about interrupting workstaions
Date: 30 June 1981 1p:52-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: DLW at MIT-CI, rivenciw.dhq at UDEL
Re: Clarifying my comments on Interrupting workstation activity
I tend to aoree with Daniel Weinreb's comments about the need
to structure the user interface so that one can move gracefully
"side-ways" between windows/activities. He states that the
ability to movc "side-ways" was lone by the removal of calling
or nesting of routines.
This nesting of dialog or routines is what I am trying to point
out as a danger area for system designers. If one allows
a designer to create an arbitrary state machine by means of a
protracued dialog, then the user will be required to read the
entrails of his display to try and reconstruct the dialog that
occured earlier when he interrupted his session.
Randy Ivanciw is gorrect when he says that a system could be
built which would "refresh" the user's memory when he returns
to a window. However the problem with arbitrary state diagrams
in dialogs is that such a smart assitant would have to understand
all transitions that a user could have made. Pre-designing
such help into a dialog is a massive chore, and therefore rarely
done well or done at all.
It seems to me that if one is to follow the old maxim: WHAT YOU
SEE IS WHAT YOU GET. Then we should not have state diagrams in
dialogs which cause the user to be able to read the entrails of
his/her display to figure out what has gone on before he/she
left a window.
- Steve Gutfreund
Subject: Re: Multiple Levels Of State
∂01-Jul-81 0344 Deutsch at PARC-MAXC Re: Multiple Levels Of State
Date: 30 Jun 1981 12:52 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 29 Jun 81 9:41:58-EDT (Mon)
To: works at Mit-Ai
Whoever mentioned the MIT Lisp machine solution hit the nail on the head: if
(1) there is no notion of "nesting" of suspensions, but rather simply a pool of
tasks in various stages of completion which the user can switch between at will,
and (2) every partially completed task is represented by a VISIBLE OBJECT on
the screen, then there is no issue about forgetting partially completed tasks,
being forced to complete them in the order they were started, etc., etc. I believe
(at least I hope) the Star works this way, since all the experimental
multi-window systems at PARC do.
Subject: Question to field: Bit Mapped displays
∂01-Jul-81 0353 DREIFU at WHARTON-10 (Henry Dreifus) Question to field: Bit Mapped displays
Date: 29 Jun 1981 (Monda{) 2210-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
o BIT Mapped displays.
Would anyone care to discuss what is a bitmap as oppsoed to
a raster-bitmap, as opposed to a whatever? I am certainly no expert
in this area, and the "Display" seems to be a key feature of most
Perscoms today.
Henry Dreifus
Subject: Addressing and File Accessing
∂01-Jul-81 0403 Vaughan Pratt <CSD.PRATT at SU-SCORE> Addressing and File Accessing
Date: 30 Jun 1981 1033-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-ML
I couldn't agree more with Bill Barns. Simplifying storage organization
is an important aspect of the more general goal of simplkfying the
user's perception of what is of necessity a very complex environment.
There is some support at Stanford for this goal; in particular we would
like to be able to offer users of SUN (Stanford University Network) a
simple coherent model of both SUN and (a rough approximation of) the
world outside SUN. Some vague thoughts along those lines appear in
<CSD.PRATT>SUNUI on Score. Brian Reid and I are mulling over such
ideas during this summer.
-------
Subject: Re: File accessing?
∂01-Jul-81 0413 DREIFU at WHARTON-10 (Henry Dreifus) Re: File accessing?
Date: 30 Jun 1981 (Tuesday) 2023-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: csd.pratt at SU-SCORE
cc: works at MIT-AI
And`what about providing parallel alternative file systems for
differing applications. Eg: Stream where Stream is good, and
chav where character is good (pipes). Make each system consistent
within itself and transparent to the end user. The system
developer can choose the file TYPEs s/he would be able to use
the most efficienly and blasto.
Hank
Subject: Re: Addressing and File Accessing
∂01-Jul-81 0428 host MIT-ML Re: Addressing and File Accessing
Date: 30 June 1981 11:46 edt
From> Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: Barns at Office-2, WorkS at MIT-ML
*from: BOB (Bob Frankston)
Local: Barns at OFFICE,WorkS at MIT-ML
Poor Multics. People seem to attribute all the limitations of
its imitators to the original. One of the major advances in
Multics was its large address space and the uniform treatment
of the address space. Files are not an intrinsic part of
Multics -- only a convention for access memory through I/O
routines. There isn't even I/O -- just a set of conventions
for writing for writing an I/O interface module.
Yes, the system/38 does work out a lot of the ideas and I still
feel it is IBM's most advanced system and have suggested people
look at it as a model. But from what I hear it has not solved
its performance problems, though the model of using gobs of
computational power to provide a powerful interface is the
correct one.
The other difference is that Multics provides the full power of
its process to its users. The System/38 is packaged like a
real computer but seems to be much closer to an assembly
language/PLS interpretter running the user code. It was clever
to invent the term vertical microcode, it means that they don't
need to give you a listimg of the operating system and are free
to change the internals as long as they preserve the user
interface.
Overall I think that the System/38 is a winner and one day IBM
will tell people that it is more than a System/34 upgrade. On
the other hand, I have not used it directly and RPG III (a VHLL
production language if you want to look at it that way) is the
only language currently available. It is also a little on the
expensive side, even compared to a Star.
Subject: Errata on Barns message "Addressing and File Accessing"
∂01-Jul-81 0445 The Moderator <WorkS-REQUEST at MIT-AI>
Errata on Barns message ''Addressing and File Accessing''
Date: 1 July 1981 07:00-EDT
From: The Moderator <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Original statement:
As far as I know the machines under discussion generally belong
to the Multics/Tenex/Unix school of thought that on the one hand,
there is memory, and on the other hand, there are files.
-- Barns at OFFICE
Comments:
Multics does not view files as something fundamentally different
from memory. Rather, it was the first system to support a uniform
single-level memory system consisting of variable size objects
(segments) from 4096 bytes to 1 megabyte in length. Files were
simulated in Multics for compatibility reasons only, and files
were constructed out of segments.
-- Paul A. Karger <PAK at MIT-MC>
An important correction for all of you who have never used Multics,
and are constantly assuming that it is like UNIX or TENEX. It is
not. Barns, for example, says that Multics/TENEX/Unix differentiate
between files and memory (and that the S/38 doesn't). Multics was
the first system to do away with the concept of file--Multics "files"
are merely part of its large virtual memory, and are accessed via
pointers. S/38 has few new ideas in this area, and a lot of crocks.
Pish tush. -- DPR at MIT-XX
You are completely wrong in classifying Multics in this group.
In Multics, there is absolutely no distinction between "memory"
and "files"; there are just segments, which live in a hierar-
chical file system and are addressed directly. The System 38
is a spiritual decendant of Multics in this regard.
Just because an idea is old-fashioned does not mean you should
identify it with Multics. For all Multics's problems and extreme
age, it is STILL ahead of its time in some ways. Sorry for the
irrelevance of this message, but I couldn't just let this go by...
-- Daniel L. Weinreb <dlw at MIT-AI>
Subject: Storage Question Restated
∂03-Jul-81 0806 Barns at OFFICE Storage Question Restated
Date: 1 Jul 1981 0628-PDT
From: Barns at OFFICE
To: WorkS at MIT-AI
cc: barns
Now that half the Multics users in the world have voiced their
displeasure, let me try to say what I was really trying to say
before, hopefully in a less offensive manner:
During the time period when Multics was born, that system
and others made varying uses of the idea of a single level
store. Naturally different people came up with different
hardware/software approaches and solved different subsets
of the universe of possible situations. Since then we have
had Tenex and Unix which have made their own contributions,
and also some steps backward because of the desire to make
something that doesn't chew up a disproportionate share of
a timesharing system's time. (Yes, many others too, but
Tenex and Unix are perhaps best known.) More recently the
S/38 has attempted to go back to some of the more general
ideas, which is noteworthy in that it is not such an enormous
processor, nor is it intended to be a timesharing system of
the flavor of Multics or Tenex or Unix. Unfortunately there
are also many unfortunate things about the 38 as now packaged
- notably the lack of programming languages that many of us
like to use, or reasonable substitutes.
Now it is my impression (unsupported by hard data) that the
38's processor is more or less in the same ballpark as (some
of) the workstation processors. This suggests that it is
not unreasonable for someone who has a mind to, to make a
programming environment on these machines, or ones like them,
which will give us a simple means of accessing data for the
purpose of local computation by the 'owner' of the workstation
and only apply restrictions on access to people elsewhere in
a network. I suggest that in the nicest form, this means that
the workstation's programs access things by an n-bit number
which is absolute for the whole workstation. This need not
mean that no other form of accessing can exist.
The question, then, is, What such things exist or are planned?
To date the responses indicate that the Lisp Machine has such
an organization and that the Perq will at some future date have
a virtual storage box to support such things at the firmware
level. Dan Lynch's message of sometime back suggests that the
STAR does its storage paging in a nasty way, not clean at all,
but details seem to be unknown outside Xerox. Anybody know
any more?
--Bill Barns
-------
Subject: Re: Addressing and File Accessing
∂03-Jul-81 0954 Chris Ryland <RYLAND at SRI-KL> Re: Addressing and File Accessing
Date: 30 Jun 1981 1131-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: Barns at OFFICE-2, WorkS at MIT-ML
In-Reply-To: Your message of 29-Jun-81 0544-PDT
Bill, the system you describe (System 38) is just a
capability-based machine, which is certainly old hat by now.
Unfortunately, this idea still seems to be barely catching on in
the "real world." Most of the seminal systems (CAL at Berkeley,
Hydra at CMU, and the Plessey System 250) were done and finished
years ago, and yet there are only a few commercial systems which
reflect this elegance of architecture (S38, Intel's 432 (in some
sense), some ICL machines). Others are working on systems which
embody these ideas (H-P's Bridge project, the S-1 project), but
most of them bastardize the design for "practicality". I surmise
that capability-based systems are finding life difficult because
no one ultimately understands how to deal with them practically
(e.g., the Hydra folks discovered quite a few problems with
accounting (who owns an object?), backup, recovery, etc., though
they also made great strides with some of the harder issues
(mostly reliability).) I think a large percentage of us would
be delighted to have a true capability-based machine if the
performance were up to what we've come to expect from current
architectures, but that doesn't seem to be around the corner (at
least in any useable way: S38 hides all its good design from the
user and masks it in the usual nonsense IBM business software.)
-------
Subject: Re: Question to field: Bit Mapped displays
∂03-Jul-81 1034 cfh at CCA-UNIX (Christopher Herot) Re: Question to field: Bit Mapped displays
Date: 3 Jul 1981 08:47:25-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: DREIFU at WHARTON-10
Cc: WorkS at MIT-AI
In response to your message of Thu Jul 2 20:26:38 1981:
Bit Map refers to the way a picture is stored, i.e. one
bit (or aggregate of bits for color) of memory for each
addressable point on the screen. As opposed to the older
"display list" technique where the picture is stored as a
list of line segments, etc.
Raster-scan refers to the method by which the picture is
refreshed on the screen, in this case, as a series of
horizontal lines, starting at the top of the screen and
moving down. As opposed to "stroke writers" which move
the beam in arbitrary directions to draw individual
graphic primitives.
The earliest displays were stroke writers. The TX-0 at MIT
moved a beam on a CRT under the direct control of the CPU.
In some sense, this was the first personal computer, as
refreshing the display didn't leave too many cycles for
anything else. Later, the direct view storage tube (DVST)
allowed the picture to be written just once instead of
being refreshed 30 or more times per second. Only problem
was that the only way to change anything on the screen was
to erase the entire screen in a blinding flash which took
.5 seconds. By the way, contrary to current publicity about
the STAR, the Advanced Remote Display Station (ARDS) storage
tube terminal was the first to offer the "mouse" as an input
device.
Stroke writers are still in common use in the CAD/CAM area.
They typically employ high-performance (expensive) analogue
circuitry to draw vectors of much higher resolution than are
currently feasible with raster displays. Resolutions of
4096x4096 are not uncommon.
The raster scanned bit map display is rapidly taking over
the display scene. It is cheaper to build circuits which
move the beam in nice sraight lines across the screen than
to build in the ability to turn corners.
To answer your question, for all intents and purposes,
raster-bitmap and bitmap mean the same thing.
-----
Subject: capability machines
∂04-Jul-81 0915 HGBaker.Symbolics at MIT-Multics capability machines
Date: 3 July 1981 14:15 edt
From: HGBaker.Symbolics at MIT-Multics
To: ryland at SRI-KL, works at MIT-AI
1. A capability is just a fancy name for a pointer in a
machine that doesn't have enough address space to begin
with.
2. The current hangup of capability machines is their
unwillingness to do garbage collection. (Tracing, etc.,
that is.)
3. Lisp was the first capability machine. It is true that
the objects are quite small in the original Lisps, but
with newer Lisps having vectors, strings, objects,
classes, flavors, and what have you, they have all the
power of Hydras, 432's, etc.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 0945 Deutsch at PARC-MAXC Re: Addressing and File Accessing
Date: 3 Jul 1981 14:50 PDT
From: Deutsch at PARC-MAXC
In-reply-to: RYLAND's message of 30 Jun 1981 1131-PDT
To: WorkS at MIT-ML
I must be missing something. Barns wishes for "an n-bit
number which is absolute for the whole workstation". Isn't
a reasonable-size conventional virtual address a solution to
this problem, provided that the operating/language system
doesn't allow you to fabricate addresses? That's the only
sense in which the Lisp Machine solves the problem, and it
only does it by virtue of NOT having any local capability
for named files. The LM doesn't provide any facilities
that replace a local file system, either, e.g. there are
no tools in the system for constructing and manipulating
directories of variables. Furthermore, the LM would be
helpless without the presence somewhere in the network
of some very conventional file systems which handle messy
questions like space accounting, periodic backup, user
authentication, etc.
Of course, if you want local objects to be remotely accessible,
then you do need something much more like capabilities. Given
that mainframes (processor + memory) are so cheap these days,
compared to the cost of a reasonable-size disk, I'm more
inclined to favor putting all potentially sharable objects on
a separate server mainframe and let workstations either cache
them on their local disks or get them over the network whenever
they need to. This requires some architectural changes in the
world to make that network access comparable in speed to, say,
something between a cache miss and a bubble memory access, as
opposed to a disk access.
To the best of my knowledge, Star, like the research machines
(Dolphin and Dorado), has a conventional paged address space;
the Star OS provides for mapping full or partial files into
this space, like Tenex or Multics. The OS happens to be
optimized for mapping sequential runs of pages of a single
file into contiguous virtual pages, but that is an
optimization only.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 1019 gaines at RAND-UNIX Re: Addressing and File Accessing
Date: Friday, 3 Jul 1981 11:04-PDT
From: gaines at RAND-UNIX
To: Chris Ryland <RYLAND at SRI-KL>
Cc: Barns at OFFICE-2, WorkS at MIT-ML
In-reply-to: Your message of 30 Jun 1981 1131-PDT.
It is little known, but the new versions of the Honeywell 6000
have a memory management unit, internally known as NSA (for
New System Architecture, I think), which makes the machine a
form of capabilities machine. It is elaborate and baroque,
but underneath are some very powerful ideas. The architecture
supports multiple independent domains (where a domain is a set
of addressing capabilities), such that a process can consist
of many domains.
Honeywell is slowly attempting to extend the old GCOS-III
operating system to take advantage of this, and the new
version is being called GCOS-8. In addition, Honeywell
some years acquired the XDS Sigma (formerly SDS) business,
together with a little-know, but much loved by its users,
system called CP-5. The group that moved over from Xerox
as part of this deal convinced Honeywell that the operating
system could be ported to the Honeywell processor, and have
produced an interesting system called CP-6, which takes
advantage of the domain features in some nice ways. For
example, a process can have a debugger in one domain to
debug code in other domains, putting it far ahead of
almost any other system I know (including UNIX) in this
area.
Those interested in system design and memory management
approaches ought to be aware of what is going on here. It
represents a significant extension to the thinking about
domains and capabilities. Unfortunately, there is little
in the way of reports or other decent documentation, but
perhaps some beating on Honeywell would produce something.
I'm not sure that this is the right forum for this discussion.
It would be nice if someone would start and manage a conference
dealing with operating system and system design issues. WorkS
and InfoMicro seem to have lots of people interested in these
topics, but they are really focused a bit more narrowly and
differently.
Subject: Xerox 820 Ethernet compatability
∂04-Jul-81 1047 BILLW at SRI-KL Xerox 820 Ethernet compatability
Date: 1 Jul 1981 1402-PDT
Sender: BILLW at SRI-KL
From: BILLW at SRI-KL
To: works at MIT-AI
Message-ID: <[SRI-KL] 1-Jul-81 14:02:56.BILLW>
I have here a piece of Xerox (propaganda) on the 820. I says,
And I quote:
"In addition, the 820 is an investment that will fit into
your long-range plans, since ETHERNET compatibility is
available through the 872/873 Communication Server using
Teletype communications mode on the 820"
I will not make any comments.
Bill Westfield
-----
Subject: EMACS -vs- UNIX
∂04-Jul-81 1219 mike at BRL EMACS -vs- UNIX
Date: 30 Jun 1981 at 2026-EDT
From: mike at BRL
To: WorkS at mit-ml, unix-cpm at udel
cc: Rivanciw.DHQ at udel, benson at utah-20
Folks -
"Eric Benson's message implicitly compares the Emacs
design with UNIX. In his words, Emacs is elegant, UNIX
arcane."
Both this comparison and the conclusion disturb me.
Comparing an editor (which can be thought of as having 3
levels) with an operating system (which has many levels of
complexity) is kind of off-the-wall, but lets play along...
INTENT: The intent of EMACS (as I see it) was to
provide a "what-you-see-is-what-you-get" screen editor
which behaved similarly over a wide range of terminal
keyboards (and terminals), and to permit construction
of Macros to implement higher-level features (LISP
indenting, etc). The intent of UNIX was to provide
a powerful, plesant, and consistent environment for
Computer Science types to experiment and build tools
in.
In a word, the intent of UNIX is "Software Tools",
whereas the intent of EMACS is "Software TOOL". Humm.
USER INTERFACE: Everybody will be quick to agree that
EMACS has a simple to learn user interface, at least to
gain "novice" status. The more intricate commands become
more obscure, and less mnemonic. (Everybody agrees that
Meta-Control-single←character can get obscure).
"What-you-see-is-what-you-get" is Motherhood and Apple Pie
for screen editors, and EMACS definitely succeeds here.
The UNIX user interface is designed to save typing while
remaining reasonably mnemonic. A remarkable number of
"Advanced" users can't type very well, so this is laudable.
Unfortunately, this means users take a while longer getting
used to the command abbreviations. There exist variants of
the UNIX Shell (command interpreter) which accept abbreviated
commands and do other nice, user-helpful things (although the
"standard" (dumb) shells are more common).
Initial EMACS and UNIX users face much the same problem...
LOTS OF SQUINTY LITTLE COMMANDS.
UNDERLYING STRUCTURE: As I understand it, EMACS can
be thought of as having 3 layers: The user interface/screen
control stuff, the Macro level commands, and the macro
implementation level (Typically TECO). Certainly, the top
level is easy to use. The Macro level can usually be learned
and profitably USED by ordinary mortals, but the macro
implementation level (TECO or whatnot) requires a Wizard
to get good results.
UNIX can be thought of as a number of levels, nested:
The terminal driver & line protocol (control/s/q & "cooked" editing).
The Shell (command interpreter)
Programs (System commands & User programs have identical status)
The I/O Library (Buffering & simple file mgmt)
The System-Calls (Direct requests made to the UNIX Kernel)
While each of these levels may have some overlap and
inconsistencies, the general "clean" philosophy of having
only one mechanism to accomplish one result is generally
evident, and a real pleasure! [More on this some other day]
"UNIX productivity must be thought of, not in terms of lines
of code written per unit time, but in terms of lines of code
NOT REQUIRED..."
CONCLUSIONS: I feel that EMACS is one of the better screen
editors around, mostly because of the "macro" facility which
permits powerful features to be built on top, and I feel that
UNIX is definitely the best operating system that has surfaced
to date, because of the consistent system-call interface, and
the "Software Tools" approach to commands.
HENCE, I think that all UNIXs should have an EMACS, and
everybody should run UNIX!
-Mike Muuss
Ballistic Research Laboratory
PS: There exist EMACSs small enough to fit on an 11/34, and
UNIX runs on everything these days, so this is less of
a pipe-dream than it may seem!
-------
Subject: CMU Workstation milestone
∂04-Jul-81 1250 Sam.Harbison at CMU-10A CMU Workstation milestone
Date: 1 July 1981 1509-EDT (Wednesday)
From: Sam.Harbison at CMU-10A
To: works at mit-ai
Message-Id: <01Jul81 150913 SH01@CMU-10A>
I thought people might be interested to know that CMU took
delivery of its 20'th Perq yesterday. Ten are in offices
of people working on Spice-related projects, and ten are
in public areas, also being used mostly for Spice work.
-----
Subject: Re: Ethernet capabilities of 820 and STAR
∂05-Jul-81 0920 guyton at RAND-UNIX Re: Ethernet capabilities of 820 and STAR
Date: Saturday, 4 Jul 1981 18:51-PDT
From: guyton at RAND-UNIX
To: Rivanciw.DHQ at UDEL
cc: Works at MIT-AI
In-reply-to: Your message of 1 Jul 81 11:09:18-EDT (Wed).
I worked for a couple of years for Xerox on the Star product and
after this slanderous message I will no doubt never be welcomed
back. However I can't resist trying to shed a little light on
the confusing state of the Xerox office automation product line.
The key to getting through the Xerox propaganda is to realize that
there is NOT one, but TWO office automation product lines which
have been forcefully "merged." These lines were developed by two
competing groups and don't really have much in common.
The two competing groups are now both under the common banner of
the "Office Products Divison" of Xerox, and are attempting to
cooperate. But until a year or two back . . . well, I'll be
polite and just say that they were very serious competitors.
The older group is out of Dallas, Texas. The new group is split
between Palo Alto and El Segundo (both in California). Here is a
short table summarizing what I think are their main differences:
"SDD" "OPD"
+-------------------------+-------------------------+
Location | California | Texas |
+-------------------------+-------------------------+
Programming | MESA | Assembler |
Environment | | |
+-------------------------+-------------------------+
Processor | Custom Bit-Slice | Standard u-processors |
+-------------------------+-------------------------+
Background | PARC/Research | Electronic Typewriters |
+-------------------------+-------------------------+
Product Lines | Star | 820 |
(Partial list | File Server | 850 |
due to failing | Communication Server| 860 |
memory) | Ethernet | |
| Laser printers | |
+-------------------------+-------------------------+
The two product lines evolved and were designed seperately. When
both groups were merged into the "Office Products Division" it was
decided (wisely I believe) to merge the product lines as much as
possible. So the Dallas products are all going to be on the
Ethernet, and everything will talk with everything else. It is a
worthy goal, but as you might imagine, there are a few rough spots
in trying to do it.
I hear that the Xerox sales force is claiming that they have an
integrated product line for office automation. Low cost 820's up
to the Star. Ah . . . I don't think I can agree with that. I
believe they are undermining their credability when they try to
convince people of this.
As for the confusion arising from the ignorance of the Xerox sales
force . . . they are all out of Dallas and the Star stuff is brand
new to them. When I'm not upset about the propaganda I'm actually
kinda pleased to see that they've done as good a job as they have.
Jim
P.S. Randy -- to answer your specific message, the products in
column one all have the Ethernet designed and built in from the
start. The products in column two have had the Ethernet added
with chewing gum and bailing wire (if at all).
-----
Subject: Switching tasks and context
∂05-Jul-81 0958 JWALKER at BBNA Switching tasks and context
Date: Wednesday, 1 July 1981 11:52-EDT
From: JWALKER at BBNA
To: WorkS at AI
I don't follow the relevance of all this talk about "state
diagrams" in the discussion of resuming a suspended activity.
The human side of resuming something involves answering the
question "Now, where was I?". One very effective answer to
that question is the screen display of the task as it was
when you left it. (It is perhaps not the best answer, but
the best answer involves some meta-knowledge of what you
thought you were doing and your intentions for the various
commands you had used. I am willing to assume that someone
can recognize what they were doing given the set of commands
they had issued before stopping work.)
I concur that the approach taken by the LISP machine and other
multi-window systems (that keep track of various process objects
and reinstate their displays when the objects are selected) is
correct. These systems typically provide two ways of picking up
a dropped ball -- by using a mouse to select one of the objects
whose window is currently visible on the screen, and by using
a mouse to select an object from a menu window that contains a
brief description of each of the objects. The menu gives you
complete context for "where was I?" by showing all of things you
are juggling. This is very important because the fewer details
you have to keep in your head about what you are doing, the more
head is left over for actually getting the work done...
Simply resuming a dropped activity should not be a problem
solving activity ("now, let's see, I think I had that running
as a kept fork under Hermes, which is running as a kept fork
under EMACS..."). The "multi-forking" TOPS-20 execs that exist
at several places (e.g. MIT, Stanford, Rutgers) also support
users who need to move "sideways" to do a task although TOPS-20
doesn't provide anything in the way of reinstating the display
context.
-----
Subject: Multiple Levels of State
∂05-Jul-81 1106 Mike Leavitt <LEAVITT at USC-ISI> Multiple Levels of State
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI] 1-Jul-81 18:15:41.LEAVITT>
For general purposes, the LISP approach seems entirely
reasonable. For a workstation, I'm not so sure -- this
is a very special case. There are a relatively limited
number of types of things I am likely to be doing, and
each of them has its own intrinsic priority. When they
are interrupted, they carry with them an implication of
how soon they should be resumed.
For example, if I have to interrupt a phone call and put
somebody on hold, this is basically different from what
happens as I am going through my in-box and someone comes
into my office. Granted, I would like to keep track of
where I was both in the phone call, and in the in-box, but
my system should and could be smart enough to understand
the difference, and indicate that YOU HAVE SOMEONE ON HOLD,
TURKEY, before I finish the interruption and go out for a
cup of coffee. Incidentally, I have been know to leave
people on hold in just such a situation.
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Subject: Spatial design for a workstation
∂05-Jul-81 1206 Rivanciw.DHQ at UDel Spatial design for a workstation
Date: 1 Jul 81 10:03:14-EDT (Wed)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 1 Jul 81 10:49-EDT
I am quite impressed with the degree to which you all responded
to my questions or thoughts on changing modes of operation in a
workstation to better reflect the way one does business.
Here is a scenario I would like to take you through. It is
about Debbie, an action officer in federal agency. Debbie
has an automated office. She has just sat down at her desk
(after getting her coffee) and is about to start her day of
work.
Debbie logs onto the system. Rather than being dropped at
operating system, she is dropped into the office automation
program (or shell). The first thing she sees is the top of
her desk on the screen.
There's an inbox, a notepad, a file cabinet, a phone, a
calendar, etc.
Debbie reaches for the inbox by either moving a cursor to
the inbox or typing "inbox". The inbox expands to fill
the entire display. In the inbox is a stack of messages
- visible on the screen. One of the messages is flashing
(or in a red envelope) indicating some level of importance.
Debbie reaches for that message first by pointing at it
with the cursor (or typing a command to read it).
The message requires a quick response. Debbie must gather
some information from several sources to answer the message.
One source of information is a phone call away. Debbie types
"desk" (or hits a function key labelled desk) and is back at
the top of her desk.
She then points to the phone and the screen fills with a
phone message pad on the left (to take notes on when a
call comes for someone else in the office) and several
phone directories stacked in the right hand corner. She
points to the phone directory labeled "DARCOM". She types
in the first couple of letters of the person's last name
(the person she is trying to reach is me - she does not
know how to spell Ivanciw - so she just types in "IVA".).
The phone directory opens to the first page with names
beginning with IVA. Debbie sees the number and dials it.
While she is talking on the phone she wants to take notes.
She gets back to the top of the desk and points to the
notepad. The notepad expands to fill the screen. She
types her notes on the notepad (which is really just an
editor).
At the conclusion of the phone call the she goes back to
the top of the desk and once again points at the inbox.
The inbox opens with the message she was last reading.
She realizes that she needs the info on the notepad to
answer the message so she types notepad - the screen
splits and the notepad with the phone notes comes on
the screen beside the urgent message.
Ah, yes, Debbie just realized that she needs some info
from the file cabinet. She types "FILE CABINET" or hits
a function key labeled "file cabinet" and a picture of
a file cabinet appears on the screen. She points to
the file drawer labeled "A-C" and it opens revealing 30
folder headers.
But wait, someone has just walked up Debbie's desk and
has asked if she had read the bulletin board this morning.
There was a notice about a presentation in the conference
room sometimes this morning. Debbie quickly hits the "desk
top" botton and points to the Bulletin Board in the corner
of her desk. The Bulletin Board expands and shows subjects
for 15 bulletins. One subject is "PRESENTATION" and Debbie
user points to it and the bulletin expands on the left side
of the screen. Sure enough, the presentation starts in 8
minutes! and Debbie wants to go to it!
Well, now she has to work quickly! Hitting the FILE function
key the screen reappears with the file drawer "A-C" open
showing the 30 folder headers. She quickly spots the file
she wants and using the cursor (or a light pen, or maybe her
finger on a touch sensitive screen) points to the folder.
The folder opens up to reveal 3 separate papers on the topic.
Once again she points to the correct paper and types "close
file". The file closes and she is back in the inbox with the
urgent message, the notepad, and the new file-paper all on
the screen.
Hell! the phone just rang and she is the only one in the
office!! She picks up the phone and finds that it is for
someone else in the office. Quickly she hits the DESK
function key to get to the top of her desk and points to
the phone. The phone expands to show a phone memo pad
and directories. She moves her cursor to the memo pad
and takes a message for her co-worker. She hangs up the
phone and types hits the CONTINUE button. (The phone
message is automatically delivered to the co-worker).
Continue puts her back into the inbox with her three
files.
She decides that she can't finish the message right now
so she hits the bye button and goes to the presentation.
Debbie knows that the next time she enters her inbox the
three files will all be there and she can dig right into
the reply to that message.
********************************
Notice a few things:
o She never had to give a command to run an editor or a
message system. She only pointed to a function and if
it used the message system it used it (INBOX) or if it
used an editor it simply used it (PHONE MEMO, NOTEPAD)
and never required Debbie to type MSG or NED or EMACS
or whatever.
o She was interrupted several times and had to move through
several systems. In all cases she never had to say
"suspend" or "save" - she just went to another function.
When she returned to the function she left it was right
where whe left it. Imagine somebody constantly clearing
off the top of your desk everytime you changed functions
- that is basically what we do in the automated office
tools of today.
The above scenario is a concept that DARCOM is considering
incorporating into its office automation environment.
Please let me know your thoughts on this concept.
Randy Ivanciw
-----
Subject: Ivanciw's ideas &c: comments
∂06-Jul-81 0329 STECKEL at HARV-10 Ivanciw's ideas &c: comments
Date: 5 Jul 1981 (Sunday) 2116-EST
From: STECKEL at HARV-10
To: WorkS at MIT-AI
As an implementor type, I have a few questions. When I work,
I have at least three stacks of things on my desk (where each
stack has sub-sub-sub-, etc. stacks):
a) what I am trying to do on a long term
b) what I started this morning because it's gotta be done today
c) the phone rang and you need it when?!?!
So... the idea of "kept context" is a nice one, but I suspect
that there could be a lot of mess. What happens in Randy's
scenario when the phone call about line 78 (+ or -) required
the use of (1) messages (2) filing cabinet? How do you "file"
where you were in a file cabinet? My file cabinets have about
3000 things in them.
I also have a quibble about the "desk" key. If the interactive
whizzes can make the super page screen work, I would much rather
never have my "desktop" hidden...
I trust my machines about as far as I can throw them when it
comes to saved contexts. Why doesn't the "phone", "pad", etc.
stay around in "icon" form? Part of the idea of piles is that
you can still see the existence of a pile, even if you're not
too sure what's in it.
Unrelated quibble concerning EMACS, &C. I am in the (lonely)
minority of those who cannot stand EMACS, and have limited
tolerance for any screen editor I have yet seen.
A) all I have experienced know far too much about what I
"want" to do (words, lines, etc. are too fully built
in) Quick, what does your screen editor call a "word"?
B) the mouse-type input ones use too many hand motions - I
touch type my TECO commands; why should I have to slow
down?
C) the control-meta-shift ones make me use many fingers at
once. I don't like that either. Also, the more obscure
the character, the less likely it will survive (1) my
memory (2) the system deciding it wants that character
This is merely to say that I think editor design is in the
dark ages, and EMACS ain't God.
Back to Ivanciw's scenario:
Does he envision a page printer, etc., for that item in the
file cabinet? My file cabinets are full of brochures from
manufacturers which arrived by U.S. Snail. Do we encode
them with a TV camera? I have had much difficulty trying to
digest any message longer than about 25 lines via any screen.
The present Workstation message blizzard gets imaged out on
a Calcomp (nee Gould) 200 dot-per-inch plotter in "micro"
form (280-character columns per page) so I can sit down and
quit craning my neck at the screen.)
Anyway, my point is: the workstation seems great if all I/O
is within the electronic environment, but falls down when
you get things like hard paper involved. I hope I provoke
a little controversy.
geoff steckel
Subject: Re: Tools for personal workstations
∂06-Jul-81 0402 Daniel L. Weinreb <dlw at MIT-AI> Re: Tools for personal workstations
Date: 5 July 1981 19:42-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: lwa.INP at MIT-MULTICS
cc: WORKS at MIT-AI
Actually, quite a few users of Multics Emacs (in particular)
do learn to write extensions. Multics Emacs has an extension
language that is particularly easy to learn and start using,
and it is well-documented. Secretaries do this as well as
computer programmers (secretaries are often underrated; there
is a wide range of people doing secretarial things out there,
and some of them are pretty damned smart people). You'd be
surprised.
However, there will always be a lot of users who don't want
to learn to "program". I think the key to making programming
painless is to use programming-by-example systems. Emacs
keyboard macros are a start in this direction, although they
are too simple-minded to do the job adequately at all. Dan
Halbert's Master's degree work at U. C. Berkeley is a
particularly good example of a prototype of such a system.
I hope more people work on this in the future.
Subject: Re: capability machines
∂06-Jul-81 0434 Chris Ryland <RYLAND at SRI-KL> Re: capability machines
Date: 5 Jul 1981 1619-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: HGBaker.Symbolics at MIT-MULTICS, works at MIT-AI
In-Reply-To: Your message of 3-Jul-81 1415-PDT
Sorry, Henry, but a capability is NOT just a fancy name for a
pointer in a machine that doesn't have enough address space
to begin with. I was referring to capabilities in their full
encapsulation sense, such that you can only manipulate an object
if you have the rights to do so (encoded in the capability)
and you can only do it by invoking an appropriate entry in the
capability's type module. (This is only suggestive; particular
implementations differ, of course.)
No, some capability machines do garbage collection. Hydra did.
Lisp is not a capability machine. Lisp is just a low-level
language for a symbolic-object machine, and thus is attractive
to hackers, because they can grovel with arbitrary "addresses"
when they please (CADDADR, for example.) Of course, no one in
their right mind would use Lisp that way today.
/Chris
-------
Subject: Re: Spatial design for a workstation
∂08-Jul-81 0144 Mike Leavitt <LEAVITT at USC-ISI> Re: Spatial design for a workstation
Date: 7 Jul 1981 1902-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: cfh at CCA-UNIX
Cc: Rivanciw.DHQ at UDEL, works at AI
Message-ID: <[USC-ISI] 7-Jul-81 19:02:46.LEAVITT>
In-Reply-To: Your message of 6 Jul 1981 13:06:26-EDT
If there is a real problem with people preferring to type a few
characters than to scroll a screen (or move a mouse?) then is
one solution a more sensitive touch-screen device than is now
easily available? I guess I would prefer pointing to a
particular icon to any of the above.
Mike
Subject: Contexts as Icons
∂08-Jul-81 0204 Lawrence Butcher at CMU-10A (X335LB50) Contexts as Icons
Date: 7 July 1981 2219-EDT (Tuesday)
From: Lawrence Butcher at CMU-10A (X335LB50)
To: works at mit-ai
CC: Gene Ball at CMU-10A
Message-Id: <07Jul81 221925 LB50@CMU-10A>
"I am sitting at my Personal Computer (terminal) in the middle of
some work and something different comes up. I get confused."
The solutions to this problem range from having lots of windows
on the screen to having little paper airplanes which are shot from
user to user to transmit phone numbers.
The Star lets the user name available services by pointing to Icons.
Pointing to an Icon generates new more detailed Icons, or causes some
Icon-dependent action to happen, or causes a window to appear thru which
the user can interact with the named service. The collection of Icons
and windows are the context within which a user does work.
When a person services an interrupt, he would like to bundle up his
previous context and stick it somewhere. When the interruption is taken
care of, the old context is returned to. It is not reasonable for a
user to have to smash all of his present windows up to the upper left
side of the display to make room to work on his new context. It is equally
unreasonable for a user to have massive piles of overlayed windows.
A much better solution than windows would be a formal context manager
which allows you to group Icons, windows, and related running programs
into little "context" objects. These could be manipulated just like
mail, files, and windows containing command interpreters. One could use
the Context Manager Icon to gain access to and to manipulate lists
of contexts.
In order to be useful these Contexts should be able to contain any
object namable by the user. This should include Icons, instances of
running programs, and should also include the user's organization of
these objects onto his display. A Context should also be able to
include other Contexts.
Users commonly work on a single project for longer than a single
day. To make this possible, Contexts must outlive terminal sessions.
They must be portable between communicating machines. The user should
be able to move down the hall and have his work follow him. The
Context should be available the next morning, even after orderly system
shutdown.
Does anyone have any experience with a system like this??
Subject: Multiple Levels of State
∂08-Jul-81 0219 Vaughan Pratt <CSD.PRATT at SU-SCORE> Multiple Levels of State
Date: 5 Jul 1981 1145-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
5-Jul-81 11:07:14-PDT,1438;000000000001
Mail-from: ARPANET site MIT-ML rcvd at 5-Jul-81 1106-PDT
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Automation works yet another miracle. Lotsa luck.
-------
Subject: Re: Switching tasks and context
∂08-Jul-81 0232 Nowicki at PARC-MAXC Re: Switching tasks and context
Date: 6 Jul 1981 10:32 PDT
From: Nowicki at PARC-MAXC
In-reply-to: JWALKER's message of Wednesday, 1 July 1981 11:52-EDT
To: JWALKER at BBNA
cc: WorkS at AI
I can't help describing a Multi-window terminal program I wrote last year at
Stanford (with the help of Vaughan Pratt and Jeff Mogul). My reasoning was
that although "integrated systems" with menus and standard user interfaces were
desired in the long run, we needed a short-term tool to help develop such
systems. My program runs on the SUN workstation, which provides RasterOPs
on an 800x1024 bit screen at roughly the speed of 16 pixels/microsecond, and
computing power about 1/4 of a VAX-11/780.
The program has one simple function: an aribtrary number of virtual terminals
are displayed in arbirary windows on the screen. Each of these virtual terminals
may be to any machine on the local ethernet, or on the Arpanet (via a
gateway). Characters the user types get sent to the "current" host, (except for
one escape character used to enter commands), and characters sent from the
remote hosts get printed in the corresponding virtual terminal. When something
more urgent comes up, you just create another window (which can partially or
fully overlay the other windows), and when you're done you destroy that
window. At any time you may select any window to be "current", so there is no
LIFO restriction.
The important thing is that such a tool WORKS, and I find incredibly useful.
The virtual terminal uses ANSI standard escape sequences, so we can use all the
tools that have been around for a long time (like the SAIL Display Service,
Emacs under TOPS-20 or Unix, etc.) with NO modifications. We are planning to
use this to develop a more integrated system, but it is nice to have the power of
all that useful but obsolete software out there.
-- Bill
Subject: not putting phone messages into electronic mail files
∂08-Jul-81 0247 Paul A. Karger <PAK at MIT-MC> not putting phone messages into electronic mail files
Date: 7 July 1981 18:44-EDT
From: Paul A. Karger <PAK at MIT-MC>
To: WorkS at MIT-AI
cc: PAK at MIT-MC
I must disagree. Putting phone messages for people in the same office
into the computer is extremely useful. My secretary mails mine to me,
so that I can review them either from home that evening or from
another site connected to the network.
This in turn raises a question. If I have an elegant work station at
the office with graphics and icons, etc., how do I read my electronic
mail from home on a cheap, slow terminal (probably 300 baud at best)?
Do I have to learn a whole different command language? Computerese
instead of pointing devices?
Subject: Re: A Quibble or two
∂08-Jul-81 0306 Joe.Newcomer at CMU-10A Re: A Quibble or two
Date: 7 July 1981 1218-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Frank J. Wancho's message of 6 Jul 81 09:37-EST
I see nothing unreasonable about entering something in the computer "for
someone in the same office"; I don't see that spatial proximity should
require using an alternate method of notification, assuming that the
mechanism is already satisfactory. If using little pieces of paper is
more effective than using the computer, this indicates that something
is very wrong in the design of the software. Either the software is
good enough to replace paper, which is presumably the intent, or somebody
blew the design. Thus, we have a very good way of determining if the
designers built a system tailored to human needs, or one which is simply
intended as an ego trip for the designer.
I still don't understand why people seem to think "rings" or "stacks" or
other complex connected graphs are remotely reasonable for representing
past context. The top of my desk has no little strings connecting all the
things I'm doing, and I don't miss them; if I have to deal with such a
mechanism on my computer, then somebody who wrote the software doesn't
understand how people do work. See above predicate test.
A more serious problem is, given massive amounts of state, how do you
preserve them over a system crash? In the case of distributed systems,
it is even harder, since the state may be embodied in many (potentially
unreliable) separate machines. In the best of all possible worlds, when
my personal workstation rolls in the door, I turn it on. If I turn it
off, the result of turning it back on should be to put me back in the state
I was in when I turned it off. Likewise for system crashes. If some server
somewhere crashes, this should be of no interest to me, even if I'm using
it; when it comes back, my work continues just where it left off. None of
this is easy, and some of it is probably impossible, but I think it is
important enough that we should be concerned about reliability at a level
above parity and disk scavengers.
joe
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0340 JWALKER at BBNA Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 0939-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
In-Reply-To: Your message of 7 July 1981 18:44-EDT
The answer to "how do I read my electronic mail from home..."?
I have heard PARC aficionados say "Well, you WON'T work at home.
You'll be so much more productive during the day that you can
leave your work behind when you walk out the door." This position
does not constitute an answer to the problem. It is imperative
that we consider all modes of work in designing the next generation
of working environments. More people will start to work at home --
surely we have all heard predictions of electronic piece work and
cottage industry. More people travelling on business will be
carrying tiny terminals with them.
The question is serious. People have to think about how to subset
both the hardware and the software so that the essential style of
the interaction can remain. Of course someone working away from
their normal desk is somewhat handicapped now, but with good
planning (taking the right papers and materials with you) you can
write more on a plane than you can at your desk in the same
elapsed time. Workers whose desks are electronic shouldn't be
prevented in principle from having analogous benefits.
Jan
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0358 Deutsch at PARC-MAXC Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 09:39 PDT
From: Deutsch at PARC-MAXC
In-reply-to: PAK's message of 7 July 1981 18:44-EDT
To: Paul A. Karger <PAK at MIT-MC>
cc: WorkS at MIT-AI
I have developed, and hope to publish soon, a detailed proposal
for a protocol between bitmap workstations and mainframes. The
protocol is probably not suitable for a 300 baud connection, but
1200 might be quite reasonable. What it demands on the terminal
end is something of approximately the computing power of the
present home micros -- it needs to be able to do RasterOp, some
simple memory allocation, and sequential communications. It
needs quite a lot of memory for the bitmap(s), but memory is
getting cheaper fast. It is designed for exactly the present
kind of workstation -- bitmap display, keyboard, mouse or
similar pointing device.
Such a protocol is, of course, not sufficient to let you read
your mail elegantly at home. What it requires is a system
(hardware and software) architecture in which the mainframe
is decoupled from the display. Fortunately this is a very
reasonable architecture even for the present generation of
workstations like the Star. If the display component and the
mainframe component are located close together, the bandwidth
between them will not significantly degrade responsiveness
compared to the present more tightly integrated architecture.
Subject: speaking of touch panels...
∂09-Jul-81 0419 Hal at MIT-MC speaking of touch panels...
Date: 8 JUL 1981 0755-EDT
From: Hal at MIT-MC
To: WorkS at MIT-AI
Does anyone know of touch panel technology that is good enough so
that one could use it instead of mice? One would need to be able
to pick out a region the size of a character. I've heard rumors
of systems that allow one to resolve at less than a fingertip's
size, but have never seen one in operation. In general, what do
people think about the use of mice vs. touch panels vs. whatever?
Subject: Re: Spatial design for a workstation
∂09-Jul-81 0427 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 8 Jul 1981 17:17:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: LEAVITT at USC-ISI
Cc: Rivanciw.DHQ at UDEL, works at AI
In response to your message of Tue Jul 7 22:02:18 1981:
The problem with spatial data organizations is that they are
really a class of menus, with the attendant problem that you
can not display every possible choice on the screen at once.
You can deal with this either by enlarging the data surface
(so that the user must move his window over it) or by creating
a hierarchy of spaces.
In either case an expert user will find that it takes more
time to locate a particular command than to type its name.
>From my own brief experience, I think that programmers would
find a spatial layout most useful for organizing short-lived
objects, like contexts. The feature that programmers using
our system like best was the ability to create a number of
such contexts and move among them - like having several
terminals in your office.
Subject: Context Managers
∂09-Jul-81 0446 SHG at MIT-AI Context Managers
Date: 8 JUL 1981 1339-EDT
From: SHG at MIT-AI
To: WorkS at MIT-AI
It was recently suggested (by Lawrence Butcher@cmu10-a) that
in order to manage a "desk" full of icon's what we need is a
global context/icon manager that understands how to organize
the icons on a desk. Several people have suggested that one
needs a hierachical, all-knowing, state preserving "assistant"
in order to provide uniform access, continuity across
interrupted sessions, and conformity across different users
of the same desk.
It probably is my background in workstations (implementing
Smalltalk-80, a very distributed control machine) but
I have viewed the concept of a global organizer and
continuity/conformity enforcer as a mistake.
I see workstation developers and end-users developing zoo
of different types of icons. (The reason I say zoo is that
I see each icon behaving as an anthropomorphic instance of
a real-world tool). Thus secretaries, financial analysts,
accountants, managers and stockbrokers are going to run off
and create icons that behave like rolloindexes, memo-pads,
stock tickers, file cabinets, bookshelves, steno-pads,
calculators, and waste baskets (one can even imagine someone
implementing the anthropomorphic method for hunting through
a waste basket, or even janitors who pick up the trash daily).
Users will create this zoo of icons because they are familiar
with how the real-world devices work, and because the human
race has spent many years perfecting their functions.
I do not see any reason to pre-constrain the system by having
a predefined global conformity rule about an icon's functions
and a global conformity manager who uses that rule to organize
icons.
I have no strong empirical data to back up these opinions, thus
I am quite curious as to what the WorkS community thinks about
this subject.
- Steven Gutfreund
ps: I am assuming a currently implementable workstation. I assume
that the AI community is still far away from an intelligent
assistant that can gracefully learn from a naive user how to
manipulate office equipment and then train temporary workers
on how to use someone's "desk". Since I am not up-to-date on
current research, I could certainly be wrong here.
Subject: Re: Re: Tools for personal workstations
∂09-Jul-81 0509 lwa at mit-csr at mit-multics Re: Re: Tools for personal workstations
Date: 6 Jul 1981 1050-EDT (Monday)
From: lwa at mit-csr at mit-multics
Reply-to: lwa.INP@MIT-Multics
In-reply-to: Your message of 5 July 1981 19:42-EDT
To: dlw at MIT-AI
CC: WorkS at MIT-AI
Interesting. I'd like to see more information on these "programming-by-
example" systems, as I feel that the issue of user extensibility is not
being adequately addressed in present-day designs for office automation
systems.
-Larry Allen
-------
Subject: Re: Contexts as Icons
∂09-Jul-81 0525 obrien at RAND-UNIX Re: Contexts as Icons
Date: Wednesday, 8 Jul 1981 10:34-PDT
To: Lawrence Butcher at CMU-10A (X335LB50)
Cc: works at MIT-AI, Gene Ball at CMU-10A
In-reply-to: Your message of 7 July 1981 2219-EDT (Tuesday).
<07Jul81 221925 LB50@CMU-10A>
From: obrien at RAND-UNIX
I hadn't really thought about this before, but the PLATO
computer-based education system does exactly this - it saves
state between terminal sessions. It does this only for students,
though, not for "authors" (programmers). I hadn't thought of it
before because PLATO is so strange that I really don't think of
it in terms of other computer systems.
State-saving works but can't be done blindly. It turns out
that almost all real applications ("lessons") require the author
to do his own state-saving so that the student doesn't come up
with no context, but is instead presented with a higher-level
frame that tells him where he was and presents some options.
Only blind drill-and-practice stuff can use full state-saving
at all usefully, and sometimes not even then.
Subject: Unfinished tasks, intra-office mail, and system death
∂09-Jul-81 0550 Brian P. Lloyd <LLOYD at MIT-AI> Unfinished tasks, intra-office mail, and system death
Date: 8 July 1981 07:19-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
An interesting point was made about the necessity of being able to
conveniently hand-off a task to another person. Certainly it would
be simple to just dump the task's parameters from RAM to disk and
restore them again elsewhere. While technically feasable (I have
done that on my CT system to provide task interruption capability),
this is tantamount to scooping up the mess on your desk and dumping
it on someone else's. In any case the user is probably going to
reorganize it somewhat in order to make a smooth transition. Given
this, I don't think that special capabilities need to be created
to meet this "need" (I know that those of you using large central
machines may have dificulty with my technique depending on system
architechture).
As far as intra-office mail for phone messages is concerned, I am all
for it. I dislike being told that "there has been a phone message
waiting at the operators desk for you for several hours. Why don't
you ever pick up your messages ..." especially since I have been
waiting for the call and I happened to be away from my desk for two
minutes when it came. Paper doesn't hack it here.
There are some tasks that are very painful if you lose your work
because of system death and others that are unimportant. If I
have been editing a document for hours and I lose it all because
of a system crash, I am going to be VERY annoyed. On the other
hand, if I am reading my mail and the system goes down, it will
not be very painful for me to recover from that situation. We
are going to have to do serious study as to which tasks can be
recovered easily.
Convergent has come up with what I believe is a unique method of
protecting a user from a crash during an editing session. All
user keystrokes and the original document are maintained through
an editing session. If the system dies or I wish to go back in
time in my editing session, I can do a replay and watch the system
duplicate my editing session in short order. This is an interesting
approach and I have found it to be VERY useful (like the time someone
pulled my plug when I was four hours into an editing session ... ).
Brian
Subject: Re: A Quibble or two
∂09-Jul-81 0616 Deutsch at PARC-MAXC Re: A Quibble or two
Date: 8 Jul 1981 09:44 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Joe.Newcomer's message of 7 July 1981 1218-EDT (Tuesday)
To: Joe.Newcomer at CMU-10A
cc: works at mit-ai
Reliable preservation of large amounts of state in the face of
hardware failures is a topic which has been explored extensively
in the data base world. (This is a nice example to support my
contention that the present tendency of computer science to fragment
into subspecialties is to be deplored.) Generally speaking, the way
to overcome the problem is ALWAYS redundancy. The forms of redundancy
that we have explored the most are (1) thinking of the workstation as
a cache for "truth" embodied on a remote file server, or (2) logging
important state changes on a server so that the workstation state can
be reconstructed (possibly slowly) if a crash occurs. A more exotic
architecture involving multiple copies and voting is explored in a
soon-to-appear thesis by Dave Gifford (MIT). The bottom line is that
the technology is available, if manufacturers and software houses
choose to offer it.
Subject: Reliability
∂09-Jul-81 0643 Joe.Newcomer at CMU-10A Reliability
Date: 8 July 1981 1348-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Deutsch@PARC-MAXC's message of 8 Jul 81 11:44-EST
I have contended for several years that I don't need better languages,
compilers, or editors NEARLY as much as I need a database management
system. Alas, the conventional DBMS is oriented to social security
records. I once mentioned "well, you put all that on a database"
to someone and they immediately began to explain how they had
variable-length text which a database system "couldn't handle".
Of course, a large class of uninteresting systems think in terms of
fixed-length records, but what we lose by ignoring them is that they
solve a whole lot of other problems. I once worked in the "real
world" on a banking system, and it is a good way to learn to be
paranoid about hardware and software. When you start playing with
millions of dollars of real bucks, and find that people audit their
checking accounts (and even interest on savings) to the nearest penny,
AND your company has posted a mongo amount of dollars in bond to back
up their promise that they WON'T screw up, you find that redundancy is
a way of life. DBMS systems have all had to deal with this class of
problems; the fact that their image of the data is prehistoric does
not invalidate the other solutions.
From a personal workstation viewpoint, the problem is to implement
the redundancy of state at a very low cost. If my machine crashes,
I want to boot it and get the display looking just like it did
before the crash, having lost perhaps a few small edits, or the
mail message I was composing (if it was shorter than some low
threshold) or possibly the window I just the instant before had
brought up. Doing this cheaply requires ingenuity.
joe
Subject: Re: JWalker comments on working at home, on planes, etc.
∂13-Jul-81 0920 Zellich at OFFICE-3 (Rich Zellich) Re: JWalker comments on working at home, on planes, etc.
Date: 9 Jul 1981 1036-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: WorkS at MIT-AI
Some of us already *do* work at home, and the receipt of stuff
that shows up in my office inbasket is a problem -- I have to
go in and get it periodically, or else have it batch-mailed to
me (the Post Awful actually does pretty good work here - I get
everything the next day).
At home I have a pretty nice workstation, but on a recent
vacation trip I took a TI745 with me, and found it not nearly
as useful as it had been when it was my *only* terminal. My
work methodology has changed so much due to the availability
of the workstation that it has become almost impossible to
get my work done with a terminal with lesser capabilities.
My electronic "filing cabinets", etc., are optimally organized
for a windowed display, and have become extremely difficult to
use from a TTY or simple scope.
It so happens that my workstation is relatively dumb (using
its internal microprocessor to handle NVT requirements only),
but the next generation should be quite intelligent - maybe
being my prime "host" itself. This all points up two problems
very neatly:
1. I need a portable workstation (or portable terminal that
can access my workstation);
2. If I use a portable terminal, then I need access to my
home workstation (the future one, that will be a
standalone system). This future system must be capable
of two-way communication; it can *not* be used strictly
to dial out to other hosts. It has to be a full host
in that it must be accessible from a remote user, and
probably from remote hosts and other workstations as
well. (gee, sounds like I just read RFC 782)
-Rich
-------
Subject: Working at home
∂13-Jul-81 0920 Joe.Newcomer at CMU-10A Working at home
Date: 9 July 1981 1447-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: JWALKER at BBNA
CC: works at mit-ai
In-Reply-To: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
Huh? "I'll leave my work behind when I go out the door?"
I've never heard such bullshit. First of all, it makes
the rather bizarre assumption that I even want to come IN
the door. Actually, I would much rather work at home. This
means such serious issues as how to get reasonable communication
bandwidth between my processor and the rest of its network is a
very serious problem. And it also seems to be predicated on the
strange (and patently false, in my case) assumption that one WANTS
to leave the machine behind. I ENJOY what I'm doing, and want to
be able to do it equally well from home or "work". Thus the goal,
for example, of giving every CMU researcher a personal machine is
not really satisfactory; I need two, or at least a display with a
high-bandwidth (say, 10MHz) connection to the "real" machine.
Perhaps in that strange world where people turn their minds off
when they leave the office this is a reasonable attitude, but I've
never yet met a professional in any area who was capable of doing
this. And if you DON'T make the facilities available at home, you
are defeating the purpose of having personal workstations: to make
individuals more productive. I don't think it is the domain of
office automation designers to dictate when and where one has
automation available. Assume it needs to be available 24 hours
a day, 7 days a week, at home and "at work", THEN figure out what
the problems are.
I have this from direct experience. When I had a 1200 baud
C-100 in the office and a 1200 baud C100 at home, I could work
interchangeably in either location. When I got 9600 baud in
the office, I worked less at home. Now that I have a Perq in
the office, I can't work at home at all. This is a real drag.
I see absolutely no philosophical reason to not provide equal
computing facilities at home and at work. The only limitations
are technical (like bandwidth) and financial (most companies
can't afford two $30K workstations per user). So "office"
automation designers should go after those problems, and quit
making such totally wedged statements that seem to reflect a
basic misunderstanding of what a "personal workstation" really
should be!
joe
Subject: Office of Tomorrow, where is it?
∂13-Jul-81 0921 DREIFU at WHARTON-10 (Henry Dreifus) Office of Tomorrow, where is it?
Date: 12 Jul 1981 (Sunday) 1955-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-ML
Workstations of Tomorrow, the office of tomorrow. [Part-I]
A general feeling by most consultants, including myself, is that
the office of the future will be distributed geographically. Not
only will the 'traveling' type person be a long-distance link, but
projects will be connected by different branches - communicating
electronically.
As this effects the workstation, indeed a traveling companion
will be developed. Something akin to the Xerox "NoteTaker".
Working from home will also be a common and practical extension.
Workstation hardware will have to provide the geographic service
at some point in the not too distant future.
Somewhat more extensive from Telex/TWX 'Datagram' service, an
electronic 'Terminal in the Hotel' will at some point be provided.
I don't see any major technological problems in that. Most people
I have spoken to say they would pay $ 25.00 or even $ 50.00 more
a night to have a computer screen and a dial up modem at their
disposal.
Flying on an airplane? Why not? First Class, Business Class,
Electronics Class and Coach. Electronics class, with SONY(tm)
TypeCorders, floppy disks, and even telephone capabilities for
burst communications to one's favorite computer. It beats the
lousy movies they are showing these days.
Henry Dreifus
[Subj: Bravo/Hypertext]
∂12-Jul-81 1803 John Howard Palevich <TANG at MIT-AI>
Date: 9 July 1981 09:02-EDT
From: John Howard Palevich <TANG at MIT-AI>
To: WORKS at MIT-AI
The Bravo (& BravoX) secretary-type editors on the PARC
Altos have the "save every keystroke and the original file so
that we can always reconstruct" hack. When the system starts
to reconstruct it puts a cute "Your Editor is Experiencing
Temporary Difficulties, Please Standy By" message on the
screen, much in the style of the message TV stations read
out over the air after they drop the camera on the floor.
What ever happened to Ted(tm) Nelson's Hypertext system,
where the entire state of the document (down to the time between
keystrokes of the person editing in) was saved, and the viewer
of the document had the option of expanding the footnotes into
the referenced texts, and all that sort of thing? I think that
he was even addressing the problems of copyright & royalty
payments. . . perhaps I should mail this to human-nets, instead.
Subject: Workstation Reliability and Redundancy
∂12-Jul-81 1724 rmc at CCA-UNIX (Mark Chilenskas) Workstation Reliability and Redundancy
Date: 9 Jul 1981 14:23:18-EDT
From: rmc at CCA-UNIX (Mark Chilenskas)
To: WorkS at mit-ai
It sounds as if your problem is similiar to (and can use)
distributed database technology. The icons can be viewed as
tuples in a relation (of work to be performed, status of work,
worker, what have you). Some icons would be provided by the
system in a common format, others would be customized by each
user, probably using some menu driven options package although
for "sophisticated" users I suppose full programming might be in-
volved. The basic idea would be to have all nameable items
stored away on disk with their requisite status information.
This would preserve state info over crashes of the individual
workstations, but does not solve the problem of going to a new
workstation if your desk dies for a day or two.
In a distributed data base it has long been theorized that redun-
dant data will provide better reliability over crashes, machine
outages, etc. and provide some (possibly limited) data to the
user even if their home system is currently unavailable. Of
course this is a pain, because you have to work up protocols to
insure that the data items all stay consistent with each other
and use up lots of overhead timestamping messages or locking and
unlocking at foreign sites to update data and it is still all
very, very SLOW! The fact that Ethernet has a higher data
transmission rate than the ARPAnet and that the updates may have
simple enough formats to use coding schemes will help. But i
suspect that this will still eat an unacceptable amount of com-
pute power at task initialization and termination. Update trans-
actions are where redundancy hurts most.
Distributed databases are only partly understood. One problem is
in deciding how to split up the data. An obvious technique would
be to store templates for all common icons at each
workstation/site and let each user pick which other sites he is
likely to use occasionally. Unfortunately this will mostly mean
the user will be too brash (i don't need backup) or too cautious
(store it everywhere! Why do i run 10X slower than everyone
else?). And what do you do when the database crashes? What info
is right, and what is out of date (especially if a locking rather
than timestamp protocol is used)? This is not to mention network
partitions...
It still seems like a good application of the technology. The
redundant data goes a long way toward assuring you the type of
reliability you want. Using a common database would allow one
mechanism for transfering tasks/icons from one desk to another.
The networks will be reasonably fast. Workstations are getting
more compute power. And slowly we begin to understand some of
the design and recovery problems. There is some NICE research to
be done here...
R Mark Chilenskas
Subject: Automated desk
∂12-Jul-81 1803 wilson at CCA-UNIX (Gerald Wilson) Automated desk
Date: 9 Jul 1981 12:38:27-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: csvax.works at Berkeley
The problem of keeping track of what quickly becomes a
multidimensional space is one we faced in the extensions of
Negroponte's work in our SDMS and VIEW systems. For SDMS we
approached it by providing two kinds of "world maps". The first
is simply a synopsis of the contents of the current work space.
Thus if you are doing several related things in this single space
(eg. building different portions of a large program), you can
always find from the world view (shown on a separate screen at
all times) where the other portions reside. The second type of
world map is a side view of all of the work spaces arranged into
a tree ( or network ). This shows a box with a label for each
work space, lines showing the connections between work spaces,
and a highlight for the work space where you currently reside.
The user can switch between world maps at the push of a function
button.
This is only a partial solution to the problem, as it does not
capture any of the real semantics of the situation. For example
you do not know how you got to the current work space, or any of
the contextual information associated with the current instance
of the work space. These are issues that we are currently
addressing in VIEW, but I have no fabulous insights to report
yet.
Subject: Re: Context Managers
∂12-Jul-81 1803 Joe.Newcomer at CMU-10A Re: Context Managers
Date: 9 July 1981 1501-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: SHG at MIT-AI
CC: works at mit-ai
In-Reply-To: SHG@MIT-AI's message of 8 Jul 81 12:39-EST
I guess I never thought of the icons as being pictures or
illustrations, but just names of windows (perhaps visible
corners of windows). Thus having a global manager in a
workstation that keeps track of all the windows seems
natural. What is your reaction to this simpler model?
joe
Subject: Icons
∂12-Jul-81 1804 Brian P. Lloyd <LLOYD at MIT-AI> Icons
Date: 9 July 1981 08:31-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Currently we catagorize workstation functions on the basis of
the existing tools we now use. Is it not possible for us to
define a new set of functions that encompasses the current
range of tools/procedures, but is much smaller? Given this,
we will have to develop a new set of icons to define the new
functions. If indeed we must define new icons, don't we lose
the existing mental correlation between picture and function?
Perhaps we should look at the whole problem from another angle.
Let us assume that the "intelligent desk" leads us in the
direction of modified worker activity. I think we should do
another system analysis and see if we can come up with a new
view of the problem: one that has an elegant [simple] solution.
Brian
Subject: Re: Reliability
∂12-Jul-81 1724 Joe.Newcomer at CMU-10A Re: Reliability
Date: 9 July 1981 1831-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: kolling at PARC-MAXC, works at mit-ai
In-Reply-To: kolling@PARC-MAXC's message of 9 Jul 81 16:21-EST
Assume the following:
A series of transactions is required to generate a consistent
database.
The cost of repeating a transaction is outrageously high.
The cost of restarting a series is even higher.
The cost of saving state at the client so that the series may
be continued is negligible.
What is the cost of the mechanism that guarantees that enough
state is preserved at the server to continue the series of
transactions given that either the server or the client may
crash?
Assume that the client, when resuming the series, may elect
to "continue" or "abort". Assume that "abort" is a truly
rare occurrence.
This is my image of the requirements of, say, a crashproof
editor that will lose no more than one keystroke if either the
client or server crashes. Note that although the "database"
(file being edited) is in an inconsistent state (relative to the
desired state), the user wishes to resume editing at the nth or
n-1st keystroke. Thus, viewing the user as the "client" and the
editor as the "server", the cost to the user of remembering which
keystroke came last or will come next is negligible. As we move
further back in time, the cost of restarting the series becomes
higher and higher. Assume for values of time > 10 keystrokes
the cost is nearly infinite. As far as I can tell, transactions
do not allow state to be SUSPENDED; they only guarantee that
under one definition of consistency, the state will always be
consistent. For a workstation, the two states in question are
the state of the workstation and the state of the work. Any
time the workstation state is consistent, the state may be
saved (the transaction completed), but this has nothing to
do with the state of the work. I think we are a long way
from being able to deal with the latter, since I think it
is perfectly reasonable to shut down the system or take a
crash when the "work" is inconsistent, as long as we can
return to the same state of inconsistency upon return and
allow the work to proceed.
joe
Subject: Touchpanels
∂14-Jul-81 0934 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels
Date: 13 Jul 1981 0939-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
To: WorkS at MIT-AI
Why do all the answers in the digested replies on touchpanels share
these glaring misconceptions?
- that a touchpanel must be mounted in front of the display;
- that a touchpanel's resolution is limited to fingertip size.
1. Any of several touchpanel technologies, including the Elographics
and Sierracin commercial units, is entirely suitable for use away
from the display surface -- say, just where you would put a
"tablet" (pen-on-a-wire type), but without ever having to find &
pick up a pen or even find the mouse where you left it. The desk
area used need not be larger than a mouse-field.
2. This same touchpanel technology, at least, offers resolution that
is much much finer than the size of the touching fingertip -- I
have personally built and used some, and with cursor feedback I
can select individual pixel positions *within* the (projected)
area of my contact "fingerprint". This is done simply and
naturally (noone has to be coached) by rolling the fingertip.
The resistive material reads out the centroid (in some sense)
of the contact patch, allowing very sensitive control for fine
positioning, as well as instantaneous pointing without having
to find the pointer (pen or mouse) first.
*Of course* there is a tracking cursor on the display, just like a
mouse/tablet. To assume absence of this well-understood software
device gives extremely unfair comparisons.
Now that we all have that straight, how about some reconsidered
answers? Preferably this time from users of real touchpanels,
not those low-resolution or screen-mounted special-purpose
devices that were blasted (rightly) in the recent batch of
replies.
Steve
Subject: Re: Touchpanels
∂15-Jul-81 0429 JWALKER at BBNA Re: Touchpanels
Date: 14 Jul 1981 0926-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: SAUNDERS at USC-ISIB
Cc: WorkS at AI
Message-ID: <[BBNA]14-Jul-81 09:26:52.JWALKER>
In-Reply-To: Your message of 13 Jul 1981 0939-PDT
You might have noticed that some of the touch panel notes pointed
out the semantic poverty of a touch when compared to the multiple
selection buttons on a mouse. That difference holds wherever the
touch panel is mounted. It means that touch panel driven systems
have to use more menus than are needed with a mouse driven
interface.
Jan
∂15-Jul-81 0444 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanel prejudice
Date: 14 Jul 1981 0839-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanel prejudice
To: JWALKER at BBNA
cc: Saunders at USC-ISIB, WorkS at MIT-AI
Again, random assumptions are being made. Who says you can't
mount buttons where they can be used easily with a touchpanel?
Specifically, you can take advantage of the normal use --
pointing with one hand while the other remains in "home position"
at the keyboard -- to provide either mouse or touchpanel with
lots of "buttons" (just 'cause they have letters printed on top
doesn't mean they aren't buttons!). Of course, the kinesthetics
aren't exactly alike; but the assertion implied by JWalker that
mouse is necessarily better on this ground is pure assumption.
If there's evidence, tell us about it!
I didn't say there was no DIFFERENCE, just that the touchpanel's
inferiority as being asserted on unfair (scientifically careless)
grounds, that touchpanels were being castigated for faults they
don't in fact have. They are indeed different, and the good and
bad points of that difference need to be carefully explored
without the interference of preconceived conclusions.
Steve
-------
∂15-Jul-81 0458 Joe.Newcomer at CMU-10A Re: Touchpanels
Date: 14 July 1981 1253-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Re: Touchpanels
CC: works at mit-ai
In-Reply-To: Steve Saunders's message of 13 Jul 81 11:39-EST
Steve,
I was assuming by touchpanels that people mean those transparent
devices, or LED-matrix arrays, that get mounted on terminal
screens. I therefore don't see any distinction between the Bit
Pad One with a piece of hardware for the cursor and the Three
Rivers touch-tablet which requires only my fingertip (except I
don't have four buttons on the touch-tablet). The fine point
that touch tablets need not be mounted on the screen did not
escape me...in fact, I even cite the 3RCC touch tablet in an
earlier note.
joe
∂15-Jul-81 0515 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels vs Tablets
Date: 14 Jul 1981 1014-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanels vs Tablets
To: Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI
In-Reply-To: Your message of 14-Jul-81 0953-PDT
Joe,
There is one real distinction between BitPad et al. and
sensitive-surface touchpanels, and that is the need or absence of
a gadget (pen, e.g.) that one must find and pick up (or take a
hand position on) before pointing/drawing. Is it your experience
that this is not important? I get *terribly* annoyed by the pen
on our Perq (which came with a Summagraphics tablet, not the
transparent touchpanel -- I don't know why). I think that a pen
on a cord is much worse than a mouse; what I don't know is whether
finding a mouse every time is worth having those buttons there
rather than (say) near the left hand. Have you experimented
with fully-worked-out setups that use each of the competing
technologies to its own best advantage? I really would like
to hear some information on this.
Steve
∂15-Jul-81 0533 Joe.Newcomer at CMU-10A Re: Collected commentary on touchpanels
Date: 14 July 1981 1235-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
Subject: Re: Collected commentary on touchpanels
In-Reply-To: "The Moderator"'s message of 13 Jul 81 07:30-EST
What's wrong with light pens? The same thing that is wrong
with the standard pen that comes with the Summagraphics Bit Pad
One: you've got to pick the damn thing up! I went nearly crazy
trying to use an editor for two weeks with my Bit Pad, because
the editor ONLY accepted cursor motion thru the tablet and the
ONLY device I had for pointing was the pen! One of the worst-
designed systems I ever used. After two weeks, the 4-button
mouse came in, and most of the headaches went away, but I still
had to keep taking my hands off the keyboard for the smallest
cursor motions. Now we have an EMACS like editor that accepts
cursor movement and positioning commands from the keyboard or
tablet, and it is really nice; small relative motions can be
done quickly from the keyboard and large dragging motions can
be done with the tablet; I find the system quite friendly.
(As an aside, pens seem to be predicated on the idea that holding
a writing implement is a "natural" action and comfortable. I've
never found holding a pen comfortable, and have always preferred
to type rather than write. I write almost nothing; if it is
worth commiting to an medium outside my brain, I type it into
the computer!)
joe
∂15-Jul-81 0551 Marshall Presser <MPresser at MIT-Multics> touch panels
Date: 14 July 1981 1331-edt
From: Marshall Presser <MPresser at MIT-Multics>
Subject: touch panels
To: WorkS @ MIT-AI
The touch panels I have seen had very fine precision, but very
high variability. As a reult, the software running the terminal
had to know what was being displayed where, so as to interpret
seemingly misplaced results. We tried cross wires held together
by rubber bands on the first model, but this gave us only the
roughly 20 by 20 points on a standard sized monitor. It is
unclear whether many people can or care to manipulate in a n
area smaller than a fingertip.
Others tried special resistive and capacitance sensitive
material, but this proved too variable. They, whoever they
are, tried invisable conductors inside channels on a plastic
overlay on the monitor, but this technology proved expensive
and the stuff wore down after a while.
What did prove successful was a two monitor system, one for
display purposes, and another as the "input" device. There
was of course, the problem that the programmers could not
eat peanut butter and jelly sandwiches while working late,
for it marred the surface badly. An image of a keyboard was
generated, but the touch was so awful, that a small keyboard
of the regular variety was hung on when large amounts of text
input were required. One application had people selecting
theater tickets by push down on the monitor over a picture
of seating plan of the theater or stadium. The main appli-
cations for such a terminal were commerical, for highly
reprogrammable banking terminals, and for computer access
to naive users about community information. In the second
case, they were to be used at public libraries, community
centers, etc.
∂15-Jul-81 0607 Joe.Newcomer at CMU-10A Re: joysticks
Date: 14 July 1981 1249-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Gary Feldman at CMU-10A
Subject: Re: joysticks
CC: works at mit-ai
In-Reply-To: <13Jul81 205424 GF20@CMU-10A>
The reason joysticks are losers deals with the interaction
between the hand motion and the screen cursor motion. In
fact, it takes a lot of skill to convert a desired motion
on the screen to an appropriate nudge of the joystick. Thus,
joysticks usually result in a lot of "hunting" as the cursor
constantly overshoots the target and the user applies smaller
and smaller corrections to get it to land on the desired point
on the screen. See Stu Card's thesis; I know he presented the
reasons at his oral (I was there) and assume they are also in
his thesis.
I have no experience with tracking balls, and am currently
reluctant to offer opinions on them since I THINK I know a
very, very cute way to implement one...and I won't say more
until I've sold the idea.
joe
Subject: Picture vs. Window names
∂15-Jul-81 0633 wilson at CCA-UNIX (Gerald Wilson) Picture vs. Window names
Date: 13 Jul 1981 13:50:10-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: works at MIT-AI
I think that the importance of worrying about the content of the
windows is closely tied to the nature of the working environment.
If the user is working with a relatively small number of windows
all of which have a fairly short half-life (probably no more than
a day), then having a nice window manager which just keeps track
by name is probably adequate, and certainly much better than
typical current facilities. I equate this solution to the ability
to declare multiple full-screen windows in EMACS, and then ask
about what windows you have created. This works nicely for me as
long as I chose good names for the windows, and I don't 'drift' on
to new things without closing out old windows.
The problem that is of primary concern to me is the environment
where a user has lots (probably hundreds over the course of a
year) of windows, many of which have long lives (> month), and
which are in various states of activity at any given moment.
When I handle this manually I often end up with a hierarchy of
storage and state preserving methods, with the "manager" being
a combination of paper and electronic messages and a mental
index. I find all the same problems that have been discussed
or alluded to in "works" messages:
* Windows change in priority and/or importance based on both
my own actions and actions of others. The biggest problem
seems to be that the actions of others can cause me to make
dramatic changes in my window organization, at least for a
short time.
* I can handle a handful of windows with little problem for a
moderate time. When the number grows I begin to lose track
of some. When the time period of a low priority window's
life is long, I also begin to lose track of it. This
corresponds to the usual observations about human memory.
* Almost invariably there are multiple relationships between
windows, and thus multiple organizations of the windows. A
single window name rarely means anything to more than one
of these views of my world. The key retrieval method is my
mental association between the window name and the semantic
aspects of the window that are of interest under given
circumstances.
* The window relationships depend upon not only the window
semantics, but also project priorities, personal preferences,
interests of the moment, machine availability, dependencies
upon co-workers, etc. Much of this meta-information about
the window organization is important to keep available, and
is used in developing priorities and schedules.
* When new windows are created I must thread them into the
existing structures, and also determine if any new structures
are required. The deletion of old windows may affect windows
not directly linked to the deleted window, as the reason for
the deletion may have implications for other windows not
otherwise related.
My conclusion is that if we are to use computers to maintain much
of our current paper files, we must provide windowing facilities
that are more versatile, more semantically oriented, and more
easily interconnected than the window naming and other similar
approaches would allow. I think that the use pictures, color,
shape, abstractions, sound, etc. are essential to this process.
They sure seem to help in manual systems, and I have not found
effective substitutes for many of them in my own limited work.
When talking with graphics people, they always use "icon" to mean
the 'total symbol', not just as the name of a region of the screen.
Although this does not imply that icon refers to any semantics, I
guess I have felt that this is a natural extension of the grahics
term.
[Subj: more on icons]
∂15-Jul-81 0700 ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
Date: 13 Jul 1981 20:54:16-PDT
From: ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
To: WorkS at MIT-AI
Phooey! This "endless hierarchy" of deletes is just plain silly!
Given delete and EXPUNGE, what if someone wants a file that has
been EXPUNGED? Should there be a little "Hardy Boys" icon which
given the burned junk from an "expunged wastebasket" icon could
re-construct (perhaps only in part) what was on the burnt paper
(the expunged file)?
And how about a little "paper shredder" icon so you could prevent
the retrieval of an EXPUNGED file? And if you didn't want to
trust your users to do that, you could always have a "bogus paper
shredder" icon which doesn't really shred things, but merely drops
them in the wastebasket.
On the other hand, with regular backups, and an "archives" icon,
perhaps you could simply trust your users most of the time, and
recover from backup when that failed (perhaps a "god from the
machine" icon could be shown disgorging the "lost" files).
Subject: Re: Unfinished tasks, intra-office mail, and system death
∂15-Jul-81 0714 Ted Markowitz <TJM at MIT-XX> Re: Unfinished tasks, intra-office mail, and system death
Date: 14 Jul 1981 1700-EDT
From: Ted Markowitz <TJM at MIT-XX>
To: LLOYD at MIT-AI, WORKS at MIT-AI
In-Reply-To: Your message of 8-Jul-81 0719-EDT
Perhaps with the price of harware dropping at the rate it has
been, the TANDEM approach (duplicate processors, disk subsystems
which "mirror" the data, etc.) might be a reasonable method to
accomplish state saving. I don't see this right away, but it
does provide another avenue to make sure that your desk doesn't
wind up 'disappearing' because of an electrical spike or a loose
cable.
--ted
Subject: Reliablity
∂15-Jul-81 0729 BHYDE at BBNG Reliablity
Date: 13 Jul 1981 1120-EDT
From: BHYDE at BBNG
Sender: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]13-Jul-81 11:20:13.BHYDE>
Folks,
There are very few new ideas that computing has had to date.
The keystroke backup file is only the editor instantiation of
a very old idea; double entry bookkeeping. An idea that some
have blamed all capitalism on. As each transaction occurs in
any organization it is recorded in two places, the journal and
the account book that it is related to. These two sets of books
are stored in separate places if at all possible and either set
can be used to reconstruct the other. This is a very important
reliability mechanism since it is the only one that is acceptable
to accounting organizations. As the only "certified" mechanism
it is the only primitive available for most commercial systems
to achieve reliability. Thus the terms audit trail or journaling
are very popular in commercial product offerings.
Ben Hyde.
Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
∂31-Jul-81 0755 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Announcements - ANSI Standards Comm. & NCC82 Call for Papers
Date: 31 July 1981 06:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
WorkS Announcements
----------------------------------------------------------------------
Date: 29 July 1981 01:31-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: X3V1 comm. for ANSI Standards in the area of Office Systems
There are four working groups:
1. User interface requirements
2. Terms and functions for office systems
3. Distribution of information (e.g., message interchange format)
4. Text communications (e.g., page image format)
They welcome new members. West coast people are especially invited
to participate. Meetings are held in Washington, DC.
For further information, contact:
L. M. Collins, Chairman
X3V1 IBM Corp
2300 One Main Place
19th Floor
Dallas, TX 75250
------------------------------
Date: 28 July 1981 17:59 edt
From: Frankston at MIT-Multics (Bob Frankston)
Subject: NCC 1982 Personal Computer Sessions -- Call for papers etc.
The 1982 National Computer Conference will have a track (i.e.,
a group of sessions) on personal computers. This means that
the papers will be refereed and appear in the proceedings.
This is in contrast to past years in which there was a
separate, unrefereed "subconference".
This reflects the growth and importance of personal computers.
But it is also a challenge. We must organize a new set of
sessions and get new referees. Part of this challenge is in
finding a balance between sessions on the mature areas in
personal computing and capturing the innovation in ongoing
research and development, both in academic and commercial
projects. Workshops might provide a better forum for the
latter.
Some of the possible topics include:
- what are personal computers -- the definitions range
from Alan Kay's dynabook, to miniature mainframes to
workstations.
- what personal computers are not.
- specific applications and issues such as wordprocessing
(though word processing also falls under office automation)
- Protocols and standards
- Networking as it relates to personal computers. This
can represent both local area networks as well as ad
hoc telco networks.
- Operating systems -- both traditional and new concepts
- Languages
- Consumer computers -- issues in design, implications of
a software marketplace.
- Education -- traditional and otherwise, computer and
noncomputer
- Implications and relationships to other fields both
within the industry and in the rest of the world.
Societal interactionals.
- Hardware trends and issues
- Games, both recreational and educational.
I am on the NCC steering committee and am in charge of
organizing/creating these sessions. If you have any
suggestions or comments, and if your are interested in
participating by writing a paper, refereeing or whatever,
please contact me either as:
nccpc82.SoftArts at MIT-Multics
or
Bob Frankston
Software Arts, Inc
PO Box 527
Cambridge, MA 02139
or 617-491-2100.
------------------------------
End of Announcements
********************
Subject: SUN Workstation
∂15-Jul-81 0747 Andy Bechtolsheim <AVB at SU-AI> SUN Workstation
Date: 13 Jul 1981 1738-PDT
From: Andy Bechtolsheim <AVB at SU-AI>
To: WorkS at MIT-AI
From: Minsky at MIT-AI
Subject: SUN query
Gee, where does one get a SUN and how much does it cost?
--------------------------------------------------------
SUN Workstation Synopsis:
Processor: 8 MHz 68000, executing without wait states.
Memory Management: two-level, multi-process, segment-page memory map.
Main Memory: 384 kBytes (128 kBytes reserved for frame buffer).
Graphics: 1024 by 800 pixel display, high-speed "RasterOP".
Network: 3 MBit/sec "experimental" Ethernet.
Pointing Device: optical "mouse".
Backplane Bus: Intel Multibus.
Operating System: Microsoft Xenix.
OEM-Price: under $10,000.
We are currently evaluating manufacturing arrangements for
SUN workstations. Stanford University plans to get 25 SUN
workstations by the end of this year. If you are interested
in participating in this pilot production run, please contact
AVB @ SAIL.
Subject: Collected Responses on Touchpanels II
∂16-Jul-81 0524 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Touchpanels II
Date: 16 July 1981 0700-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Here is the second set of collected responses on touchpanels
and other cursor moving devices. They are being distributed
in this form rather than as individual messages, because this
is the only way that we can manage to promptly distribute the
incoming volume of mail to this list.
Enjoy,
RDD
------------------------------
Date: 15 July 1981 08:54-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: BitPad Experiences
To: WORKS at MIT-AI
We at DEC did not have mouse hardware on hand. What we did
have was a SummaGraphics BitPad with crosshair cursor that has
4 buttons (bugs in the PARC terminology) on top. It was fairly
easy to write software so that we could have a relative postion
mouse instead of an absolute location cursor. We even hyped
up the sensitivity of the mouse so that simple (wrist only)
movements could carry one across the entire screen. One can
even lift up the cursor and replace it like a real mouse.
Opinions:
Given the way the smalltalk window editors work, I can keep
almost all of my activity off the keyboard. Indeed I think
if I was given a chord keyboard in my other hand (5 buttons
could give me 120 different keys) then I could completely
get rid of that anachronism of the industrial age: the 4
row QWERTY keyboard.
- Steven Gutfreund
------------------------------
Date: 15 Jul 1981 1032-PDT
From: Michael Dolbec <CSD.DOLBEC at SU-SCORE>
Subject: Re: Touchpanels vs Tablets
To: SAUNDERS at USC-ISIB, Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI, CSD.DOLBEC at SU-SCORE
In-Reply-To: Your message of 14-Jul-81 1014-PDT
The Alto set up has a mouse with 3 buttons ("bugs") for the
right hand, and a 5 key device for the left to play with.
There are text editors in Smalltalk that allow the mouse to
be used primarily as a pointing device while the key-set is
used to select actions and modes. So you see, devices exist
to keep the other hand busy also. I believe that Englebart
at SRI used a key set too. --Mike
------------------------------
Date: 15 Jul 1981 10:18:56-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Saunders at isib
Subject: touch sensitive digitizers
Cc: WorkS at mit-ai
While using a touch sensitive digitizer (tsd) on a table
top wins in that you don't need to find a special stylus
with its clumsy wire, it suffers from the fact that other
objects, such as the palm of your hand, can set it off as
well. I heard that Elographics has a tablet that works
only with sharp objects. Has anyone had any experience
with it?
I am very wary of any comparisons made from theoretical
perspectives. In the long run, the most successful
input technique, whether tsd, tablet, or mouse, will
depend on which one "feels good" and works reliably.
As you pointed out, this depends a lot on how the
software is implemented.
------------------------------
Date: 15 Jul 1981 0843-EDT
From: WMACGREGOR at BBNA
Subject: Pointing Devices
To: works at MIT-AI
I agree with Steve Saunders position that touch panels
may not be as inferior as commonly assumed. Certainly mice
have their advantages, but they have problems too. Because
the machine cannot determine the absolute position of a
mouse, it is awkward, at best, to use as a digitizing device.
Tablets are much better, since a stylus can be traced over a
graph or map placed on the tablet.
Even though mice do not require dedicated desk space in
theory, I have seen many users place a plastic sheet on the
desk (some kind of heavy vinyl with a tacky-feeling surface)
to give the mouse good traction. If you're going this far,
there is little advantage over a BitPad-type tablet.
Joysticks seem to be dismissed out of hand, and on the
whole I agree. However, one variant of the joystick, the
'force stick', I suspect is comparable to a touch panel or
mouse if properly engineered. (A force stick remains in
one place, and produces an output proportional to the forces
exerted on it in the X and Y directions; they are usually
elastically mounted, so that they bend slightly, maybe 1/8"
maximum, when force is applied).
- Bill
------------------------------
Date: 15 Jul 1981 1304-PDT
From: Park at SRI-AI
Subject: PWS cursor control
To: works at MIT-AI
Suggestions for New Kinds of Cursor Controllers
by
Bill Park
SRI International
One of the recent developments in robotics is a thin, flat sensor
that can measure force distributions normal to its surface as well
as shear forces. It might make a very convenient, rugged, reliable
fingertip cursor control.
These devices can be fabricated as array sensors with resolutions
on the order of a millimeter. They are intended for use as tactile
sensors to be installed as "fingertips" on robot hands, e.g., to
adjust gripping forces to prevent slippage. People at M.I.T.'s
Artificial Intelligence Laboratory, among others, are building
and experimenting with them.
They are typically made by embedding layers of parallel flexible
metal conductors in a matrix of silicon rubber that has been doped
with granules of an electrically conductive material such as carbon
or silver. Local conductance of the material is then a function of
local stress. A microprocessor measures the resistance between
selected pairs of conductors to determine the stress distributions
throughout the material.
You could mount one of these sensors flush with the top surface
of the keyboard housing, and use it somewhat like a trackball as
follows:
(1) Whenever the operator touched it with a finger, the micro-
computer would determine the centroid of the distribution of
pressure exerted. (Using the centroid might overcome the
objection to high resolution in a touch-sensitive device to
be operated by a "fat finger.") The location of this centroid
would determine a corresponding coarse location on the screen
at which a cursor would appear. Rolling the finger slightly
or sliding it over the surface would allow fine adjustment of
the cursor position. This is a small-muscle task which I
believe would be easy to learn and to perform rapidly.
(2) Pressing harder on the surface could signal a special action
to perform at that point, such as placing a marker on the
screen or changing the mode of operation. Using modes (1)
and (2) alternatively, one could quickly place a sequence of
markers around a block of text or a polygonal region of an
image.
(3) Pushing the finger along the surface (producing a shear
stress signal) could then indicate a corresponding vector
in the plane of the screen. This could be used, for example,
to control cursor velocity or to move a previously delineated
region of the image around on the screen.
I think it might be most convenient to mount such a control on
the keyboard within easy reach of either thumb, such as on the
front edge of the housing below the space bar. One would then
not have to move one's hands at all to point at things on the
screen.
A much cruder device is available commercially. It is a linear
array of parallel electrical conductors. Stroking it produces a
bipolar analog signal. It is marketed as, e.g., a more rugged,
completely sealed replacement for a knob on a piece of military
electronic gear. Two of these could be mounted at right angles
to one another within reach of a thumb to control incremental
horizontal and vertical cursor motion.
Another possibility for minimizing hand motion would be to
incorporate a miniature 2- or 3-degree-of-freedom joystick
into the keyboard, in the form of one more, special, key.
Or even several such "joykeys."
------------------------------
Date: Thursday, 16 July 1981 03:28-EDT
From: Jonathan Alan Solomon <JSOL at RUTGERS>
To: Steve Saunders <SAUNDERS at USC-ISIB>
Cc: JSol at RUTGERS, JWALKER at BBNA, WorkS at MIT-AI
Subject: Touchpanel prejudice
Touch Panels! Touch Panels! Indeed. Give me the greatest touch
panel known to man, the Terminal Keyboard. Some of them even
come detachable.
Seriously, since the primary appeal for workstations will be to
users who already have some aptitude on computers, there should
probably be some correlation between touch panels and terminals.
(here I envision my briefcase-thin terminal with the touch panel
screen which doubles as a keyboard).
Jsol
------------------------------
End of Collected Responses on Touchpanels II
********************************************
Subject: Re: Picture vs. Window names
∂16-Jul-81 0604 Chris Ryland <RYLAND at SRI-KL> Re: Picture vs. Window names
Date: 15 Jul 1981 0911-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: works at MIT-AI
In-Reply-To: Your message of 13-Jul-81 1050-PDT
I recommend heartily that everyone stop wondering about window/session
managers until they read the four PIE papers now available from PARC,
by Ira Goldstein and Danny Bobrow. PIE provides most of the mechanics
for exactly the kinds of things people are meandering verbally around.
I'm referring to report CSL-81-3 from Xerox PARC. Also related, though
possibly not available yet, is CSL-81-4, ``PIE: An Experimental
Personal Information Environment.''
Subject: pukcba ekortsyek
∂16-Jul-81 0620 Frankston.SoftArts at MIT-Multics pukcba ekortsyek
Date: 15 July 1981 20:40 edt
From: Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: works at MIT-AI
*from: BOB (Bob Frankston)
Local: works at mit-ai
There are many naive ideas for backup that work in limited
contexts. The assumption of keystroke backup is that the
keystrokes are the only information needed. That might be true
in simple system. It is not true when one is interacting with
a more general environment. For example, inserting files from
a hierarchy using names relative to the current environment.
Or reading mail, or waiting for timeouts.
Subject: Making paper go away
∂16-Jul-81 0704 Joe.Newcomer at CMU-10A Making paper go away
Date: 14 July 1981 1211-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: gaines@RAND-UNIX's message of 12 Jul 81 18:14-EST
You've fallen into the same trap that most people do. If what you
want is the ability to scan quickly thru a document, this suggests
that a capability the computer should have is to scan quickly thru a
document. If you want to make notes, the computer should provide the
ability to make notes. If you want to doodle in color, the computer
should provide the ability to doodle in color. What you've stated is
not reasons for retaining paper, but a specification of what
capabilities we need in a computer if we want paper to go away.
Now current technology makes a lot of this extremely difficult. For
example, at very slow data rates (say, 9600, which is as close to DC
as one would care to get), it is unreasonable to browse thru most
large documents. With 24-line screens, finding enough context to
make sense of what has been typed is nearly impossible. But saying
that online retrieval will never replace paper is silly; it means
you've failed to adapt the computer to what people need.
The observation that it is useful to print things out on paper so
they don't have to be stored online is likewise looking at the
problem from the wrong side. What I want is a method of taking silly
pieces of paper and getting them onto the machine so I don't need to
store the paper! Fact: secondary storage is cheap, is getting
cheaper, and even primitive archiving techniques make it look even
cheaper. Why should I have to do something (file a piece of paper)
that the computer can do more effectively?
I keep all my source listings in hardcopy form. Why? Because it is
faster to look something up on hardcopy than online. Why? because a
24x80, 9600 baud terminal is too small and too slow to accomodate me.
If I had four or five 60-line screens with a typical effective
bandwidth (including disk latency, etc.) of about 100Kbaud, I
wouldn't need to print anything. One way of achieving this is to use
multiple windows, but it is not the only way (another is to have four
or five 60-line terminals).
If paper is more effective, then there is a mismatch between the
needs of the person and the software. I don't see anything which has
yet made that statement even suspect. What we need to do is explore
how to eliminate that mismatch.
joe
Subject: Programming by example
∂16-Jul-81 1052 Halbert at PARC-MAXC Programming by example
Date: 13 Jul 1981 10:35 PDT
From: Halbert at PARC-MAXC
To: WorkS@mit-ai
Here is a short description of programming by example. I
have gotten requests from a LARGE number of WorkS subscribers
requesting it.
------------------------------
Since a few people have mentioned programming by example and
the work I've done on it specifically, I will try to give a
brief outline of what it is, and what I've done:
At its simplest, programming by example is just recording a
sequence of commands to a system, so that the sequence can
be played back at a later time, to do the same or a similar
task. The sequence forms a program. The user tells the
system, "Remember what I am doing". The system executes
the user's commands normally, but also remembers them.
The user has created a program by giving an example what he
wants the program to do. However, the statements in his
program are the same as the normal system commands. The
user does not have to learn some programming language with
its attendant syntax and semantics; instead he can do his
programming -in the user interface- of the system, which he
already has to know anyway in order to operate the system.
In addition, he has written the program by performing,
concretely, an example of what the program is supposed to
do. Since he can easily verify whether he did his example
correctly, he can be fairly confident his program will work.
He does not have to understand his program abstractly.
Naturally, straight line programs without parameters are not
very interesting. Once the user has written a program he
may want to -generalize- it. He may want to print file Y,
instead of the file X he used in his example. So the system
has to provide a way for him to to change the constants in
his programs to variables, and specify how these variables
are to be bound (e.g. by prompting the user, by looking for
similar data, etc.)
The user may also want to insert conditional or looping
constructs into his program. There are various ways, which
I will not go into here, of inserting these constructs into
programs using programming-by-example techniques.
I would emphasize that this kind of programming by example
does not use inductive inference techniques used in AI,
in which the user does several examples, and the system
inductively determines what has changed from example to
example (e.g. 1+2, 5+2, hmm, first operand must be a
variable; or a[1], a[2], a[3], hmm, looks like a loop
stepping through the array).
The seminal work in programming by example was done by Dave
Smith of Xerox in his Stanford Ph.D. Thesis. Gael Curry
did similar work in which the examples given by the user
could contain abstract as well as concrete data values.
Certain industrial robots can be programmed by example by
guiding them through the task they are to perform. Here
at Xerox, I have added programming by example to a prototype
of Star. The system provides program generalization and
an iteration mechanism as well as simple command recording.
I have written up this work and my ideas on programming by
example so far in a Master's project report done for U.C.
Berkeley. I intend to continue and extend this work into a
Ph.D. thesis.
References:
Daniel C. Halbert. An Example of Programming by Example.
Master's project report, University of California, Berkeley,
and internal report, Xerox Corporation, Office Products
Division, Palo Alto, CA.
David C. Smith. Pygmalion: A Computer Program to Model and
Stimulate Creative Thought. Ph.D. thesis, Stanford University,
1975 and Birkhauser Verlag, 1977.
Gael A. Curry. Programming by Abstract Demonstration. Ph.D.
thesis, University of Washington, Seattle. Technical Report
No. 78-03-02. March, 1978.
Henry Lieberman and Carl Hewitt. A Session with Tinker:
Interleaving Program Testing with Program Writing.
Conference Record of the 1980 LISP Conference, Stanford
University, August, 1980. [describes a programming by
example system for Lisp]
Michael A. Bauer. Programming By Examples. Artificial
Intelligence 12: 1-12 (May 1979). [describes inductive
inference techniques].
Copies of my report are available on request.
Dan Halbert
Xerox Corporation
Office Products Division
3450 Hillview Avenue
Palo Alto, California
or
Halbert@PARC-MAXC (preferred)
(or csvax.halbert@Berkeley)
--Dan
-----
Subject: Re: Reliablity
∂16-Jul-81 1634 Bernie Cosell <cosell at BBN-UNIX> Re: Reliablity
Date: 15 Jul 1981 13:50:10 EDT (Wednesday)
From: Bernie Cosell <cosell at BBN-UNIX>
In-Reply-to: Your message of 13 Jul 1981 11:20 EDT
To: BHYDE at BBNG
Cc: Works at MIT-AI
I agree with Ben that the `real' accounting fellows really did figure
it mostly out (several hundred years ago!), with Journalizing and
autid trails and the like. I would like to make a tiny correction:
if I remember correctly from some accounting courses I took, double
entry bookkeeping has nothing really to do with the `journal' aspect:
the double entry name comes from the fact that both debits and credits
are simultaneously maintained and every financial transaction is fully
entered on both sides. Thus, at any moment, you can check a set of
books for a simple addition error by simply totaling up all of the
accounts and the balance should always be zero. (I think that this
is called taking a trial balance).
/Bernie
Subject: PIE reports from PARC
∂16-Jul-81 1811 Chris Ryland <RYLAND at SRI-KL> PIE reports from PARC
Date: 16 Jul 1981 1446-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: WorkS at MIT-AI
Since I've gotten quite a few requests for the PIE reports
I referenced, I'm forwarding the official requesting address
and the report identifiers:
CSL-81-3, Goldstein & Bobrow "An experimental description
based program environment - four reports" and
CSL-81-5 Goldstein & Bobrow "A layered approach to software
design" are available by sending a message to Jenkins@PARC
with your address.
Subject: Quickie poll
∂16-Jul-81 1825 Lloyd at MIT-AI Quickie poll
Date: 15 July 1981 2220-EDT
From: Lloyd at MIT-AI
To: WorkS at MIT-AI
How many people on this list are ACTIVELY hacking a personal
workstation in hopes of creating a real live 'office automation'
or 'executive information' system? I feel fairly certain that
the PARC folk are but how 'bout the rest of you?
Brian
P.S. It's OK to swamp my mailbox this time. I will pass the
results of my poll on if anyone is really interested.
B
Subject: Re: Making paper go away
∂16-Jul-81 1841 Zellich at OFFICE-3 (Rich Zellich) Re: Making paper go away
Date: 16 Jul 1981 0936-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: Joe.Newcomer at CMU-10A, works at MIT-AI
cc: ZELLICH
In response to the message sent 14 July 1981 1211-EDT (Tuesday)
from Joe.Newcomer@CMU-10A
Well, there is already a way to scan quickly through files:
it's called structured (or hierarchical, or whatever) files
a la Engelbart's NLS (now called Augment) and (Ted Nelson's ?)
Hypertext.
You can look at one or more levels, and independently one or
more lines of those levels, and open up or close up the part
on your screen to see more or less. It makes it very fast
to see what is in a document you've never seen before, or
to find something specific in an old document when you don't
know it's exact location. You may even be able to "address"
desired text by context. Combined with a windowing capability,
a pointing mouse, and auxiliary 5-key keyset, this gives an
extremely powerful tool - now if only it came packaged in a
briefcase-sized personal DEC-10...
Structured files are great, but do have an interface problem
because the rest of the world uses "flat" files - it's not
always easy to translate between the two - especially if there
is highly-formatted text like columnated tables, or "drawings"
(dot-and-dash boxes, etc.). Of course, the interface with the
rest of the world is a problem when using *any* advanced system
- I might have a little trouble putting a Star icon in a netmail
message, too.
-Rich
-------
Subject: Re: Making paper go away
∂16-Jul-81 1902 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 16 July 1981 1400-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Zellich@OFFICE-3's message of 16 Jul 81 11:35-EST
One of the main problems in dealing with structured files is that
most operating systems give you "the files" and "the user space"
and you're on your own to figure out what to do with the files.
In Hydra, it was possible to define the text string transformation
of a file as part of the "subfile" type description. No matter
how peculiar the internal representation of the file might be,
the interface it provided to the outside world was a sequential
"flat" file suitable as input to a compiler or lister. Of course,
there were other interfaces which were presented; internally, the
editor for that file type was powerful enough to manipulate the
full representation. One could also have a "display" interface
by which illustrations were made visible on a CRT, or a "printer"
interface by which the file was presented in a form suitable for
printing (e.g., a Press file format would have been possible).
This is necessarily a simplified view, and we didn't begin to
explore all the problems, but the really important idea is that
at the basic interface, an ordinary program could NOT get at the
bits of the file. Only the bits presented by the file interface.
This abstraction is critical in protecting users from file repre-
sentations, and I consider any file system which does not support
at least this form abstraction to now be hopelessly behind the
state of the art.
I hope to do some more research in this area in the next few
years. The Hydra idea may NOT be the best, or even close to
right, but it is a whole lot better than any conventional file
system.
(In Unix, it is possible to use pipes to provide the transfor-
mation; a filter converts a complex file to a sequential byte
stream. Alas, Unix does not provide the protection necessary
to keep any random program from trashing the file by THINKING
it is a sequential byte stream file. Nonetheless, their heart
is in the right place. This is one of the reasons I think
pipes are a winning concept).
(The message based operating system for Spice, called Accent,
makes it possible to build systems with this style of
interaction).
joe
Subject: Making paper go away
∂16-Jul-81 1928 Vaughan Pratt <CSD.PRATT at SU-SCORE> Making paper go away
Date: 16 Jul 1981 1445-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
If paper is more effective, then there is a mismatch
between the needs of the person and the software.
Joe's implication that any mismatch between people and computers
needs to be eliminated is similar to the attitude that gave rise
to the BART fiasco. This zeal to automate everything is misplaced.
Some products already do their job quite well. Paper, for example.
One thing I particularly like about paper is that I can leave
it on the beach while I'm swimming without being too concerned
that someone is likely to walk off with it. Is anyone willing to
predict which century will see portable computers able to compete
with paper as an improbable target of petty thieves?
A more appropriate attitude would be to keep an eye open for
opportunities where the computer can outperform the traditional
product. I suspect this is what Joe really has in mind when
he talks about automating paper. Paper has its disadvantages
as well as its advantages. Pen-and-paper is a poor medium
for speed of text input (many of us type twice as fast as we
write, though presumably not Steven Gutfreund, who says he
prefers mice and chordsets to 4-row QWERTY keyboards). Paper
is inconvenient to transmit, with a delay measured in days
rather than minutes. It is difficult to search associatively.
It does not lend itself to alteration. Making duplicates for
redundancy (e.g. guarding against fire etc.) is awkward.
Text and graphics macros (Letraset, stencils, french curves,
rubber stamps, etc.) are relatively inflexible. Conversion
to machine readable form is much harder than the reverse
direction.
The moral is that while computers outperform paper in some
categories, it is wishful thinking to imagine that it will
also soon come to dominate in all the remaining categories.
Needless to say, the moral applies equally well to other
products besides paper, e.g. BART drivers.
Applying this to AI, I would prefer to characterize AI
not so much in terms of passing Turing's test as looking
for additional human activities that lend themselves to
automation.
Subject: Re: Office of Tomorrow, where is it?
∂16-Jul-81 1947 Joe.Newcomer at CMU-10A Re: Office of Tomorrow, where is it?
Date: 14 July 1981 1222-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: DREIFU at WHARTON-10 (Henry Dreifus)
CC: works at mit-ai
In-Reply-To: DREIFU@WHARTON-10's message of 12 Jul 81 18:55-EST
I suppose you've heard of the idea of putting 2GHz packet
transmission repeaters on every commercial aircraft? The idea
is that there is hardly a moment when there isn't at least one
aircraft over someplace in the U.S., so the number of times
you would find the global network unavailable to your pocket
terminal should be fairly small...and of course, if you are on
the airliner, you should be able to use the facility as well.
joe
∂16-Jul-81 2007 Chip Maguire <Maguire at UTAH-20> Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 1617-MDT
From: Chip Maguire <Maguire at UTAH-20>
Subject: Re: Office of Tomorrow, where is it?
To: DREIFU at WHARTON-10, works at MIT-ML
cc: Maguire at UTAH-20
In-Reply-To: Your message of 13-Jul-81 0745-MDT
Over two years ago I spoke with the North American VP of
a large European airline, he was looking toward terminals
in the airplanes for both passanger use and for airline
reservations/info (because of the high degree of being late
screwing up large numbers of passengers schedules - let the
passengers change their reservations while circling JFK or
when making that suprise landing at Moline). His company
was also thinking of utilizing TELETEXT for reservations
in cities offering this service.
Chip
-------
∂16-Jul-81 2023 JWALKER at BBNA Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 0934-EDT
Sender: JWALKER at BBNA
Subject: Re: Office of Tomorrow, where is it?
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA]13-Jul-81 09:34:24.JWALKER>
In-Reply-To: Your message of 12 Jul 1981 (Sunday) 1955-EDT
Why not on airplanes? Until the problems of electro-whatever
interference are more under control we won't be using terminals
on airplanes. As they explained on one flight I was on, the
kiddies couldn't use their electronic games because they
interfered with the plane's navigation equipment. So I think
it will be awhile before we beam communications out of the sky
to our home computers!
Subject: Icons and analogy
∂12-Jul-81 1804 BHYDE at BBNG Icons and analogy
Date: 10 Jul 1981 2252-EDT
Sender: BHYDE at BBNG
From: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]10-Jul-81 22:52:13.BHYDE>
It is not difficult to develop a sympathy for the
earlier comment that it seems sad to adopt as a primitive
of the automated office all of the curious mechanism of
the traditional paper mill. Three ring binders, electric
pencil sharpeners (where ones mouse regularly visits), to
calling cards.
There is a reason for this fundamental decision being so
popular in the community. I believe that I recognize in
this choice a pattern I first saw in the product lines of
the process control companies, product offerings always
mimic existing products. This seems to be a fundamental
truth of all marketing. If a product is completely new
then your customers will not be able to comprehend it,
they will not recognize it, it will be foreign, odd ball.
In the real time control community a very popular device is
the programmable controller, it replaces a relay controller,
its operation is specified with relay ladder diagrams. It
is implemented with a microprocessor, programmed on a video
terminal. The video terminal is often specially constructed
to be able to draw the ladder diagrams. I have heard sane
and successful providers of these devices talk of the new
model that includes as a standard component a speaker which
will generate the simulated noise of the relays clicking.
Once installed the plant foreman will never notice the
difference.
In creating a successful product one has to sell too many
groups of people, technical management, business management,
sales management, the sales men, and lastly the customers.
Each to these groups must be taught. Taught enough so that
they feel warm and comfortable about this new (and hence
suspect) product. If one can explain the product via analogy
then their rich body of experience ( hence trust ) with the
analogous situation can be used to leverage the short period
of time available to train them in.
What is this they cry! If you can't answer in one sentence
the sale is lost.
Ben Hyde
Subject: Redefining the art
∂13-Jul-81 0712 Brian P. Lloyd <LLOYD at MIT-AI> Redefining the art
Date: 12 July 1981 12:42-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Yes, there are significant marketing reasons for not changing
the state-of-the-art too rapidly. Fortunately we do not need
to concern ourselves with what the customer expects. Look
at Xerox-PARC and the Alto system: I don't think that they
concerned themselves with market acceptance when they first
designed the Alto. Their experiences have brought them to the
forefront of the personal workstation and office automation
marketplaces. Ok, I accept "Star" as the current SOTA. I now
want to know what lies beyond. On a day-to-day basis I have
to stifle my creative urges in order to satisfy the needs of
a marketing organization. In this forum I want to discuss
future concepts.
Brian
Subject: Re: Re: A Quibble or two
∂13-Jul-81 0810 gaines at RAND-UNIX Re: Re: A Quibble or two
Date: Sunday, 12 Jul 1981 16:14-PDT
To: Joe.Newcomer at CMU-10A
Cc: works at MIT-AI
In-reply-to: Your message of 7 July 1981 1218-EDT (Tuesday).
From: gaines at RAND-UNIX
.... If using little pieces of paper is more effective than
using the computer, this indicates that something is very
wrong in the design of the software. Either the software
is good enough to replace paper, which is presumably the
intent, or somebody blew the design.
This implicitly states the view that paper is going to go away.
I don't believe it. As computer use increases in offices, I
think that we can expect that the amount of paper shuffled
will substantially decrease. But paper has its own uses. It
is easier to scan rapidly through a large report (or a printed
collection of junk messages from the Arpanet) that to do the
same on-line. It is wonderful to be able to write or draw, in
colors, on a printed page, including on top of the writing. I
can often find interesting things in a file cabinet when I'm not
sure just where I filed it than I can find things filed on-line
when I am faced with the same degree of uncertainty. I expect
that the evolution of office work brought on by intensive use of
computer works stations will cause many changes which affect how
and when paper is used, but will not eliminate it.
Incidentally, the one thing really needed is a cheap way to
read in a computer-printed piece of paper, so I don't have to
maintain the corresponding text on-line. If we had really cheap
large capacity stores so that things could stay on-line forever,
then it would be nice to copy anything printed to a retreivable
place, with the identification automatically printed on the piece
of paper so that if I delete it from my files, I can retreive it
again when I next look at the piece of paper.
Overall, I think we need more progress on getting the paper
and computer worlds to mesh together nicely, in contrast to
the objective of getting rid of paper.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 0556 JWALKER at BBNA Re: Spatial design for a workstation
Date: 6 Jul 1981 2102-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 6-Jul-81 21:02:05.JWALKER>
In-Reply-To: Your message of 1 Jul 81 10:03:14-EDT (Wed)
My initial reaction to your scenario is that the idea of selecting
an operation is no different in essence from continuing a suspended
operation. E.G. selecting INBOX is exactly the same as continuing
a mail reader. The distinction is in being able to reinstate visual
context. This is an important distinction of course, being made
feasible by the new generation of hardware for displays.
One question though. This scenario description assumes that each thing
you can select has one "reason" for being selected. The INBOX being
selected means you are rummaging through it. Is this assumption likely
to hold? That is, will the reason for selecting something always be
unique or unambiguous enough that the right set of operations will
become available automatically?
Jan
∂07-Jul-81 0650 Zellich at OFFICE-3 (Rich Zellich) Re: Spatial design for a workstation
Date: 6 Jul 1981 1731-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Spatial design for a workstation
To: WorkS at MIT-AI
I currently use a system that keeps track of the previous infile locations,
the previous file(s), and the previous programs/tools. It is very
handy to be able to do this, but it *does* have some drawbacks. One is
that there is a finite number of such things that can be kept track of,
so occasionally you lose track of the nth-back thing (the computer does,
anyway - you may still remember it yourself); the other main drawback is
that sometimes you *don't* want to keep track of everything you just did.
You can't win, really. Either the system tries to keep track of *everything*
and makes it really confusing to go back through the ring structures after
being online for a couple of hours, or the user must issue an
explicit command to either "save" or to "don't save" when interrupting to
somewhere else.
-Rich Zellich
-------
∂07-Jul-81 0721 DPR at MIT-XX Spatial design for a workstation
Date: Monday, 6 July 1981 09:39-EDT
From: DPR at MIT-XX
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
Subject: Spatial design for a workstation
Congratulations. It seems that you have just discovered the paradigm
of the Xerox STAR and Negroponte's Spatial Data Management systems. More
likely you knew about them already. With a little improvement in
Xerox's software, this could be the substance of an ad for STAR!
THe problem, though, is the same as the one on my desk--it get cluttered
fast with incomplete tasks. If certain tasks have long time horizons,
and certain ones have short time horizons, the result is a mess. If the
priority is not correlated with time horizon (since in my case there is
always more to do than can be done, requiring that some things NEVER
get completed), then the pile gets deeper and deeper. So now I need
three dimensions, and a way to hand tasks off to others in a partially
completed state if it looks like I won't be able to finsih them.
How does my secretary extract stuff from my "automated desk" and finish
it when I'm out--or conversely, how do I or a temp deal with her "automated
desk" when she's sick?
David
∂07-Jul-81 0748 Deutsch at PARC-MAXC Re: Spatial design for a workstation
Date: 6 Jul 1981 07:53 PDT
From: Deutsch at PARC-MAXC
Subject: Re: Spatial design for a workstation
In-reply-to: Rivanciw.DHQ's message of 1 Jul 81 10:03:14-EDT (Wed)
To: Rivanciw.DHQ at UDel
cc: works at Mit-Ai
As I mentioned before, the concept you mention is exactly the one that has
evolved at Xerox over the last 10 years and is (I believe) incorporated in
the Star in a form very similar to the one you envision. Of course, your
scenario includes a good deal more "polish" than the Star in terms of the
system being more intelligent about the relative priorities, default
desires, etc. of the user.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 1035 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 6 Jul 1981 13:06:26-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
In response to your message of Sun Jul 5 14:23:05 1981:
We built a system here for ARPA which incorporates
some of the facilities you describe in your scenario.
The system consists of a number of intelligent (8080-based)
terminals hooked up at 9600 baud to a PDP-11/70 running
Unix. The screen provides a window into a data surface
which contains icons of various shapes. The outlines of
the icons are made up of standard printing characters.
The user can scroll the data surface by pressing an arrow
key (8 are provided to allow diagonal motion) or an
outboard joy stick.
The icons are user-defined and can correspond to any
program runnable under Unix. To run the program, the
user centers its icon on the screen and presses an
"activate" button. Typically, the program to be run
is the Ned (Rand ->BBN) display editor editing some file.
The user can return to the top level via either of two
buttons - "deactivate" or "detach". The "detach" button
suspends the program and causes the icon to blink. When
the user again activates that button, the screen is restored
to its previous state. I agree that it would have been
better to make "detach" the standard mode, but this was
not practical under Unix with the implementation approach
that we had chosen.
We haven't tried the system in an actual office environment.
Programmers found it cumbersome because there was always a
Unix command that didn't yet have an icon, and they already
knew most of the command names anyway. It usually took more
time to scroll to the icon than to type its name. People
always enjoy the demo however, and we are still looking for
a place to try it out.
Subject: Collected responses on terminal input devices
∂19-Jul-81 1612 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 19 July 1981 10:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
This collection of 9, relatively short messages continues the
WorkS discussion of interchangeable keyboards, touchpanels,
and other terminal input devices.
Enjoy,
RDD
------------------------------
Date: 17 July 1981 12:17-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: chordsets
To: csd.pratt at SU-SCORE
cc: WORKS at MIT-AI
Actually I don't know how I would feel after using a chordset
all day. What I am interested in is finding an alternative to
QWERTY input. There must be something with better ergonometrics
than a matrix of keys laid out to suit 18th century designers
of mechanical devices.
- Steven Gutfreund
------------------------------
Date: 18 July 1981 07:50-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Interchangeable keyboards
To: SHRAGE at WHARTON-10
cc: WORKS at MIT-AI
The Convergent Technologies system has the ability to change
the keyboard encoding and the font on the display. We have
experimented with AZERTY, Dvorak, and special purpose
keyboards. We have used the unencoded mode of the keyboard
to simulate a chord keyboard. The only thing we lacked was
a simple way to relabel the keys (do you have any concept of
how difficult it is to make 98 little self-adhesive labels
and stick them on your keyboard every time you make a change?).
I would be interested in the re-label-able keyboard if you get
more info.
Brian
------------------------------
Date: 18 Jul 1981 (Saturday) 1148-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: LCD interchangeable keycaps.
To: lloyd at MIT-AI, works at MIT-AI
Well, let's let our imaginations run wild for a moment. It might
be possible to construct a 50x50 (or even less could do it) LCD
display with individually addressable points. Since the time
that an LCD takes to fade is very long, a rather slow Z80 would
be able to keep up with the updating of 50 or 60 of these. The
problem is really in fabricating the LCD and in wiring the keys
since there would have to be all these wires to each key (LCD is
not XY addressable as far as I know). The trick is to minimize
wires to the key. Typically this is done by putting encoding
onboard (onkey). Then we would only need two or three wires to
each key. I would think that if someone set their mind to it the
technology exists to do this job right.
Here are two other alternative in case you don't happen to have
an LCD fabrication plant in your back yard:
(1) put LCD strips just above the separated rows of keys. The
problem here is that the separation of the keys could make
it rather difficult to type.
(2) Train people to type on totally blank keys by reading a
"keyboard icon" that is ALWAYS displayed at the bottom of
the screen. This is my favorite idea and I'll bet that it
is not hard to so train typists. Well, give it a try and
let me know what you discover.
-- Jeff
------------------------------
Date: 18 July 1981 23:17-EDT
From: Brian P. Lloyd <LLOYD at MIT-MC>
Subject: LCD interchangeable keycaps.
To: WORKS at MIT-MC, SHRAGE at WHARTON-10
CT has an interesting keyboard diagnostic along the lines you
proposed. The program displays a facsimile of the keyboard on
the screen, and echoes what you type by turning the corresponding
key reverse video. It even shows whether or not the LEDs on
the keys are lit. I see no reason that this display couldn't
be shrunk and placed in its own window at the bottom of the
screen.
Good idea you had!
Brian
------------------------------
Date: 16 Jul 1981 20:53:37-PDT
From: CSVAX.rob at Berkeley
Subject: Tablets, mice, etc.
There is a very nice tablet available from Kurta Corporation
(206 S. River Dr., Tempe, Arizona, 85281 (602)968-8709). It
comes with either a parallel or serial interface, so if you
choose you needn't decode 9600 baud ASCII (a major break-
through...). It's about 8"x11", and if you ask for the Bell
Labs cursor you'll get a 3-button cursor much like a mouse.
We have a couple here, and are pleased with them. People
using them mostly feel they prefer the tablet to a mouse.
Rob Pike (research!rob@berkeley i think. or (for sure) robt@mit-mc)
------------------------------
Date: 17 Jul 1981 18:44:25-PDT
From: decvax!duke!unc!smb at Berkeley
To: duke!decvax!ucbvax!WorkS@MIT-AI
Subject: touching mice
I'm not too crazy about any of the pointing systems I've seen
described here, because I don't like having to take my hands
off of the keyboard. Besides, menus tend to have too few
options (can you imagine a menu for the UNIX command set) and
they impede the user who knows what he/she wants to do next.
But there seem to be enough folk out there who LIKE to worship
icons, so.... an idea I've seen suggested for a pointing device
is a light pen that's worn as a thimble or attached to a ring.
One must still remove a hand from the keyboard, but at least
there's no need to grope for squirmy mice. This idea works
best, it would seem, in situations where there's a fairly
large amount of pure text work, as well as commands -- say,
a text editor.
--Steve Bellovin, UNC, Chapel Hill
------------------------------
Date: 16 July 1981 13:54 edt
From: MPresser.Multics at MIT-Multics
Subject: Tracking balls
To: WorkS at MIT-AI
In-Reply-To: Message of 15 July 1981 09:32 edt from Joe.Newcomer
I have used a reasonably good tracking ball on a system that
did the automatic recognition of human chromosomes. Every
so often, the system would get confused and not be able to
separate two chromosomes that were, or appeared to be touching.
The ball was used like a scissors to cut the surface, so that
two disconnected objects appeared. Our ball was homemade, and
the most circuitous of cuts to be made in next to no time.
The principle used was that of extreme gearing down, so that
very fine motions could be made. For these purposes, the
thing was very useful. I'm not sure how it would have worked
for menu manipulation. We used the terminal keyboard for that.
------------------------------
Date: 16 Jul 1981 0924-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Bill Park's message
To: WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 0400-PDT
Bill Park's message mentioned what I believe XEROX marketed as a
"cat" on the 850-series word processors: a small area which you
stroke to move the cursor. Since these systems were fixed-font
oriented, I don't know if these cats would be useful in a more
high-resolution environment.
------------------------------
Date: 18 Jul 1981 (Saturday) 1110-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Visionary terminals
To: minsky at MIT-AI, works at MIT-AI
If you sneeze does it blow all the icons off the screen?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: Bell Labs "writers workbench"
∂19-Jul-81 1613 mike at RAND-UNIX Bell Labs ''writers workbench''
Date: Saturday, 18 Jul 1981 12:43-PDT
From: mike at RAND-UNIX
To: works at MIT-ML
As has been mentioned, Bell Labs has put together a "writers
workbench" which is a set of tools to help detect and correct
common errors. Along with a spell program, there is also a
program to correct "bad diction", along with an "explain"
program which acts as an interactive thesaurus.
If you are interested, send me a message and I will forward
off the manual page.
Michael
Subject: writing aids
∂19-Jul-81 1614 Lauren at UCLA-SECURITY (Lauren Weinstein) writing aids
Date: 18 Jul 1981 0218-PDT (Saturday)
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
To: ELLEN at MC
CC: BUG-EMACS,WORKS at AI
While I cannot help you with EMACS, there is a package of
programs running under Unix called, I believe, the "Writer's
Workbench". These programs do all sorts of neat tricks, like
looking for "awkward" sentence construction, overused or trite
words and phrases, and all sorts of similar actions. Kinda neat.
--Lauren--
---
Subject: Realtime proofreaders
∂19-Jul-81 1615 SHRAGE at WHARTON-10 (Jeffrey Shrager) Realtime proofreaders
Date: 18 Jul 1981 (Saturday) 1130-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: ellen at MIT-XX, works at MIT-AI
I think that one would lose a great deal of the effect of "offline"
proofreading if the system did much of that work in realtime which
the text was being entered. The clearest argument against that type
of system is that you are supposing that the errors are entirely
detectable from PREVIOUS context. Why should that be so? If you
are not assuming that then at what point do you extract and test?
Coherence is not a clearly distinguishable effect at any given level
(sentence, pgh, etc). Additionally, coherence and intention are
understanding effects. It is not clear that they can be extracted
without a rather fancy knowledge acquisition and utilization system
-- not to mention a grammar and semantics analyzer to front end the
thing (neither of which we are very comfortable with yet). Lastly,
more concretely, having a lot of little aid demons around it okay to
a point. You have to avoid the mistake that Twenex makes in being
overhelpful -- I wish that I could disable the space-delimiter help
system that keeps telling me that TPYE is not a legal command before
I've had a moment to back up over it and fix it!
Subject: Configuration
∂19-Jul-81 1617 BHYDE at BBNG Configuration
Date: 16 Jul 1981 1445-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]16-Jul-81 14:45:00.BHYDE>
There seen to be a clusters of similar designs for work stations.
One group is into bit slices and microcode tuning of instruction
set and i/o drivers. Another group seems to be into integrating
state of the art leading edge lsi and i/o devices into an expensive
terminal/computer ala 68000, winchester, and bit map. A smaller
group seems to be into building (the low rider community) super
personal machines a small cluster of 6809 which is a very smart
terminal mostly.
Is there a right answer here?
There seem to be various configuration control designs, the
strongest group seems to be big into 10 Megabit shared medium.
Why is 1 Megabit not good enough, what's wrong with 9600 baud
phone connections, what is so hot about shared medium designs
verses say a local store and forward design with twisted pair?
I don't understand how the configuration problem got standardized
to 10 Megabit shared medium so quickly?
People seem to be very excited about getting rid of the computer
center. I remember the pleasure of discovering that some one
else worried about backup, maintenance, selecting the standard
editor, etc. I believe these places have been called centers
of excellence. The work station architecture seem to be going
in the other direction, for what I believe are marketing reasons
not technical ones. Are there technical ones?
Are new forms of service centers going to appear in the
community? Are we going to see a high speed/quality printing
center in Chicago with one day mailing turn around and very
low cost per page? Are we going to see file backup whales
offering competing cost per bit archiving spread around the
nation? Federal expressing a four color document would add
very little to the cost of a hundred page one time printing.
If I offered a intercity file transfer with one day delivery,
and very low cost would there be any buyers?
All of these questions are the same meta question, how are
systems like this going to be configured, at the office level,
facility level, city level, and national level. Where will
the economies of scale fall out? What is the unit dollars
available at each layer?
Ben Hyde
Subject: [don: EP]
∂18-Jul-81 0044 Dave Crocker <dcrocker@udel> [don: EP]
Date: 17 Jul 81 12:49:40-EDT (Fri)
From: Dave Crocker <dcrocker@udel>
To: WorkS at Mit-Ai
cc: Don at Rand-Unix
Don Waterman has done work similar to Halbert's and said he
would not mind my forwarding the enclosed citations.
Dave
----- Forwarded message # 1:
Date: Thursday, 16 Jul 1981 16:09-PDT
To: Halbert at PARC-MAXC
Subject: EP
From: don at RAND-UNIX
Dan: I saw a brief description on your Exemplary Programming work
and thought you might be interested in similar work done here at
Rand a few years ago. The references are:
Waterman, D. A., Faught, W., Klahr, P.,Rosenschein,
S., and Wesson, R. Design Issues for Exemplary
Programming. In Automatic Program Construction
Techniques, Biermann, G., Guiho, G., and Kodratoff,
Y. (Eds), MacMillan, In Press.
Faught, W., Waterman, D. A., Rosenschein, S., Gorlin,
D., and Tepper, S. EP-2: A Prototype Exemplary
Programming System. Rand Report R-2411-ARPA, 1979.
Waterman, D. A. Exemplary programming in RITA. In
Pattern-Directed Inference Systems (D. A. Waterman
and F. Hayes-Roth, Eds.). Academic Press, New
York, 1978.
plus a few others. I can send you copies of the papers if you
are interested.
Regards,
Don Waterman
----- End of forwarded messages
Subject: Alternatives to making paper go away
∂18-Jul-81 0106 SHRAGE at WHARTON-10 (Jeffrey Shrager) Alternatives to making paper go away
Date: 16 Jul 1981 (Thursday) 2305-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
An alternative to hierarchical file structures for quickly perusing
bulk data: We once tried to implement a fancy solution to this
problem on a rather fancy piece of VG 3-D graphics equipment. Hook
the Z axis into the velocity of a joystick so that the faster you
move the farther away from the text you get. [Actually it isn't
quite as simple as that -- there are various tuned lags that have
to be implanted in order to give the user a chance to respond to
the modifed view, etc]. The effect is that of flying a helicopter
over your text and automatically zoom down for a close up when
you've decided that you're in the right part. I have never seen
a device less fancy than the VG that can respond and redraw quickly
enough to do this properly. The VG is a very high speed vector
graphics display that isn't really built for text work. It has a
stylus pad/light pen/knobs/buttons/full+keyboard (sorry, no meta
keys)/ and the nicest vector display around but it's really for
pictures, not text -- shame about that. Anyhow, we started to
do this and I got sick of having to deal with Fortrash and the
VG internal coding language after about a week so it never "flew"
but it was a nice idea. The real advantage is in reviewing huge
chunks of text (like the Unix manual) that are in some order (say,
alphabetically) because the text is still in front of your face
but the letters are smaller (and you get more of them on the page)
when you zoom out.
Subject: Re: Making paper go away
∂18-Jul-81 0130 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 17 July 1981 1246-EDT (Friday)
From: Joe.Newcomer at CMU-10A
To: Vaughan Pratt <CSD.PRATT at SU-SCORE>
CC: works at mit-ai
In-Reply-To: Vaughan Pratt's message of 16 Jul 81 16:45-EST
Actually, your example is quite amusing. We were recently at a
conference at Pajaro Dunes. One of our participants was walking
along the beach during one of the interludes, and left his book
on the beach while he went into the water. When he came out, he
found that someone had stolen his book.
Yes, paper is more effective for some things RIGHT NOW. While I
don't believe automating blindly is a good idea, for most values
of use of paper I would prefer to use a computer. Even if I
produce hardcopy so it can be carried around, read on beaches and
busses, etc., I prefer to produce it via the computer. There are
lots of cases where paper is more convenient ONLY because of limi-
tations of the computer (e.g., 9600 baud slow lines). And when
computers will cost only $8.95 (or free with a deposit of $500),
there will be far less reason to walk off with one. We have to
quit thinking as if computers will always be expensive, and decide
what we can do with them when they are not. In fact, assume the
cost of the computer is ZERO. Now, what would you LIKE to do with
a computer? What capabilities should it possess at the interface?
Assume a communication cost of ZERO. How would you like to commu-
nicate with other computers? Now, at any given instant we have
to temper these ideas by the rather nasty fact that computers and
communications really do cost money. But that should NOT limit
our imaginations. A Dorado is a good example of what happens if
you let ideas not be limited by technology, and technology comes
along. Things which were unbelievably bad to run on an Alto run
just fine on a Dorado.
Don't tell me automating everything is bad. I don't believe it.
Automating everything INCORRECTLY is bad. I'd rather worry about
how to do it right, even if right isn't possible, than to not
think about the problem because this year's technology can't
support it.
joe
Subject: Scanning structured text
∂18-Jul-81 0150 Bob Hyman <HYMAN at DEC-MARLBORO> Scanning structured text
Date: 17 Jul 1981 1447-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: works at MIT-AI
Message-ID: <"MS5(1715)+GLXLIB1(1033)" 11744780684.17.399.17489 at DEC-MARLBORO>
The static structure of text rarely matches its "content",
except for artificial cases like program sources. Most
of the time, the salient features of a document, which
are the ones I'd like a structured editor to key on, are
dynamically defined by the reader. Until such a symbiotic
system is available, the artificially imposed structure
of the presentation is likely to impede comprehension,
not expedite it.
The alternative is to agree on a canonic form for a class of
documents, and for authors to conform their contribution to
the mold. This solution makes discussion of the canonic form
difficult, and is probably sufficiently restrictive to repel
prospective contributors on other topics as well.
Bob
Subject: Editing
∂18-Jul-81 0211 V. Ellen Golden <ELLEN at MIT-MC> Editing
Date: 14 July 1981 03:12-EDT
From: V. Ellen Golden <ELLEN at MIT-MC>
To: BUG-EMACS at MIT-MC, works at MIT-AI
cc: ellen at MIT-XX
As is often my occupation, I am indoctrinating a new user to
EMACS. She (factual, please do not accuse me of sexism) asked
after a couple of hours of EMACS-power, if it would be possible
for "it" ("The Computer", i.e. a program) to warn her while she
is typing a text, that she has used the same word repeatedly.
I pointed out to her that (a) many words in English repeat because
they are common (parts of the verb to be for instance) (b) some
words need to repeat, like "pathologist" because of the technical
nature of the text, and thus to chose between "facts" and "data"
in discourse might be hard, or to warn her that in the last two
paragraphs the word "experimental" had repeated 6 times might not
work. However, her problem is understandable in English terms:
she is typing up notes for a doctor. He wants to write "well",
which to him means not to repeat himself, which means not using
the same word over and over again, unless it is a technical term
(a distinction he may recognize but I am not sure). His hard-
working secretary is trying to help him, and now that she knows
how much EMACS can help her in just the typing up of his notes,
she is asking for what she sees as the next step, a program
to help her with editorial corrections... (i.e. "How many
times have I used "practical"... should I get out the thesaurus?"
-- next step of course is to provide the thesaurus, but let's
concentrate on repetition of non-common but non-technical words
in text).
Any thoughts on this?
And my comment, to everybody, "BUG-EMACS", and "Work Stations":
See, secretaries are NOT a sub-species of homo-sapiens, they in
fact often request the most sophisticated features from their
editors, justifiers, work stations, etc. In fact, some of them
are even willing to work on programming the features they want
(they do know the specifications, after all!).
Subject: Writing English
∂18-Jul-81 0230 JWALKER at BBNA Writing English
Date: Tuesday, 14 July 1981 22:34-EDT
From: JWALKER at BBNA
To: Ellen at XX, WorkS at AI
CC: Bug-EMACS at AI
I have for several years wanted to write a system with the goals
you described in your note to Bug-EMACS and WorkS. (No funding
has materialized though.)
Some work has been done on the problem by people at Bell Labs.
See the paper by Lorinda Cherry in the June issue of SIGPLAN
Notices. Still the real problems are those that you pointed
out. How can a computer know your reasons for word choice?
What is it possible to do without trying to implement a system
that "understands" free text? (Good writing is more a matter
of taste than of strict rules. Of course, if mediocre writers
follow a set of strict rules, they are more likely to produce
good writing than if they ignore the rules. But that's part
of a different argument.)
I have a few EMACS functions that were designed to help in
finding and correcting common problems -- changing "which"
to "that" (if you care) and "may" to "might" or "can" (may
is ambiguous). I'd like to hear from other individuals who
have written functions to help with the job of writing as I
am working on a technical writing environment.
Jan
Subject: Ideal word-processor
∂18-Jul-81 0250 Robert Elton Maas <REM at MIT-MC> Ideal word-processor
Date: 15 July 1981 03:14-EDT
From: Robert Elton Maas <REM at MIT-MC>
I wish EMACS/RMAIL had this, but maybe if I suggest it this
feature will be installed in some future text-processing system:
You're rapidly typing new text into this editor program. As you
type, in parallel with your typing, the spelling&grammar-corrector
is checking your text. When it finds an apparent error it flags
the error and indicates alongside it a suggested correction.
Any time you want, without having to manually put the cursor back
there and manually make the correction, you may enter one of three
commands:
Stet (ignore the error, let it stand without correction)
Ok correction (make the correction it guessed at)
Repair manually (automatically put cursor there, then you
manually fix it however you want, then if the spelling
corrector still doesn't your fix it shows its new best
guess at correction and leaves the cursor there, so you
can Stet or Ok or Repair again)
After satisfying the flagged apparent error by Stet or Ok, it
shows you the next apparent error if there is any pending; but
you may just continue typing normally if you don't feel like
handling the new apparent error immediately. If you're a bad
speller, what you'd probably do is type a half a screenful
then sit there giving the Ok command for a whole batch of
errors it found, then go back to typing. Thus you wouldn't
have to constantly check your typing to see if keystrokes were
lost or words you're not sure of were wrong. If both the word
you typed and the suggested correction were wrong, but you're
lazy (it isn't an important document nor a submission to a
mass-mailing such as WORKS, just an informal note to a friend),
you could just Stet the error if it's not too gross. You could
even let the suggested corrections roll off the screen, not
bothering to even check them for grossness, if you're really
in a hurry (thus it would degenerate to what we have now if
you choose not to actually use the info the spelling-corrector
gives you).
With a Xerox-Smalltalk style of user interface, you could easily
random-access the suggested corrections, manually fixing the
gross ones and then Steting or Oking all the others en masse.
["Automate the Business Office--How and When"]
∂18-Jul-81 0311 ROBERTS at USC-ISI
Date: 15 Jul 1981 1941-PDT
Sender: ROBERTS at USC-ISI
From: ROBERTS at USC-ISI
To: WorkS at MIT-AI
Cc: roberts
Message-ID: <[USC-ISI]15-Jul-81 19:41:39.ROBERTS>
Interesting quote (attributed to an article in the "Siemens
Review") in this month's issue of "Telecommunications" magazine,
which has an article entitled "Automate the Business Office--How
and When":
"When new functions are added to an integrated work station, the
number of system components increases negligibly because existing
typewriter keyboards already possess keys for function selection,
and the function keypad will be expanded to allow the selection
of communications forms. The flat video display, designed to sit
on the desktop, is used for text preparation with correction and
editing function, the input and output of texts into memory, and
the input and output of texts to be transmitted. The flat screen
is the input/output medium for videotex, interactive videotex,
cable television, storing data from the user's own integrated
work station, and for departmental or central data-processing
systems. Finally, it also serves as the output medium for the
picturephone and video teleconferencing, for which an additional
camera, microphone and loudspeaker are incorporated into the work
station."
Now that's what I call a workstation! Comments, anyone?
Carlos Roberts
Subject: Talking Workstations, that elusive 'external device'.
∂18-Jul-81 0338 DREIFU at WHARTON-10 (Henry Dreifus) Talking Workstations, that elusive 'external device'.
Date: 17 Jul 1981 (Friday) 2127-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
o Introducing Talking Workstations, Part II in presentation series
For some time, people have been doing research and development in
speech recognition.
As the 'locator device' why not voice recognizer?
While I am in my screen editor, I could say 'INSERT' or 'UPSCREEN'
rather than the key strokes.
I could say 'SEARCH' then it would prompt me for a search string.
In addition a key should be provided to toggle this feature on
and off. Imagine a demonstration saying Search or Reverse Screen
and your presentation is forever doomed.
Comments and ideas are being explored by a research group here
at Penn in this area. We'd like to know what the Works community
feels.
Subject: mice,balls,touch-plates,pens.
∂18-Jul-81 0354 MINSKY at MIT-ML mice,balls,touch-plates,pens.
Date: 18 July 1981 01:20-EDT
From: MINSKY at MIT-ML
To: WORKS at MIT-ML, MINSKY at MIT-ML
I feel that the pen-mouse-ball discussion is reactionary --
though many of the ideas are realistic and practical. But all of
them look back to non-interactive sensors of the past. Suppose
the terminal could SEE the user -- using a couple of little
vision-boxes. Then (i) it could watch your hands. You could
point to your icons on the screen in a really natural way. A
tracking cross would permit higher resolution, and the cursor
would move at a rate, say proportional to some power of the
distance between where it is and where you point. Then, one
could use some more AI to distinguish "intentional" hand motions
from tremors, etc. A smart such box could watch your eyes and
face, too.
If you like holding a pen, that too could be wireless -- because
the vision system would track its point. Such systems could work
in three dimensions. The vision box would observe your
eye-point. When you move your head, the various windows would
move in accord with 3-d occlusions, and this would permit more on
a cluttered desk than the usual methods -- moving your head a
couple of inches to the left would uncover the next layer below
on each stack -- etc.
Given a lot of R&D, such gadgets could be made in the next few
years, and would be as important as speech inputs. We need a
"terminal vision machine" project. Also, aren't the CRT schemes
rather reactionary, if flat TV stuff is coming in the next year
or two? Instead of vertical displays we can soon have (i)
desk-surface displays for near vision and (ii) wall projected
screens for far vision.
Subject: Re: Configuration
∂20-Jul-81 0737 Steve Crocker <Crocker at USC-ISIF> Re: Configuration
Date: 19 Jul 1981 1344-PDT
From: Steve Crocker <Crocker at USC-ISIF>
To: BHYDE at BBNG, WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 1145-PDT
Ben,
I don't think it's a fair reading of the present situation
to suggest that computer centers are "going away" in favor
of personal workstations. A better view is that the computer
center is becoming distributed and more easily incremented.
A lot of this is dependent on the specific cost of providing
service in any given technology. Today's costs make it
relatively cheap to provide a noticeable amount of computing
power to each person in the form of an individual workstation.
This means that the cost of separate packaging is less than
the cost of multiplexing several users onto the same (large)
machine. It's quite possible for this to shift back the other
way, though not likely, in my opinion.
Several things do remain centralized, and properly so:
a) file servers, high-quality printer/plotters,
long distance communication;
b) maintenance;
c) system development (hardware and software).
Your scenario of using a service in Chicago with overnight air
service is not only reasonable but entirely usual. There are
indeed services that are expensive enough to absorb the cost
of long-distance delivery. Various forms of fancy printing,
as you mentioned, is one; transcriptions of stenographic tapes
is another. I'm sure there are others.
Getting back to individual workstations, my own view is they
offer one big plus and one important trap. The big plus is
that the economics of adding a new user to "the system" is
much clearer. The classical time-sharing environment essen-
tially forces overloading of the machine, and we commonly see
environments where only the trivial tasks can be done during
the day and the heavy-duty tasks are delayed until evenings
or weekends. Unfortunately, it's these heavy-duty tasks that
are the reason for the facility and the people in the first
place. (Yes, I know this can be seen as a straight case of
mismanagement. Nonetheless, it's where things are.) With
computation tied to terminals, it becomes essentially
impossible to add people without adding capacity. (There's
always the possibility of "sharing" workstations. This may
be useful in some cases, but it will be clear to all that
when a person does not have access to the workstation, he
does not have access to anything. Compare with today's
situation where everyone has a terminal, but that doesn't
guarantee access to anything substantive at all.)
The trap in all this is there is a far sharper limit on the
size of the task that can be carried out with a workstation.
A lot of important tasks use more of the cetral facility than
the nominal capacity that is being doled out in workstations.
That will mean that transition from a small task fitting on a
workstation to a larger task that requires a different machine
will be relatively painful.
Steve
-------
Subject: Collected Responses on Terminal Input Devices
∂20-Jul-81 0838 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Terminal Input Devices
Date: 20 Jul 1981 08:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 July 1981 07:00-EDT
From: sdcsvax!norman@NPRDC
Msgname: norman
To: works@mit-ai
Subject: keyboards should get changed, maybe
Marvin Minsky suggests that it is unimaginative to worry about
track balls and mice, light pens and touch screens, when visual
sensors can interpret your finger and eye motions so that you
need not lift your fingers far off the keyboard. Keyboard?
You mean the good old qwerty keyboard, arranged in 1873 by the
Sholes brothers to minimize jamming of the big lever arms on
the keys as they made their way to the platen? That triumph
of technology over common sense? Well, if you want to be
imaginative, why stick with qwerty keyboards?
The answer, by the way, is not to be found by simply rearranging
the keys. It turns out that qwerty is not so bad. The scheme
the Sholes brothers used to minimize clashes put the keys for
frequently typed bigrams far apart, meaning on opposite hands,
which we know today means faster typing. Lots of people have
fiddled with keyboard arrangements; its not worth the fuss.
Dvorak did a time and motion study analysis in the 1930's and
only improved typing speed by about 5% (some have claimed more
improvement; this figure comes from experiment, by computation,
and by a typing simulation program that we have developed). (In
similar ways, azerty and alphabetical arrangements don't lead to
much difference -- about 2 to 5% decrement.) And several studies
of beginners using alphabetically organized keyboards show no
improvement over qwerty. (Paper available on request.)
The current keyboard is hard to learn (several months to get to
speed), a surprisingly large proportion of people in this country
cannot type, and the top speed is limited by a combination of
physiological/anatomical factors and keyboard layout. Chord key-
boards, as used by court stenographers, go considerably faster
(they type syllables, with several simultaneous keystrokes), but
this takes even longer to learn (years), and it isn't easy to
decode as the users develop their own code for many words.
(On-line decoding can and has been done.)
BUT, why have 4 rows of keys? Why have a space bar that takes
up the whole row and is used only by the right thumb? Why not
allow upward movements as well as downward ones to be meaningful.
Why not allow multiple strokes to have meanings. Why so big?
The current size and the funny diagonal layout is determined
by historical mechanical constraints and violates the natural
mirror-image symmetry of the hands. Fitts law states that the
time to move the hands is linearly related to log(D/P) where
D is the distance to be moved and P the precision required.
You will gain a lot if the keyboard is made smaller and if
sloppiness in target location is allowed. Eliminating the
need to type RETURN on a line can speed up typing a much as
30% (our high speed films show the hand must distort itself
rather badly to get to the RETURN).
Would speech input be easier? Probably not, but a combination
of a sophisticated keyboard plus speech might be very effective.
How about tiny mice mounted on the keyboard where the thumbs can
reach them, or worn on rings, or available on a "roof" just above
the keys so that lifting the hands a fraction of an inch contacts
them. Or consider inserting the hands into gloves (wear your
keyboard) with touch and force sensitive fingertip sensors and
let hand configuration select the word and/or cursor placement.
And so on. The point is, it is time to change the keyboard,
and not just by rearranging the keys; that won't buy anything.
don norman (norman@nprdc or ucbvax!sdcsvax!norman)
------------------------------
Date: 19-Jul-81 17:08:04 PDT (Sunday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Talking Workstations, that elusive 'external device'.
In-reply-to: DREIFU's message of 17 Jul 1981 (Friday) 2127-EDT
To: DREIFU at WHARTON-10 (Henry Dreifus)
cc: Hamilton.ES, works@AI
I'd like to preserve my vocal cords, thank you. Not to mention
the fact that not everyone has a private office. I can deal
with the clack of my officemate's keyboard and the hum of his
disks, but I don't think I want to hear him muttering to his
computer all day.
I think that something along the lines of what Minsky was
suggesting would be more appropriate -- we could make much
greater use of technologies that have been heretofore
reserved for the handicapped, such as breath control, eye
control, etc. Also, I really like the idea someone suggested
a few days ago of placing lotsa special input devices just
below the spacebar. I just realized that my left thumb is
\completely/ unused!
--Bruce
------------------------------
Date: 19 July 1981 20:38-EDT
From: Marvin Minsky <MINSKY at MIT-MC>
Subject: visionary terminals
To: WORKS at MIT-MC
The general question of sneezing, etc., is interesting, and I wonder
if there is a nice theory of this: many interaction-devices separate
"pointing" and "doing". One positions a mouse and then presses an
action-button. This makes things clear to the computer, and protects
us from using signals than can be accidental. One does not often type
"DELETE *.*" as a side-effect of a sneeze.
In my vision, the AI sensing system gets better and better at telling
what you intend. In the first decade, I suppose, we'd be lucky to get
it reliably to tell where you're pointing, or what simple verbal
command you said. In another generation, it would be able to tell
when you're talking to IT, rather than someone else who just came in.
("What're you doing?" "Oh, just deleting everyone's files" -- meant
sarcastically, of course, but obeyed by the clever system.) As we
progress, the systems should grow better at telling what you really
want, and being sensible about which such intentions are plausible.
Of course, I don't believe that programming will become a casual,
natural language activity, because I don't think natural language has
adequate ways to describe an advanced programmer's intentions. (But
perhaps in a couple of generations a new order of procedural
expressiveness will indeed creep into everyday life!)
------------------------------
Date: 19 July 1981 1849-EDT (Sunday)
From: Jordan.Nash at CMU-10A
To: works at mit-ai
Subject: Terminal input devices
Message-Id: <19Jul81 184908 JN70@CMU-10A>
If we are willing to disregard cost for the moment, why not
consider pupil tracking technology as an input device. One could
simply look at the desired operation displayed on the screen and
perhaps confirm its selection by pushing a button. This certainly
eliminates the hand coordination needed for mouse input and the
sticky screen and physical exertion of the touch panel. Having
been attatched to a pupil tracking device, I realize that current
design is uncomfortable for the trackee, but I don't know enough
about the technology to throw out the idea.
Any thoughts?
/Jordan Nash
------------------------------
Date: 20 July 1981 0357-EDT (Monday)
From: Lars.Ericson at CMU-10A
To: WorkS at mit-ai
Subject: Soft Keyboards
Message-Id: <20Jul81 035716 LE60@CMU-10A>
Has anyone ever tried to build LED's right into the keytops?
This idea has always intrigued me, though it would make for
a rather expensive keyboard. Then when one wanted a new
character set, one would simply download a new set of keytop
images to the keyboard. No messy paper stickons; invent new
symbols; who knows what possibilities?
No, I do not consider a video display with a touch sensing
pad over it to be a reasonable equivalent to this.
------------------------------
End of Collected Responses on Terminal Input Devices
****************************************************
Subject: terminals versus comp centers
∂21-Jul-81 0814 Hank Walker at CMU-10A (C410DW60) terminals versus comp centers
Date: 20 July 1981 1815-EDT (Monday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Gordon Bell has pointed out that disk drives and fancy printers
are about the only things left that have economy of scale. You
might as well chop everything else into little pieces, it makes
the incremental cost smaller.
As almost everyone on this list surely knows, comp center people
frequently tend to be power-mad, bureaurocratic, etc. Given the
choice, would you rather use the comp center or the CS department
machines?
When computing is relatively free, all arguments about wasted
cycles are bogus. You should think of your computer like your
car. Are you worried that you car is sitting idle all day
while you are at school or work? I'd think that you'd be
plenty worried if it wasn't. Are you worried that it isn't
being used at night? No. Same goes for computers.
To do fancy graphics, you need a lot of local processing due to
bandwidth. Once you do that, adding general purpose computing
isn't all that hard or expensive. If the graphics is done by a
general-purpose CPU, a la Alto, then the cost is essentially
zero.
Subject: Collected responses on terminal input devices
∂21-Jul-81 0922 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 21 Jul 1981 09:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 Jul 1981 12:09 PDT
From: Kimball at PARC-MAXC
Subject: Terminal Input Devices
In-reply-to: WorkS-REQUEST's message of 20 Jul 1981 08:00-EDT
To: WorkS at MIT-AI, ALBrown
Speaking of soft keyboards, I'm surprised no one has mentioned
an old idea that has been kicking around 5 or 10 years: an image
of the keytops can be generated on the display and then reflected
off a half silvered mirror that is mounted over the keyboard.
The user can see the keys (even when his hands are over them!)
with whatever labelling he desires, switched at electronic speed.
Furthermore the geometry is such that the user doesn't have to be
exactly "on axis" to see the desired image.
Of course, there are some drawbacks, but none of them seem to be
showstoppers:
1) a lot of expensive resources (e.g. bitmapped display &
memory) are given up to support the keyboard image. Also
the image on the screen surface itself is upside down;
2) the glass "shield" over the keyboard sounds awkward;
3) I wonder whether screen curvature, raster blooming, and
the like would make it hard for the keytop images to be
precisely aligned with the physical keyboard.
Ralph Kimball
P.S. Allen Brown tells me that this concept was explored
by someone in IBM on behalf of J. C. R. Licklider
(Licklider @ MIT-XX). Forgive me if this is a garbled
pointer.
------------------------------
Date: 20 Jul 1981 1319-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: SHRAGE at WHARTON-10, works at MIT-AI
Subject: Re: Interchangable keyboards
In-reply-to: Message from SHRAGE at WHARTON-10 (Jeffrey Shrager)
of 18-Jul-81 0641-EDT
At an NCC a while ago, I saw a terminal with a dynamically
lableable keyboard. The keys were arranged in a 10 x 50 matrix,
and had transparent tops. There was a mechanical (air-driven,
I believe) sheet feeder that could slide any one of about 10
different layouts under the key matrix. The particular layout
was selected by function keys off to one side, and it took about
1/10 sec. to switch, accompanied by some hissing and clunking.
It was not an entirely unworkable arrangement.
------------------------------
Date: 20 Jul 1981 1218-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: QWERTY space bar
To: WorkS at MIT-AI
If the RETURN key is in the wrong place and the full-length
SPACE bar is a waste, why not split the SPACE bar and use the
left thumb for RETURN? One would think this would not cause
too much trauma either for manufacturers or users.
------------------------------
Date: 21 Jul 1981 00:39:45-PDT
From: decvax!duke!unc!smb at Berkeley
To: WorkS at MIT-AI
Subject: keyboard tracking system
Cc: duke!shg@Berkeley
This note was sent to me; I thought I'd pass it on
>From duke!shg Mon Jul 20 09:34:50 1981
Date: Mon Jul 20 09:33:20 1981
I saw your note about a keyboard tracking system. It
seems to me that the most convenient position for a cursor
control setup is just below the space bar on the keyboard.
A small trackball or joystick modified (or even a two-
dimensional slide switch) could be easily manipulated by
either thumb without moving the fingers from the keyboard.
I find that I always use my right thumb for spacing,
thus I guess with a little practice I could use my left
thumb for cursor control EVEN WHILE TYPING.
------------------------------
Date: 20 Jul 1981 0838-PDT
From: WMartin at Office-3 (Will Martin)
Subject: Keyboards
To: works at MIT-AI
Message-ID: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
Keyboards: There was a LONG series of discussions on Human-Nets
some time back about Dvorak keyboards. If there are people on
this list who weren't exposed to that, maybe somebody with an MIT
account could run an editor through the HN archives and come up
with a consolidated file for FTPing of that exchange. Would be
appropriate as the list seems to now be covering alternatives to
the standard keyboard, and Dvorak has lots of supporting data
which was outlined in that discussion.
[ A transcript of the HUMAN-NETS discussion on keyboards is
available in the file DUFFEY;WORKS KEYBRD on MIT-AI. -- RDD ]
------------------------------
Date: 21 July 1981 02:12-EDT
From: Marvin Minsky <MINSKY at MIT-AI>
Sender: MINSK0 at MIT-AI
Subject: pointing devices
To: MINSKY at MIT-AI, WORKS at MIT-AI, norman at NPRDC
I agree with Donald Norman about re-examining keyboards. I
wasn't concerned with keeping hands on keyboard, because I
once learned some American Sign Language (ASL) and saw that
sign-language works quite well and could be quite fast --
provided the intelligent observing machine can keep up. One
learns a large lexicon of special words and symbols in ASL
and, when these fail one uses "finger-spelling". The latter
is lots slower than expert typing, to be sure. But this is
because one has to reconfigure the whole hand for each letter;
the vision machine could sense smaller finger changes than a
person could, I think. Then we could adopt Norman's idea
of using bidirectional finger motions, and little "chords",
etc. In the end it should be faster than typing.
Gloves and rings and things might do, but I think AI will get
around to making good seeing machines eventually, and they'll
do so many things that they'll be cheap. In the end, there
will be two or three of them inside the average typewriter,
just watching for paper jams and ribbon problems. After a
while, people will find that they don't need many of the
machines that the vision boxes were made to keep an eye on.
------------------------------
Date: 20 July 1981 1222-EDT (Monday)
From: Hans Moravec at CMU-10A (R110HM60)
To: WorkS at mit-ai
Subject: Gloves
Along with the keyboard gloves you get a head-mounted binocular
display, as in the old Utah 3D system. Now you can not only
move your head from side to side to reveal obscured pages,
but can walk around your workspace and view it from behind or
underneath. If you're into such, the entire workspace can be
mapped onto the surface of your real desk, and there can be
simulated piles of paper that look like the real thing! To
focus your attention on one, just move your head closer to it.
If the head mounted display carries outward looking cameras
that can track your fingers (and microphone and earphones),
you could pick up and shuffle the simulated paper. In the
long run all this stuff should be integrable into an
eyeglasses frame.
It needs some kind of intertial or other navigation system to
make sure it knows where your head is to generate the appro-
priate view. With a radio link to a communication system and
a shaving mirror it could be used as a videophone. Or a cheap
telepresence terminal. Or a syntha-presence unit; Imagine the
adventure display possible when you can walk around the scenes
in 3D (need a lot of crunch power for this, but much more
practical than some "holographic" methods suggested by Niven).
Better watch your icons, though!
------------------------------
Date: 20 Jul 1981 (Monday) 1804-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: In response to "gloves"
To: works at MIT-AI
It was suggested to my by Saul Levy of Bell Telephone Labs, (as
not to implicate myself) to use Teflon Boots that someone puts
their feet into, as not to have to remove one's hands from the
keyboard when typing. I leave this as a comment nothing more.
Hank
------------------------------
Date: 20 July 1981 1056-EDT
From: David Smith at CMU-10A
Subject: Pointing devices
To: WorkS @ mit-ai
In the summer of '78, I saw a demo at SRI of a device which
could tell where your eyeballs were pointed. It used internal
reflections in the lens. People were writing their names with
it. The writing was rather jerky, because the eyeballs move in
saccades. If your work station had one of those, plus a speech
(word) recognizer, you wouldn't have to remove your hands from
the keyboard to designate an icon. Lacking a speech recognizer,
you could type escape-footpedal-foo, but that lacks class.
------------------------------
Date: 20 Jul 1981 1351-PDT
From: Kelley at OFFICE
Subject: The Back Split Twist Keyboard
To: works at MIT-MC
Take the Maltron contoured keyboard. Chop it in half down the
middle. Put mice wheels under each half. Pick the portion of
the desktop you are viewing on the screen with one half. Pick
entities on the screen with the other half. No need for your
hands to leave the keyboard. Engineer a little to keep the
keyboard stationary while you type.
Now. Take a flat display screen that fills one whole surface
of a box about the size of the Whole Earth Catalog. Put your
processor in the box. On the back, place each half of the
keyboard twisted so you are holding the book while you type.
Control wheels / track ball on the side with the thumb / palm
of your hand. Control your dynabook with your back split
twist keyboard while you walk the earth.
-- kirk
------------------------------
Date: 20 Jul 1981 (Monday) 1935-EST
From: STECKEL at HARV-10
Subject: recommended reading
To: WorkS at MIT-AI
Seeing the flames and flak fly freely the last few weeks, I
would strongly recommend all participants to read the issue
of the ACM Computing Surveys Vol 13 no. 1 of March, 1981.
It addresses "human factors in computing". Especially of
interest are the article on editors and Beau Sheil's
article.
Aside, I would suggest that the ideal "terminal" look like
a pad of paper (flat screen display), with a keyboard on the
lower 1/3 or so...
g steckel
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: WorkS problems
∂21-Jul-81 1105 DREIFU at WHARTON-10 (Henry Dreifus) WorkS problems
Date: 21 Jul 1981 (Tuesday) 0950-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
WorkS has now grown to include roughly 750 people on 50 sites
across the ARPAnet. The number of topics being discussed at
any one time has increased from 1-2 to 4-5. Somewhere between
12-15 messages are submitted to the list each day. Each day's
submissions comprise approximately 15,000 characters of material.
The result is that WorkS is beginning to suffer from severe
problems. Problems which many people have begun to note.
It takes roughly 30 minutes (real time) of processing by the
mail server to redistribute one, 1000 character to everyone on
the WorkS mailing list. The amount of time required depends on
several factors. The most important factor is simply the total
number of individual message transmissions that the mail server
must do.
For example, consider the difference between distributing one
20,000 character message and 10 2,000 character messages to
WorkS. The 20,000 character message will require around 100
minutes (real time) of processing by the mail server. The 10
2,000 character messages will require 300 minutes (real time)
of processing by the mail server. Here you see the advantage
in redistributing the messages oriented around a single topic
as a collection of messages rather than as individual messages.
However, that expedient is proving inadequate to deal with
WorkS problems.
This means in all probability that WorkS will have to become
another digest mailing list. Over the next few days we'll
explain what this change entails. In the meantime we will
continue with redistributing the incoming messages in topical
collections where appropriate.
Comments/opinions/questions to WorkS-REQUEST at MIT-AI.
Hank Dreifus
Subject: Realtime proofreaders
∂21-Jul-81 1022 Robert Elton Maas <REM at MIT-MC> Realtime proofreaders
Date: 21 July 1981 09:25-EDT
From: Robert Elton Maas <REM at MIT-MC>
To: SHRAGE at WHARTON-10
cc: works at MIT-AI, ellen at MIT-XX
The advantage of automatic fixups is that you can spend your time
proofreading for deep stuff instead of proofreading for trivial
spelling errors and the like. (This is the general thing about
automation, you let the computer or other machine do the trivial
stuff so you can have more time to do a good job with the deep
stuff. FFM loosely quotes somebody named "Andre Gide", who said
"This has all been said before, but since no one was listening it
bears repeating.")
The advantage of realtime fixups, or at least flags you can
confirm later, is that the typist can detect whether something
heesh noticed as a mistake was also noticed by the computer
instead of wondering for the next hour if the post-processor
will find it; if the computer flagged it, then the typist can
safely ignore it now, even forget it, because heesh will be
reminded of it later when making a big confirm-pass thru the
document.
The problem with TWENEX is its method of flagging errors in
realtime is obtrusive. It goes ahead and makes a mess, instead
of just brightening or boxing the offending misspelled word and
letting the user move the mouse back there later to fix the word.
(Of course this is because it was designed to work on TTYs and
Decwriters, not ALTOs and other graphics-mode displays with
massive display-computing power and mouse.) Perhaps somebody
with experience on Xerox-Smalltalk on Dorado could comment on
how Xerox-Smalltalk handles errors when manually typing in
commands (instead of using the mouse to select commands from
a menu). I seem to recall you type commands into a window
and can edit them to your heart's content, then when you hit
the activation button on the mouse they are parsed and any
syntactic error is flagged, and you can edit again and again
until the parser accepts it.
Right?
Subject: File Backup
∂23-Jul-81 0031 Joe.Newcomer at CMU-10A File Backup
Date: 22 July 1981 1649-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
The Spice project plans to treat the local disk as a cache for
the central file system. Thus, primary backup is handled by
the same staff which backs up all our other systems. Local
disks will not have substantive amounts of private data which
is not replicated on the CFS.
In the case of workstations not on a network, if we abandon
such archaic ideas as single-task workstations, files without
timestamps, and similar absurdities, and produce some reasonably
intelligent software, a background task which does hourly, daily,
or as-needed backup to a floppy disk or other medium such as
streaming tape, occasionally prompting the use to insert a new
disk or tape, and which handles the grubby details of how to do
file retrieval in case a file restoration is necessary seems the
obvious simple solution. As I am currently thinking about having
a personal 68000-based system at home, which will not be on a net-
work, and cannot use CMU's machines for backup, this is one of the
first pieces of software I would build. My plans are to simply
assign ascending serial numbers to the floppies, and keep a file
(which is naturally backed up) which is a migration archive file
[CMU-10A users will recognize this as MIGRAT.DIR...]. Since all
REAL computers (not toy computers, no matter how powerful) have
date-time stamps which can go on files, the software architecture
is reasonably obvious.
Those ridiculous systems in which one can save or restore the
entire disk, but not do incremental save or restore, are not
worth talking about. I certainly don't want to reset my
entire disk to yesterday afternoon just because the system or
I accidently damaged one file.
More sophisticated applications, including large databases, need
more sophisticated incremental backup procedures. But these are
ALL OBVIOUS and can be ALL AUTOMATED. Using "clerical people"
or "professional people" means we've forgotten the best drudge of
history: the computer itself. The overhead on anyone to write a
serial number on an existing disk or streaming tape and insert a
fresh one is so small as to be unnoticeable. (Of course, I would
never consider the problem of "tying up the floppy drive" while
doing backup; floppies are not reasonable as secondary storage for
serious applications; they are far too small and slow compared to
even the current processors they are mated with. I consider a 10Mb
disk as small, but marginally acceptable, on a personal workstation.
24Mb is acceptable, 100Mb is reasonable. Floppies are at best a
cheap backup medium, not to be used for serious storage. I have
a small personal database which already exceeds 1Mb).
joe
Subject: Collected responses on terminal input devices
∂23-Jul-81 0228 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 23 July 1981 02:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at AI
------------------------------
Date: 21-Jul-81 14:55:07 PDT (Tuesday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Terminal Input Devices
Another problem with the idea of reflecting images of keycaps onto
the top of the keys is that it prevents the use of a detachable
keyboard. Some human factors expert at NCC spent a lot of time
ranting and raving about how important detachable keyboards are.
Also, the natural touch-typing position would mean that (1) the
home-row images would be invisible because they would appear
on my next-to-last finger bones, which are angled back toward
the screen, and (2) for most keys below the home row, the image
would appear on my fingers or hands at such a distance above
the keyboard as to make the association with an individual key
rather difficult. This could even become a racial issue(!),
since presumably black people's hands don't function nearly
as well as projection screens.
All in all, if you really want to look at the keys, the key sides
are a lot more visible than the key tops, unless you're some kind
of two-fingered wonder at the keyboard.
I don't think anyone has mentioned the idea of burying a small,
high-density CRT inside the keyboard and then using fiberoptics
to route the appropriate portion of the image to each keycap.
--Bruce
------------------------------
Date: 22 Jul 1981 0941-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
Subject: Terminal Input Devices
It seems to me that the position of the operator's head is very
important in a scheme to reflect the key markings off a half-
silvered mirror. I have always hated things with half-silvered
mirrors anyway, because head positioning is so critical. Also,
it eliminates the possibility of a removable keyboard.
On another tack, I was discussing some of these schemes (boots,
gloves, rings, LCD keytops, etc.) with a friend here at DEC and
he was repulsed by them. He wasn't even interested in foot pedals.
Then again he has always worked for DEC (since leaving WPI), and
neither DEC nor WPI are exactly at the forefront of these ideas.
It suprises me that no-one has mentioned the possibility (seriously)
of mounting the keyboard on a (large) mouse. Mice don't have to move
a great deal to scroll the entire screen, and four mounted as the
feet of a removable keyboard could work nicely. They would need a
sticky surface and would have to require more umpf to push them (in
order to avoid false readings), but I think the idea is feasible.
For those of you in love with chord keyboards, you could mount a
mouse under one even easier.
If you think this is entirely ludicrous, I cast my second vote for
a trackball near the left thumb (perhaps cutting the spacebar short).
My VT100 does not insist that a distort my hand too much to hit the
return key (it is a selectric arrangement), and I would rather be
cursory with my left thumb. However, as my WPI/DEC friend points
out, it can be hard to use: he has a broken left thumb.
------------------------------
Date: 22 July 1981 01:41-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Keyboard Augmentation
Someday, I will actually try to implement this: maybe three
footpedals, one for Shift, one for Control, and one for Meta
(Edit). I have had a sore left wrist for three months now,
and am just beginning to realize just how much I use and
contort that hand/wrist to use those keys. Footpedals would
certainly go along way to aleviate that strain.... maybe not
just three...
--Frank
------------------------------
Date: 22 July 1981 1751-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
Subject: Finger distortion
I find the backspace and escape keys even more awkwardly placed
than CR. I usually use ↑H in preference to Rubout or Backspace
because the finger travel is shorter and faster, but not all
systems treat ↑H, Backspace (which is usually ↑H but sometimes
sent as rubout, depending on your terminal) and Rubout
identically.
joe
- - - - Begin forwarded message - - - -
Date: 16 Jul 1981 (Thursday) 1503-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Interchangable keyboards
To: works at MIT-AI
Via: MIT-AI; 18 Jul 1981 0639-EDT
I once saw design specs for a keyboard in which the keytops were
little LCD displays and were, of course, under computer control.
The types of things I can imagine doing with such a device are
virtually unlimited: Emacsify the keyboard for ↑X or ESC (Sorry,
Fineify), show keywords like various Basic systems, swap your
keyboard to APL mode with the screen, etc, etc. Does anyone
actually produce such a device?
- - - - End forwarded message - - - -
------------------------------
Date: 21 Jul 1981 21:57:41-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
Subject: Talking Workstations
Have there been any measurements of the relative `work' involved
in:
a) typing "s/foo/"
b) finding a key labeled "ENTER", hitting it, typing
"foo", finding a key labeled "SEARCH" and hitting it
c) saying "SEARCH!" then saying "EFF OH OH (pause)" ?
------------------------------
Date: 22 Jul 1981 18:10 PDT
From: Kosower at PARC-MAXC
Subject: Re: mice,balls,touch-plates,pens.
In-reply-to: MINSKY's message of 18 July 1981 (Saturday) 01:20-EDT
Better yet, we could construct a box that "listens" to the
user's brainwaves (or brainstorms, as the case may be...) and
figures out from that what the user wants to do, and does it.
That way, the user would be completely spared the tedious task of
pointing. And by using a little more AI, we could construct a box
that would figure out what needed to be done (edit reports, write
programs, answer mail, etc.) and would do it without any user
intervention at all. That way, we could get rid of "reactionary"
old terminals and perhaps with the user to boot!
David A. Kosower
------------------------------
Date: 21 Jul 1981 21:56:01-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
How can you call that a workstation without holocamera & odorama?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: More on configuration
∂23-Jul-81 2309 BHYDE at BBNG More on configuration
Date: 23 Jul 1981 1116-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]23-Jul-81 11:16:04.BHYDE>
Let me repeat some of the phrases in the replies to my query on
configuration.
From Steve Crockers message;
"the cost of the separate packaging is less than the cost
of multiplexing several users onto ... larger ... machine."
"things do remain centralized, an properly so: file servers,
high quality printers, long distance communications, ...
maintenance ... system development ( hardware and software )"
"classical time-sharing ... forces overloading of the machine
... this can be seen as miss management... with computation
tied to terminals it becomes ... impossible to add people
without adding capacity."
"transition from small task fitting on a work station to a
larger task ... will be ... painful."
From Hank Walkers message;
"disk drives fancy printers are about only things left with
economy scale ... might as well chop everything else into
little pieces, it makes the incremental cost smaller."
attributed to Gordon Bell
"center people frequently ... power-mad, bureaurocratic."
"are you worried about you car sitting idle?"
"fancy graphics needs a lot of local processing .. (then the
cost of) ... adding general purpose computing ...(is) ..
essentially zero."
Forgive me for the paraphrasing and quotation out of context.
I find quite convincing the point that baseline services; communi-
cations, graphics processing, and packaging make the marginal cost
of a substantial piece of computing power in the office trivial.
No ones seems to argue for the demise of the computing center, I
had expected people to argue it would be replaced; on the low end
by work stations and on the high end by external service firms.
People seem to believe that central facilities, file servers etc.
will remain within the organization.
As an aside the comment about cost of multiplexing into the central
facility seems odd considering the huge increase in cost of communi-
cations that local networks imply verses front ends. Any one want
to argue the other side of that one? No one has explained to me
yet why the hugh bandwidth is a good thing in the local computing
environment?
I have believed that the leverage available in purchasing larger
machines was very substantial. If I build out of a fast expensive
technology I get a power of ten improvement in my cycles for a
linear increase in my cost. If I build out of many processors
I get a linear increase in power for a linear increase in cost.
Have I been stupid and mislead?
If this is true than, disks, fancy printers, communications, and
fancy processors will go in the central facility. The work station
design will be aligned on a cost effective boundary one up from
that amount of power necessary for graphics, communications, and
work space management.
I find the comment about cars rich in metaphorical implications;
there are many people who believe that cars are a very poor piece
of social engineering. Do organizations have more capital tied
up in the parking lot than they do inside? Unsafe at any speed?
Ben Hyde
Subject: WorkS Software.
∂24-Jul-81 0011 DREIFU at WHARTON-10 (Henry Dreifus) WorkS Software.
Date: 23 Jul 1981 (Thursday) 1928-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
Part-III
The Hardware is one thing, the software is the more lasting concept.
Will the future software change? Will we see more screen-formatting
packages, better user interfaces?
What about the programmer? Source level Debuggers, complete control
of the machine (micro-code all the way to the I/O slot which is
latched to the on/off switch)?
Screen this, and menu that.
Will there be standards for screen definitions? Not at all
unlike the Core←graphics←standard we are seeing now, thanks
to VanDam and Badler and company.
Will there be "drivers" for One-User software? Distributed
power, shared computing, the questions of Queuing processes
accross machines - across the country.
Local-vs-Long Distance networks. How does one effectively
integrate this? There are more machines out today than ever
before.
The above are just some thoughts/interesting topics to get
discussions going off over all of the innovations necessary for
PersComs.
Henry Dreifus
Subject: Collected responses on useable systems
∂24-Jul-81 0036 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on useable systems
Date: 23 July 1981 04:17-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WORKS at MIT-AI
------------------------------
Date: 23 July 1981 16:29-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: mundane
To: Joe.Newcomer at CMU-10A
Joe Newcomer raises a very good point in his letter of July-22:
I find that I have less and less time to worry about,
say, how to make CR in EMACS behave like LF and how to stop
LF from behaving differently if the previous line started at
the left margin. I know what effect I want; I don't want to
know about 37 different variables, TECO FS-flags, and other
crap to get a simple change in behavior. This is a lot of
what is involved in getting really good personal workstations;
if I have to remember dozens of incantations to, say, set up
defaults when I boot, I'm not going to be very happy.
joe
=-=-=-=-=
Peter Keene (sp?) of MIT Sloan School has a nice way of describing
the sort of system behavior Joe is looking for: mundane.
If I am not a car wizard I want my car's behavior to be mundane.
I want my car to be boring, I don't want it doing interesing things
like losing wheels. Many car drivers also don't want to learn all
the exciting things that you can do with manual transmission, boring
old automatic transmissions are good enough to get where you are
going.
If I am not a phone wizard I want my phone to be mundane. I am
not particularly interested in the intimate details of the phone
billing system when I am complaining about a $7,000 phone bill,
I really wanted the phone company to do the boring old thing and
bill me my normal ammount.
I believe that most people will want their workstations to be
mundane. They probably won't want a 3 week training course to
learn all sorts of wizzy neat features. If it behaves mostly
like those boring old office equipment (typewriters, phones,
etc.) it will probably be enough. After all, most people will
be using the workstation as a tool to get their work (what they
find interesting enough to be paid for) done.
- Steven Gutfreund
------------------------------
Date: 23 July 1981 04:17-EDT
From: James M. Turner <JMTURN at MIT-AI>
Subject: Various subspecies
To: Joe.Newcomer at CMU-10A
Shade and Sweet water,
But designing systems who's most inexperienced user is it's
lowest common denominator severely limits what can be built in
to the language.
As an example, I am currently involved in moving Scribe
to the Lisp Machine (albeit, in a greatly changed appearence).
A decision that was made very early was that although the
DOCUMENT (the Scribe input file) requires no specialized
knowledge to write, extensions to the system itself require a
working understanding of Lisp, and the way Scribe works in this
version. The idea behind this was that if we tried to create
a "secretary extensible" environment, we would be sacrificing
efficiency (important in a package which is already dangerously
slow due to LISPM <-> PDP-10 I/O speed) and clarity of code for
the benefit of people who would probably not wish to change the
code anyway.
Besides, the typical supervisor doesn't want "low level"
personnel fooling with the code anyway. A friend who is
currently doing DE for DEC related the story to me of how her
supervisor had flamed when she had poked around the OS trying
to find out how to logout (it seems SOP was to hang up, which
she could not accept).
James
------------------------------
End of collected responses on useable systems
*********************************************
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac workstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac wo
rkstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
To: "@SUN.DIS[P,DOC]" at SU-AI
Date: 22 Jul 1981 1736-PDT
From: RINDFLEISCH@SUMEX-AIM
Subject: INFORMATION RE INTERLISP DOLPHINS
Ed Feigenbaum received the following message from Mr. R.E. Bomeisler,
Marketing Manager for Xerox EOS, in response to repeated requests for
more information about Dolphins necessary for planning acquisitions.
Since others may be in the same situation, Ed wants to pass the
information along to other computer scientists. You may forward
it if you wish.
Tom R.
*********************************************
7/16/81
"In our telephone discussion, Ed, you indicated that Xerox
was not providing you and potential users with enough information
to assist you in designing your networks and planning for future
growth. I would like to apprise you of the steps we have taken
at XEOS to fill the information gap.
Marcel Pahlavan is the program manager and is the focal
point for responding to customer inquiries on interface and other
technical matters. On August 1, Terry Haney will join the staff
to provide hardware expertise. An Interlisp software expert is
being actively recruited. In addition, Pahlavan can call on other
system experts within XEOS to solve specific customer problems.
With regard to 3M bps Ethernet networks, the 1100 system
includes the hardware necessary for connection. In addition,
XEOS will make available the hardware necessary to connect the
DEC Unibus. This includes the DEC Unibus Ethernet Interface
Board, Transceiver, Terminator and Connector. This hardware
enables connection to 3M bps Ethernet on the DEC PDP-11 family
aswell as the DEC 2020 and the VAX family. To connect the
DEC 2040, 2050, and 2060 to 3M bps Ethernet will require either
development of a Massbus Ethernet Interface Board or a PDP-11
front end interface. When either of these is developed within
the ARPA-sponsored research community, XEOS will facilitate
distribution.
XEOS is a systems organization with the skills to develop
special hardware or software. It is expected that we will be
called upon to modify the 1100 hardware or software to meet
special customer requirements.
With regard to DEC hardware/software, there exists within
the ARPA research community a number of special systems. Many
of these exist on your own campus. As we become familiar with
thesesystems, XEOS will serve as a facilitator and will make
certain that potential 1100 users are familiar with interface
software that exists or is under development. To the best of
our knowledge, the following systems have been or are being
connected to the 3M bps Ethernet: KI-10/TENEX, KL-10/TENEX,
2020/TOPS-20, 2050/2060/TOPS-20, and VAX/UNIX. XEOS will
facilitate distribution of the Stanford-modified PUP software.
As you know, this software runs under TENEX and TOPS-20 and
enables DEC KA-10, KI-10, KL-10, and DEC 2020 to act as file
server to the 1100.
The dissemination and distribution of information would
be greatly enhanced by formation of an 1100 users group. XEOS
is prepared to assist in the organization of such a group.
XEOS plans to make available the necessary hardware and
software to connect the 1100 system to the 10 M bps Ethernet,
thus providing access to the Xerox 8000 Network System. We
are also investigating the feasibility of an internet gateway.
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system is five
times faster than it was a year ago and significant further
improvement is expected.
Since the 1100 is a powerful, flexible machine, it can
be expanded in a number of ways: physical memory from 576K
words (1.15 M Bytes) to 768K words (1.54 M Bytes), virtual
address space from 4M to 16M words, and increased local disk
storage capacity. Furthermore, there is sufficient cabinet
space to add special functions that might be needed by certain
customers: floating point arithmetic, color display interface,
image processing, and other special logic, etc. XEOS is inves-
tigating the feasibility of adding to the 1100 system: color
display, low cost bit map display, large capacity file server,
and 5700 electronic printing system. The architecture, I/O
structure, and bandwidth of the 1100 make it the ideal machine
for dedicated applications in the research and scientific
environment.
In addition to Interlisp, XEOS is planning to implement
Smalltalk on the 1100. The schedule is yet to be determined.
As a key ingredient of the overall 1100 program, it is
planned to release a version of Interlisp on the Star processor
after January 1, 1983. This will provide Interlisp to future
users on a very cost-effective basis.
I trust, Ed, that this information will enable you and
others to plan system expansion."
-----
Subject: "mundane" systems
∂26-Jul-81 1553 Jan Walker <JWALKER at BBNA> ''mundane'' systems
Date: Saturday, 25 July 1981 15:59-EDT
From: Jan Walker <JWALKER at BBNA>
To: WorkS at AI
I have to voice my strong support of Joe in his message against
"mundane" systems. The original message advocating mundane
systems used an analogy of a car -- you choose a boring automatic
because you don't care what wonderful things you might be able to
do with a standard transmission. Let's point out a few things
that make this analogy somewhat less applicable to the current
case (system/software design).
Notice that with the kind of technology people are accustomed to,
once you choose one (automatic), you can't have the other
(standard). (This can lead people into defending their choices
with more reasons than they originally had for making the choice.
Some psychologists talk about related phenomena under "cognitive
dissonance".) With the kind of technology we use, you can either
follow the same design philosophy -- make things in a limited
number of flavors and make people choose -- or you can design to
support redesign by the purchaser. Surely with the flexibility
of computers behind us, we can do at least as well as the kludge
in the car that chooses 4, 6, or 8 cylinders depending on load,
mileage goals, or whatever.
People don't like the illusion of choice nearly as much as they
like having the choice. The reason that so far we don't find
ordinary people looking for software modifications is that they
don't expect to be able to have them. (The old technology of
course has molded people's expectations about the new one.)
While I am on the car analogy... I hear a lot about providing
systems for people who want to be able to use a computer without
any training or practice. How many people do you know who wanted
to just jump in and drive a car without any training or practice?
(Not many!) Why do you suppose that difference exists? Consider
that a car has one primary purpose -- transportation. They all
have standard components and operating procedures. Even people
who have never driven know a lot about cars, for example, that
they have a little slot where you put a key and turn it in order
to start the engine. The point is that cars are simpler in
purpose and operation than computers, yet people don't expect to
just hop in and drive away until they know from cars. Maybe the
real lessons in this analogy come from considering training,
learning, and transfer issues.
The ideal way to provide software is to offer something that a
new user who knows about the application of the software (for
example, editing, drawing) can start using it with the help of a
good summary and maybe 15 minutes of explanation. The next
hurdle to pass is in discovering that things can in fact be
changed. A well-designed and documented program helps you make
this discovery and then provides good support tools to help you
find out what it is possible to change and how best to do it.
Jan
(JWalker@BBNA)
Subject: re: REM' s remarks on Global configurations
∂29-Jul-81 0907 Farrell at PARC-MAXC re: REM' s remarks on Global configurations
Date: 27 Jul 1981 11:47 PDT
From: Farrell at PARC-MAXC
To: REM at MIT-MC
cc: WorkS at MIT-AI, Farrell
In places, you simply misunderstood / misstated Bruce Hamilton's
position; in others, your positions are new (and interesting).
Corrections/clarifications:
Bruce demanded 56 Kbaud, not Mbaud. The 3 orders of magnitude
easily cross the frontier of available technology.
There are a number of "centralized" services besides
archiving/library: printing, mail distribution, gateways to other
systems & nets, to name 3. Note also that file storage is a com-
munication mechanism as much as a receptacle -- it is easier (&
more efficient) to store a large object in a commonly accessible
container or two, & pass a pointer, than to ensure direct transfer
from the source to each destination.
Your framework of workstation & centralized facilities is impoverished
(and I believe not justified by Hamilton's discussion): there is no
requirement that facilities be centralized; in particular, there are
good reasons for distributing different services (functions) onto
different servers (machines), and for replicating and distributing
servers geographically (minimize communication, limit loss, provide
convenient user access). Even with most communications involving a
server on at least one end, this distribution still requires high
capacity in the underlying medium. When the net (or whatever) must
also support frequent reconfiguration, you may as well provide that
bandwidth to everyone, so you don't have to decide in advance which
ones are going to be servers.
Probably derived from your workstation/centralized facilities
dichotomy (and maybe a little from Bruce's remarks), I think
you put too much emphasis on network (i.e. communications medium)
failures, when server failures are more of a problem. I derive
this from my experience over 8 years now with two networks, ARPAnet
& 3mb Ethernet. In each, I can recall 1 occasion when I noticed
thenet was down -- that is, that NOBODY could use the net. (I
know the ARPAnet went down regularly for new releases of the IMP
software, and I've heard of outages on both which I didn't happen
to hit. . .) Contrast this to many occasions when I couldn't get
at MACSYMA, or the Datacomputer, or print on Clover, or wasn't
getting my mail, or . . . . Few of us are so single-minded that
we can't work around loss of a server (which needen't even deny
us the service -- e.g. redundant printing/file/mail servers).
Your super-automatic archive to file server has much to recommend
it; two possible drawbacks are that data on my local disk is less
accessible than anything that has hit the net or been stored in
a file server (clearly, holes that should be fixed; but while
they're there . . . ), and such a catholic approach may require
more resources than justified (I suspect workstation time and
file server space are more critical than communications
capacity).
Jerry Farrell
Subject: apollo s/w release 2.0
∂29-Jul-81 0941 Andy.VanDam at CMU-10A apollo s/w release 2.0
Date: 29 July 1981 1028-EDT (Wednesday)
From: Andy.VanDam at CMU-10A
To: works at mit-ai
CC: Andy.VanDam at CMU-10A
Message-Id: <29Jul81 102809 AD50@CMU-10A>
The second release of Apollo DOMAIN s/w happened as promised in
mid-July. Performance has improved greatly - cmd startup time
is (usually) instantaneous, cmds execute much faster (cp, for
example, is about 25% faster both for copying local-local and
over the network), and most known bufs have been fixed. Func-
tionality has also increase (although there's still plenty of
room for more increases...): there are a few new s/w tool cmds
(such as Unix-like sed, grep, macro processor), the display
manager (i.e., their full-screen editor) has cut, paste,
searches, and the user can access the display memory and
bit-mover.
In response to a query from the other week, yes, the Apollo
Users Workshop did take place at Brown on 21-22 June. Users
and potential users from: USAF Geophysics Lab, Bell Labs,
CaslTech, CCA, Computer Techniques, Cornell, Daniel Wagner,
AHarvard, IBM Cambridge, MIT, Mentor Graphics, Schlumberger
Well Services, UMass - Boston, UPenn, and Yale briefly
described what they are planning to do with their apollo's,
Dave Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth, Kim
McCall from PARC-LRG talked about implementing Smalltalk
on an Apollo, and workshops were held about porting unix,
graphics, lisp, and tex.
The general reaction of the participants was that Apollo is
listening to its user community, which at present is primarily
CS R&D/academia. Apollo looks like it will be around for quite
some time, and will be emphasizing mktg for commericial world
(though they promise not to forget us CSers). Presently, the
h/w is quite solid, and most agree that the s/w is still about
a year away from being there.
Details of Apollo's plans discussed at the mtg are confidential.
Contact me for a list of participants (w/ phone, arpa addreesses)
that can be contacted for more direct info, or for a short (3
sentence) summary of what the participants said they'd be doing
with the Apollos.
Marc Brown
Subject: Mouse Guts
∂29-Jul-81 1023 Eric K. Olson <OLSON at DEC-MARLBORO> Mouse Guts
Date: 28 Jul 1981 0927-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11747606017.5.545.5372 at DEC-MARLBORO>
Conglomeration of responses to "How does a mouse work?":
Currently, a mouse is a small box with a fairly large (1-2 cm
diam.) ball bearing captivated so a fraction of it lies outside
the bottom of the box. As the box is rolled around, two wheels
positioned perpendicular to one another pick off the rotational
motion of the ball in their plane only (they slip in all other
planes). Hence we get two rotational motions, one for each
component of the two-dimensional motion of the mouse.
The direction and (over time) speed of the rotation shafts are
measured by disks attached to the shafts encoded with a gray
code, and read either photoelectrically (via led and phototran-
sistor) or mechanically (via brushes). The grey code output
might look like 00 01 11 10 00 going one way and 00 10 11 01 00
going the other, so we can tell the difference in direction.
Some historical information about mice, according to Bill Barns:
The mouse as originally invented by Doug Engelbart and Bill
English and patented by them (rights assigned to their employer
at the time, Stanford Research Institute (now SRI International))
consists of two high precision potentiometers connected mechan-
ically to metal wheels with rather sharp edges, approximately 2
inches in diameter, and set at right angles to each other as close
as possible without touching. [This seems a kludgey way to get
this motion, because the pots would "pin" occasionally, even if
they were 20-or-more-turn.] The pots are mounted on a metal base
plate to which is attached a bracket. On the bracket there are
(in the original, and still popular configuration) three switches
which are triggered by buttons about 5/16 inch diameter [8 mm]
which rest upon spring metal fingers attached also to the bracket.
The bottom of the metal finger rests on the momentary-contact
actuator of the microswitch. This arrangement puts some "click"
into the feel. The switches typically are SPST with a common
ground so that for a three button mouse there are four wires for
the switches and one wire for the non-ground side of each pot - 6
total. The mouse wheel voltages are fed into an analog->digital
converter of about 10 to 12 bit resolution and at appropriate
times, some logic samples the digital value and does the
appropriate thing.
Engelbart lives on at Tymshare, and English went to Xerox PARC
and gave birth to Alto etc., (not sure if he's still there).
Bill estimates the invention of the mouse between 1962 and 1967,
and *guesses* 1963/4.
By the way, I got several warnings about suits, patents that I
musn't breach, etc, which I condense below:
Patents to SRI and Xerox apply to a number of features of the
design. The Englebart/English Patent is probably still in
force, and it covers both digital and analog mice. [I was
warned to check the patents before building my own. I really
don't think that building your own personal whatever falls
under patent laws (unless possibly if you sell it).]
Thanks to Jerry Farrell (Farrell at PARC-MAXC), Bill Barns
(Barns at OFFICE), Craig Everhart (Craig Everhart at CMU-10A),
and Steven Kirsck (SK at MIT-MC).
-----
Subject: Big AND Small
∂31-Jul-81 0459 Rivanciw at Darcom-HQ Big AND Small
Date: 30 Jul 81 8:37:19-EDT (Thu)
From: Rivanciw at Darcom-HQ
To: works at Mit-Ai
Via: Darcom-HQ; 30 Jul 81 8:49-EDT
In reading the debates pro and con on big systems and little
systems, where big systems are large mainframes and little
systems are personal workstations it seems that the best of
both worlds would be architectures for office automation that
encompass both. Let me illustrate how we have attempted to
incorporate both worlds in our OA plans.
DARCOM has a DEC 10 (DARCOM-KA) on the ARPANET which it uses
to provide electronic mail and other OA services to a broad
community of users throughout the command (the command is all
over this country). Access is via ARPANET. Advantages here
are that for a relatively inexpensive yearly charge a remotely
located single user can obtain OA service with a communications
capability as powerful as the ARPANET. This service is in such
demand that we cannot supply services in large enough quantities
(thus the DEC 10 will soon be replaced with a couple of 11/780s
to provide more services).
One level down (in computer size) DARCOM uses what it calls
LARGE CLUSTER machines. These are mini computers (DEC 11/70
size) which provide LOCAL OA services to 100-150 users. Long-
haul communications is accomplished via the RELAY computer
to the ARPANET (or dial-up communication channel to non-ARPA
computers). These Large Clusters are not hosts on the ARPANET.
The computer I am working on right now is one of these large
clusters. This message is routed to the RELAY computer which
routes it to the ARPANET for delivery.
The next level down SMALL CLUSTER. The small cluster is a
general purpose micro computer (like the ONYX or "C" Machine).
The Small Cluster services 8-30 users. It communicates with
the LARGE CLUSTER for large file storage and backup. Communi-
cations on the small cluster are handled via the large cluster
or the RELAY.
The lowest level is the personal workstation (one user). We
haven't gotten there yet in large scale implementation. Yes,
we have a lot of personal workstations around but have not
yet incorporated them into our large scale implementation
plans yet.
This architecture is used for economies of scale and incremental
investment on behalf of the user. For example, let me paint
a typical scenario of one of DARCOM's subordinate commands or
activities just entering into the world of office automation:
The Commander or somebody at the command wants to try office
automation. Now they are unsure of its benefits so they don't
want to spend mucho money. The buy a mailbox on our DARCOM-KA
(LARGE MAINFRAME). With this mailbox they can experiment with
all the OA tools.
After a short while they want 5 or 10 other people at
their command or activity to get mailboxes so that they can
communicate via electronic mail. They buy more mailboxes
on the large mainframe.
Then it is determined that office automation is good for the
command. They make large scale plans to provide OA services to
100, or 200, or 300, or how-ever-many prople. At this point the
economies of scale move towards the LARGE CLUSTER machine. With
a large cluster installed locally, the command is essentially
running their own OA.
But soon they find that more and more users are demanding service.
Enter the small cluster. As one division goes from one or two
users (who were getting OA services on the large cluster) to a
demand to provide services to 8 or 10 people in that particular
division, a micro computer is installed in the division to provide
those services (and offset the demand on the large cluster). An
example of this implementation is DARCOM Headquarters. We began
by buying accounts on the big DARCOM-KA (large mainframe). When
demand grew to 60 users we brought a large cluster into the
building. The number of users on the large cluster grew from 60
last Oct to 210 as of last week. We now have some 20 micros on
order. These micros will service 8-10 user each so we now supply
services to an additional 160-200 individuals. As folks move
off the large cluster to the small cluster there are more folks
wainting in line behind them for accounts on the large cluster.
This multi-level (of size?) architecture seems to be working
pretty well for providing services to our command.
Randy
Subject: Keystroke Monitoring
∂31-Jul-81 0721 Eric K. Olson <OLSON at DEC-MARLBORO> Keystroke Monitoring
Date: 30 Jul 1981 0128-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: TAW at SU-AI
cc: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11748043074.24.545.10627 at DEC-MARLBORO>
As I said in a message to Human-Nets (once again, the two lists are
discussing similar things), I think a reasonably valid statistic
for keystroke monitors indicating performance of the secretary is
keystrokes per character in output document. This way the typist
that makes no errors will have fewer keystrokes (lower, better
score) than the typist that makes lots of errors to produce the
same document. This also takes care of the problem of a secretary
idling by typing jkl;jkl;jkl;jkl;jkl;. I personally do not condone
the use of keystroke monitors to monitor performance (I think that
management should not even be told the statistic is available).
This all assumes of course that the monitor is on a word processing
system used primarily for word processing. Programmers shouldn't
be subjected to keystroke monitors (I am a little more vehement
about this; it hits home), and fortunately the statistic is harder
to generate for programmers.
-Eric
-----
Subject: WorkS Digest V1 #1
∂03-Aug-81 0629 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #1
Date: 3 AUG 1981 0849-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 3 Aug 1981 Volume 1 : Issue 1
Today's Topics:
Administrivia - Welcome, Workstations - Harvard Apollo Experience,
Polls - OA System Developers & WorkS Census
----------------------------------------------------------------------
Date: 1 Aug 1981 (Saturday) 0956-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Administrivia - Welcome to the WorkS Digest
To All WorkS readers:
As you have probably guessed, we are making the workstation
discussion list into a digest. It shall be a daily digest.
One of the few things we are looking for is a moderator. If
you have the (a) interest, (b) the time, (c) easy and proper
access to the Network (MIT computers), and (d) the patience,
please drop a message in WORKS-REQUEST@MIT-AI.
Henry Dreifus
------------------------------
Date: 2 Aug 1981 (Sunday) 1422-EST
From: BUSH at HARV-10
Subject: Four Months with Two Apollos
We have had two Apollos at Harvard for about four months
now, and I have a few personal observations to contribute from
my experience with them.
The best way to describe them is as a state-of-the-art
product, with the emphasis on product. The Apollo seems to be
the best large-micro-based system available with a bit-mapped
display, Winchester disk, and high-speed local network. Since
it started a little over a year ago Apollo Computer has managed
to produce a very solid piece of hardware, and quite a bit of
software. We have had no trouble with the hardware, and the
software, while poorly documented and a tad flakey (we are a
beta test site), has been basically usable. The network file
system works, and, on our small network, file access is not
appreciably slower for remote files.
The Apollo is not, however, a state-of-the-art tool for
computer science research, nor does it claim to be. It is not
a Dorado nor a Star-with-Mesa. A lot of the folks at Apollo
came from Pr1me, and in order to produce a working, competitive
product, they built what they knew how to build for a market
they were familiar with (the engineering/scientific market).
The system was tuned for user programming in FORTRAN, not system
programming, with such things as interprocess communication and
software interrupts not supported. Now that its primary market
is academic, Apollo will put a number of these features in, but
system programming, and the kind of features it requires, are not
a fundamental target of the system software. The system also has
a rather unsophisticated human user interface. Some of this is
clearly a matter of time, but some things that I imagine people
at Xerox would consider basic, such as a mouse and non-confusing
windows, are not along yet. (The Apollo windows are confusing
because they are all full-screen width and bordered with a single
line, so it is difficult to determine which windows are on top.)
It seems that Apollo did not do a lot of research in designing
their product, but instead will be educated by their users.
Bill Bush
------------------------------
Date: 2 August 1981 11:34-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Results of Poll
Here are the results of the "Are you actively working on an
Office Automation system" poll. The results surprised me very
much. Here are some of the numbers:
Responses 32
Working on a system 23
Not working 9
The "Not Working" column also contains responses from people
indicating that they were simply implementing OA functionality
on their home systems (e.g. not for commercial sale/distribution).
That was a value judgement on my part and may not be valid.
There were many very interesting responses but in order to keep
this message short I will exclude most. Two immediately caught
my eye and are reproduced here:
------------------------------
Date: 18 Jul 1981 13:22 PDT
From: XXXXX at PARC-MAXC
...
The Xerox redistribution list for WorkS currently contains
57 members. I don't know exactly how many of them (us) are
actually working on workstation design or implementation,
but I suspect about 75-80% are, in one capacity or another.
-- XXX
------------------------------
Date: 16 Jul 1981 21:05 PDT
From: Kimball at PARC-MAXC
Nearly everyone from Xerox on list, as you surmised...
Ralph Kimball
Manager CUSP Development, Xerox
------------------------------
In the first note I was asked not to reveal the sender. Based
on the numbers in the first message, we could probably skew
the results, but that is up to you.
As mentioned earlier, the raw responses are in the file
USERS3;LLOYD WORKS on the MIT-AI machine.
Brian
P.S. I too am actively working on a system. I am managing the
software development for the M/A-Com Executive Management
System (MEMS) which uses the Convergent Technologies
hardware.
B
------------------------------
Date: 3 August 1981 08:00-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Subject: WorkS Census II
On 25 June, Randy Rivanciw proposed a census to give everyone
who wished, a chance to briefly describe who they are and what
their professional interest in personal workstations is. We
already have a variety of responses. However, a large number
of people have been added to the list since 25 June. Now that
the list population has stabilized, we want to give everyone a
chance to participate before making the results available.
If you would like to participate in this census and have not
already responded, please forward a brief description of your
interests in personal workstations to WORKS-CENSUS@MIT-AI.
Please do so promptly however, as we will make the results
available early next week.
Enjoy,
Roger
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #3
∂09-Aug-81 1202 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #3
Date: 9 AUG 1981 1418-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sun, 9 Aug 1981 Volume 1 : Issue 3
Today's Topics:
Query - Smalltalk
----------------------------------------------------------------------
Date: 6 Aug 1981 1002-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
Subject: Smalltalk systems
What-all systems support smalltalk? Are there dialects of
smalltalk, as there are of FORTH? Do smalltalk systems come
without the graphics-oriented user interface?
Bob
------------------------------
Date: 9 August 1981 12:00-EDT
From: "The Moderator" <Duffey at MIT-AI>
Subject: Archived information about Smalltalk
Smalltalk has come up briefly in several earlier WorkS discussions.
For your convenience, a summary transcript of the archived material
on Smalltalk is included below. Complete copies of these messages
are available upon request from the archives.
-- RDD
... LRG, a group within PARC, has licensed Smalltalk-80 (the
only Xerox-authorized version of Smalltalk to be released)
to a number of micro- and mini-computer manufacturers. The
release consists of detailed specifications for the machine-
dependent kernel, plus a mag tape containing the rest of the
system (windows, editor, compiler, file system, etc., etc.)
Several of these manufacturers have made excellent progress
on implementing the system, to the point of having windows
appear on their displays. I can't comment on the specific
list of manufacturers, since we prefer to let them make
their own announcements. ... and we are currently working
out ways to license the system to manufacturers (and univer-
sities) beyond the original group. I can't comment on the
availability of Smalltalk for the Star, except to say that
the Star hardware is definitely powerful enough to support
Smalltalk.
-- <Deutsch at PARC-MAXC>
Smalltalk IS being released by PARC this summer. There
was a big presentation on the subject at this year's NCC.
Apple, DEC, HP and other companies are doing research
into implementing it on their machines. (In fact, one of
the primary Smalltalk implementors, Larry Tesler, is now
at Apple and was one of the speakers at NCC.) A huge
article on the subject will appear in the August issue
of BYTE.
The deal is that PARC gives you an "image" file on a
tape, which contains all of Smalltalk ready to run. To
run it, you have to implement an interpreter on your
machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
-- Ron Newman <NEWMAN.ES@PARC-MAXC>
... Xerox intends to release a book on Smalltalk called
Smalltalk 80. This version of Smalltalk is intended to be
easily portable. There was some discussion within Xerox
legal about whether the Smalltalk virtual image would be
released. But the book which describes the interpreter
plus the virtual image would result in a very easily
portable language.
One could then port it to the machine of your choice,
including the STAR, assuming that you could PROGRAM
the STAR. When MESA gets released you will be able to
implement it in that: but a better place is microcode.
I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation)
for Smalltalk.
-- Michael <mike at RAND-UNIX>
... Also, XEROX is now putting up Smalltalk on the Star,
for internal use. I have no idea, and I suppose neither
does XEROX, if they'll ever release it.
-- Chris Ryland <RYLAND at SRI-KL>
Ed Feigenbaum received the following message from Mr. R.E.
Bomeisler, Marketing Manager for Xerox EOS, in response
to repeated requests for more information about Dolphins
necessary for planning acquisitions. ...
*********************************************
"In our telephone discussion, Ed, you indicated that
Xerox was not providing you and potential users with
enough information to assist you in designing your
networks and planning for future growth. I would like
to apprise you of the steps we have taken at XEOS to
fill the information gap.
...
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system
is five times faster than it was a year ago and signi-
ficant further improvement is expected.
...
In addition to Interlisp, XEOS is planning to
implement Smalltalk on the 1100. The schedule is
yet to be determined.
As a key ingredient of the overall 1100 program,
it is planned to release a version of Interlisp on
the Star processor after January 1, 1983. This will
provide Interlisp to future users on a very cost-
effective basis.
...
********************************************
-- Tom R. <RINDFLEISCH@SUMEX-AIM>,
forwarded to WorkS by <Geoff at SRI-CSL>
In response to a query from the other week, yes, the
Apollo Users Workshop did take place at Brown on 21-22
June. Users and potential users ... briefly described
what they are planning to do with their apollo's, Dave
Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth,
Kim McCall from PARC-LRG talked about implementing
Smalltalk on an Apollo, and workshops were held about
porting unix, graphics, lisp, and tex. ...
Details of Apollo's plans discussed at the mtg are
confidential. Contact me for a list of participants
(w/phone, arpa addresses) that can be contacted for
more direct info, or for a short (3 sentence) summary
of what the participants said they'd be doing with
the Apollos.
-- Marc Brown in care of <Andy.VanDam at CMU-10A>
The August issue of BYTE is devoted to Smalltalk. The
good folks at Xerox PARC contributed quite a bit to the
issue. I'll refrain from further comment till I've read
the thing.
-- <decvax!duke!unc!smb at Berkeley>
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #4
∂12-Aug-81 0247 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #4
Date: 12 AUG 1981 0522-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Wed, 12 Aug 1981 Volume 1 : Issue 4
Today's Topics:
Query - Micro benchmarks, Reply - Smalltalk
----------------------------------------------------------------------
Date: 11 Aug 1981 1917-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks
Has anyone performed, or seen documentation concerning,
benchmark comparisons of micros commonly used in
workstations/personal computers? Specifically, the Z80,
8086, M68000, LSI-11/2, LSI-11/23. Please send replies
directly to me and I will compile the results and submit
to works. Thanks. -Steve
------------------------------
Date: 11 Aug 1981 08:41 PDT
From: Adele at PARC-MAXC
Subject: Xerox Smalltalk
Various messages have been sent on this distribution list
relative to the release of the Xerox Smalltalk-80 (tm) system.
The messages in general are inaccurate or not complete because
plans for general distribution are not yet set. At this time,
for individuals to obtain information relative to their own
needs, you can contact me directly via telephone or
non-electronic mail.
Adele Goldberg
Xerox PARC
Learning Research Group
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #5
∂13-Aug-81 0624 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #5
Date: 13 AUG 1981 0740-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 13 Aug 1981 Volume 1 : Issue 5
Today's Topics:
Reply - Micro Benchmarks, FYI - IBM's Personal Computer
----------------------------------------------------------------------
Date: 12 Aug 1981 2246-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks Results
Many thanks to those who responded to the micro benchmark query.
I have summarized the benchmarks reported in the April 1/81 issue
of EDN, but the article should be read for details concerning the
benchmarks. It appears that the 68000 is the hands down winner,
unless you need floating point processing and can't wait for the
chip (floating point benchmarks were not performed in the report).
I have appended messages (edited to remove redundancy) from those
who responded to the query.
Benchmark tests were compiled at CMU in 1976, and coded by each
manufacturer.
MICRO | LSI-11/23 | 8086 | 68000 | Z8000 |
-------------+------------+-------------+-------------+-------------+
BENCHMARK | Code| Time | Code| Time | Code| Time | Code| Time |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O Interrupt| 20 | 114 | 55 | 126 | 24 | 33 | 18 | 42 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O w/FIFO | 86 | 1196 | 85 | 348 | 118 | 390 | 106 | 436 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Char. Search | 76 | 996 | 70 | 193 | 44 | 244 | 66 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Ops | 70 | 799 | 46 | 122 | 36 | 70 | 44 | 123 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Linked List | 138 | 592 | 94 | - | 106 | 153 | 96 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Quicksort | - | - | 347 |1.2E↑5 | 266 |3.3E↑4 | 386 |1.2E↑5 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Matrix | 152 | 1517 | 88 | 820 | 74 | 368 | 110 | 646 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Clock time: LSI-11/23 = 3.3 MHz
8086 = 10.0 MHz
68000 = 10.0 MHz
Z8000 = 6.0 MHz
----------------------------------------------------------------------
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Micro Benchmarks
ComputerWorld has been running a series of benchmark articles
over the last six months or more and periodically publish
accumulated summaries of the results in each category.
--Frank
----------------------------------------------------------------------
From: Nowicki at PARC-MAXC
Subject: Re: WorkS Digest V1 #4
Forest Baskett has the famous "Baskett Benchmark" that has been
run on machines like Dorados, Dolphins, Altos, 10s, 20s, Vaxen,
and MC68000 in both C, "hacked" C and Pascal. The results
are very informative. I would like to see the results on other
microcomputers. By the way, we get almost 40% VAX/780 performance
on the 8 MHz 68000 in this test, which is a small, integer only,
compute bound puzzle solver.
-- Bill
----------------------------------------------------------------------
From: CAIN at SRI-AI
Subject: Micro benchmarks
The April 1, 1981 issue of EDN has a number of benchmarks
between the LSI-11/23, the 68000, the Z8000, and the 8086.
They are taken from a more complete study done at CMU which
I was hoping to find one of these days.
Since these benchmarks omitted floating point tests, I
performed a couple informal ones on a 68000 with Doug Beck
here at SRI. To do 10000 iterations of a floating point add,
subtract, multiply, and divide took 71 seconds (implying 1.75
milliseconds per operation) using Whitesmith's C compiler and
104 seconds using Motorola's PASCAL compiler.
When talking to Motorola about this sluggish performance,
they mentioned that the 68000 has a fast floating point PROM
in development which has done floating-point multiplications
(in software!) in 35 micro seconds. This compares very well
with the LSI-11/23's floating point hardware times.
Also C makes all floating point numbers to double precision
before doing the implied operation, meaning much of that 71
seconds was devoted in going "float-to-double" and
"double-to-float". According to my calculations, the 68000
is capable of that 35 microsecond time easily (roughly 100
to 150 clock states would be required), and since it has the
most support (cross compilers on the VAX, etc), I think it is
the preferable chip. It is promised that the floating-point
support will be built onto the chip mask so that some new
instructions will manipulate floating point numbers directly.
I am seriously weighing the choice of VAX vs 68000 for a new
project (where cost may outweigh the greater power of the VAX).
... Ron
----------------------------------------------------------------------
------------------------------
Date: 12 Aug 1981 2130-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
Subject: New IBM Personal Computer
Business Day : IBM Personal Computer
By ANDREW POLLACK
c. 1981 N.Y. Times News Service
NEW YORK - The International Business Machines Corp., the
giant of the computer industry, is thinking smaller: Wednesday
it introduced a personal desk-top computer for use at home,
in schools and in business.
Although the announcement had been expected for months,
it still sent reverberations through the industry.
Besides representing a dramatic change in image for IBM and
marking its entry into consumer electronics, the endorsement
of personal machines by a company whose name is practically
synonymous with computers is expected to stimulate the growth
of the business.
And IBM could pose the stiffest challenge yet to Apple
Computer Inc. and the Tandy Corp.'s Radio Shack division,
the current leading vendors.
"It's one of the most important announcements we've seen
in the industry," said Christopher Morgan, editor in chief of
Byte, a personal computer magazine.
"People will now know that personal computers are not a fad
or a flash in the pan," said Michael McConnell, executive vice
president of Computerland, a chain of a retail stores that will
market the new IBM products.
The price of the machines will range from $1,565, for a
simple system that will require users to provide their own
television screens and cassette tapes, to more than $6,000 for
the most elaborate versions. In addition to Computerland, the
line will be sold through several new business-machine stores
being started by Sears, Roebuck & Co., by IBM's own three retail
stores and directly by IBM to large corporations.
By most accounts of analysts and others connected with
the personal computer business, IBM's machine is impressive
technologically, not because of any single breakthrough, but
because of a combination of good features and sound engineering.
The new model uses a microprocessor capable of handling
16 bits of information at a time, which will permit the machine
to handle data more quickly and perform more complex tasks than
most other personal computers, which have 8-bit microprocessors.
The machine, depending on the model, can store 16,000 to more
that 260,000 characters in its memory.
But analysts disagreed on whether the price would be low
enough to knock Apple or Tandy out of the ring.
In Fort Worth, Garland P. Asher, chief of financial planning
for Tandy, said he was relieved in two ways. "I'm relieved that
whatever they were going to do, they finally did it," he said.
"I'm certainly relieved at the pricing. They haven't introduced
anything that's going to rewrite the ground rules."
Comparing prices is difficult, however, because the machines
come in different configurations and are not directly comparable.
McConnell, of Computerland, which sells both Apple machines and
the IBM home computer, said that in some typical configurations
the IBM machine was several hundred dollars more expensive than
the Apple II, Apple's popular brand. Yet the IBM device is
slightly less expensive than a typical configuration of the
newer, more powerful Apple III.
Other factors such as the availability of programs for the
computer and marketing are equally important, analysts said. IBM
will have fewer retail outlets and fewer programs initially than
Apple and Radio Shack. Yet, Aaron Goldberg, an analyst with the
International Data Corp., a Framingham, Mass., consulting firm,
said IBM's direct sales staff could be a potent force in selling
to leading industrial companies, who might buy dozens of desk-top
computers at a time.
Chances are, there will be room for all the companies, many
analysts believe. The personal computer market is growing
explosively, although accurate figures are hard to get because
there is no clear distinction between home computers, personal
computers for other users and desk-top computers designed for
business use.
International Data estimates that 327,000 desk-top computers,
ranging in price from several hundred dollars to $20,000, were
sold in the United States in 1980, and projects that this total
will increase to 1.3 million by 1985. In dollar volume, the
market is expected to grow from $2.4 billion last year to $9
billion in1985.
According to estimates by International Data and others,
there are approximately a million personal computers in use,
with the largest application being for business and professional
uses. The home and education markets are still small, but are
expected to explode.
When the new computer becomes available in October, the
program offerings will include Visicalc, a popular business
forecasting program; three business and accounting packages
by Peachtree Software; Easywriter, a word-processing package,
and Microsoft Adventure, a fantasy game. The software,
however, will sell in some cases for about twice the price
of the equivalent programs sold for use on other machines.
IBM is also allowing anyone else who wants to do so to
write programs for the IBM machine, which the company would
evaluate. If the programs were accepted for marketing, the
writer would be paid a royalty on sales of the program.
A veritable cottage industry of computer buffs has sprung
up to write programs for other personal computers, and the
abundance of such home-grown programs is largely responsible
for the market strength of the Apple and Tandy computers.
IBM also said it would make its computers nearly compatible
with some other home computers, so programs written for those
machines could be transferred to the IBM model.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #6
∂14-Aug-81 1101 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #6
Date: 14 AUG 1981 1025-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Fri, 14 Aug 1981 Volume 4 : Issue 6
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 13 Aug 1981 1159-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
IBM announced its new 8080 based personal computer yesterday.
The prices range from $1500 to $6000 (approx.). It seems
that the system has color graphics. Does anyone has any
more details on the system? What is the OS on the system
and what are options?
Willie
------------------------------
Date: 13 Aug 1981 0813-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmark Units
The units in the benchmark chart sent Aug 12 were bytes for
code, and microseconds for execution time. Sorry for the
omission. -Steve
------------------------------
Date: 14 Aug 1981 0448-PDT
From: SCHIFFMAN at SRI-KL
Subject: Benchmarking new Micros
I forget where I first heard it said that benchmarking was Advanced
Lying With Statistics....
I looked rather carefully at the EDN benchmarks when they first
came out. I took these more seriously than usual because:
They were in Assembly language; therefore they measure
programmer skill plus machine performance, as opposed to
higher-level-language benchmarks which measure programmer
skill plus machine performance plus compiler quality.
(Worse yet are benchmarks written in different languages
for different machines which throw "language- quality"
into the mix... or benchmarks running on time-sharing
systems that end up measuring scheduler fairness and
disk performance.)
They were written by employees of the respective manu-
facturers who were likely to be skilled with the given
architecture. This also removes the possibility of
unfair advantage given due to hidden prejudices.
A reasonable coverage of routine types were made that
collectively might represent "general performance".
(Including interrupt service routines was a good move,
for example.)
Nevertheless, the benchmarks were about as useless as benchmarks
usually are!
To pick some specific nits--
Although there was ONE environmental parameter supplied (the
clock speed for the given processor) there was no mention of
what memory performance is required to run at that speed
without wait states. I believe it is the case that a 10Mhz
8086 can run with memory much slower (and therefore cheaper)
than a 10MHz 68000. Nor is it mentioned what the availability
of the part is at that clock rate. Did you know that a 10MHz
8086 is $200 cheaper than a 10Mhz 68000? Maybe if you paid
that kind of money to Intel they would sell you a 16MHz part!
The benchmark specifications had loopholes in them which
were taken (quite understandably) to differing advantage.
For example (as best as I can remember) the interrupt
service benchmark did not specify that context had to be
completely saved. The Intel programmers went ahead and
saved all registers anyway (a reasonable thing for a
service routine to do). The programmers for the other
machines only saved the minimal context necessary to meet
the specification.
So much for GOOD benchmarks!
Any yet one often hears that "CPU X is 20% faster than CPU Y"
based on even less careful comparisons.
{BTW, I'm planning to use the 68000 in my next system. And
I do think that is much faster than the 8086 for the things
I want to do. But it's very likely a bit slower (for what
I want) than the Z8000. Don't forget that there are other
reasons for choosing a CPU than how fast it goes.}
Most CPU designers, when pressed, will agree that there is no
reasonable way to collect a small set of general metrics that
will characterize machine performance. To find the fastest
among several computers "in the same performance class" can
only be done by carefully attempting to model the application
for which the machine is to be used. If you are lucky, this
can be as simple as designing your program and coding the
inner loops for each machine to be considered. If you're not
so lucky, you might spend a year building a workload simulator
and still not know how different things will be if you get a
different disk controller.
Doing it right, of course, can be very hard. It's much easier
to refer to a list of how long a quicksort of 100 items takes
for every machine ever invented.
Joseph Weisenbaum (in "Computer Power and Human Reason") tells of
the story about the drunk repeatedly walking around a lamp post
at night. A passing policeman asks him for an explanation. The
drunk replies that he lost his keys--
Cop: "Oh, so you lost them under the lamp post?"
Drunk: "Naw, lost 'em over there." (Waving at the distant
darkness).
Cop: "So why look for them under the lamp?"
Drunk: "Silly! 'Cause the light's so much better here!"
-Allan
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #7
15-Aug-81 1143 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #7
Date: 15 AUG 1981 1355-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sat, 15 Aug 1981 Volume 1 : Issue 7
Today's Topics:
Micro Benchmarks
----------------------------------------------------------------------
Date: 14 Aug 1981 15:28 EDT
From: Marshall.WBST at PARC-MAXC
Subject: Micro Benchmarks
A salesman from Intel was here this week and said that EDN has
retracted its benchmarks and will run another set. He said that
the new numbers show the 8086 only 10-15% slower than the 68000.
He said the retraction would be in the next issue.
Sidney Marshall - Rochester N.Y.
------------------------------
Date: 14 Aug 1981 11:36 PDT
From: Kosower at PARC-MAXC
Subject: Re: Benchmarking new Micros
Worse yet, benchmarks can be doubly deceiving, since they
may induce you to choose a micro for all the wrong reasons.
Unless you have a very specific application in mind, or
unless you plan to design and build your own operating system
from scratch, software development facilities, system quality,
and especially user interface quality are extremely important.
A Dorado, for example, may run faster than greased lightning,
but it would be about as useful as an F-15 powered by turboprop
engines if it had IBM-quality software running on it. After
all, most of us do not want to write reams and reams of code
in some J-random processor's assembly language (more so if it's
microcodable); so quality of the high-level language available
and quality of the compiler ARE important. Furthermore, most
applications change, and even with changes, their lifetime is
limited, so that other development facilities (editor, debugger,
etc.) are ALSO important. If it takes you 10 times longer to
write a program that will take 10 times longer to debug and will
eventually run 10 times slower, on processor A whose raw speed
is 10 times greater than that of processor B, which one would
you choose? Choosing B will save you time, to say nothing of
frustration, even though it is a "slower" processor. These are
not idle thoughts: an IBM 370/168 has tremendous raw speed, but
some of the cruftiest software ever written makes it seem slower
than the US Postal Service. Admittedly, almost all of the
software for micros such as the 8086 and 68000 is pretty awful,
but I still think it's worth keeping the above considerations
in mind. As Allan points out, just because something is easy
to measure does not mean it's useful or even meaningful.
David A. Kosower
------------------------------
Date: 14 August 1981 1832-EDT (Friday)
From: David.Lamb at CMU-10A
Subject: EDN benchmarks
Allan Schiffman may be right that the EDN benchmarks are
"about as useless as benchmarks usually are," but the MCF
(Military Computer Family) test specifications on which
they were supposed to be based *can* be used in a sensible
fashion to evaluate a computer architecture. The original
experiment design was set up at CMU with the co-operation
of one of the members of out Statistics department, who
designed the experiment to separate variance on the tests
into differences based on programmers, particular tests,
and the architecture itself. The notion was to see how
good the *architecture* (instruction set, visible registers,
etc.) was, rather than any particular implementation of the
architecture. Several different measurement scales were
set up. One measured the number of bytes need to encode
the programs, another measured the memory accesses needed
in an idealized implementation, and the third measured the
amount of data transferred between registers in the idealized
implementation. I'm a little disappointed that the tests are
being used now for a different purpose; it's not clear to me
that you want the same kinds of tests to do a comparison of
particular implementations of the architecture, as was the
case in the EDN tests.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #8
∂18-Aug-81 0804 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #8
Date: 18 AUG 1981 0811-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 18 Aug 1981 Volume 1 : Issue 8
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 17 Aug 1981 1331-PDT
From: Rubin at SRI-KL
Subject: IBM Personal Computer
For those of you who stay in touch by computer rather than paper
or radio: Here's the latest on the IBM PC. It's a three-piece
unit, VERY slim nice-looking keyboard, with basically the same
key layout as the 5250 series. The display looks cosmetically
the same as a displaywriter's, and sits on a logic box with dual
diskettes. Inside we have an 8088, up to 256K, five expansion
slots, 80x25 screen memory with graphics 320x200 or 640x200.
Figure it out, that means an OK but not great 8x8 character
cell. The unit displays up to 16 foreground colors on 8 back-
ground colors (but I doubt if all those are available in the
graphics modes). And you get a sound generator and built-in
speaker to boot!
The thing is totally modular; even the I/O cards are separate!
For $ 1,565 you get a keyboard and logic unit with 16K RAM and
a Basic interpreter in 40K ROM. A cassette interface is built
in, I think; but no diskette or monitor at this price -- you
use your TV set. Of course you can add one or two minidiskettes,
lots more memory (16-64k increments), a B&W monitor (no color
monitor was mentioned), RS-232C interface card, matrix printer,
a joystick/paddle interface (but you have to buy somebody else's
joysticks and paddles); and maybe the kitchen sink. A "business
configuration" with 64K, dual diskettes, printer, and "color
graphics" goes for about $ 4,500.
The big news might be the software -- there's plenty of
it. If you don't like their idea of a diskette OS or Pascal
compiler or word processor, you can try USCD Pascal or CPM-86,
coming soon from Softech and Digital Research. (Gee, and I
was looking forward to JCL). And then there's Visicalc, three
Peachtree business applications, Microsoft Adventure, 3270
emulation on the way, and a new IBM Software Publishing outfit
(!**8). It looks like they read Byte.
Where can you get it or ogle at it? Try your local Sears,
Computerland, or IBM store (or DPD sales rep, if you're a
big banana).
Darryl Rubin
SRI International
------------------------------
Date: 17 Aug 1981 1220-PDT
From: Rubin at SRI-KL
Subject: Micro benchmarks
This may sound like an answer that begs the question. But THE
one true way to benchmark a micro depends entirely on your point
of view. (As you see, I have an unmatched knack for discovering
the obvious.) CPU architecture and instruction throughput matter
the most to designers of CPU boards for number-crunching and other
compute-bound stuff. Good I/O architecture and throughput score
highest to OEMers of communications and data base boxes. Good
compilers, spiffy user interfaces, and software tools (Xerox we
hear you!) matter the most to the rest of us system developers
and end users. What you will "see" is what you should measure.
Just to be exhaustive if not obsessive, I'll mention the sometimes
overlooked importance of good I/O controllers and peripherals,
especially big fast disk; a W-I-D-E choice of hardware and
software offerings; reliability, support, and the prospects for
compatible future enhancement. Most of all, vendor credibility
and track record. How do I benchmark thee, have I counted all
the ways?. . .
Darryl Rubin
SRI International
------------------------------
Date: 15 AUG 1981 1411-PDT
From: STEWART at PARC-MAXC
Subject: Benchmarks
Quote from ???: "There are lies; there are damn lies;
and there are benchmarks."
-Larry
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #9
∂22-Aug-81 0646 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #9
Date: 22 AUG 1981 0917-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sat, 22 Aug 1981 Volume 4 : Issue 9
Today's Topics:
Workstations - IBM's Personal Computer
----------------------------------------------------------------------
Date: 18 Aug 1981 1406-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
For more details on the IBM new personal computer see a full page
ad (page 16) in Monday's Wall Street Journal (8/17/81). There is
a number one can call : 1-800-431-2670. But Rubin's mail to
WorkS seems to have quite a good description of the system.
Willie
------------------------------
Date: 18 Aug 1981 1415-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM new PC
There is a rumour that the S-100 bus is (or going to be) on the new
IBM PC. Is this true?
Willie
------------------------------
Date: 20 Aug 1981 (Thursday) 1737-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: IBM Personal Computer
Would someone collect information on the IBM Personal Computer,
and then send it out to the list? Here is all that I know about
it:
Processor Class: 8086 (lets face it, its a display-writer)
Up to 256 K memory
Either Floppy (avail now) or Winchester drives.
Can run DOS, a version of CP/M or IBM's own OS.
Will have EasyWriter & VisiCalc; not sure on Wordstar.
It is clearly going to be more powerful in the long run over
8080 class microprocessors.
For more info, they have an 800/431-2670 number for information
pacquets.
Hank
------------------------------
End of WorkS Digest
*******************
∨
Subject: WorkS Digest V1 #10
∂31-Aug-81 0013 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #10
Date: 31 AUG 1981 0142-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 31 Aug 1981 Volume 1 : Issue 10
Today's Topics:
Workstations - IBM's Personal Computer, Working While Flying
----------------------------------------------------------------------
Date: 23 Aug 1981 1700-EDT
From: GILBERT at MIT-XX (Ed Gilbert)
Subject: IBM's personal computer: S100?
I saw a sales presentation and a couple of prototypes the other
day. From what I remember, the cards did not look like S100
cards. During the presentation, they promised to publish the
bus specs, so we can assume that it isn't S100. However, they
seem to be encouraging a plug-compatible market, so it should
soon grow to be as large as the S100 market.
Someone sent a message to this list some time ago describing
the system. I learned little of significance at the presentation
that was not in that message. I do want to clarify something
that could cause confusion. The DOS that is offered with the
personal computer is not the same one that runs on the main-
frames. If you think about it that would be very difficult
to do, but IBM hasn't been very clear about it. I am told
the new DOS is of the same flavor as CP/M.
------------------------------
Date: 26 August 1981 1153-EDT (Wednesday)
From: Marc.Donner at CMU-10A
Subject: IBM Personal Computer
I saw some of the discussion of the IBM personal computer
in the Apollo bboard at CMU. I just left IBM Yorktown
Heights and I brought with me a copy of the 'blue letter'
that announced the PC. I will be glad to send you any
information from it that you want ... it is public
information. I don't have it with me physically right
now, but here is some of the gist:
In the beginning IBM will be selling two basic configurations:
Configuration 1 includes 'System Unit', Keyboard, 48K RAM,
40K ROM, floppy disk controller and one floppy (5-1/4 inch
minifloppies). Configuration 2 is same as configuration 1
with addition of another 16K RAM (total 64K) and the other
floppy. The system unit has capacity for up to five cards.
One option that you MUST buy before you may use the system
is one of three video interfaces. One interface connects
to the IBM monochrome display, one connects to a TV modulator,
and one connects both to the monochrome display AND to the
printer. The list price for Configuration 1 is about 2300
dollars. For configuration 2 the list is about 3000 dollars.
Oh, one thing that is also included in the Configuration 1
and 2 systems is the Asynchronous Communications Interface.
All software beyond the ROM Basic (by MICROSOFT) is extra
cost. Asynchronous communications software is $40, Pascal
is $300 (requires two floppies and big memory, I think),
Adventure is $30 ... more details when I have the blue
letter in my hand. The minimal systems (system unit, 16K
RAM) will only be available from Sears and Computerland.
Volume discounts are available ... 5% for more than 20
units on up to 15 or 20% for >100 units.
The processor is an Intel 8088, which is the 8 bit bus version
of the 8086 ... it is a 16 bit machine shouting through a small
hole. The processor cycles at almost 5MHz. Assuming three
byte instruction and one data fetch or store per instruction,
there will be five memory transactions per instruction ... if
memory cycles at system clock speed (I think that this is so)
then they get about 1 microsecond per 8086 instruction. The
first 64K of RAM plug into sockets on the main processor board
... you don't have to buy the RAMs from IBM ... you can get
the chips from a distributor and save bucks.
Almost all of the software (read ALL) is from outside. The
floppies and the printer are also OEM components that IBM
buys. The monochrome display is capable of displaying 25
lines of 80 characters ... the TV interface is limited to
25 lines of 40. The monochrome display may have monochrome
graphics ... the announcement is quite vague.
I priced out the nicest combination of goodies that would
go together in the box ... two floppies, 192K RAM, printer,
display, communications, and it came to about $6K sans
software.
Please let me know if you want more details.
Marc
------------------------------
Date: 27 Aug 1981 1743-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Working while flying - airborne phones coming
From the 26 Aug 81 issue of MIS Week newspaper:
W.U. TO ACQUIRE 50% OF AIRFONE
Upper Saddle River, N.J.
- Western Union Corp. said last week it has agreed to acquire
a 50 percent interest in a new communications system, owned by
Airfone Inc., that will allow passengers on commercial airlines
to place a telephone call while in flight.
According to Western Union, Airfone has received a developmental
license from the Federal Communications Commission (FCC) to
provide a nationwide, fully automatic air-to-ground radio
telephone communications service.
Initially, Western Union said, service will be provided through
air-to-ground telephones installed in wide-bodied aircraft, which
in turn will be linked with multiple ground stations providing
coast-to-coast coverage. It said a passenger would be able to
place a call by using portable telephones located in various
sections of the aircraft.
The system, it said, is expected to be operational during the
second half of next year.
------------------------------
Wonder if I'll be able to use my TI745 with this service...or
better yet, the still-to-come portable CRT connected to my
still-to-come stand-alone home workstation? -Rich Zellich
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #11
∂01-Sep-81 0933 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #11
Date: 1 SEP 1981 1042-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 1 Sep 1981 Volume 1 : Issue 11
Today's Topics:
Workstations - IBM's Personal Computer, Working While Flying
----------------------------------------------------------------------
Date: 31 Aug 1981 08:20:52-PDT
From: SomeoneOnUUCP at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
Reply-to: "Steven M. Bellovin in care of" <CSVAX.upstill at Berkeley>
Subject: New IBM system
I have a few questions about the thing, and I'd appreciate any
information anyone has gathered.
a) is it S-100 compatible?
b) Is it program compatible with their 8086-based Datamaster?
c) Can one get 8-inch floppies for it?
------------------------------
Date: 31 Aug 1981 1214-PDT
From: Rubin at SRI-KL
Subject: IBM PC, last round
A last note on the IBM PC, and then maybe we can get back to
discussing REAL research workstations (which the IBM PC probably
isn't quite).
I got the literature pack IBM sends out, and would like to correct
something Marc said in his recent note. This literature mentions
only two video interfaces -- one for the IBM monochrome display and
one for a color graphics display. The monochrome board includes a
printer interface. If you get the color board, you buy a separate
printer interface. The color board has 16K RAM for color storage,
used like this:
Text mode -- 16 foreground colors, 8 background
Graphics mode -- 4 colors 320 x 200 (might there be a lookup
table ???), 2 colors (B&W) 640 x 200
The graphics board puts out RGB and composite video. IBM does
not (yet) sell a color graphics monitor or RF modulator, but if
you buy somebody else's, the graphics board will accommodate it.
If you're seriously interested in this PC, be wary of a couple
things: First, the five slots probably isn't enough if you want
> 128 K of memory and color graphics; with luck they'll add a
bus extender. Also, I'm wondering whether any of the announced
software really supports more than 64K in any useful way, or how
soon it will. (Given the slowness of diskettes, you'll need the
extra RAM for decent response time, if the software will only use
it properly). Third, I don't believe the IBM DOS applications
can send their output to the ASCII port; if true, you'd have to
buy their printer (and that's a loss because the printer doesn't
do graphics, or at least IBM doesn't claim it does).
Still, I think this PC has more pluses than minuses, compared
to Apples, TRS-80s, Xerox 820s, ad triviatum. Good hardware,
lots of software, lots of future enhancement, and lots of
support (maintenance contracts, even!). Look for IBM to add
a 5.25" Winchester and lots of color graphics software.
Now, about REAL workstations. I just read a rumor that about a
year from now DEC will be announcing a floppy-based, VLSI VAX
packaged as a workstation. Price about $ 15,000. Supposedly
it's already in beta test. Does anyone know more about this?
--Darryl
------------------------------
Date: 31 Aug 1981 0018-PDT
From: the tty of Geoffrey S. Goodfellow
Sender: GEOFF at SRI-CSL
Reply-To: Geoff at SRI-CSL
Unless you like getting 3 and 4 digit phone bills, I don't
think you'll want to use your terminal on AIRPHONE. Such
a service currently exists on some United DC-10's using
equipment sold by SKYTEL (or SKYPHONE) using the currently
allocated FCC Air-to-Ground Mobile channels. Last I heard
the charge for use was $15/first three mins (air-time), and
$3/ea. addtl min (air-time). This charge was IN ADDITION
to the Operator Assisted dialed call rate from the ground
base station you were going thru to the person you were
calling.
I have found the mobile phone I have in my car indispensable,
and have often wished for similar service on air plane
flights. I just hope that the license the FCC gave AIRPHONE
for its developmental system means it will operate on some
new frequency allocations, and hence, will be a 'new type
of service' and not subjected to the (excessive) rates on
the current system in use today.
P.S. Wouldn't this have been more appropriate for HUMAN-NETS?
[ It was addressed to HUMAN-NETS as well as to WorkS. It
was deemed appropriate for WorkS because of this list's
earlier speculations on using terminals while traveling.
I would like to take this opportunity to remind everyone
that almost all of the WorkS subscribers also subscribe to
HUMAN-NETS. The moderators will point out other discussion
lists to submitters when that seems appropriate. However,
the final decision of where to distribute something remains
with the submitter. -- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #13
∂03-Sep-81 0957 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #13
Date: 3 SEP 1981 1004-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 3 Sep 1981 Volume 1 : Issue 12
Today's Topics:
Query - Mesa availability, A book on Workstations,
Call for People - NCC '82 Personal Workstations track
----------------------------------------------------------------------
Date: 3 Sep 1981 (Thursday) 0753-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Mesa shall be released (?)
I have heard from two sources that Mesa - the programming
language for the Xerox Star, among other Xerox products,
will be released, and available for programmers to use.
Just how much and exactly when Mesa is coming out are two
interesting questions at this time.
Hank
------------------------------
Date: 3 Sep 1981 (Thursday) 0816-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Workstations -- a book ?
Personal Workstations Mailing list;
to all participants:
Computer Science Press of California is interested in making
WorkS a book. Sections on all the different personal computers,
and interesting areas such as local networks will probably be
addressed.
Please send me your comments in this matter. I would like to
use most of the information contained here already in WorkS,
as well as continue to put together more topics and 'chapters'
through continued input.
The way in which I foresee the book becoming a reality is by
having everyone who has expertise in an area write the appro-
priate chapter. I am still in the idea-cogitating stages of
this -- your input shall be most valuable.
If interested in helping, let me know!
Henry Dreifus
------------------------------
Date: 3 Sep 1981 (Thursday) 0821-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: WorkS in NCC'82 works.
This is a version of a message that Bob Frankston of SoftArts
sent to the Works users who are interested in getting NCC-82's
personal workstations track running and up and off the ground.
People are needed to help organize this thing, and do it right.
If you are at all interested in any aspect of what is below, or
have some ideas you think are important for the NCC please send
them along to Bob Frankston [Frankston.SoftArts@MIT-MULTICS].
Hank
--------------------------------------------------
1. What is personal computing.
This should cover some of the history of personal computing
(it is not a new idea) as well as the current explosion in
popularity and availability. A subtopic is "what is
programming". Traditionally it has been languages such as
Fortran and COBOL. What is it now?
2. Local Networks, Workstations
These are both popular topics these days.
3. Education/Social Implications
Issues beyond traditional CAI. Learning with and about
computers. What are the effects in the US society, in
other, possibly "less well developed" societies. What
are the myths such as "computers for kitchen recipies"
vs "computers are impossible for people to ever learn to
use". Society also affects computers. As the computation
becomes more accessible, more people will be programming
and affecting the machines.
4. Global Networks
This is actually a combination of the previous two --
what is the implementation of and the implications of
communicating computers. The emphasis is on the use of
such a capability be individuals as a means of access
and communication. Cable TV and information services
are both relevant to this as is electronic mail.
5. Software Environments/Operating Systems.
This covers both traditional operating systems work
as well as special machines for Lisp and Smalltalk.
Also relevant are tools, standards and protocols, and
languages. The emphasis is on the particular issues
for personal computing (this sometimes means small
computing, but not necessarily).
6. Hardware
The emphasis would be on developments that make the
computation more accessible for personal computing.
7. Applications.
There is not necessarily a strong distinction between
systems work and applications. Applications may include
individual ways of exploiting computers for personal use
or use of computers in environments such as homes and
offices. For example, workstations are both applications
and environments for applications.
8. Graphics
As it applies to personal computing.
9. Peripherals and I/O.
How is access to personal computing provided, how can such
systems interact with their users and their environment.
These are, of course tentative. Suggestions are stil welcome.
If you know of other people who would be interested in helping
or people you know of who you hink I should contact, please
send me a note (nccpc82.SoftArts at MIT-Multics).
Thanks.
Bob Frankston
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #13
∂04-Sep-81 1006 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #13
Date: 4 SEP 1981 0907-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Fri, 4 Sep 1981 Volume 1 : Issue 13
Today's Topics:
What is a Workstation?, Workstations - Xerox 1100
----------------------------------------------------------------------
Date: 3 Sep 1981 1703-PDT
From: Mike Leavitt <LEAVITT at USC-ISI>
Subject: Works Book
One of the issues that has weaved in and out of the discussion
here is why certain small machines are *not* workstations.
It would seem interesting for the definitive (for this year)
workstation book to discuss this issue, as well, and perhaps
to indicate just what would need to be done to the more common
small machines for them to qualify as workstations. I'm cc'ing
the list on this because I want to hear the flames about how
an Apple can NEVER become a REAL workstation, before I give
specifics!
Mike <Leavitt at usc-isi>
------------------------------
Date: 3 Sep 1981 0959-PDT
From: Richard R. Cower <COWER at SRI-KL>
Subject: Xerox
NO. 509
August 27, 1981
XEROX ANNOUNCES INTERLISP PROCESSOR
FOR ARTIFICIAL INTELLIGENCE RESEARCH
A compact computer system for use by research scientists in
artificial intelligence has been announced by Xerox Corporation.
The Xerox 1100 Scientific Information Processor includes a wide-
format, bit-map display, keyboard, and "mouse" pointing device.
It makes available the Interlisp-D software, an upward-compatible
extension of Interlisp, formerly available only on large, time-
shared computers.
The 1100 Interlisp system provides scientists with a computing
environment for conducting artificial intelligence research.
This research discipline has applications in engineering,
medicine, genetics, geophysics, robotics, and other fields.
Both the hardware and software were developed at the company's
Palo Alto Research Center in California. The system will be
marketed by Xerox Electro-Optical Systems in Pasadena, California.
Louis G. Karagianis, Vice-President of Marketing for Xerox
Electro-Optical Systems said, "The 1100 processor is intended for
use by research scientists in universities and large industrial
research laboratories, which are centers of activity for the
development of artificial intelligence techniques."
The system has 1.15 megabytes of memory and virtual address space
of 4 million 16-bit words. It also includes a 23-megabyte Shugart
disk drive and interfaces for the original Xerox 3-megabit-per-
second Ethernet, and for RS232 communications lines. All of this
equipment is housed in a 2.5-foot-high cabinet that fits under a
desk.
The display is a high-resolution unit with a 13" x 11" viewing
area (1024 x 808 pixels). The text portion of two pages can be
displayed side-by-side.
The Xerox 1100 includes a complete implementation of the Interlisp
virtual machine specification. In addition to the standard Inter-
lisp features, it offers new personal computer facilities, such
as a complete set of raster scan graphics operations and Xerox
Ethernet software.
Purchase price of the Xerox 1100 Scientific Information Processor
in the United States is $59,719; this includes a license for
use of the Interlisp-D software. Deliveries will begin in the
first-quarter of 1982.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #14
∂08-Sep-81 0550 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #14
Date: 8 SEP 1981 0718-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 8 Sep 1981 Volume 1 : Issue 14
Today's Topics:
Query - Cheap touchpanel
----------------------------------------------------------------------
Date: 4 Sep 1981 1257-EDT
From: Kastner at RUTGERS (John)
Subject: Touch Panel
Do you know of any vendors that sell a touch panel terminal or
an add-on touch panel for an existing terminal? Either the actual
touch sensitive or the light array type would be acceptable. We
are looking for a panel that fits rights over the screen. We
would prefer one on which a finger would work but might consider
a light pen. We don't need high resolution and probably 16 X 16
would be sufficient.
The terminals that we've seen cost over $7000 and have fancy
graphics that we don't really need. What we would like is a
cheap way that doesn't require a lot of fancy code or hardware.
Thank you,
John Kastner
[ During July, WorkS discussed a variety of different workstation
input devices. A major portion of the discussion was devoted
to touchpanels. For your convenience, a transcript of this
discussion is now available in the file DUFFEY;WORKS TOUCHP
on MIT-AI. -- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #16
∂16-Sep-81 2316 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #16
Date: 16 SEP 1981 2315-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Wed, 16 Sep 1981 Volume 1 : Issue 16
Today's Topics:
Administrivia - Issue numbering, Input devices - Mice
----------------------------------------------------------------------
Date: 16 September 1981 22:55-EDT
From: The Moderator <Duffey at MIT-AI>
Subject: Administrivia - Issue numbering
Due to a combination of problems, the last three WorkS issues
were misnumbered. These issues, which were dated 3, 4, and
8 Sep., should have been numbered V1 #13, V1 #14, and V1 #15.
Today's issue is V1 #16 and it immediately follows the issue
dated 8 Sep. My thanks to everyone who pointed out these
errors.
-- RDD
------------------------------
Date: 16 September 1981 02:55-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: What is the "optimum" shape of a mouse?
Here's your chance to "shape" the future course of mouse-kind.
I would like to know what people think the ideal mouse should
be shaped like. Also, should there be less than three buttons?
Note that this is an optical design (the mouse slides on a
surface, rather than rolling) so comments about the mechanics
are not applicable.
Comments will be accumulated on MIT-MC in SK;MOUSE SURVEY
(no password needed to ftp).
Some comments I received so far follow. If you have any
opinions on these, please voice them. Some of the following
comments are mutually exclusive.
------------------------------
The Xerox mouse is too small. It doesn't fit the hand well/it
is hard to find.
The Xerox mouse is too large.
The ISI/TYMSHARE mouse is way too large.
Long buttons are great for accomodating various size hands.
The buttons should have good "bounce" to them to facilitate
double and triple clicking.
The MIT mouse (tan case) seems to be about the right size.
The mouse should have rectangular shape and edges. Any hand
contouring is doomed to failure because of the wide variety
of hand sizes.
The mouse should be rounded to fit the contours of the hand
(prolate hemi-spheroid). The hand should slip naturally into
a "home" position where the fingers rest on the buttons.
The mouse should not be "handed". This is to accomodate
lefties as well as two handed mouse applications.
The wrist must be able to rest on the table with the fingers
comfortably on the buttons. This is necessary for accurate
positioning.
There shouldn't be more than three buttons on the mouse
because two fingers are needed to move it around. Also,
coordination is difficult.
------------------------------
[ If you want a copy of the survey messages and cannot obtain
it yourself, please send a message to WorkS-REQUEST at MIT-AI.
We will be happy to insure that you receive a copy now. A
file containing all of the responses will be made available
for FTP distribution when the query is over.
-- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #17
∂21-Sep-81 0239 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #17
Date: 21 SEP 1981 0500-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 21 Sep 1981 Volume 1 : Issue 17
Today's Topics:
Query - Cell graphics algorithms,
Book - Audience and objectives, Workstations - MicroDaSys 68000,
Input Devices - TASA touchpanel & Apple mice
----------------------------------------------------------------------
Date: 20 Sep 1981 (Sunday) 0941-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Call for information, forwarded request
[Begin forwarded messages]
Date: 19 Sep 1981 2317-PDT
From: William "Chops" Westfield <BILLW at SRI-KL>
Subject: Need algorithms for Cell-organized graphics displays
Does anyone have references for graphics algorithms (line
drawing, polygon filling, etc) that have been optimized
for use with subcell style graphics display (such as some
terminals and many micros have)? I know Barrett & Jordan
have some articles in CACM (march,feb 1974) (I haven't read
them yet). Are there any others written since then?
Thanks
Bill W
[End forwarded messages]
------------------------------
Date: 20 Sep 1981 (Sunday) 1004-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Book.
The general opinion is to gear this book to the technical market-
place, the educational as well? I am not that high on having a
loose leaf type book, but that could be for the second volume,
an update service on all the new machines that are around.
I would be interested in what one would want to see in a book
such as this describing personal workstations, what sorts of
things should be stressed and so forth.
Hank
------------------------------
Date: 21 September 1981 02:50-EDT
From: Patrick G. Sobalvarro <PGS at MIT-AI>
Subject: Workstations - MicroDaSys 68000
There is a company in California called MicroDaSys, which claimed
in the latest issue of EDN to be selling a 68000 Unix system that
looks too good (and cheap) to be true. Two 12mhz 68000s (one for
virtual memory management, with demand paging), and a 6809 for
interrupt-driven I/O. Comes with 6 RS232 ports, running at up to
500k baud, and 4 parallel ports, with handshaking.
A multiuser system comes with 512k bytes of RAM in a 16M-byte
virtual space, 40M bytes of Winchester storage, and V7 Unix.
All for less than $20K.
Does anyone have any experience with these folks? Are they
delivering?
-pgs
------------------------------
Date: 19 Sep 1981 (Saturday) 2337-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Touch Panels: TASA
Product: Touch-Panel, x-y positioning
Price: $400.00 quantity 1, $150.00 in mass
Model: X-Y 3600
Principle: Capacitive Sensing, look at Xrx860 abortion
60x60 steps in square surface 5"x5".
Probably useful in augmenting user work-effectiveness.
Address: Touch Activated Switch Arrays, Inc.
2346 Walsh Avenue, Santa Clara
California, 95051
(408) 727-8272
Contact: Bob Abler, manager of marketing.
I'd be interested if there is a demonstrated use for touch panels
that are not a part of the screen, and if they have the ability
to be used for Office Automation? What also does one need from a
touch panel? More x-y points ?
Hank
------------------------------
Date: 19 Sep 1981 1806-PDT
From: Mike Leavitt <LEAVITT at USC-ISI>
Subject: Mice for Apples
Does anyone know of anyone who sells Mouses for Apples?
I presume they should plug into the game socket, and work like
a joystick plus the three button sensors. A couple of micro-
switches on the side would be nice to determine which of the
paddle controls would be activated.
Mike
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #18
∂24-Sep-81 2021 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #18
Date: 24 SEP 1981 0540-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 24 Sep 1981 Volume 1 : Issue 18
Today's Topics:
Input Devices - Touchpanels
----------------------------------------------------------------------
Date: 22 September 1981 19:40 edt
From: SSteinberg.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Subject: TSD's
Xerox uses them to implement a mouse on a workstation. ArqMaq
put them on the arms of a chair and did gesture recognition so
they could control sound volume (circular motion), page viewing
(diagonal lines for forward and back), and so on. Gesture
recognition doesn't need hi-res.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #19
∂16-Oct-81 0617 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #19
Date: 16 OCT 1981 0604-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Reply-to: WorkS at MIT-AI
To: WorkS at MIT-AI
WorkS Digest Friday, 16 Sep 1981 Volume 1 : Issue 19
Today's Topics:
Technology - 32 bit Micros, Input Devices - Mice,
Workstations - Apple-O Arrival
----------------------------------------------------------------------
Date: 16 Oct 1981 0600-EDT
From: DUFFEY at MIT-AI
Subject: Welcome back (again) and goodbye (one last time)
This is WorkS V1 #19. It directly follows WorkS V1 #18 published
on 24 September. A long hiatus due to a lack of submissions, but
one that will not be repeated soon as WorkS turns its attention
to a variety of new and old topics over the next few weeks.
Welcome back.
As subscribers to some of the other lists already know, I will
soon begin a two year leave of absence from MIT to pursue research
with a private company. Starting with the next issue, Jon Solomon
<JSol at RUTGERS> will take over as WorkS moderator and maintainer.
Jon is already well known to subscribers to these lists as both a
moderator and subscriber. I hope you will welcome him with the
same cooperation and interest that you have always shown me. It
is the only thing that makes it possible to do this job. Thank
you and enjoy.
Roger Duffey
------------------------------
Date: 7 Oct 1981 (Wednesday) 0012-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: How far away are the 32 Bit micros ?
This is something that has not been introduced in too much
detail as of yet. With the forthcoming 432 32 bit-on-a-chip,
and putting it into a workstation/small multi-user machine
is of some interest. What does 32 bits really win over
16 bits?
Henry Dreifus
------------------------------
Date: 12 Oct 1981 2042-PDT
From: Jim Guyton <Guyton at RAND-AI>
Subject: Xerox Mouse
Xerox Mice fans:
Jack Hawley (owner of Hawley labs, maker of the Xerox
Alto mouse) has made a new license agreement with the
Xerox Corporation.
His new agreement will allow him to sell the mouse
to almost anyone, including for-profit companies.
Previously he was restricted to selling to Xerox
and non-profit educational institutions.
Developmental prototype (no case) available in January
for $750. Production quantities available mid-April
for about $425.
The number for Hawley Labs is (415)525-5533.
Mouse in quantity:
1-99 425
100 375
250 315
500 290
1000 280
------------------------------
Date: 11 Oct 1981 (Sunday) 2140-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Our APPLE-O arrived on Friday,
a review of it will be made in WorkS next week.
Hank
------------------------------
End of WorkS Digest
*******************
Subject: WORKS Digest V1 #20
∂21-Oct-81 2128 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #20
Date: 21 Oct 1981 0713-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
WorkS Digest Wednesday, 21 Sep 1981 Volume 1 : Issue 20
Today's Topics: Administrivia
Where are the 32 Bit WorkStations?
VideoDisks as Storage Devices
Mesa Manual Query
----------------------------------------------------------------------
Date: 21 October 1981 0642-EDT (Wednesday)
From: The New Moderator <JSol at Rutgers>
Subject: Hello! and Welcome to WorkS!
Hello,
Roger Duffey was a superlative moderator and it will not
be an easy job trying to match the quality of service which he was
famous for. I will, however, do my best and hope that I can at
least comes close to the fine work Roger has done. There is no
question that the ARPAnet community will miss his fine services as
moderator.
Once again, I wish to express my appreciation at being given the
responsibility of maintaining this digest, and I hope that the
transition between moderators will be as transparent to the readers as
possible.
Enjoy!
JSol
P.S. You can still send mail to <WorkS at MIT-AI>, or you can send
mail to <WorkS at Rutgers> if you prefer. Archives will continue to be
maintained at MIT-AI, and additionally at Rutgers in the <WORKS>
directory (at Rutgers, much of the WorkS archive is on tape, so if you
desire back issues you should mail your request (or any list
maintainence request) to <WorkS-Request at MIT-AI> or <Works-Request
at Rutgers>.
------------------------------
Date: 16 October 1981 1014-EDT (Friday)
From: Hank Walker at CMU-10A (C410DW60)
Subject: when are 32-bits coming
CC: dreifu at wharton-10
I assume that the MC68000 doesn't count as a 32-bit machine. Intel
has yet to ship any 432s, so it will be a while before any appear in
personal computers. A VAX takes 400 kbits or more of microcode, and
at least 500k transistors total to make even the slowest one. Even a
chip-set must be fairly complex.
The obvious thing that 32 bits gives you is a larger virtual address
space. Lots of applications are hard up against existing limits, and
must resort to memory management by hand, which is a royal pain. In
addition, 32-bit processors usually have a more complex instruction
set, addressing modes, etc, which allow them to perform better on a
wide range of tasks (ignoring the RISC arguments). Examples are
string and floating-point datatypes. The 432 includes a significant
amount of OS support, as well as provide a capability architecture.
Given the thickness of the architecture manuals, I don't know how well
this will go over.
32-bit processors usually also have a larger physcial address space.
Since 16 Mbytes and more memory will appear on personal computers in
this decade, this is an important consideration.
------------------------------
Date: 19 October 1981 18:50 edt
From: SSteinberg.SoftArts at MIT-Multics
Subject: #19 and 32 bits
The most important thing 32 bits buys is larger address space.
It was annoying to have to pass around 16 bit pseudo-pointers
on the IBM 1130 (back in '69) to address a data base larger
than 64KB and it is still annoying to have to call the
subroutine library in order to reference an item of data.
Think of 32 bits as more object names one can use in
programming.
------------------------------
Date: 20 Oct 1981 0030-PDT
From: SCHIFFMAN at SRI-KL
Subject: 32-bit micros, iAPX-432 based workstations
cc: schiffman at SRI-KL
To figure out how much an advantage a 32-bit micro would be, first
figure out what a "32-bit" micro is --
There are several things in a computer which have a `size':
1) The width of the accumulators/general-registers
(This is confusing in machines which allow concatenation
of registers like the Z8000). Wide registers gets you
shorter (faster) programs by eliminating extra `name'
references for OPERANDS WHICH REQUIRE THAT PRECISION.
Not surprisingly, 128-bit registers aren't very handy for
programs which only do byte-boffing. In fact, wide
registers HURT for programs which don't need the precision
if having narrower registers means having more of them.
The Z8000 tries to have its cake and eat it too.
2) The width of significant data paths such as the ALU.
(How many bits can you add in one microcycle?
Many machines have a N-bit ALU and an 2N-bit shifter.)
Wide data-paths make atomic operations faster for
operations which require the precision. All else being
equal, however, the wider the data path gets, the slower it
cycles (carry propagation).
3) The width of the processor/memory data interconnect.
(How many bits can you fetch in one bus cycle?)
Wide data interconnects to memory speed up operand
fetches/writes which again, helps only on operands which
need the precision. Luckily, if the instruction execution
unit is at all clever, wide memory almost ALWAYS speeds up
instruction fetches; this can be VERY significant.
Unfortunately, for small systems, cost can be almost
linearly proportional to memory bus width.
Under these criteria....
CPU Register Data Path Memory bus
Width (bits) Width (bits) Width (bits)
----------------------------------------------------------------------------
Z8000 64,32,16,8 16 16
MC68000 32 32 16
I8086 16,8 16 16
I8088 16,8 16 8
NS16000 32 32 16
iAPX-432 variable?, to 80 80? 16/user-prov.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
The table is straightforward, except for the 432. My understanding is
that the 432 has no "general-registers", really. It does have many
internal registers available at the microprogram level, at least some
of which have to be 80 bits to hold results in Intel (IEEE draft)
floating point `double-extended' format. As for the bus interface,
this is rather complicated -- the 432's Bus Interface Unit can connect
to user-designed memory systems of various types. I believe that the
Intel evaluation boards use a 16-bit memory bus. So what about the
432 is 32-ish? Only the obvious, I think.
As for its applicability in personal workstations, I think this is
pretty dubious for the next few years.
* A system including the 432 would be VERY expensive by
workstation standards, even if Intel gave the chips away
(which doesn't seem to be in their plans -- the set
currently costs on the order of a kilobuck). Besides
being very memory hungry, a realistic system requires an I/O
processing symbiont higher in complexity than most current
micro-computer systems.
* A personal workstation system based on a 432 could very
well be much SLOWER than a system based on (say) the 8086!
Sorry folks, a full context switch on every subroutine call
and a domain-check for every external reference is very
expensive. Now if you had, say, four CPU sets in your
workstation, you might very well win -- that is if all your
compute-bound programs divided into four balanced processes.
Intel seems to be saying that the 432 is intended for high-performance
shared-database transaction processing systems. I say that if it's
good for anything at all, its probably just that.
-Allan
------------------------------
Date: 18 Oct 1981 (Sunday) 1506-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: VideoDisks on Personal Workstations ?
[Note: This message originally appeared on the VideoDisk discussion
list -JSOL]
Electronic Design for Sep-30, 1981 has a full artical on video-disk
technology. Here are some highlights....
Corning has eraseable video disks using polarizers and stuff !
Medias being used include: Silver-halide, Tellurium,"Drexon Media",
bismuth, rhodium, titanium, thermodegradable/metal film.
Many are producing disks writable with semiconductor lasers (cheaper)
Formerly it took a gas laser to produce enough power.
(this is also due to improvments in laser technology)...
Bill W
<BillW at SRI-KL>
------------------------------
Date: 20 Oct 1981 1610-EDT
From: PRSPOOL at RUTGERS
Subject: MESA MANUAL
Does anyone at XEROX-PARC ( or anywhere else )
know where I can get hold of a MESA manual ( or at least
a fairly descriptive paper ). I recently noticed a
referance to the MESA LANGUAGE MANUAL by James G. Mitchell,
William Maybury and Richard Sweet of XEROX PARC, published
in February, 1978.
--Peter R. Spool
Rutgers University
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #21
∂21-Oct-81 2329 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #21
Date: 22 Oct 1981 0103-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
WorkS Digest Thursday, 22 Sep 1981 Volume 1 : Issue 21
Today's Topics:
Other Considerations Of 32 Bit Processors
Videodisks As Memory
----------------------------------------------------------------------
Date: 21 Oct 1981 1918-PDT
From: SCHIFFMAN at SRI-KL
Subject: Addition to processor taxonomy
In my consideration of the "32-bitness" of CPUs, I now realize that I
left out two other things that have a width:
4) The number of physical address bits presented to the
memory bus.
Obviously physical address bits cost more IC pins and
backplane wires, contributing to cost. Not so obviously,
address bits can contribute greatly to the cost of memory
management hardware (and the time cost of using it). The
point is that you don't really want to pay much more for
physical address bits than you need to address the memory
your systems will be able to afford.
5) The internal "name-space" of the architecture, i.e. log2 of
the number of unique objects that can be referenced.
The reason why we can't more simply define this
(as say, the number of bits in a `pointer') is that
some architectures can have arbitrarily complex ways
of encoding internal names, say by using the data-type
field of an op-code to provide extra "logical-address
bits".
Again, a large name space can be a mixed blessing. One of
the most important (for instruction encoding efficiency)
areas of CPU architecture is how to compress memory
requirements for expressing local names. This can be done
badly for machines with even a relatively small name space
(i.e. the PDP-11, where all offsets take 16 bits).
Under these additional criteria, the updated table...
WIDTH (Bits)
CPU Registers ALU Memory Phys. Log.
Data Addr Addr
------------------------------------------------------------
Z8000 64,32,16,8 16 16 24 24
MC68000 32 32 16 24 24
I8086 16,8 16 16 20 20
I8088 16,8 16 8 20 20
NS16000 32 32 16 24 24
iAPX-432 to 80 80? 16 24 40
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
I reread the 43203 data sheet and decided that the memory data bus
was, by the definition that I gave, not "user-supplied", but 16 bits.
The reason for this confusion is that the data bus operates in burst
mode (only one address output for the transaction) for operations on
words longer than 16 bits; this is real optimization since addresses
usually take as much as half a bus cycle.
-Allan
------------------------------
Date: 21 October 1981 2333-EDT (Wednesday)
From: Stephen.Hancock at CMU-10B
Re: Rotating Memories ("video disks")
The October issue of Mini-Micro-Systems has an artice entitled
"Rotating- memory devices move to optical reading". The article
informs us that european systems are being devoloped by Philips NV
and Thomson-CSF. The device is supposed to be a 10G bit drive with a
twelve inch platter. There are plans to have a system with a 64
platter magazine (thats 640G bits). The system is expected to be
released in about 2 years the projected OEM cost is between $2000 and
$10000 each. The article also points out the sales dollar volume and
number of optical units sold will be only a small fraction of the
total rotating memory market.
Steve
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #23
∂26-Oct-81 0011 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #23
Date: 26 Oct 1981 0233-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Monday, 26 Oct 1981 Volume 1 : Issue 23
Today's Topics: Alto Snipe Revisited
Symbolics' Personal Workstation Query
----------------------------------------------------------------------
Date: 24 Oct 1981 0057-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: apparently random Alto snipe
To: Editor-People at SU-SCORE
I just sent an apparently snide message to Editor-People about the
Altos and their outdatedness; I realized that this might sound
off-hand or snooty, so let me clarify what I meant, and possibly start
a set of flames.
The Alto, without a doubt, was an interesting toy which gave many
bright people a teething device for their ideas about human
engineering, etc. However, I have a heretical theory that the Alto
did more to *slow down* Xerox in their mad rush for the information
systems of the future than it did to help them. Why? Because it's
far too small of a system to be anything more than a toy, in the sense
of providing enough power to support a very good programming
environment.
For example, because the Alto was so successful as a workstation
within Xerox for the past few years, everyone was saddled with them;
this included even the SDD folks, who were chartered to pull together
the PARC tinkerings into some sort of reality (the Star and its
satellites). To build even a medium-sized system in Mesa would
require hours and hours of sitting at an Alto (well, doing other
things), and thus, for things like BravoX (SDD folks out there, please
correct me if I'm wrong), building new systems would take far longer
than if some sort of time-sharing system had been around to do the
crunching needed. Only recently did the SDD folks get Dolphins, and
even these were no huge step forward. The Dorado is confined mostly
to PARC and certainly is too expensive and flakey to replace all the
Altos within the Xerox companies.
In my opinion, the only workstation worth even considering at this
point is the Lisp Machine, as purveyed by Symbolics and LMI. Even the
current generation beasts are rather underpowered for what they're
trying to do; this is supposedly being solved by the next generation
of machines (the only one in the works, as far as the public knows, is
the Symbolics 3600).
Why do I make this extravagant claim, given all the incredibly
wonderful workstations around, such as the Apollo, the PERQ, the
Wicat, the SUN? The reason is software (isn't it always), even
ignoring the pitiful hardware being touted these days as the latest,
greatest thing since sliced bread. The Lisp Machine comes with dozens
of man years of software investment, and those are years invested in
what is by far the most synergistic environment you could hope for,
given the state of technology. I would make the claim that nothing
else comes within 5% of matching that environment, though I have no
way of proving that claim. A good indicator might be a simple
anecdote about IJCAI '81: when the Three Rivers folks actually sat
down with a Lisp Machine (in a nearby booth), they were astounded (I
shouldn't put feelings in their hearts, and this was reported by a
Lisp Machine type, but I can certainly understand any astonishment,
having seen the PERQs and having worked with Lisp Machines!)
Admittedly, other people have gone long ways towards building
excellent environments (the Cedar project at PARC, and the LRG people
at PARC with their various Smalltalk systems); however, it'll be
years, if ever, before the world gets the benefit of the first, and
Smalltalk is a fairly impressive system, but still has some questions
about viability in "the real world" (for example, Smalltalk 80/81/82
still lacks multiple inheritance).
I guess what triggered this whole flame was the sight of the pitiful
systems being proposed by the real world as useful working
environments. The Xerox, IBM, HP and DEC new "personal systems" are
abject horrors (CP/M, my foot). PERQs are just beginning to get
simple operating systems with real file system support. Every 68000
incarnation in the world has its Unix lookalike, or a XENIX hovering
in the wings. I make the bold claim that NONE OF THEM has anything
interesting to offer other than, perhaps, a large screen.
End of flame.
------------------------------
Date: 5 Oct 1981 10:21 PDT
From: Fenchel.ES at PARC-MAXC
Subject: Symbolic Systems Inc. Personal Computer
Is anyone familiar with products/planned products of Symbolic
Systems Inc. (or is it Symbolic Inc.). They are based in Los
Angeles and rumor has it they are building a Lisp machine and
an Ethernet interface for it.
Any information will be appreciated.
Bob (Fenchel.es@parc)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #24
∂27-Oct-81 0107 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #24
Date: 27 Oct 1981 0144-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 27 Oct 1981 Volume 1 : Issue 24
Today's Topics: Xerox Altos
Symbolics LiSP Machines
----------------------------------------------------------------------
Date: 26 Oct 1981 1035-PST
From: Tom Wadlow <TAW at S1-A>
Subject: Alto Flamage
Chris Ryland claims that the Alto development and general use
held back the development of better things at Xerox. My question
is: Compared to what?? The Alto was developed around 1972,
and is clearly obsolete today. However, I would still rather
have an Alto than the fairly unintelligent terminal I work on
today. If Xerox had waited for Dolphins or Stars, their people
would be getting them right about now. With the Altos, Xerox
has had several years of *very* valuable experience in office
information systems. If they had not used Altos, chances are
that their people would have spent those years working on
80x24 character terminals and hated it, while Xerox learned nothing.
Another point. While I agree that a Lisp Machine probably provides
the best programming environment around today, an Office of the
Future is not entirely a programming environment. The Alto got
advanced office automation software into the hands of its intended
user community: secretaries and managers and other non-programmers.
And I strongly suspect that the experience gained from that move
is heavily reflected in the design of the Star. The widespread
use of the Alto was a necessary step in the development of
the current generation of Xerox products, not a hindrance.
------------------------------
Date: 26 Oct 1981 2228-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Symbolics; Alto snipe
Symbolics does manufacture a personal workstation; see my previous
WorkS message about the Lisp Machine. They will support Ethernet
hardware on the next version of their machine (the 3600), but it will
speak Chaosnet protocols softwarily (of course, I shouldn't prejudge
their longer-range plans about protocols; one can assume they'll
attempt to live compatibly with other Ethernet protocols via suitable
encapsulation on the 10Mhz ether). Call them in LA if you want more
info. (No, I don't get any commissions from them.)
Let me clear up my previous "Alto snipe" lest I appear completely
insane. I stated my position about the Alto somewhat provocatively,
but I didn't mean to imply that Xerox has made some huge mistake in
using the Altos extensively in-house; they never had much alternative
(I also wasn't pushing for time-sharing systems, but rather advocating
powerful servers for when you need to crunch). What I meant, rather,
was that the outside world has always been dazzled by the Altos, which
are, when you get down to it, rather "cute". However, their "punch"
is fairly minimal, and they have always lacked the kind of
comprehensive environment which makes a system such as the Lisp
Machine so attractive. For example, although various Smalltalks on
various Xerox machines (not copiers; Altos, Dolphins, Dorados) do
provide a fairly comprehensive computing environment, they've never
had an editor or a mail system in common use built-into the Smalltalk
environment. I.e., Altos and Dorados tend to be used as tiny
single-user "timesharing" systems, in which you have the usual
executive/program dichotomy. (I used Altos enough at MIT to learn to
dislike them, though they're wonderful intelligent terminals.)
On the other hand, the Lisp Machine provides a completely homogenous,
"vertically integrated" environment, in which the editor, mail system,
compiler, network file server (yes, each machine has a file server),
network file user, local file system, interpreter, window system,
etc., are completely useable at any level by any user (Lisp!) program.
The folks who built these machines at MIT (now dispersed to various
companies) spent a lot of time making the system software
comprehensive and useable.
For example, someone here wrote an Alto Draw equivalent (roughly the
same functionality, without all the bells and whistles) on the Lisp
Machine in a week of spare time hacking (mostly spent learning the
window system); in otherwords, there is a vast range of functionality
available through the system software, which is fairly easily extended
via Flavors.
This is not to say these machines are without problems. For example,
the system, as you boot it up, occupies about 5 megabytes of virtual
memory. That's fine, but clearly, you need a good deal of real memory
to make things work reasonably (1.5-2 megabytes seems to be
comfortable). And, these machines are NOT fast; no one has been able
to compare them to other machines to anyone else's satisfaction, but
there's a general feeling that they're faster than a KA-10 and 2-3
times slower than a KL-10. They don't do arithmetic very rapidly (an
integer add seems to take more than 10 usecs, for example), but this
isn't a fair yardstick for their basic speed. A lot of speedup is
promised for the Symbolics 3600, esp. in the area of function calling
and message passing.
Perhaps I can best summarize this flaming with a suspicion which only
time will bear out: to provide the kind of comprehensive computing
environment which the Lisp Machines are approaching, you're going to
need a heck of a lot of hardware power (virtual memory, microcode
space, raw microengine speed, paging disk speed, etc). And I don't
think any of the other current offerings come close. I don't mean to
say that you can thus write off all the workstations on the market,
but that you can't expect them to provide anything else than a
bare-bones world, or a fairly tightly-bundled, special-purpose
environment (such as the Star). That's sad, because the "real world"
seems to be making all the mistakes of yesteryear all over again (it
happened with micros and it'll happen many times more), instead of
starting with the best that we've got and building from there.
(I forgot to mention the Dolphins: they seem to be fairly good
Interlisp engines: Xerox EOS claims they'll be KL-10 speeds or better
after some software tuning. However, their major problem, for an
experimental environment, seems to be their lack of common bus
connectability.)
(Oh yes, though this is getting long-winded, I can't shouldn't slight
Xerox: they HAVE built a very good software development environment
for Mesa on the Dolphins and Dorados. But I don't think this'll see
the light of day for a while, if ever. And, Mesa is a compiled
language lacking more modern message-passing concepts (though I did
hear that the Star software was built with a Flavor-like package built
on Mesa), so you don't get the kind of dynamicity you would with Lisp
or Smalltalk.)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #25
∂27-Oct-81 2304 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #25
Date: 27 Oct 1981 2240-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 28 Oct 1981 Volume 1 : Issue 25
Today's Topics: MC68000 Paging Query
Lisp Machines: Not Everybody Likes To Program In Lisp
----------------------------------------------------------------------
Date: Friday, 23 October 1981 00:04-EDT
From: Goldberg (Robert N. Goldberg)
Re: MC68000 paging
Someone who works for a company that produces specialized computer
systems has been telling me that they decided to build their next
system around the Z8000 rather than the MC68000 because they had
serious doubts about being able to do paging on the MC68000. They
claim that there is a design problem that prevents instruction
resumption after a page fault. I understand that Apollo solves the
problem by using 2 68000 chips.
Having briefly studied the instruction set and architecture of the two
CPU's, I see the MC68000 as superior for the application of this
company (they want a large virtual address space that can be accessed
from a high level language, and speed is important), and it seems to
me that getting stuck with the funny segment addressing of the Z8000
will cause problems.
1) Is there a real problem implementing virtual demand paging on the
MC68000?
2) Can anyone tell me some of the problems one faces when generating
code from a compiler (e.g. C) for a segmented memory machine such
as the Z8000? I know that you have to do array subscripting
carefully, but what are some of the more insidious subtle problems
that come up?
Bob Goldberg
------------------------------
Date: 27 Oct 1981 15:14:19-PST
From: decvax!pur-ee!purdue!cak at Berkeley
Re: Lisp Machines
I may be called a heretic for this, but here goes. The Lisp Machine
sounds very nice...I was really excited when I first saw the
announcement. But,....
WHAT IF YOU DON'T WANT TO PROGRAM IN LISP?
I personally am not crazy about Lisp. It is good for some things, but
for most of my hacking, I prefer C (I fight with emacs because I have
to do my extensions in MLisp. I understand why, but I don't have to
like it.)
chris
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #26
∂29-Oct-81 0055 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #26
Date: 29 Oct 1981 0212-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Thursday, 29 Oct 1981 Volume 1 : Issue 26
Today's Topics: LiSP Machines - Not Just for LiSP
MC68000 Query - Answered
Hardware and Editor Technology
----------------------------------------------------------------------
Date: 28 Oct 1981 11:03:57-PST
From: ARPAVAX.ecc at Berkeley
Full-name: Eric C. Cooper
Subject: Languages and Lisp Machines
A friend at Symbolics told me that a comprehensive language project is
going on there; by the time the new machine is released, they expect
to have C, Pascal, and Fortran 77 (translated to Lisp, of course.)
Since routines in any of the languages will be mutually compatible,
they will be able to provide the same whizzy program development
environment that is already there for Lisp.
Also, in response to the question about network support, they seem
biased towards chaosnet, but may be swayed by their customers' needs.
They may even talk TCP/IP soon.
Eric Cooper (ecc@berkeley, ucbvax!ecc)
------------------------------
Date: 28 Oct 1981 1154-PST
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: C Compilers for the MC68000
cc: Milunovic at SRI-KL
I would appreciate any info on available C compilers and optimizers
for the 68000. I have heard rumors that the MIT compiler is 'better'
than Whitesmith's and would like to hear other comments. Please send
replies to milunovic@sri-kl and I will send a combined response to
Works. Thanks.
Steve...
------------------------------
Date: 28 Oct 1981 16:00:37-PST
From: ihnss!ihuxq!ihuxp!ljspot at Berkeley
Subject: MC68000 Paging Query
I have a report from John Gilmore, an independent consultant, which
has info on this problem. In brief, he states that:
1. On a page fault, the executing instruction can not in
general be identified.
2. There is no way to determine how far execution of the
instruction had progressed prior to the pafge fault.
3. Any executing instruction is aborted when a page fault
occurs due to instruction prefetch.
His report is titled "Suggested Enhancements to the Motorola MC68000"
and is 14 pages long. The report is copyrighted, but may be
reproduced if not for commercial advantage and credit for the source
is given. His address is:
431 Ashbury St
San Francisco, CA 94117
Voice: (415) 621-9355 ABBS(300 baud): (415) 863-4703
Hope this is of some use to you.
------------------------------
Date: 28 October 1981 23:55 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: Lisp Machines
Luckily, LISP has a much larger semantic space than most languages so
it is much easier to imbed a C, PASCAL, FORTRAN or whatever language
you wish to program into it than the other way around. I would not be
surprised if someone hacked up a PASCAL, ADA or FORTRAN front end for
the LISP machine which just transformed the source program into LISP
program and passed it to the compiler. I am less sure that someone
would be interested in doing this for C.
------------------------------
Date: 28 Oct 1981 09:39:39-PST
From: cbosgd!mark at Berkeley
To: CSL.BKR@SU-SCORE
Subject: Re: Hardware and Editor Technology
Cc: ucbvax!editor-people@Berkeley
[Forwarded to WorkS by Henry <Dreifus at Wharton>]
The SUN sounds wonderful, if you're willing to spend $5-7K each for
them (which is reasonable in some industrial environments, but I find
it farfetched that a University would spend that kind of money on its
students for instruction) and if you don't want to work at home.
Couldn't you put a couple floppies and a modem on one of these things
and make it usable over a dialup? If you're already spending $5K,
another $1500 seems insignificant for the extra capability.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #27
∂29-Oct-81 2312 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #27
Date: 30 Oct 1981 0041-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Friday, 30 Oct 1981 Volume 1 : Issue 27
Today's Topics: More On MC68000 Paging
Lisp Machine Vs. The Alto
----------------------------------------------------------------------
Date: 28 Oct 1981 1041-PST
From: Ian H. Merritt <MERRITT at USC-ISIB>
Subject: Re: [Goldberg] MC68000 paging
To: works at RUTGERS
I have heard that the solution to the problem is simple: use 2 chips,
one for the main processor; the other for the pager. The reason that
the instructions may not be restartable is because of the way
auto-inc/auto-dec is handled. Restarting the instruction would result
in the register being modified twice. The two processor solution is
to have the page trap cause the second processor wake up, while
asserting a *LONG* wait state on the first. The second processor then
checks the error registers and determines the necessary action,
fetches the page, and clears the latch which is holding the primary
processor hostage. This, in turn, puts the secondary processor in a
wait state until another page is required.
As for the capability of the two processors... I would agree: the
MC68000 is by far the better of the two.
<>IHM<>
------------------------------
Date: 28 Oct 1981 0451-PST
From: SCHIFFMAN at SRI-KL
Subject: Paging on the 68000
cc: schiffman at SRI-KL
Yes, it is not really possible to do vanilla paging on the 68000.
It's rather cruel to think of this as a flaw in the design, since the
other microprocessors in its class have similiar problems (e.g. Z8000,
I8086).
Basically, ANY processor which has "page-faultable" instructions that
have side-effects must take heroic steps to make the instructions
re-startable. For example, auto-incrementing address modes in a
PDP-11'ish instruction:
MOVE -(R0),(R0)+
if the either of the memory references fault, you can't restart from
the top.
You can keep extra bits of "micro-state" to remember where you were
when you faulted, so that you can restart from there. In a complex
architecture, this may mean keeping "shadow-registers" or completely
saving the "micro-state" -- VERY hairy. One particularly silly way
to save the micro-state is to switch out the processor and switch
another one in to handle the page fault! (But if you didn't design
the processor you may not have had a choice). The main reason why it
loses is that you can't do anything else while waiting for the disk
page to roll in (yes Virginia, even personal machines have multiple
processes).
Alternatively, you can simplify your architecture so that instructions
that can cause a fault don't have side effects. Intel, for example,
will be using "demand-segmentation" in the iAPX286 -- the only thing
that can cause a fault is loading a segment register -- and those
instructions are simple to restart. It is also possible to just make
these restrictions by software convention (ha!).
Zilog, Intel and Motorola all claim that they will shortly have new
versions of their processors that permit restarting of memory faults.
Because of the extremely restrictive way that they address memory,
Intel will have the easiest time of it.
My estimation is that the MC68000 and the Z8000 will be about equally
difficult (for the manufacturer) to turn into a "virtual-memory"
version.
BTW, I might mention (at the risk of appearing biased) that there are
microprocessors that already handle true demand-paging:
Intel iAPX 432
National NS16000
Fairchild F9445
although all three have problems of availability!
-Allan
------------------------------
Date: 27 Oct 1981 15:37 PST
From: Deutsch at PARC-MAXC
Subject: Ryland's comments on Xerox Alto
The Lisp Machine is a much larger, MUCH more expensive system than the
Alto. Here at PARC we were quite aware of the fact that we exceeded
the Alto's capacity to do things that were interesting to us sometime
around 1976. If non-technical factors had not intervened, we would
have had Dorados (which knock the present Lisp Machine flat on its ass
in terms of hardware power, both absolute and per dollar) not long
thereafter.
The Smalltalk environment is as integrated as that of the Lisp Machine
-- more so, in my opinion, in that a much smaller part of the system
is written in any language other than ordinary user-level Smalltalk
(no subprimitives, etc.). The Lisp Machine environment offers a
larger range of features and services largely because more people
interested in programming environments per se have worked on it on
more powerful machines for a longer period of time, while the
Smalltalk builders at PARC have been concerned with other things.
------------------------------
Date: 29 October 1981 22:58 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: MC68000/Z8000 Paging Query
Reply-To: Frankston at MIT-Multics (Bob Frankston)
It is not the Z8000 itself that handles faults, but the Z8003
(formerly the Z9000) -- an updated version. Supposedly an
updated 68000 is planned. Using two processors where the
second process the fault while the first is suspended does
allow one to handle page faults on the 68000, but the page
handler must not itself take page faults -- a limitation on the
architecture of an operating system. It also means that no
other processing can be done on the main processor until the
fault is satisfied.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #28
∂01-Nov-81 2227 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #28
Date: 1 Nov 1981 2353-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Monday, 2 Nov 1981 Volume 1 : Issue 28
Today's Topics: Lisp Machine Language Support
Demand Paging On iAPX 432
Backing Out Of An Auto{inc|dec} Instruction
Symbolics 3600
Altos & Dorados & LispMs & Dolphins
Paging (Or Lack Thereof) On The MC68000
----------------------------------------------------------------------
Date: 1 November 1981 23:38-EST
From: The Moderator <JSol at Rutgers>
Subject: Administrivia
[Due to a small hardware problem, some of you received multiple
copies of Friday's digest (V1 #27), sorry -JSOL]
------------------------------
Date: 30 October 1981 01:49-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Languages and Lisp Machines
Eric Cooper is correct: Symbolics will support Pascal, Fortran 77, and
C on the 3600. This may work by actual translation into Lisp, or by
translation into an intermediate representation inside the compiler.
------------------------------
Date: 30 October 1981 0755-EDT
From: Hank Walker at CMU-10A
Subject: autoinc/dec
It isn't that hard to implement autoinc/dec. The 11/780 has an RLOG
stack containing 9 locations of 5 bits each (I think). Whenever you
do an autoinc or dec, you push the inc or dec value on the stack. On
a fault (any kind of fault), the microcode pops the stack values and
reverses the operations. I can think of lots hairy problems with
backing out of instructions than this.
------------------------------
Date: 30 Oct 1981 (Friday) 1154-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
The intel iAPX 432 does not support any form of demand paging, but,
rather, has a fairly primitive segmentation scheme. This scheme
allows segments to either be entirely swapped in or not in memory at
all. The dual 68000 implementation allows for true demand paging with
the restrictions already enumerated. Other 68000 solutions include
restricting the instructions that a compiler will generate so that the
page fault address can be detected and the code resumed (using only
one 68000). Motorola is in the process of coming out with a new 68000
that corrects the "bus error" problem and some really minor
annoyances.
Jamie Frankel
------------------------------
Date: 31 October 1981 02:51 est
From: HGBaker.Symbolics at MIT-Multics
Subject: Symbolics 3600
36-bit machine, 2↑28 word address space (1 billion bytes)
32-bit immediate (non-consed) integers, IEEE float
instruction fetch unit
instruction + stack cache
2↑24 word physical address capability
512K words memory/card
4-5 slots for memory cards
67, 160, 300+ Mbyte winchesters
10 Mbit Ethernet
800 rows of 1000 dots B/W
1K x 1K color, 8 bits/pixel
68000 I/O controller
Multibus.
basic configuration <$60K for quantity 10.
Ethernet protocols subject to availability from Xerox Corp and
reasonableness.
------------------------------
Date: 31 Oct 1981 1019-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: one last apologia; query for high-end users
In response to Peter Deutsch's mail, I should once more emphasize that
my initial flame was mostly in reaction to the world's tendency to
adulate the Alto; as Peter pointed out, the folks at XEROX knew long
ago that they had outgrown the machine, but I don't think that's clear
to the world at large. I didn't intend to slight XEROX. And, yes,
the Dorado certainly "whup[s his] ass" off the current Lisp Machine,
though it's a little hard to determine the relative speeds, given the
different word sizes and internal data path sizes.
Now, my query, addressed to those of you who are contemplating using
personal machines for high-end, mostly stand-alone computational
needs, i.e., AI (speech, robotics, vision), VLSI design, physics,
etc.: what is your sense about the language base you'll need for your
work? This begins to approach "theological" issues, but I still think
it's an interesting topic.
For example, my feeling (shared by some, I hope) is that the only two
languages worth considering are Lisp and Smalltalk (I'm ignoring the
idea of embedding well-known languages such as Fortran and C in a Lisp
or other environment, to support those who don't want to deal with the
host language). The Lisp Machine and the Dolphin provide two rather
distinct approaches to the environment, but both provide Lisp. The
Dolphin, running Interlisp, is "pure" Lisp in the sense that it makes
no concessions in the arena of object-oriented programming. The Lisp
Machine is heavily object-oriented, with perhaps the most flexible of
all classification schemes imaginable, Flavors. The problem I see
with this dichotomized world of Lisp and Flavors is that, though
people are hard at work turning more and more of the Lisp Machine
world into objects which are dealt with via message-passing, there
will always be the basic objects such as fixnums (integers) and conses
which aren't objects in the Flavor sense. This fundamental dichotomy
can't be good, in that it requires two different styles of programming
and thus requires some additional and perhaps needless complexity.
Of course, there are those who must use Lisp, so the Dolphin and the
Lisp Machine appear to be the only hope we've got. (The SpiceLisp
PERQ is still a question-mark, but it's hard to imagine it being as
powerful as the other two, in nearly any sense of the word "power".)
Now, Smalltalk presents us with a choice: it is certainly as capable
as Lisp, though it certainly requires a distinct approach to most
problems, and yet it is probably 1-2 years away from even beginning to
be used widely. And, it's not clear that it will enjoy the same
popularity in the research community that Lisp does (for whatever
reasons, which probably won't be technical). Further, it will
probably be 1 year at least before it is solidly up on an acceptable
machine, such as the Dolphin, Lisp Machine, or what-have-you hardware.
Can you wait for something which isn't a sure bet yet?
Yet, Smalltalk also appears to have a good chance to be widely
available on every imaginable size of machine, which can only bode
well for the availability of good software, people versed in the
language, transport- ability of research software into the "real
world" (and vice-versa), etc. For example, it is confirmedly rumored
that DEC is basing their personal VAX's system software (the SUVAX) on
Smalltalk, and this system has a rather good graphics interface. Of
course, HP, Tektronix, Apple, and DEC have been working with the
pre-release of Smalltalk for nearly a year now, so that provides
further reason to believe that it will have acceptance in the
industry.
Enough speculation. Comments?
------------------------------
Date: 31 Oct 1981 0143-PST
From: SCHIFFMAN at SRI-KL
Subject: Re: Demand paging on iAPX 432
To: FRANKEL at HARV-10
cc: schiffman at SRI-KL
The Intel iAPX 432 does not support any form of demand
paging, but, rather, has a fairly primitive segmentation
scheme. This scheme allows segments to either be entirely
swapped in or not in memory at all.
``Primitive segmentation''??
When you think about it, pages are only fixed-size segments that must
"either be entirely in memory, or not at all". Segmentation is
clearly a more "sophisticated" quantum of memory management because
objects don't come in fixed sizes. Unfortunately for computer
architecture, it is difficult to ALLOCATE memory if you don't pretend
they do.
The 432, which can have umpteen thousand segments defined at a time,
(with each one being a typed protection domain) is considerably more
sophisticated when it comes to virtual memory management than any
other microprocessor will be for a LONG time. In fact, it is more
sophisticated than [almost] ANY existing computer's memory management
architecture.
Of course, the implementation is such that only a few segment
descriptors are cached simultaneously, which leads to poor
performance.
In fact, I think that the 432 is going to suffer for a long time due
to its lack of "primitiveness".
-Allan
------------------------------
Date: 1 November 1981 02:28-EST
From: Leonard N. Foner <FONER at MIT-AI>
Subject: Paging on the MC68000
Yes, there is a definite problem with paging with the MC68000 chip.
I worked on a design team about a year ago that, among other things,
was going to implement a virtual memory system using the MC68000 as
its CPU. Among various problems we ran across (such as only ONE
interlocked instruction, when you really needed at least two) was the
problem of paging.
As it turns out, the MC68000 does not save enough state on such a
fault to be able to recover completely. It misses about two status
bits. I don't have my manual handy, and it's been a while since I
looked at this problem (the project ended about 9 months ago), but it
most definitely would not do paging right. This made it quite
difficult to come up with a robust paging system.
The general idea we came up with was that paging on the MC68000 was
easily possible if certain instructions were avoided (or, alternately,
could be guaranteed never to fault upon execution, a rather diffcult
constraint).
If people are interested, I will go back through my old design notes
and see exactly what the problem was. It was not insurmountable (since
we figured out at least one way around it, as I recall), but it was
definitely an inconvenience.
I don't know about this system with two MC68000's in it, but from the
description it sounds like they're using one chip to keep track of
state for the other... a klugy solution at best, of course, but
better than having to eliminate virtual memory as an option.
Note that, even using two processors and having one wait for the other
to handle paging, you can keep track of the most recently paged-out
pages in memoyr and so decrease your hits on disk paging. VAX/VMS,
for instance, does this. Then you can do a fast (no disk activity)
page for most faults (VMS hits almost all the time except for programs
that do a LOT of random paging, which is rare... and demand-zero
pages (i.e., fulll of zeroes because they've not been used yet) are
easy to do without any disk access). The only time the processor
waits is when a fault really has to involve the disk. Then you're
stuck, since you can't run any other processes while that happens.
Have fun. if you want more info, ask and ye shall receive...
eventually.
<LNF>
[By the way, your message in yesterday's digest appeared with a From:
field of simply Goldberg. Since I don't know where you are, this goes
to the whole list without mailing to you directly, which is somewhat
impolite of me but necessary under the circumstances. JSol: if
Goldberg is at Rutgers, please make sure that the @RUTGERS winds up on
the message...]
[Oops - that makes two apologies this digest. A record? -JSOL]
------------------------------
Date: 1 Nov 1981 (Sunday) 2224-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
When segmentation is the only form of memory management, it must be
used for both protection and typing, and storage allocation. The
advantage of having both segmentation and paging is that there are two
distinct mechanisms to handle the two problems. It is often true that
segmentation alone is sufficient to solve both, but not always. The
problem with paging is that the context of the data areas of the
original problem is lost and the memory management unit must attempt
to ascertain the working set of pages the program is using. The
problem with segmentation is that it is often the case that only a
small section of a object is to be touched yet the whole object must
be swapped in.
In the 432, the segments are limited to 64K -- too small for many
large arrays used in various applications {This problem can be
resolved by using levels of arrays of pointers to achieve the desired
size}. On the other hand, if one would attempt to implement LISP on
the 432, one would find that there are not enough segments to allow
each dotted pair or even each list to be a separate segment.
In many respects there are a large number of existing computers with
at least as sophisticated an MMU.
The 432 is certainly a large accomplishment for microprocessors and
(except for its poor performance) should find good acceptance in the
Pascal/Ada market.
Jamie Frankel
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #29
∂02-Nov-81 2347 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #29
Date: 3 Nov 1981 0136-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 3 Nov 1981 Volume 1 : Issue 29
Today's Topics: Programming Languages
Dual CPU Paging Implementations
Paging Vs. Segmentation
Demand Paging On The iAPX 432
More On The Alto User's Handbook
----------------------------------------------------------------------
Date: 2 November 1981 02:51-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Programming languages
I agree that Smalltalk's uniform use of message passing for all
operations is more simple and elegant than the Lisp Machine's mixed
use of simple (non-generic) function calls and (generic) message
passing. However, I think that it would be very hard (though maybe
not impossible) to use message passing everywhere without sacrificing
a great deal of speed. In practice, it does not seem to hurt is much;
the language has function calls and it has message sends, and both do
argument-passing the same way; the only difference is that in one case
you name a function directly, and in the other you specify an object
and a message name, and the flavor system finds the function (the
"method") for you. We use function calling for simple things, and
full message passing when the modularity is interesting enough to
require the added flexibility and control that message passing gives
you.
------------------------------
Date: 2 November 1981 11:26 est
From: Sibert at MIT-Multics (W. Olin Sibert)
Subject: dual CPU paging implementations
Sender: Sibert.Multics at MIT-Multics
In the ones I'm familiar with, the implementation is very simple: the
"problem" CPU simply experiences a VERY long memory cycle (many
milliseconds) when it tries to access a page which the outboard memory
management unit sees is not in core. No state saving, or complicated
deductions about the processor status are required. The "supervisor"
CPU simply waits all the time until the MMU notifies it that it should
bring in a page, at which point it runs, does the I/O, restarts the
other CPU, and goes back to sleep.
This didn't work reliably with some early MOS microprocessors because
they couldn't stand to have the processor clock stopped for more than
about 5 milliseconds or so.
This is really a pretty cheap way to implement paging, all things
considered. The two CPUs run from the same memory, using the same bus,
and CPUs are switched by tri-state buffers. CPU chips are pretty cheap
(even 68000s), compared to total system cost.
It's true that this doesn't do "real" multitasking on page faults, but
the system can still do real multitasking on other events, like demand
disk I/O and timers.
------------------------------
Date: 2 November 1981 11:35 est
From: Sibert at MIT-Multics (W. Olin Sibert)
Subject: paging and segmentation
Sender: Sibert.Multics at MIT-Multics
Ah, but there IS a fundamental distinction between paging and
segmentation, to wit: Segmentation is a mechanism for helping the
programmer manage information, and paging is a mechanism for helping
the computer system manage information.
A computer system uses paging in order to appear to have a larger
quantity of physical memory than it was given by its manufacturer. In
systems where the virtual and physical address spaces are comparable
in size (the IBM 370, for example), this primarily manifests itself in
the ability to multiplex several processes with the appearance that
each has all the system memory available to it. In systems where the
virtual address space is much larger (such as the VAX), it also
provides the appearance of much more memory to individual processes.
Segmentation, on the other hand, is a way for programmers to treat a
single region of storage, of arbitrary size, as an object. Depending
on the implementation, these objects may see many different uses-- if
segments are cheap and plentiful, they can be used in a much more
versatile fashion.
When a system provides only one of these mechanisms, it must be
twisted to provide the facilities of both. For instance, PDP-11 and
VAX addressing is used to provide both the compartmentalization of
segmentation and the load-based memory management of paging.
Ideally, the two mechanisms should be completely independent; the
effects of paging should never be directly visible to the programmer.
This is usually not quite true; for instance, in Multics, segments are
expensive, largely because each segment must be an integral number of
pages, at 4K bytes each.
Another problem is the allocation of segments in a linear address
space: as long as the address space in which segments are allocated is
large enough, garbage collection is rare, though fragmentation will be
a problem. In a small address space, segments must be constantly moved
and compacted to get free space. This problem is eliminated (but at a
cost) by using paging to permit pages of a segment to be allocated
anywhere in memory.
Note that yet a third level of indirection can be imagined, which
would permit pieces of segments to be relocated transparently, yet
still not be a multiple of the pagesize in length, so that segments
could be allocated in pieces throughout a large linear virtual address
space, which was itself paged. This gets complicated, though, and one
must draw the line somewhere.
It would be possible, for instance, to implement an APX-432 paging
system which used a dual processor approach to give the "problem"
processor the appearance of as much actual physical memory as the chip
can address, and use a "supervisor" processor (not necessarily a 432)
to read in pages from disk when they are found to be missing. This
would let the 432 programmer use segments with wild and gay abandon,
never explicitly reading them in.
------------------------------
Date: 2 November 1981 20:25 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Demand paging on iAPX 432
Reply-To: Frankston at MIT-Multics (Bob Frankston)
cc: SCHIFFMAN at SRI-KL, FRANKEL at Harv-10,
schiffman at SRI-KL
Paging ↑= Segmentation
Segmentation is address space management technique, though it is often
treated as a second level of paging.
Paging is a memory management technique used by the system, though
some systems are not careful about layering and let it show through to
the users.
Guess we need new words to avoid confusion not only due to word
inflation but architectures like the IBM /38 and probably the iAPX 432
which do not make sharp distinctions.
------------------------------
Date: 2 Nov 1981 14:42 PST
From: Taft at PARC-MAXC
Subject: Re: The Alto User's Handbook
In-reply-to: FURUTA's message of 23 Oct 1981 1607-PDT
To: Richard Furuta <FURUTA at WASHINGTON>
cc: jeff at WASHINGTON, Dake, Swinehart, Lampson, Taylor, Taft
Your message announcing the availability of the Alto User's Handbook
received rather wide distribution (for example, I believe it appeared
in the WorkS digest). I would appreciate it if you would convey the
following clarification to Editor-people and any other lists you know
about to which your original message was distributed.
While the Alto User's Handbook has indeed been cleared for
distribution outside Xerox, it has not been brought out as a PARC
external report. Our present supply of Handbooks is limited, and we
do not have the resources to satisfy the large demand that would be
generated by a public release.
Our past practice has been to sell Handbooks, at cost, to
organizations that have Altos (principally at CMU, MIT, Stanford, and
University of Rochester). But even this is ending, since we are no
longer actively developing or maintaining Alto software at PARC;
consequently, we are unlikely to reprint the Handbook again.
People who do not have Altos may be interested in more general
technical reports on the Alto and Alto-based software, available in
the open literature. The most comprehensive report on the
architecture of the Alto itself is "Alto: a personal computer", which
appears in the recently-published second edition of "Computer
Structures: Principles and Examples", edited by Siewiorek, Bell, and
Newell (McGraw-Hill). Additional good sources of papers relating to
the Alto and follow-on machines include the last two years' SOSP
proceedings and several issues of CACM.
We have published a number of PARC external reports on Alto-based
systems. These are available on request, though again we are unable
to satisfy an enormous demand. Many university and company libraries
subscribe to the PARC report series, so you may be able to find copies
in your library.
Ed Taft
Computer Science Laboratory, Xerox PARC
------------------------------
Date: 2 Nov 81 22:09:31-EDT (Mon)
From: Michael Muuss <mike.bmd70@BRL>
Subject: Re: WORKS Digest V1 #28
JSol -
I keep hearing about Smalltalk. Is there a good blurb online,
or something in the recent press that I can sneak a peek at? Seems
like there are enough enthusiasts out there, but it's new to me...
-Mike
[Don't look at me, I don't know much about it (except that it has been
discussed on WorkS). You are invited to peruse the WorkS archives at
MIT-AI, in DUFFEY;WORKS ARCHIV, or at Rutgers, in the <WorkS>
directory -JSOL]
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #30
∂04-Nov-81 0136 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #30
Date: 4 Nov 1981 0159-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 4 Nov 1981 Volume 1 : Issue 30
Today's Topics: Programming for Personal WorkStations
Smalltalk Info - BYTE Magazine
----------------------------------------------------------------------
Date: 3 Nov 1981 (Tuesday) 0910-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Programming for Personal Workstations
Are the techniques that will be used for programming personal
workstations going to be different to those of current scale
implementations?
How will one program workstations? Will it be easier? Will there
be other proceedures than those of large systems or simply a
reduced scale of large system design?
Hank
------------------------------
Date: 3 Nov 1981 (Tuesday) 2058-EST
From: KENDALL at HARV-10
Subject: Smalltalk info source, 432/Smalltalk juxtaposition
To: mike.bmd70 at BRL-, WorkS at RUTGER-
cc: KENDALL
The excellent August (July?) issue of \Byte\ was dedicated to Smalltalk,
written completely by members of the Smalltalk development group. This
is the best source of information about Smalltalk until the two books
come out.
If I remember correctly from that issue, the old Smalltalk virtual
memory system (called OOZE) allowed as many as 64K objects, but that
limit was reached, so the new system allows more than 64K objects.
This means that the Intel iAPX [what do those letters stand for?] 432,
which allows no more than 64K objects, would make a bad Smalltalk
engine.
-- Sam Kendall
[Thanks also to Ian H. <Merritt at USC-ISIB>, <TonyWest at PARC-MAXC>,
Steve Bellovin, Ed Pattermann <G.ECP at UTEXAS-20>, Chris <Ryland at
SRI-KL>, Jeff Prothero <JSP at Washington>, Ron Fowler <rgf at BRL>,
<Sternlight at USC-ECL>, Hank Walker at CMU-10A and Bob <Hyman at
DEC-Marlboro> for also pointing to the BYTE issue. -JSOL]
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #31
∂05-Nov-81 0835 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #31
Date: 5 Nov 1981 0456-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Thursday, 5 Nov 1981 Volume 1 : Issue 31
Today's Topics: More On Smalltalk
Programming Personal Workstations
Smalltalk, Paging/mmu on the 432
----------------------------------------------------------------------
From: Chris Ryland <RYLAND at SRI-KL>
Re: Smalltalk info
Peter Deutsch is probably the best person to reply to the query about
Smalltalk, but here's something: Smalltalk-80, the only Smalltalk to
make it out of Xerox, will be available sometime around the end of the
year. Adele Goldberg's group, (formerly?) called the Learning
Research Group, is going to publish "the book", which will tell you
all about the language, styles of use, etc., as well as the
nitty-gritty of what it takes to bring up the system (via a virtual
machine) on your favorite hardware; and, they'll license "the tape" to
organizations, said tape containing the "virtual image" and all the
system sources. With that tape, and the book, you can bring up
Smalltalk in its full glory by merely implementing the virtual
machine.
The big question at this point is how the tape licensing goes.
There'll be no problem or real expense for universities, of course,
but commercial firms will have to negotatiate with Xerox lawyers
according to their intended use of Smalltalk (e.g., for internal use
only, or for resale).
Adele may want to say something over this medium to clear up any
confusions, but, then again, we might as well wait the couple of
months it still seems to be before the book is published and the
licensing arrangements announced.
(There are said to be pirate copies of the book floating around, but
they're useless at this point, in any case, as they're rather out of
date. This is by hearsay.)
------------------------------
Date: 4-Nov-81 11:26:04 PST (Wednesday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Programming for Personal Workstations
Reply-To: Hamilton.ES @ PARC-MAXC
cc: DREIFU at WHARTON-10 (Henry Dreifus), Hamilton.ES
"Reduced scale" my eye! Over a thousand man-months and a
quarter-million lines of Mesa have gone into Star, with roughly thirty
programmers going at it for roughly three years. And that doesn't
include the underlying Pilot/ Mesa/ Communications stuff, which would
add another 50 to 100 %. I don't know how that compares with OS/ 360,
but it certainly qualifies as a large system. And one can imagine all
sorts of applications built on top of Star or similar workstations
(data base, information retrieval, realtime data acquisition and
analysis, ...) that would be of a similar scale. In fact, almost any
application more sophisticated than running the payroll is probably
amenable to a distributed implementation.
--Bruce
------------------------------
Date: 4 Nov 1981 1139-PST
From: Rubin at SRI-KL
Subject: Smalltalk on the 432
cc: kendall at HARV-10
Actually, the iAPX 432 would make a very good Smalltalk engine. It
supports 16M segments, not 64K, so object address space is not a
problem (64K is the size limit for any one segment -- probably not a
problem for Smalltalk, but a big limitation otherwise). The 432's big
win for Smalltalk would undoubtedly be its fancy context switching
(with dynamic memory allocation, even!) and hardware support of typed
domains. Since domain objects can be linked into complexes, the 432
also lets you realize the Smalltalk concepts of classes and instances
almost at the hardware level.
People seem to think the 432 will be really slow, but I'd be
interested to know if Intel has got any benchmarks yet. Based on
their initial literature, the 432 looks about as fast as a mid-range
mini for typical stuff, but it is faster than probably anything else
if you look at its operating system primitives (e.g., send message is
80 microsecs, and their send primitive is fancy). Of course, the
question is whether those primitives are useful as they stand, or
whether you need to crust a lot of software around them to get a
decent kernel. If not, response time and throughput at the
application level should be quite high (except for number crunching)
because of the incredibly low OS overhead.
By the way, my guess for the iAPX acronomym is: i -- Intel, A --
Advanced, P -- Processor, X -- makes it sound scientific (or maybe the
X stands for *, in other words, multiprocessing).
--Darryl
------------------------------
Date: 4 Nov 1981 20:31:41-PST
From: ARPAVAX.hickman at Berkeley
Subject: paging/mmu on 432
1) As for the 432 segmentation setup being too small, that is what
Prime uses for their segments, and it works just fine. As for
arrays that are larger than 64k, lifes tough all over, isn't it?
2) The nastiest page fault problems come not from auto{inc,dec}rement
stuff, but from instructions which modify memory/registers in a non
un-doable way...That is, the AND/OR type instructions....Apparently
(I am told) on the 68000 it IS possible (using the 2 chip) scheme
AND limiting the instrucitons generated by the compilers (and
assemblers, for good measure). This scheme is used in the Micro Da
Sys 68000 system and works fine...
3) If I can buy a personal computer that runs virtual vax unix on a
68000, even with the pageing brain damage, I'll take it.
kipp
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #32
∂06-Nov-81 0417 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #32
Date: 6 Nov 1981 0631-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Friday, 6 Nov 1981 Volume 1 : Issue 32
Today's Topics: Apollo Domain Systems
Software Engineering - OS/370 vs. Star
Laurel Manual Available
Fewer Programmers On Tomorrow's WorkStation
System 38 - Description Query
----------------------------------------------------------------------
Date: 5 Nov 1981 0544-MST
From: Griss at UTAH-20 (Martin.Griss)
Subject: Re: WorkS Digest V1 #31
I might comment that the Apollo Domain systems are 68000 based, do use
the 2 68000 hack to provide the VM. They run a multiprocess OS,
somewhat UNIX(tm) like; one can get about 5-9Mb per process. The
machines also communicate very smoothly across a Ring network, and our
experience with the OS, VM and network is very positive. We run their
PASCAL and FORTRAN, use some ASM too. There is likely to be a C, a
"eunice-like" system, and maybe even a full V7 Unix.
------------------------------
Date: 5 Nov 1981 0940-PST
From: Jim Archer <CSL.SUN.ARCHER at SU-SCORE>
Subject: Why would anyone want to use OS/360 as an example?
To: Hamilton.ES at PARC-MAXC
I believe OS/360 passed 3 man-millenia somewhere in the early 1970's.
Given the general relationship between total effort and the quality of
the final product, pointing out that Star may have taken 200 man-years
tends to make me suspicious rather than confident.
Jim
------------------------------
Date: 5-Nov-81 11:46:35 PST (Thursday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Why would anyone want to use OS/360 as an example?
To: Jim Archer <CSL.SUN.ARCHER at SU-SCORE>
Reply-To: Hamilton.ES @ PARC-MAXC
Before you get too "suspicious rather than confident" regarding Star,
let me remind you that the project started some four or five years ago
from ground zero -- all new hardware, microcode, network protocols,
etc. Permit me to recommend Hugh Lauer's paper, "Observations on the
Development of an Operating System" (which discusses the development
of the Pilot operating system kernel underlying Star and the other
Xerox 8000 series Ethernet products), to be published in the
proceedings of the ACM/ SIGOPS 8th Symposium on Operating System
Principles next month. Lauer's thesis is that every major new
operating system takes around five clock years and dozens of man-years
to move from conception to maturity.
--Bruce
------------------------------
Date: 5 Nov 1981 1204-PST
From: Rubin at SRI-KL
Subject: Star vs OS/360 manpower
To: hamilton.es at PARC-MAXC
If a 1,000 man months gets you a Star, then OS/360 should have been a
universe. That system took 20,000, according to what I have heard.
Excuse me, that's 20,000 man years. If you like comparisons, I
believe it took the Egyptians about 20,000 man years to build the
Great Pyramid at Cheops. In fact, the architecture of OS and its
descendants rather reminds one of the Great Pyramid (not that I'm
trying to compare IBM to pharaoh).
Who knows, it may even last as long.
--Darryl
------------------------------
Date: 5 Nov 1981 11:17 PST
From: Taft at PARC-MAXC
Subject: Laurel manual available
cc: Dake at PARC-MAXC, Taft at PARC-MAXC
Those of you who wanted to obtain Alto User's Handbooks may be
interested to know that an expanded version of the Laurel Manual,
which constituted one section of the Handbook, has recently been
brought out as a PARC report. The abstract is reproduced below. If
you would like a copy, please send a message to Sara Dake
<Dake@PARC-MAXC>.
Laurel is a user interface to an electronic mail system.
Complementing it is a mail transport mechanism called Grapevine, which
maintains a distributed data base to deal with naming, authentication,
distribution lists, and mailbox location. A paper on Grapevine will
be presented at next month's SOSP.
Ed Taft
-------------------
Laurel Manual
by Douglas K. Brotz
Abstract: Laurel is an Alto-based, display-oriented computer mail
system interface. It provides facilities to retrieve mail and present
it for delivery, and to display, forward, classify, file, edit, and
print messages. Additional features include facilities to read,
write, and copy files, run programs, and a whole lot more. Laurel is
a component of a distributed message system that has been in operation
for several years in the Xerox Research Internet.
This document is a description of the facilities contained in Laurel.
Several tips on proper use of computer mail facilities in a social
context are included.
------------------------------
Date: 5 November 1981 18:57 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: New programming styles on Work Stations.
I think that the largest single difference will be the
relatively smaller number of programmers at the level we
traditionally consider programming. Instead of 3% or 25% of
all people who use a system programming it at the bit or
language level only .1% or .03% will be doing this on the Work
Station of the future. How many people double clutch anymore?
A much larger group will still consider itself programmers
although they will be dealing with constraint oriented systems
such as DNA sequencers, VisiCalc, simulation systems, Star and
so on. While many old time bit shovelers won't consider this
programming it will be considered so by most people.
The quantities of (what is now called) programming which will
go into these systems will be immense, but the dividends will
be equally large. My feeling is that a lot of those early
computer pioneer predictions will come to pass in the next few
years.
------------------------------
Date: 5 November 1981 18:53 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: paging/mmu on 432
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: ARPAVAX.hickman at UCB-C70
Prime allows segments to be concatenated. This allows arrays >64K,
but does seem to miss the point of segments as independent objects.
------------------------------
Date: 5 November 1981 16:18-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: System 38
Is there any information available on the detailed structure of the
IBM System 38?
Stavros Macrakis
Harvard
------------------------------
End of WorkS Digest
*******************
-------
Subject: Works Digest V1 #33
∂07-Nov-81 1423 Jonathan Alan Solomon <JSol at RUTGERS> Works Digest V1 #33
Date: 7 Nov 1981 1631-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: Works at Rutgers
To: Works: ;
WorkS Digest Saturday, 7 Nov 1981 Volume 1 : Issue 33
Today's Topics: Smalltalk Usefulness
Information on IBM System 38
WorkStation Languages
TI 16-Bit Chip
----------------------------------------------------------------------
Date: 6 Nov 1981 09:09 PST
From: TonyWest at PARC-MAXC
Subject: How to get IBM System/38 Documentation
To: Stavros M. Macrakis <MACRAK at MIT-MC>
cc: TonyWest at PARC-MAXC
About finding out more technical information on the IBM System 38:
There was a nice collection of technical papers published by IBM in
1978. You might try to get hold of it:
"IBM System/38 Technical Developments" published by IBM GSD (then)
publication order number G580-0237
However - I think this report is out of print, in which case, what I
recommend is that you call an IBM branch office, tell them about this
report and what you want, and ask them to look up for you the list of
publications available for the S/38 (which has since been announced,
so there is plenty available about it). All Branch offices have a
list of publications and can order them for you (though you may have
to produce some money sometime for the books).
Tony West
Computer Science Laboratory
Xerox PARC
------------------------------
Date: 5 Nov 1981 01:07:49-PST
From: decvax!ittvax!cox at Berkeley
Subject: Suitable workstation languages?
Being of the Evolutionary, rather than Revolutionary, school of
thought I've been concerned over means for experimenting with a
language like Smalltalk on a UNIX (i.e. READILY portable TODAY) base.
The approach so far has been to use the C compiler as an "assembly
language" for a virtual Smalltalk machine; i.e. to develop a Smalltalk
compiler that produces C language as output, and then bootstrap from
this to versions that bring up more and more of the stuff that UNIX
doesn't help with (automatic garbage collection, incremental
compilation, etc, etc.).
The part that works so far is as follows: a C precompiler (of the
lex/yacc school) reads a language close to C, and turns that into C
language containing data initialization statements that define class
relationships, in a manner as close to Smalltalk as I can glean from
the available information. So with this one can experiment with
programming in objects, classes and messaging, although the input
syntax isn't Smalltalk 81 and most of the Smalltalk 81 environment is
also missing.
The next step isn't working yet, but should be soon, which is to
complete a (non-incremental) compiler for Smalltalk 81 syntax, which
uses primitives generated from the step above for data storage.
This compiler generates interpreted code, for which an interpreter
will be written (in preprocessed C).
Subsequent steps can also be envisioned, but I'll probably stop
this approach well short of "Complete Smalltalk on UNIX".
Any interest out there?
------------------------------
Date: 6 Nov 1981 (Friday) 1236-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Can smalltalk work ?
Technology wise we will probably see an S-machine, microcoded to do
the byte-code operations very efficiently.
Will the 'programmers of tomorrow' use this concept in programming
versus classical PASCAL/Fortran/ . . . styles ?
Hank
------------------------------
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: Size of OS/360
In "The Mythical Man-Month", Fred Brooks estimates that over 5000
man-YEARS went into OS/360 between 1963 and 1966.
------------------------------
Date: 5 Nov 1981 09:05:36-PST
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
Subject: TI 16-bit chip
TI introduced a 24-MHz TMS99000 MPU, with a $65 price in 100-piece
quantities. (Quotes from the Nov. 2nd Electronic News).
It includes an "on-chip macrostore memory with 1K bytes of ROM and 3K
bytes or RAM for storage of frequently-used functions which can then
be accessed at full processor speeds." The company is preparing a
chip version using that macrostore for floating point operations, and
said that part, designated the TMS99110, would be available in
December at $99. The instruction set is a superset of the TMS9995 and
TMS9900, with object code compatibility. There are also new
instructions for multiprecision arithmetic, stack operations, parallel
I/O, and memory bit manipulation. It has "an instantaneous address
reach of 256K bytes of main memory and 120K bytes of internal and/or
external macrostore memory", as well as compatibility with the
TIM99610 memory mapper for control of address space up to 16M bytes.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #34
∂11-Nov-81 0224 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #34
Date: 11 Nov 1981 0156-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 11 Nov 1981 Volume 1 : Issue 34
Today's Topics: Small Operating Systems
Portable SmallTalk System
Query - Real Experiences
S-Machine
Programming For The Future
----------------------------------------------------------------------
Date: 9 November 1981 0756-EST (Monday)
From: Hank Walker at CMU-10A (C410DW60)
Subject: more on VMS
When VMS was first being written, they had a goal to fit it into
64Kbytes. Since current versions lock 800-1000 pages to VMS, they
have obviously gone way beyond this. But the size constraint may be
an additional reason to scrimp on the user interface. Someone now
stand up and say that UNIX is small. Yes, but its user interface is
no better, and VMS provides more capabilities.
[There is also a discussion of VMS's user interface in HUMAN-NETS.
I would suggest that you address any further discussion on that
particular topic to HUMAN-NETS@AI -JSOL]
------------------------------
Date: 9 November 1981 1537-EST (Monday)
From: Mark.Tucker at CMU-10A
Subject: Portable Smalltalk System
Message-Id: <09Nov81 153741 MT71@CMU-10A>
The best way to obtain a portable Smalltalk system would be to code
the Smalltalk virtual machine in some suitable algorithmic language: C
would be fine. Then, get the rest of the environment by importing the
Smalltalk virtual image from PARC. By maintaining compatibility with
the Virtual Machine, all software developed under the portable system
would be valid when the a personal S-machine is eventually perched by
our desks.
Even though Xerox expects the Smalltalk virtual machine to be
microcoded, most implementations will face similiar problems detailing
the way the VM maintains data structures in a byte-aligned memory
space. A well written HLL VM implementation would serve as a
guideline for microcode writers. Perhaps,like Xerox did with BCPL on
the Alto, these HLL procedures could be subsumed into microcode as
time and microstore space would allow.
Finally, I think we want the underlying power of Smalltalk to be
available in some measure on standard 24x80 CRTs. I know this is
blasphemey, but it will be a very long time before you have a bit-map
system at home and at work. So we should start today to consider how
we will have to limit the amount of information contained by a
Smalltalk display so that it will fit in 2K characters. About the
only display format a "portable" Smalltalk system could provide would
be such a restricted, 24x80 one.
------------------------------
Date: Monday, 9 November 1981 21:13-PST
From: WANCHO at DARCOM-KA
Cc: WANCHO at DARCOM-KA, ARMTE at OFFICE-8
Subject: Real World Decisions
It seems that the current discussion, though very interesting, has
gone astray from what we have to consider as today's real problems in
selecting a workstation configuration of modest cost.
At the risk of provoking wild flaming (or utter silence), we would
like to solicit some opinions/advice on the situation we are faced
with right now:
We need to gather some hard experiences with small 4-6 user 8 or
16-bit micros of the Z80 CP/M-based or LSI 11/23/24 varieties,
respectively. These systems are to be used in an environment which
will crudely communicate in a batch fashion to send and receive mail
from a central site. We have plenty of experience with a
multi-processor CP/M system, and we have all of the correspondence of
the recent UNIX vs. CP/M discussion. What we don't have is any
experience with RT-11 that one user is strongly pushing with seemingly
convincing arguments to the novice potential user.
One of his major points is that there is a large amount of free
software available to run on it. There is also a large amount of
software already designed to interface with VT-52-like terminals.
What is not certain is the availability of a decent word processor...
Our concerns are mainly centered around our bias to the
speed/response-time advantage obtained by using a multi-processor over
the small-scale timesharing of something like an LSI 11 running RT-11.
Secondly, we need to know what compiler are available besides FORTRAN
and COBOL. Pascal, C are two others that come to mind.
Now I know that the machines discussed appear to be a step backward in
the high technology discussions carried on here, but we need to know
alot about a cost-effective approach without getting trapped in either
an obsolete technology or a flashy new one which may not get off the
ground.
Please be sure to include ARMTE@OFFICE-8 in your replies.
Thanks,
Frank
------------------------------
Date: 10 Nov 1981 (Tuesday) 1706-EST
From: KENDALL at HARV-10
Subject: S-machine
cc: KENDALL at HARV-10, Dreifus at Wharton-10
Re Dreifus's speculation on the "S-machine": the Xerox workstations
ARE microprogrammed to fit the language being used. There are
"Smalltalk bytecodes" and "Mesa bytecodes", and probably many others,
implemented in microcode.
-- Sam
------------------------------
Date: 10 Nov 1981 (Tuesday) 1707-EST
From: KENDALL at HARV-10
Subject: Programming of the future?
cc: KENDALL at HARV-10
This is in response to Dreifus's question on the programming of future
workstations, and SSteinberg's letter "New programming styles on Work
Stations".
I found the question too vague even as a topic for speculation.
SStenberg's response was somewhat specific, but contained no
arguments, only naked speculation. Furthermore, it did not specify
whose workstations it meant; and neither did Driefus's question.
This implies a belief that all workstations will share the advances in
programming of today and the future. Surely no one would argue that
most current computers are even close to the state-of-the-art, in
programming environments or languages; they use something like OS/360
and COBOL. But workstations are surely at the forefront of
innovation-- the existence of this digest implies it.
And so Xerox is. But although they have had their Altos for ten
years, the only commercial product to come out of that line of
research has been the Star, which is a word processor (a great one, to
be sure) and office filing system, not a full programming workstation.
Perhaps most work- stations will be like the Star, running slick
special-purpose packages, as SSteinberg suggests. But I fear that
Apollo-like stations will be dominant.
My purpose here is not to insult the Apollo. Apollo, Inc. itself
projects that 95% of its sales will be to engineering firms and such
using FORTRAN; this type of customer does not appreciate or want
programming innovations. The Apollo programming environment is very
primitive--indeed, the Apollo system programmers had never seen a
Xerox workstation when they wrote the Apollo software. Note also that
the Apollo is the most sophisticated general-purpose workstation
commer- cially available.
To summarize, I see the possibility for widespread better "programming
of the future", but I fear that the mistakes of the past will continue
to be perpetuated; and I see evidence for this perpetuation.
-- Sam
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #35
∂15-Nov-81 0139 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #35
Date: 15 Nov 1981 0339-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Sunday, 15 Nov 1981 Volume 1 : Issue 35
Today's Topics: RT-11 Pascal & C Compilers - Reply
Programming Environments - FORTH , Smalltalk
Apple's Lisa Project
Integrated Office Automation & Manufacturers
Portable Smalltalk Compiler in C
WorkStations For Programmers Vs. Users
----------------------------------------------------------------------
Date: 11 Nov 1981 (Wednesday) 0528-EST
From: KENDALL at HARV-10
Subject: Inquiry on RT-11 PASCAL and C compilers
To: armte at OFFICE-1
Whitesmith, which frequently has advertisements in \Byte\, sells
PASCAL and C compilers for RT-11.
-- Sam
------------------------------
Date: 12 Nov 1981 1628-PST
Sender: BILLW at SRI-KL
Subject: Programming environments....
From: William "Chops" Westfield <BillW@SRI-KL>
Just what distinguishes a programming environment from an ordinary
operating system with its utilities ? (I think I can tell the
difference, but Im looking for formal definitions here...).
What are the currently available environments ? If I had to guess,
Id say:
Smalltalk (well, not yet really available)
Forth
and maybe
UCSD P system
Unix
Are there others ?
Bill W
------------------------------
Date: 13 Nov 1981 1503-PST
From: Gene Autrey-Hunley <Autrey-Hunley at SRI-KL>
Subject: Apple's Lisa
cc: AUTREY-HUNLEY at SRI-KL
The Wall Street Journal (11 Nov. 1981) contains the following on page
18.
"Now that the Apple III is returning to the marketplace, the company
plans to turn its focus to the strategic new products under
development, one of which has been code-named 'Lisa.' 'You are
looking at the most sophisticated and powerful graphics-editing
machine in the history of mankind,' says Mr. Jobs as he puts Lisa
through it paces. Lisa, which may become Apple IV, is a computer
aimed at the office market. It has data- and word-processing
functions, as well as a program that permits novices to create charts
and other graphics. It cost $30 million to develop."
The comment about Lisa being "the most sophisticated and powerful
graphics- editing machine in the history of mankind" sounds like hype.
But does anyone have any more substantial information about Lisa?
Could it possibly be a Smalltalk machine?
--Gene
------------------------------
Date: 13 November 1981 23:58-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Manufacturers and integrated OA
Does anyone know of a vendor other than Xerox that is involved in the
design of an integrated OA system (at the user/application level)
that will win?
Some manufacturers are only investigating distributed system issues
(Ollivetti, NBI) or are only looking at hardware and language issues
(BNR). HP Labs seems to be ignoring "office" automation in favor of
expert systems for the engineer which is contrary to statements from
the president of HP about HP's role in the office. Wang probably
won't have a well integrated system for historical reasons (it will be
messy underneath, I suspect). IBM lost de Jong and the San Jose folks
don't really have the right tools or background. InterActive doesn't
have a uniform user interface; they just have a lot of tools that can
be combined (Unix approach). ROLM has a uniform user and program
interface, but their implementation strategy will lose due to lack of
cycles.
With the size of the OA market, you might think there might be ONE
company that is exploring future integrated office system design on a
suitable tool (e.g., LISP machine or reasonable facsimile). But other
than Xerox, I can't think of one.
------------------------------
Date: 14 November 1981 09:49-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Portable Smalltalk kernel in C
In reply to Mark.Tucker@CMUA: The idea of a portable Smalltalk kernel
in C sounds good superficially, but you should keep in mind that only
some of the kernel can be done this way. As I understand the division
of the Smalltalk-80 system between its kernel and the rest of the
system, I surmise two kinds of things reside in the kernel. The first
kind of things are operating-system or environment-dependent things;
for example, every kernel must implement a primitive that implements a
real-time interval-timer facility, that signals a given semaphore at a
given time in the future. Things like this can't be portably
implemented in C because they depend on the environment in which the C
implementation resides: either the operating system (if any) or the
hardware (if there's nothing corresponding to an operating system).
Access to the bit-mapped display and other I/O devices is likewise
dependent system-dependent, and the parts that don't depend on the
operating system or hardware are probably in Smalltalk code rather
than in the kernel. The second kind of things are those that have to
run very quickly, and indeed you might benefit by writing those once
in C and attempting to make the C code portable. I don't know how
much of the kernel makes up the first kind of things and how much the
second kind; perhaps there is a Xerox person around who can comment?
------------------------------
Date: 14 November 1981 10:02-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
In reply to Sam Kendall: I think you can rest assured that systems
like the Apollo will not be dominant among workstation-class
computers. The reason is that there is a much larger market for slick
packaged applications than there is for program development systems.
This, in turn, is because there are not that many program developers
in the world, but there are a whole lot of secretaries,
businesspeople, accountants, engineers, car designers, fashion
designers, musicians, film-makers, and so on, all of whom might
someday benefit from neat computer-based applications. SSteinberg is
in a good position to know: he is the author of the 8080 version of
VisiCalc, a particularly slick, useful, cheap, and well-implemented
application that is rightly selling very well. His company, Software
Arts, is a leader in the field of slick application packages running
on cheap computers for the mass market, and I think they stand to do
extremely well.
Now, among those workstations that will be marketed for program
development, it is possible that Apollo-like systems will be dominant.
I, too, sometimes complain that their software is backward and
primitive. But at other times, I reflect on how advanced and easy to
use and modern it is. It depends on my mood. If you compare Apollos
to all the good ideas I've seen on Lisp Machines and on various Xerox
PARC systems, they may look backward, but compared to what most people
in the world are using (not only on IBM batch systems but on Data
General time sharing systems and other things of that ilk), it's not
so bad. One can do worse than copying Unix. And the window system on
the Apollo is not half-bad; if they put in a graphical input device it
would be quite good by today's standards.
Also, you are mistaken in your assertion that the Star is the only
machine to have been marketed by Xerox that was based on the Alto
ideas. The Xerox 1100 Scientific Information Processor, or whatever
the external marketing name is, is also on the market. It is known
internally as the Dolphin, and it is a real program-development system
for the Interlisp-D system. By anyone's standards, its user interface
is up to the state of the art and is one of the best things around.
(I'm not comparing it to other things in its class so much as
comparing to to the rest of the world. There isn't very much in its
class, anyway.) You can buy them from Xerox Electro-Optical Systems
(EOS).
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #36
∂16-Nov-81 0152 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #36
Date: 16 Nov 1981 0320-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Monday, 16 Nov 1981 Volume 1 : Issue 36
Today's Topics: C Compilers Available From DECUS
WorkStations for Programmers Vs. Users
More On The "Lisa" Project
----------------------------------------------------------------------
Date: 15 November 1981 0309-EST
From: The Moderator <JSol at Rutgers>
Subject: WorkS Archives
The WorkS Archives are kept in two places. The traditional place for
digest archives is at MIT-AI in the file DUFFEY;←DATA← WORKS. A copy
of the archives are also kept at Rutgers, however all but the most
recent issues are offline. Due to MIT-AI's recent disk problems, the
archives were not accessable from MIT-AI, so I retrieved the entire
archive from backup tapes at Rutgers.
Now that the disk problems seem to be cleared up at MIT-AI, I am
deleting the offline files from the WorkS Archive at Rutgers. If you
have need for the files on Rutgers for any reason, then please send
mail to WorkS-Request@MIT-AI and I will retrieve them from tape again.
MTFBWY,
JSol
------------------------------
Date: 15 November 1981 0216-PST (Sunday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: C compilers
To: WORKS at AI
There is a fairly full C compiler in the DECUS library. I'm not
sure whether it is oriented towards RT-11, RSX-11, or both...
--Lauren--
P.S. It's free.
--LW--
------------------------------
Date: 15 November 1981 12:27-EST
From: Mark L. Miller <MILLER at MIT-AI>
Subject: WorkS Digest V1 #35
In response to DLW's remarks about things like the Apollo probably
losing out to slick end-user applications, I think perhaps a key point
has been overlooked. [I have seen major companies lose by providing
"non-programmable" (and thus hard to upgrade, inflexible, etc.)
systems geared to particular (usually incorrect) perceptions of
"slick" end-user applications.] Although it is probably accurate that
most end-users are not programmers and that it is the slick
applications (e.g.,VISICALC) that sell systems, it is also probably
accurate to assume that most slick applications (e.g., VISICALC) will
be written by software and OEM-systems companies, rather than hardware
manufacturers. The OEM's and software developers will choose things
like Apollos or LISP machines based on several factors: perceived
power and flexibility of the basic programming environment and
development tools, price relative to the market for the slick
application, etc. I believe that Apollos and LISPM's will flourish,
but that most sales will be via demand for particular packages (e.g.,
"What machine do I need if I want to run VISICALC" -> "What machine do
I need to run Daedalus?" etc.) Perhaps the best OA systems will be
written by separate software vendors serving as OEM's for systems such
as Apollo. Regards, Mark (Miller, DallaSoft)
------------------------------
Date: 15 Nov 1981 1417-EST
From: G.PALEVICH at MIT-EECS
Subject: Smalltalk 80 bible
So just where do I (a humble student) go to get a copy of the
Smalltalk 80 specifications book and the 380K byte system tape?
I read in Infoworld that the Apple IV is 68000 based. I seem
to remember rumours that they had at least the window portion of
Smalltalk 80 up.
The Infoworld article also talked about two other Apple
computers: a redesign of the Apple II for 64K chip, and some sort of
portable (ala Osborne I) 68000 based machine -- possibly code-named
the Mackentosh.
I believe that Tandy is working on a 68000 based machine, too.
In fact, I bet just about everyone is going 16bit because of the
greater speed/power/RAM.
------------------------------
Date: 15 November 1981 23:13-EST
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Apple and 'Lisa'
While visiting Apple several months ago, I caught a glimple of a box
that bore no resemblence to any current Apple product. I snooped
around a bit and read the memos that people had tacked on the walls of
their cubicals. Although I could be wrong, I got the strong
impression that I saw their 'top secret' product (this was the new
products development group).
The device I saw looked much like a VT-100 (same form factor) and had
a mouse. They were experimenting with color graphic printers, and I
overheard some discussion of the quality of the bitmapped display. I
was unable to find out what processor is being used, but I did learn
that it is a 16 bit chip. They were most interested in my experience
with the Convergent Technologies cluster communications and OS
architecture.
If I had to guess I would say that Apple is trying to build a cross
between the Xerox 'Star' and the Convergent Technologies system. They
could actually have something as far as the hardware is concerned, but
I wasn't too sure about their software crew.
Brian
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #37
∂17-Nov-81 0027 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #37
Date: 17 Nov 1981 0254-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 17 Nov 1981 Volume 1 : Issue 37
Today's Topics: New Radio Shack Computer
Smalltalk Kernel In C
Major Corporations and Workstations
Book Reference
DECUS C Compiler
----------------------------------------------------------------------
Date: 16 November 1981 1045-EST
From: Hank Walker at CMU-10A
Subject: new Radio Shack computer
The current ELECTRONICS claims that the new Tandy computer will be 68000-
based, and be out in Feb or March 1982.
------------------------------
Date: 16 Nov 1981 10:06 PST
From: Deutsch at PARC-MAXC
Subject: Re: WorkS Digest V1 #35
Re the Smalltalk kernel in C: I would guess the current kernel is
about 70% relatively environment-independent and 30%
environment-dependent. However, there is another important point: the
Smalltalk system includes its own instruction set, and the 70%
includes the emulator for it. If you are going to run native machine
instructions rather than the Smalltalk bytecodes, you will have to
write your own compiler and decompiler, and do some careful thinking
about how to retain the current pleasant properties of reasonably
direct mapping between the source and object codes. For example, with
the Smalltalk instruction set, the debugger can highlight the exact
spot in a procedure being executed.
Smalltalk is set up so that you can take any procedure whatever and
recode it in an underlying instruction set without any change to its
callers or the system structure. For this kind of thing, having C
underneath would work just fine.
------------------------------
Date: 16 Nov 1981 14:09:45-EST
From: rmc at CCA-UNIX (Mark Chilenskas)
Subject: Major Corporations and Workstations
Last year Mike Hammer of MIT was consulting with the OA group
at EXXON. I believe he was involved in designing a database for
integrating office functions. A student of his, Tim Anderson, was
to be working on an editor/word processor function for the same
project, but last i heard Tim was choosing another thesis, so the
whole thing may have fallen through. Anywho, it is a possibility
that EXXON is actually trying to do something major here.
R Mark Chilenskas
Chilenskas@ISIE
------------------------------
Date: 16 Nov 1981 13:53:21-CST
From: jacobson at uwisc
Subject: Book Reference
Cc: jacobson@uwisc
I have a reference to a book entitled Interactive Programming
Environments, edited by E. Sandewall, H. Shrobe, and D. Barstow.
I picked it up from somewhere (perhaps fa.works) about two weeks
ago. I recorded that it was published by McGraw-Hill, but they
don't know anything about it. If you know who has or will
publish this book, please let me know.
-Fred Jacobson (jacobson@uwisc)
------------------------------
Date: 16 November 1981 2248-est
From: Brian N. Hess <Hess.Unicorn at MIT-Multics>
Subject: DECUS C compiler
Cc: Lauren at UCLA-Security
It's pretty worthless. That is to say, we don't like it because it
doesn't compile Mince (our ersatz EMACS) at all. For $695, who can
afford to NOT use the Whitesmith's C compiler? (Both DECUS and
Whitesmith's run under RT, RSX, and RSTS.)
Brian
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #38
∂17-Nov-81 2231 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #38
Date: 17 Nov 1981 2342-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 18 Nov 1981 Volume 1 : Issue 38
Today's Topics: Exxon's Answer To The Star
Programming Environments - Operating System Vs. User Interface
----------------------------------------------------------------------
Date: 17 November 1981 17:25-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Exxon
Xonex [which is Exxon spelled sideways] is the Exxon company that is
building Exxon's answer to Star; it has a full bitmap and other nice
features that I am not allowed to disclose. However, the system is
very special case (i.e., like Wang) and concepts such as
"extensibility and customizability" seem to be foreign to the people
there. The software is impressive, but last I saw, they were still
coding in a macro assember.
------------------------------
Date: 17 November 1981 17:41-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: WorkS Digest V1 #35: Programming environments
To: BillW at SRI-KL
A programming environment supports development of programs. Examples
are Harvard PDS, CMU Gandalf, PWB/Unix (shell and utilities).
An operating system supports running of programs and storage of data
(including, presumably, the programs which implement the programming
environment). Examples are Tops-20, Unix.
A programming system supports cooperation of running programs. In
most places, this consists of a set of conventions. In Unix, for
instance, it consists of conventions on the use of pipes and the
passage of textual parameters. Examples are the conventions of
Multics, Tops-10 (CCL files!).
A general user interface (there appears to be no standard name for
this and moreover it is often incorporated into the OS itself)
supports user control of the running of programs. Examples are
Tops-20 Exec, Unix Shell, DDT/Hactrn. Note that the Tops-10 "monitor"
is both an operating system and an interface.
The above classification is not to imply that the distinctions are
always sharp, nor that the best organization separates the levels.
Some very successful systems (Lisp Machine, for instance) blur many of
the lines; more and more other lines, such as those between
programming language, system, and environment, are similarly blurred.
There is a large literature on the first two topics. The third and
fourth topics are less discussed in themselves, although instances are
sometimes reported in the literature.
In all of these areas, there are debates about the right way to do
things. Some typical dimensions of dispute are the degree to which a
PE "understands" what it is working on (in PWB/Unix, not at all: it is
just a string of characters to most tools; while in Gandalf and PDS it
is structured and cannot be dealt with as a string of characters); the
degree of integration of parts of the system (again, in Unix almost
none--the toolbox approach; in PDS, very great); the amount of
structure in interfaces in PS's (in Unix, arguments are just strings
which may be interpreted as desired; in Multics, they are PL/I
objects); ... etc. etc. ad infinitum.
In any case, there is an extensive literature especially on
programming environments. See Horst Huenke's (some libraries may
transcribe u umlaut as 'u', giving Hunke) recent collection for a
starting point.
Stavros Macrakis
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #22
∂23-Oct-81 2321 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #22
Date: 24 Oct 1981 0154-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Friday, 24 Oct 1981 Volume 1 : Issue 22
Today's Topics: BBN BitGraph Terminal
The Alto Users Handbook - Cleared For Print By Xerox
----------------------------------------------------------------------
Date: 23 Oct 1981 (Friday) 1521-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Interesting 68K workstation (?)
cc: MORGAN (Howard Morgan)
Begin forwarded messages
Date: 22 October 1981 18:56-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Favorite terminals
To: decvax!duke!unc!smb at UCB-C70
cc: INFO-TERMS at MIT-MC, BERN at MIT-MC
BBN has recently sold us a terminal called the BitGraph Terminal.
1024 * 768 bit mapped screen, 15" monochrome monitor, 40 Hz.
interlaced.
68000 micro (7 MHz.) with 128 Kbyte of RAM, 32 KByte of ROM, and 64
bytes of EAROM, 4 rs232 ports up to 19.2 Kbps, one 20 ma current loop
interface, and EIA rs-422 sync. HDLC serial link up to 200 Kbps.
All on one board. Expansion bus (Motorola Versabus) for additional
memory and IO. Maximum (in cabinet I believe) memory: 2048 Kbytes.
Speaker and programmable sound generator.
VT-100 keyboard.
Software in ROM: emulates VT52 and teleray (?), future software: HP
and TEKTRONIX 4010 graphics terminal emulation. For hackers: write
your own software. Code and fonts downloadable.
Price: $4500 single quant.
Bern
[End forwarded messages]
------------------------------
Date: 23 Oct 1981 1607-PDT
From: Richard Furuta <FURUTA at WASHINGTON>
Subject: The Alto User's Handbook
To: editor-people at SU-SCORE
cc: jeff at WASHINGTON, furuta at WASHINGTON
Some of you may be interested to know that that old underground
classic "The Alto User's Handbook" has been cleared for
release at Xerox and is available from Sara Dake at
Xerox-PARC. This handbook includes writeups on
Bravo, Markup and Draw.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #39
∂24-Nov-81 0035 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #39
Date: 24 Nov 1981 0237-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 24 Nov 1981 Volume 1 : Issue 39
Today's Topics:
Programming Environments - Request For References
MC6800 Paging
----------------------------------------------------------------------
Date: 18 November 1981 15:05
From: Eugene Bordelon <epb at BTL-ihuxo>
Reply-to: ihnss!ihuxs!ihuxp!ihuxo!epb at Berkeley
Subject: WorkS Digest V1 #38: Programming environments
To: Stavros M. Macrakis at MIT-MC
I am interested in reading further about various approachs to programming
environments. Could you list (in full) some references?
Eugene Bordelon
------------------------------
Date: Sunday, 22 November 1981 18:01-EST
From: FEINBERG at CMU-20C
Subject: [G.KTK: 68000 Paging]
cc: KTK at AI
This message was sent to me by a Hardware designer who is currently
working on implementing his own 68000 system. He claims you can do
totally winning paging on the 68000 without kludging two processors
together, by adding hardware to detect page faults, and signalling a
bus error which such an event takes place. If the following is true,
why did people go to such great lengths to implment paging?
Date: Friday, 20 November 1981 22:54-EST
From: Kristofer Karas <G.KTK at MIT-EECS at MIT-AI>
To: FEINBERG
Re: 68000 Paging
Howdy!
Ah, but the 68000 has something even better in that it is really
versatile; it has a BERR (bus error) interupt that can either re-run the
bus cycle in case of parity error in memory, or call a routine in the
monitor to modify the page and swap in/out virtual memory. This single
input can (under complete control of the Monitor) trigger any special
routine the user wishes when page faults or other such immediate conditions
occur. Combine this with status outputs that can tell outside hardware
(page-mappers for that matter) whether the currently running program
is Monitor (privileged) or User (ordinary) and you have the basis for a
really sophisticated virtual memory/multi user/multi tasking system with
a minimum of external hardware!
--Kris
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #40
∂25-Nov-81 2239 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #40
Date: 26 Nov 1981 0034-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
Works Digest Wednesday, 25 Nov 1981 Volume 1 : Issue 40
Today's Topics: Demand Paging On A MC68000
Programming Environments
----------------------------------------------------------------------
Date: 24 Nov 1981 10:42 PST
From: TonyWest at PARC-MAXC
Subject: Re: WorkS Digest V1 #39
cc: TonyWest
About demand paging on the 68000 and FEINBERG at CMU-20C's question
about what makes it difficult:
Yes, it is true that the 68000 has a hardware signal (BERR), which
allows external logic to interrupt the processor if any of the bus
cycles in an instruction cannot be completed (eg. because the page is
not there). The hardware to detect references to missing pages and
generate this signal is trivial.
However, that is only half a solution to the demand paging problem.
The other facility that is required is that, when such a fault occurs,
it must be possible to stop what you're doing, load the page, *and
continue again*. There are two approaches one might take:
Scheme A: On a BERR, store the entire state of the processor and
restore it after the missing page has been loaded so that the
execution of the instruction can be resumed from whatever intermediate
point it got to before it faulted (ie. don't restart the instruction
from the beginning -- continue from where you left off).
Scheme B: If one could only figure out which cycle of an instruction
caused a fault, then, with the help of some code (which is rather
similar to an instruction disassembler), one could undo the work the
processor has accomplished so far in the execution of the instruction,
and *then* save the starting state *before* the instruction which
failed. Thus, after loading the page, the instruction can be re-run
from the beginning (ie. don't continue from where you left off --
unwind the partial instruction and try it again from the beginning
later).
The problem with the 68000 that everyone has been talking about is
that, on a Bus Error interrupt, the facilities the 68000 provides for
getting your hands on the internal machine state *within* an
instruction are deficient. Thus it is extremely difficult or even
impossible to "trigger any special routine the user wishes when page
faults or other such immediate conditions occur" and have it unwind
what's going on successfully.
For Scheme A, you can't restore the 68000 to a previously-saved state
halfway through the instruction.
For Scheme B, it is extremely complex to undo the instruction the
processor has half executed so it can be re-run later. One encounters
problems with things like auto-increment addressing modes, etc.
I have seen it suggested that, by carefully restricting the set of
instructions a code-generator is allowed to generate (eg. by avoiding
things like autoincrement addressing modes), a system designer can
reduce the range of possibilities of what might be going on when an
instruction faults to manageable proportions. However, *intimate*
knowledge is required of the way the instruction processing is
performed.
If you have to have demand paging, consider the following suggestions:
a) Implement the two-processor scheme and have done with it. You
sacrifice performance and multiprogramming during page faults.
However, it's makes for a very simple system.
b) Call Motorola and ask them about the timescales for availability of
the following two devices I saw advertised in some of their literature
(I quote verbatim):
MC68010 Virtual Machine
This processor is an extension of the MC68000 that
readily supports advanced virtual memory techniques.
MC68020 Advanced M68000 Processor
This advanced 16-bit microprocessing unit will feature
architectural extensions of the MC68000 such as
virtual memory, co-processor support, string handling,
and higher performance.
c) Consider using the National Semiconductor NS16000 microprocessor,
which will soon be available, and will support demand paged virtual
memory from the beginning. Datasheets are available now from NS. This
machine is in the same architecture and performance class as the
68000.
Tony West
Computer Science Laboratory
Xerox Palo Alto Research Center
------------------------------
Date: 24 November 1981 17:55-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: WorkS Digest V1 #39 / Bordelon
To: ihnss!ihuxs!ihuxp!ihuxo!epb at UCB-C70
Programming environments are a major area of research. There are
journals and conferences which devote a large chunk of their resources
to the subject.
Software Engineering Environments, ed. Horst Hunke/Huenke is the book
I had in mind. But note that, e.g. Transactions on Software
Engineering, IEEE, of last month had a special section on
environments. These should be good starting points for a literature
search. However, I am not in a position to do literature searches or
bibliographies. I suggest you talk to your friendly local librarian
in regard to your particular interest. When I'm ready to publish a
bibliography (if ever!) I'll certainly do so....
------------------------------
Date: 24 Nov 1981 16:55:40-PST
From: ARPAVAX.hickman at Berkeley
Subject: m68000 paging
The person is wrong for the simple reason that it is not always
possible to restart an instruction which has part way finished....I am
not certain which instructions meet this class, but I believe there
are some...On the z8000, for instance, the problem is easily told by:
pushl @r15, rr0
Which would attempt to push r0, and r1 on the stack (r15). If the
stack crosses a page boundary when it tries to push r1 (that is, push
of r0 works fine, but push of r1 causes a fault) then restarting the
instruction after completion of the page software would cause two
copies of r0 to be put on the stack, instead of one.....There must
certainly be a parrallel (?) to this on the 68000....
kipp
------------------------------
Date: 24 Nov 1981 17:12:47-PST
From: decvax!yale-comix!ima!johnl at Berkeley
From: John R. Levine
From: The INTERACTIVE Electric Calculator Co., Cambridge MA.
Subject: 68000 paging problems
I am under the impression that the problem with paging on the 68000 is
that you can't always restart an instruction if you get a page fault
at an inconvenient place in an instruction. There's no way for the
memory manager to tell the CPU to back up. That's why Apollo has two
on their systems, one for regular work and the other to service page
faults while the first is frozen. Believable rumors say that Motorola
will have a modified 68000 out within a year that can take its own
page faults.
------------------------------
Date: 24 November 1981 2049-EST (Tuesday)
From: Joe.Newcomer at CMU-10A
Subject: 68000 paging
At least the last 68000 manual I looked at indicated that Bus Error
would abort the current instruction. Alas, it is not possible in
general to restart an aborted instruction, since you can't find out
which byte the instruction starts on. If the solution were as simple
as claimed, everyone else would be using it. The fact that so much
effort is expended is because the bus error signal is NOT adequate. A
little careful reading of the manual will reveal this.
joe
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #41
∂01-Dec-81 1852 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #41
Date: 1 Dec 1981 2110-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
Works Digest Wednesday, 2 Dec 1981 Volume 1 : Issue 41
Today's Topics: Release of UNIX III
M68000 Paging Hardware & Problems
iAPX 432 & 8086's
Programming Environments
----------------------------------------------------------------------
Date: 19 Nov 81 1:03:18-EDT (Thu)
Sender: Michael Muuss <mike.bmd70@BRL>
To: OA-DRDAR at Brl
Subject: Commercial Release of UNIX III
From: Myra Hartwig <myra@brl>
[Note: This message is intended for government sponsored projects, and
not for personal use. It is being presented on WorkS as a time saving
tool for Arpanet-sponsored Unix users. -JSOL]
The Patent Licensing Office of Western Electric has announced the
release of UNIX III to the commercial market. If you have a
Source license, you can obtain a binary license for $4800. They
are currently evaluating a COBOL Compiler to run under UNIX III.
In addition to running on 11/780's, 11/70's, 11/34's and 11/23's,
UNIX III now will run on ONYX.
I can be contacted for more information, in needed:
Myra Hartwig (ARPANET address - myra@brl)
USA Ballistic Research Laboratories
Aberdeen Proving Ground, MD 21005
301-278-5691 or AUTOVON 283-5691
or you can contact Western Electric directly
Western Electric, Guilford Center
ATTN: Joe Hunt, Dept 34GC212310
P.O. Box 25000
Greensboro, North Carolina 27420
919-697-5714
------------------------------
Date: Monday, 30 November 1981 10:55-EST
From: DPR at MIT-XX
Subject: WorkS Digest V1 #39
The problem with the 68000 is that it handles bus errors wrong:
you can't restart correctly after one. Don't believe the
manuals! Any hardware person who does is probably a bit green...
------------------------------
Date: 30 November 1981 18:21-EST
From: Robert A. Morris <RAM at MIT-MC>
Re: The M68000 paging question about what fails with the facilities
Re: provided by Motorola.
Demand paging requires more than simply detecting when a non-resident
page has been referenced. Since instructions will be only partially
complete when a page fault occurs, it is generally necessary to bring
in the non-resident page and restart the instruction. To do this
properly the processor must save sufficient state during the bus error
interrupt to backup the instruction if not to the beginning then at
least to the point where it can proceed, recalling that servicing the
interrupt will change the processor state. It is known that certain
M68000 instructions, including some very useful ones, do not save
sufficient state to restart these instructions. Since Motorola's
position is to fix this in some future version, some users use
compilers which do not generate the offending instructions program
with these compilers. Others adopt the two processor solution
described elsewhere in these pages.
Bob Morris
------------------------------
Date: 30 Nov 1981 22:20:09-PST
From: decvax!watmath!bstempleton at Berkeley
Subject: IAPX 432
Does anybody out there know anything about a special board containing
the 432 and an 8086 that is supposed to plug right into a unix system?
It's supposed to run around $5K, and come with software for Intel's
Object Programming Languange The name of the thing is something like
INTELlect. We're interested in info on it and how to get it.
------------------------------
Date: 1 December 1981 17:51-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: Programming environments
An IEEE tutorial collection has recently appeared: Software
Development Environments, ed. Anthony I. Wasserman, IEEE Order no.
385, Catalog No. EHO 187-5.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #42
∂04-Dec-81 0043 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #42
Date: 4 Dec 1981 0314-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
Works Digest Friday, 4 Dec 1981 Volume 1 : Issue 42
Today's Topics: Tandy 68000 Based Microcomputer
Intel Opsys
Limiting the 68000 to permit demand paging.
----------------------------------------------------------------------
Date: 2 December 1981 07:51-EST
From: Hal Abelson <HAL at MIT-MC>
I heard a rumor (in this forum, perhaps) of a soon to be released
68000-based computer by Radio Shack. Anyone have any information
about this?
[This computer was discussed briefly in WorkS Digest V1 #36 and #37. -JSOL]
------------------------------
Date: 2 Dec 1981 (Wednesday) 1029-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Intel Opsys
In November 1981 MINI-MICRO systems pp199-200 is a description of
a few of the Operating System classes around. In addition there
is mention of iRMX/MMX and iRMX86. The big concept though, is the
possibilities of combining an Opsys with all the new technology.
Though the article is heavily skewed towards Intel, the idea is the
same: What should the Opsys be at the Personal Computer level?
There is some mention of layered Opsys's with actually embedding
parts on the chips themselves.
If there are more references, please put them up in WorkS.
Hank
------------------------------
Date:3 Dec 1981 06:27:43-PST
From: decvax!watmath!idallen at Berkeley
Subject: Limiting the 68000 to permit demand paging.
Am I correct in my assumption that most of the
auto[increment|decrement] modes of the MC 68000 would have to be
avoided to permit demand paging? Is this not like purchasing a sports
car to drive to Church on Sundays? I would find it hard to believe
that satisfactory performance could still be squeezed out of the chip
if it was limited in this way -- I'd certainly like more details on
just what must be avoided (and at what cost). -IAN!
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #43
∂08-Dec-81 2346 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #43
Date: 9 Dec 1981 0104-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Works Digest Wednesday, 9 Dec 1981 Volume 1 : Issue 43
Today's Topics: Demand Paging
ECICS 82 - Call For Papers
West Coast Depraz Mice
----------------------------------------------------------------------
Date: 4 Dec 1981 0842-PST
From: Ian H. Merritt <MERRITT at USC-ISIB>
Subject: "decvax!watmath!idallen's comment on 68K demand paging
You are not correct in that assumption. A real implementation of this
has no limiting effect on the instruction set; it simply freezes the
information in a recoverable form so that the instructions are either
restartable or continuable.
<>IHM<>
------------------------------
Date: 4 December 1981 13:34-EST
From: Giuseppe Attardi <BEPPE at MIT-AI>
Subject: Call for Papers
To: ARPA-BBOARDS at MIT-AI, INFO-LISPM at MIT-AI, ICE at MIT-AI
-------------------------------------------------------------------------------
European Conference on Interactive Computing Systems
- ECICS 82 -
-------------------------------------------------------------------------------
When: September 1-3, 1982
Where: Stresa, Italy
Sponsors: ACM Italian Chapter, AICA, AFCET, INRIA, SSI, AISB, BCS, GI
Program Chairman: Erik Sandewall, Sweden
Papers are invited on all aspects of the design, methods, techniques and
applications of interactive computing systems.
Deadline for submission: April 1st, 1982
Notification of acceptance: July 15th, 1982
For the full Call for Papers, see the file "BEPPE; ECICS CALL" on MIT-AI or
send mail to BEPPE@MIT-AI.
------------------------------
Date: 6 December 1981 20:30-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject: West coast Depraz mice
Does anyone around here (Silicon Valley) have a Depraz mouse I could
take a look at? These are hemi-spherical mechanical mice made in
Switzerland for $175. People at BBN have been very pleased with their
performance.
By the way, lead time on these mice is over 4 months. The address is:
Depraz SA
Ch 1345 le Lieu (Sussie)
Their phone is (021) 85-15-33. Telex is 24 310.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #45
∂17-Dec-81 2049 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #45
Date: 17 Dec 1981 2306-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Works Digest Friday, 18 Dec 1981 Volume 1 : Issue 45
Today's Topics: MC68000 Paging Schemes
64K And 256K Memory Chips - Is The US Falling Behind?
[Sorry for the delay putting out digests,
there hasn't been too much to send out -JSOL]
----------------------------------------------------------------------
Date: 16 Dec 1981 1624-PST
From: Jim McGrath <JPM at SU-AI>
Subject: 64K and 256K memory chips
Sender: CSD.MCGRATH at SU-SCORE
Reply-To: CSD.MCGRATH at SU-SCORE
I have been talking to some business folks who generally seem to have
a good feel for the chip market. They were bemoaning the fact that US
manufacturers have pretty much given the 64K market to the Japanese
(only Motorola and TI are selling those chips in any significant
quantity, and the Japanese have captured an estimated 60 to 70% of the
market). I was wondering what people in the "front lines" of chip
manufacture think about this. It appears that the US spent far too
much time and energy on trying to come up with a denser chip to
increase yeilds, resulting in practically no one coming up with a 64K
chip for the general market (as opposed to in house IBM and ATT use).
With this head start, the Japanese could head us off in the 256K
market as well, although perhaps all the time we have spent on the 64K
chip will give us a technical edge there.
This is an important issue. If US industry falls behind on
64K and 256K chips for the mass market, we will lose the
computer manufacturer market, which will decrease revenue and
then really knock us out of the R&D race. And once the memory
chips go, can logic chips be far behind? Eventually our
"cutting edge" industry will subsist on DoD handouts (since they
are a more reliable source of chips than the Japanese).
Comments?
Jim
------------------------------
Date: 14 Dec 1981 0950-PST
From: Ian H. Merritt <MERRITT at USC-ISIB>
Precisely. A real implementation is onw which works. Some are better
than others, but I refer to a real implementation as one which doesn't
limit the instruction set at all. The 2 chip solution is a royal
kluge, but it works and it doesn't have any effect on the available
set of instructions; only the effective speed.
<>IHM<>
------------------------------
Date: 14 December 1981 20:33-EST
From: Robert A. Morris <RAM at MIT-MC>
Subject: M68000 paging schemes.
I have the impression that those who have adopted the two cpu schemes,
eg. Apollo Computer, to overcome hardware deficiencies on pagefaults
have NOT restricted the instructions useful on their machines. This
would lose the benefit of the two cpu scheme. Restrictions on
instructions are adopted by those who can or wish to enforce them or
depend on "scouts honor" programming. I know vendors doing this who
expect Motorola to produce correctly working chips before they bring
any products to market and do their program development with
high-level langauge compilers which circumvent the offending
instructions. Such development presumes that the compilers can easily
be fixed to generate more effective code when the chip handles the
fault correctly and/or when the program is to run in a non-paging
environement.
--bob morris
------------------------------
Date: 17 December 1981 01:44-EST
From: Leonard N. Foner <FONER at MIT-AI>
Subject: The Real Implementation of
Subject: the MC68000 Demand Paging Algorithm
This was a project I was working on about a year ago. The scoop:
You CAN use ANY insruction in the processor with the dual-processor
system. Essentially, what happens on a page fault is that the CPU
gets a LONG memory wait for the next byte. The other processor
handles the stuff. Of course, you can't go off and run somebody else
while you're waiting for the next page to come into memory, unlike
reasonable VM machines like VAXen, but this will work.
For this reason, you probably also wanna use a stacklike cache of
pages that are bound for disk, to decrease "expensive" page faults
which have to hit the disk. (That way, you've effectively got a
larger working set, since only the page last accessed in \that/ cache
gets stuck on disk, when you've gotta bring a page in from disk on a
fault.) I'm not at all sure how much of an advantage this makes when
you can't run somebody else during the fault, though... but good
references on good paging algorithms are in the VAX Hardware Handbook.
There \must/ be theoretical treatments around on how to do it
efficiently, and that will really help in this situation.
Obviously, how fancy you wanna get on paging is a tradeoff between
price and performance, pure and simple... with the law of diminishing
returns thrown in as an extra added feature.
Have fun.
<LNF>
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #46
∂20-Dec-81 1537 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #46
Date: 20 Dec 1981 1756-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Works Digest Monday, 21 Dec 1981 Volume 1 : Issue 46
Today's Topics: 64K vs. 256K Chips
The 68000 Paging Game
----------------------------------------------------------------------
Date: 18 December 1981 0952-EST
From: Hank Walker at CMU-10A
Subject: 64K and 256K chips
Some people seem to have short memories. Who was first into the 16K
RAM market? Intel. Whose design dominates the 16K RAM market (and
everyone copied it)? Mostek. They also happened to be one of the
last into the market. Their design was simply better, allowed smaller
packages, and much higher yields.
The Japanese do not use mirrors. They simply made a different choice
than the American manufacturers. Companies like Intel concentrated on
redundancy. But since they had to go back and retrofit it, this cost
more time. Companies who've used it from the start, such as IBM and
Western Electric, have been building 64K RAMs for quite a while now.
Other companies like Inmos and TI have concentrated on design
trickiness to get a part that will be inherently cheaper to
manufacturer. My current vote is with the TI part since it is the
smallest and lowest power.
The volume of 64K RAMs is currently small compared to what it will be
in a year or two. That's when market share will really matter. 75% of
a small amount is a small amount.
I think that the attention to redundancy in the US will really pay off
at the 256K RAM level. Also the catching up in reliability (which the
US has essentially done).
People seem to forget that a great deal of the Japanese process
equipment was built in the US. They're using the same equipment, but
not necessarily the same designs. The Japanese have never been noted
for design cleverness as much as good engineering and manufacturering.
As any company will tell you, a good design with half-way decent
manufacturering will beat out a poor design (or a brute force one)
with excellent manufacturing every time. For example, TI doesn't use
redundancy in their 64K RAM. They claim that they don't need to since
their yields are high (about 50%). The lack of fuses, and possibly
laser zapping, allows them to use plastic packaging, which makes for
cheaper RAMs.
------------------------------
Date: 19 Dec 1981 18:57:47-PST
From: menlo70!nsc!ross at Berkeley
Subject: 64k dynamics
Attn: Jim McGrath ("Comments" you say? OK, I can't resist...)
....why aren't more U.S. companies making them? I would say it's
the usual short-term/marketing-dept/management/brain-damage which
doesn't understand the nature and importance of technical progress.
Until the price crashed, they were quite happy making 16k parts.
Then there's the usual mixture of technical incompetence. The 64K RAMS
aren't like other LSI devices; to be competitive the yield must be
quite high, so the design and the process must both be done right.
A fundamental problem: the big companies don't seem to understand the
importance of technical talent. They don't recognize it.
And, sadly, it's getting a bit late to enter the 64K scene. The big
customers have already qualified their suppliers. Those who enter
late won't be selling high-profit technology, they will be selling
commodities for low prices with low margins.
Your comment ``can logic chips be too far behind?'' is perceptive.
Besides the above-mentioned problems, new process technologies are
developed and proven with memory devices.
------------------------------
Date: 18 Dec 1981 (Friday) 1124-EST
From: STECKEL at HARV-10
Subject: M68000, again
The major, abiding, fault with ANY current 68000 paging implementation
is that recovery from page faults is extremely limited. The two chip
scheme allows one to call in a page which is on secondary storage. It
does NOT allow one to abort the instruction entirely and enter any new
environment. This essentially means that any paging system on such a
machine is very limited in what scheme of traps, faults, etc., are
available to users.
For example, if one is attempting to allocate stack space on demand as
the program requires it, the information the allocator has about the
page reference is merely an address. The information that the
reference was via the stack pointer is not (as far as I know)
available.
We asked Apollo to give us a stack extension feature in their system
to enable us to run ECL (an extensible language) on their machines and
they mostly went "uhh.....". A kluge where one essentially tells the
page manager "I'm gonna need some more pages" was the only one
feasable with their hardware.
Geoff Steckel (STECKEL@Harv-10)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #47
∂24-Dec-81 0027 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #47
Date: 24 Dec 1981 0253-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Works Digest Thursday, 24 Dec 1981 Volume 1 : Issue 47
Today's Topics:
Administrivia
Paging On Other Hardware
National Semiconductor NS16032s - Availability
Commentary - Contents Of This Digest
----------------------------------------------------------------------
Date: 20 Dec 1981 1924-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Administrivia
An old bug involving truncated messages just cropped up while sending
Monday's digest. There was no digest yesterday. Let me know if you
did not receive a complete digest on Monday, and I will resend one to
you.
This is the final digest of the year. I want to wish everyone a very
Merry Christmas, and a Happy New Year. Next digest is scheduled for
the 4th of January.
Cheers,
JSol
------------------------------
Date: 21 December 1981 23:17 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: stacks on the 68000
Sender: COMSAT.SoftArts at MIT-Multics
I thought that 68000 stack references went to memory. If so, the two
CPU paging kludge would work with no modifications. Is the stack
register a really weird kludge?
[FLAME ON]
The VAX paging system appears to offer no improvements in basic design
since the work done on the ATLAS in the early 60's. Granted the
hardware support is much better but I get the impression that the VAX
paging scheme is needlessly complex!
I also noticed that people cannot figure out the second step of the
reasoning chain which begins:
The reason for paging is to provide a large memory space
in a small physical memory.
The next step is:
The reason to have a large memory space is to provide a
large [object] name space.
Large name/address spaces eliminate the need for vasty crocks such as
overlay managers, data object paging managers and explicit user disk
I/O. A great deal was written about this in the early sixties but as
usual the industry is still 20-30 years behind the software
technology.
------------------------------
Date: 22 Dec 1981 02:27:29-PST
From: decvax!microsoft!gordon at Berkeley
There are currently 'several' National Semiconductor NS16032s which
are primarily functional. A completly functional chip is expected
soon, the MMU chip will be available around mid-year. It is
interesting to note that the 16032's MMU is a dual-level virtual
memory system, with an associative LRU memory to hold the mapping
elements.
The MMU also has lots of fancy debugging go-fast in it, such
as hardware breakpoints, and instruction back-tracing.
The architecture is very good, and it looks like the initial
10mhz part will run 'c' a little bit faster than the 8mhz 68000. The
hardware people claim that the internal layout of the chip will allow
a 2 to 1 improvement in speed, without requiring faster clocks and
memorys, when they do their next design itteration.
------------------------------
Date: 22 December 1981 22:06-EST
From: Brian P. Lloyd <LLOYD at MIT-MC>
Subject: Content of this digest
C'mon gang. I thought that this digest was created to discuss
workstations and not chips. I accept the fact that the 68000 has
demand paging problems, but I also feel that the hardware hacking
sould be discussed in Info-Micro. I personally would rather talk
about making useful workstations for PEOPLE and what approaches other
manufacturers have taken. I guess I am interested in ideas rather
than engineering.
Brian
[I agree that the discussion of paging hardware for a specific
microcomputer should be best discussed on INFO-MICRO, but as the
discussion has started (with today's digest) to branch out to a more
general paging discussion, there is really no better forum
Subject: WorkS Digest V2 #1
∂03-Jan-82 2230 Jonathan Alan Solomon <JSol@RUTGERS> WorkS Digest V2 #1
Date: 3 Jan 1982 2356-EST
From: Jonathan Alan Solomon <JSol@RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Via: Rutgers.ArpaNet; 3 Jan 82 20:59-PDT
Via: Sri-Unix; 4 Jan 82 0:19-EDT
Works Digest Monday, 4 Jan 1982 Volume 2 : Issue 1
Today's Topics: Administrivia - Volume 2
Hunting For NEC Graphics S100 Board
Large Address Spaces - Multics
68000-Based APPLE Query
SUN Workstation
----------------------------------------------------------------------
Date: 3 Jan 1982 2319-EST
From: The Moderator <JSol at Rutgers>
Subject: Administrivia
Well, I'm back from my vacation and am resuming WorkS today as
promised. Note that we are now officially starting Volume 2. I plan
to increment the volume number each year on Jan 1st.
An additional note, In the next week or so, I will be moving my base
of operations to the USC-ECL machine, and WorkS will also move
there. At this point, there is no address for WorkS at USC-ECL, so
continue to use either the Rutgers address or the MIT-AI address. I
will keep you posted on developments as they occur. I hope the
transition will be a smooth one...
Cheers,
JSol
------------------------------
Date: 24 Dec 1981 06:37:44-PST
From: allegra!rdg at Berkeley
Subject: Hunting for NEC graphics S100 board
We are hunting for an S100 graphics board built around the
NEC graphics display controller (the PD7220). Has anyone
built one? Any commercially available boards?
please respond to allegra!rdg.
thanks, -ron gordon (201) 582-4099.
------------------------------
Date: 25 December 1981 16:34-EST
From: Leonard N. Foner <FONER at MIT-AI>
Subject: Large address spaces
I'm certainly no expert on Multics, since I've never really used it,
but isn't the Multics system designed to really \use/ a large address
space? I vaguely recall \somebody/ discussing (on this list?) the
fact that Multics looks at everything as if it's in memory, and that
"files" are a convenience to the user more than anything else.
What's the real story here? Any such systems around, which really
make use of a large address space in virtual memory? Any workstations
around which do this? Is there good reason for a workstation in
particular to be \able/ to do this or to be engineered to take
advantage of using a very large virtual address space in a really
aggressive way? Or will "good old software" for workstations be okay?
Does it matter for workstations if they really \are/ 20-30 years
behind the times, as someone has suggested most systems are... is it
that much of a pain in the neck to those who design them?
<LNF>
------------------------------
Date: Sunday, 27 Dec 1981 15:31-PST
From: mike at RAND-UNIX
Subject: 68000-based APPLE
Does anyone have any information about the new APPLE system,
supposedly 68000-based? Will it be cheap or expensive? Will it
have a bitmap? Will it truly run Smalltalk? When will it be
released? Etc.
Rumors are welcome.
Michael Wahrman
------------------------------
Date: 1 January 1982 19:16-EST
From: Andrew S. Cromarty <CROM at MIT-AI>
Subject: SUN Workstation
On about 13-July there was an entry in this digest from Andy
Bechtolsheim (AVB at SU-AI) describing the Stanford University Network
workstation: 68000-based w/ 1Kx800 BitBlt display, mouse, Multibus,
Ethernet interface. I later requested more info from him on the SUN,
but my request went unanswered.
Particularly in light of the discussion in this digest regarding 68000
paging problems, it would be interesting to know what approach they
have taken in designing the SUN. I assume it's not the same "solution"
that Apollo used (twin 68000's), since the 13-July synopsis simply
described the processor as "8 MHz 68000, executing without wait
states". It does, however, offer both segmentation and paging
("two-level, multi-process, segment-page memory map"), so the problem
is there to be solved. Does anyone know how they handle it?
asc
------------------------------
End of WorkS Digest
*******************
-------
The SUN workstation indeed uses a segment-page scheme that
supports a 10 MHz 68000 executing without wait states.
No attempt has been made to simulate full virtual memory with the 68000.
Instead, the SUN has been designed to use the 68010, the virtual memory
version of the 68000 that is expected for 3Q 1982.
The 68010 has the same pin-out as the 68000, but handles
instruction aborts correctly and has a number of other small enhancements
such as an interrupt vector base register and programmable function codes.
The announced report on the SUN workstation is finally available.
If you like a copy, please send your requests to PRATT@SCORE.
Subject: WorkS Digest V2 #2
∂05-Jan-82 2322 Jonathan Alan Solomon <JSol@RUTGERS> WorkS Digest V2 #2
Date: 5 Jan 1982 2048-EST
From: Jonathan Alan Solomon <JSol@RUTGERS>
To: Works: ;
Reply-to: WorkS at Rutgers
Via: Rutgers.ArpaNet; 5 Jan 82 17:52-PDT
Via: Sri-Unix; 5 Jan 82 23:19-EDT
Works Digest Wednesday, 6 Jan 1982 Volume 2 : Issue 2
Today's Topics: The SUN Workstation
Multics - Paging Using Segments
APPLE 68000 Rumor Answered & Query - 60010 With Paging
----------------------------------------------------------------------
Date: 4 Jan 1982 04:27:26-PST
From: pratt@Shasta at Sumex-Aim
Subject: Sun paging (and status)
To answer the question about paging on the Sun:
While the Sun does indeed have paging it is not demand paging, at
least not with the 68000 processor. The paging unit serves two
purposes: to provide hardware support for memory allocation at 2K
(page) granularity, and as a place holder for the 68010, the promised
VM 68000. The Sun is designed to perform demand paging with the 68010
as currently spec'd by Motorola.
Given the inability of the 68000 to work on other things while waiting
for a page in the twin-processor solution, not to mention the
additional complexity of that solution, we decided not to go the
twin-processor route. (This isn't the NIH syndrome, Forest Baskett
was kicking around the twin-processor 68000 idea at Stanford two or
three years ago.) We felt that a more satisfactory approach was to
build a non-demand pager for non-VM applications and shift our
attention to the VM applications when the 68010 appeared.
While VM would be nice right now for our purposes, we are still
managing to develop a lot of our software without it. You can make up
for no VM to a considerable extent by being rather more generous with
memory; Unix runs nicely on a Sun with 768K of memory, the size Sun I
have in my office at the moment. (That doesn't count the 128K of
graphics memory). However it WOULD make our programming a lot easier
if we had VM. (Motorola, take notice.)
This may be a good opportunity to fill people in on what's been
happening lately with the Sun project.
Hardware Status:
All three Multibus boards comprising the basic Sun workstation have
reached the production revision of their PC boards. The processor
board has been in production for several months and by now there are
over a hundred of them in the field, mostly delivered to other
customers of the licensees besides Stanford. The graphics board has
been in production for about a month, and limited quantities are
appearing. The Ethernet interface was just debugged last week and
will now go into production. (About time, Stanford has only a dozen
right now. This is holding up our using our processor boards, which
aren't much use without the network. We are very dependent these days
on Ethernet.)
Manufacture:
Various components of the Sun are presently licensed to some half
dozen companies. CadLinc is licensed to manufacture all three boards
and will bring out a completely packaged workstation with mouse and
Star-like 17" landscape mode display. Forward Technology have
delivered most of the processor boards to date, followed (I think) by
Pacific Microcomputer, although Codata recently produced 50 processor
boards. Imagen also produces processor boards, mainly for use in
their Canon laser printer interface.
The graphics board is licensed to Forward and CadLinc. The Ethernet
board is licensed to CadLinc, and will also be produced by VSI.
Of the above manufacturers, only CadLinc is presently in a position to
offer a complete packaged Sun. Stanford has been quoted a price of
$6800 from CadLinc for complete Suns (including mouse). However it
would cost Stanford only $4900 + labor to plug in assembled and tested
boards (at prices available to Stanford) and bolt the packaging, power
supply, and card cage together, where labor = 1/2 day at the most, so
we're not inclined to take the $6800 figure as the rock bottom price
for Suns at Stanford.
Use
At Stanford we presently have 10 Suns in operation. Three are
graphics workstations, three more are Ethertips (terminal
concentrators with 16 lines on two of them, 32 lines on a third), one
is a "bridge" (pseudo-Gateway), one a software development station,
one the LOTS workstation, a partially built 16-processor teaching tool
that presently can work as another Tip, and one at my home. We also
have all the boards and other parts for three more graphics
workstations, though the demand for Ethernet interfaces in other
applications may delay putting these into service, at least on the
Ethernet.
Some Suns are in operation at Lucasfilm, I don't know how many. They
use mainly processor boards, disks, serial line connections, and octal
uart cards as DZ-11 equivalents. Jim Lawson there tells me they are
starting to rely on Sun Unix as much as on UCB Vax Unix for software
development.
Imagen is delivering its first printers now, with Sun processor boards
in them.
Codata have shipped quite a number (50?) of their CTS-300
workstations, which use the Sun processor board but their own
graphics.
I don't know what the hundred or more other processor boards are being
used for, or by whom.
Software:
Unix: John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on
the Sun. We have an Ethernet based version of this Unix running at
Stanford, using a large file on a Vax (Shasta@SUNet) as a disk
accessed via the Xerox Leaf file access protocol. (This must be one
of the more remote filesystems for Unices doing remote physical io.
However I have a more remote one: a Unix running at my home via a 10
mile 1200 baud phone line, good for debugging Unix when you're stuck
at home though hopeless for actually using Unix.)
Emacs: John Seamons has James Gosling's Unix Emacs running on the Sun,
which he says runs a trifle slower than the speed we are accustomed to
on the Vax.
Network software. We have Xerox Pup protocols running at Stanford,
namely RTP/BSP for user telnet and Sequin/Leaf for most other
applications. However we intend to go to IP/TCP ASAP.
Benchmarks: Never trust a benchmark. However I did a number of C
benchmarks for a broad spectrum of nonnumeric programs (eight queens,
Floyd's shortest path algorithm, a Lisp-like environment in which I
ran merge sort, algebraic differentiation, and disjunctive-normal-form
translation), and for all of them came up on the Sun with 70-75% the
performance of the same C programs on Diablo, a Vax 11/780, with -O
(optimizer on) for both machines' compilers. Floating point however
loses badly on the Sun, as do arrays with dimensions not a power of
two (essentially a compiler problem).
Literature:
Andy Bechtolsheim, Forest Baskett, and I have this weekend been
putting the finishing touches to "The SUN Workstation: Hardware
Architecture" and will be distributing copies this week. Requests to
avb@sail or pratt@score.
Vaughan Pratt
[Thanks also go to AVB@SU-AI for announcing the SUN Handbook -JSol]
------------------------------
Date: 4 Jan 1982 13:55:58-PST
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
Subject: Multics
Cc: FONER@MIT-AI
Multics is a good example of how not to design a large-address space
machine, at least not in the future. (Disclaimer: the following is
based on my own experience 5 years ago on a Multics system at the Rome
Air Development Center, and on Organick's book on Multics, which I
recommend as a reference. If anything I say is grossly wrong or out
of date, I'm sure some kind folks will point out my errors without
*too* much laughter.)
A Multics address is really an ordered pair, consisting of a segment
number and an offset into that segment. As I recall, the offset is
about 18 bits, yielding a maximum segment size of 256K. The system
supports a large number of simultaneously available segments. Address
arithmetic does *not* carry from the offset into the segment number;
hence the proper view is that the system provides multiple address
spaces, rather than one large one. When one *initiates a segment*
(more below), the system converts the name of the segment into a
segment number, and returns a pointer to the base of the segment;
after that, it may be addressed like any other part of memory.
Files, stack space, heap space, and external subroutines are all
segments. When a file is opened, or a procedure is called for the
first time, the appropriate segment is initiated. Appropriate spells
are cast over various tables, etc., to avoid operating system overhead
on subsequent calls to the same procedure. The system is fairly smart
about breaking the linkage between a segment number and a particular
segment, as when a particular procedure is recompiled; users doing
sophisticated things can trip over this, however.
The two big things this buys you are (a) runtime binding of procedure
calls (there is a linker, though, for packages); and (b) a file can be
accessed like any other part of memory. The classic example of how
the latter can be used is file copying: one initiates the two files
(the PL/I library will properly initialize structure descriptors), and
then just do a structure assignment.
The place where all this falls down is large files. 256K is just not
enough -- nor are we likely to see address spaces large enough -- to
handle the size files people will want to manipulate. Multics handles
large files as "multisegment files", a horrible kludge. Such files
cannot be accessed as primary memory; special access methods must be
used. Back when I was using Multics, many of the system utilities
didn't understand about such beasts, and hence could not be used on
multisegment files. But it isn't clear to me that enough bits could
have been allocated. Historically, essentially every machine ever
built (or its program-compatible successors) has run out of address
space bits; furthermore, such bits are a scarce resource for the
machine architect. To expect a general-purpose CPU to reserve enough
bits to address the large files we can expect to use in the future
just isn't reasonable; the alternative would slow down performance the
rest of the time.
------------------------------
Date: 5 January 1982 02:42-EST
From: John C. Gilmore <GNU at MIT-AI>
Subject: 68000 Apple rumor response; (unrelated) 68010 with paging query
My sources told me that the Apple IV would have a pair of 68000's --
one to run just the keyboard and bitmap display, the other to do the
"work". It would run smalltalk. I don't know the resolution or the
mouse quality, storage size, interfaces, etc. Presumably it would not
support paging until Motorola fixes the chip.
On that topic, I heard a number recently -- 68010 -- which was
supposed to be the version that supports page faults. Does anyone
have any further info?
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #3
∂12-Jan-82 0443 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #3
Date: 9 Jan 1982 1321-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works: ;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb.ArpaNet; 9 Jan 82 13:18-PDT
Via: Sri-Unix; 12 Jan 82 6:04-EDT
Works Digest Saturday, 9 Jan 1982 Volume 2 : Issue 3
Today's Topics: Administrivia - All Moved In
Large Address Spaces - Multics & IBM
----------------------------------------------------------------------
Date: 8 Jan 1981 16:06-PST
From: The Moderator <JSol at USC-ECLB>
Subject: All Moved In...
Many thanks for being patient with me while I moved from
Rutgers to USC-ECL. Mail to WorkS may now be sent to
WorkS@USC-ECLB, in addition to the normal addresses, WorkS@MIT-AI and
WorkS@Rutgers.
The archives are now in the directory <JSOL.WORKS> at USC-ECLB. Volume
1 in its Entirety is stored in <JSOL.WORKS>VOLUME-1.TXT. Current
issues are stored in <JSOL.WORKS>WORKS.RECENT.
In addition, I am now testing new software used to distribute WorkS.
Please report any problems (truncated or garbled digests or
multiple digests received) to me with great dilligency
(WorkS-Request@USC-ECLB).
------------------------------
Date: 6 January 1982 01:11 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Large address spaces
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: Leonard N. Foner <FONER at MIT-AI>
There are actually a few related concepts:
Uniform addressing --
This is used by both Multics and the IBM/38 among others.
It means that one can just name an object and need not
worry about how to acccess it, i.e. via memory or via a
file system. This is closely related to object-oriented
architectures, though Multics represents an earlier
approach and deals better with large objects than small
ones.
Large address space:
This means that the set of objects that can be named is
sufficiently large and can be represented in a virtual
memory.
Large memory:
This simply means that one does not have to spend most of
the time developing strategies to fit inside of a small
machine. Of course, when one has a small machine reality
can impinge. A large address space with a small memory
can be inefficient, but this is relative. The concept of
a working set is real and effective.
Memory based communication:
This is important in Multics, but can present problems in
distributed architectures. But is it actually possible to
distribute a memory based system. Message based
communication is simpler to distributed since all one need
do is implement the interfaces and thus can support
communications among heterogeneous components.
These concepts are all relevenet to work stations. Basically,
having a large uniform address space with sufficient physical
resource to support it greatly reduces the cost of
implementation and makes for a more effective implementation.
I think Star attempts to do this, but doesn't have enough
physical memory to make the best use of its architecture -- at
least in the first implementation.
------------------------------
Date: 6 January 1982 01:14 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: large address spaces
I know that Multics uses its large address space well. A
workstation designed which uses its large address space is the
LISP machine being sold by Symbolics. My feeling is that it is
possible to write software for poorly designed hardware running
horrid operating systems but there is no need to do so. It is
possible to waste time with dippy address spaces and
atavistically designed operating systems but it is a lot easier
to just concentrate on new applications.
------------------------------
Date: 6 January 1982 23:00 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: decvax!duke!unc!smb at UCB-C70, FONER at MIT-AI
While this not a Multics forum..
The comment that the Multics segmentation scheme fails because
it does not handle large files is wrong. This is saying that
it fails because the scheme does not support record files,
indexed files or whatever. In fact, these are all objects that
normally use program mediated access (i.e., an I/O system).
The fact that Multics streamlines the simple cases and provides
efficient mechamisms for implementing files (i.e. directories
of segments -- the multisegment files) does not meant that it
is bad, just that programmers fall into the trap of using the
nonmediated direct access to segments because it is there, not
because it is appropriate for a particular application.
It is also a FEATURE that segments and offsets are independent.
If increasing the offset did go over into the next segment,
errors in address arithmetic could result in bashing some bits
in some utterly unrelated an innocent object. Since offsets,
not segment numbers, are normally used in program address
calculations bad programs would only clobber the segment they
owned, not another one. This random clobber is particularly
nasty because it can go undiscovered for years -- long after
the cause and knowledge about how to recover has been lost.
This is not to say that Multics is perfect, but much of the bad
press is undeserved.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #4
∂12-Jan-82 1825 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #4
Date: 12 Jan 1982 1228-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works: ;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 12 Jan 82 15:32-EDT
Via: Brl-Bmd; 12 Jan 82 19:11-EDT
Works Digest Sunday, 10 Jan 1982 Volume 2 : Issue 4
Today's Topics: What Is A WorkStation
Multics
256kB Chip & TandyCorp Announcement Rumors
68xxx - What's Happening At Motorola
----------------------------------------------------------------------
Date: 12 January 1982 12:15-PST
From: The Moderator <JSol at USC-ECLB>
Subject: Administrivia - AAAAUUUUUGGGGGHHHH!!!!
The new software also broke in very unfriendly ways, but it is
still better than truncated messages. Please bear with us while we put
the peices back together. If you are missing digests, please send a
message to WorkS-REQUEST asking me to resend you that issue. If you
get random messages (about problems with receiving mail from the
arpanet), please ignore them. I am on the recipient list, so I know
when these messages occur. If you receive multiple digests for Issue
4, please ignore them as well and accept my apologies, I have no idea
how many of them have actually been delivered. Starting with issue 5 I
would like to hear about any problem you have, thank you for your
cooperation in this matter.
I'm very sorry that this happened, please excuse any garbage
in your mailfile caused by this unfortunate problem!
Cheers,
JSol
------------------------------
Date: 9 January 1982 00:09-EST
From: Andrew S. Cromarty <CROM at MIT-AI>
Subject: WorkStations?
I received several informative responses to my request for details on
the SUN. Among the most striking features of those responses, though,
was an assortment of comments suggesting that the SUN didn't have
paging or segmentation, that it did have segmentation and paging but
not virtual memory, and that it was "never intended to be a
workstation".
Some of those remarks may be attributable to inadequate press given to
the SUN (including by the SUN designers themselves, I suspect), but
they also suggest two questions that this dialogue has been talking
around for many months without (I think) addressing directly:
1. Why virtual memory? (This question was actually asked, or at least
implied, by FONER on 25-Dec.) Particularly when physical memory prices
are approaching dirt-cheaphood and address spaces for micros are in
the megabyte range (and certainly in the 100K range without any
problem), do we need virtual memory? Consider: there's an overhead in
the translation through paging tables and so forth, so it doesn't come
for free, even when supported in hardware (which still isn't free
itself, and requires maintenance, additional design effort, and so
forth.) Sure, RAM isn't free either, but those 64K bit chips are about
$7 each. I'm not suggesting that we abandon virtual memory; I'm
questioning what its virtues are in a WorkStation. Are the
applications we're going to run in PWS's going to be impeded or
impossible without it, or enhanced by it? Will it make a significant,
cost-effective difference?
2. What is a workstation? There seems to be a considerable difference
of opinion. Does a PWS have to be as powerful as a Lisp Machine in
order to qualify? (If so, not many will.) If the SUN can run Xenix
(the 16-bit Unix clone) including Unix Emacs, support some local
graphics, and handle some computation on its own plus network to a
file server, for example, is it still not a WorkStation?
A legitimate response to the latter question might be "Does it matter
what we call it?", but for the fact that Personal WorkStations are
presumably what the WorkS dialogue is about. Elsewhere I am part of a
group which meets regularly to discuss PWS's in all their gory detail,
and it seems difficult for us to get away from the question of what
one is; usually we find ourselves left with answers that sound
something like "It's whatever functionality I want sitting on my
desk", which can serve as a useful design touchstone but is hardly a
rigorous specification.
Similarly, I suggest that virtual memory is worth discussing here
precisely because there is apparently disagreement among WorkS
participants as to whether virtual memory techniques and problems are
germane to a WorkStation dialogue (even when the discussion centers on
implementations in PWS's). Are demand paging or segmentation really
needed for the applications we'll be running on these machines? Yes,
segmentation can provide protection and memory management for
object-oriented systems (for example), or even just for large programs
in general, but is that what we'll be using WorkStations for? Or will
they be used mostly for text-editing? Perhaps the Xerox star is just a
slick special-application turnkey system, the exception rather than
the rule among PWS's, and all we'll generally want to use these
systems for is relatively simple applications, saving large jobs for
larger, faster processors that the box on your desk can't, perhaps
even shouldn't try to, compete with.
If we are the (admittedly self-appointed) experts on WorkStations and
can't decide (that is, agree) on what fundamental features and
architecture they should have, who will? (I shudder at the thought of
leaving it to IBM, or even DEC.)
Any takers?
cheers, asc
[I would like to see some discussion on the subject of exactly "What
is a WorkStation." -JSol]
------------------------------
Date: 8 January 1982 22:03-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Multics
Most explanations of Multics that I have seen on the net have been
somewhere between misinformed and completely wrong. However, Steven
Bellovin's description of the Multics virtual memory system is quite
correct. There are only two things I'd like to add. First of all,
the ability to dynamically link subroutines is one of the most
important things that Multics is about, and is (as far as I'm
concerned) the single most important thing about the segmentation
scheme. Secondly, the limitation on segment size is indeed a pain,
but it is not completely debilitating. In particular, programs
("object segments", to use the official term) never run into this
limitation; only data files do. And while 256K is not totally
gigantic, it does suffice for most purposes. Some people do run into
the problem; many (most) never actually encounter it.
When I had an opportunity to work on building a similar system, I did
participate in the creation of an improved design, which is being used
in the S-1 architecture at Lawrence Livermore. Without going into
gross detail, the boundary between the segment number and the offset
in an S-1 address "floats" such that you can have a lot of little
segments as well as a few really big segments in your address space.
The total pointer size is 31 bits, and you can have as few as one
segment, or as many as 16K segments (or maybe it's 32K). This still
isn't enough, but we only had 31 bits in which to work; if you really
wanted to feel that the problem was solved, I'd follow the example of
an experimental project at HP Labs that I once heard about in which
addresses were 96 bits: 48 bits each of segment number and offset.
------------------------------
Date: 9 January 1982 12:56-EST
From: Hal Abelson <HAL at MIT-MC>
Subject: rumors
I hear from a reliable source that Tandy will announce their new
6800-based machine on January 19.
I've also heard tell of a company that is currently working on a 256K
byte (yes, BYTE) chip that they expect to be marketing next year.
Again, the source of the rumor is reliable. What do people think
about the credibility of this claim?
------------------------------
Date: 9 Jan 1982 10:24:22-PST
From: pratt@Shasta at Sumex-Aim
Subject: 68xxx devices
Cc: pratt
While I was in Austin this week I took the opportunity to talk to John
Zolnowsky at Motorola about 68xxx parts. Here's the scoop on three
promised chips.
68010
This is the VM 68000. A long time back (> 6 mo.) Motorola promised
this samples of this chip for August 82. It is reassuring that with
this date now only half as far away Motorola has not felt it necessary
to postpone it significantly. They expect to be have working silicon
then themselves, and to be making samples available in September.
68020
This is a sort of successor to the 68000, available around the third
quarter of 83. It features:
(i) 32-bit data bus
(ii) 24-bit address bus for the 84-pin version and 32 for the
100-pin version.
(iii) Bit-extraction operations, akin to the PDP-10
load-byte/deposit-byte operations. Current plan is that the
descriptor word giving the left and right boundaries of the field can
go in either the instruction stream or a register.
(iv) Higher-density version of the HMOS process (if you care).
(v) 10 MHz clock (i.e. no faster, pity).
68881
This is a floating point processor that one attaches to the 680x0,
also available around the third quarter of 83. It features:
(i) IEEE standard floating point operations.
(ii) 5 usec multiply.
Vaughan Pratt
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #5
∂14-Jan-82 0153 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #5
Date: 13 Jan 1982 2209-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 14 Jan 82 1:10-EDT
Via: Brl-Bmd; 14 Jan 82 1:27-EDT
Works Digest Thursday, 14 Jan 1982 Volume 2 : Issue 5
Today's Topics: Administrivia
Query Answer - Why Virtual Memory
What Is A WorkStation
----------------------------------------------------------------------
Date: 13 January 1982 21:04-PST
From: The Moderator <JSol at Rutgers>
Subject: Administrivia - Problems (hopefully) straightened out
At this point, you should all be up to Volume 2, Issue 5. The mail
problems of the past few days should be straightened out. At the very
least, the people responsible for the machine which distributes the
digest have more control over the distribution. This should mean
better service for all subscribers.
This also means that I want to hear about every little nit picking
problem that happens which could be linked to me or this digest. Send
any bugs or gripes to WorkS-Request@USC-ECLB. Thanks.
Enjoy,
JSol
------------------------------
Date: 12 Jan 1982 22:44:33-PST
From: pratt@Shasta at Sumex-Aim
Subject: asc answered
To answer another asc question:
Why virtual memory? The main fact supporting the need for VM is:
While available physical memory per machine continues to grow,
programs and their data are both managing to keep ahead in
size.
If this fact doesn't hold for your particular system, you don't need
VM. You are either lucky (maybe you only use your computer to search
for large primes) or software-poor. For many if not most computer
users the above is an inescapable fact. For them, if anything the gap
is growing.
This fact alone does not lead inevitably to VM. Programs can always
be broken up into overlays. Data can always be maintained on files
and the relevant portions read and written when needed. However with
a simple main memory one pays one of two prices to get at more data
than the memory will hold: either program structure or program
performance suffers.
Program structure suffers when you have to complicate a simple
algorithm by inserting code to read and write files, and to translate
between internal and external representations as data moves between
primary and secondary memory. Programmers get so used to this mode of
operation that they tend not to notice the loss of structure in their
programs. However it can be made quite apparent by rewriting the code
pretending that the whole universe lives in primary memory.
You can restore your program structure by treating all references as
composite references to a file and an object in that file, and
interpreting those references with routines that decide when to swap
subroutines and data in and out. Done right, the only place where the
primary-secondary memory distinction shows up is in the interpreter of
the references; your program itself need no longer make the
distinction.
The price for this approach is performance; all references triple or
worse in cost. Performance-wise, you are much better off sticking to
your original ill-structured program. Few programmers attach more
importance to structure than to performance .
The role of VM is to restore program structure without the performance
price of the interpretive solution. With VM, references cost about
the same as with a simple memory scheme for references to objects
already in main memory. Page faults cost, but the idea is that any
other scheme may well have to go to secondary memory approximately as
often as a VM scheme. The big saving then is clean program structure
at little or no performance cost.
The program-structure problem is particularly visible in a language
that encourages one or another form of structure in one's programs,
e.g. Lisp and APL. A simple recursive Lisp routine can be quite
mangled by a need to move some of its data between primary and
secondary storage. And an APL one-liner can turn into a two-pager if
secondary storage is needed. For such languages VM becomes
particularly vital.
If you bring your old file-manipulating programming style with you to
a VM environment you will naturally ask "Why do I need VM?" You
don't, if you stick to that style. The reason the Sun project can
continue without VM is that all of the code we inherit, most
Unix-style C code, is written for manual overlays and heavy file
manipulation. While we stick to that style we can put off VM day. We
would like to be able to get away from that style however, both to
improve the style of our low-level programs (C, Pascal) and to be able
to write Lisp and APL programs in something better than a Fortran
style laced with file operations.
Vaughan Pratt
------------------------------
Date: 13 January 1982 1219-EST (Wednesday)
From: Hank Walker at CMU-10A
Subject: virtual memory, workstation, big chip
For those that think that you don't need virtual memory when you have
lots of physical memory, read Peter Denning's editorial in this
month's CACM. Any architect will say that you need it, and that it
doesn't cost that much to implement (at least not VAX-style virtual
memory).
The question of what is a workstation reminds me of the what is a
minicomputer discussion. In the beginning, a minicomputer was defined
by its size, price, and computational power. It was soon realized
that since speed changes over time, the defining factors are size and
price, not performance. A minicomputer is probably anything in the
$5,000-$250,000 small box to VAX-size range. Similarly, a workstation
is defined by it's basic features, such as keyboard, network
interface, graphics, disk, or whatever, and it's basic price, such as
$10,000-$30,000. It is not defined by any performance measures except
for minimal ones. Available software might also define a workstation,
although this too changes radically over time.
For those that believe that someone is going to announce a 2 megabit
RAM next year, I suggest that you read the literature such as the IEEE
Journal of Solid-State Circuits or the IEEE Journal of Electron
Devices. The largest reported chip to date was a nonworking 1 megabit
Japanese chip. The largest reported working RAMs are 256K RAMs, which
have been reported by several sources. In other words, there is no
way that anyone is going to announce a 2 megabit RAM for sale for
quite some time, if only because they can make much more money selling
smaller chips. A 2 megabit RAM will be announced by 1985 at the
earliest, except possibly for laboratory experiments.
Now if you were talking about a 2 megabit bubble chip.
P. S. Rumors seen in BYTE that I know something about are usually not
very accurate, but do contain some grain of truth.
------------------------------
Date: Wednesday, 13 January 1982, 18:19-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: OK, What is a WorkS Digest?
It seems backwards for us to all join a Workstations mailing list and
then all ask "What is a Workstation?". I think a more profitable
question might be, "What is it that we all want to talk about?". I'd
be happy to just say that we want to discuss single-user computers
intended for interactive use, with interesting user interfaces.
[As Moderator, I would be disappointed if the WorkS mailbox became
filled with endless reams of people trying to figure out what they
want to talk about. WorkS has a very defined list of topics, and
answering the question "What is a WorkStation" is definitely one of
them. In fact the creation of this list was in part to come up with
some clear cut ideas of just what a WorkStation is. -JSol]
As to whether you need virtual memory: well, at least SOME personal
computers require some or all of large address spaces, large amounts
of memory, and/or uniform addressing. Bob Frankston's recent mail
described these issues. If everything you're doing fits into an
affordable amount of RAM, then it it wasteful to use mapping for
demand paging. Lisp Machines need a WHOLE LOT of memory, and we
cannot possibly have that much RAM on the machines; our need for
demand paging is clear to us. Certainly you can get some worthwhile
things done in far smaller computers, and I think that 68000's with
lots of main memory and no demand paging will be quite useful for many
applications. A 68000 with a lot of main memory would be fine for
running VisiCalc; the existing computers are distinctly too small for
many real-world applications to fit comfortably.
------------------------------
Date: 13 Jan 1982 1910-CST
From: CS.APPLEWHITE at UTEXAS-20
Subject: Workstation rationale and virtual memory
I don't propose to give a precise definition of 'workstation' (I don't
think a useful one exists), but I will describe @i<why> and @i<what>
I want in a workstation. I think my basic desires have been described
in this digest before. I want the basic power of a reasonable large
machine (say a VAX) on hand so that I can build up a support
environment *I* like.
There isn't anything qualitatively different a workstation can offer
that isn't available on a conventional machine. What is different is
the amount of control I have over the workstation's resources. For
example, I have a set of experimental VLSI programs which will eat up
hours of cpu time at the drop of a hat. Given that someone has to pay
for machine resources, the workstation is cheaper than say, the 2060
I'm editing this note on.
Virtual Memory : There is never enough main memory. No matter how
much I have, my ambitions soon exceed it. For example, my main
interest for a workstation is VLSI design, and I have developed a set
of programs to do this. Unfortunately, the size of my database is
quite large compared to main memory, and a lots of cycles are needed
to massage it. It's counterproductive (and expensive) to spend time
splitting it up. Access to a large number of objects simply requires
a large number of address bits. I can do all of this on a big machine,
but it's more expensive and (wall clock) probably slower.
For the sake of argument, assume that physical memory is large enough.
With virtual memory, my application will run on any workstation I have
access to; without it, the application will run only on machines
configured with enough memory. The point is that virtual memory
separates the application from details of the machine configuration.
-Hugh
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #6
∂15-Jan-82 0305 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #6
Date: 14 Jan 1982 2211-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 15 Jan 82 1:13-EDT
Via: Brl-Bmd; 15 Jan 82 1:35-EDT
Works Digest Friday, 15 Jan 1982 Volume 2 : Issue 6
Today's Topics: RFC - Book Layout
Food For Thought - WorkStations Query
Query Replies (a few of them) - What Is A WorkStation
Laser Printer - Based On The SUN Board
----------------------------------------------------------------------
Date: 14 Jan 1982 (Thursday) 1019-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Possible layout for Workstations book: comments?
PERSONAL COMPUTER WORKSTATIONS
Chapter 1: What is a Personal Workstation
- General Introduction
- Its impact
- List the components, brief description
Chapter 2: Management & Economics of PWS (Maybe 2 chapters)
- Why there is a trend towards PWS's
- Where they belong, their function
- What they should NOT be used for
- Advantages, incremental growth, dist'd topologically
- Costs, what they are worth, how much should one pay for a PWS
- What makes a WS a justifiable expenditure
- Businesses of the future
- New management styles
- Other changes due to PWS's
Chapter 3: Expectations
- Hardware, limited capabilities; it is not a mainframe
- Software, it will be much better
- What a PWS will and will not do
- Misconceptions
Chapter 4: [POSSIBLE] Design of a PWS
- What does one need in a PWS
- What NOT to put in a PWS
- Expansion considerations
- Reliability of WS, needs for new kinds of procedures
for PWS's (archiving, backup, security, location)
Chapter 5: Distributed Systems & Local Networks [could be 2 chapters]
- Definition
- How they work
- Architecture
- BroadBand, Baseband, what can one put on a BBN
- What constitutes a distributed envr. Why does one need one
- Problems, management & other babble w/dist sys. (concurrency)
Chapter 6: Connecting up a PWS
- Interface considerations, problems
- Lack of Standards, types of communications, modes, bandwidth
- Gateways
- What does one attach to a PWS? How to set up a PWS
in an envr, some example(s).
- +'s and -'s of networks, what kinds: Broad v. Base band
- Other devices, Laser Beam Printers, special devices
Chapter 7: The User Interface
- Display Managers
- Personalization
- User-oriented devices, representations.
- Heterogeneous environments
- User environments ]
- Programmer environments ] their needs
Chapter 8: The Workstation's Next Step
- Now that we've got them, what else can they do for us
- Training considerations
- How do we "use" the workstation
- Office of the Future
- Engineering for the future (throw away drafting
introduce CAD)
- Impact of the WS
DESCRIPTION
PERSONAL COMPUTER WORKSTATIONS, tentative title, will be a book aimed
at the technical and management market. Introducing Personal
Workstations, defining some of the terms, identifying problems that
exist, the goal is a leading edge informative book, from which a
manager will understand what personal workstations can accomplish and
how they can best be utilized in his environment.
------------------------------
Date: Thursday, 14 January 1982 11:06-EST
From: DPR at MIT-XX
Subject: questions I'd like to answer
Generally, I find myself bored with the content of WorkS. THus, to
spice it up let me ask some questions that I care about.
1. Rather than worrying about chips I care about the packaging of
those chips into workstations. What are the best 68000 based products
people have seen out now that so many are being announced (Computex,
Dual, Wicat, Charles River Data Systems, BBN's BitGraph...)?
2. Is a multi-processor workstation a good idea (for dynamic graphics,
for example)? Adding additional hardware processors with shared
memory doesn't seem to add much to hardware cost, so why has no one
done it?
3. I hypothesize that sound output on a workstation is cute, but a
terrible product idea (in shared offices, it is annoying...). For
similar reasons sound input is a problem. Is there a good use for
sound in an office?
4. How do you train users of winchester-based systems to do proper
backup so that they don't lose everything the first time their disk
fails? Is there a technical solution (require a local net with a
backup server?)
5. There seem to be two distinct design points for workstations
regarding theeir communications environment -- either they are always
connected to a net and always listening (for mail, e.g.), or they are
only connected when the user is running a communications appl. (such
as FTP or fetching mail from a mail drop server). Each is workable,
but system usability, hardware design requirements (e.g., to always be
listeening requires a kind of "personal timesharing system"), network
technology (ehternet vs. digital pabx) are all affected by the choice
of design point. Can anyone comment on their experience with one
choice or the other; is one clearly better? is one cheaper?
David
------------------------------
Date: 13 Jan 1982 00:10:42-PST
From: pratt@Shasta at Sumex-Aim
Subject: asc answered (again)
To answer yet another asc question:
What is a workstation? I haven't a clue, making me suspect it is the
wrong question. So I'll change the question to "Where should
computing resources be located, and at what time granularity and
community size should they be shared?" Without going into great
detail, here's an institutional answer based on today's prices and
performance figures.
Processors and main memory should go on the user's desk, in a corner
of the box that the display goes in. Secondary memory should consist
of perhaps 150 megabytes shared by 5-10 users, connected say by one
Ethernet. Tertiary memory is harder to pin down, but might consist of
a few gigabytes shared by 100 users. Printers (which should of course
be laser printers) should be shared by one floor's worth of people -
it is a pain to have to retrieve printouts from another floor.
This is the model on which the Sun workstation design has been based.
The design gets its economical leverage (a) by respecting this model,
and (b) by parsimonious implementation.
For noninstitutional users effective sharing is much more awkward to
arrange, putting at a disadvantage anyone who needs to use a computer
at home, whether or not they also have access to a computer at work.
Either much cheaper memory, or much higher bandwidth communication
with shared resources, will alleviate this problem. Of the two,
better communications is the better solution, one reason being that
software you can really benefit from is not the sort of thing you
generally want to be maintaining on your own, even if you have a 100
megabyte disk to maintain it on.
The above pretty much circumscribes "the system." If you can do
better than this you are either a hobbyist (no slight intended, I am
both a computer hobbyist and a ham - VK2AUA - myself) or are willing
to settle for less than productive computing resources. Don't forget
to figure in the value of your time when calculating the cost of lost
productivity. Also don't forget that "usable" computers and memories
are getting pretty cheap - we hope to get the Sun workstation design
down to $1500 worth of parts including packaging within the next year
or two, to bring the retail cost down to well under $5000.
Vaughan Pratt
------------------------------
Date: 12 Jan 1982 11:55:34-PST
From: decvax!yale-comix!ima!johnl at Berkeley
From: John R. Levine
From: The INTERACTIVE Electric Calculator Co., Cambridge MA.
Subject: SUN workstation
Friends at Yale just got a nifty laser printer that is based on a SUN
board. Contrary to earlier claims, no paging. Perhaps they're just
waiting for the 68010 and 68020.
------------------------------
Date: 14 January 1982 01:23-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: WorkStations?
To: CROM at MIT-AI
90% of what a programmer does at his terminal is editing (modifying
and viewing) text (source programs, documentation of programs,
expository articles about research, electronic mail). Thus a
workstation should be defined as something that can do this 90%
totally locally and call up a network for the rest.
100% of what a secretary or publisher does is editing text (financial
data, correspondence, articles). Thus a workstation should be defined
as something that can do all this and then send the result out to the
postal service (correspondence) or the printing press (articles).
------------------------------
Date: 14 January 1982 05:25-EST
From: Frank J. Wancho <FJW at MIT-MC>
Subject: What's a WorkStation
Seems to me that the definition is a function of the kind of work that
needs to be done. For the most part, the recent discussion centers
around S&E applications programming as the work - and there are those
who will say, won't a relatively dumb terminal connected to a super
mainframe do the job...
But, there are other kinds of work stations that are not being
discussed here, and maybe should be.
One is the manager's work station. He's the one who wants to query
locally shared databases (through a local net) as well as some piece
of much larger databases elsewhere. He also wants to draw
plots/graphs of the extracted data, both on the screen and occassional
hardcopy, maybe at times, in color, for a report or presentation. He
also wants to write draft reports, papers, and corespondence to have
his secretary cleanup (format) and print - and maybe even send to
someone else (via electronic means).
Another is the office manager's work station. Mostly what the office
secretary will use to prepare "paper" work and correspondence for
inter-office and inter- and intra-site delivery... the first step
toward the "paperless" office.
And the last one of interest (to my people) is the project engineer's
work station. His is the combination of all of the above, although
the programming requirements are more routine, such as massaging data
to prepare technical reports. Like the manager, he also needs to
access the large databases to prepare his reports too...
And all these somewhat different types of work stations need to
communicate with each other and the outside world - and for a total
cost of less than $5K per user - not $10-$30K... And do all of that
today (with whatever's currently available, as an interim off-the-self
solution that is not self-obsolescent), maybe tomorrow (*if* there is
something really better and cheaper worth waiting for).
Now, we have some ideas along those lines and we need to know if we've
overlooked somethings in either the choice of the hardware or the
choice of the software (operating system). Given that most of the
WorkS discussions have been rather highly technical and leaning
heavily toward the kind of work station that supports mainly heavy S&E
applications programming, am I alone and maybe in the wrong discussion
group?
--Frank
------------------------------
Date: 14 January 1982 2049-EST (Thursday)
From: George.Coulouris at CMU-10A
Subject: What is a workstation?
Given that we want personal machines that offer a natural and
convenient user interface for all of the information handling tasks
that we and other, possibly more naive, users want to do, I believe
that we can derive some important consequences. A natural user
interface to any reasonably sophisticated task must contain a visual
representation of the state of the task as it progresses. If the task
is complex, the visual representation needs to be quite rich in order
to represent its state. It is for this reason that high-resolution
displays have become so popular, not because all workstations are used
for typesetting, vlsi design, or any other specific interactive
graphical purpose.
The visual representation needs to change in real time, so that it
constitutes a 'window onto the state of the application'. For many
applications, this involves animation-like image generation, *directly
from the application data structures*. It therefore follows that the
application program that manages the application data structures
should run in the workstation, so that the data structures are
available to the 'animation process'. I am therefore led to the
conclusion that a workstation must have sufficient resources to
execute a very large proportion of the interactive tasks its users
wish to perform, leaving only non-interactive and very infrequently
used software to run in other kinds of computer system. Of course, the
workstation programs may call upon other stations to perform services
(shared file access, printing, mailing, etc) but the state of the task
has to stored in the workstation if a smoothly integrated interactive
environment is to be achieved. This leads me to the further
conclusion that workstations need as many of the architectural
features that have been found really useful in current machines as we
can afford to put into them, so that they can run the application
software well. In addition, they need extra hardware support for the
screen in order to achieve the above mentioned smooth animation.
George Coulouris
(Computer Systems Laboratory, Queen Mary College, London)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #7
∂16-Jan-82 1933 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #7
Date: 16 Jan 1982 1629-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 16 Jan 82 19:33-EDT
Via: Brl-Bmd; 16 Jan 82 19:44-EDT
Works Digest Saturday, 16 Jan 1982 Volume 2 : Issue 7
Today's Topics:
Virtual Memory Concepts, Memory Schemes
----------------------------------------------------------------------
Date: 14 January 1982 01:16 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: WORKS V2 #4: Memory Schemes
1. Why virtual memory?
When the large computers came out everyone said that memory was
getting cheaper and that virtual memory roached performance and was
obviously unnecessary. Everyone learned to lived in cramped memory
space and thousands of programmer hours were wasted on hairbag overlay
schemes and disk based memory managers.
When minicomputers came out everyone said that memory was getting
cheaper and that virtual memory roached performance and was obviously
unnecessary. Everyone went bananas trying to cram anything into itty
bitty 64K (B or W) address spaces which was especially ludicrous since
the machine often had .5M(B/W) on it.
When midicomputers came out I personally flamed at a couple of the
manufacturers suggesting that they consider putting in VM. They at
least conceded that it could be done efficiently but they couldn't
imagine why I'd need given a full 20 bit address space. When I
explained that I would have to limit the size of the symbol table at
x, they explained that I should write a software paging system.
When microcomputers came out everyone was blown away by the fact that
you could stack 300 of them in the carcass of a bombardier beetle and
have room left over for an I/O multiplexer chip so no one considered
VM. So what do we have today?
"Why can't VisiCalc hold more stuff in it?"
"Damned, the editor buffer is full again and now I can't
just add memory."
"You can't call a Macsyma program from a PL/I program
because they don't both fit in memory even if there is
enough room."
In other words. Everyone is bumping into the same garbage they bumped
into ten years ago except that more people are bumping into it and
this time we might all win.
As far as segmentation goes I approve completely. Segmentation lets
PL/I call Macsyma since it enforces a set of rules which describe how
all programs have to communicate and it allows them to share an
address space (segmentation is not as important on object oriented
machines since each object can be viewed as a segment).
A very successful segmented machine is the HP41C calculator. It
provides segmentation and dynamic linking in a tangible form. It
provides one system segment, one writable segment and four user
addable segments each of which may contain any number of named entry
points. A key may be bound to any entry point.
When I buy a device, such as the magnetic card reader, I plug it into
one of the segment slots and suddenly I can invoke a whole series of
programs which can read and write data to this device. If I buy the
business package I can suddenly run the TBOND function to evaluate
Treasury bills and so on. I am often surprised that such a simple and
powerful scheme is used so rarely.
------------------------------
Date: 14 Jan 1982 08:19:14-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: Another view of virtual memory
While the comments about a person's desires exceeding his machine is a
good argument for virtual memory, I would like to present a somewhat
different view. (50 pounds of code in a 5 pound machine is the
classical party line taken by many vendors who sell machines with
virtual memory (except Burroughs).)
I view paging as primarily a physical memory management and protection
strategy. While real memory will never be large enough for everything
you can think of, it is large enough so a bit here and there can be
sacrificed to fragmentation. Relocating and protecting access of
things via the hardware in nice, fixed-size chunks makes things much
easier. Anyone who has written a memory allocator knows it is MUCH
easier to write a good one for fixed-sized blocks than one for
variable requests. Not having to scrimp and save each byte, and the
availability of the paging hardware makes managing the contents of
physical memory much easier. It also lets you play the 50 pounds of
code game if you want, but that is not as visibly important (I realize
it is to MANY people).
I have a more Multics-oriented view of segments - they are structuring
tools (code or data). However, I do subscribe to the "1-1/2
dimensional" virtual memory schemes. By 1-1/2 dimensions I mean the
bits carry from page into segment, rather than the Multics 2
dimensional scheme whereby they don't. There are several reasons.
Unless you use gigantic addresses (like the HP scheme mentioned here
before), you can never have the right number of bits where you need
them. Some programs have huge arrays so need very large segments,
others have many arrays, needing many segments, and still others have
both!! While the S1 scheme of a floating boundary is clever, it is
hard to do if you aren't designing your own hardware. Therefore, for
machines with a flat virtual address space, like the VAX (which are
vexed by a small page size), a good scheme is 16 bits of page and 16
bits of segment with carry's allowed. This allows a file in the
filesystem, or a large array, to be mapped into memory as several
contiguous segments, providing consecutive, indexable addresses. To
prevent tragedy, simply force the following segment to be a hole which
will access trap. If you put these firewalls between each active
segment, you do reduce the maximum number of distict, active segments
to 2**15, but that is still quite a few (I know, Multics-ers wouldn't
be satisfied). And if the segments are code, they can normally be
allocated adjacently with reasonable safety.
The 1-1/2D scheme is straightforward to implement given a machine with
only demand paging, enough logical address bits (32!), and a decent
page size. The VAX bairly qualifies on this last point. To really
use the VAX 2 gigabyte logical address space requires 8 megabytes of
physical page tables, if you don't share segment tables. This is the
current maximum physical memory!!!! People building pagers should go
read the studies IBM did a long time ago. The picked 1K and 4K byte
page sizes for a good reason!!
-Mike
------------------------------
Date: 14 January 1982 12:43-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: WorkS Digest V2 #5: VM
Large address space gives you uniformity of reference, as has been
pointed out, across physical configurations and for that matter
software configurations (what happens to your 'real memory' when you
need to enlarge some process's workspace?). The penalty is presumed
to be performance.
The discussion on virtual memory so far has assumed that swap
management is independent of the application. It would appear an
unwarranted assumption. When performance requires it, it is normal to
tweak lower-level virtual machines in one's hierarchy. For instance,
if it is discovered that some particular kind of array calculation is
taking a large fraction of the runtime of an important program, one
may well wish to modify the compiler or the microcode of the machine
one is running on, or for that matter buy a processor which runs that
calculation better. Similarly, it should be possible to define
interfaces to swap management (note, for instance, the ITS paging
parameters PagAhd and PagRange which warn the system of linear sweeps)
which either define a particular regime of swapping or even allow
swapping to be fully controlled by the user process (e.g. in addition
to requesting swap-in of the faulted page, request several 'related'
pages): a page fault becomes essentially a kind of subroutine
invocation.
Demand paging with its various refinements is a sound general-purpose
method, but certainly other methods are possible when the application
warrants.
Stavros Macrakis
------------------------------
Date: 14 Jan 1982 1102-PST
Subject: Re: big memory chips
From: BILLW at SRI-KL
I believe the largest RAM chip to date is an IBM 288K dynamic (in a *9
organization). There were rumors in Electronic engineering Times of
an entirely new nonvolitile RAM technology that is alledged to be able
to put 4M bits on a chip the size of todays ram chips using ordinary
processes. Sort of two 5 volt chips with electron beams going
inbetween them, if I recall (this was a couple of months ago). Most
of the secrets are being kept under wraps until "they can be adaquatly
protected".
Bill W
------------------------------
From: William "Chops" Westfield <BillW @ SRI-KL>
Subject: more on big memories
zurich -(dj)--nippon electric co. (nec) of japan
expects to post higher profits for the year ending march 31,
senior executive vice president m. hirota told zurich
bankers thursday.
:
:
hirota said nec has -solved all the technical
complications for mass production of a 256 kilobit random
access memory (kram) circuit, which would quadruple the
memory capacity of computers and telecommunications
equipment which currently use 64 kram circuits. demand for
the 64 kram circuits is still growing and should peak in
1984 or 1985, he predicted, adding that demand for 256 kram
circuits should become significant by 1986.
:
:
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #8
∂16-Jan-82 2147 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #8
Date: 16 Jan 1982 1926-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 16 Jan 82 23:21-EDT
Via: Brl-Bmd; 16 Jan 82 23:38-EDT
Works Digest Sunday, 17 Jan 1982 Volume 2 : Issue 8
Today's Topics: What is a WorkStation?
Backups Or Not?
----------------------------------------------------------------------
Date: 16 January 1982 00:15-EST
From: Brian P. Lloyd <LLOYD at MIT-MC>
Subject: What is a workstation?
Most of us here think that 'workstation' has something to do with
computers. It doesn't. It is the place we go to work. For most of
the world it is a desk with a telephone.
For those of us involved with computers it is also someplace we go to
communicate with a computer. I think the real question is, "What do
we need to make our workstations more efficient?" Now we can get into
talking about LAN's, local processors, bitmapped displays, and shared
databases.
Brian
------------------------------
Date: 14 January 1982 01:16 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: WORKS V2 #4: What is Work
2. What is a workstation?
As far as I am concerned a workstation is any small computer system
which is aimed at a single user. Word processors are workstations,
LISP machines are workstations, the S-1 computer will be a very
powerful workstation. A workstation must provide computer power for
an individual. This puts certain economic and interface constraints
on it but in my definition an advanced telephone is a kind of
workstation even if it lacks a full keyboard and a crt.
One big problem in the computer field is that it is hard not to be
conservative without appearing flakey. It is as if predicting the
future of the automobile I had the choice of describing fuel injection
or teleportation. My guess is that we are about ten years from a desk
top Symbolics LISP Machine.
------------------------------
Date: Saturday, 16 January 1982, 10:04-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Dave Reed's questions
Regarding the backup problem: I don't see how you can convince people to
do backup if they don't appreciate the need -- they'll find out soon
enough, probably. When Symbolics sets up a new site, they insist that
the site either provide a time-sharing system on their network that has
tape drives, or else that the site buy a magtape drive for file system
backup; the marketing department makes it clear that any configuration
that we are willing to sell must include provision for file system
backup either locally or over the net.
Regarding network communications, Lisp Machines are always listening to
the net. If for no other reasons, this is useful because of the FINGER
server that lets other people ask who is logged into the machine, and
the SEND server which receives interactive messages. It's not
particularly expensive to do this; we just have a process that sits
around blocked all the time waiting for a packet to appear on the
network, which doesn't cost anything much.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #9
∂18-Jan-82 1154 Jon Solomon <WorkS@USC-ECLB> WorkS Digest V2 #9
Date: 17 Jan 1982 1733-PST
From: Jon Solomon <WorkS@USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 17 Jan 82 0:04-EDT
Via: Brl-Bmd; 18 Jan 82 13:07-EDT
Works Digest Monday, 18 Jan 1982 Volume 2 : Issue 9
Today's Topics: Page Size & Page Tables
Ways To Do Backups
Must Displays And Mainframes Share Memory?
----------------------------------------------------------------------
Date: 17 Jan 1982 0007-EST
From: WALKER at CMU-20C
cc: mo at LBL-UNIX
Subject: page size
While not wishing to extend the infinitely long discussion on
paging, I can't let the references to the VAX page size pass without
comment.
It is true that 8Mbytes is required for the system page table when the
process space is 2Gbytes. However you are confusing implementation
with architecture. Just because the VAX-11/780 has an 8Mbyte memory
limit doesn't mean that VAX-11/XXX will have such a limit. If you
also keep in mind that the architecture was designed to last a long
time, you will realize that 8Mbytes may be only a small percentage of
the physical memory space when 2Gbyte programs become common. This is
not to say that AI types have it easy right now.
If you are really worried about the page table space, it is possible
to add another level of indirection (and factor of 16 reduction in
space) by putting the system page table into the reserved part of
system space by modifying the architecture at a future date. I
doubt that it will ever happen. This is somewhat similar to
National's NS16000 scheme.
A small page size is good because it reduces internal fragmentation.
It can't be too small because it is your unit of communicating with
the disk. 512 bytes has been found to be a good compromise no matter
what any IBM studies say. 512 is definitely better than 1K or 2K.
In summary, think in 20 year time spans. The 360/370 has been around
nearly that long. The VAX will be too.
------------------------------
Date: 16 Jan 1982 21:24:58-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
To: walker at cmu-20c
Subject: page size
If memory gets cheap enough to use 8 megs of page tables for EACH process,
you won't give a flip about internal fragmentation. You will still
be concerned about the amount of screwing with page tables the system
has to do.
Two gigabyte programs are very real things right now. VLSI rule checkers
and routing algorithms are just waiting for the extra address bits.
On a more religous level, I doubt seriously if the Vax will have
the lifetime of the 370. It is too easy to build better machines
these days, but that is fuel for a different flame on a different
mailing list.
-Mike
[Agreed - INFO-VAX@MIT-AI is the best place for such a discussion.
-JSol]
------------------------------
Date: 17 January 1982 1228-EST (Sunday)
From: Hank Walker at CMU-10A
Subject: backups
There are two basic ways to do backups if you are a small business.
The first is to have some removable media, such as a floppy or TU58
tape cartridge that you plug in periodically. The operating system
automatically handles incremental backups. It tells the user whenever
to insert a new cartridge. Intelligent encoding of backup data should
keep the typical daily backup down to 200K or so per workstation. The
OS should keep track of everything and just tell the user to do
something once per day or so.
The second alternative is for backups to be handled by your
maintenance contract. If the small business computer is hooked up to
cable TV, and so has a high-speed path to the field service office,
then backups take place rapidly. Naturally, encryption would be used
by the owner. If there are no cable links, then the machine can have
a 1200 baud modem, which requires about 1/2 hour to back up 200K.
Since you really only need half duplex, a 2400 baud modem would reduce
the time to 15 minutes. The field service center would call machines
in its area at night to perform backup to their large disks or tape.
Directories of backed up files would be left behind, or exist on disk
at the center. If the user needed a backed up file, the machine would
dial the center, request the file, and have it shipped over the phone
line.
Backup will only succeed if the user has almost no involvement, other
than doing the most trivial of things, such as "insert catridge
MONDAY", or "wait, fetching backup copy...".
------------------------------
Date: 17 January 1982 18:13-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: What is a workstation?
Subject: Must works&display and main-cpu share memory?
To: George.Coulouris at CMU-10A
In order for the state as presented on the workststion screen to
be understandable to the human, it must be built upon a small
number of symbols each of which can be learned quickly, the
small number of symbols so that the total system can be learned
in a short time (a small number of quicklies, not a million
quicklies which can be a rather long training period).
That being assumed, it's easy to represent these symbols and
their locations on the screen (x,y offset, x,y scale, angle if
rotated, and which other symbols overlay them). That being the
case, it doesn't take much data to transmit updates to the screen
from the computer that's running the process to the word-processor
that's displaying it. Thus I see no reason to insist that the
whole system (cpu-intensive process, and workstation display)
run in shared mainframe memory. It is sufficient that they be able
to communicate over some halfway-reasonable network (perhaps 9600 baud).
Thus we design the workstation for editing, display, and network
communication, and leave the cpu-intensive tasks for the big machine
that is shared among seveal users.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #10
∂21-Jan-82 0307 Jon Solomon <WorkS at USC-ECLB> WorkS Digest V2 #10
Date: 21 Jan 1982 0010-PST
From: Jon Solomon <WorkS at USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works:: ;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 21 Jan 82 3:14-EDT
Via: Brl-Bmd; 21 Jan 82 3:34-EDT
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
*******************
-------
Subject: WorkS Digest V2 #11
∂21-Jan-82 2237 Jon Solomon <WorkS at USC-ECLB> WorkS Digest V2 #11
Date: 21 Jan 1982 2058-PST
From: Jon Solomon <WorkS at USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works:: ;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 22 Jan 82 0:00-EDT
Via: Brl-Bmd; 22 Jan 82 0:16-EDT
Works Digest Friday, 22 Jan 1982 Volume 2 : Issue 11
Today's Topics: Hard Copy Output - Not Needed?
Query Reply - Everything In Main Memory
Multics - Quicksorts
----------------------------------------------------------------------
Date: 21 Jan 1982 0942-EST
From: WALKER at CMU-20C
Subject: hard copy
There is certainly no use for an optical character reader to insert a
machine-generated document into another machine, but what about all
the books, papers, etc already laying around? Most of this stuff can
be safely thrown away (look around your office, or at least mine), but
a lot of it is relatively timeless. It would be a royal pain to have
someone type in the Library of Congress by hand.
------------------------------
Date: 21 Jan 1982 1457-PST
From: BILLW at SRI-KL
Subject: Re: Large address spaces
Re: the whole world is not in main memory (for example my terminal).
Well, It could be, maybe it should be, and on a lot of workstations,
it IS. DMA displays have all sorts of advatages over any other type
of display. Its just that if the display bitmap takes 128K bytes,
and your processor only addresses 64K, you are in a lot of trouble.
WW
------------------------------
Date: 21 Jan 1982 09:03:26-PST
From: decvax!duke!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
To: REM@MIT-MC
Subject: Re: Multics
From REM@MIT-MC Thu Jan 21 08:55:16 1982
Via: duke!chico!ucbvax
Date: 21 January 1982 01:34-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Multics
To: chico!duke!unc!smb at UCB-C70
Quicksort is N↑2 worst case, so even in main memory it isn't
good. Thus it's a red herring. Anybody who would use it even
when it all fits in realmemory (no thrashing) is a loser
already and thrashing is beside the point. Some other methods
of sorting are n log n worst case, and some of them can be
made to run in virtual memory with much localness of accessing
so as to avoid thrashing if real memory is small, even tiny.
Quicksort is n*log n in the average case, and generally does quite
well, but that isn't my point at all. You've made it for me -- that
some sorts "can be made to run in virtual memory with much localness
of accessing", i.e., that the program *must* be aware that it may run
in that environment, that awareness of the underlying structure *is* a
concern of the programmer.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #12
∂22-Jan-82 2351 Jon Solomon <WorkS at USC-ECLB> WorkS Digest V2 #12
Date: 22 Jan 1982 2237-PST
From: Jon Solomon <WorkS at USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works:: ;
Reply-To: WorkS at USC-ECLB
Via: Usc-Eclb; 23 Jan 82 1:39-EDT
Via: Brl-Bmd; 23 Jan 82 1:54-EDT
Works Digest Saturday, 23 Jan 1982 Volume 2 : Issue 12
Today's Topics: Bell Labs 256K Ram
Swap & Shop - Computer Equipment Wanted
Status Of WorkS?
----------------------------------------------------------------------
Date: 22 January 1982 1400-EST (Friday)
From: Bob.Colwell at CMU-10A
Subject: 256K RAM from Bell
A friend at Bell who worked on their 64K DRAMs told me in 1980 that
their 256K DRAMs were going to be ready in late 1981, so sometime 1982
sounds about right for their real release. At the time, all that was
left to do was tweaking the myriad timing paths so that the chip
tended to reflect a constant load on the supply -- they were very
worried about noise margins and claimed that this was the major
contributor.
The 256K chip will use their redundant-rows technique that Bell
developed for their 64K DRAMs. (In fact, this same person told me
that the 256K and larger chips were the real reason that technique was
devised in the first place).
Did Newsweek really get the scoop over all of those Electronics News
magazines? They knew about Libya, too......
------------------------------
Date: 22 Jan 1982 1605-PST
From: Daul at OFFICE
Subject: WANTED: Computer Equipment
WANTED:
1. 3270 Emulator for DEC VT100 (supported by UNIX(tm))
2 . VAX -> IBM Channel connection (supported by UNIX(tm))
3. VAX -> IBM Bisync. connection, looks like a 3271
(supported by UNIX(tm))
For more information call Bob Herriot at 408 745 1300 Ext. 237. I
will relay info to Bob if you would rather use me as a go-between.
------------------------------
Date: 22 January 1982 11:36-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
WorkS appear to be degenerating. There is no need for long discussion
on trivial and peripheral points:
1. Of course we'll want hardcopy. Paper is a marvelous medium.
2. Of course we need OCR. However, it will likely be hard to justify
OCR's for individual workstations: reliable reading of free text is
remarkably difficult and expensive.
3. Some things are serial-access, some are random-access. Clearly the
logical interfaces to the two differ: the former is not a segment.
4. Few underlying mechanisms are strictly invisible. VM, like any
other such, has its demands but remarkably little overhead for
core-resident applications. Certainly, all interfaces should not be
forced into a Procrustean bed, requiring all file I/O to be through
demand paging.
Now, may we return the the discussion of workstations?
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V2 #13
∂27-Jan-82 0512 Jon Solomon <WorkS at USC-ECLB> WorkS Digest V2 #13
Date: 23 Jan 1982 2151-PST
From: Jon Solomon <WorkS at USC-ECLB>
Sender: JSOL at USC-ECLB
To: Works:: ;
Reply-To: WorkS at USC-ECLB
Reply-to: JSol at RAND-AI
Via: Usc-Eclb; 24 Jan 82 0:52-EDT
Via: Brl-Bmd; 24 Jan 82 14:36-EDT
Works Digest Sunday, 24 Jan 1982 Volume 2 : Issue 13
Today's Topics:
New Products - Radio Shack's Upgrade For TRS-80 Model II
WorkStation Requirements - What does a WorkStation Need?
Query Replies - Multiprocessor WorkStations & Sound Output
Cheap Memory Prices - 64K Chip for $10 Each
----------------------------------------------------------------------
Date: 23 January 1982 03:00 est
From: Schauble.Multics at MIT-Multics
Subject: Radio Shack announces new machine
Since I haven't yet seen this on the net...
On Tuesday Radio Shack announced a new top-of-the-line computer. This
is an upgrade to their Model II.
The computer contains both a Motorola 68000 and a Z-80. It will run
all existing Model II software written for the Z-80 without change.
The announcement said nothing about software for the 68000.
The basic configuration is 24X80 screen, keyboard, Z-80, 68000, one
DSDD 8" floppy offering 1.2 Mbyte storage, 128Kb main memory, two
serial interfaces and one Centronics style parallel. This sells for
$4900.
An extra floppy is $700. Extra memory is $450 for another 128K, then
~$1000 for another 256, making a maximum of 512k. This full-blown
machine will sell for ~$7100.
A hard disk is available for ~$5000 for 8 Mb.
Add a graphic board to this and I think you have a very nice personal
computer.
Paul
------------------------------
Date: 23 January 1982 1330-EST (Saturday)
From: Hank Walker at CMU-10A
Subject: What does a Workstation need?
What are the basic requirements of a workstation, and how can they be
met?
I will list these loose specs as my requirements for a workstation:
(1) Reasonably high resolution and performance graphics, at least 512
x 512 x 1 for the bottom-of-the-line system with speed sufficient to
prevent the user from having to wait for screen updates to any
significant degree for most tasks. Higher resolution, along with the
higher speed updates needed to maintain response time, and color, are
options for more expensive models. I assume that the graphics is
raster.
(2) Keyboard and mouse. Voice I/O might be an option.
(3) Access to secondary and tertiary storage.
(4) Processing power sufficient to make my interactive software truly
interactive. I also need power sufficient to handle my large
simulations.
(5) Ability to communicate with other people, again without system
speed getting in the way.
(6) Access to a good printer, although not necessarily Dover-like.
Here are possible ways of meeting the above requirements:
(1) The only reasonable way to meet the graphics requirements is with
a local frame buffer and graphics processor. Communications costs are
too high to do anything else. Most of the cost of this system will be
the terminal and frame buffer, not the graphics processor.
(2) Any old keyboard and mouse will do. The keyboard is clearly slow
enough to be handled remotely if desired. Mouse updates to the screen
will probably have to be handled locally, and don't involve that much
processing anyway.
(3) Disk drives and printers are about the only things that have
economy of scale these days. Given a high-bandwidth network, it may
be possible to eliminate local disk drives, tape drives, floppies,
etc. These are also lower reliability devices, so workstation
reliability could go up. It is not clear whether local or remote
disks will result in better performance/cost/reliability for a large
system, but is a possibility. A sufficiently large local memory might
cut down traffic enough to avoid a performance penalty if processing
is local. Anyway, there is some possibility that secondary and
tertiary storage need not be local to a workstation in a large system.
Clearly, in a small business that does not have continuous access (or
any access) to a high-speed network, local disk drives are required.
(4) As in (3), access to a high-speed network may eliminate the need
for local processing. However, most of the economy of scale in large
shared machines comes from higher utilization, which will lead to
lower performance, and lower packaging, power supply, etc costs. If
you already have a terminal with power supply, adding a small
processor won't add much of a cost penalty, assuming that utilization
of machines is high. Again, a small business will need self-contained
machines, and doesn't have this option.
Large machines will probably still be required for large jobs. Small
businesses won't do much of this, or can afford the slow network delay
when remotely submitting a batch job.
(5) A network as discussed above, will allow communication with
others. Small businesses might use cable TV (which may be tried in
Pittsburgh) or dialup phone lines.
(6) Large systems can share printers, while small businesses will need
their own. Large systems can more easily afford an expensive Dover,
but prices of laser printers should fall significantly in the future.
In summary, a small business, or anyone lacking access to a very high
speed network (Ethernet or faster) must have everything built into the
workstation, or plug into it. Workstations in a large business can
definitely share printers and tertiary storage. It might also be
possible to share secondary storage and processing. It may not be
cheaper to share interactive processing, but it is certainly
reasonable for batch jobs. The question of whether sharing disk
drives is reasonable is open, since it has never really been done.
Disk drives do have a clear economy of scale though.
------------------------------
Date: 23 January 1982 18:32-EST
From: Andrew S. Cromarty <CROM at MIT-AI>
Subject: Responses to some questions
cc: DPR at MIT-XX
2. Is a multi-processor workstation a good idea (for dynamic
graphics, for example)? Adding additional hardware
processors with shared memory doesn't seem to add much to
hardware cost, so why has no one done it? [DPR at MIT-XX]
I suspect that it slows down product development to address the
problems involved, especially because the issue of how to distribute
large computational tasks is itself an as-yet-unsolved research
problem. (There are, of course, some machines with coprocessors,
mathematical processors, etc., but these are really a degenerate case
of what you mean, if I understand your question.) Note that a
multi-processor arrangement is probably the only viable way to use an
iAPX432, and that the only stand-alone system using one (to my
knowledge), the 432/100, relies heavily on its additional processor (I
believe it's an 8086 sharing 432 memory and farming out tasks to it in
a SmallTalk implementation. The 8086 has a "window" on the 432 through
which they communicate, and the user communicates with the 8086, not
the 432. Someone correct me here if you know better.)
3. I hypothesize that sound output on a workstation is cute,
but a terrible product idea (in shared offices, it is
annoying...) . For similar reasons sound input is a problem.
Is there a good use for sound in an office? [DPR at MIT-XX]
Ever heard a typewriter? Ever worked in a secretarial pool? Most
employers seem to be rather unenlightened about acoustic disturbances
(the recent cult of office divider walls notwithstanding). Of course,
there is a human-engineering issue here regardless of how current
workplaces are organized, for which headphones might be a solution (if
there's a problem, which I think remains to be seen). As for
applications, I know people working on intelligent operating systems
that would say "Now are you really sure you want to do that?" when you
tell it to delete all the files you ever owned, for example. (Maybe I
should call them "clever" operating systems. But this isn't the place
to fight the battle of The Existence of AI.) Even without talking
workstations, it isn't too hard to imagine that trivial acoustic
feedback will be a useful adjunct to a fancy piece of software. (Silly
example: as I type, Emacs will beep at me if I abort out of a command
I initiate and change my mind about. The acoustic feedback is useful.
And nobody in my office has ever complained about the terminal beeping
too loudly.) As for voice input, 95% of what I've done to prepare this
mail message would have been done more efficiently and comfortably via
voice. If typing were more efficient, DictaPhone would never have made
it in the business market. (Remember, in offices (the workplace about
which you expressed concern), the vast majority of "work" is
paper-shuffling, and an awful lot of that is just plain typing in
text.) How soon speech input will be comercially viable is, of course,
another question.
asc
------------------------------
Date: 23 January 1982 18:36-EST
From: Andrew S. Cromarty <CROM at MIT-AI>
Subject: 64K chips
Verification for cheap memory prices: a friend at Stanford reports
that he is using 64K chips at $10 each for some hardware work there.
These prices only go in one direction.... asc
------------------------------
End of WorkS Digest
*******************
-------
∂23-Feb-82 2344 AVB WorkS Digest V2 #14
∂19-Feb-82 0204 The Moderator <WorkS@USC-ECLC> WorkS Digest V2 #14
Date: 19 Feb 1982 0024-PST
From: The Moderator <WorkS@USC-ECLC>
Subject: WorkS Digest V2 #14
Sender: JSOL at USC-ECLC
To: WORKS at USC-ECLC
Reply-To: JSol at USC-ECLC
Via: Usc-Eclc; 19 Feb 82 3:55-EDT
Via: Brl-Bmd; 19 Feb 82 4:03-EDT
Works Digest Friday, 19 Feb 1982 Volume 2 : Issue 14
Today's Topics: Administrivia - No More Digests
Topics For Discussion
Perceived Or Actual Complexity Of Systems
----------------------------------------------------------------------
Date: 19 February 1982 0013-PST
From: The Moderator <JSol at USC-ECLC>
Subject: No more digests
Effective with this issue, WORKS is now an direct distribution list.
Due to the low volume of mail, I will abandon the digest distribution
for this list. I may start doing digests again if the list starts to
become active again. Mail may be sent to WORKS@MIT-MC or WORKS@BRL.
The archive location has not changed, and will continue to be updated.
Please continue to mail problems and maintainence requests to
WORKS-REQUEST@MIT-MC or WORKS-REQUEST@USC-ECLC.
Enjoy,
--JSol
------------------------------
Date: 13 February 1982 1838-EST (Saturday)
From: George.Coulouris at CMU-10A
Subject: topics for discussion
1. Multiprocessor workstations
How many processors should a workstation have? If more than one, how
should they be exploited?
I am not thinking of the dedicated processors built in to disk
controllers, etc., although there is probably some mileage in
dedicating a processor to file handling and another to scan conversion
for the display (i.e. converting characters and graphical objects to
bit-map representation). The thing I find puzzling is: in a
single-user interactive system, is more than one processor needed to
provide the interactive response, even in sophisticated applications?
Has anyone got any practical or theoretical experience in this area? I
am a firm believer in the need for multiple cooperating processes to
structure the application software and enable the user to schedule his
own activities amongst a number of interactive task contexts, but at
any one instant, he/she is only interacting with one of them.
2. Software extensibility
Is it important to most users to be able to add functions to their
workstation? If so, do the extensions need the full power of a
programming language? Are we anywhere near to being able to offer
such a language to non-programmers?
------------------------------
Date: 17 February 1982 1639-EST (Wednesday)
From: Jeff.Shrager at CMU-10A
Subject: Perceived or actual complexity of systems
I am seeking pointers to papers etc on the actual or perceived
complexity of programming languages, systems, interfaces, or processes
relating to computers (debugging, editing, etc). Are there any good
dimensions along which to measure perceived complexity? Have any
experiments been done to measure this? (Note that the kind of
complexity that we are interested in is not directly related to
complexity of algorithms whose metric is of the sort: NSquared, or
NLogN. Rather, we are looking for measures in terms of learning
curves, or funnction use statistics (or anything else that might
indicate this sort of "human" complexity, not "mathematical"
complexity)).
------------------------------
End of WorkS Digest
*******************
-------
∂23-Feb-82 2345 AVB Perceived Complexity of computer and/or text editing systems
∂19-Feb-82 1548 Jon L White <JONL@MIT-MC> Perceived Complexity of computer and/or text editing systems
Date: 19 February 1982 14:37-EST
From: Jon L White <JONL@MIT-MC>
Subject: Perceived Complexity of computer and/or text editing systems
To: Jeff.Shrager at CMU-10A
cc: WORKS at MIT-MC, JONL at MIT-MC, Sheil at PARC-MAXC
Via: Mit-Mc; 19 Feb 82 14:39-EDT
Via: Brl-Bmd; 19 Feb 82 14:45-EDT
Re Your quest:
Date: 17 February 1982 1639-EST (Wednesday)
From: Jeff.Shrager at CMU-10A
To: works at MIT-MC, human-nets at MIT-MC, *tens at MIT-MC
Subject: Perceived or actual complexity of systems
I am seeking pointers to papers etc on the actual or perceived complexity
of programming languages, systems, interfaces, or processes relating to
computers (debugging, editing, etc). Are there any good dimensions along
which to measure perceived complexity? Have any experiments been done to
measure this? (Note that the kind of complexity that we are interested in
is not directly related to complexity of algorithms whose metric is of the
sort: NSquared, or NLogN. Rather, we are looking for measures in terms of
learning curves, or funnction use statistics (or anything else that might
indicate this sort of "human" complexity, not "mathematical" complexity)).
I'd reccomend looking at a paper by Beau Sheil of XEROX Palo Alto
Research Center "Coping With Complexity", CIS-15 (ssl-81-4) April 1981.
Also someone else at Xerox did a recent PhD thesis about the
complexity of using text editing systems (maybe Terry Roberts?); probably Beau
can give you pointers.
Dr. Beau Sheil
XEROX Palo Alto Research Center
2400 Hanover St.
Palo Alto CA
Arpa-Net: SHEIL@PARC-MAXC
∂23-Feb-82 2345 AVB Test and archive
∂19-Feb-82 1536 Jonathan Alan Solomon <JSOL@MIT-AI> Test and archive
Date: 19 February 1982 13:36-EST
From: Jonathan Alan Solomon <JSOL@MIT-AI>
Subject: Test and archive
To: APOLLO at MIT-AI
Via: Mit-Ai; 19 Feb 82 14:01-EDT
Via: Brl-Bmd; 19 Feb 82 14:18-EDT
This is yet another test, to be sure the list works from both AI and MC.
Someone asked me where the archive lives. Here is a brief explanation
for all to hear.
On host USC-ECLB, in one of my subdirectories, PS:<JSOL.WORKS>,
lives the complete archive of the WorkS mailing list. You may FTP this
file using the username ANONYMOUS and the password GUEST. Unfortunately
ECLB does not permit guest accounts, and AI ran out of disk space months
ago, hence the move of the archives from AI, where they used to be located.
If anyone has any trouble accessing the archives, I will be happy to
help out.
Cheers,
JSol
∂23-Feb-82 2359 AVB Workstations and multiprocessing
∂20-Feb-82 2235 Lars.Ericson at CMU-10A Workstations and multiprocessing
Date: 21 February 1982 0037-EST (Sunday)
From: Lars.Ericson at CMU-10A
To: WorkS at MIT-AI
Subject: Workstations and multiprocessing
Message-Id: <21Feb82 003749 LE60@CMU-10A>
Via: Mit-Ai; 21 Feb 82 0:39-EDT
Via: Brl-Bmd; 21 Feb 82 0:53-EDT
1) (Random) Has anybody used the new MC68000 machine that came out
(somebody in California, begins with a C?) -- the one with a real
pretty white case, seperate monitor, fancy looking keyboard. Maybe
begins with an F like Formula Systems or something.
2) (Multiprocessing) I think the proper model here is that one has
several powerful (68000) processors in your personal computer, some
of which are attached to special devices (like two sharing the disk,
two sharing the screen, one doing mouse and keyboard as well as general
purpose work).
All processors would be general purpose "process pools", and programs
would be built up from processes communicating with an IPC mechanism.
In a sense, it would be simply an artifact that some of the processors
happen to be connected to the graphics display. One would use a general-
purpose distributed processing language to organize use of the processes
available on each processor. That is, each processor would be running
its own instantiation of the operating system, and would think of the
other processors as if they were on a tiny local net. Everything
would communicate with message passing, although this could be optimized
with a multiple-port memory shared among processors, as opposed to a
tiny ETHERNET-style arrangement.
This would make it possible to realistically think of writing programs
which devoted themselves to a single aspect of the graphics display
which operate in parallel with other non-display programs.
I think a reasonable amount of compute power in such a configuration for
really friendly use would be a pool of 10 68000's (the updated version
of 68000, of course).
By the way, I have implemented a distributed processing language which
allows one to build programs composed of processes communicating via
message-passing. It works with VAXes running Berkeley UNIX which are
connected via 3 MB Ethernet.
-- Lars
∂24-Feb-82 0004 AVB Fortune 32:16
∂21-Feb-82 2011 David.Anderson at CMU-10A Fortune 32:16
Date: 21 February 1982 2157-EST (Sunday)
From: David.Anderson at CMU-10A
To: works at MIT-AI
Subject: Fortune 32:16
Message-Id: <21Feb82 215737 DA80@CMU-10A>
Via: Mit-Ai; 21 Feb 82 22:39-EDT
Via: Brl-Bmd; 21 Feb 82 22:42-EDT
The machine that Lars was describing sounds like the Fortune 32:16, a desktop
system based on the 68000 that is being built by Fortune Systems Corporation
in San Carlos, California. The basic system runs $5k, and includes 128k ram,
1Mb floppies, and an operating system "derived from Bell Labs proven Unix
system." This is expandable to 1Mb main memory + 20 Mb winchester.
Given the memory size, sounds like no bit-mapped display. Has anyone used one
of these? And what about the Wicat system? (Any one know if it has a bit-
mapped display?)
--dave
∂21-Feb-82 2306 Michael Muuss <mike@BRL> UNIX & Workstations & Networking ...
Date: 22 Feb 82 0:15:36-EST (Mon)
From: Michael Muuss <mike@BRL>
To: David.Anderson at Cmu-10a
cc: WorkS at Brl
Subject: UNIX & Workstations & Networking ...
Via: Brl-Bmd; 22 Feb 82 0:22-EDT
Nix on bit maped display (at least at this point) for the Fortune machine,
or the Wicat.
I had a chance to use both at the UNIX Convention. The Fortune machine
placed you at a (huge) menue to start, and allowed you to drop into
any one of a large number of levels. One of which was the UNIX Shell,
fortunately. A useful mechanism for novices, except that I hate
flying cursors around using the keyboard.
The Wicat does not currently run UNIX, although I am told that it
definitely will after they upgrade the processor board and the
system bus (!). Right now, what they have is a rather unsatisfying
clump of UNIX utilities ported to run under their own operating system.
With all the messiness that that entails. I understand that they are
promising real UNIX "soon".
At the convention, HCR anounced UNIX for the PERQ. The demo they did
was *ultra* spiffy, but it turned out that it was running under the
PERQ's native system, and was the software equivalent of a glossy
sales brochure. If they can come anywhere near the quality of the
demo with the result, I will be petty impressed. Of course, the PERQ
is rather expensive.
An interesting use of a 68000 was the BLIT, also reported on at the
convention. The intention here was to give PERQ type graphics and
multiple windows/viewports/whatever on a bit mapped display, with
communication to the host over 9600/19200 baud style async lines,
using the UNIX MPX link protocol (oh well). Very nice functionality
with extremely impressive response, considering what was going on.
This is definitely the way of the future for multi-user "workstation"
computers to interact with their users... The cost was also exceedingly
low, rumored to be around $6Kish for the prototypes, and $3Kish for
production models (which should be marketed by some little company
sometime in the not distant future). (For the curious, the designer
reported that BLIT was != Bacon Lettuce Interactive Tomato, and it
was != Bell Labs Interactive Terminal. DEC-10 fans will recognize
the origin).
Lots of groups are doing lots of neat things with 68000's. Most of
the ones I have heard about are using UNIX. Are there any other
sets of software being developed on the 68000?
On a slightly different note, one thing which distresses us here at
BRL quite a bit, is the fact that most of the people who are building
these workstations (Hewlett Packard, Wicat, Fortune, etc, etc) are
all answering "Oh yes, we support Ethernet, RS-232, bla, bla" networking,
so you can connect them all together and do distributed processing
and all these wonderful things. When pressed about what kind of
networking protocols they plan to use, the answer is ususally
something proprietary or special or otherwise incompatible.
Various parts of the Army (and other DoD elements are probably doing
the same thing) have started recommending that ALL computers,
where ever possible, support the DoD Standard Networking Protocol
TCP/IP. Our corporate goal is to be able to have uniform communications
(uniform in functionality and interface, not in speed) between
as many of our machines as we can, including all workstations sufficiently
non-braindamaged as to be able to multi-program. We would like to
be able to go on travel, and still be able to get to our personal
workstation through the nearest TIP. How do others feel about this?
Best,
-Mike
∂22-Feb-82 0902 lwa.mit-csr at BRL Fortune 32:16
Date: 22 Feb 1982 1050-EST (Monday)
From: lwa.mit-csr at BRL
Reply-to: lwa.INP at MIT-Multics
Subject: Fortune 32:16
To: WorkS at mit-ai
Via: Mit-Ai; 22 Feb 82 11:13-EDT
Via: Brl-Bmd; 22 Feb 82 11:27-EDT
The information I have seen indicates that neither the Wicat nor the
Fortune 32:16 has a bit-mapped display. In fact, as I recall, both
have 24x80 CRT's.
-Larry Allen
-------
∂24-Feb-82 0008 AVB Re: UNIX & Workstations & Networking ...
∂22-Feb-82 1138 lwa.mit-csr at BRL Re: UNIX & Workstations & Networking ...
Date: 22 Feb 1982 1113-EST (Monday)
From: lwa.mit-csr at BRL
Reply-to: lwa.INP at MIT-Multics
Subject: Re: UNIX & Workstations & Networking ...
In-reply-to: Your message of 22 Feb 82 0:15:36-EST (Mon)
To: mike at BRL
CC: WorkS at MIT-AI
Via: Mit-Ai; 22 Feb 82 13:18-EDT
Via: Brl-Bmd; 22 Feb 82 13:24-EDT
With respect to uniform network protocol standards:
HEAR! HEAR!
Our experience here at MIT has been that interconnecting network
HARDWARE is (relatively) easy. We have two different ringnets, an
experimental (ie 3 Mbaud) Ethernet, Chaosnet, and of course Arpanet,
and it is possible to forward packets among all of them. Unfortunately,
there are almost as many network protocols as networks, and it appears
that protocol translation is a very difficult problem.
Protocol standardization within an organization is, of course, as much
a political and administrative problem as a technical one. Each of
the available network protocols has its own technical advantages and
disadvantages. Also, writing network software seems to require a great
deal of time and manpower, so I don't expect the situation to improve
very quickly.
-------
∂28-Feb-82 1126 AVB Re: Works archive...
∂20-Feb-82 1615 Zellich at OFFICE-3 (Rich Zellich) Re: Works archive...
Date: 20 Feb 1982 1503-PST
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Works archive...
To: cbosg!nscs!vrt at BERKELEY, WorkS at MIT-AI
cc: Zellich at OFFICE-3
Via: Mit-Ai; 20 Feb 82 18:32-EDT
Via: Brl-Bmd; 20 Feb 82 18:44-EDT
The complete WorkS archives run almost 2 full large-size 3-ring
binders when run off on a line printer. The full file could be sent
to you as a message \maybe/, but I know my message system can't handle
a single file that large; maybe someone elses can. Of course, I could
edit a header onto the front of the file with XED, and then write the
edited version out as mailer-file [--UNSENT-MAIL--].cbosg...etc., but
I don't know if \your/ message system could handle it then.
Try a message to WorkS-Request if you decide you want the whole thing
- maybe the moderator can break it up into manageable chunks for you
without too much trouble.
A synopsis would be kind of hard - the discussions have changed quite
a bit over time as the list has matured. I think about half of the
archives will be found to be from the first 3-4 weeks of the lists
existence.
Good luck,
Rich Zellich
-------
∂28-Feb-82 1126 AVB General Works comments
∂20-Feb-82 1813 ROSSID at WHARTON-10 (David Rossien) General Works comments
Date: 20 Feb 1982 (Saturday) 1906-EDT
From: ROSSID at WHARTON-10 (David Rossien)
Subject: General Works comments
To: works at MIT-AI
Via: Mit-Ai; 20 Feb 82 19:08-EDT
Via: Brl-Bmd; 20 Feb 82 19:25-EDT
Hi:
I'm a new WorkS member, having spent last night reading the archives. I'm a
member of the Office Systems Technology Division of a Fortune 10 corporation,
involved in internal office automation consulting for the corporation,
worldwide. My group has a good bit of experience with "workstations," and we
currently have a group of Stars on an Ethernet, some Apollos on Domain, and I am
typing this in via a Datapoint on an ARC LAN. My particular interests are in
workstations in an office environment, integration of workstation functions, and
local area networks.
First, some observations, which also serve to answer some questions that people
have raised thus far:
1) What is a workstation? I consider a workstation a single-user (interactive)
computer. I expect most "interesting" workstations (e.g. those we want to
talk about) will also have the following functionality: high resolution
display, "interesting" user interfaces (e.g. CAT, mouse, tablet, touchpanel,
etc.), CPUs more powerful than the Z-80, and local area network capabilities.
2) On LAN speeds (someone asked why it mattere). After a good deal of
research, I consider the question of speed of an LAN to be similar to the
question of how good a roadbed a highway has. What that means is it is
@i(potentially) easier to go faster down a well paved highway than one with
potholes, and it is @i(potentially) easier to utilize a workstation which is
connected via a fast (10MB+) LAN. However, this does not mean that you can't
go fast on a crummy highway, or inch along on a highway made like the
Autobahn for that matter; the speed YOU travel is a function mostly of the
car you drive, not so much of the condition of the highway. Likewise, the
workstation, its configuration, and its architecture are the primary factors
in determining the its functionality, not the network it is connected to. It
is not particularly relevant to simply examine, say, an Ethernet, without
understanding what you will be attaching to it, and how the system will be
used. For example, think of how a system where workstations have local
storage (connected directly, off the LAN) in addition to a filerver (on
the LAN) in contrast to workstations which rely entirely on a file server.
In the former, the workstation need not access files over the LAN too often,
and in fact, the local storage could be "intelligent" and serve as a sort of
cache memory, automatically downloading from the file server what it thinks
the user might require next. I would not be at all surprised if under this
type of workstation configuration, a twisted pair (standard telephone wire)
9.6KB connection would serve all non-interactive voice/video applications.
3) On why we need a 10MB or greater LAN -- in fact, as the above comments
explain, we probably don't. That 10MB was formulated given the following
assumptions: a high resolution, bit mapped screen (1,000 by 1,000 is 1MB), a
typical network utilization rate of 10% (that is, since the network is a
shared resource, we assume we only get a 10% piece of the pie), and no local
storage. Now, if we have a maximum tolerated response time of 1.5 seconds to
put up a page on our screen (studies suggest that 1.5 seconds, if constant,
is a pretty good guestimate) we need an LAN speed of:
1000x1000B(screen size) x 10(utilization factor) / 1.5 sec =
about 6.6MB, which we round up to about 10 MB since all the numbers were
pulled out of a hat anyway and we just wanted an order of magnitude. As
mentioned above, notice most of the assumptions made are functions of the
@i(workstation) design. The primary assumption is that we would want to go
directly from file server on the LAN to the workstation screen, without using
the local storage as buffer/cache. Other assumptions include: no compression
algorithm in the bit mapped display (or even the fact that a bit mapped
display is required), and network utilization level of 10% (no-one really
knows, but clearly the network will be required more if we always use the
file server than if we have local storage, therefore higher utilization is a
function of the workstation configuration too).
4) And now, a question -- anyone on this list from the SPICE project? I had a
PERQ demonstration last week, but they really didn't say anything of great
interest. I have a writeup done by another member of our staff which
compares the two, concluding, as did I, that while there are some cute things
in both, till there is any end-type software who cares!? What I'd like to
know from SPICE/SALT people is, is there any documentation available to
non-CMU people on the project, where it is going, and what it is trying to
do? I know, for instance, that Three Rivers is getting Scribe to run on its
machine, but evidently NOT in interactive mode a la Etude and Janus, but
rather as the vanilla batch system, which is a real loss! Is there a goal of
interactive Scribe eventually? What are time frames for releasible end-user
products?
Well, that's it for now -- Dave Rossien (ROSSID@WHARTON)
∂28-Feb-82 1128 AVB Bit-map for the Wicat
∂22-Feb-82 1202 RI at MIT-XX (Richard Ilson) Bit-map for the Wicat
Date: 22 Feb 1982 1326-EST
From: RI at MIT-XX (Richard Ilson)
Subject: Bit-map for the Wicat
To: David.Anderson at CMU-10A
cc: works at MIT-AI
In-Reply-To: Your message of 21-Feb-82 2157-EST
Via: Mit-Ai; 22 Feb 82 13:29-EDT
Via: Brl-Bmd; 22 Feb 82 13:36-EDT
I have been in touch with Howard Gordon of Peninsula Research, which is
marketing the WICAT. When I asked him about bit-map availability for
the WICAT, and told him of its importance for a workstation, he replied
in a letter dated November 1981.
". . . Peninsula Research is working with Andy Bechtolscheim of Stanford
University to integrate his graphics and Ethernet boards with WICAT
hardware.
"We will perform our first integration tests in mid-December with the
graphics card installed in a WICAT System 150. Assuming we encounter no
major problems, we should have a working prototype of a complete work
station with bit-map graphics, Ethernet, MC68000, 256KB RAM, 10MB
Winchester, 1MB floppy, and WICAT software in January.
"It is our expectation that WICAT will take the work station into
production in early 1982. The total package would retail for
approximately $12,000."
For more information, contact:
Howard R. Gordon
Peninsula Research
20 Hurricane Street
Marina Del Rey, CA 90291
213-392-6200
-- Richard Ilson
-------
A while back, I discussed with Howard Gordon from Peninsula Research
the possibility of using the SUN graphics system in the WICAT system.
As it turned out, the WICAT display did not have sufficient resolution
to be compatible with the SUN graphics board.
In the meanwhile, WICAT started working on a lower-resolution bit-map
display option of their own design for their current system.
A new company, SUN Workstation Inc, has just received venture financing
with the mission to exclusively manufacture SUN workstations for
the workstation marketplace. For further information, please contact:
SUN Workstation Inc.
PO BOX 3005
Stanford, CA 94305
(415) 494-8922
∂28-Feb-82 1143 AVB Wicat Graphics
∂24-Feb-82 2206 Jeffrey at OFFICE Wicat Graphics
Date: 24 Feb 1982 2042-PST
From: Jeffrey at OFFICE
Subject: Wicat Graphics
To: works at MIT-AI
Via: Mit-Ai; 25 Feb 82 0:13-EDT
Via: Brl-Bmd; 25 Feb 82 0:24-EDT
I recently visited Wicat at their home office in Orem Utah. They are
located in A beautiful area about an hour's drive south of Salt Lake
City - directly beneath what appears to be skier's heaven.
They are currently reworking the 150-WS (~$10000) workstation which
is 68000 based. The renovations include a transition from Motorola's
bus (Versabus?) to multibus, more dense memory (boards),
incorporation of memory management (to truly be able to support
multiple processes), and development of a "native" unix. Currently,
Wicat "unix" is simply some utilities which run under MCS, the Wicat
operating system. MCS looks a little like VAX VMS and a little like
unix (very little).
The system 100 (~$20000) is in pretty good hardware shape. I believe
Wicat is working on a DMA disk controller to replace the current
bufferred controller. Software-wise, Wicat is progressing the system
100 from a few unix utilities to a lot of unix utilities to a true
native unix. Wicat hopes native unix will run before summer.
One interesting thing is that Wicat thinks OEM'ers will like to
develop applications under unix, but these applications might run
under MCS therebye avoiding unix licensing charges for end users who
don't care about unix. I'm not really sure how much this would save
giving the falling cost of unix licenses.
Now, about graphics. Wicat offers a $900 board which may be added
(post-purchase) to any Wicat VDT. The board adds medium resolution
graphics. I don't remember the exact resolution - something like
300x400. At any rate, the demo was very impressive. Wicat graphics
are for real.
I recently saw the graphics offered by Forward Systems whose 68000
workstation is patterned after the Stanford SUN workstation. The
Forward graphics (1000x1000 and full of real time) were lovely. The
Wicat graphics weren't nearly that fine, but for $900 they were very
satisfying.
Jeffrey Stone
Menlo Park, Ca.
-------
∂28-Feb-82 1144 AVB Re: Wicat Graphics
∂25-Feb-82 0041 Bill Nowicki <CSD.NOWICKI@SU-SCORE> Re: Wicat Graphics
Date: 24 Feb 1982 2313-PST
From: Bill Nowicki <CSD.NOWICKI@SU-SCORE>
Subject: Re: Wicat Graphics
To: Jeffrey at OFFICE-2
cc: works at MIT-AI
In-Reply-To: Your message of 24-Feb-82 2042-PST
Via: Mit-Ai; 25 Feb 82 3:07-EDT
Via: Brl-Bmd; 25 Feb 82 3:12-EDT
A slight correction from that last note about Wicat vs. the SUN
workstation: The Forward Technology graphics and CPU boards
are not only patterned after the SUN boards, they ARE the SUN boards.
The boards are being licensed on a non-exclusive basis in order
to promote them as de facto standards (as Multibus and Ethernet)
and share software development effort.
I think the SUN graphics are impressive as well, but I'm biased.
-- Bill
-------
∂28-Feb-82 1145 AVB Window Management
∂25-Feb-82 0052 decvax!watmath!watarts!plrowley at Berkeley Window Management
Date: 25 Feb 1982 00:16:45-PST
From: decvax!watmath!watarts!plrowley at Berkeley
To: watmath!decvax!ucbvax!works at mit-mc
Subject: Window Management
Via: Mit-Ai; 25 Feb 82 3:18-EDT
Via: Brl-Bmd; 25 Feb 82 3:23-EDT
I am looking for information on window management strategies and peoples'
experience with them (likes, dislikes, etc.). I'd appreciate any pointers
to reports on the subject, esp. those about designs based on the results
of psychological experimentation.
Specifically, I've read that the Star designers spent some tens of man-
years designing their user interface and laboratory-tested their theories.
Have the results of this experimentation been reported in print?
Finally, what do people think of overlapping windows? As I've not used
a window-oriented system, I hesitate to venture an opinion, but experience
with cluttered desks suggests to me that I wouldn't like overlapping windows.
Of course, if the windows aren't all on the screen, partially hidden or not,
they have to be catalogued in some manner. Does anyone know of any such
cataloguing system?
peter rowley, univ. of waterloo
∂28-Feb-82 1149 AVB Re: Wicat Graphics
∂25-Feb-82 1046 BISBEY at USC-ISIB Re: Wicat Graphics
Date: 25 Feb 1982 0927-PST
From: BISBEY at USC-ISIB
Subject: Re: Wicat Graphics
To: Works at MIT-AI
cc: Bisbey at USC-ISIB
Via: Mit-Ai; 25 Feb 82 12:50-EDT
Via: Brl-Bmd; 25 Feb 82 13:04-EDT
I too have visited Wicat's Utah offices. The graphics option for the
150-WS is 400x300. Also, the 150-WS is already multibus. We found
the unit to be EXTREMELY SLOW. Wicat admitted that there were two
wait states per memory access which (they said) slowed the 68000 to
63% of 8 MHZ (that's an effective speed of only 5 MHZ). Rumor has it
that someone put a scope on the WICAT and found the 68000 to be
running at an effective speed of only 3 MHZ. WICAT was working on
a memory board that used 64K chips and a small page table for the
first 2 meg. of address space.
-------
∂28-Feb-82 2322 AVB
∂27-Feb-82 1143 cbosg!dale at Berkeley
Date: 26 Feb 1982 12:34:26-PST
From: cbosg!dale at Berkeley
Via: Mit-Ai; 27 Feb 82 5:26-EDT
Via: Brl-Bmd; 27 Feb 82 5:32-EDT
There are two companies that you can buy the SUN terminal CPU board from.
Forward Technology Inc. Pacific Microcomputer, Inc.
2595 Martin Ave. P. O. Box A81383
Santa Clara, Ca. 95050 San Diego, Ca. 92138
(408)988-2378 (714)565-2727
∂28-Feb-82 2322 AVB Victor Workstation
∂27-Feb-82 1144 Tom Wadlow <TAW@S1-A> Victor Workstation
Date: 26 Feb 1982 1240-PST
From: Tom Wadlow <TAW@S1-A>
Subject: Victor Workstation
To: works at MIT-AI
Via: Mit-Ai; 27 Feb 82 5:26-EDT
Via: Brl-Bmd; 27 Feb 82 5:34-EDT
Last night, on a local PBS show called 'The Computer Chronicles' I
saw a new personal workstation called the Victor. The Victor claims
to have the following features:
- Bit-mapped display (800 x 400 x ?). Some comments were
made about gray levels, but nobody ever said anything
explicit. The display has software-selectable fonts,
with proportional spacing possible as well.
- 8088 processor. Basic system comes with 128KBytes of
memory. Expandable to 512K. 5MHz clock.
- 2 5 1/4 inch floppy drives. Available with single sided
(600KB per drive) or double sided (1.2MB per drive) drives.
A Winchester is supposedly in the works.
- Software encoded detachable keyboard.
- 2 RS-232 ports. IEE-488 bus support.
Does anybody know anything more about this machine?? The show told
a lot about the hardware but never once mentioned the cost. The
folks from Sirius Systems (the makers of Victor) claim that they are
looking toward local networks and office automation type products.
The machine sounds interesting, and the Sirius people also claimed that
they would be getting full page displays, and color soon.
∂28-Feb-82 2322 AVB where's the innovation
∂27-Feb-82 1145 Jan Walker <JWalker@BBNA> where's the innovation
Date: 27 Feb 1982 1005-EST
Sender: JWALKER at BBNA
Subject: where's the innovation
From: Jan Walker <JWalker@BBNA>
To: WorkS at AI
Message-ID: <[BBNA]27-Feb-82 10:05:47.JWALKER>
Via: Mit-Ai; 27 Feb 82 10:15-EDT
Via: Brl-Bmd; 27 Feb 82 10:23-EDT
Hohum. Yet another company making a microcomputer-based
"workstation". All this sound-alike hardware. Is it really a
case of a lot of "me too, me too" hardware work going on?
What's going on in the way of innovative software? All you ever
hear about there is "office automation". Boring. Office
automation is a market of the present, not the future. Where's
the thinking that ought to be going into "home environment
support systems" and stuff like that?
Maybe the smart people are just doing it without talking about it.
∂28-Feb-82 2322 AVB
∂27-Feb-82 1146 ihnss!ihuxl!marks at Berkeley
Date: 27 Feb 1982 09:37:44-PST
From: ihnss!ihuxl!marks at Berkeley
Via: Mit-Ai; 27 Feb 82 12:37-EDT
Via: Brl-Bmd; 27 Feb 82 12:43-EDT
Forward Technology
2595 Martin Ave.
Santa Clara, CA 95050
Mark Beckner
ihuxl!marks
∂28-Feb-82 2323 AVB victor 9000
∂27-Feb-82 1159 David.Anderson at CMU-10A victor 9000
Date: 27 February 1982 1232-EST (Saturday)
From: David.Anderson at CMU-10A
To: works at MIT-AI
Subject: victor 9000
CC: taw at s1-a, info-cpm at MIT-AI
Message-Id: <27Feb82 123232 DA80@CMU-10A>
Via: Mit-Ai; 27 Feb 82 12:40-EDT
Via: Brl-Bmd; 27 Feb 82 12:52-EDT
I have some information on the Victor 9000, mentioned recently by Tom Wadlow.
This comparison of the IBM PC and the Victor 9000 comes from the Silcon
Gulch Gazette. The IBM info comes from IBM's Billion Dollar Baby, by Isaacson
and Juliussen, available for $450 from Future Computing in Richardson,
Texas. The Sirius/Victor data came from Victor, available in Chicago at
(312) 539-8200.
THE VICTOR 9000
The Sirius Machine is well worth looking at. One of the sages of the
computer industry said to us, "Chuck [Chuck Peddle, creator of the 6502
and the Pet] has done all the things IBM should have done." We think IBM did
lots of things right, but let's compare:
Like the IBM machine, it uses a 16-bit, 8088 as its CPU. Like IBM,
Sirius has a detachable keyboard. In fact, it has five keyboard options
(typewriter, word processor, programmer, etc.)
IBM offers a video monitor as an option (a necessity for most useful
information processing). The 9000 comes with a green phospher screen that
is tiltable and turnable - not just a monitor with a handle on the top.
The 9000 has a graphics mode with an 800 x 400 resolution! IBM offers,
at best, 640 x 200.
132-CHARS x 50-LINES OF TEXT!
If you get tired of skinny paragraphs and lines running off the tradi-
tional 80-character x 25-line display, you can switch to the Victor's
132-character x 50-line display, complete with fully legible upper and lower
case characters, with descenders. (That, alone, is enough to sell it to us
word-junkies.)
IBM's character display matrix is 9x14. Sirius' is 10x16 or 16x16. The
character set is loaded into user-accessible RAM, so, if ya don't like what
you see, ya can change it to suit your palate.
Unlike IBM, the Sirius unit does not currently support color (a decision
that was debated long and hard), but the system has all the hooks to add
color later. Our impression is that they felt that (a) their marketplace
is the business market, to which color is less useful than for home and
educational computing, (b) it's very difficult to do really useful things,
in an information sense, with color, and (c) hi-res color monitors capable
of supporting those great graphics and 132x50 text displays cost lots!
1.2 MEGABYTE FLOPPY DISK DUET
The 9000 comes with dual 5 1/4 " single-sided floppies, like the IBM.
Unlike the IBM, which can store 163K [per drive], the Victor system packs
1.2 megabytes into those two on-line minifloppies.
CP/M-86 & MSDOS
Like the IBM pc, the Victor system offers both CP/M-86 (available right
now - IBM's is expected soon), and Microsoft's also-IBM DOS. Unlike IBM,
both MSODS and CP/M-86 come with the system - CP/M is an option with IBM.
And there is the usual package of support software, e.g. a VisiCalc
clone (VisiClone?) called VictorCalc from Image Systems, a Select editor, etc.
THE FUTURE IS VERY SOON
Oh, yes, Victor will almost certainly be offering a Winchester and an
SMD interface before the end of '82, and very probably a medium-speed
networking facility (say, 1 to 2 megabit bandwidth). We suggest that Vic-
torites also watch for a C compiler and a UNIX operating system licensed
from Bell Labs as yet another 1982 option (installed and supported by one
of the best unixizers in the business).
ORANGES AND APPLES - HOW MUCH?
The Victor/Sirius system with dual floppies (1.2M), screen (80x25,
132x50 and 800x400), 128K of memory (that's minimum), MSDOS and CP/M-86
lists for $4995, a price that might be haggled once the supply pipe
begins to fill.
In this apples-with-oranges comparison, an IBM system with dual
floppies (326K), screen (80x25 and 640x200), 48K of memory and MSDOS
is $3525, available from list-price-only dealers.
from: Silcon Gulch Gazette, January 1982, page 2, by Jim C. Warren, Jr.
∂28-Feb-82 2323 AVB IBM PC Review
∂27-Feb-82 1524 Ozzie.SoftArts at MIT-Multics IBM PC Review
Date: 26 February 1982 18:23 est
From: Ozzie.SoftArts at MIT-Multics
Subject: IBM PC Review
Sender: COMSAT.SoftArts at MIT-Multics
To: works at MIT-MC
*from: OZZIE via SAI via MIT-Multics (Ray Ozzie)
Original to: WORKS at MIT-MC
Via: Mit-Mc; 27 Feb 82 17:27-EDT
Via: Brl-Bmd; 27 Feb 82 17:32-EDT
I have spent quite a bit of time using the IBM PC, and use it
full time as a terminal on my host machine (with the PC running
a vt100 (subset) emulator at 19200 baud). I have a vt100
to the right of my IBM PC; it is typically used only when
I happen to need 132 mode.
I find the keyboard to be one of the best that I have ever typed
on, with the possible exception of one or two PLATO keyboards.
The positive mechanical feedback is a dream. Yes, it took me
several weeks to get used to the single-width shift keys (and
thus the placement of the back-slash key), but now I can type
circles around a vt100.
I bind the keys on the various keypads to various EMACS
functions, and use the right pad extensively (arrows and page
keys). The left pad, in my opinion, suffers greatly because it
was not designed with enough room to put a "template" around it.
The IBM monochrome monitor suffers from a terrible lack of
contrast. We have reduced this problem by putting a $200
Polaroid CP-70 Contrast Enhancement Filter over the display.
I have not yet been exposed to the color monitor.
I am not impressed with the processor speed. The programs that
we have converted from z80 to the 8088 do not run much faster,
primarily because of the 8-bit data path. The instruction set
is obviously better than the 8-bit machines. As Seth noted,
however, dealing with 64k segments is a tremendous pain. This
is, of course, not IBM's fault, though the 8-bit bus IS.
A MAJOR problem with the IBM is the lack of board slots
available. This limits the amount of memory to 512k, or
typically 256k. You must trade off peripherals for memory.
The IBM sorely needs a hard disk.
The IBM hardware beats the hell out of the previous generation
8-bit systems. All peripherals interrupt through a very handy
8259a programmable interrupt controller. There are three hardware
clocks: one to refresh memory, one used for DOS timer services
(and to time out the disk), and the last to provide a tone
generator to play music. The machine provides a socket for the
8087 floating point processor. The color graphics card uses
the (fairly flexible) 6845 CRT controller. The disk controller
is a NEC uPD765. All in all, it is a very high quality piece
of hardware, and very nice to work with.
The ASYNC interface is satisfactory. The supplied driver in ROM
is a polling driver, and is not much good for many applications.
NOTE: If you attempt to write your own interrupt-enabled driver,
you may get very frustrated. If you ever want an interrupt from
the 8250, you must set bit 3 (OUT 2) of the Modem Control Register.
This is documented as a "user-designated output", where the user
is IBM, and the designation is to inhibit interrupts(!). The only
place that you can find this out is by looking at the schematic on
page D-48 of the Technical Reference Manual.
IBM DOS is satisfactory. Disk error recovery is pretty good, but
other error recovery is marginal. For example, "break"ing during
program image activation will frequently cause DOS to crash. The
function calls have all seemed to work "as documented". The
"end but stay resident" function call is very handy for those of
us who wish to write device drivers that stay around. It also
enables one to write a very nice "histogramming" program that
stays resident during user program execution.
Last but not least, I must CHEER for IBM with regards to the $36
"Technical Reference Manual". It has EVERYTHING you ever wanted
to know about the machine: schematics, chip write-ups, chip and
connector pin-outs, configuration info, LISTINGS OF THE ROM,
etc. IBM should be complimented for making all of this info
available in an inexpensive, well-put-together manual.
Ray Ozzie (Ozzie.SoftArts)
∂01-Mar-82 1223 AVB IBM PC Review
∂25-Feb-82 1541 SSteinberg.SoftArts at MIT-Multics IBM PC Review
Date: 25 February 1982 03:20 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: IBM PC Review
Sender: COMSAT.SoftArts at MIT-Multics
To: works at MIT-MC
*from: SAS (Seth A. Steinberg)
Local: works at mit-mc
Via: Mit-Mc; 25 Feb 82 17:58-EDT
Via: Brl-Bmd; 25 Feb 82 18:03-EDT
My first view of this computer was of a bunch of cards nailed
to a wooden board with a transparent keyboard and a monitor
from Apple.
The IBM has several great features:
- 8086 CPU which means it can address almost as many dollars
worth of memory as the basic system costs (256KB = $2-4K).
Most companies go by the credo: "Millions for software
research, pennies for more memory." (and choose the former).
- it is nicely package with room for disk drives, RS232,
graphics board and other goodies in the main box. This means
you can grow your system pretty nicely.
- it runs CP/M which means it has a fair bit of software. The
IBM name means that some good and TONS of mediocre and lousy
software will be available soon.
The nits include:
- the 8086 has a 16 bit address. You can combine a segment
number with an offset but if you just want to store a 20 (or
18) bit address you have to do a LOT of work. This is a win if
you plan to write a LISP or SMALLTALK where this kind of thing
can be isolated but a pain if you just want a big buffer.
- the keyboard is horrendous. Unless you can span an octave
without stretching your hand (at all) you will have to take
your fingers off the home keys to hit NewLine. The shift keys
are small keys located in weird places. No one here has really
gotten used to them. Hitting PrtSc will hang your CPU if you
don't have a printer.
- It does NOT have a reboot key. It has a keyboard sequence
which will often reboot the machine but not always and rarely
when you are debugging. You have to turn off the machine,
count SLOWLY to then, then turn it back on. You can leave the
disks in.
- It does NOT have any good memory management software. CP/M
does not scale well. UNIX does not scale well, though it
scales better than CP/M.
Would I recommend it? YES, I would. It is much better than
the APPLE II, holds more memory than a TRS-80 (Model III),
compares favorably with most CP/M machines and so on. It
expands well, seems to be pretty reliable and is not much worse
than anything else I can name.
∂01-Mar-82 1223 AVB IBM PC Review
∂25-Feb-82 1653 SSteinberg.SoftArts at MIT-Multics IBM PC Review
Mail-from: ARPANET site BRL rcvd at 25-Feb-82 1557-PST
Date: 25 February 1982 03:20 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: IBM PC Review
Sender: COMSAT.SoftArts at MIT-Multics
To: works at MIT-MC
*from: SAS (Seth A. Steinberg)
Local: works at mit-mc
Via: Mit-Mc; 25 Feb 82 17:58-EDT
Via: Brl-Bmd; 25 Feb 82 18:03-EDT
Via: Usc-Eclc; 25 Feb 82 19:02-EDT
Via: Brl-Bmd; 25 Feb 82 19:13-EDT
My first view of this computer was of a bunch of cards nailed
to a wooden board with a transparent keyboard and a monitor
from Apple.
The IBM has several great features:
- 8086 CPU which means it can address almost as many dollars
worth of memory as the basic system costs (256KB = $2-4K).
Most companies go by the credo: "Millions for software
research, pennies for more memory." (and choose the former).
- it is nicely package with room for disk drives, RS232,
graphics board and other goodies in the main box. This means
you can grow your system pretty nicely.
- it runs CP/M which means it has a fair bit of software. The
IBM name means that some good and TONS of mediocre and lousy
software will be available soon.
The nits include:
- the 8086 has a 16 bit address. You can combine a segment
number with an offset but if you just want to store a 20 (or
18) bit address you have to do a LOT of work. This is a win if
you plan to write a LISP or SMALLTALK where this kind of thing
can be isolated but a pain if you just want a big buffer.
- the keyboard is horrendous. Unless you can span an octave
without stretching your hand (at all) you will have to take
your fingers off the home keys to hit NewLine. The shift keys
are small keys located in weird places. No one here has really
gotten used to them. Hitting PrtSc will hang your CPU if you
don't have a printer.
- It does NOT have a reboot key. It has a keyboard sequence
which will often reboot the machine but not always and rarely
when you are debugging. You have to turn off the machine,
count SLOWLY to then, then turn it back on. You can leave the
disks in.
- It does NOT have any good memory management software. CP/M
does not scale well. UNIX does not scale well, though it
scales better than CP/M.
Would I recommend it? YES, I would. It is much better than
the APPLE II, holds more memory than a TRS-80 (Model III),
compares favorably with most CP/M machines and so on. It
expands well, seems to be pretty reliable and is not much worse
than anything else I can name.
∂01-Mar-82 1225 AVB Re: Window Management
∂25-Feb-82 2208 George.Coulouris at CMU-10A Re: Window Management
Date: 25 February 1982 1732-EST (Thursday)
From: George.Coulouris at CMU-10A
To: works at mit-ai
Subject: Re: Window Management
In-Reply-To: decvax!watmath!watarts!plrowley@Berkeley's message of 25 Feb 82
03:16-EST
Message-Id: <25Feb82 173209 GC12@CMU-10A>
Via: Mit-Ai; 26 Feb 82 0:31-EDT
Via: Brl-Bmd; 26 Feb 82 0:42-EDT
Based on our experience with our 'animated desktop' colour windowed display
here at Queen Mary College London, I have the following comments:
1) The interface seems most natural when windows glide smoothly onto
the 'desk-top' instead of appearing suddenly in the middle of it.
Similar comments apply to moving windows to other parts of the screen
and removing them from the screen.
2) If you do that, the windows have to overlap, at least while they are
moving, otherwise they would have to find a path that was free of other windows.
3) Colour helps a great deal in discriminating overlapping windows.
Having tried it, we wouldn't want to give it up.
4) Despite the above, the screen can get cluttered. It can also
be quickly uncluttered by the use of an application-level command to
remove some of the windows (in our model, the command is to 'put them
back in the filing cabinet'). If you want to, you can construct
your application software so that the screen isn't allowed to get cluttered,
but I wouldn't use the clutter argument as a reason to ban overlapping
windows at the system level.
George Coulouris
∂01-Mar-82 1226 AVB WorkS Now both DIGEST and Direct distribution
∂26-Feb-82 0006 Jonathan Alan Solomon <JSol@USC-ECLC> WorkS Now both DIGEST and Direct distribution
Date: 25 Feb 1982 2321-PST
From: Jonathan Alan Solomon <JSol@USC-ECLC>
Subject: WorkS Now both DIGEST and Direct distribution
To: WorkS at BRL
Via: Usc-Eclc; 26 Feb 82 2:25-EDT
Via: Brl-Bmd; 26 Feb 82 2:33-EDT
Due to overwhelming demand, I am now supporting two versions of how
WORKS is being distributed, both the digest and the direct mail
approach. I expect that the direct approach will be most useful for
those who want to contribute to the list, while digests will be more
useful to those users who are only interested in reading what goes on.
The digest will tend to lag behind the discussion, there is some
middle ground (if there is about 6000 characters of mail to go out
each day then there will be a daily digest), but most of the time
digests may either be sparse (due to lack of discussion), or very
large and frequent (lagging behind the overwhelming discussion).
Either way, there are now two ways you can be on the list.
If you are receiving this message in the form of a message addressed
to you, then you are on the direct mail list. If you receive this as
an "Administrivia" to the normal digest, then are on the digest list.
In any event, you can be switched back and forth at will by sending
mail to WorkS-REQUEST@MIT-AI.
Oh, yes. My apologies to all who received more than one copy of one of
the messages sent to WorkS. I had inadvertently created a loop in the
list in the process of splitting the list in two. This has been fixed
now.
Enjoy,
--JSol
-------
∂01-Mar-82 1226 AVB
∂26-Feb-82 0855 Andy Bechtolsheim <AVB@SU-AI>
Date: 25 Feb 1982 2237-PST
From: Andy Bechtolsheim <AVB@SU-AI>
To: ri at MIT-XX, david.anderson at CMU-10A, works at MIT-AI
Via: Mit-Ai; 26 Feb 82 11:05-EDT
Via: Brl-Bmd; 26 Feb 82 11:14-EDT
A while back, I discussed with Howard Gordon from Peninsula Research
the possibility of using the SUN graphics system in the WICAT system.
As it turned out, the WICAT display did not have sufficient resolution
to be compatible with the SUN graphics board.
In the meanwhile, WICAT started working on a lower-resolution bit-map
display option of their own design for their current system.
A new company, SUN Workstation Inc, has just received venture financing
with the mission to exclusively manufacture SUN workstations for
the workstation marketplace. For further information, please contact:
SUN Workstation Inc.
PO BOX 3005
Stanford, CA 94305
(415) 494-8922
∂01-Mar-82 1228 AVB IBM PC comments
∂26-Feb-82 1344 ROSSID at WHARTON-10 (David Rossien) IBM PC comments
Date: 26 Feb 1982 (Friday) 1509-EDT
From: ROSSID at WHARTON-10 (David Rossien)
Subject: IBM PC comments
To: works at MIT-AI
Via: Mit-Ai; 26 Feb 82 15:12-EDT
Via: Brl-Bmd; 26 Feb 82 15:35-EDT
To make a couple of corrections ->
1) In point of fact, the chip is an 8088, 16 bit registers and
8 bit data paths. Some benchmarks has suggested this is the
worst of both worlds -> it doesn't necessarily perform loads
better than a Z-80. It may some day be possible to attatch
(officially that is) an 8087 FP processor to it (the slot seems
to be there) and speed things up some more.
2) It does not have CP/M at this time... it runs IBM DOS. Digital
Research is working on CP/M for the PC, and IBM will be the distri-
butor when that occurs. For the time being, there is VERY LITTLE
software available for DOS. There are lots of people whuggest
that most PC users will run DOS, not CP/M, under the theory that
there is this certain mentality of an IBM buyer, and that DOS will
probably be the vanilla OS version, and costs about $40, not $140.
3) A friend of mine who is admittedly somewhat biased says the
Apple III has the PC beat. I can discuss his opinions at length,
but I would appreciate some other opinions too.
4) So far, the famed IBM support of bugs has consisted of a
"thank you for sharing that problem with us...and then they
send the bug report off to the company that made the software
(Lifeboat, Peachtree, VisiCorp, MicroSoft, etc. [admittedly not
lightweights!])."
6) There really is not much room to grow! You only get 5 slots in
the back, and the following take up space:
a. Memory after the first 64K takes up 1 slot per additional 64K
b. Dist drive adapter
c. Asynchronous Communications Adapter
d. Monocrome Display and printer Adapter
e. Color/Graphics Monitor Adapter
f. Printer Adapter
g. Game Control Adapter
So, say we are running IBM Pascal (req 128K or 1 slot), with a
color graphics game using paddles (1 for color monitor, 1 for paddles)
with printer and disk drive (1 each) we have now take up all the slots.
If we want to also use the system as a terminal we have to remove
something. What all this means (and IBM admits the problem, my info
comes from some IBM internal use only documents) is that 5 slots
is enough for any given application, but you may have to open the
back many times if you switch applications.
-Dave
∂04-Mar-82 2156 AVB Re: where's the innovation
∂03-Mar-82 1210 gary.RAND-UNIX Re: where's the innovation
Date: Tuesday, 2 Mar 1982 13:45-PST
To: Jan Walker <JWalker.BBNA>
Cc: WorkS.MIT-AI
Subject: Re: where's the innovation
In-reply-to: Your message of 27 Feb 1982 1005-EST.
<[BBNA]27-Feb-82 10:05:47.JWALKER>
From: gary.RAND-UNIX
Message-ID: <42.383953526@RAND-UNIX>
Via: Mit-Ai; 3 Mar 82 12:34-EDT
Via: Brl-Bmd; 3 Mar 82 12:47-EDT
It's not clear to me that the boring and often petty character of
so much "office automation" work is going to be relieved by a
turn to things like "home env. support sys." (for which one
pessimistically imagines a veritable tsunami of "recipe support
systems" and "checkbook data-base technology" and "machine-readable
gardening advice" etc.). That is, just plugging the same old tools
into some new application areas will not necessarily stir the
adrenalin in those of us who are growing jaded and gray. Things
might pick up a bit when the computing field more widely raises
its sights above the easy clerical and administrative chores, and
goes after some higher functions of (life, corporate, military,
home, and ...) management -- like planning, situation analysis,
etc.
But the easy chores are really there, and they do need help, and
we can hardly blame enterprising folks for chasing after them.
And, easy as they may be in principle, there still remains lots of
room for improvement in their actual coverage!
Finally, though I have come to take a good (UNIX) file system,
screen editor (E, EMACS), message system (MH, MM) pretty much
for granted, they really do add something substantial to the
quality of my life. If I ungratefully think of them (and their
sibling capabilities) as "boring", it's probably only because
they do what they do quite well and unobtrusively. Sigh!
Gary
∂04-Mar-82 2157 AVB Re: IBM PC Bus Extensionts)
∂03-Mar-82 1212 rubin.Sri-Nsc11 Re: IBM PC Bus Extensionts)
Date: 2 Mar 82 13:30-PDT
From: rubin.Sri-Nsc11
To: WLIM.MIT-XX
CC: works.mit-ai
Subject: Re: IBM PC Bus Extensionts)
Via: Mit-Ai; 3 Mar 82 12:34-EDT
Via: Brl-Bmd; 3 Mar 82 12:57-EDT
TECMAR makes a bus expansion box for the IBM PC; I've seen it advertised in
"Byte" the last few months. Cosmetically, the box looks just like the IBM
system unit, but taller (for bigger cards I guess). If I recall correctly,
it has about 7 slots, room for a winchester, and goes for around $800 or $1000.
It has its own power supply.
By the way, Tecmar has announced more than a dozen other accessories for the
IBM PC. I don't know if they are really being manufactured yet, or are just
being implemented in viewgraphs.
--Darryl
∂04-Mar-82 2158 AVB
∂03-Mar-82 1217 ''John Howard Palevich, & CO.'' <TANG.MIT-AI>
Date: 2 March 1982 18:40-EST
From: "John Howard Palevich, & CO." <TANG.MIT-AI>
To: WORKS.MIT-AI
Via: Mit-Ai; 3 Mar 82 12:37-EDT
Via: Brl-Bmd; 3 Mar 82 13:04-EDT
I think that the IBM PC Bus is position independant
(unlike the Apple II, OSI, or Atari buses, but like the
S-100) so that all Techmar does is buffer the bus & add a
power supply. Given that the IBM cards have connecters on
their rear edges, I bet that the expansion box's back looks
just like the IBM PC to the installed cards.
Jack Palevich
∂04-Mar-82 2159 AVB IBM PC Bus Extension
∂03-Mar-82 1218 Ittai Hershman <ITTAI.MIT-MC> IBM PC Bus Extension
Date: 2 March 1982 21:17-EST
From: Ittai Hershman <ITTAI.MIT-MC>
Subject: IBM PC Bus Extension
To: WLIM.MIT-MC
cc: works.MIT-AI
Via: Mit-Ai; 3 Mar 82 12:37-EDT
Via: Brl-Bmd; 3 Mar 82 13:08-EDT
Date: Tuesday, 2 March 1982 11:29-EST
From: Willie Lim <WLIM>
To: works at MIT-AI
Re: IBM PC Bus Extension
It seems that a BUS extension unit (non-IBM product) is available for the
IBM PC. Perhaps this will alleviate the 5-slot problems. Does anyone know
of the details of the bus extension unit?
See TecMar Inc.'s ad on page 83 of the new (ie. March 1982) issue of
BYTE magazine. The TecMate(Tm) is a seven slot expansion cabinet with
full bus support, matched IBM PC styling, heavy duty power supplies,
convenience outlets to power printers or monitors, and built in
provision for a 5 inch Winchester hard disc drive. The preceding
sentence was a quote from TecMar's literature packet. The November 1981
price list quotes a price of $795.- for the expansion cabinet. A whole
slew of other items in the TecMate(tm) series exists.
TecMar Inc.
Personal Computer Products Division
23600 Mercantile Road
Cleveland, Ohio 44122
216-464-7410
∂04-Mar-82 2200 AVB Innovation...
∂03-Mar-82 1354 William ''Chops'' Westfield <BillW@SRI-KL> Innovation...
Date: 3 Mar 1982 1157-PST
Sender: BILLW at SRI-KL
Subject: Innovation...
From: William "Chops" Westfield <BillW@SRI-KL>
To: WorkS at BRL
Message-ID: <[SRI-KL] 3-Mar-82 11:57:45.BILLW>
Via: Sri-Kl; 3 Mar 82 16:24-EDT
The point is that to most of the world, putting a PDP-8 in their
office is more innovation than they think they are ready for...
You and I and the rest of the NET may need a Cray 3 with a 6 foot
diagnal color picture and a rat (a big mouse..) before we are
impressed, but much of the world is terrified if characters that
they haven't typed appear on a display. Improving the human
engineering with mice and bit-maps and stuff may make it easier
for some people, but is scares other people even more... So.. .
Let's ge tthe current technology out into the world. Then we can
worry about inovative technology...
Bill W
∂04-Mar-82 2209 AVB 68000 wait states
∂03-Mar-82 2040 pratt.Shasta.Sumex-Aim 68000 wait states
Mail-from: SU-NET host SU-SHASTA rcvd at 3-Mar-82 2000-PST
Date: 3 Mar 1982 19:58:45-PST
From: pratt.Shasta.Sumex-Aim
To: works.ai
Subject: 68000 wait states
Via: Mit-Ai; 3 Mar 82 23:13-EDT
Via: Brl-Bmd; 3 Mar 82 23:23-EDT
The Sun has a two-level (segment & page) memory map, and NO wait
states. Memory consists of jelly-bean 4164's.
Vaughan Pratt
∂04-Mar-82 0040 William ''Chops'' Westfield <BillW@SRI-KL> 68000 memories...
Date: 4 Mar 1982 0001-PST
Sender: BILLW at SRI-KL
Subject: 68000 memories...
From: William "Chops" Westfield <BillW@SRI-KL>
To: works at BRL
Message-ID: <[SRI-KL] 4-Mar-82 00:01:20.BILLW>
Via: Sri-Kl; 4 Mar 82 3:07-EDT
Motarola has an "Engineering Bulletin" titled something like
"The interrelationship between clock speed and memory access times".
According to it, you can get by with no wait states using 150-200 nS
(I forget which, and the paper is in my office) and Schotkey bus
drivers. The Sun processor board manages to get by running with
no wait states by doing neat memory hacks with the on board RAM
(256K worth) The memory is expandable to .5 Meg via the P2 connector
and I assume that that will also run with no wait states...
However, if you want to expand memory beyond that by adding ordinary
multibus memory boards, wait states ARE required.
On an interesting note, the 68020 (32 bit A/D buses), which was anounced
tuesday, will include on board cache memory. Motarola said that eventually
top-of-the-line 680xx series components will run at 16 MHz.
BillW
The SUN 68000 Board runs at 10 Mhz without wait states, even though
all addresses are translated by a two-level, segment-page virtual
memory management. No caches are used. Memory consists of 150 nsec 64k RAMs.
∂04-Mar-82 2345 AVB 68000 system performance
∂03-Mar-82 1646 NZeck.WBST.PARC-MAXC 68000 system performance
Date: 3 Mar 1982 13:48 EST
From: NZeck.WBST.PARC-MAXC
Subject: 68000 system performance
To: BISBEY.USC-ISIB
cc: Works.MIT-AI, NZeck.WBST at PARC-MAXC
Via: Mit-Ai; 3 Mar 82 13:52-EDT
Via: Brl-Bmd; 3 Mar 82 14:07-EDT
---------------------------
Mail-from: Arpanet host BRL rcvd at 25-FEB-82 1040-PST
Date: 25 Feb 1982 0927-PST
From: BISBEY at USC-ISIB
Subject: Re: Wicat Graphics
To: Works at MIT-AI
cc: Bisbey at USC-ISIB
Via: Mit-Ai; 25 Feb 82 12:50-EDT
Via: Brl-Bmd; 25 Feb 82 13:04-EDT
I too have visited Wicat's Utah offices. The graphics option for the
150-WS is 400x300. Also, the 150-WS is already multibus. We found
the unit to be EXTREMELY SLOW. Wicat admitted that there were two
wait states per memory access which (they said) slowed the 68000 to
63% of 8 MHZ (that's an effective speed of only 5 MHZ). Rumor has it
that someone put a scope on the WICAT and found the 68000 to be
running at an effective speed of only 3 MHZ. WICAT was working on
a memory board that used 64K chips and a small page table for the
first 2 meg. of address space.
-------
While I have no bias toward a particular system, I am interested in if anyone has
any info on the performance of other 68000 systems (Fortune Systems, Forward
Systems etc...)
Is it Wicat's software (I assume it was their opsys that was running not a
version of unix) that is slow or is it really the hardware?
It looks like from the 68k specs that for no wait state memory access, the
memory access time has to be around one to one an a half clock cycles (125-185
ns) including driving any busses, decoding etc. While this is doable, it puts a
$premium on memory. Also if the design includes a memory management unit
of some flavor (which would be desirable for os/user protection/dynamic
binding), this will add to the required memory performance.
Also note that while the processor is slowed down for a memory access, it
still implements the execution phase of the instruction at 8 Mhz.
------------------------------------------------------------
∂06-Mar-82 1203 AVB Innovation
∂05-Mar-82 2309 BUSH.USC-ISIE Innovation
Date: 5 Mar 1982 2207-PST
From: BUSH.USC-ISIE
Subject: Innovation
To: WorkS.MIT-AI
Via: Mit-Ai; 6 Mar 82 1:18-EDT
Via: Brl-Bmd; 6 Mar 82 1:21-EDT
Hohum indeed. There's no real technical innovation in putting a 16-bit micro
in a box with a tube and maybe a network interface. It's interesting from a
marketing/business standpoint to see how IBM manages as an Intel OEM, but
that's not where the technical challenges are. All this personal hardware is
not too useful, certainly not very advanced, without sophisticated software.
I want a personal computer system, not just an expensive terminal.
Apollo is a case of the hardware without the software. They've always had
a bit-mapped display with overlapping windows, but until recently all their
windows were full-screen width with no identifying information, so it was
difficult to parse the screen and figure out which windows were partially
obscured. Now they have Alto-like windows of varying widths with a thick bar
at the top with information about the window (for example, which file is being
edited in it), so now there's a real reason for the display. Innovative
products, like the Star, will be defined by their software.
-------
∂06-Mar-82 1203 AVB re: 68000 wait states
∂05-Mar-82 2339 Andy Bechtolsheim <AVB@SU-AI> re: 68000 wait states
Date: 04 Mar 1982 2209-PST
From: Andy Bechtolsheim <AVB@SU-AI>
Subject: re: 68000 wait states
To: works at BRL
Via: Su-Ai; 6 Mar 82 2:06-EDT
The SUN 68000 Board runs at 10 Mhz without wait states, even though
all addresses are translated by a two-level, segment-page virtual
memory management. No caches are used. Memory consists of 150 nsec 64k RAMs.
∂06-Mar-82 1703 AVB Re: Innovation
∂06-Mar-82 1630 Nathaniel Mishkin <Mishkin.YALE> Re: Innovation
Date: 6-Mar-82 1600-EST
From: Nathaniel Mishkin <Mishkin.YALE>
Subject: Re: Innovation
To: Works.MIT-AI
Cc: Odonnell.YALE, Rees.YALE, Adams.YALE
In-Reply-To: Your message of 5 Mar 1982 2207-PST
Via: Mit-Ai; 6 Mar 82 18:50-EDT
Via: Brl-Bmd; 6 Mar 82 19:02-EDT
Date: 5 Mar 1982 2207-PST
From: BUSH.USC-ISIE
Subject: Innovation
To: WorkS.MIT-AI
Apollo is a case of the hardware without the software. They've
always had always had a bit-mapped display with overlapping windows,
but until recently all their windows were full-screen width with
no identifying information, so it was difficult to parse the screen
and figure out which windows were partially obscured. Now they
have Alto-like windows of varying widths with a thick bar at the
top with information about the window (for example, which file
is being edited in it), so now there's a real reason for the
display. Innovative products, like the Star, will be defined by
their software.
*** Apollo Flame ***
Having used the Apollo fairly extensively, I'd say this is an incorrect
statement. The hardware is pretty straightforward stuff. Where Apollo
has made its mark is in the software engineering of their system. They
have a real system and it's not Unix (thank god). They have made
intelligent decisions about what to compromise on and more importantly
what NOT to compromise on.
The window problem is a typical example of Apollo's approach. I'm
sure they wanted the whole zippy window thing from the start. The
full width windows were a temporary stage. In general, Apollo has
designed software which does not preclude future increases in
sophistication; in fact it plans for such increases.
If you want to talk hardware without software, let's talk PERQ...
-- Nat Mishkin
-------
∂08-Mar-82 2148 AVB Apollo system software
∂08-Mar-82 1635 JW-Peterson at Utah-20 (John W. Peterson) Apollo system software
Date: 8 Mar 1982 1645-MST
From: JW-Peterson at Utah-20 (John W. Peterson)
Subject: Apollo system software
To: works at Mit-Ai
cc: Lars.Ericson at Cmu-10a
Via: Mit-Ai; 8 Mar 82 19:06-EDT
Via: Brl-Bmd; 8 Mar 82 19:09-EDT
Correction to Lars.Ericson at CMU-10a:
Apollo's system software is NOT in FORTRAN. Apollo used a few of the
RATFOR Software Tools programs for text manipulation & processing, but the
*majority of the system* (i.e, the Aegis nucleus, system utilities,
superviser code, and system I/O) is in Pascal. What's more it is a clear,
modularly designed system, and is reasonably documented as well. [The
University of Utah has a source agreement with Apollo, so I know this for a
fact].
jp
-------
∂08-Mar-82 1641 Lars.Ericson at Cmu-10a Apollo/Pascal
Date: 8 March 1982 1354-EST (Monday)
From: Lars.Ericson at Cmu-10a
To: WorkS at Mit-Ai
Subject: Apollo/Pascal
Message-Id: <08Mar82 135404 LE60@CMU-10A>
Via: Mit-Ai; 8 Mar 82 19:11-EDT
Via: Brl-Bmd; 8 Mar 82 19:21-EDT
I'm sorry. The Apollo machine they had here last semester came with
Fortran guide, and a statement that they had a Pascal internally, but
were not going to support it for some time for users. Plus, compared
to the Perq windows and general screen aesthetics, the Apollo looked
like a real kludge. It was big, bulky, low resolution, expensive, didn't
have a mouse, and had truly wierd and unfathomable protocols for
creating and moving amongst windows.
∂08-Mar-82 1910 Nathaniel Mishkin <Mishkin@Yale> Re: Apollo/Clever?
Date: 8-Mar-82 1744-EST
From: Nathaniel Mishkin <Mishkin@Yale>
Subject: Re: Apollo/Clever?
To: Works at Mit-Ai
Cc: Odonnell at Yale, Rees at Yale, Adams at Yale
In-Reply-To: Your message of 8 March 1982 0026-EST (Monday)
Via: Mit-Ai; 8 Mar 82 21:28-EDT
Via: Brl-Bmd; 8 Mar 82 21:32-EDT
Mail-from: ARPANET site BRL rcvd on Mon Mar 8 17:21:04
Date: 8 March 1982 0026-EST (Monday)
From: Lars.Ericson at Cmu-10a
To: WorkS at Mit-Ai
Subject: Apollo/Clever?
Message-Id: <08Mar82 002626 LE60@CMU-10A>
Via: Mit-Ai; 8 Mar 82 2:20-EDT
Via: Brl-Bmd; 8 Mar 82 2:31-EDT
Apollo system software is programmed in FORTRAN. I guess this is an
example of clever, conservative system design allowing future upgrading --
like maybe to a recoding in PASCAL. Then, 10 years from now, maybe
we'll see an Apollo upgrade programmed in LISP....
This is a misrepresentation of the facts.
(1) Some fraction (~.50) of the user tools are in Ratfor. These
came from the so-called "Software Tools" tape.
(2) The other tools are written in Pascal. I'm no Pascal fan,
I can assure you, but they're not bad.
(3) The kernel is written in very cleanly coded Pascal.
How many other commercially produced software systems are programmed
in Pascal, let alone Lisp? A project to bring up Lisp/Scheme on the
Apollo is well underway here at Yale. We expect to start doing our
systems programming in it within the next few months (not 10 years).
-------
∂08-Mar-82 1911 Chip Maguire Re: [Lars.Ericson at Cmu-10a: Apollo/Clever?]
Date: 8 Mar 1982 1743-MST
From: Chip Maguire
Subject: Re: [Lars.Ericson at Cmu-10a: Apollo/Clever?]
Sender: MAGUIRE at Utah-20
To: Works at Mit-Ai
cc: Maguire at Utah-20
Reply-To: Maguire at Utah-20
In-Reply-To: Your message of 8-Mar-82 0739-MST
Via: Mit-Ai; 8 Mar 82 21:27-EDT
Via: Brl-Bmd; 8 Mar 82 21:30-EDT
To the best of my knowledge (having seen the sources for the previous
iteration of system software (i.e. not the latest release but the fall release))
the sources were written in:
PASCAL - most of the OS
RATFOR - many of the tools are from the SOFTWARE TOOLS collection
(this may be where you got the idea that they were written in
FORTRAN)
ASSEMBLY - a trivial fraction of the code, in fact I was trying to
produce assembly code for their assembler (as output of
the SYSLISP compiler effort here) and did not have a manual
for this assembler and found it difficult because there were
so few examples to follow.
The majority of the assembly code is concerned with
device drivers and forcing things to hardware page
boundaries and then it calls the actual program which is
usually a PASCAL routine.
So far, despite some rough edges, the system has been quite
reasonable to use, and has a working multiprocess OS that supports real
windows (unlike the fake windows on the PERQ - which do look nice, but
presently can't have a processing running in each of them). It is
unfortunate that your narrow linguistic understanding has blinded you to
the realities of existing systems. It should be noted that the PRIME
Computer systems early OS, which was largely take from and patterned after
MULTICS was implemented in FORTRAN, and supported a virtual memory system
with imbedded OS, and many of the other nice features of MULTICS with a
very large address space for the time (early 70's). I think that given the
efforts of groups at Brown Univ., Yale, Utah, Caltech, etc. You will see
working systems which support C and LISP; as components in CAD/CAM, CAI,
personal algebra machines, etc. Until such time as LISP systems are readily
available for purchase for the 68000, as current PASCAL, FORTRAN, and C
compilers are, it seems to be a perfectly reasonable "clever, conservative
system" design which sells what is available rather than trying to sell
what is not available as several other companies are presently doing!
Chip
ps To other Works readers: Sorry for the flame but I am very disappointed
by many of the companies which are selling software and hardware which does
not exist yet.
-------
∂08-Mar-82 1931 Griss at Utah-20 (Martin.Griss) Re: Apollo/Pascal
Date: 8 Mar 1982 1935-MST
From: Griss at Utah-20 (Martin.Griss)
Subject: Re: Apollo/Pascal
To: Lars.Ericson at Cmu-10a
cc: Griss at Utah-20
In-Reply-To: Your message of 8-Mar-82 1154-MST
Remailed-date: 8 Mar 1982 1938-MST
Remailed-from: Griss at UTAH-20 (Martin.Griss)
Remailed-to: works at MIT-AI
Via: Mit-Ai; 8 Mar 82 21:52-EDT
Via: Brl-Bmd; 8 Mar 82 22:00-EDT
I suppose I should add my $.02 as well. We have 2 Apollo's, they are
connected with a well designed working network, which permits files to be
accessed by name on other members of the network. Our systems have BitPAD
ONE's, and we can expand/contract and move windows quite easily. PASCAL (as
opposed to the internal SPL that they had), has been released, with a real
manual, etc for some time (i.e. at least November). They did not want to
call it PASCAL until they were happy (unlike other manufacturers).
The resolution has ALWAYs been 800*1024, with working BitBlt, multiple
fonts, etc. We have a FONT editor. It does indeed have a GREEN interlaced
display, being replaced by a non-interlaced BLACK-WHITE. Thus it has the
same resolution as the PERQ, and MUCH more software that actually works!
[We also have a PERQ, so we have experience on BOTH machines].
It seems a bit more expensive than the PERQ, but does have Virtual Memory
(~9MB process), and came with a working Network and larger disk, in a
larger cabinet .
So where's the problem, and the need to relate inaccurate information?
Martin L. Griss
-------
∂08-Mar-82 2000 DREIFU at Wharton-10 (Henry Dreifus) Re: apollo
Date: 8 Mar 1982 (Monday) 2201-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: Re: apollo
To: Griss at Utah-20
cc: works at Mit-Ai
Via: Mit-Ai; 8 Mar 82 22:26-EDT
Via: Brl-Bmd; 8 Mar 82 22:30-EDT
We also have the font editor, running on a Black&white display with
a touchpad. It seems much nicer than the Perq, of which I've used
only slightly. As compared with other systems the Apollo is a win.
That is not to say that it is the best and all others are not even
usable, but rather that Apollo has made some of the more intelligent
trade-offs.
Much of our software (Quick-Graph), a DBMS graphics-interface,
Q/A window prompt manager and underlying core software to (at some
future date) handle graphics-laser printer interface has all been
and will continue to be developed in Pascal. As one of the first
Pascal sites, we've been especially pleased with with the implementation.
At first, though it was a bit strange (* *) would not work, and so on...
I would be interested if everyone who is working on the Apollo could/would
send a little note to Works (to be incorporated in an electronic-issue)
on what you are doing and how it looks. One thing of primary interest
is if the user community would take time to answer the following short
questions:
If you have an Apollo, are you dis-satisified? Why?
If you have a Perq, can you qualify yourself as to whether you can
compare the two machines? If so, can you contrast them?
If you have a Perq, are you dis-satisified? Why?
If you have a |X|, are you pleased? X:=={personal workstation}
Henry Dreifus
∂08-Mar-82 2148 AVB Ethernet Doomed?
∂08-Mar-82 2136 the.tty.of.Geoffrey.S.Goodfellow at Sri-Csl Ethernet Doomed?
Date: 8 Mar 1982 2045-PST
Sender: GEOFF at Sri-Csl
Subject: Ethernet Doomed?
From: the.tty.of.Geoffrey.S.Goodfellow at Sri-Csl
Reply-To: Geoff at Sri-Csl
To: WorkS at Mit-Ai, Human-nets at Mit-Ai
Message-ID: <[SRI-CSL] 8-Mar-82 20:45:22.GEOFF>
Via: Mit-Ai; 9 Mar 82 0:03-EDT
Via: Brl-Bmd; 9 Mar 82 0:09-EDT
March BYTE, p 437
A report issued by Strategic Incorporated, a market-research firm
in San Jose, California, predicts Xerox Corporation's Ethernet local
area network will be a total failure within two years. According to
Strategic's president, Michael Killen, "Xerox is headed for the worst
failure in the company's history." He believes that Xerox lacks
technological and price advantages, sales force, and customers
interested in buying large systems. Fuerther, he contents that
Ethernet's baseband approach to local networking will prove inferior
over the long haul to the broadband approach taken by Xerox's
competitors. He points out that broadband systems are better suited
to carry video, heavy voice and data transmissions, among other
applications.
∂08-Mar-82 2156 AVB Electronic Newsroom Info Request
∂07-Mar-82 1507 hail.mit-vax.BRL-BMD Electronic Newsroom Info Request
Date: 7 Mar 1982 17:24:04-EST
From: hail.mit-vax.BRL-BMD
To: human-nets mit-mc at BRL-BMD, works mit-mc at BRL-BMD
Subject: Electronic Newsroom Info Request
Via: Mit-Mc; 7 Mar 82 17:25-EDT
Via: Brl-Bmd; 7 Mar 82 17:31-EDT
The Tech, MIT's largest student newspaper, is planning to install an
electronic newsroom/typesetting system this summer. If we choose to
roll our own, we hope to use a UNIX-like system running on a large
micro, e.g. the 68000. The system would have to support visual
editing, including typesetting scanning, plus formatting and spooling.
As we are not sure whether we can junk our old typesetters yet, we are
also interested in device independence. We would appreciate any
information on electronic newsrooms, text editors and formatters,
(device independent) typesetting, local networking, microcomputer
UNIX's, large micros, and anything/everything related. Please mail any
information, suggestions, or whatnot to TEN@mit-vax (or
...!eagle!mit-vax!TEN). If you want to talk, call Rich $alz at The
Tech, (617) 253-1541. Thanks.
∂09-Mar-82 1044 AVB Re: Ethernet Doomed?
∂09-Mar-82 0327 Frankston.SoftArts at Mit-Multics Re: Ethernet Doomed?
Date: 9 March 1982 05:44 est
From: Frankston.SoftArts at Mit-Multics
Subject: Re: Ethernet Doomed?
Sender: COMSAT.SoftArts at Mit-Multics
Reply-To: Frankston at Mit-Multics (Bob Frankston)
To: Geoff at Sri-Csl, WorkS at Mit-Ai, Human-nets at Mit-Ai
*from: BOB (Bob Frankston)
Local: Geoff at Sri-Csl,WorkS at Mit-Ai,Human-nets at Mit-Ai
Via: Mit-Ai; 9 Mar 82 5:44-EDT
Via: Brl-Bmd; 9 Mar 82 5:50-EDT
The Strategic Incorporated report seems rather naive:
1. Why would the failure of ethernet be the worst in the
companies history? So you plug a ringnet behind Star. Big deal.
2. Why is broadband superior to baseband? For a LAN (local
area network) it seems better to run two cables and not mix
technologies.
3. Ungermann/Bass has announced a broadband ethernet anyway.
So you can have your cable TV and send data over it too.
∂11-Mar-82 1215 AVB Perqs, Accent, and Spice
∂09-Mar-82 1504 Roger.Dannenberg at Cmu-10a (C410RD60) Perqs, Accent, and Spice
Date: 9 March 1982 1442-EST (Tuesday)
From: Roger.Dannenberg at Cmu-10a (C410RD60)
To: works at Mit-Ai
Subject: Perqs, Accent, and Spice
Message-Id: <09Mar82 144228 RD60@CMU-10A>
Via: Mit-Ai; 9 Mar 82 17:20-EDT
Via: Brl-Bmd; 9 Mar 82 17:32-EDT
Before the Apollo vs Perq flames get too high, I'd like to mention some
of the work going on at CMU toward software for Perqs. First, the
Accent kernel is operational (although there are apparently a few
bugs). Accent provides multiple processes with separate 32 bit address
spaces. Processes communicate through message passing primitives which
are extended by network servers to talk to other machines (see SOSP 81
proceedings for more info).
Second, an IO package called Canvas has been developed to support
user interaction with multiple processes, including multiple windows.
Canvas currently runs on the Three Rivers operating system, but has not
been converted to Accent.
The Spice file system is expected to be up soon, at which time
we hope to pull together the basics of a Spice development system.
Also on the list of Spice software is Common Lisp which is now
running interpretively on a DEC-20. Having just received our first 16K
writeable microstore, work is underway to debug the microcoded lisp
byte-code interpreter.
It's too early to say much about performance, but the Perq is
inherently faster than the 68000, and hardware to support paging
(currently done in microcode) is reported to be on its way.
-Roger Dannenberg
∂11-Mar-82 1216 AVB
∂09-Mar-82 1525 research!bart at Ucb-C70
Date: 8 Mar 1982 19:39:34-PST
From: research!bart at Ucb-C70
Via: Mit-Ai; 9 Mar 82 17:32-EDT
Via: Brl-Bmd; 9 Mar 82 17:52-EDT
More on wait states...
In every monkey cage there is bound to be some ape that stands up to show
all the other apes how long his organ is. The designer of the SUN processor
board has cleverly arranged the on-board memory so that the 68000 can run
without waiting for memory. This is attributable to the following:
1) Mapping the high order address bits results in a tolerable delay since
the memory chips only want the lower order bits first. (bravo!)
2) The 68000 does memory refresh in software, AND
3) memory on the processor board is NOT accessible from the Multibus, which
means the addresses to the memory array can only come from one source and
need not be multiplexed or arbited.
Yes, the SUN processor does not need wait states for memory access, at
a speed penalty of about 10% per wait state, but it spends maybe 5% of
its time refreshing memory (insignificant) and DMA is disallowed.
Anyone who has written code for bitmap graphics knows it is very easy to
lose large factors in seemingly innocent ways. If the WICAT system is
really as "SLOW" as the reviews, obviously they haven't figured out this
world yet. The effects of hardware "assist" and extra wait states are really
down in the noise.
TANSTAAFL.
- Bart Locanthi
---------
Bart,
some comments to your message:
1) One 68000 wait state is 1/4 of a normal speed cycle.
Thus each wait state stretches out the cycle time by 25 %,
instead of the 10% you mention. The Wicat system I once measured
had between 3 and 6 wait states for every cycle at 8 MHz,
thus effectively running between 3 and 5 MHz, making it run
at less than half speed of the SUN.
2) The way the SUN refreshes memory in software
leads to exactly the same overhead as refresh done in hardware.
In fact, we are now using the refresh routine to perform certain
system checks, thus effectively decreasing refresh overhead to 0.
3) The hardware assist in the SUN graphics system leads to a significant
improvement over a software implementation of the same function.
For a random rasterop, the improvement is between 5:1 and 10:1.
The SUN bitblts at a rate of 32 MBit/sec (reading and writing
16 bits per microsecond).
Thus, in summary, I do not agree with your statement that wait states
and hardware assists are in the noise compared to clever software.
Rather, clever hardware design is as much part of an optimized system
as good software, and in fact, more importantantly so because you can
run the same software faster on a hardware without wait states.
In particular, for bitmap display manipulation, hardware speed
is directly visible.
- Andy Bechtolsheim -
∂11-Mar-82 1216 AVB Re: Ethernet Doomed?
∂09-Mar-82 1632 guyton at Rand-Unix Re: Ethernet Doomed?
Date: Tuesday, 9 Mar 1982 13:44-PST
To: Geoff at Sri-Csl
Cc: WorkS at Mit-Ai, Human-nets at Mit-Ai
Subject: Re: Ethernet Doomed?
In-reply-to: Your message of 8 Mar 1982 2045-PST.
<[SRI-CSL] 8-Mar-82 20:45:22.GEOFF>
From: guyton at Rand-Unix
Via: Mit-Ai; 9 Mar 82 18:56-EDT
Via: Brl-Bmd; 9 Mar 82 19:01-EDT
Quotes from an article in Mini-Micro World, Feb 82, pg 17-18.
(Also, the same article has some information on a couple high
level protocols recently announced by Xerox.)
" . . . Davide Liddle, vice president and general manager of the
OPD, defended the single-channel, baseband approach used by
Ethernet against multi-channel, broadband LAN methods. He also
took issue with the critical Strategic, Inc., report, entitled
"Xerox - The Key Issues."
"Out of about 100 pages," Liddle said, "only about two and one-
half pages deal with Ethernet. Most of the remainder consists of
historical data, untrue information and gossip. The Ethernet
material that does exist is incorrect."
[ . . .]
Liddle claims assertions of broadband cost advantages are
"rubbish." Although many broadband components are the same type
of units used for CATV transmissions, and are, therefore,
produced in quantity at low costs, the broadband transmitters are
relatively expensive and difficult to maintain on a one-per-work-
station basis, Liddle says. Broadband systems also require a
separate modem and controller for each terminal at each node,
while Ethernet requires only one controller per node.
Broadband also suffers in comparison to baseband during the
planning stage, Liddle says. "You need a galactic plan to
implement a broadband network because you must ensure systgem
balance, since a strong signal can overpower a weak one." Drop
cables to terminals must also be of the same length.
∂11-Mar-82 1217 AVB Administrivia - Archives.
∂09-Mar-82 1827 Jonathan Alan Solomon <JSOL@Usc-Eclc> Administrivia - Archives.
Date: Tuesday, 9 March 1982 17:42-PST
From: Jonathan Alan Solomon <JSOL@Usc-Eclc>
To: WorkS at Usc-Eclc
Subject: Administrivia - Archives.
Via: Usc-Eclc; 9 Mar 82 20:44-EDT
Via: Brl-Bmd; 9 Mar 82 20:51-EDT
Hi,
Finally I have what I believe is the total cost for printing and
mailing the archives to WorkS to those who can't otherwise retrieve
them. I'm sorry if this seems a bit much, but I'm only charging actual
costs and not making any money on it.
The CPU/PRINT charges for printing the WorkS archives are $25.00
The postage charges for mailing the WorkS archives (cheapest route)
are $10.00
Therefore, if you want me to send you the archives via UsSnail, it
will cost you $35.00.
Unfortunately, this will have to be charged in advance. Sorry, guys.
I will update the "Hello" message I send to new members of WorkS to
reflect this charge. I had no idea it costed that much myself!
Send your check for $35.00 to:
WorkS Archives,
c/o Jon Solomon
PHE 204 USC-ECL
University Park
Los Angeles, CA 90007.
Once your check arrives and is processed by my bank, I will print and
mail you a copy of the archives. Be sure and include a return address.
UUCP users: I have been asked many times to remail a copy of the WorkS
archives to users on the UUCP network one digest at a time. This cannot
be done. There would be about 50 or 60 messages, each about 18K
characters long. Can you imagine how long it will take to process all
that at 300 baud?
As always, If you have access to an Arpanet machine, you can FTP the
files from USC-ECLB, in the directory <JSOL.WORKS>. The files are
WORKS.RECENT, which contains all issues for the current volume, and
VOLUME-1.TXT which contains all messages previous to 1 January 1982,
when I started volume 2. In addition, if you are willing to mail me a
magtape (2400 foot), and return postage (I don't know how much), then
I will be happy to mail you a copy of the archives in this form.
Cheers,
--JSol
∂11-Mar-82 1217 AVB Re: Ethernet Doomed?
∂09-Mar-82 2246 mo at Lbl-Unix (Mike O'Dell [system]) Re: Ethernet Doomed?
Date: 9 Mar 1982 20:49:09-PST
From: mo at Lbl-Unix (Mike O'Dell [system])
To: guyton at Rand-Unix
cc: WorkS at Mit-Ai, Human-nets at Mit-Ai, Geoff at Sri-Csl
Subject: Re: Ethernet Doomed?
In-reply-to: Your message of 9 Mar 1982 1709-PST (Tuesday).
Via: Mit-Ai; 10 Mar 82 0:52-EDT
Via: Brl-Bmd; 10 Mar 82 1:01-EDT
"Rumors of my recent demise have been greatly over-exagerated."
-Mark Twain
The market survey which pronounced the death of Ethernet is not
completely accurate and grossly oversold, but could you think
of a better scam to sell zillions of your document?
All the same, the comments by Xerox about broadband are equally
ill-informed. I have spent quite a while comparing the two
schemes and have come to the following conclusions.
1) Broadband does require a bit more initial planning because
you are wiring the world once and for all. But contrary to
Xerox, the design process isn't that complex, and if designed
properly, doesn't require the constant diddling Xerox implies.
Admittedly the required modem is complex, but for a good RF
designer, not that much more complex than an Ethernet transceiver
and occupies the same place in the architecture. Production
economies and special chips will get the modem cost down, just
like for Ethernets.
2) For a given piece of Coax, broadband systems get 5-10 times the
bandwidth out of the cable. Broadband systems multiplex in two
domains: time in each channel, and frequency within the cable.
This allows data, voice, video, and whatnot all on the same cable.
I know it is possible to put voice and maybe even video on Ethernet,
but you can get a lot more with 5 logical networks within the same
cable! Most of the modem designs are frequency-agile, so there
are lots of optimizations possible for either high-bandwidth
applications, or private subnets, again, all in the same cable.
3) On the other hand, Ethernet is CSMA/CD, while most wideband
systems are either pure CSMA, or CSMA/hopefully-CD. You have to
look closely and think hard to understand the real behavior of
the wideband systems, and the suppliers haven't been to helpful
giving away fine details to make these distinctions.
4) The other problem with Ethernet is its DC coupling. While
it will work fine in an electrically-quiet office, there are
some very real problems with electrical noise, ground loops,
sheild currents, and other similar evils. Some are just nusiances,
but others can be deadly, if accidently applied to a human.
When wiring a large building, you won't run an Ethernet through
the building core with the power feeds and elevator circuits.
Here at LBL, we have power transients which would certainly kill
an Ethernet going further than one building, and possibly even
within a single building.
Ethernet and Broadband aren't natural enemies; they are in fact
more similar than different. Same basic algorithms, different
encoding on the medium. I forsee large building or campuses with
wideband backbones interconnecting small baseband subnets.
I think Ethernet will be viable in that many people are building
things to plug into it, but Broadband does have advantages for
large building or campuses. The two will co-exist quite usefully.
At least one vendor, Ungermann-Bass, intends to make sure of it.
-Mike
∂11-Mar-82 1217 AVB Apollo
∂10-Mar-82 0009 BUSH at Usc-Isie Apollo
Date: 9 Mar 1982 2333-PST
From: BUSH at Usc-Isie
Subject: Apollo
To: WorkS at Mit-Ai
Via: Mit-Ai; 10 Mar 82 2:33-EDT
Via: Brl-Bmd; 10 Mar 82 2:41-EDT
Date: 6-Mar-82 1600-EST
From: Nathaniel Mishkin <Mishkin.YALE>
Subject: Re: Innovation
The window problem is a typical example of Apollo's approach.
I'm sure they wanted the whole zippy window thing from the start. ...
I believe it is typical. I've been working with the Apollos for almost a year
and I happen to know that Apollo was unfamiliar with the Alto when they
designed and implemented their original display manager. I wish they had taken
more time and looked around more before releasing their system. A la PR1ME,
they produced an initial product as quickly as possible, and have since refined
it (with the aid of substantial user feedback). Xerox, on the other hand (with
considerably greater resources) refined the Star before releasing it. I also
wish the system were more flexible (in the general direction of the Lisp
machine). Currently, for example, you either use the Apollo display manager
in its entirety, or write your own. There is no way, for example, to replace
the display manager's editor with your own. Assuredly, the product will
mature, but it could be less restrictive and could easily have been more
mature to begin with.
-------
∂11-Mar-82 1218 AVB Ethernet Doomed?
∂10-Mar-82 0105 Chris Ryland <Ryland@Sri-Kl> Ethernet Doomed?
Date: Tuesday, 9 March 1982 18:57-PST
From: Chris Ryland <Ryland@Sri-Kl>
to: Human-nets at Mit-Ai, WorkS at Mit-Ai
Subject: Ethernet Doomed?
Via: Mit-Ai; 10 Mar 82 3:39-EDT
Via: Brl-Bmd; 10 Mar 82 3:41-EDT
Date: Tuesday, 9 Mar 1982 13:44-PST
From: guyton at Rand-Unix
[ . . .]
Liddle claims assertions of broadband cost advantages are
"rubbish." Although many broadband components are the same type
of units used for CATV transmissions, and are, therefore,
produced in quantity at low costs, the broadband transmitters are
relatively expensive and difficult to maintain on a one-per-work-
station basis, Liddle says. Broadband systems also require a
separate modem and controller for each terminal at each node,
while Ethernet requires only one controller per node.
This is nonsense. Ethernet also requires a modem and controller per
node. He must have been misquoted or misunderstood.
Broadband also suffers in comparison to baseband during the
planning stage, Liddle says. "You need a galactic plan to
implement a broadband network because you must ensure systgem
balance, since a strong signal can overpower a weak one." Drop
cables to terminals must also be of the same length.
This is also partial nonsense. Would someone from Sytek or one of the
broadband companies please clarify?
∂11-Mar-82 1219 AVB Hardware Driven?
∂10-Mar-82 0948 Jeffrey at Office-2 Hardware Driven?
Date: 10 Mar 1982 0706-PST
From: Jeffrey at Office-2
Subject: Hardware Driven?
To: works at Mit-Ai
Via: Mit-Ai; 10 Mar 82 10:20-EDT
Via: Brl-Bmd; 10 Mar 82 11:45-EDT
I've been reading WorkS mail for a couple of months. I have the
impression that the discussions like current commercial workstation
technology tend to be hardware driven.
Recently the Apple people (yes, that's Apple like in Apple II and
Apple ///) have been consistently saying that they think the real
problems are software problems. Unix may be a wonderful system for
developing and maintaining files of source code, but how do you
support any graphic application under Unix?
I hear rumors that the next Apple machine may support a sophisticated
application development environment including a language like
Smalltalk. If this is true, then Apple may steal the show for the
next generation of small systems.
My impression of things is that with sophisticated "information
graphics" software development capabilities, small computers can be
really be made orders of magnitude more useful than the ones we are
seeing today (and that includes the vanilla 68000/Unix systems).
I'd love to hear comments, responses - anything. Can anyone describe
the high level application development facilities available through
existing systems. I'm very interested in facilities which can be
used to by software to manipulate sophisticated displays displays.
The kinds of things that SUN and STAR are aiming towards.
Does anyone know what Apple has been doing for several years with all
those computer scientists (I doubt that they are writing Apple II
applications in AppleSoft).
Thanks,
Jeffrey Stone
Menlo Park, Ca.
-------
∂11-Mar-82 1219 AVB Re: WORKS Digest V2 #19
∂10-Mar-82 1057 baker.wbst at Parc-Maxc Re: WORKS Digest V2 #19
Mail-from: ARPANET site PARC-MAXC rcvd at 10-Mar-82 1002-PST
Date: 10 Mar 1982 12:50 EST
From: baker.wbst at Parc-Maxc
Subject: Re: WORKS Digest V2 #19
In-reply-to: JSOL's message of 9 Mar 1982 0047-PST
To: WORKS at Usc-Eclb
Via: Usc-Eclb; 10 Mar 82 13:03-EDT
Via: Brl-Bmd; 10 Mar 82 13:14-EDT
As someone in a Xerox distribution list pointed out, "I wonder if Killen's working
previously for Wang shaded his predictions any, hmm? This little gem has been
floating around the tradepapers for the last two months. Truth is anything
repeated often enough."
And even so, Mostek has just announced its intentions to make an Ethernet
controller for the 68000, and Siemens has announced its intent to market
Ethernet-based equipment in Europe.
∂11-Mar-82 1220 AVB Mike O'Dell and Ethernet
∂10-Mar-82 1340 John O'Donnell <Odonnell@Yale> Mike O'Dell and Ethernet
Date: 10-Mar-82 1436-EST
From: John O'Donnell <Odonnell@Yale>
Subject: Mike O'Dell and Ethernet
To: Works at Mit-Ai
Via: Mit-Ai; 10 Mar 82 15:41-EDT
Via: Brl-Bmd; 10 Mar 82 15:52-EDT
Several points should be made:
First, about broadband. Current RF modems have problems with a cumulative-noise
phenomenon; 40 dB down is not necessarily good enough if you plan hundreds of
modems. Also, as I understand it a broadband cable is almost, but not quite,
many logically independent networks. Problems arise on collisions: transmitters
beat against each other, spraying noise across all frequencies on the cable.
Second, cable bandwidth. Ethernet provides one channel, with well analyzed
and understood behavior under wide-ranging loads. The CATV systems partition
cable bandwidth in ways that may not correspond to the load; also, many of them
use questionable FDM and packet-allocation practices that look nice in theory,
but may match real loads quite poorly. Comparing 'raw' bandwidths is
quite misleading.
Third, DC coupling. Properly designed transcievers provide ground isolation.
Lighting has struck near PARC several times without problems (problems
DID occur once when cable ground was not properly isolated from building
ground; this is equally dangerous and/or likely with broadband systems).
No argument here between Ether/Broadband makes sense, unless the 'broadband'
medium is fiber optic.
Our view is that indeed, some mix of ether and broadband makes a great deal
of sense in planning for a large campus: in-building Ether distribution linked
via broadband gateways (the Ungermann-Bass systems look attractive for this).
-------
∂11-Mar-82 1221 AVB Is UNIX really the answer ?
∂10-Mar-82 1448 Joel.Goldberger at Usc-Isib Is UNIX really the answer ?
Date: 10 Mar 1982 1214-PST
Sender: JGOLDBERGER at Usc-Isib
Subject: Is UNIX really the answer ?
From: Joel.Goldberger at Usc-Isib
Reply-To: JGOLDBERGER at Usc-Isib
To: Works at Mit-Ai
Message-ID: <[USC-ISIB]10-Mar-82 12:14:23.JGOLDBERGER>
Via: Mit-Ai; 10 Mar 82 16:42-EDT
Via: Brl-Bmd; 10 Mar 82 16:52-EDT
I was glad to see that someone else has the same concerns as I do
concerning not only the Works discussion, but the current commercial
offerings as well. I am referring to Jeffrey Stone's msg of 10 March.
We here at ISI have been going around and around with our discussions
concerning what it is we actually want, and/or can get. We currently have
5 TOPS-20's and a TENEX running the usual compliment of editors,
mail-readers, and document preparers. Everytime we (the New Computing
Environment Project) have mentioned workstations running some flavor of
UNIX our researchers have risen in protest. Some of their concerns are
"easy" to overcome; Long file names (we have just gotten this working, and
Berkeley is rumored to be doing it too), Version numbers, Filename
completion, a "real" backup mechanism, to name a few. But there are many
other concerns that come from some very fundamental aspects of UNIX.
I must admit that I am not a great fan of UNIX myself, but have to agree
that for "small" machines there isn't anything that's better, nor am I
advocating porting TOPS-20 to personal computers. My point is that I'm not
convinced that its such a win to start with an operating system that has
none of the needed hooks in place to build the computing environment of the
80's. Xerox apparently reached a similar conclusion; that is rather than
add all the bells and whistles to their ALTO environment (that atleast knew
about bit-mapped displays) they developed an entirely new environment
starting with MESA & PILOT and ending with the STAR. For a few months we
were in heated negotiations with Xerox to try to get STARs with the MESA
development environment. At that time (~2 months ago) we were told NO.
Now there are rumors that it may be available. Still, there are obvious
problems associated with being tied to a single manufacturer for both
hardware and software.
It is my belief that UNIX is fantastic as what it is, namely a portable
operating system. To my knowledge nothing else has ever come close. The
extensions that Berkeley has made (and continues to make) are also great,
but already one can see incompatibilities developing. Some of the new
features Berkeley has added will probably never find their way into the
UNIX that will run on WICATs, SUNs, PERQs, and the like.
The issue for us (atleast) is that our user community is not going to be
satisfied with just increased performance at the loss of functionality
(as they perceive it), this is what UNIX on a WICAT/SUN/PERQ/... seems to
offer. What they would really like is all the things a STAR offers: Fancy
editor, Graphics, Multiple Windows, Dazzling user interface, etc. BUT they
also want to be able to program the thing and make use of all the neat
stuff themselves.
At both the recent ACM SIGOPS conference and the most recent USENIX meeting
there were presentations by people who had added some windowing suport to
existing operating systems, they were impressive efforts, but not quite
impressive enough to be worth the effort (for us).
I wish I had an alternative to suggest, but all I have are these concerns.
- Joel Goldberger -
∂11-Mar-82 1221 AVB Re: is unix really the answer?
∂10-Mar-82 1650 RENTSCH at Usc-Ecl Re: is unix really the answer?
Date: 10 Mar 1982 1557-PST
From: RENTSCH at Usc-Ecl
Subject: Re: is unix really the answer?
To: WORKS.BRL at BRL
cc: Jeffrey at Office-2, JGoldberger at Usc-Isib
Via: Usc-Ecl; 10 Mar 82 18:57-EDT
Via: Brl-Bmd; 10 Mar 82 19:01-EDT
I would like to second most if not all of Joel Goldberger's comments. I too
think that trying to adapt UNIX for Alto style personal computers is simply
the wrong path. Admittedly many many people have been and will be using
UNIX, but the environment envisioned for UNIX just doesn't match the
Alto style mold. Most systems that start with a good idea and then try to
adapt to a new paradigm end up being a disappointing mixture of the two,
with a real identity crisis about when to use which ideas. It's better
to do a new design from the ground up both in terms of quality of
implementation and conceptual integrity. Xerox has the right idea with
the mesa development environment, for example, by deciding to go with
an all new system.
On the subject of Xerox, the information that I have is that MESA will be
available on the STAR, at a cost of $3,000/processor, but not until
the end of this calendar year. I have seen the development environment
running on a STAR (at Xerox) and it looks pretty good and very integrated
into the workstation mold (uses windows, makes use of display well and the
mouse, etc.) This is not too surprising since after all Xerox has been
blazing the trail (you can tell the pioneers by the arrows in their backs)
and has many many man years of experience with Alto style implementations.
What would really be nice is if a Smalltalk implemenation were available
from Xerox for the STAR. Office Products Division has not yet gotten
off its corporate butt and made the decision (officially) to get back
into the (now personal) computer business. I have heard rumors that
Xerox is planning a Smalltalk implementation for the STAR and that Dave
Liddle of OPD is enthusiastic about Smalltalk, but a flurry of enquiries
would certainly help. Call David Liddle at (415) 494-4770 , and ask him
personally when Smalltalk will be available. I think he'll get the message.
Tim Rentsch
-------
∂11-Mar-82 1222 AVB Re: is unix really the answer?
∂10-Mar-82 1801 BILLW at Sri-Kl Re: is unix really the answer?
Date: 10 Mar 1982 1704-PST
Sender: BILLW at Sri-Kl
Subject: Re: is unix really the answer?
From: BILLW at Sri-Kl
To: RENTSCH at Usc-Ecl
Cc: WORKS.BRL at BRL, Jeffrey at Office-2
Cc: JGoldberger at Usc-Isib
Message-ID: <[SRI-KL]10-Mar-82 17:04:37.BILLW>
In-Reply-To: Your message of 10 Mar 1982 1557-PST
Via: Sri-Kl; 10 Mar 82 20:38-EDT
Im not sure I agree. One of the nice things about UNIX is the
SHELL concept - You can supply UNIX NOW with a system, then
improve the user interface in the future by supplying different
shells. Theoretically, you can do this for TOPS-20, but I
gather DEC tends to be fussier about supplying source code
for their "EXEC", making it harder for people to develop their
own versions...
∂11-Mar-82 1223 AVB Re: Mail headers
∂10-Mar-82 1955 Jan Walker <JWalker@Bbna> Re: Mail headers
Date: 10 Mar 1982 2003-EST
Sender: JWALKER at Bbna
Subject: Re: Mail headers
From: Jan Walker <JWalker@Bbna>
To: Lepreau at Utah-20
Cc: WorkS at Mit-Ai
Message-ID: <[BBNA]10-Mar-82 20:03:32.JWALKER>
In-Reply-To: Your message of 10 Mar 1982 1208-MST
Via: Mit-Ai; 10 Mar 82 22:19-EDT
Via: Brl-Bmd; 10 Mar 82 22:31-EDT
Sure. It makes perfect sense not to @i[require] the To: field,
for example, in applications where you are just filing the
message, rather than actually sending it. This is a case,
however, where the spirit of the law demands some indication of
the auspices under which the mail is arriving even if the letter
of the law does not. Note that RFC733 tried to make that the
case by requiring the From field. Unfortunately in the big
public mailing list world, the From: information does not make
that identification and the To: field would.
∂11-Mar-82 1224 AVB Unix really isn't the answer
∂10-Mar-82 2048 Nathaniel Mishkin <Mishkin@Yale> Unix really isn't the answer
Date: 10-Mar-82 2149-EST
From: Nathaniel Mishkin <Mishkin@Yale>
Subject: Unix really isn't the answer
To: Works at Mit-Ai
Via: Mit-Ai; 10 Mar 82 22:52-EDT
Via: Brl-Bmd; 10 Mar 82 23:02-EDT
I think there are two basic reasons people feel uncomfortable with
the idea of "personal machine Unix":
(1) Unix is not interactive; the shell and the software tools
were designed to be "programmable" (i.e. fit well together,
not with the user). What use is a personal RJE station?
(2) Unix has developed out of a limited-resource environment;
there's just so much you can fit into a 64K address space.
For reasons unclear to me, it seems that Berkeley Unix still
is bit-stingy. Is this because of how paging works in Berkeley
Unix?
At the other extreme, there is Tenex/TOPS-20. It is about as
interactive as a timesharing can get. It never suffered (or benefited)
from an attitude of "gee, we better not put this in the monitor since
we might run out of address space".
Given a choice of either extreme of featurefullness for my personal
machine, I would take the TOPS-20 attitude. But let's face it, this
isn't going to fly on a 256K machine. If you want all the zippy
features available without paging to death, you're going to need 2M.
I don't mean to sound so anti-Unix, it's just that people seem to have
accepted Unix so uncritically as the model for the future; its warts
have been painted over, not removed. It's time for major surgery.
Let's take the good ideas and move on.
-------
∂11-Mar-82 1225 AVB UNIX & "the" Answer
∂11-Mar-82 0159 Michael Muuss <mike@Brl-Bmd> UNIX & "the" Answer
Date: 11 Mar 82 4:06:10-EST (Thu)
From: Michael Muuss <mike@Brl-Bmd>
To: WorkS at Mit-Ai
cc: Cluster at BRL
Subject: UNIX & "the" Answer
Via: Mit-Ai; 11 Mar 82 4:11-EDT
Via: Brl-Bmd; 11 Mar 82 4:22-EDT
UNIX is probably not where good interactive computing is going to be
in 7 years. Maybe less. It certainly has it's faults. UNIX might
well be the worst timesharing system around, except for all the rest!
If we all had bit-mapped displays and .5 MIPs "personal computers",
we might elect something sexier than UNIX. We might not.
There are several things which make (made?) UNIX great:
1) Delightful programming environment (ie, "C" and the UNIX system-
calls, and I/O library)
2) Hardware independence
3) Highly tailorable and modular user environment (for a mini, and
most mainframes too!)
#3 was superfantastic in 1972, but is being overtaken as neat things
happen. The bit-mapped terminal people are (seemingly) trying to
do away with a lot of #2 (this will get better after the hardware
proliferates for a while). And most people accustomed to "big systems"
don't always seem to understand #1.
Biased? Sure! -- Until better things come along.
-Mike
∂11-Mar-82 1226 AVB Ethernet Doomed?
∂11-Mar-82 0805 ''Marvin A. Sirbu, Jr.'' <SIRBU@Mit-Mc> Ethernet Doomed?
Date: 11 March 1982 09:02-EST
From: "Marvin A. Sirbu, Jr." <SIRBU@Mit-Mc>
Subject: Ethernet Doomed?
To: Ryland at Sri-Kl
cc: Human-nets at Mit-Ai, WorkS at Mit-Ai
Via: Mit-Ai; 11 Mar 82 10:19-EDT
Via: Brl-Bmd; 11 Mar 82 10:28-EDT
I'm sorry, but Ethernet does not reguire a MODEM, it requires a
TRANSCEIVER. There's a big difference. A modem implies RF oscillators
and receivers with lots of filters and other non-digital components.
Transceivers, operating on honest-to-goodness digital signals, not
RF tones, are easier to build.
The controllers, on the other hand, which packetize and do the right
thing when collisions are detected, are essentially the same for
baseband and broadband CSMA-CD networks.
Marvin Sirbu
∂11-Mar-82 1227 AVB ethernet, unix
∂11-Mar-82 1149 DPR at Mit-Xx ethernet, unix
Date: Thursday, 11 March 1982 11:45-EST
From: DPR at Mit-Xx
To: works at Mit-Mc
Subject: ethernet, unix
Via: Mit-Mc; 11 Mar 82 11:48-EDT
Via: Brl-Bmd; 11 Mar 82 13:53-EDT
Ethernet:
People are comparing apples and oranges here. Ethernet has
had a long period of testing in the field. If you want to
buy a technology that's known to work, buy Ethernet.
Broadband data nets (not broadcast cable video) now being
"announced" by venture companies, and even Wang, are all
promise... I'd get a contract that let me sue if they don't
satisfy my needs if I were to risk my company on those
technologies (they may be "better" eventually, but that is
only one aspect of considering them--would you buy a BART?)
Most of the technical "differences" advertised by manufacturers
fall into the "brand differentiation" area here -- when
all is said and done, looking at the whole system, the approaches
probably will all work about equally well. whose snake
oil do you buy?
UNIX:
It sure is nice not to have to build an operating system for
each machine you build. Thus hardware makers will love UNIX.
On the other hand, the concept of an "operating system" is obsolete.
What is needed for workstations or any other computer is a set
of easy to use primitives for manipulating the kinds of abstractions
that are of interest in building applications. For many of the
things I used to do, MACLISP (interlisp as well) is the programming
system of choice. Many users had built a huge library of wonderful
primitives for data structuring, debugging, screen managment, ...
If it runs on UNIX, fine. But I'd never use UNIX raw for those things.
UNIX is good at streaming-file-oriented processing (in fact it makes I/O
devices look like files so that the file-oriented tools can work on
character streams from other sources). For objects not structured as
byte streams (databases, knowledge rep systems, window management systems,
simulation modelling, video game construction, robot control, ...)
UNIX provides no help. In fact, since UNIX provides rather clumsy
processes and access to I/O, UNIX can't easily be perverted to do these
things.
At times it becomes useful to attack established dogma. UNIX is
an embodiment of a lot of clever ideas that comprise a model of what
computing is. I assert that computing for the 80's is best treated
by a radically different model or set of models. Little or nothing
is contributed by UNIX and C other than a programming system that might
be used with the intent of throwing it away when the better ideas
jell into practical systems.
∂11-Mar-82 1228 AVB TOPS-20 EXEC
∂11-Mar-82 1222 Joe.Newcomer at Cmu-10a TOPS-20 EXEC
Date: 11 March 1982 1338-EST (Thursday)
From: Joe.Newcomer at Cmu-10a
To: works at Mit-Ai
Subject: TOPS-20 EXEC
In-Reply-To: <[SRI-KL]10-Mar-82 17:04:37.BILLW>
Via: Mit-Ai; 11 Mar 82 14:36-EDT
Via: Brl-Bmd; 11 Mar 82 14:42-EDT
The last I looked, DEC was nut fussy at all about releasing the source code
to the EXEC; for a modest number of dollars you can get a source license
but I don't know if that is a site license or a processor license. Modest
is under $10K, which on a typical $750,000 KL20 just ain't all that much
additional.
One major difference between Unix and TOPS-20 is that on Unix I felt a
compulsion to rewrite the shell because it was so bad, but never had the
time to engage in the compulsion. I would like to do a few tweaks on
the TOPS-20 EXEC, which has it s own problems, but they are not a
major departure from the basic philosophy of the TOPS-20 EXEC. In the
case of Unix, I would never have considered using the shell code at all,
except possibly to see how some bizarre interface to the kernel was done.
It is such a poor piece ofinterface that I found it a constant aggravation
every time I typed a command.
joe
∂11-Mar-82 1245 AVB Re: UNIX & "the" Answer
∂11-Mar-82 1237 Joe.Newcomer at Cmu-10a Re: UNIX & "the" Answer
Date: 11 March 1982 1354-EST (Thursday)
From: Joe.Newcomer at Cmu-10a
To: works at Mit-Ai
Subject: Re: UNIX & "the" Answer
In-Reply-To: Michael Muuss's message of 11 Mar 82 04:06-EST
Via: Mit-Ai; 11 Mar 82 14:36-EDT
Via: Brl-Bmd; 11 Mar 82 14:52-EDT
I guess I would never have classified the programming environment on Unix
as "delightful"; the editors pretty uniformly are crocks, and C is the
third worst high-level language I've used (Pascal being the worst), but
it is one of the few languages in which one can write a realistic program
that is hardware independent. What made Unix great was the third point,
which was the tailorable user environment on a mini. There is no
question that Unix is a great operating system for a PDP-11, Z80,
maybe a 68000, but it compromises too many things on a VAX, and trades off
people cycles for machine cycles. People cycles cost a whole lot more.
It also reflects some very narrow cultural background which is slightly
out of step with the rest of the world ('ls'' means 'directory' and
'rm' means 'delete') which wouldn't be so bad if the documentation keyword
retrieval used traditional words as well as Unix-cultural words.
Alas, it does not, and the great "on line documentation" is nearly useless
to an experienced programmer who thinks in concepts (like deleting
a file) instead of Unix jargon. This makes the learning cureve on Unix
very difficult to overcome, and the frustration of spending 15 minutes trying
to figure out how to delete a file is enough to turn someone off completely.
joe
∂11-Mar-82 1652 AVB Re: Ethernet Doomed?
∂11-Mar-82 1544 BILLW at Sri-Kl Re: Ethernet Doomed?
Date: 11 Mar 1982 1206-PST
Sender: BILLW at Sri-Kl
Subject: Re: Ethernet Doomed?
From: BILLW at Sri-Kl
To: SIRBU at Mit-Mc
Cc: Ryland at Sri-Kl, Human-nets at Mit-Ai, WorkS at Mit-Ai
Message-ID: <[SRI-KL]11-Mar-82 12:06:05.BILLW>
In-Reply-To: Your message of 11 March 1982 09:02-EST
Via: Mit-Ai; 11 Mar 82 18:00-EDT
Via: Brl-Bmd; 11 Mar 82 18:11-EDT
You are also wrong. An ethernet tranceiver is a far cry from a
modem, and is a lot simpler, but it isnt quite pure digital.
I believe that EtherNet does colision detect by measuring the
DC level on the coax - If one person is using it, the dc level
is about X. If two people are trying to transmit at once,
it deviates from X. A tranceiver has to be pretty sneaky
since X will vary depending on how far away from this tranceiver
the station that is transmitting is. A person from MIT recently
gave a talk at Stanford advocating ringnets over ethernets for
this (simplified analog electronics), amoung other reasons...
Bill W
∂11-Mar-82 1653 AVB Re: Re: UNIX & "the" Answer
∂11-Mar-82 1602 mike at Rand-Unix Re: Re: UNIX & "the" Answer
Date: Thursday, 11 Mar 1982 13:56-PST
To: Joe.Newcomer at Cmu-10a
Cc: works at Mit-Ai
Subject: Re: Re: UNIX & "the" Answer
In-reply-to: Your message of 11 March 1982 1354-EST (Thursday).
From: mike at Rand-Unix
Via: Mit-Ai; 11 Mar 82 18:30-EDT
Via: Brl-Bmd; 11 Mar 82 18:42-EDT
Dear Joe,
Your message about UNIX has the following semantic content:
UNIX is no good because a) C is "the worst" and b)
because UNIX doesn't call things the way "I'm" used
to, ie it doesn't conform to PDP 6 (and its successors)
terminlogy, so it must be "wrong".
Can we raise the intellectual content of this list a little?
Michael
∂11-Mar-82 1653 AVB Someone's Theory
∂11-Mar-82 1612 mo at Lbl-Unix (Mike O'Dell [system]) Someone's Theory
Date: 11 Mar 1982 13:09:56-PST
From: mo at Lbl-Unix (Mike O'Dell [system])
To: works at Mit-Ai
Subject: Someone's Theory
Via: Mit-Ai; 11 Mar 82 18:40-EDT
Via: Brl-Bmd; 11 Mar 82 18:44-EDT
Just a passing comment...
There is a psychological theory, the author of which I can't remember at
the moment, which says the first language you learn, or become fluent
in, dramatically controls the thoughts you can have. In watching
the recent interchanges, I wonder if there is evidence supporting
this for Operating Systems (Tenex, for example) and Programming
Languages (C, for instance). The flames both ways are interesting
to watch, so I won't jump in just now, but it might be interesting
for people to reflect on their opinions and attempt to understand
their biases. The whole world is not Vaxen, 68000's, or even KL20's.
-Mike
∂11-Mar-82 1930 AVB Re: Unix really isn't the answer
∂11-Mar-82 1920 George.Coulouris at Cmu-10a Re: Unix really isn't the answer
Date: 11 March 1982 1843-EST (Thursday)
From: George.Coulouris at Cmu-10a
To: works at BRL
Subject: Re: Unix really isn't the answer
In-Reply-To: Nathaniel Mishkin's message of 10 Mar 82 21:49-EST
Message-Id: <11Mar82 184300 GC12@CMU-10A>
Via: Cmu-10a; 11 Mar 82 21:28-EDT
After 6 years working on user interface problems here at Queen Mary College
London in a UNIX environment. I agree wholeheartedly that UNIX is not suitable
(and was not intended by its designers) as a basis for workstation application
development. It isn't surprising that this is so, because 'dazzling user
interfaces' require quite a lot of computing resource, and they require
the resources to be allocated on a schedule that gives the user an illusion
of animation (see my earlier message on this bb 'what is a workstation').
Resource scheduling and process swapping are so deaply embedded in the
philosophy of a system like UNIX that it will be harder to change
it than to start again (I don't mean tinkering with the scheduling
algorithm, I mean altering the design so that process swapping
is as economical as procedure calling).
Is Mesa the answer? I don't know because I haven't used it, but how about
steering some of our discussion towards identifying our requirements for
the software environment of a workstation? Let me kick off with
a very incomplete wish-list:
1) Extensible application software. Working environments evolve,
and so do individuals' approaches to their work.
The old 'software releases' approach to software updating is clearly
laughable when applied in a distributed information pprocessing environment.
We need to be able to extend the software WHILE IT IS RUNNING, with a high
degree of confidence that our extensions are consistent with the existing system.¬
This requires modularity, interface checking, dynamic binding of symbols
to objects and strict typing (so that the objects passed across interfaces
can't spread infection to previously valid modules) I understand that
although Mesa is strongly typed in most areas, there are loopholes.
I don't think that is good enough because we require almost total confidence in our
interfaces. In passing, it is worth mentioning that C can never be strongly typed
because array bounds cannot be checked (amongst other reasons).
2) Concurrency. Workstations exist in a distributed information processing
environment (a local network containing workstations and server stations).
The environment is inherently less synchronous than a single central
system, so the program should be made up of many communicating sequential
processes. I think this also applies within a single workstation because
the CSP makes a very good modular building block, with the added advantage that the
decisions about which are executed concurrently can be left to the
scheduling and communication mechanism.
George Coulouris
Computer Systems Laboratory
Queen Mary College
London
∂13-Mar-82 0958 AVB Opinions & Biases
∂11-Mar-82 2007 Joel.Goldberger at Usc-Isib Opinions & Biases
Date: 11 Mar 1982 1719-PST
Sender: JGOLDBERGER at Usc-Isib
Subject: Opinions & Biases
From: Joel.Goldberger at Usc-Isib
Reply-To: JGOLDBERGER at Usc-Isib
To: Works at Mit-Ai
Message-ID: <[USC-ISIB]11-Mar-82 17:19:30.JGOLDBERGER>
Via: Mit-Ai; 11 Mar 82 22:06-EDT
Via: Brl-Bmd; 11 Mar 82 22:10-EDT
In my original message that seems to have touched off this recent
debate I was not trying to advocate the development of a portable
TOPS-20 for personal computers, nor did I feel the need to point out
the continuing annoyance of UNIX command naming practices.
I believe the theory offered by Mike O'Dell is certainly true but of
little relevance to my original concerns. Someone here at ISI pointed
out that computers are extremely good at re-educating their users to
new commands and/or procedures, it only takes a few trys at using
file-name completion on UNIX to learn that it doesn't work!
I think the real point is that when standing at the crossroads that
many of us are, in terms of changing our present computing
environments, it is a serious mistake to be content to trade one
traditional operating system for another. In the past this was not
the case; It was entirely reasonable to trade TOPS-10 for TENEX/TOPS-20,
or RSX/RSTS for UNIX, it is probably still reasonable to trade VMS for
UNIX. I don't know the options for 68000 based systems, but you get
the idea. It is not reasonable however to trade TOPS-20 for UNIX or
vice-versa, each has virtues the other lacks and when faced with a
user community that is comfortable in one or the other, the only way
to convince them the change is for the better is to offer them
something MUCH BETTER. The general feeling seems to be that this
means bit-mapped displays, mice, multiple windows, and reasonable
tools for the manipulation of these things.
My concern is that UNIX doesn't provide a suitable foundation for
building this environment (I don't think TOPS-20 does either!). One
way to insure that you build an entirely new environment is to pick
some hardware that all the old stuff doesn't work on (SPICE on PERQ's eg)
the other way is to use the same old hardware, but with an entirely
new operating system (seems like UNIX started this way).
It may well be that it requires an effort on the scale of the STAR to
accomplish this, but if that is the case we should admit it, and not
pretend that we're entering the new-age of computing with SUN
terminals running UNIX.
- Joel Goldberger -
∂13-Mar-82 0959 AVB UNIX as a working environment
∂11-Mar-82 2017 SSteinberg.SoftArts at Mit-Multics UNIX as a working environment
Date: 11 March 1982 20:12 est
From: SSteinberg.SoftArts at Mit-Multics
Subject: UNIX as a working environment
Sender: COMSAT.SoftArts at Mit-Multics
To: works at Mit-Ai
*from: SAS (Seth A. Steinberg)
Local: works at mit-ai
Via: Mit-Ai; 11 Mar 82 22:10-EDT
Via: Brl-Bmd; 11 Mar 82 22:31-EDT
UNIX is a nice homey system but it is not a lot different from
something like CP 67. Like a half a dozen other systems I have
used it has a nice subroutine library so you can get at the OS
from a higher level language and it provides a weak form of
dynamic linking (using process forking) so you can write your
own command processor like programs. Multics did it better,
OS/360 MVS did it about as well except the terminal support was
worse, early Primos blew it because their high level language
was Fortran, Magic 6 did this pretty well but was a bit big for
the processor and so on. Some of these systems felt more
comfortable than others. UNIX is usually the first decent
system people get to use and they usually fall in love with it
and never question it. [1] Having put up with a dozen
operating systems so far I put UNIX in the much better than
average category but am constantly reminded of the saying, "If
English was a good enough language for the Lord to write the
Bible in then it's good enough for me."
As far as the future? My favorite system today consists of a
hairy EMACS. I login, enter EMACS and stay there. Why?
Because, with a few extensions we have put in, there is no
reason not to work in an environment in which the screen is
well managed and I can do the things I do all the time easily.
Is EMACS the answer? I doubt it.
What does a good system need?
Dynamic linking: UNIX almost has this, but you still have
to work to fix a bug in a library. Multics, Magic 6,
SMALLTALK systems and the Lisp Machine have this.
Screen Management: You don't NEED bit mapped screens to do
something nice to your screen. You need imagination.
Personally, I like bit mapped screens, they can be treated
device independently, but what you really need is to think
in terms of screens, not teletypes.
Memory Management: I have seen several good approaches.
Language oriented systems use "object" orientation which
will probably be the winner, but segmentation provides a
number of useful advantages. The Lisp Machine uses both
and, of course, you PAGE underneath the whole thing. [2]
I agree that there is a software problem and I think there is a
software problem because most systems programmers and most
systems hackers are NOT IMAGINATIVE and INNOVATIVE enough.
Wow, that ought to get the bath
water a-bubbling,
Great balls of fire ...
Seth Steinberg
USELESS FOOTNOTES
[1] Why else does everyone say: UNIX is just like Multics
except better and ignore all of the work on capabilities and
scaling large systems back on CTSS and the PDP-1? It's simple,
they know UNIX but they haven't even read about Multics.
[2] SMALLTALK does not page. It loads objects from the disk
which is NOT the same. They tried a BIBOP scheme and when it
failed threw out the baby too. As you may have gathered I
think they made a mistake with their VERY CLEVER scheme but I
may be wrong.
∂13-Mar-82 0959 AVB Unix, IBM, humankind, Smalltalk, animation, parallelism
∂11-Mar-82 2112 Chris Ryland <RYLAND@Sri-Kl> Unix, IBM, humankind, Smalltalk, animation, parallelism
Date: 11 Mar 1982 2001-PST
From: Chris Ryland <RYLAND@Sri-Kl>
Subject: Unix, IBM, humankind, Smalltalk, animation, parallelism
To: works at BRL
Via: Sri-Kl; 11 Mar 82 23:07-EDT
Please, let's not crank up the old Unix religious debate on WorkS. See
back issues of nearly every other digest on the net for similar debates.
I think it's clear that the critical resource in today's computing world
is manpower, not machinery. The result? Systems which encourage and
support software movement among a variety of hosts are bound to be popular;
Unix and CP/m fill that bill reasonably well (no comparison betwixt the
two intended).
Since this list is supposed to be a collective soul-search for the ultimate
workstation (whatever that is), what might conceivably serve as a basis
for the next wave, after Unix? I propose Smalltalk (ST80 for short).
ST80 sits just about on the edge of what today's hardware (read: 68K
equivalents and follow-ons) can support "reasonably". I've seen ST80
in use, and know that I'd much prefer that world to anything else I've
seen (including Lisp machines, which have perhaps the most complete, if
also the most arcanely complex programming environment today). I think
the XEROX Systems Concepts Group (or whatever they call themselves now)
also knows it (why else would they have devoted so many years to ST?)
It's a shame that they're having such a hard time releasing ST to the
world, but I hear they're on the verge of such a release after a long
battle to get licensing going. (I hate to speculate like this, but
I can't say all that I hear.)
ST80 has exactly the properties proposed recently: an extensible system
with an "animated" feel. It doesn't use parallelism in any large
way, but I'm convinced that we don't understand how to use massive
parallelism in any but the crudest sense (e.g., weather prediction).
My ideal workstation, perhaps buildable by 2000, would place me in a
virtual world (3d and all) where the hallmark was malleability of the
objects and actors in the universe. This is an old idea, but makes
complete sense to me. And no one is doing anything seriously along
these lines. Boils down to the same old problem: no one knows how to
use massive amounts of computing power. The old paradigms just don't
make sense anymore if you have billions of hardware actors (in the
Hewitt sense) following quadrillions of scripts.
-------
∂13-Mar-82 1000 AVB software releases
∂11-Mar-82 2114 WALKER at Cmu-20c software releases
Date: 11 Mar 1982 2229-EST
From: WALKER at Cmu-20c
To: works at Mit-Ai
Subject: software releases
Message-ID: <820210222926WALKER@CMU-20C>
Via: Mit-Ai; 11 Mar 82 23:29-EDT
Via: Brl-Bmd; 11 Mar 82 23:31-EDT
Software releases will only be different in the future in that there will
be many more machines, and any individual one may not have a boot device.
Things that will continue to have releases are all the standard computer
company software, such as OS, compilers, DBMS, etc. Obviously these
must be backward compatible with applications packages. So what's new?
As long as the interfaces are compatible, there will be no problem.
As to the physical mechanism for distributing software, it can follow
the old style of sending a new tape or floppy. This would be mounted
on an individual machine, or on a network server and then boot over
the net. The CMU VAXs already do this since 12 VAXs share 2 tape
drives over an Ethernet.
The other obvious alternative is simply to ship the new software via
network. Berkeley is hooked to our VAXs. So is DEC. In principle,
all new software releases could be shipped via ARPAnet and Ethernet.
I simply haven't heard anything that makes me think that selling
and servicing software will be any different (except as mentioned
above) than it is now. Remember that large machines already have
the capability for remote diagnosis via the phone of hardware and
software problems while the machine is up and running.
--------
∂13-Mar-82 1001 AVB A minor point...
∂12-Mar-82 0027 William ''Chops'' Westfield <BillW@Sri-Kl> A minor point...
Date: 11 Mar 1982 2343-PST
Sender: BILLW at Sri-Kl
Subject: A minor point...
From: William "Chops" Westfield <BillW@Sri-Kl>
To: WorkS at BRL
Message-ID: <[SRI-KL]11-Mar-82 23:43:39.BILLW>
Via: Sri-Kl; 12 Mar 82 2:55-EDT
I would like to ponit out that new micro-processors are being
anounced at a rate of greater than one per year. If you want
your workstation to be able to use state of the art technology,
you have to be able to put an operating system on it pretty
quickly. This means that it should be written in a relatively
high level language, wit a minimum of machine code necessary
for each processor. Right now, this means UNIX, I think.
Maybe in a little while it will include SmallTalk and others...
WW
∂17-Mar-82 1139 AVB WORKS Digest V2 #24
∂16-Mar-82 2037 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #24
Date: 16 Mar 1982 2253-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #24
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Tuesday, 16 Mar 1982 Volume 2 : Issue 24
Today's Topics: Administrivia
Someone's Theory
Modems vs Transceivers
Ethernet Doomed?
Your first language
UNIX & Workstations & Networking
UNIX & "the" Answer
C third worst?
Opinions & Biases
----------------------------------------------------------------------
Date: Monday, 15 March 1982 20:46-PST
From: Jonathan Alan Solomon <JSOL at ECLC>
Subject: Administrivia - Out with the old - In with the new
I wish to take this opportunity to note that we have gone back to the
digest form of publication for all readers. Unfortunately, due to load
restrictions and the extreme volume of mail WorkS has generated, it
has simply become impossible to distribute the information fast enough
to all readers in the short time before the next response is ready to
be sent. I hope you will understand that it is for the good of all
that WorkS not interfere with the normal operation of the ARPANet, and
that it continue to maintain a "secondary" status to the important
business which is conducted on the Net.
When I started to offer immediate redistribution and digestification,
I was hoping that the list would no longer require as much time as I
was spending on it. The fact was that I spent more time on WorkS than
I had ever before done, since the volume of mail had increased quite
so much and it was hard for me to keep the digests up to date with the
discussion. Additionally, some of the traffic had little to nothing to
do with WorkS. It was my responsibility to insure that such
discussions were channeled to the proper mailing list. One example of
this was the complaints about the message header. This type of
complaint should have gone to WorkS-Request. Normally I would have
caught them before publishing a digest.
The simple fact is that I don't have the time anymore to handle the
traffic of 2 digests, 4 direct mailing lists, and the brunt of mailing
list maintainence across the ARPAnet. Unfortunately since I do this au
gratis, and I don't get paid to do it, I can't let it interfere with
the work which I do here at ECL, which I do get paid for. I am now
forced to take the less popular alternative (to me) which is to give
up moderation of the list. Therefore I am officially resigning my
place as moderator of WorkS.
I'm not going completely away, I will remain on the sidelines to
advise and to help maintain the list, along with our new moderator,
Mel Pleasant. Mel is a good friend of mine, someone who I can trust to
keep the discussion hearty and healthful, and I am sure that he will
do a fine job moderating the WorkStation discussion. Mel is a systems
programmer at Rutgers, and had always had an interest in WorkS, so it
seemed only natural for him to moderate it. Please help me welcome him
to the WorkS community.
Good Luck Mel!
******
*JSol*
******
------------------------------
Date: 12 Mar 82 2:10:19-EST (Fri)
From: Michael Muuss <mike@Brl-Bmd>
To: Mike O'Dell [system] <mo@Lbl-Unix>
Subject: Re: Someone's Theory
I spent my first half-dozen years programming and hacking on IBM
systems. I like UNIX tons better. Does this mean I'm sick? I wager
that most people on the net who learned computing someplace other than
college probably learned IBM. This may dent the theory somewhat....
By the way, I would like to see discussion tend to follow the lines of
"what things can we do that give people even more power than
UNIX/TENEX/TOPS-20", rather than re-hash the basicly dead issue of
whether UNIX, TENEX, or TOPS-20 (or even something else) is "best". I
regard the three as being (roughly) functionally equivalent (hackers
everywhere, peace!), differing mostly in smallish details. They all
represent the "best" of the "current" software technology in
ultra-widespread use. So, what's next?
-Mike
------------------------------
Date: Thursday, 11 March 1982 08:45-PST
From: Chris Ryland <Ryland@Sri-Kl>
To: SIRBU at Mit-Mc
cc: Human-Nets at Mit-Ai
Subject: Modems vs Transceivers
Date: Thursday, 11 March 1982 06:02-PST
From: "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC>
I'm sorry, but Ethernet does not reguire a MODEM, it requires a
TRANSCEIVER. There's a big difference.
Of course there's a difference (and I assumed that any reader of my
message would understand the technical distinction), but not the kind
of difference the article was implying: a naive reader would assume
that there was no need for a cable driver on the Ethernet. A modem
and a transceiver are functionally identical.
... A modem implies RF oscillators and receivers with lots of
filters and other non-digital components. Transceivers,
operating on honest-to-goodness digital signals, not RF tones,
are easier to build.
Not true; rather, people have more experience building transceivers.
This is bound to change: TRW makes chips which allow you to build a
2MHz fixed-channel RF modem with essentially 3 components (rcvr,
xmittr, SDLC chip). Frequency-agile modems are harder, but LSI can
change that, also.
------------------------------
Date: 12 March 1982 03:17-EST
From: Howard I Cannon <HIC@Mit-Mc>
Subject: Ethernet Doomed?
To: BILLW at Sri-Kl
cc: SIRBU at Mit-Mc, Ryland at Sri-Kl, Human-nets at Mit-Ai
I'm not sure how the Ethernet is spec'ed (since I'm at home, and the
documentation is in my desk at work), but the Chaosnet, which is a
CSMA/CD (carrier sense multiple access, with collision detection (did
I get this right?)) ethernet-like network, does something less analog
and in some sense more sneaky to detect collisions: it watches the
cable, and if what's on the cable isn't what it is sending, then a
collision has occured. Since the cable is only actively driven in one
direction, this works nicely. (positive, passive terminators on each
end provide the "pulldown". Just like open-collector TTL, but
reversed.)
The analog electronics in the Chaosnet transceiver have mostly to do
with driving the cable, which is perhaps the most tricky part of any
scheme. By getting this right, you can run at 10 megabaud baseband.
We had to slow the Chaosnet down from 8 to 4 megabits/sec in order to
get more acceptable error rates on our longer runs. I believe the
major problem with 8 megabaud turned out to be that many of the
optical isolators we were using didn't work very well at that speed.
There is no question that ringnets have simpler interfaces to their
cables. One could build a ringnet cable interface out of two
differential parts and do very nicely. Even add optical isolation if
you want for a coupla more chips. But I wouldn't want to try arguing
ringnet vs. ether-like net on that basis alone.
------------------------------
Date: 11 Mar 1982 1819-PST
From: Tom Wadlow <TAW@S1-A>
Subject: Your first language
From: mo at Lbl-Unix (Mike O'Dell [system])
Subject: Someone's Theory
There is a psychological theory, the author of which I can't
remember at the moment, which says the first language you
learn, or become fluent in, dramatically controls the thoughts
you can have.
The first computer language I learned was BASIC, on some obscure
Westinghouse computer. This has not stopped me from appreciating the
good features of LISP, C, Pascal, Forth, Smalltalk, Mesa and others.
To say nothing of UNIX, Tops-20, Multics, WAITS, and other operating
systems too numerous to mention. It has also not kept me from flaming
at great length about the drawbacks of the aforementioned. I don't
wish for the good old days with line numbers and NEXT X statements.
Occasionally, I have met folks who claim that their language is The
Language. They are always wrong. It seems to me that the essence of
good software engineering is to be able to pick the appropriate
language from your repertoire (and, like anything else, the bigger
your repertoire, the better) and to know WHY you picked Language X for
Task Y.
------------------------------
Date: 12 Mar 1982 11:18 PST
From: Deutsch at Parc-Maxc
Subject: Re: UNIX & Workstations & Networking ...
In-reply-to: mike's message of 22 Feb 82 0:15:36-EST (Mon)
To: Michael Muuss <mike@BRL>
A few weeks ago you sent a message to WorkS about a terminal called
the BLIT. I've seen a similar machine from BB&N called the BitGraph.
But it sounds like the BLIT has more functionality, and might even be
expandable to include more memory and/or a hard disk, which in my
opinion are both absolutely necessary for a home computer (which is
what I'm interested in). Can you give me more information about who
designed it, who might market it, where to find out more about it,
etc.?
Uniform network protocols are a must. Unfortunately, TCP/IP is
relatively complicated and (as I understand it) has some features that
run counter to our (the Ethernet world's) philosophy of
packet-switched, best-efforts communication. I guess having some
halfway reasonable standard is better than not having any at all.
Incidentally, I think there is absolutely no excuse in this day and
age for building a workstation "so braindamaged as not to be able to
multi-program". All it takes is some kind of hardware interrupt
system and a tiny bit of multi-process scheduling software. Memory
protection, timers and suchlike are unnecessary. In the mid-1960s
someone I knew at U.C. Berkeley wrote a real-time multi-process
scheduler for a DEC PDP-5 (the precursor of the PDP-8) in about 100
instructions.
P. D.
------------------------------
Date: Thursday, 11 Mar 1982 13:56-PST
To: Joe.Newcomer at Cmu-10a
Subject: Re: Re: UNIX & "the" Answer
In-reply-to: Your message of 11 March 1982 1354-EST (Thursday).
From: mike at Rand-Unix
Dear Joe,
Your message about UNIX has the following semantic content:
UNIX is no good because a) C is "the worst" and b)
because UNIX doesn't call things the way "I'm" used
to, ie it doesn't conform to PDP 6 (and its successors)
terminlogy, so it must be "wrong".
Can we raise the intellectual content of this list a little?
Michael
------------------------------
Date: 12 March 1982 1900-EST (Friday)
From: Joe.Newcomer at Cmu-10a
To: pratt.Shasta at Sumex-Aim
Subject: Re: C third worst?
In-Reply-To: pratt@Shasta@Sumex-Aim's message of 11 Mar 82 18:28-EST
One thing is true of modern languages: you need not restrict yourself
to medium-level control and data strctures, it is possible to build
optimizing compilers which remove the burden of hacking and allow the
user to write the expression which is meant instead of the one which
"generates good code", and although garbage collectors are nice,
explicit allocation/deallocation is not so bad. The major problem I
had with C after using Bliss is that the abstractions I program in
were extremely difficult to write. If you ignore such incidentals as
the completely bogus way "." and "->" introduce a level of
inappropriate concretization of structures, and the inability to write
decent iteration abstractions (the most imnt one I care about), and
the proclivity in every C program I ever looked at to handle string
iteration by wiring in [i++] type notations, and the lack of a
'leave' style construct, the bogus way of doing case statements, and
the general unreadability of the programs because procedure
declarations look like procedure calls and a few dozen other
notational problems, it probably isn't a bad language. However,
having used both Bliss and SAIL, I much prefer those two langauges.
SAIL without a string garbage collector would be a bit of a pain to
use, but I find that I can warp either of those langauges to the
"language" I use in my head (which is neither BLiss nor SAIL, but a
much higher level object-based notation), but with C, the underlying
mechanisms and notations I use cannot even be expressed. Therefore, I
found that I was always writing very concrete code in C, instead of
abstract code, and I always had to be concious of how badly the
compiler was going to translate it, instead of knowing the compiler
would optimize away any rubbish I wrote. It was almost as bad as
writing in assembler in terms of the mind-set I found myself
maintaining. I usually program two or three levels above the
implementation, and use sophisticated macros and knowledge that the
compiler will optimize to defer the detailed implementation. The
change was more than I could bear. Even a preprocessor would not
suffice in the case of C, bewcause some of the primitives I needed
weren't present, and in any case, I couldn't exploit the non-existent
sophisticated optimizer. The only experience I have had worse than
this was with Pascal, which actively goes out of its way to prohibit
me from letting code flow from my head to the target language. For
the curious, the second-worst language is Fortran, which is truly the
assembly code of high-order languages. However, it doesn't actively
prevent me from doing what I want to do, as Pascal does.
joe
------------------------------
Date: 12 March 1982 1917-EST (Friday)
From: Joe.Newcomer at Cmu-10a
To: JGOLDBERGER at Usc-Isib
Subject: Re: Opinions & Biases
In-Reply-To: <[USC-ISIB]11-Mar-82 17:19:30.JGOLDBERGER>
Indeed, no system is perfect. I have a massive file on TOPS-20 in
which I document several dozen major or minor problems with the
system; the major ones usually deal with the fact that the original
computing model was a single user at a model 33 TTY running a single
program (perhaps of multiple processes) on a system possessing one
logical file strucutre (no dismountable packs) working on a single
project. Since none of these conform to what I do every day, I find
serious mismatches between what I need and what TOPS-20 supplies. On
the other hand, for all those things which are within the design
parameters, it does them very well indeed. I agree with your comment
that a complete new rethinking of the fundamental paradigm is
important. The STAR and PERQ/SPICE are starts, but both will need to
be refined as the actual experience with distributed computing is
gained. All workstation projects predicated on this are going in the
right direction.
It is important to separate the Unix user interface from the Unix
kernel. All of my flaming about Unix center primarily on its user
interface. A project which chooses to use the Unix kernel and which
completely redoes the interface might well produce a system which is
hardware independent and superior to TOPS-20 or Unix. Couloris is
arguing that the Unix kernel may not be appropriate; I cannot
participate in that argument because I never explored the fringes of
the kernel enough to find where it broke down from the model of what I
need.
joe
------------------------------
Date: 13 Mar 1982 12:35:28-PST
From: pratt@Shasta at Sumex-Aim
To: Joe.Newcomer@CMU-10A, pratt@Shasta at Sumex-Aim
Subject: Re: C third worst?
I too like to write abstract code. So far I've found that the only
obstacle to this in C has been the absence of garbage collection.
Modulo this problem, I've found myself able to program pretty
abstractly. Of course there's no way to hide the implementation, but
that's a separate issue from being able to program abstractly to begin
with; hiding is more of a personal-security issue, trying to protect
yourself from your own stupidity.
The BIG problem for me is garbage collection. I have no intuitive
feeling, WHEN I PROGRAM ABSTRACTLY, for when to return something. I'm
impressed you are able to do it easily, I should learn the trick. I
find when I try to do it I am working at the low level I was trying to
avoid by programming abstractly. This slows me down, and my error
rate goes up sharply.
Vaughan
------------------------------
End of WorkS Digest
*******************
-------
∂20-Mar-82 1009 AVB WORKS Digest V2 #25
∂18-Mar-82 0026 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #25
Date: 18 Mar 1982 0237-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #25
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Thursday, 18 Mar 1982 Volume 2 : Issue 25
Today's Topics: Administrivia
Opinions & Biases
UNIX on workstations
The Apple Bill
C, Bliss, SAIL
----------------------------------------------------------------------
Date: 18 Mar 1982 0227-EST
From: The Moderator <Pleasant at RUTGERS>
Subject: Administrivia
A system crash and subsequent recovery caused many of you to receive
a second copy of the last digest. I am sorry for the inconvenience
that this might have caused you and will try to prevent it from
happening again in the future.
-Mel
------------------------------
Date: Sunday, 14 Mar 1982 21:22-PST
To: JGOLDBERGER at USC-ISIB
Subject: Re: Opinions & Biases
In-reply-to: Your message of 11 Mar 1982 1719-PST.
<[USC-ISIB]11-Mar-82 17:19:30.JGOLDBERGER>
From: gaines at RAND-UNIX
I find the recent discussion of UNIX rather short of content and long
on opinion. Would those that think UNIX is not a suitable operating
system for workstations be a bit more explicit, please? It would be a
help if the comments actually apply to the operating system part of
UNIX, and not non-supervisory software such as a particular version of
the shell.
------------------------------
Date: 15 Mar 1982 11:32:41-PST
From: cbosg!nscs!rew at Berkeley
The theory you are referring to is known as the Wharfian hypothesis.
Actually, I haven't seen it written out in a while, so I may have the
spelling wrong (might be Warf). Although it has led to a lot of
research and is of perennial interest, there is not much solid support
for it. This would suggest, of course, that the theory would not have
much application to programming languages, either.
Bob Warren
cbosg!nscs!rew
------------------------------
Date: 15 Mar 1982 12:22:07 EST (Mon)
From: decvax!duke!mcnc!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
Subject: UNIX on workstations
I'm not going to claim that UNIX is the ultimate operating system (I
tend to dislike religious arguments), but it does have one very strong
point that many "highly interactive" [sic] systems lack: the ability
to combine existing commands into personalized tools.
If we accept that *no* system designer can satisfy everyone, even
every new user who has never been corrupted by exposure to the old way
of doing things -- and I regard that statement as beyond argument
(*sigh*, another religious statement) -- then we have to provide some
ability to customize the environment in ways not anticipated
before-hand. UNIX does this in several ways; the most important,
though, is the UNIX philosophy: *any* program should be usable as part
of any other.
Now -- I'm not saying I need pipes (though I like them); I'm not even
saying I need output redirection (though things are messy without it).
But I do need *some* way I can, for example, list the names of a bunch
of files, sort them, and then perform some other operation on just
those files -- because you, as the system designer, might not have
anticipated my application.
--Steve Bellovin
------------------------------
Date: 16 Mar 1982 17:25 EST
From: dvorak.WBST at PARC-MAXC
Subject: The Apple Bill
Reply-To: dvorak
Permit me to paraphrase from SCIENCE, Volume 215, 19 March 1982:
Last month Steven Jobs, Apple founder and prez, happened to sit next
to Rep. Pete Stark (D-Calif.) on a jet from California to Washington.
Shortly thereafter, Feb. 23 to be exact, Stark introduced a bill
entitled the Technology Act Education of 1982 that would permit
companies to donate scientific equipment to elementary and secondary
schools and then deduct the full cost of the equipment from its pretax
income--just as companies now do for gifts to colleges. In addition,
the bill raises the maximum such contribution from 10 to 30 percent of
a corporation's income (which is more important for Apple than IBM or
Xerox). Both of these changes from current practice would only last
for one year. This "Apple Bill" is apparently receiving the support
of members representing the entire political spectrum (unlike the
budget).
Oh, I almost forgot . . .
Jobs apparently plans to give EVERY elementary and secondary school in
the country an Apple (configuration not stated). If so permitted,
Apple would enjoy a tax savings of about $35 million for a deduction
of about $75 million that represents manufacturing cost only (total
retail value of $200-300 million). Service costs, software and
training manuals would not be deductible, but something tells me that
Jobs believes there must be some business advantage to having all
future generations of computer users weaned on Apples.
--Chuck
------------------------------
Date: 16 Mar 82 21:31-PDT
From: mclure at SRI-UNIX
Subject: C, Bliss, SAIL
C is best considered as a high-level assembly language for systems
programming, but people are trying to force it into niches where it
doesn't belong, just as for years people have been forcing PASCAL to
be other than a teaching language. Having programmed a great deal in
SAIL, BLISS, and C, I prefer C for systems programming because it just
seems inherently better suited. SAIL is too PL1ish and BLISS just
doesn't seem to have enough, although I did like its value-return
mechanism very much; however I can understand how the other two might
be preferable for higher-level tasks.
Stuart
------------------------------
End of WorkS Digest
*******************
-------
∂20-Mar-82 1010 AVB WORKS Digest V2 #26
∂20-Mar-82 0146 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #26
Date: 20 Mar 1982 0409-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #26
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Saturday, 20 Mar 1982 Volume 2 : Issue 26
Today's Topics:
Whorfian Hypothesis and Programming Languages
Unix Shell
Wang Interconnection Request
Unix on Workstations
----------------------------------------------------------------------
Date: 18 Mar 1982 1016-PST
From: Keith Wescourt
Subject: Re: Whorfian Hypothesis and Programming Languages
Sender: WESCOURT at RAND-AI
Reply-To: Wescourt at RAND-AI
In-Reply-To: Your message of 17-Mar-82 2337-PST
The "Whorfian Hypothesis" (named after Benjamin Whorf), stated
briefly, is that one's native language determines (to at least some
extent) one's primitive perceptual and conceptual categories-- i.e.,
linguistic structure determines the structure of thought processes.
The contrary view is that all human languages have a structure
determined or limited by universal (presumably genetically programmed)
primitives of thought. It's one of those "chicken-and-egg" issues and
has been studied by cultural anthropologists for decades.
I think the Whorfian Hypothesis has little or no bearing on the issue
of how one's first programming language instills biases that affect
one's subsequent learning and/or appreciation of other programming
languages. More "mundane" psychological theories of learning and of
social psychology are more relevant to the phenomena.
------------------------------
Date: 18 Mar 1982 14:12:43-PST
From: decvax!shannon at Berkeley
Subject: Unix shell
One major difference between TOPS-20 and Unix is that on TOPS-20 I
felt a compulsion to rewrite the EXEC because it was so bad, but never
had the time to engage in the compulsion. I would like to do a few
tweaks on the Unix shell which has its own problems, but they are not
a major departure from the basic philosophy of the Unix shell. In the
case of TOPS-20, I would never have considered using the EXEC code at
all, except possibly to see how some bizarre interface to the monitor
was done. It is such a poor piece of interface that I found it a
constant aggravation every time I typed a command.
Some people may recognize the above paragraph. It is based on a
message from Joe Newcomer to WorkS recently. I have simply swapped
Unix and TOPS-20, and shell and EXEC. It now says essentially what I
feel. This is just to show that this is a religious/personal opinion
topic and there is really no point in trying to "resolve" it. As far
as I'm concerned, all the people who don't like Unix (or TOPS-20, or
VMS, or ...) should be encouraged to go off and build something that
they do like. If they build something good it might catch on. If
they build something bad it will probably die a natural death. I'm
not about to leave Unix until someone can offer me a system with
essentially all of it's advantages, some amount of compatibility, and
much more. I'm sure the TOPS-20 users feel the same way.
Bill Shannon
decvax!shannon
DEC UNIX Engineering Group
------------------------------
Date: 19 Mar 1982 (Friday) 1051-PST
From: ATHEY at LLL-MFE
Subject: Wang interconnection request
cc: ATHEY
Does anyone have any experience with connecting WANGs to networks and
transfering data and control information to other types of machines?
We are planning on doing this at LLNL and I would appreciate any
information that you could supply me with.
Chuck Athey
∂22-Mar-82 0820 AVB WORKS Digest V2 #27
∂21-Mar-82 1853 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #27
Date: 21 Mar 1982 2036-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #27
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Sunday, 21 Mar 1982 Volume 2 : Issue 27
Today's Topics:
The Seventh West Coast Computer Faire
----------------------------------------------------------------------
Date: 21 Mar 1982 1053-PST
From: Jeffrey at OFFICE
Subject: 7th WCCF
To: pipes at PARC-MAXC, sweer at SUMEX-AIM, bnh at MIT-AI,
To: badob at MIT-AI, info-cpm at MIT-MC, w8sdz at MIT-MC
Random Faire Impressions
The Seventh West Coast Computer Faire
19-21 March 1982, San Francisco
A great deal of silicon has passed through the furnace
since last April. We all watched as Xerox and IBM gave
instant credibility to what was heretofore a newcomer's
game. A moment later, everyone was talking about
workstations with vast amounts of computing power,
sophisticated operating systems, high resolution graphics,
and enough mass storage to keep most people happy until
1984.
What a year. The only area which hasn't far exceeded my
expectations is local networking.
The year has also been a very busy year for me personally.
I haven't quite caught up to where I was a few months ago.
One result of this constant state of behindness is that I'm
not able to cover the Faire as well as I'd like. In
advance, let me say that the coverage here is of a cursory
nature. One area where I definitely should have spent more
time is software applications. This is where the Faire
excels and where I didn't spend nearly enough time
looking.
This Year's Faire
Last year was my first visit to a Faire. I spent two whole days
wandering, laughing, and generally trying to keep my eyes positioned
interior to my skull.
This year, I did the whole thing in one day. I suppose there weren't
so many surprises because I've kept up with things and because there
just weren't so many surprises. The Faire is a lot of fun, but it
isn't where the big equipment manufacturers care to display their
goods. Of the the big three (Apple, Tandy, IBM), only Tandy
represented itself directly. Sure - there were ooddles of Apples and
IBM PC's, but neither of Apple nor IBM had a booth. Strange, IBM was
present last year when all they could bring was a bulky 5120 box. I
suppose they were testing the water.
It seems to me that this year's Faire was a little better organized
and a little more serious than last year's. My impression is that
last year, many of the exhibitors were hoping to attract hobbyists as
well as businessmen. This year, everyone seemed somewhat more
business oriented. The tools (both software and hardware) are well
worth the investment in business environments. I think this has
become clear during 1981.
Silicon Valley sage, Bill Murray, thinks that Faire organizer Jim
Warren will always keep the Faire light hearted and fun. "If it
isn't going to be fun" says Bill, "you might as well go to NCC".
I missed the kids selling time on plywood Invader boxes.
Fortune
Fortune had two machines on the floor. They were identical and
consisted of a 68000 processor (6 Mhz), 256k RAM, a neat display and
keyboard, a 5mb winchester, and a 5.25" 800kb floppy. The floppy and
winchester are mounted in the main chassis along with the
electronics. The screen sits on top of this chassis and the keyboard
is separate. The appearance of the system is generally similar to
that of the IBM PC; the Fortune will take up a little more table
space.
I was quoted three prices for the configuration: $8700, $9000, and
$9500. Your guess is as good as mine. Fortune's smallest
configuration will cost $4995 and will for that price you'll get one
floppy plus 128k RAM.
Fortune's system is an honest Unix. It is fully interrupt driven and
does support multiple concurrent processes. In addition to the
regular Unix utilities, Fortune demonstrated Multiplan and FOR:WORD,
a word processing system.
Multiplan is a Visiclone which is probably going to make quite a few
people happy. Its easy to use and has facilities for cross-linking
data between different reports (something which VisiCalc doesn't yet
do). Even I could imagine using Multiplan - something which I could
never say about brand X.
I suspect that Fortune's word processing package is going to be a big
drawing point. FOR:WORD is a detailed copy of the Wang word
processing system ("with 31 extensions"). It looks powerful and yet,
easy to learn. Some of this power and simplicity stems from
consistent use of special purpose keys. Fortune has provided a
generous number function keys to avoid dependence on multiple key
inputs (a'la control characters). Under the function key row is a
plastic label strip which may be changed to fit a particular
application. The strip I saw was printed to go with FOR:WORD.
Someone had crayoned a Multiplan legend on the reverse side.
Fortune will charge about $500 for FOR:WORD and about the same for
Multiplan - as the salesman put it "microcomputer software prices".
The Fortune system was said to be of the multi-user variety (up to
13). I found it interesting that both of the display systems were
configured for but a single user.
CP/M and other Rarities
Well, I have to admit that I think Digital Research has blown it. I
don't see a place for 16-bit CP/M or its ilk between MS-DOS (the IBM
PC system) and Unix. I discussed this question with Mr. Lehman, the
head of MT systems which was recently acquired by DRI. Being a
gentleman of upstanding character, he stood behind his new outfit.
But the arguments were weak (Unix isn't secure and reliable enough
for commercial applications; MS-DOS will never be multi-user).
However, for me two of the Faire's most interesting revelations came
from the CP/M world. Godbout demonstrated an MP/M-86 system running
on his dual processor 8088/8085 board. The system was basically
MP/M-86, but whenever any of the multiple concurrent users invoked an
8085 program, the system correctly uses the 8085 to run that
program. Thus at any moment, some users may be running 8086 programs
and others 8085 programs. Pretty fancy.
Digital Research itself, demonstrated concurrent CP/M-86 on the IBM
Display-Writer. Concurrent CP/M enables a single terminal to operate
several tasks. The operator can switch the terminal between the
tasks simply by keying control-1 for the first task, control-2 for
the second and so on. Each time the terminal is switched to a task,
the CRT displays what you would have seen if the CRT had always been
attached to the task. It was all very natural and nice.
Digital Research has some sort of arrangement with Hitachi to develop
CP/M for the 68000. I'm not sure if Hitachi is developing the code or
if DRI is developing the code for some Hitachi hardware. Lehman and
I discussed the possible utility of such a system. Again, I don't
imagine it will cause a major revolution in computing.
The Great MicroFazer
Watch out multitasking, here comes MicroFazer! MicroFazer is a little
box (.75x3.5x2 inches) which you plug between your printer cable and
your your Centronics style printer. It contains 64k RAM which are
loaded at 3000-4000 characters per second. When you go to print, the
box gobbles up your characters in a few seconds and your CPU is free
for other work. The box passes the characters to your printer as
fast as the printer will accept them.
The only hitch comes if you decide you really don't want to print
that big file. Then you must reach over and reset the box (a
micro-switch is provided for this purpose).
The box retails for $299. You need to feed it 9 volts which can come
from the printer or from a calculator transformer (external plug
provided).
If 64k isn't enough, then you can attach two MicroFazers in series.
Pity you if you change your mind after loading up both to print.
You'll have to reset two buttons.
MicroFazers will be sold through computer stores. They are
manufactured by the Quadram Corporation, 4357 Park Drive, Norcross,
Georgia 30093.
Onyx's Dance
Onyx Systems (who have installed about 600 Z8000-based Unix systems
to date) had their 8-bit Sundance box out to stroll. Sundance looks
like a VT-100 but contains a Z80, a 6.7mb winchester, and a 10mb 1/4"
tape drive. It all fits in a box that is about the size of a VT-100.
I believe the single unit price is close to $8500.
As usual, Onyx refuses to admit support for floppies. How do you
import software?
Applications
Two application packages caught my eye. They are both color graphic
oriented and both run on Apples. I never cease to be amazed at the
quality, speed, and variety of the color graphics which can be
generated by that terrible little box.
Island Graphics showed a graphics design package which can be used to
create color graphic pictures on monitor. The system includes a
graphics tablet with pen and an Apple with color monitor. The artist
draws the picture on the tablet and the system reproduces the image
on the color display. The artist can use a variety of "pens" and
colors, and can cause geometric shapes of varying sizes to be added
at any point.
While the artist is drawing, the monitor shows the image being
created. If the artist wants to change the pen or color, add a form,
save the image, or perform any other control function, the keyboard
is used. The monitor then temporarily displays a graphic image of
all available options. The options are selected by moving the cursor
to the option on the monitor and depressing an appropriate key.
The package can be used to create posters, charts, or just about any
color image you'd like. Although there was no printer at the demo,
I'm sure one of the color printers (e.g. the Prism from IDS) could be
used to print images directly from the monitor.
I didn't ascertain the price of the package but it probably isn't
more than a few hundred dollars in addition to the hardware. A
company called Via Video offers the same sort of package on a more
expensive micro with a display of higher resolution than that of the
Apple. Via Video's package is substantially more expensive but is
potentially useful to professional graphic artists.
I don't think the resolution of the Apple color monitor is good
enough for professional work. Island Graphics' product is
nonetheless, very impressive. Is it reason enough to bite the Apple?
Nope, but each one of these Apple things makes that unit look
better.
Graphics Magic is another Apple color graphics tool which enables
software developers to create games or most any display oriented
application without all the fuss and muss. Its actually just a set
of routines which can create and manipulate color graphic displays.
One of the most impressive demonstrations of the package's capability
is a little show that takes about 20 seconds. The screen starts out
black and then dots of color emerge at random places. These dots
grow into small shapes of varying size, color, and outline.
Everything is random and everything is moving too fast for this be an
Apple. The little shapes (there must be about 25 of them) fly
randomly about the screen for a few seconds and then coalesce into
two rows of large color script letters which say "Graphics Magic".
And magic it is.
Altos
Conspicuously absent was Altos' ACS8600 Unix system. If they succeed
with this product, it will be the first (and possibly the only)
8086-based Unix system. The Altos rep said the system was "almost
ready".
I understand that Altos has added many chips to the 8086 board in
order to make Unix possible.
Japan Microcomputer Club
Japan Microcomputer Club has visited the WCCF since its first show in
1977. This year, their booth didn't look much different than last
year. The beautiful BMC all-in-one color graphic system was again
center stage (the last time I saw one of these was at the Faire last
year). Again, SHARP's small black and white graphic box was on the
table. I wonder where all the 8088/8086 systems are.
Unix for the PC?
Quantum Software Systems, a Canadian firm with an office in San Jose
showed Qunix, a Unix-like system running on the IBM PC. Qunix is
multi-tasking and sells for a mere $150.
The developer claims that most Unix C codes will port to Qunix with
just a few mechanical source changes. I guess this is the sort of
thing that can be verified fairly easily.
Where Quantum treads, can Microsoft be far behind?
Tandy
Tandy was there, occupying the very same piece of Brooks Hall which
they had last year. They had one of their Model-16 computers, but it
was to look at only - no software. Actually, it was running some
sort of display driver which produced some very unimpressive low
resolution slow moving pictures. If it had been me, I would have
left the power off. I asked about Unix for the Model-16 and got a
rather consistent "no comment". They really didn't want to talk
about it.
Sorry Folks - The Show Deserves Better
The show deserves more time and more coverage. I'd guess that about
half of the floorspace was dedicated to software. Most of the
software was of the application variety upon which I have barely
touched. Maybe next year.
Jeffrey Stone
20 March 1982
------------------------------
End of WorkS Digest
*******************
-------
∂22-Mar-82 2216 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #28
Date: 23 Mar 1982 0028-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #28
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Tuesday, 23 Mar 1982 Volume 2 : Issue 28
Today's Topics:
Whorfian Hypothesis and Programming Languages
Specialized Network Automatic Processors
----------------------------------------------------------------------
Date: 20-Mar-82 2250-EST
From: Stephen Slade <Slade at YALE>
Subject: Re: Whorfian Hypothesis and Programming Languages
The "Whorfian Hypothesis" (named after Benjamin Whorf), stated
briefly, is that one's native language determines (to at least
some extent) one's primitive perceptual and conceptual
categories-- i.e., linguistic structure determines the structure
of thought processes. The contrary view is that all human
languages have a structure determined or limited by universal
(presumably genetically programmed) primitives of thought. It's
one of those "chicken-and-egg" issues and has been studied by
cultural anthropologists for decades.
I think the Whorfian Hypothesis has little or no bearing on the
issue of how one's first programming language instills biases
that affect one's subsequent learning and/or appreciation of
other programming languages. More "mundane" psychological
theories of learning and of social psychology are more relevant
to the phenomena.
(Wescourt at RAND-AI, 18 Mar 1982)
Whorf studied American Indian languages, such as Hopi, and noted that
they often embody a naive physics quite different from western
thought, e.g., different notions of time would be reflected in unusual
tense structures. He conjectured that (a) native speakers of those
languages would necessarily view the universe the way those languages
framed it, and (b) non-native speakers would would find the concepts
illusory, at best, or perhaps incomprehensible. A common anecdote in
support of this position is that Eskimos have a dozen or more words
for "snow", while in English, we have only one -- you guessed it --
"snow".
A version of the rebuttal to Whorf suggests that one's language is a
reflection of one's view of the world in that it must communicate the
important concepts one has about the world. Thus, Eskimos must be
able to distinguish among freshly-fallen-snow and
hard-packed-snow-suitable-for-mushing-into-town, and
snow-that's-ok-for-flash-freezing-the-walrus-meat, and other types.
Now, English does in fact have multiple terms for snow, as skiers
should be aware, and English achieves this through its great
extensibility. One can create new terms explicitly ("slush"), or
modify old ones (as above) or use an old word in a new context, e.g.,
figurative speech ("John scored an ounce of snow.").
One may apply this argument to programming languages as follows: The
model is one of "machine as agent" and the programming languages
should facilitate one's communication with the machine. Just as
natural languages do not predestine the subject of discourse (Whorf
perhaps to the contrary), neither should programming languages limit
the concepts one can communicate to the machine.
Natural languages seem to display a conceptual homogeneity, reflecting
the concepts in the world, that apparently exceeds the conceptual
intersection among programming languages. While most concepts may be
communicated equally well in a dozen different natural languages
(again, rejecting Whorf), there are many significant programs that
cannot be implemented in a dozen arbitrary programming languages.
So the question is not really "Does your first programming language
determine how you view programming?", but "Does your nth programming
language provide the features necessary for the task at hand?" As in
English, extensibility in programming languages, such as LISP, is a
real benefit in this regard, however it is not sufficient. There are
real practical considerations involved in programming languages of
which there are correlates in natural languages: you may be able to
express your thoughts quite fluently in English, but that may not help
if you are talking with someone who speaks only Chinese.
-- Stephen Slade
------------------------------
Date: 22 Mar 1982 (Monday) 0833-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: SNAP's
Does anyone have strong feelings for or against SNAPs? Specialized
Network Automatic Processors? The idea is to have some special
(different that Personal Workstations) processors on a network doing
Network functions.
I would group GateWays, Network-controllers and things like
Mail-Pumps, Mail-Servers, Number-Crunchers, and IO processors
(magtape, ...) in this category. How should one percieve such devices
in the environment?
Should Software packages look the same way as well?
Henry Dreifus
------------------------------
End of WorkS Digest
*******************
-------
∂23-Mar-82 2212 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #29
Date: 24 Mar 1982 0024-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #29
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Wednesday, 24 Mar 1982 Volume 2 : Issue 29
Today's Topics: Whorfian Hypothesis
The Seventh West Coast Computer Faire
Special Network Devices
Network Servers in Lans
----------------------------------------------------------------------
Date: 22 Mar 1982 21:57:00-PST
From: alice!rabbit!mitch at Berkeley
Subject: Whorfian hypothesis
The hypothesis that the grammatical form of language affects one's
conceptual structure is due to Benjamin Lee Whorf. One source for his
theory is Language, Thought, and Reality, Selected Writings of
Benjamin Lee Whorf, published in paperback by MIT Press. Particularly
relevant is the paper "The Relation of Habitual Thought and Behavior
to Language" in that volume. While quite interesting, there is little
evidence he's right.
------------------------------
Date: 23 March 1982 06:00-EST
From: Jerry E. Pournelle <POURNE at MIT-MC>
Subject: 7th WCCF
To: Jeffrey at OFFICE-2
cc: W8SDZ at MIT-MC, bnh at MIT-AI, badob at MIT-AI,
pipes at PARC-MAXC, sweer at SUMEX-AIM
My impression of the Faire after three days was "consolidation
rather than bold advances." Godbout is coming up with nice stuff real
soon now, as are others, but nothing big has happened just yet. The
Z-8000 looks dead, and there's so much support for the 8086/8088
family that the emergence of teh 68000 cannot blow it out of the
water--although the 8088 etc cannot kill off the 680000 either.
There were two 68000 systems, but the SAGE uses SCUD PASCAL as
the operating system and will have unix Real Soon now. I cannot agree
about Digital research going away; I suspect CP/M is about to take
another quantum leap, actually, as they get translators to bring
things up from 8-bit to 16 bit saystems.
It was an interesting faire, and I wrote about it all day today for an
article, so I think I'll stop...
JEP
------------------------------
Date: 23 March 1982 1008-EST
From: Hank Walker at CMU-10A
Subject: special network devices
If visible at all, they should probably be logical devices. The fact
that they are local or not is irrelevant. A tape drive might look
like part of the file system, and be invisible, at least for some
things. Gateways, mail servers, etc seem naturally invisible. Number
crunchers are probably visible. It does matter whether you want your
job to run for a week on your processor or a minute on the Cray-1.
But again, they should look like they are local. One means is logical
devices, which sort of works now on VMS anyway (with DECnet Phase III).
------------------------------
Date: Tue, 23 Mar 82 13:08:44 EST
From: chilenskas at CCA-VMS
Subject: NETWORK SERVERS IN LANS
I suspect that in many larger networks some form of network
server would be useful. As an example, consider the MAIL task. If i
am sending a message to some workstation that station could be
unavailable for a number of reasons. It could be under repair, shut
off for the evening, busy shipping a large file along the cable (io
busy) or have too many processes running servicing the user's current
needs to allow the mail receiving program to initiate (cpu busy). In
fact, it could take quite a while for both workstations to be able to
communicate simultaneously, especially if the message is going between
shifts or sections of a staggered short work week. Thus a mail
server/spooler is useful to grab the message and wait for the
recipient to come back up. Even if you do not buy the argument that
it might take a long time for both stations to be up together, you
still don't want to dedicate a task to waiting to send the message or
continually poll the down station in your own workstation.
Spooling is obviously desirable in some other cases as well.
One would be managing the queue for the DOVER or whatever high quality
printer is available for large output.
Other non-spooling functions could be handled as well. An
archive manager might also help after the system is in place long
enough. A separate station or two gathering statistics on network
load and performance would help tuning and detecting bottlenecks. In
high security environments you might want a snoop of some sort. There
are high speed, shared peripherals to manage. etc.....
R Mark Chilenskas
Chilenskas@CCA-VMS
------------------------------
End of WorkS Digest
*******************
-------
∂24-Mar-82 2318 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #30
Date: 25 Mar 1982 0041-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #30
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Thursday, 25 Mar 1982 Volume 2 : Issue 30
Today's Topics: Words for Snow
More on UNIX . . .
Programming Languages and Whorf
Software Wish List
First languages and Whorf
BELL BLIT
----------------------------------------------------------------------
Date: 23 March 1982 21:13 est
From: SSteinberg.SoftArts at MIT-MULTICS
Subject: words for snow
Sender: COMSAT.SoftArts at MIT-MULTICS
*from: SAS (Seth A. Steinberg)
Words which quickly come to mind include: snow, powder, slush, frost,
a dusting, .... I'm sure I could jack this up by looking in a
thesaurus or a skiing guide but English has lots of words for snow.
There was an interesting book review in Science a week ago. There is
a culture (the Vai) in Africa in which three writing systems live side
by side. There is the native Vai system, the Arabic (the religious
language), and English (the administrative and scholastic langauge)
system. Vai script is taught informally, usually by a friend, and is
learned in a few days or so. Arabic is taught in religious schools
and is heavy on memorizing the Koran. English is taught in the
schools and is usually part of a general Western style education which
includes mathematics, science, history, and what not.
Needless to say. Men who could write Arabic had really good memories
and the English writers did better than most on SAT/IQ type tests.
People who could write did better than people at large. The
impression I got (from reading the book review) is that the
researchers felt that alphabetic literacy did not engender major
changes in thought patterns, but rather that new thought patterns
could be taught along with an alphabetic system.
(I should probably read the book but ... )
------------------------------
Date: 23 Mar 1982 2259-PST
Sender: RENTSCH at USC-ECL
Subject: More on UNIX . . .
From: RENTSCH at USC-ECL
Message-ID: <[USC-ECL]23-Mar-82 22:59:20.RENTSCH>
The arguments for Unix are that it is available, widely used, readily
transportable, and has (and will have) lots of software available.
These same things could be said of FORTRAN in 1970. Not only that, in
1970 FORTRAN was 13 years old; Unix is now 13 years old. Let's hope
the analogy stops here and doesn't extend into the future.
I don't want to enter the arena of religious debate. It's not that
Unix is evil; it's dated. And it's a pretty poor match for the
workstation environment. Unix is a timesharing system for a
minicomputer. I want MY personal computer to be more powerful than a
mini, and the last thing I want to do on that personal computer is
timeshare.
Unix's shortcomings for the workstation environment are clearly
evident by looking at what it does and does not provide. It does
provide C, which is a great language for hacking around. It does not
provide adequate type checking, nor is there any support for
"programming in the large." C does provide a terse solution for many
typical program fragments. It does not provide clearly readable code
(declarations are particularly offending here). Unix does provide
hardware independence. It does not provide hardware independence for
devices which don't fit the byte stream model, like a mouse and bitmap
display, to name two important examples. Unix does provide a
replacable command processor, which is therefore tailorable within the
command byte string model. It does not provide a framework for a user
interface that follows a different paradigm, e.g., modeless
window-object based.
The siren call of instant availability is luring us to repeat the
FORTRAN disaster. We can save paying N dollars now only at the cost
of 10*N dollars later. Not only that, as the cost of conversion
increases as time goes on, so will the pain and correspondingly the
reticence of people to convert.
The prospect of putting off getting something running on your very own
personal workstation is, I'm sure, unbearable to some. But take just
a slightly longer view. I'd rather wait six months for a Mercedes
Benz than have a Ford today, even if that means I get my choice of 43
different new Fords in a year from now. All the arguments I have
heard agree that Unix is no panacea, and that the switch will have to
be made. The question is whether it should be made before there is a
big investment in Unix software or after. Seen in this light, the
answer is much clearer. And don't kid yourself that the change can be
made "evolutionarily." It hasn't been done yet in the software world.
Remember the lesson of FORTRAN, and remember this: those who do not
learn from the mistakes of history are doomed to repeat them.
One final note. The reluctance of people to switch from Unix is
perfectly understandable in view of the large personal investment.
Learning a new system is a serious matter, and one not to be
undertaken lightly. But undertaken it will be, so would you rather do
it now and get it over with or wait until you have learned even more
Unix reflexes? Come on, you Unix people, come out of your shell; it
won't be as bad as you think.
------------------------------
Date: 23 Mar 1982 2336-PST
Sender: RENTSCH at USC-ECL
Subject: Programming Languages and Whorf
From: RENTSCH at USC-ECL
Message-ID: <[USC-ECL]23-Mar-82 23:36:51.RENTSCH>
While the Whorfian hypothesis does seem to apply to programming
languages as well as natural language, what is really being talked
about is something else. I thought it was well known (I see I was in
error) that the FIRST programming language that a person learns
strongly casts, or sets, his ideas about programming. The experiment
that was done (and I have no idea of the reference) was to compare
people who first learned one language, say A, then another, B, to
people who learned them in the order B then A. Other studies have
been, with the conclusion that the first impressions one gets
programming (i.e., the "programming language") strongly influence how
one views programming from then on, and is remarkably strong even in
the face of learning very different programming systems. This
apparently can be overcome, but it is easy to underestimate.
In my personal experience, this explains (at least partly) why I
didn't particularly take to LISP, which I learned as a third or fourth
programming system. I hope I am not just being vain when I say I have
broken the set of my first programming language, which was FORTRAN.
In this respect I have been lucky (I guess) in that FORTRAN is so bad
that it must be given up completely, thus forcing me to very carefully
examine what it is that makes a good programming language. Pity the
people who learned an intermediate language like Pascal, which has
some good ideas but is definitely not current in terms of programming
language design. These people will have a hard time giving up their
set for something truly better, for their tendency will be to simply
"fix up" the problems in pascal, overlooking the important change of
shifting paradigms.
------------------------------
Date: 23 Mar 1982 2343-PST
Sender: RENTSCH at USC-ECL
Subject: Software wish list
From: RENTSCH at USC-ECL
Message-ID: <[USC-ECL]23-Mar-82 23:43:28.RENTSCH>
I applaud the suggestion that people on Works identify their desires
for workstation software (without being particular as to which system
supplies them, if any.) My contribution follows.
What do I want in personal workstation software? My wish list:
1) A really good editor. And I mean REALLY good. This deserves more
comment, but at least it should make good, full use of the mouse and
bitmap display (with windows and real fonts, no more of this fixed
width or helvetica junk). I spend most of my time editing in one
guise or another, so let's please have one excellent editor that is
used for editing in ALL of its guises.
2) Pleasant user interface. By this I mean one that I don't have to
wrestle with to get things done. Definitely modeless. Certainly
including windows and completely integrated into the whole system
design, see next.
3) Integrated system. A good synthesis of programming language,
database manager, and graphic software can take the place of (the now
outmoded concept of) an operating system.
4) Programmable in the extreme. The system should be programmable as
much as the user wants to program, but without the usual drawbacks of
having to to sixteen different kinds of programming. This relates
also to point 3, and implies removing some distinctions: the
distinction between system code and user code, the distinction between
interface language and programming language, the distinction between
built in things and added on things. The system should be written in
one programming language which defines the system and therefore the
programming language, which should be the same as the interface
language, which should be the same as the editing language, etc.
5) Storage allocation and memory management. A must. Not that I
would choose it, but a clever software scheme can help overcome the
hardware limitation of small virtual address. However, this is only
true if the memory mapping and allocation is entirely done by the
supplied mechanism; the temptation, as well as the need, to supply
your own should be zero.
6) Incremental compilation. Probably this means dynamic binding, but
what I really want to recompile only those things that have changed
since last the task was done.
7) Interruptible activities. The classic edit, compile, debug cycle
is not only out of style, it's out of the question. Besides being
modeless in the small the system should be not modeful in the large,
i.e., an activity should be interruptible to resume another activity
at the whim of the user.
8) Good programming support. This is a whole raft of things, such as
type checking (not necessarily in the Pascal sense), large scale
programming support, strong implementation of contemporary programming
language, good symbolic debugger, program assisting editor, etc.
9) Good metaphor for interprocess (or interprocessor) communication.
This is rather vague, I admit, but our understanding in this area is
still very limited. Parallel to the communication needs are
synchronization needs, the two go hand in hand. The important thing
here is that as much as possible the distinction between local/remote
communication should be removed. [Reply to George Coulouris' comment:
CSP may be the right model, but I prefer the weaker suggestion here
only that the two be the same. More thought as to the fundamental
nature of the issues seems warranted. If by CSP you mean as in C. A.
R. Hoare, I disagree, CSP in this sense is too much of a straight
jacket; in defense of CSP, however, I have no better suggestion.]
10) Simplicity. Too many systems have been built with the idea that
problems could be solved one at a time by adding a gizmo that takes
care of that one problem. Really good solutions inquire as to the
nature of the kinds of problems they will encounter, then combine a
few simple ideas for an elegant solution to all of them. Let's
simplify our ideas rather than complicate them, for a system that will
solve well the problems we run into in the future, not just the ones
we think of today. This way our system will be strong enough to last
a long time, and also be easier to give up when we finally do have to
change.
Tim Rentsch
------------------------------
Date: 24 Mar 82 13:08-PDT
From: rubin at SRI-TSC
Subject: First languages and Whorf
A high-school buddy of mine speaks French, and wants to learn German.
I've cautioned him against it. I told him if he really wanted to
speak German, he should have learned it first; having instead started
with French, he's stuck with French. I asked, do you really want to
speak German like a Frenchman with an American accent? He called me
something with the word "merde" in it, which only proved my point. He
never heard of Whorf.
The Whorfian hypothesis is related to models of brain plasticity. The
human brain is very "plastic" during the first few years of life; this
is the time when the brain's firmware is literally being programmed by
experience and the environment. A classic experiment is to blindfold
a newborn cat for its first several months; this blinds the cat for
the rest of its life by causing atrophy of the visual cortex. With
human infants, the reverse kind of experiment has been performed --
increased stimulation and early teaching of specific skills seems to
promote specific talents. (It is generally supposed that sensory
deprivation in humans would lead to a high incidence of politicians.)
Plasticity diminishes throughout childhood, so only the earliest
experiences influence the mind's "set." Whorf's hypothesis, if true,
can only apply to what infants and toddlers learn. Beyond age 6, even
exposure to Cobol won't prove permanently debilitating (although
surgery might be indicated in later life). But if your 2 year old is
learning to program, well then, maybe you do have something to worry
about.
In a few years the kid will know more than you!
--Darryl
------------------------------
Date: 24 Mar 1982 (Wednesday) 2251-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: BELL BLIT
Does anyone out there know anything about this "workstation" ?
THanks
Hank
------------------------------
End of WorkS Digest
*******************
-------
∂26-Mar-82 2100 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #31
Date: 26 Mar 1982 2309-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #31
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Friday, 26 Mar 1982 Volume 2 : Issue 31
Today's Topics: Administrivia
CMU VLSI proceedings
Productivity Survey
Ted Nelson is alive and well and living in Texas
Software wish list
More on UNIX . . .
----------------------------------------------------------------------
Date: 26 Mar 1982 2245-EST
From: The Moderator <Pleasant at RUTGERS>
Subject: Administrivia
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
I had hoped that the current discussion concerning languages
and Whorfian theories would somehow wind its way back to workstations
but this has proven not to be the case. I believe that the discussion
itself should continue but should be moved to HumanNets where it
probably belongs.
-Mel
------------------------------
Date: Wed Mar 24 15:02:02 1982
From: decvax!utzoo!henry at Berkeley
Subject: CMU VLSI proceedings
CMU recently ran a conference on VLSI systems, including a paper on
the "Optical Mouse" that I would very much like to see. Does anybody
know how I can get a copy of the proceedings?
------------------------------
Date: 25 Mar 1982 0956-PST
Sender: SAC.ADXCA at USC-ISIE
Subject: Productivity Survey
From: SAC.ADXCA at USC-ISIE
Message-ID: <[USC-ISIE]25-Mar-82 09:56:27.SAC.ADXCA>
Does anyone on the network have some good productivity surveys,
questionnaires or other information that look at the productivity
gains by an organization when that organization installs a local area
network (distributed processing capabilities) with hundreds of
terminals, hardcopy output (including color), and a good data base
management system? The system will have office automation and
managment information system capabilities. If so, please reply back
to SAC.ADXCA at ISIE.
------------------------------
Date: 26 March 1982 02:32-EST
From: Joseph W. Boyle <BOYLE at MIT-AI>
Subject: Ted Nelson is alive and well and living in Texas
To: HUMAN-NETS at MIT-AI
That's right, Ted and several other Xanies are at Datapoint in San
Antonio working on micros and local networking and generally
infiltrating subversive ideas into Datapoint management. They've
expressed interest in getting on the Arpanet; if anyone in that area
can give them an account, send me a message.
The Xanadu project itself is running in Michigan under Roger Gregory.
To find out what's going on or buy a copy of Ted's new book "Literary
Machines" at $15, contact him at:
Box 7615, Ann Arbor MI 48107 (313) 663-3637
Unconfirmed rumor has it that Xanadu is negotiating a $1M deal with
Bell Labs to put up a Xanadu system for filing the mountains of code
and text produced there.
------------------------------
Date: 26 March 1982 20:49-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Software wish list
To: RENTSCH at USC-ECL
When you say "the operating system", do you really mean the "monitor
command reader" (RSX-11M) or the "EXEC" (TENEX/Tops-20) or the "shell"
(Unix)? If you do, then indeed it's time we get away from a
teletype-oriented interface and try more screen-editor-oriented
interfaces. But if you really mean "the operating internals", i.e. the
job scheduler, the memory-manager, the I/O device drivers, the disk
file system, etc. then I beg to disagree. (I assume you mean the
mcr/exec/shell but you didn't make it clear you understood the
difference, and others might not either, so I'm pointing it out.)
------------------------------
Date: 26 Mar 1982 1834-PST
Sender: RENTSCH at USC-ECL
Subject: Re: More on UNIX . . .
From: RENTSCH at USC-ECL
To: REM at MIT-MC
Message-ID: <[USC-ECL]26-Mar-82 18:34:50.RENTSCH>
In-Reply-To: Your message of 26 March 1982 20:12-EST
The question came up as to whether I was willing to give up multiple
processes as implied by my comment about not wanting to timeshare on
my workstation.
Timesharing should not be confused with multiprogramming. Certainly I
want the ability to run concurrent processes, single program operating
systems are more out of date than cars with crank starters. But
timesharing is a whole lot more than just concurrent processing. A
typical timesharing environment includes support for multiple users
and/or terminals, complicated file protection schemes, resource quota
enforcing, inviolable operating system kernel, scheduling policy
enforcement, etc., etc. MY personal computer will be used by one
person, on one "terminal" (bitmap display), with all files belonging
to the one owner. The "quota" on the machines resources is that I
will never use more than 100% of any of them, but I will always want
the ability to use at least that much. I do want the system to help
me protect me from myself, but when I want to override that protection
it should help me do it in a clean way. The scheduling policy that I
set will often have nothing to do with "fairness" or minimizing delay
or maximizing throughput, but it will reflect what I want at the
moment. In short, I want to think of a workstation as personal
property to do with as I see fit, NOT as a resource to be spread among
its users. This notion extends down into the hardware design, see for
example the paper on the Dorado Memory System (Done by B. Lampson at
PARC, I don't have the reference), where he concludes that certain
problems need not be considered on a single user machine.
To give this discussion slightly wider scope, one of the strong points
of Unix (not to pick on Unix, but it serves as an example) is its
hardware independent I/O. That's great if you have 43 different
devices hooked up to your computer all of which match the byte stream
model, teletypes, disks, lineprinters, magtapes, etc. A personal
workstation has ONE device that matches that model, the disk (possibly
also the ethernet, the argument there is weaker). The display and the
mouse and the keyboard are simply not used up to their potential if
forced into the byte stream model. Hardware independence over one
(perhaps two) devices is hardly an advantage worth considering. The
entire timesharing model does not apply to a machine which entirely
belongs to one person.
"A computer with one person using it and another person waiting to use
it is overloaded."
Tim Rentsch
------------------------------
End of WorkS Digest
*******************
-------
∂29-Mar-82 2342 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #34
Date: 30 Mar 1982 0153-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #34
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Tuesday, 30 Mar 1982 Volume 2 : Issue 34
Today's Topics: LISP Availability
The GRiD and Portables
----------------------------------------------------------------------
Date: 28 Mar 82 23:07:17-PST (Sun)
From: kp.HP-Labs at UDel-Relay
Subject: LISP availability
Does anyone have a list of which LISP dialects are available, or
likely to be available soon, on which workstations?
------------------------------
Date: 29 Mar 1982 (Monday) 0826-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: re: Lisp Availability
To: kp.HP-Labs at UDEL-RELAY
There is a lisp-for-Apollo's, being done by a few groups. Try Martin
Griss at Utah or John O'Donnell at Yale. There are "plans" for the
Perq, but I know of no firm committment. There is a D2
processor/workstation available from Xerox corporation, called an
InterLisp Machine, which, does run Inter- Lisp. That is now available
from Xerox. I know of a group doing Lisp for the IBM-PC, but that is
still a not-firm/finalized project.
Henry Dreifus
------------------------------
Date: 29 Mar 1982 0739-PST
From: Jeffrey at OFFICE
Subject: the GRiD and portables
Since first learning of the GRiD last week, I've been trying to
understand its potential - particularly in view of the steep price
tag.
For comparison, I've been imagining a $10000 configuration consisting
of a Fortune 32:16 (including 5mb winchester plus floppy) combined
with a TI 745 bubble memory portable terminal (~ 100k bubble memory
with some editing facilities, thermal printer, keyboard, 300 baud
acoustic coupler, first deliveries ~ 1975, price ~ $2000).
Initially, it seemed like the GRiD just wouldn't be able to compete -
even with added winchesters and floppies. The GRiD would have the
advantage of being somewhat smaller than the TI (although the TI is
quite small and light) and would additionally enable remote use of a
few tools like Gridplan. These advantages would be more than offset
by the advantages of the Fortune+TI system:
- Two terminals, each well suited for its environment. I believe
this to be quite desirable. It would seem reasonable to expect
GRiD to offer a large desktop terminal to stay at home with the
discs.
- Lower price (say $10000 versus probable $13000 for the GRiD with
discs).
As I was "comparing" the two configurations, I began to wonder what
sort of filing system the GRiD would have. If the GRiD's local
permanent store (128k going to 256k going to 1mb) is organized as a
full file system which could "mount" or "dismount" the home base
discs, then things begin to look promising. More practically
speaking, I suspect that the home base would eventually have more
processing power than the portable and it would "mount" and
"dismount" the portable's file system (device).
Either way, the portable would be able to carry whatever software and
data was needed limited only by storage space. The portable's
operating software (OS) should probably be in ROM.
At this point I've obviously stopped comparing and am dreaming. I'd
like to know what sort of software/file organization the GRiD people
really have in mind.
I'd also like to hear ideas on how portables are or can be organizied
to be useful.
Jeffrey Stone
Menlo Park, Ca.
------------------------------
End of WorkS Digest
*******************
-------
∂30-Mar-82 2244 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #35
Date: 31 Mar 1982 0001-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #35
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Wednesday, 31 Mar 1982 Volume 2 : Issue 35
Today's Topics: LISP Availability
Relational Databases on Workstations
Software Wish List (3 msgs)
Grid vs Fortune Plus TI
----------------------------------------------------------------------
Date: 29 Mar 82 22:20:11-PST (Mon)
From: kp.HP-Labs at UDel-Relay
To: dreifu at Wharton-10
Subject: LISP Availability
Thanks for the information. However, I have a few other questions:
1: How efficient (if at all) are the various LISP implementations on
existing workstations, e.g. how does LISP on the Apollo compare with
LISP-machine LISP or with the Xerox D2, or the ISI interlisp on
Vax/750?
2: Several LISP companies have been recently formed, SYMBOLICS, The
LISP company, LISP Machine INC., etc. What kinds of LISPs are they
implementing on what? Does anyone have an idea about the price range
of these LISP based workstations? (I know the SYMBOLICS prices, if you
have to ask you can't afford it kind of prices!).
3: IJCAI 81 reports that interpreted PROLOG is available for the
APPLE. However, since it pages from the floppy it is rather slow. Has
anyone used it to know how slow it is? Does anyone know of PROLOG
being implemented on any workstations?
Thank you,
K. Parsaye.
------------------------------
Date: 29 Mar 82 22:40:08-PST (Mon)
From: kp.HP-Labs at UDel-Relay
Subject: Relational Databases on workstations
Following my question about a list of LISPs available on workstations,
I would also like to ask:
Does anyone have a table of any relational (or E/R) databases
available on workstations in local network environments, e.g. similar
to Xerox's cedar. Moreover, can such queries be directly embedded in
LISP programs, or are they all as awkward as the Ingress/Franz-LISP
situation?
K. Parsaye.
------------------------------
Date: 30 Mar 1982 1432-PST
Sender: RENTSCH at USC-ECL
Subject: Re: Software wish list
From: RENTSCH at USC-ECL
To: REM at MIT-MC
Message-ID: <[USC-ECL]30-Mar-82 14:32:18.RENTSCH>
In-Reply-To: Your message of 26 March 1982 20:49-EST
I had a previous conversation about the subject of whether operating
systems are outmoded that was private, i.e., not published on works.
I have tracked down a copy and reproduce it here for all to see.
[These messages have been divided up so that users reading the digest
with digest software will be able to access the messages one by one -
Mel]
------------------------------
Date: 25 Mar 1982 08:27 PST
From: Lear.es at PARC-MAXC
Subject: Re: Software wish list
In-Reply-To: Your message of 23 Mar 1982 2343-PST
To: RENTSCH at USC-ECL
I agree most enthusiastically with everything you said. I'm afraid,
though, my hackles raised at your statement " ... take the place of
(the now outmoded concept of) an operating system". Before I go to
the whole distribution list, I thought I would ask for clarification
(since I think you just tickled one of my more irrational buttons).
You said:
3) Integrated system. A good synthesis of programming language,
database manager, and graphic software can take the place of
(the now outmoded concept of) an operating system.
By operating system, do you mean the command interpreter, an interface
between the client's program and a system dedicated to managing the
available resources, or a collection of utility programs to manage
resources and provide commonly requested services? I really don't see
how you can call the operating system an outmoded concept.
I have no doubt that a good programming language/database manager is a
sure winner, and, since I find graphics much easier to digest than a
column of numbers, I also think a good graphics system should be
provided.
------------------------------
Sender: RENTSCH at USC-ECL
Subject: Re: Software wish list
From: RENTSCH at USC-ECL
To: Lear.es at PARC-MAXC
Message-ID: <[USC-ECL]25-Mar-82 14:17:57.RENTSCH>
In-Reply-To: Your message of 25 Mar 1982 08:27 PST
This is a difficult point to clear up, since what an OS "is" is not at
all clear. IBM takes a point of view that is pretty all-encompassing,
for example, they include the compilers and loaders (which after all
are completely separate programs) as being part of the "Operating
System." Before we can call an operating system outmoded, we must
have a good idea of just what an operating system is.
I don't have simple explanation of what I think an operating system is
or isn't. OSes came into being pretty much when machines were
starting to be used by multiple people, with the idea of allowing
cooperative sharing of the machines resources. The personal computing
situation is quite a bit different, yet the artifact (which some of
us, me included, are too young ever to have not known) remains. There
is not a piece of a system that I would say definitely is or is not
part of the operating system, that depends on the context on which it
is examined. For example, the command interpreter. On TOPS-10 that
is certainly part of the operating system. What about UNIX shell, is
that part of the UNIX operating system? Other examples are even
fuzzier.
With all the preceding negative talk, you are probably hoping for
something more definte and positive. Here it comes. As to what an
operating system is, let me quote Dan Ingalls:
"An operating system is a collection of things that don't fit into a
language. There shouldn't be one."
This quote is from Dan's excellent article on Design principles behind
Smalltalk, published in BYTE August 1981. Following the quote is an
elaboration of this aphorism, and Dan says it as well as I could hope
to. If, after reading what he has to say, you have more comments or
questions let's talk some more.
Feel free to publish both your message to me and this reply on Works
if you see fit.
------------------------------
Date: 30 Mar 1982 (Tuesday) 1838-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Grid vs Fortune plus TI
I would say a primary strength lies in consistency of interface. That
is, if I want to use the cute Wang-like editor on the Fortune I'd
better be on the Fortune (even attached via TTY link won't give me
full screen editing on a thermal printing terminal). Further, all of
interfaces can take into account the fact that I have a screen, not
paper, so we get menus, windowing, etc.
-Dave
------------------------------
End of WorkS Digest
*******************
-------
∂04-Apr-82 0100 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #38
Date: 4 Apr 1982 0225-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #38
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 4 Apr 1982 Volume 2 : Issue 38
Today's Topics: Lan's to the World
Brave New World? (2 msgs)
----------------------------------------------------------------------
Date: 2 Apr 1982 (Friday) 2010-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: Lan's to the world
Well, I am no expert on TCP/IP, but my first hand view of a Z80
running IP to me seems to indicate that though it may not be a great
protocol, if everyone gets in line to that standard there will exist a
mechanism for getting in and out. Insofar as to management of such an
item, things like name-servers, back-end data servers and all the
other networking issues are somewhat left open.
Discussion along the line of how to approach the connection of a LAN
to the outside world, the way a personal-workstation on a LAN should
"see" this world, and what types of user-interfaces should exist are
all good material for WorkS. TCP/IP specifics are best discussed in
Human-Nets or TCP-IP.
Hank
------------------------------
Date: 2 Apr 1982 (Friday) 2159-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Brave New World?
On the subject of software, several comments; first, it is suprising
how little software people actually need to get 99% of their jobs
done. Your average professional can probably be classed into one of a
handful of groups (information creator, information seeker,
information analyzer etc.) and the needs of most groups are small (one
way of proving this is that most people don't use computers now, so
clearly they don't require them to function). A great number of
professional types can get a great deal of help from a good word
processing package ["what you see is what you get" with all sorts of
goodies like forms a la Scribe and spelling checkers etc.], a good
graphics package (again, user oriented, for business graphics),
electronic mail, electronic filing [keyword if not full text],
administrative software like scheduling programs, ticklers, diaries,
calendars, etc., a very easy to use database manager (relational,
preferably graphic/spacial), a spreadsheet program, and an easy to use
math/statistics program. Not that this isn't a great deal of
software, but I'd argue very little of it actually exists in a form we
would really want on a workstation (or a mainframe either)! I think a
significant number of the hundreds of programs lying around are there
because someone wasn't given the tools to do whatever was required
without creating some more code which no one else wants.
On the interfacing comment; this is quite true, we have to get the to
the outside world too, but here too, it isn't like someone's alreaday
invented a wheel... we'd have this problem on any machine... no matter
what system you are on, there will still be some time where what you
need to do is interface to another system.
Performance is a good point; I too think all the mathematics in the
world isn't as good as one "well, lets try it". All this means is
that you don't go putting in a bunch of these things without
prototyping. But that's just common sense!
Fred Brooks (Mythical Man Month) noted that "the question is whether
to build a pilot system and throw it away. You will do that. Hence
Hence, plan to throw one away; you will, anyhow." [requoted from the
(quite informative) article on the Star interface in BYTE.
------------------------------
Date: 3 April 1982 10:27:28-PST (Saturday)
From: pratt@Shasta at Sumex-Aim
Subject: Re: WORKS Digest V2 #37
To answer Dan Lynch's pessimistic query with some notes of optimism:
1) Having to build a mountain of new software.
Standards help enormously here. The external (user-visible) half of
Unix, starting from the user-kernel interface and working out from
there, provides such a standard. (This should NOT be construed as
support for the Unix kernel, which is not in good shape and would
benefit enormously from some modern love and care, including evicting
much of it from the kernel.) Blessed are they with a Unix environment,
for they shall inherit a mountain of software.
A similar remark could be made about many other operating systems. My
preference for Unix has to do with the overall quality of the
mountain. I have been an operating system user for 17 years and a
Berkeley Unix user for 20 months, and can say without qualification
that I have not seen as well organized, useful, and comprehensive a
body of software running under any other operating system. (The
Whorfians among you should note that Unix was the most recent
operating system I learnt, suggesting the possibility of an anti-Whorf
hypothesis.)
2) Interfacing each LAN/PC to the external world (electrically,
transport protocol, FTP/Telnet access in and out).
The LAN interface problem is orthogonal to the PC question. PC's are
perhaps more dependent on LAN's, but mainframes are rapidly becoming
sufficiently dependent on them that the problem must be solved for
them too. Thus this is not a PC-relevant issue.
3) Lack of performance data.
The key here has been the 68000, the first machine with an
architecture and a performance reasonable enough to contemplate using
it as a direct substitute for a conventional time-shared mainframe.
Comparing nonnumerical C programs on a no-wait-state 8 MHz 68000 and
the Vax 11/780, compiled on each machine by the Johnson C compiler
with optimization turned on, the 68000 shows up as about 70-75% of the
Vax. The transition to 10 MHz 68000's is already under way (the Sun
workstation will shortly be running at 10 MHz without wait states),
further narrowing this gap. There is therefore no reason to
anticipate a shortage of computer cycles as a result of migrating the
processor from the computer center to the user's desk.
The lesson here is that small need not imply toy. Now that we have an
existence proof that one chip of silicon can execute instructions at a
speed approaching that of a vastly more expensive processor like that
of the Vax we know that personal computers with their own built-in
processors are technically, economically, and practically viable.
Computer cycles are only part of the performance picture. Secondary
storage constitutes a major performance bottleneck for many programs
under many systems, due to a variety of overheads: inherent physical
disk limitations (seek time, rotational latency), current controller
limitations (many controllers can only transfer a small fraction of a
track per revolution), and bus and (in many cases) processor
performance limitations. An architecture which moves the processor to
the user's desk leaving secondary storage as what remains of the
mainframe (preferable to moving expensive, noisy, bulky disks into the
user's office), connected to the user's workstation via 10 Mb
Ethernet, interposes an additional delay. A performance question I
have yet to see answered anywhere (pointers PLEASE if you have them)
is the user-perceived increase in overhead introduced by this
connection in a setting that duplicates the user interface of a
timeshared mainframe operating system such as Unix. (Popek's LOCUS
project at UCLA has measurements for PDP-11's that are related to this
question, but I would like to see such measurements for a system with
higher-performance processors like the 68000, and with a 10 Mb
Ethernet.) My own intuition is that this additional delay will add
about 20% to secondary storage overhead. However this figure is down
in the noise compared to the variability in performance of different
disks, controllers, drivers, and file system organizations.
Vaughan Pratt
------------------------------
End of WorkS Digest
*******************
-------
∂05-Apr-82 2253 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #39
Date: 6 Apr 1982 0105-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #39
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Tuesday, 6 Apr 1982 Volume 2 : Issue 39
Today's Topics: While we are on the subject...
Performance Analysis and Remote Disks
What is a LAN?
----------------------------------------------------------------------
Date: 4 April 1982 09:25-EST
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: While we are on the subject...
Someone is working on the personal workstation concept. At M/A-Com
Alanthus we built a throw-away workstation package offering several
languages, a VisiClone, limited graphics, Email, automatic access to
outside services (e.g. Dow-Jones, The Source), Word Processing,
keyword retrieval of filed information, paper item indexing, and more.
We also did it in six months on the Convergent Technologies system
(read 8086 based). Our LAN only runs at 0.6 Mbits/s and uses twisted
pairs.
Here is what we have learned:
1. The 8086 is a very capable chip. There is no need to wait
for the more esoteric processors. CT's software and tools
made development possible -- not the processor.
2. You can get a lot done on a slow LAN. You can even provide
resonable response time.
3. You don't need a bit-mapped display. Sure it would be nice
but the users haven't noticed yet.
4. The ease-of-use (friendliness?) is of paramount importance.
We used function keys and labeled them on the screen on a
screen-by-screen basis. It evidently worked since the
Chairman of the Board of M/A-Com took the keyboard from my
hands after a 3 minute demonstration and started using the
system himself.
What is the point of this letter? It is that everything we have
talked about is possible now. All you have to do is write it. Fancy
hardware is very nice, but it does not a workstation make. The keys
are software and development tools. No component is especially SOTA,
but the gestalt is.
Brian
------------------------------
Date: 4 April 1982 1011-EST
From: Hank Walker at CMU-10A
Subject: performance analysis and remote disks
Benchmarks written in a high-level language and then compiled tell me
NOTHING. Anyone who thinks that a MC68000 is 70-75% of an EFFECTIVELY
USED VAX had better think again. Assembly-code benchmarks are the
only relevant ones for comparing architectures. Now if you are
comparing available compiler-hardware systems, C benchmarks are
relevant.
An Ethernet interposed between a disk and processor presents the
following delays: outgoing protocol, transmission time, incoming
protocol, disk processor queueing time, processing time, disk access,
outgoing protocol, transmission time, and incoming protocol.
Transmission time total both ways is probably 1ms. Protocol mucking
depends on whether you have a dedicated processor. We use remote tape
drives here, and TCP burns up to 60% of the cycles on a 780. This
might be a problem. Assuming processing time is negligible. The disk
access can't be avoided without a cache. The big time is probably
queueing time if you have lots of workstations sharing a big disk
drive. The two areas to pay attention to are protocols and queueing
time. The latter may be larger. Sharing a disk probably means you
can add a disk cache, so your overall performance may be no worse than
a local disk. Also, the big remote disk is undoubtedly faster than a
small local Winchester.
------------------------------
Date: 5 April 1982 19:46 est
From: Frankston.SoftArts at MIT-MULTICS
Subject: What is a LAN?
Sender: COMSAT.SoftArts at MIT-MULTICS
Reply-To: Frankston at MIT-MULTICS (Bob Frankston)
*from: BOB (Bob Frankston)
I presume that the key characteristics are that it is relatively cheap
to interface to, provides a high bandwidth, short transmission time
for packets and a reliable connection. Basically it can be assumed to
always be there and be sufficient to support a file server. How does
this differ from other people's views?
In particular, I am allowing for the protocols to be similar to a
global network. It is just the ability to assume the ready
availability of resources over the network that distinguish it.
------------------------------
End of WorkS Digest
*******************
-------
∂06-Apr-82 2254 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #40
Date: 7 Apr 1982 0027-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #40
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 7 Apr 1982 Volume 2 : Issue 40
Today's Topics: Performance Analysis and Remote Disks
Brave New World?
Whether Network Protocols Should be Discussed Here
Standards: User-Kernel Interface
----------------------------------------------------------------------
Date: 6 April 1982 00:39:53-PST (Tuesday)
From: pratt
Reply-to: csd.pratt at SCORE
Subject: Re: performance analysis and remote disks
Date: 4 April 1982 1011-EST
From: Hank Walker at CMU-10A
Subject: performance analysis and remote disks
Benchmarks written in a high-level language and then
compiled tell me NOTHING. ... Assembly-code benchmarks
are the only relevant ones for comparing architectures.
So who's comparing architectures? The corresponding statement for
automobiles would be "Automobile road tests tell me nothing. Bench
dynamometer tests are the only relevant ones for comparing engines."
A car customer wants to know how the car performs, not just the
engine. Dan Lynch wanted to know the cost of the move from
timesharing to PC's. Answering him by talking about the performance
of one component of a PC system is only relevant if it helps predict
system performance. Dan's question is far better addressed directly
using system performance measurements than indirectly (and
incompletely) with data on the performance of just one component.
Anyone who thinks that a MC68000 is 70-75% of an
EFFECTIVELY USED VAX had better think again.
You have some hard data to back this up? (I don't know what
interpretation of "effectively" you had in mind, but it sounds like
you had the rather dated one of the machine alone executing
efficiently, as opposed to the more modern one of the human-machine
combination being used efficiently. Even so, I'd like to see the
evidence for this case.)
The benchmarks I used (there were five of them) all had the MC68000
crippled by the C compiler. If you want to compare the Vax to the
MC68000 with the Vax sped up using assembly code, you should permit a
similar speed-up for the MC68000. DEC's Doug Clark by the way has
extracted from several days worth of carefully instrumented
measurements on the Vax 11/780 the number 0.5 MIPS. Even allowing for
the fact that the Vax does A=B+C in one instruction, I wouldn't be too
surprised to find the MC68000 hot on its heels in assembly language,
though I wouldn't much care since no one around these parts programs
either the Vax or the 68000 in assembly language.
Thanks for the input on the cost of interposing an Ethernet between a
disk and a processor. Your warning about TCP duly noted, this agrees
with observations of Lampson, Nelson, Popek, and others about the high
cost of general purpose protocols. However I was startled by "the big
remote disk is undoubtedly faster than a small local Winchester," this
seems to be in the same category as the belief that a large Vax must
be faster than a miniscule MC68000. The 10" Fujitsu Eagle Winchester
transfers data at almost 2 megabytes/second, and more than one 8"
Winchester runs at 1 megabyte/sec, all quite likely to be faster than
the big washing machines I bet you have in your machine room. Small
need not be slow, for either processors or disks.
Vaughan Pratt
------------------------------
Date: 6 April 1982 09:13-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Brave New World?
To: pratt@Shasta at SUMEX-AIM
It shouldn't be too hard to add an extra level of software at the
point where the user program itself interfaces to UNIX. Having done
so, for example having all OPENs of files/pipes go thru a single
user-written procedure, which is moved to a separate source file and
shared among all user programs that are written in the same source
language, it should then be possible to modify the interface source
file to run on a non-unix system, at which point all those user
programs should work without significant modifications on the other
system. Thus systems needn't be standardized to have UNIX as their
user-program/system interface, in order to acquire the UNIX
application-program "library". (Quotes around "library" because I
don't mean library in the usual computer-jargon sense of a "library of
assembly-language subroutines editable by FUDGE2".)
To some extent, SAIL and LISP already do this sort of thing, as does
PCNET software.
------------------------------
Date: 6 April 1982 09:28-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: whether network protocols should be discussed here
To: pratt@Shasta at SUMEX-AIM
Of course the issue of network access isn't a workstation-specific
question, it applies to mainframes also. But when considering any
particular workstation, one of the most important questions is what
sort of network access it has (the other most important questions are:
what sort of word-processing/editor, what sort of display, what sort
of computing power, and what other software is available; did I leave
out anything important?).
Thus perhaps issues of particular protocol to use should be moved to
INFO-PROTOCOL (for low speed asynchronous long distance telephone and
modem communication) or INFO-LAN (doesn't exist that I know of; maybe
it should; for Ethernet-type things) or TCP-IP (for TCP/IP/X.25; I'm
not sure of this one), assuming we're designing a workstation
ourselves or sending suggestions to some commercial workstation
vendor, but discussion of the network capabilities of particular
existing workstations belongs here. Does everybody agree that a
workstation located near other workstations (such as in an office
building) should be on a LAN, and that regardless of whether a
workstation is on a LAN or not, it should have some long-distance
communication, either directly or via a longhaul-gateway on the LAN?
------------------------------
Date: 6 Apr 82 9:22:22-EST (Tue)
From: Dave Crocker <dcrocker.EE@UDel-Relay>
To: pratt.shasta at Sumex-Aim
Subject: Standards: User-kernel interface
With respect to the Unix user-kernel interface offering a general
standard, which version of Unix has the standard interface?
------------------------------
End of WorkS Digest
*******************
-------
∂02-Apr-82 0055 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #37
Date: 2 Apr 1982 0256-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #37
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 2 Apr 1982 Volume 2 : Issue 37
Today's Topics: Modem Survey
Brave New World?
----------------------------------------------------------------------
Date: 1 Apr 82 15:44:59-EST (Thu)
From: Vonglahn at UDel-EE
Subject: Modem Survey
Although this may not be the right forum for the following, I'm
sending it to WORKS since WORKS is the most active and widely-
distributed bboard being tracked here at UDel.
I'm trying to get together an informal data base on people's
experiences with various 300, 1200, and/or 2400 baud telco line
modems. The information will be used to help new members of the CSNET
select modems for their sites.
More specifically, I'm interested in learning what results the user
community has had with various brands and types (single or multi-line,
single or multispeed, originate only or autoanswer, manual or
autodial, etc) of modems. Since CSNET uses telco long distance, dial
up, voice grade, lines as its communications medium, I'm especially
interested in your experiences with your modem over such links.
If you have any positive or negative experiences with particular
hardware, I'd like to hear from you. All responses will be kept
strictly confidential unless requested otherwise. Please respond
directly to me at <vonglahn.vax at udel-relay>.
Thanks.
Peter von Glahn
------------------------------
Date: 1 Apr 1982 1428-PST
Subject: Brave New World?
From: Dan Lynch <LYNCH@ISIB>
Message-ID: <[USC-ISIB] 1-Apr-82 14:28:14.LYNCH>
Before we all jump off the end of our current earth and buy a gaggle
of Workstations (PCs) to populate our worlds we should consider the
whole picture to see if we are buying into a problem we might not be
able to solve.
As I see it the desire is to leave the current state of computing
support and head off to a better world where there is:
1) More computes per researcher.
2) More control over those computes.
3) Different (better) user interfaces.
4) Support for new computer science ideas (networking, parallelism,
sharing).
The initial attempts at solving this problem have led us to looking
at distributed architectures (like LANs with PCs and some file
server).
The drawbacks we have run into so far are that existing "solutions"
suffer from:
1) Having to build a mountain of new software.
2) Interfacing each LAN/PC to the external world (electrically,
transport protocol, FTP/Telnet access in and out).
3) Lack of performance data.
Item 3 is a real problem. I have not yet done the "analysis and
modeling" of what any particular choice would look like in operation.
I really doubt that doing a priori analysis would be of much benefit
because the assumptions on load would be so subject to misstatement.
So the only real "solution" is to build one and test it. If it has
terrible performance we will be quite unhappy and must make sure that
we can augment the basic architecture to improve performance.
Item 1 is also a real problem. The size of the "mountain" is much
bigger than one might imagine. There are hundreds of programs that
users find useful in the (our current) TOPS20 world. Just how many of
them do we have to duplicate to make the change appear as a move
forward? On this issue I might also note that it is not a trivial
matter to port application software around. (I am referring to the
amount of work, not its technical content.) Also, not much
communication is taking place about who will really commit to building
this package and that package on a reasonably firm schedule. As it
now stands one must just build it all from whole cloth or sit back and
wait for others to do it.
Item 2 is not too terrible. Just lots of engineering work.
Does anyone have an architecture that doesn't present so many apparent
drawbacks?
------------------------------
End of WorkS Digest
*******************
-------
∂08-Apr-82 0211 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #41
Date: 8 Apr 1982 0201-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #41
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Thursday, 8 Apr 1982 Volume 2 : Issue 41
Today's Topics:
Performance Analysis and Disks (2 msgs)
Request for Info (Apollo & Perq)
Performance Measurements
----------------------------------------------------------------------
Date: 7 April 1982 0434-EST (Wednesday)
From: Hank Walker at CMU-10A
To: csd.pratt at SU-SCORE
Subject: performance analysis and disks
In talking about disk performance, I was thinking more of seek times
than transfer rates. Something like an RM03, RP06, RP07 has a seek
time of about 25ms. Not very many small Winchesters approach this,
and in general are about half as fast, although this is changing all
the time. It's the shared disk cache that will probably buy you the
speed anyway.
Having worked at DEC, I am well aware that a VAX executes 0.5M VAX
instructions/sec (780 that is). I was just pointing out that if you
actually do care about the bare implementations, and not the HW-SW
system (as you do for your particular problem), then you have to use
assembly-code benchmarks to factor out the compiler. My problem is
for example, that the 68000 C compiler might be close to optimal while
the VAX one is bad. I don't know that, but the point is that it is an
unknown variable.
What I meant by effective use was a compiler generating BLISS-quality
code, which is estimated by Bill Wulf to be a factor of 2 better than
the UCB compiler.
Being a VLSI designer, I know that small doesn't necessarily mean
slow, and that the price/performance of the 68000 is much better than
that of a 780. But not quite as good as some would believe. It may
be that the 68000 is 70% of a 780 on simple instructions (probably
is), but the overall performance is highly dependent on the mix. More
string operations, or floating-point, would kill the 68000 if used
very frequently.
------------------------------
Date: Wednesday, 7 April 1982 09:13-EST
From: DPR at MIT-XX
Subject: Hank Walker and Performance
Hank Walker's performance comments touched a nerve. "the only way to
compare architectures is in assembly language"? Pish tush. Let Hank
write all his programs in assembly language, then. No one except
hardware-only bigots has made that mistake for the last 10 years. If
a salesman told me that I'd throw him out of my office.
It is true that better and worse compilers exist, and it may be true
that the VAX is wonderful when you have a good compiler. Show us.
On the other hand, Pratt in his comments never compares programs that
do a lot of I/O. Instruction set architecture has very little effect
on the performance of "REAL" programs (i.e. other than Puzzle). How
fast you can get data into and out of a machine is much more
important. The I/O bandwidth on most 68000 machines is pitiful. The
VAX, with its MASSBUS, and UNIBUS and cache memory, is a winner here,
and shows the real cost difference between big and little machines
(the CPU instruction interpreter is such a minor component of cost...)
Getting to a substantive point, we are just about to hook up a gaggle
of 750's to a local net, with the disk in some cases being provided by
a shared server across the 10MB net. So I think in a couple of months
we will have a data point for Pratt on this subject. I am unaware of
any useful comparisons and would be interested in other work.
I expect there to be little perceivable difference in UNIX on a 750
with local RK07 and UNIX on a 750 with remote simulated (admittedly we
will be using a faster disk for the remote server). As main memory
gets cheaper this is probably the way to go to keep your office quiet
and your disks reliable.
------------------------------
Date: 7 Apr 1982 1107-PST
From: Jeffrey at OFFICE
Subject: Request for Info (Apollo & Perq)
I have been reading through the WorkS archives. The interest is
great, but the eyes are weak. Nonetheless, I shall continue.
There are many references to the Apollo and Perq machines. So far,
however, I haven't seen any descriptions of these devices.
I would appreciate receiving all descriptive materilas on these
machines which perople would care to send. Would someone please send
me the address of Apollo?
Thanks,
Jeffrey Stone
(jeffrey@office)
------------------------------
From: sdcsvax!jvz at NPRDC
Subject: Performance measurements
In the discussion of performance measurements, it was mentioned that
the VAX-780 was analyzed as a 0.5MIP machine (by Doug Clark). How
does a MIP relate to my compiling a Fortran program or interacting
with a DBMS? And what is a MIP? If we are going to compare machines
and architectures, we need to be more specific. The one thing
lacking in the analysis of machines today is a standard reference
point and definition of work (as opposed to MIP). The measurement
should be the number of functions performed per unit time, where
"number of functions" has some rational base. And note, the
"functions" might be different depending upon the environment of the
user.
John Van Zandt
UCSD
uucp: ucbvax!sdcsvax!jvz
arpa: sdcsvax!jvz@nprdc
------------------------------
Date: 7 April 1982 13:25:54-PST (Wednesday)
From: pratt@Shasta at Sumex-Aim
Subject: Re: WORKS Digest V2 #37
To: REM at MIT-MC
From REM@MIT-MC Tue Apr 6 08:43:49 1982
It shouldn't be too hard to add an extra level of software
at the point where the user program itself interfaces to UNIX.
I agree. A very reasonable way to provide a Unix environment is to
provide a fast-and-lean kernel and implement most Unix services on top
of it as privileged user processes. One drawback of this scheme is
that it is next to impossible to get support for it - Unix lovers
wonder why you would want to do that much violence to a fine kernel,
while Unix haters wonder why anyone would want to implement a Unix
environment.
------------------------------
End of WorkS Digest
*******************
-------
∂09-Apr-82 0028 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #42
Date: 9 Apr 1982 0136-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #42
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 9 Apr 1982 Volume 2 : Issue 42
Today's Topics: Brave New World?
References on PERQ
Cheapo LAN Board for Multibus
What's a Nanosecond Here or There...
----------------------------------------------------------------------
Date: 7 Apr 1982 1901-PST
Sender: RENTSCH at USC-ECL
Subject: Re: Brave New World?
From: RENTSCH at USC-ECL
To: Lynch at ISIB
Message-ID: <[USC-ECL] 7-Apr-82 19:01:42.RENTSCH>
I am pleased to see that some people are thinking more about where we
are going than how soon we can start moving. Wasn't it Benjamin
Franklin who said "It is easy to mistake motion for action." ?
Your statement of what the better world is (more computes, better
computes, etc.) is good. Let me see if I improve on it by
generalizing:
The new world should provide a better vehicle for individual
(and group) creative expression.
The important ramifications of this as I see them are as follows:
1) The visual user interface should match well human vision
well in terms of bandwidth (say at least 25 Mb/s)
2) The processing function should therefore be local to the
user to avoid long distance/high bandwidth dilemma
3) The system should be felt as "quick" in the sense that
simple things happen instantly, which means
a) There should be enough processing power to deliver the
cycles at very high rates for important things
b) There should be plenty of memory (of the real variety) so
the swapping time is not the bottleneck
4) The user interface should feel natural (not familiar, that's
something different) and should not have unnecessary
artificial constraints
5) Therefore there should be plenty of virtual memory and
corresponding secondary memory to avoid the program
"strangeness" usually necessary to accompanying those lacks
6) Individual resources should, as much as possible, be completely
available to the individual and NOT to anyone else (except of
course as the individual sees fit)
7) Similarly with resources belonging to a group
8) Group interaction, which is always necesary, implies complete
communication being available
9) Be flexible and rich in functionality without sacrificing
individuality and individual comprehension
What all these things mean is that we are more or less on the right
track, even though there are the problems you mentioned (New software,
network interfacing, performance analysis). Personal workstations do
provide the potential at least for the necessary bandwidth and
processing power. Having plenty of memory will make a big difference
to how the system feels even though processor speeds are more easily
objectively measured. Communicating with high speed LANs provides the
communication potential even if the appropriate metaphors for the
styles of communication are not clear yet. Having writable microstore
will help both in terms of being flexible and in providing the right
amount of processing power "where it counts."
Having painted such a rosy picture, let me respond to your problems.
- The need to interface each environment to the communication network
I mostly agree with your assessment of being just lots of engineering
work. As long as we realize now that this will be going on, we can
avoid the most important pitfall of non-standardization. With some
planning up front, each environment can be interfaced to only one
communication protocol. I presume that there will be lots of
environments, so that there will still be a (linear) amount of work to
do, but that's not so bad. The real issue here is that the high level
notions of communication are not yet right. We have been accustomed
to think in terms of such objects as exist in the old world, but as
experience with distributed computing grows these ideas will be
replaced with new objects more appropriate. Simple example: a file
transfer program. In my ideal creative environement there is no need
for such a thing, perhaps replaced by a "remote file object," which
gets gotten at such time as you ask for it. The higher level
communication modes are even less well understood, and so it should
not surprise us (or frighten us) to think that a few mistakes may be
made. This is the nature of experimental science. The important
thing is to realize up front that the experiment is going on and not
overcommit to the wrong idea.
- Lack of performance data
The trouble with performance data is that the measurements are all so
objective that they don't tell us about how the systems feel, which is
the important impact on how well the vehicle carries the creative
effort. But personal workstations do have the property that the
performance is repeatable, and studies have concluded that uncertainty
in delay is the important factor in frustration, much more than the
delay itself. Also, if an individual is dissatisfied with the
performance of his workstation, he should be able to spend more money
on another, better performing one. The availability of a flexible,
writable microcode should mean that going from one environment to
another will be pretty easy, so the performance gain doesn't mean
sacrificing the old context.
- Mountains of new software
Is this a problem or a blessing? In order to get to a NEW world we
will have to write NEW software. If all we want is our old world
speeded up and less frustrating, that seems doable by the "standard"
portability techniques (I admit this is oversimplifying.) We should
instead view moving to a new environment as a blessing in disguise,
since it presents a tremendous opportunity to throw away all the bad
things we have just gotten used to rather than really liking.
Admittedly this means getting rid of things that we like, too, but I
claim that they would have to be rethought for the new world anyway.
The advantages of a complete redesign are well known, I shouldn't have
to give any other arguments on this point. And if some important
piece of software is really indespensible in more or less its present
form, then someone will do it for the new world, and maybe even in a
better, cleaner way. Finally, let me say that most of us aren't
sacrificing our old world (the hardware and software will still be
there) when we go to the new. So, while the interim may be juggling
two systems, we should be able to get to the new world smoothly and
without the trauma normally associated with a complete change in
environments. Lots of new software? Yes, but NEW software that is
better than the old, hopefully minus the crocks. And a fantastic
opportunity to build new systems based on new paradigms.
-- Tim Rentsch
------------------------------
Date: 8 Apr 1982 9:20:35 EST (Thursday)
From: tony lake <lake at BBN-UNIX>
Subject: References on PERQ
To: lake at BBN-UNIX
The 1980 and 1982 IEEE Computer Society Spring COMPCONs each have
sessions describing current workstations, although neither has a paper
from Apollo. In addition to papers on the PERQ (p. 317-8, 484-5),
Spring 1980 includes papers on the MIT NU system and LISP machine, the
CMU SPICE machine, and the Xerox Dorado. Spring 1982 proceedings
includes papers on the IBM PC and the HP-125. Some of the papers are
rather superficial, but they are a start at understanding the designs.
//Tony
------------------------------
Date: 8 April 1982 13:16 cst
From: Cornhill.APSE at HI-Multics
Subject: Cheapo LAN board for Multibus
To: cornhill at HI-Multics
We are in the process of assembling a couple of standalone M68000 (SUN
board) based workstations for executing Telesoft Ada. I would like to
use the workstations to investigate the desirability of using a LAN
for the development of software projects that are too big for a single
workstation.
I would appreciate any pointers on information that would help me
connet the two workstations in a manner meaningful to my needs. I
would prefer something a bit cheaper than Intel's $4000 Ethernet
boards, though we do need something that is compatible to a Multibus.
At one time I thought that Corvus had a $500 board for Multibus but
their sales rep knew not. Any other options?
Dennis
------------------------------
Date: 8 Apr 1982 1639-EST
From: Ron Fischer <FISCHER at RUTGERS>
Subject: What's a nanosecond here or there...
DPR brings out the important point to consider in this discussion of
CPU speeds, it is not the CPU, but the IO speed that (usually)
determines how fast your software will execute. But beyond this I
think there's a more important distinction to be made. Barring truly
unbearable situations CPU speed is just not that important. Most
people on this list sound like sports car fanatics!
A bit of reminiscing... back in 1976 when personal computers were just
starting to be sold in poorly designed kits one of the loudest cries
could be summed up by: "Who cares if it takes 1 minute or 5 minutes to
finish running the program, the computer's cheap, it's mine and no one
else can sporadically slow it down or crash it." The workstation
concept seems to embody the ideas of the latter part of the statement,
we all want our own computers.
So, although all of this wonderful hardware is going to let us do
really "fun things" even faster, shouldn't we be talking about what
those "fun things" are going to be? How about some more general
issues?? What can people do with a workstation that would be
impractical or silly to do with a mainframe? (besides play Pacman...)
What software techniques can take advantage of all those extra cycles
lying around? Are there better physical designs other than keyboard,
mouse, and display? Maybe workstations should be more like desks or
chalkboards, or perhaps even more like notebooks (Dynabook, hurrah!)?
Are there better architectures for personal machines (cringe)?
Religious arguments, ones that are unanswerable or based on
preference, don't qualify as "fun things" either... what should a
workstation's language or OS do? How should it support a bitmap
display? Who cares about the sundry specifics of existing stuff, take
the useful concepts and go from there. Performance measurements can
tell us if a system was implemented "stupidly," but they can only hint
that we took the wrong approach in the first place. Creativity makes
"adequately fulfilled" into "amazingly better."
Hit that mental "meta key!"
(ron)
------------------------------
End of WorkS Digest
*******************
-------
∂10-Apr-82 1457 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #43
Date: 10 Apr 1982 1538-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #43
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 10 Apr 1982 Volume 2 : Issue 43
Today's Topics: Power of a WorkStation (3 msgs)
UNIX & Remote Disks
Standards: User-Kernel Interface
Brave New World? (2 msgs)
----------------------------------------------------------------------
Date: 8 Apr 1982 (Thursday) 1931-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Power of a workstation
The MIP as a unit of workstation functionality is about as useful a
measurement as horsepower is for the space shuttle... great for the
media to make people oooh and ahhh, but otherwise useless. When a
shuttle is put together people don't want to know about horsepower,
they want to know whether the damn thing is gonna fly; and that is a
function of its weight, payload, pull of gravity, wind velocity,
and... the pilot. I was up in White Plains at Big Blue not long ago,
and the district sales manager told managers of my department that
"the IBM Displaywriter has the power of a 370/135." Great, I
exclaimed... I want to run TEL-A-GRAF, IFPS, APL, and IMS (those being
some of the packages/languages we use). The manager looked sheepish
"you can't do that" he said. But I could on a 370... Well, it turns
out he was talking MIPS, and lemme tell you, when it comes to word
processing (which is what the furshluginer thing was MADE for, ) it is
slower than a half a dozen word processors which use Z80s as CPUs.
For all the talk of power, we decided the machine was agonizingly
slow!
Butler Lampson, an Alto designer, told us in class that the Star was
one of the fastest machines around... Maybe so, but it is too slow to
use in a production word processing operation. (We haven't spoken
about the Star's speed that I remember... DON'T ASK FOR "HELP" it
literally takes 30 minutes to get the files from the file server and
load them all in!!! Oh, and the Stars you see at NCCs and INFOs are
generally souped up with extended memory so as not to run
embarassingly slow. I was told that Xerox first expected to sell the
Stars with 192K, but they ran SO slowly they now use a minimum of
256K.
The point to all this is, don't give me how many MIPS, let me tell you
what I want to do, and then tell me what my response time will be ...
since it depends on how its implemented, you will have to implement
what I want and let me fiddle... which all comes back to the point I
made before... all the math (and MIPS) in the world isn't worth one
case of "try it and see."
-Dave
------------------------------
Date: 9 Apr 82 3:07:05-EST (Fri)
From: Michael Muuss <mike@BRL>
Subject: Re: WORKS Digest V2 #40
The type of networking discussion that has been starting on WorkS
should probably stay with WorkS for the "Workstation+LAN" type
comments. Discussions of the details of the LAN might be more
profitably brought up in the TCP-IP-Digest.
TCP-IP @ BRL TCP-IP @ MIT-AI for submissions
TCP-IP-Request @ BRL TCP-IP-Request @ MIT-AI for requests & meta
discussion.
Best,
-Mike
------------------------------
Date: Thu Apr 8 22:51:09 1982
From: decvax!duke!bcw at Berkeley
Subject: Re: Workstation power
Source-Info: From (or Sender) name not authenticated.
From: Bruce C. Wright @ Duke University
Re: Workstation power
Recently there has been quite a bit of discussion about computer
system power as a function of MIPS. Although for some uses this is
quite appropriate, it has been quite some time since most computing
systems have been designed and purchased solely on the basis of MIPS.
MIPS only give you the potential for CPU-bound tasks (and even then
not very well, as I'll demonstrate later). For I/O-bound tasks (most
data processing, database manipulation, editing, compilation, linking,
word processing and so forth), a much more cogent measure can be I/O
bandwidth. For example, recently here at the Medical Center where I
work, we put together an LSI- 11/23 system with large (60MB) disk
drives. We had to be rather careful which controller we purchased,
because one of these high performance disk drives will simply saturate
the poor Q-bus if there are long (multi-block) transfers. Since it
wasn't really practical to modify the software to change multi-block
requests into a series of single-block requests, we had to ensure that
any controller we got for the system would automatically buffer the
request in some way (say by breaking it up into smaller chunks and
letting the drive spin around an extra time sometimes). The resulting
system has about the CPU power of a PDP-11/34, but I can attest that
it was *noticeably* slower for most types of computing, though we
never made any performance measurements.
Even for CPU speed, MIPS can be misleading without an understanding of
the application and the hardware than such a vague number is able to
give. For example, MIPS really don't have much meaning if the CPU
doesn't have a floating point instruction set and you need to do a lot
of floating-point math; ditto for decimal and to a somewhat lesser
extent character instruction sets. Another example is interrupts:
one of the fastest machines for large amounts of interrupt processing
is the TI-990 series, since it takes only about 1-2 instruction times
to enter an interrupt, save the registers and context, and be ready to
begin processing the interrupt service routine. Try that on your
PDP-11, VAX, or MC68000! The point is that this architecture was
specially optimized for a highly interrupt-driven environment (such as
process control) and it would take an enormous amount of hard- ware to
make those other architectures run as quickly in that environment.
MIPS only give the barest glimpse of the actual CPU speed; what really
matters in questions of system speed is the total match of the system
to the application.
Even apart from simple performance criteria, there are a lot of other
reasons why specific machines are chosen: software, for example. If
you have specific software needs, you may have to forego the cheaper
hardware in order to lower your total system costs.
Back in the 1940's and early 1950's, it might have had some meaning to
assign a single number to a computing system, but this technique no
longer has any particular merit.
Bruce C. Wright @ Duke University
------------------------------
Date: 9 Apr 82 3:45:36-EST (Fri)
From: Michael Muuss <mike@BRL>
Subject: UNIX & Remote disks
We have a home-grown UNIX-UNIX network with virtual disk access across
the network, and local -vs- remote disk access is indistinguishable.
Important details:
1) We use DEC PCL-11s (16Mbaud network hardware)
2) Home-grown, low overhead protocols ("BRLNET").
Testing indicates that we can bring 100 blocks/sec across the
network with only about a 5% "network overhead" expense
on the server end. (Both ends PDP-11/70 with MOS memory).
When we generalize BRLNET to run under InterNet IP, we expect the cost
to go up, but it shouldn't be terrible.
3) Special "High-Performance" BRL/JHU UNIX Kernel (although the effects
of this on the measurement cited above is small. Regular UNIX's
may have perhaps twice the overhead).
More on all this if there is interest.
-Mike
------------------------------
Date: 7 April 1982 15:34:36-PST (Wednesday)
From: pratt@Shasta at Sumex-Aim
Subject: Re: Standards: User-kernel interface
To: dcrocker.EE at UDel-Relay, pratt.shasta at Sumex-Aim
From dcrocker.EE@UDEL-RELAY Tue Apr 6 09:05:28 1982
With respect to the Unix user-kernel interface offering a
general standard, which version of Unix has the standard
interface?
Your guess is at least as good as mine. There is a crying need for a
standard here. Any takers for a Unix kernel interface standard
committee? Surely this is something the various Unix communities
(Usenix, unix-wizards) toss around from time to time?
-v
------------------------------
Date: 9 April 1982 04:14-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Brave New World?
To: RENTSCH at USC-ECL
cc: Lynch at USC-ISIB
Let me restate what you said and see if you agree: There will always
be an FTP program, that is a program that transfers files or parts of
files (pages?) between two different computers across a communications
medium (network). But whereas currently we always have to run the FTP
program explicitly from our keyboard&CRT before starting a process
that needs the file at the FTP destination, in the future the FTP
program will be run automatically from underneath our applications
programs so that we don't have to run the FTP program ourselves, thus
we may often forget that file-transferring is going on because it's so
transparent.
------------------------------
Date: 9 April 1982 04:18-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Brave New World?
To: RENTSCH at USC-ECL
Re your proposed desiderata for the workstation of the future: Is the
hardware for the compute-video bandwidth you propose available
currently (ignoring cost)? If so, who has it and how much did it cost?
If not, how many years will it be before the first prototype system
meeting your desiderata can be constructed from available technology?
(This is all to put it in perspective, are you talking about something
that could exist now but hasn't quite been put on the market yet, or
something that requires 5 or 10 more years of hardware development?)
(Perhaps you can't answer that question and somebody on the list with
more up to date information about hardware developments can.)
------------------------------
End of WorkS Digest
*******************
-------
∂11-Apr-82 1706 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #44
Date: 11 Apr 1982 1750-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #44
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 11 Apr 1982 Volume 2 : Issue 44
Today's Topics:
Call for Standards on Local Network Specifications
Brave New World/FTP (3 msgs)
LAN Hardware (2 msgs)
Addresses for Apollo and Perq
The Last Word on MIPS?
----------------------------------------------------------------------
Date: 9 Apr 1982 07:03:59-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: comments
Interlan has a Multibus 10 Meg Ether for about $2500 I believe. Tell
the you know of the forthcoming price reduction.
As for communications, I want to pour some of the cold water of
reality on these wonderous discussions.
If you are a local network research person, you are well aware of the
incredible fiascos going on in both standards efforts (IEEE 802-ring
circus)(double pun??) and everyone building networks going off and
inventing a new access protocol. Even worse, most vendors are
inventing their own higher-level protocols, many of which are
proprietary. (Vendor lock-in is a powerful marketting tool.) I also
don't buy the statement made in this forum that with this
heterogeneity, the work to intercommunicate is linear. There is an N x
M getway problem, and gateways are VERY hard when you DON'T have to do
protocol translation. If you want systems which will outlive the
current market spasms over broadband vs ethers vs rings vs
strings-and-tin-cans, the networking must be done in a way which is
INDEPENDENT OF THE WIRE, using protocols in the public domain (not
dominated by a vendor) and which will be widely implemented. At the
moment, IP/TCP/UDP are the only candidates. While they aren't my
favorite protocol designs (everyone would change something on
anything, given the chance), they ARE being implemented on MANY
machines and systems, and they are promulgated by an organization
which is so large, it is difficult for it to change its mind. This
means an implementation will have a reasonable expected lifetime. And
while a poor implementation of TCP may reduce a 10 Meg Ether to a
200Kbaud dribble, that is 200K more than you would have if the box at
the other end spoke something you don't.
There will be systems capable of acting as glue to bind this
heterogeneous world together. You will probably want some access to
Xerox NS because if Xerox ever releases Interpress (which appears to
be in question), you want to be able to send you document to the Laser
down the hall even though your machine speaks IP/TCP.
What this is really saying is that the world is VERY heterogeneous and
will continue to be into the forseeable future. I get very nervous
when people start talking about systems which don't realize this or
honor its impact. Any system which goes off in the corner and does
yet another design as if its the only network in the world, or the
only protocol in the world, or the only anything else in the world
might as well be written in assembler language.
Here at LBL, we have learned why the greatest evolutionary lever is
currently possessed by the tortise: he takes his shell with him
where-ever he goes. Unless an organizations plans to get in bed with
one vendor and buy only that vendor's equipment from here to eternity,
you CANNOT do things permanently wedded to one particular system.
(Even then, vendors do stop making hardware and do stop supporting
software.) Sometimes this means you can't exploit every little frob,
but we don't program in assembler either. And while the tortise is a
bit slower and not quite as thoroughly-modern as some of this
compatriots, he has outlived them all. If this sounds overly
dogmatic, it is, but the point is to question whether the evolution of
workstations, this grand ticket to a distributed world, is going to
commit the same old mistakes, only in more virulent forms.
The introduction of any new technology much include planning for is
inevitable obsolecence.
-Mike
------------------------------
Date: 10 Apr 1982 1535-PST
Sender: RENTSCH at USC-ECL
Subject: Re: Brave New World?
From: RENTSCH at USC-ECL
To: REM at MIT-MC
Message-ID: <[USC-ECL]10-Apr-82 15:35:45.RENTSCH>
In-Reply-To: Your message of 9 April 1982 04:14-EST
The question was raised about FTP continuing to exist but being so
transparent to use that it seems not to.
The answer is: yes and no. While at some level bits are certainly
being shipped across the net, the existence of a file transfer PROGRAM
is another matter. The code to ship the bits may not be a program,
just a piece of code embedded in some object. And it may not be
anything as fancy as FTP since after all it knows what file to ship
and needn't include ancillary functions such as listing of files and
choosing directory.
Furthermore, all the preceding discussion presumes that FILES still
exist. There will, of course, still be bits stored on a secondary
medium. But will these bits be structured into files? For
compatibility with the old world, I think there will be some files.
But for the new world, a better model might be to have EVERYTHING live
in virtual primary memory, with the appropriately large swapping
space. (This argument has nothing to do with swapping and scheduling
policies, since accessing the objects in the virtual memory universe
is not specified and may affect those policies.) In that case the
need for files as such disappears (except for compatibility, as noted
above.) Then what is an FTP? Answer: so different it can't even be
called an FTP.
Tim Rentsch
------------------------------
Date: 10 April 1982 21:03-EST
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Brave New World?
To: REM at MIT-MC
Isn't that the same transparent FTPing that goes on here when you give
a site name instead of using the default device DSK: ? For all the
grumbling about ITS, there are many features that are way ahead of the
"state-of-the-art"...
--Frank
------------------------------
Date: 11 Apr 1982 0544-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: No FTP
To: REM at MIT-MC
No! There is a distinct difference between FTP and the kind of file
access that is desired for workstations. In the FTP case, you
transfer a file from somewhere "remote" to somewhere "local". In the
file access case, THERE MAY BE NO LOCAL FILESYSTEM. There is no
copying going on, and indeed, the access may not even be linear; I may
access the first item in a file, then the last, then somewhere in the
middle....
Probably one of the earliest examples of this kind of thing is the
"MLDEV" program on ITS. This is the automatically invoked
software-device which handles file accesses accross the ARPAnet for
one ITS talking to another. Any program on any ITS can reference any
file on any other ITS. I can reference "AI:RWK;RWK LOGIN" on AI, MC,
ML, or DM in exactly the same manner.
This is slow, as you have seen. Don't judge remote disks by that: The
LISP Machine's FILE protocol does the same thing in a much more
efficent manner over a much more reasonable network (CHAOSnet, a 4MB
network similar to the Ethernet which serves as the local network at
MIT). The FILE protocol was developed to interface MIT's LISP
Machines to files living on ITS. The protocol has since been
implemented on TOPS20, TENEX, UNIX, VMS, Multics, and the LISP
Machine. File systems (there are 3) on the LISP Machine are a recent
invention, so the LISP Machine grew up in an environment where all
file accesses were remote. Now files can be accessed from all these
systems with equal ease.
Interestingly, it often seems to be faster to read from another host
than from your local file system (providing the other system is not an
over-loaded timesharing system). Why not? You've got two machines
working for you instead of one!
Of course, MLDEV and FILE can be used in concatenation. Thus LISPM's
can reference files on DM, although DM is not on the CHAOSnet. Of
course Internet and standardization will eventually make this
unnecessary, but probably not in DM's lifetime.
The FILE protocol is used as to implement file transfer (CFTP) on the
various CHAOSnet hosts. This uses only a subset of the capabilities
of the FILE protocol. Thus the FILE protocol is both more primitive
and more general than FTP. It's a network extention of an
operating-system's file-system interface.
------------------------------
Date: 9 APR 1982 1059-PST
From: SHOCH at PARC-MAXC
Subject: Inexpensive Ethernet/Multibus boards
To: Cornhill.APSE at HI-MULTICS
cc: Shoch
3Com Corporation has recently announced an Ethernet interface board
for Multibus machines; see the recent issue of Electronics.
In quantity 25, they are prices at about $900; comparison with the
price for the Intel configuration shows what a year can do in this
business, if there is sufficient projected volume for a board......
John Shoch
Xerox, Palo Alto
------------------------------
Date: 9 Apr 1982 1301-EST
From: Chris Ryland <CPR at MIT-XX>
Subject: LAN hardware
There are only two Ethernet (10Mb variety) interfaces worth looking at
right now: the 3com and the Interlan. Both have Unibus, Qbus and
Multibus versions. For Multibus, the 3com board is the winner: only
$1500. The Interlan boards have a couple of advantages over the 3com
boards: they provide fairly substantial address filtering, and they
implement the exponential backoff algorithm when transmission
collisions occur.
However, for some applications the 3com board is the only choice,
since it provides on-board host-addressable memory. E.g., for SUN
workstations, which ordinarily have no Multibus memory into which to
DMA, the 3com board is ideal.
Other than the Multibus 3com board, both companies are selling these
interfaces for around $3K. (Why anyone would buy the Intel interface
is beyond me.)
Please don't send mail requesting further information. Instead, look
in nearly any trade magazine for addresses and phones of Interlan and
3com.
------------------------------
Date: 11 April 1982 03:52-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: INFO-ATARI at MIT-AI
I'm interested in getting one or two track balls to use experimentally
instead of mice on our Lisp machines. I'd like to know of any
manufacturers or distributors of track balls who I can write to for
information. I'd also like information on prices, quality, and output
produced (i.e., resolution, maximum speed, etc.). Please reply to me
(PGS@AI), not the mailing list, because I'm not on it.
Thanks,
Pat Sobalvarro
------------------------------
Date: 9 April 1982 11:54-EST
From: Stephen C. Hill <STEVEH at MIT-MC>
Subject: Addresses for Apollo and Perq
To: Jeffrey at OFFICE-2
cc: STEVEH at MIT-MC
Perq (pronounced Perk, I was told) is made by:
Three Rivers Computer Corporation
720 Gross Street
Pittsburgh, PA 15224
(412) 621-6250
and they have sales and service offices in Hartford, Washington, D.C.,
Atlanta, Pittsburgh, Chicago, Dallas and Los Angeles
The Apollo is produced by:
Apollo Computer Inc.
19 Alpha Road
Chelmsford, MA 01824
(617) 256-6600
I have seen the Perq, and in my opinion, it is a slick looking
and operating machine. It has lots of nifty features, some of them of
dubious utility (like the ability to shape the cursor in one or
several different shapes. They used this feature to have the cursor
look like a little man pushing text off the screen in full animation.)
I think that I would have difficulty justifying this to my superiors,
unless they love executive toys. I know that they would never let ME
get one!
------------------------------
Date: 10 April 1982 19:35-EST
From: Tom Knight <TK at MIT-AI>
MIPS:Performance :: IQ:Intelligence
[AMEN -Mel]
------------------------------
End of WorkS Digest
*******************
-------
∂16-Apr-82 0033 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #45
Date: 16 Apr 1982 0236-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #45
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 16 Apr 1982 Volume 2 : Issue 45
Today's Topics: Another View of Mips
Call for Standards on LAN Specifications
----------------------------------------------------------------------
Date: Wed Apr 14 18:56:28 1982
From: decvax!cca!decvax!minow at Berkeley
Subject: Re: another view of mips
Source-Info: From (or Sender) name not authenticated.
One problem with published benchmarks, such as Wheatstone's, is that
less than honorable vendors might try to tune their compiler/operating
system to the benchmark. There are reports of such things happening
for Fortran compilers and the Wheatstone benchmark, by the way.
When Dec first announced Fortran-IV-PLUS and the 11/70 at Hannover
(1974 or 1975), someone went around to all the vendors with a Fortran
benchmark. The 11/70 ran it in zero time. Turned out to be a loop
like:
X = 0
DO 10 I=1, 100
DO 10 J=1, 100
10 X = X + 1
Fortran-IV-PLUS did the entire computation at compile-time, generating:
I = 101
J = 101
X = 10000
exit
The person running the benchmark accepted it as valid.
Moral: benchmarks -- especially computational ones -- are generally
unrepresentative of situations where the customer asks "How many users
can I put on my ..." (correction: "where the customer really wants to
know...")
Martin Minow
decvax!minow
------------------------------
Date: 15 April 1982 00:37-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: comments
To: mo at LBL-UNIX
I think I agree with you. Let me state concisely my view. Any network
system that has no public-domain-protocol interface to the outside
world is worthless in the long run. (This applies to private networks
that have NO modem whatsoever, those which have a modem but no
protocol with supporting software to interface that modem to the local
network, and those which have both modem and supporting software but
use a protocol that isn't public domain and thus can't legally be used
to talk to outside equipment no supplied by the same vendor.)
Anyone contemplating a workstation and/or local network at this time,
several years after it became obvious to any intelligent computer
person that networks are the way to go in the future, should refuse to
buy any such system unless it has a way to talk to the outside world
using a decent public-domain protocol (X.25, IP/TCP, PCNET, et al). It
would be nice if one single protocol existed, but varying equipment
(cheap asynchronous low-speed modems with auto-dialers vs. expensive
synchronous high-speed modems over leased conditionned lines) and
varying communication needs (low-overhead point-to-point protocols vs.
true packet switching with their necessary high overhead) force us to
use different protocols as appropriate. But even with 2 or 3
different protocols needed, a few gateways can link the networks
together, which however can't be done if everybody uses
vendor-supplied private protocols that can't talk to anybody else and
thus 20 or 30 different kinds of private networks exist and can't
link.
------------------------------
End of WorkS Digest
*******************
-------
∂17-Apr-82 0159 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #46
Date: 17 Apr 1982 0252-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #46
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 17 Apr 1982 Volume 2 : Issue 46
Today's Topics: Bogus Benchmarks
Comments on Minnow's Remarks on Benchmarks
Color Monitors
----------------------------------------------------------------------
Date: 16 April 1982 0934-EST
From: Hank Walker at CMU-10A
Subject: bogus benchmarks
The most flagrant violator of benchmark reasonableness that I've seen
lately is Perkin-Elmer. They had an add comparing their machine to a
VAX-11/780. The machine supposedly executed one of the benchmarks
>1000 times faster than the VAX. How was this possible. Well the
benchmark didn't generate any output, so the compiler optimized it to
a NOOP, which could be executed 1000 times faster...
------------------------------
Date: 16 April 1982 07:20:44-PST (Friday)
From: pratt@Shasta at Sumex-Aim
Subject: Minow
Martin Minow's observation about the FORTRAN program that was
optimized from a doubly nested loop to two instructions is well taken.
The same observation could be applied to other well-known benchmarks.
The Takeuchi function is a popular benchmark for comparing
call/return/parameter-passing overhead on different machine-language
combinations. The existence of a closed form for this function opens
up the possibility that a clever optimizer could discover the closed
form. As Martin says, people have been known to tune compilers for
benchmarks, so this possibility is less remote than it might seem.
Furthermore if one is going to accept as valid the optimization Martin
cited, on what basis would one reject some other optimization as
invalid?
However Martin's inference that benchmarks are unrepresentative of
machine performance is not the inference I would have drawn. A better
inference is that a benchmark written in a high-level language but
intended to reveal the performance of the underlying machine should
solve a well-defined problem in an efficient way, so as to prevent the
optimizer from playing too large a role.
Not all benchmarks need be efficient. A customer may be interested in
knowing how slow things will go if the programmers are sloppy, e.g.
adding up the numbers from 1 to n with a loop instead of using a
closed form. Clearly a sloppy benchmark is called for in such a case.
Moral: when benchmarking, choose benchmarks matched to what it is you
want to measure.
Corollary: there is no such thing as the universal benchmark.
--Vaughan Pratt
------------------------------
Date: 16 Apr 82 14:34-PDT
From: rubin at SRI-TSC
Subject: color monitors
I would like to buy a hi-res color monitor for a personal computer.
Mitsubishi, Hitachi, and Barco all seem to make similar units in the $
1,500 - $ 2,000 range (they have .31mm pitch and resolutions about 750
x 550). I would appreciate opinions about the reliability and picture
quality of these or similar units. For others who are interested, I
will collect and make available the responses I get.
Thanks,
Darryl
------------------------------
End of WorkS Digest
*******************
-------
∂21-Apr-82 0045 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #47
Date: 21 Apr 1982 0258-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #47
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 21 Apr 1982 Volume 2 : Issue 47
Today's Topics: WorkStations as Furniture
User Interface of the Xerox Star
----------------------------------------------------------------------
Date: Sun Apr 18 20:11:16 1982
From: decvax!utzoo!henry at Berkeley
Subject: workstations as furniture
Source-Info: From (or Sender) name not authenticated.
Something I have very seldom seen discussed is the issue of building
workstations as furniture. The original Alto was a desk; this
approach does not seem to have been followed up by successors. It has
advantages. For one thing, one can get the damn keyboard at the
proper height! Also, by designing the workstation and the human work
surfaces as a unit, one can ensure that there is enough horizontal
surface near the display/keyboard for spreading papers -- something
that many work environments are badly short on. One can certainly
meet these needs with a separate piece of furniture, but it starts to
be so heavily customized that it might as well be an integral part of
the workstation. Or so I speculate.
Has anyone done work along these lines? I would be very interested to
hear any ideas people have on pros and cons.
------------------------------
Date: Sun Apr 18 20:04:21 1982
From: decvax!utzoo!henry at Berkeley
Subject: recommended reading
Source-Info: From (or Sender) name not authenticated.
The April issue of Byte has an **excellent** article on user-interface
design by the designers of the software of the Xerox Star. One may
not like the precise interface they came up with, but the exposition
of basic principles is extremely good.
------------------------------
End of WorkS Digest
*******************
-------
∂24-Apr-82 0007 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #48
Date: 24 Apr 1982 0025-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #48
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 24 Apr 1982 Volume 2 : Issue 48
Today's Topics: Osbourne 1 Query
Color Monitor Information
Workstations as Furniture
Comments on this WorkStations Digest
----------------------------------------------------------------------
Date: 21 Apr 1982 1338-MST
From: Pendleton at UTAH-20 (Bob Pendleton)
Subject: osbourne 1 query
I am looking for information about the osbourne 1 portable computer.
Any information about quality, reliability, and usability from people
who have used one would be appreciated. Please reply directly to me
Pendleton@utah-20
Thank You
Bob P.
------------------------------
Date: 21 Apr 82 14:06-PDT
From: rubin at SRI-TSC
Subject: Color monitor info
Attached are the responses I got to my color monitor query. I have
also done some scouting on my own, with these results:
1. Amdek and Electrohome make monitors for about $1000. At
80x25, white characters are fuzzy as compared to a normal
A/N terminal. Otherwise, the pictures look OK. You can
get these at Computerland; the folks there seem to favor
the Electrohome monitor.
2. Barco makes a monitor (CD-33 HR) that normally goes for
$1590 from the distributor. It has a .31mm pitch tube but
the video bandwidth is only 7 Mhz! For this reason, an
80x25 screen is not too crisp here either, although it is a
little better than on the Amdek or Electrohome. They say a
newer version at the same price will be available in
September with 15 Mhz bandwidth. However, for a limited
time (due to overstock) you can get one of the current
CD-33 HRs for $ 795 from the distributor in Santa Clara
(408-727-1506). Note that an adapter for hooking up to
your PC is $100 extra.
3. Hitachi's HM 2713 is the sharpest of the monitors I saw
($1900), and is also by far the bulkiest. You'll need
plenty of desk space for this one! Unlike Barco, they
don't supply adapters for the popular PCs, so be ready to
invent your own.
Before you buy a monitor, make sure you know how to interface it to
your PC. Each PC and monitor seems to have its own unique type of
connector and signal outs, so special adapters are usually required.
The IBM PC adds a wrinkle in that extra electronics are needed in the
adapter if you want to use the PC's intensity line to get all 16
colors (Amdek and Electrohome now have this circuitry built in). I
did find one company (M&R, San Jose) that is working on a "universal"
adapter that will accommodate most of the combinations you're likely
to come up with; it will supposedly support the IBM's intensity line,
too. Their number is (408) 980-0160. Look for the product in about 6
weeks.
Good luck,
Darryl
----------
Date: 19 Apr 1982 13:55 EST
Sender: Marshall.WBST at PARC-MAXC
From: Marshall.WBST
Via: Parc-Maxc.ARPAnet; 19 Apr 82 10:57-PDT
We've had good luck with monitors from
Electrohome Electronics
809 Wellington St. N.,
Kitchener, Ontario
Canada. N2G4J6
Telephone (519) 744-7111
These are 13" diagonal OEM monitors (model G09) without an enclosure
and require isolation transformers. They take RGB and scan standard
525 TV resolution. They would easily do 750 x 550 with single pixel
resolution. Cost about $1000.
--Sidney
----------
Date: 19 Apr 1982 12:20 PST
From: Pasco at PARC-MAXC
Via: Parc-Maxc.ARPAnet; 19 Apr 82 12:21-PDT
We bought a bunch of Hitachi HM-2713C monitors for use in VLSI design
workstations, and are quite satisfied. The color rendition is
excellent, but the maximum brightness is somewhat less than on your
retail Trinitron CRT. The works-in-a-drawer makes adjustments super
easy.
We did have one minor problem which is that our computers don't
generate equalizing pulses as part of the composite sync signal, and
this meant we need Hitachi's electronics board to be Rev. level I or
later. Despite our specifying this on our order, some of the monitors
we received were Rev. G and H. Their local office was most
supportive, and sent a Hitachi representative here and to change all
the boards for us.
Richard Pasco
----------
Date: 17 Apr 82 19:10:49 EST (Sat)
From: decvax!duke!unc!wm at Berkeley
Via: Sri-Nsc11.ARPAnet; 19 Apr 82 18:29-PDT
I have used both mitsi and barco monitors. As far as I know the tubes
(at least) are all made by the same company. (Barco does make some of
their crt's, but not in that line). I have always liked barco
monitors the best. I know people who swear by them (like NYIT).
------------------------------
Date: 22 Apr 1982 (Thursday) 2132-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Workstations as Furniture & Ramblings
Having spent the past several days on several workstations (I don't
have my own Star, but rather a Datapoint, so when I need a Star I have
to use someone else's... each person configures their furniture
differently, so I have had some problems) I have the following
comments about workstations as furniture:
IF people followed basic ergonomics and furniture design, like
allowing plenty of room for the mouse (Star specific, but fill in
whatever you want), plenty of room for papers next to the
workstation, realized that desk height is not good for typing
(something which any secretary knows, and secretary's desks are
built with that in mind), THEN there would be know need for
workstations as furniture, and in fact I would not be for it,
because I might want mine arranged differently than would be
provided (for lefties, for instance).
However, people don't seem smart enough to know all that, and
therefore their attempts at placement of workstations stinks.
Personally I figure they deserve it, but when I have to work at a
workstation they designed (or more often didn't design) I can't
stand it!
There are companies, like Steelcase, which make generic workstation
desks which work fine... but they are EXPENSIVE (I have one for my
Datapoint). Also, they can't handle certain specific peripheral like
RIMs (Datapoint network access boxes), file servers, etc.
There are people who feel workstations will never get on the
executive's desks till they are available in walnut grain... I am not
sure they really ought to be on the executive's desk in the first
place (executive means the HEAD people, not "managers"), and if we are
dealing with a smart enough executive he/she will take whatever given
IF you can PROVE it will HELP.
My boss is giving a presentation (that I'm writing for him) to DP type
managers and applications planners. There are some topice covered in
the talk that I think are relevant to this Newletter. He will say:
o The interface to mainframes will alter from terminals
to multifunction workstations.
o This leads to many users who might at first used only a
single application (like a database manager) take a broader
view and start using many applications like word processing,
graphics, electronic mail, etc.
o Therefore, applications planners lives become more complex
since its hard to judge resource requirements of new, naive,
experimenting users, who are using computers to do their
jobs, not for production runs.
o Finally (and for this audience this is so revolutionary
he isn't sure he's gonna say it yet), the DP functions of
the computer (like database management, numerical calculations,
modeling, etc.) will occupy only a teeny fraction (say 10-20%)
of the usage of the workstation... office functions like
storage/retrieval, word processing, mail, activity management
(personal calendars, etc.) will be what users user most. We
Have found, forinstance, that the most used programs, by
an order of magnitude, are that text editors on our DEC,
not the compilers, etc.
-Dave
------------------------------
Date: 22 Apr 1982 1142-EST
From: WITTMAN at RU-GREEN
Subject: WorkS
I've been reading the WorkS list for my daily entertainment, and find
it fascinating and enlightening. (Thanks). What moves me to write is
reference to a "language & mind set" theory regarding languages
(attributed to Whorf).
An issue of "Science 81" contained an article about Language,
maintaining that research had demonstrated that people whose first
language was Japanese performed certain processing on one side of the
brain whereas all others performed those tasks on the other side of
the brain and implied that Language may indeed impose on the PHYSICAL
structure of the brain. If this is true, there are frightening
prospects for creating languages which will eliminate the need for
genetic engineering in some sense, but that really isn't the point;
the question is how much relevance might this have to "first
programing language" (an influence which may grow worse as younger and
younger children are exposed to primitive programing languages).
I don't know what Genius is, but perhaps it's the ability to rise
above environment. I don't claim to be up to the intellectual power
of the WorkS list personnel, but I'm supposed to be fairly
intelligent; and I find it difficult to change environments; even when
the new environment has some VERY nice features, I find an immense
number of things I no longer know how to do, and have a feeling I'm
not using the new system as it was intended (until I really ABSORB it
which takes a long time). (As an example, I once tried to write a
program in APL with very little exposure; it looked like FORTRAN. I
also know some very bright people who STILL express certain concepts
in 709x assembler. And apparently the "A, B language order tests"
indicate my difficulty shifting gears is not due exclusively to my own
intellectual shortcomings).
What I expected to see in the WorkS discussion were abstract
discussions of what a WorkStation was. What I have seen are:
1. Occasional irrelevancies (eg, the Header gripes, which
detract from the information content)
2. Semi-relevancies (eg, discussion of a particular Micro, OS or
communications system, which aren't really relevant but which
I find rather educational)
3. Advertisements and criticisms of various extant systems
(probably part of the above item; also very interesting, but
perhaps not germane)
4. A little theory now and then (which I thought was what this
group was all about). (And I don't know if Whorf fits in
this category or not).
I would frankly lose a lot if Items 2 and 3 above disappeared, but I
wonder if they should be such a focus. At Rutgers, our CS program
uses languages as illustrative lab tools to practice general
principles taught in class, but rarely focuses on the language itself.
I wonder if WorkS mightn't be more satisfying to some of its
participants if the products cited were used only as examples to
illustrate some general principle of what a WorkStation should be.
The intellectual Power of this group (which I don't claim to be up to)
is likely to be one of the few places one might find a collection of
"genius" which can rise above "what is" and talk more about "what
ought". I've seen a lot of (kind of hidden) complaints about that,
and I wonder if it's not part of the "language" problem; also, we can
only criticize or laud what we know - some members may not have been
exposed to Everything (there's so MUCH of it) and are trapped into
advocating a buzzword (eg, UNIX) instead of a concept (performing
function FERN, in a UNIX-like way).
I think the pragmatic advice transmitted about what systems exist and
what they do is invaluable to people who actually have to choose
systems to work with (probably all of us), but I hear an undercurrent
of discontent, so I've taken a selfish position: I want to continue
to be amused (highest sense: entertained and enlightened) by this
Digest, and don't want to see anyone get discouraged and go away.
By the way, all I know about a WorkStation is that it appears to be a
semi-private or private mini-environment tailored to getting your
particular tasks done.
Thanks, People. Sorry for the intrusion.
Barry Wittman (Spectator)
------------------------------
End of WorkS Digest
*******************
-------
∂25-Apr-82 1943 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #49
Date: 25 Apr 1982 2125-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #49
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 25 Apr 1982 Volume 2 : Issue 49
Today's Topics: What WorkStations Aren't
PlayStation?
WorkStations as Desks
----------------------------------------------------------------------
Date: 24 Apr 1982 08:13:48-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: what workstations aren't
Here at LBL I am finishing up serving on an administrative committee
called COWPEM (Committee on Word Processing and Electronic Mail).
[More humorous versions of the acronym have come to mind.] Anyway, we
were supposed to develop a Lab-wide position on the above topics.
Since the WP business is such a mess, we looked at Electronic Mail.
We looked at many of the systems being hawked by various outfits and
ruminated for a while.
The general result was rather interesting. Instead of trying to
recommend something (which we think was what was desired) or producing
a "Requirements Document", we produced a set of criteria which any
mail system must not violate. We found this much easier than
thinking of everything we want or might want electronic mail to
encompass. The process is also adaptive: the set of criteria will
evolve and become more specific as we see and use more and more
systems.
Now, how come this is on WorkS and not Info-EM or some such? The
point is the process. For dealing with new technologies in general
(and Workstations are such), we have found it useful to sketch such a
set of anti-social criteria and then explore the resulting space.
This is a case where enumerating the compliment set is much easier.
As we find other things we want X NOT to do, we add them to the set.
Otherwise, we feel we will unintentionally isolate ourselves from new
things.
While this position may be of no interest to us computer science
people, sometimes getting this new technology in the door rests on our
being able to make a case for "what good it does". Plans like the one
I just outlined can be useful for that, as well as dealing with an
administrator who says "Why can we just get one thing for everyone and
then it is all compatible?"
So anybody have any ideas what a workstation isn't?
(Besides a z80 and CP/M.) -- ONLY JOKING!!!!!
-Mike
PS - If anyone wants to see our list of non-acceptability criteria for
Mail systems, I can submit it to the digest or mail it directly.
------------------------------
Date: 24 April 1982 14:49-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: Playstation?
It occurs to me that the very word "workstation" implies that the
device is used only for work (something you're getting paid for, or
something you consider to be drudgery, or something that you believe
is benefitting the world in some way). What if you want to play, like
play games with other people or with the computer, or send messages of
a friendly rather than business nature such as making appointments to
get together for playing games or making love or having dinner
together? Am I to assume these non-work activities are somehow
impossible due to the design of a WORK station? (Perhaps you don't
personally own a work station, your employer does, and everything you
do is logged and summarized and analyzed by the computer and a report
of your activities is sent to your supervisor who can confiscate your
WORK sation if it is used for any non-productive tasks?)
I'd rather have a personal computer-system, i.e. a computer-system
that is available for my personal use, tied into a personal
computer-network, that is a computer-network that is available for
arbitrary personal use, not restricted to work-related tasks only,
which connects me with other personal computer-systems (and with WORK
stations of those poor unfortunate workers who aren't allowed to
play).
When I'm riding the bus, sometimes I wish I had a flat display I could
prop between my lap and the seat in front of me, with capabilities of
displaying a Go board and managing a Go game between myself and either
a computer program or some other person via a radio-linked compute
network. As the bus passes within range of a repeater, data
communication is established and the other person's move comes to me.
Then I think and move, and as soon as I'm within range of another
repeater my move is transmitted outward and then this cycle repeats.
The computer would handle error correction and re-establishing
contact. If we were out of contact for a while it would seem to me
like the other player was taking a long time to make a move. I could
be locally analyzing variations using my display as a scratchpad while
waiting for the earphone to beep indicating the other player's move
had finally come. Or I could be doing WORK or catching up on my
electronic mail. But with a WORK&PLAY-station I'd have the choice.
------------------------------
Date: 24 Apr 1982 2127-EST
From: Ron Fischer <FISCHER at RUTGERS>
Subject: Workstations as desks
An interesting observation was made along these lines by Gregory Yob
in Creative Computing. He suggested that an entire desk surface might
be a graphics display.
This sounds like a very neat idea. Combine a four by three foot
graphic display mounted in a desktop, tilted at a comfortable angle,
with a small keyboard, and pen-like pointing device with some window
support software. That seems like part of a nice environment. You
could shuffle papers (or icons if it gets designed by Xerox) just like
normal. If the display surface could be made sensitive enough, and
you didn't have to do much typing, a keyboard could probably just be
drawn on the surface when needed.
Since terminal displays are getting larger it might become more
logical to build them into desktops.
Anybody know if we could make one of these nowadays? Are there limits
to the size of a plasma display?
(ron)
------------------------------
End of WorkS Digest
*******************
-------
∂27-Apr-82 2333 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #50
Date: 28 Apr 1982 0147-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #50
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 28 Apr 1982 Volume 2 : Issue 50
Today's Topics: What WorkStations Aren't
Data Security?
----------------------------------------------------------------------
Date: 25 April 1982 23:38-EST
From: Robert Elton Maas <REM at MIT-MC>
Subject: what workstations aren't
To: mo at LBL-UNIX
Most importantly, a work station must not destroy my efforts via
crashes that lose the file I was editing at the time of the crash or
via inadvertant deletions of files that can't be undone or via editor
commands that run amok and can't be undone, nor even frequently lose
keystrokes due to not being fast enough to keep up with my typing.
Also it must not punish me severely for mistakes I make. If I make a
simple mistake I don't want to have to spend 15 minutes trying to find
out how to get back to where I was just before the mistake, or worse
having no way whatsoever to get back except by manually repairing the
damage such as by retyping text that was accidently altered.
------------------------------
Date: 26 Apr 82 23:08:54-EDT (Mon)
From: Michael Muuss <mike@BRL>
Subject: Data Security?
The conclusion I have reached so far is that permissions need to be
taylored to the needs of the organization sub-element being served:
*) Service organizations & Administrators are naturally (and often
necessarily) secretive.
*) Research organizations are generally ultra-open, even when placed
inside a fence.
QUESTION: What is the proper amount of "data hiding" for a diverse
organization which has large needs in both the Administrative and in
the Scientific departments for the benefits of (ahem) "Workplace
Automation"? And, what kinds of openness can we permit for our
intermediate work?
Starting Suggestion: Contemplate the MULTICS "Rings of Protection"
type concept. Extend it to the "Venn Diagram" environment where
different rings may have to overlap.
Computer←Science Question: What type of protection system
(theoretical or implemented) properly allows for the full range of
protection, and accounts for organizational oddities such as:
Secretaries
Team Leaders
Phone Answerers
People in more than one defined "Project"
Rapid changes in all of the above
????????????
-Mike
------------------------------
End of WorkS Digest
*******************
-------
∂02-May-82 2345 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #51
Date: 3 May 1982 0031-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #51
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Monday, 3 May 1982 Volume 2 : Issue 51
Today's Topics: Computer and WorkStation Security
Protection Systems (an Implementation)
Cost Driven Architectures
----------------------------------------------------------------------
Date: 29 Apr 1982 17:13:03 EDT (Thursday)
From: Carl D. Howe <cdh at BBN-UNIX>
Subject: computer and workstation security
Date: 26 Apr 82 23:08:54-EDT (Mon)
From: Michael Muuss <mike@BRL>
Subject: Data Security?
. . . .
QUESTION: What is the proper amount of "data
hiding" for a diverse organization which has large
needs in both the Administrative and in the Scientific
departments for the benefits of (ahem) "Workplace
Automation"? . . . .
Starting Suggestion: Contemplate the MULTICS "Rings of
Protection" type concept. Extend it to the "Venn
Diagram" environment where different rings may have to
overlap.
Computer←Science Question: What type of protection
system (theoretical or implemented) properly allows for
the full range of protection, and accounts for
organizational oddities such as:
Secretaries
Team Leaders
Phone Answerers
People in more than one defined "Project"
Rapid changes in all of the above
I believe that you have lumped two separate protection
mechanisms provided by Multics into the term "rings of protection".
As implemented in Multics, rings of protection simply allow a
multi-level operating system in a similar spirit to the T.H.E. system
designed by Edsger Dijkstra [1]. Ring 0 contains a minimal kernel
with infinite privileges, Ring 1 contains more functionality, but
fewer privileges, etc. until you get down to Ring 4 or 5 here the
user's program sits. The nice things about this sort of system is
that it allows the structure of your operating system to correspond
directly to your levels of abstraction in its design. It's an
excellent design tool, but doesn't really provide any security in and
of itself other than protection of the operating system, and denial of
access to sensitive entry points and system routines. Rings also
provide for the creation of "protected subsystems" that can
implement further security measures.
The Multics protection mechanism that does provide an excellent
form of security for large multilevel organizations is the use of
access lists at the segmentation level. To access a segment, you must
be on the access list for that segment when you try to open it. If
you are on the access list, you are given a segment descriptor and
then can use the segment according to the privileges granted you in
the access list. If you are not on the list, you are denied access.
The check of the access list is done both by user name and project
name, so you can have different privileges depending upon what project
you are currently working on. This system bears some similarity to
the government's security system, where you are only granted access to
a classified document if you are specifically on the access list; all
other requests are denied. This system provides a great deal of
flexibility because it does not require security to be hierarchical.
Cases where access must cross project or organizational boundaries can
be accommodated by changing access lists.
Unfortunately, in workstations, the problem is made more
complicated by the distributed nature of the system. Clearly,
protection mechanisms placed in the workstation are ineffective if the
user can change those mechanisms by modifying the operating system or
writing stand-alone programs. Requests sent over a local network to a
centralized file server may require some sort of authentication to
assure that one user is not masquerading as another to gain access to
material that s/he should not have. Sensitive data sent back over
the network may be picked up by other "promiscuous" workstations that
should not be granted access. Finally, any software or hardware
mechanisms you use to assure security may be totally ineffective if
you don't assure physical security of the system (e.g. immunity to
wiretapping, nasty people who patch programs from the front panel of
the machine, etc).
All in all, Multics provides some excellent mechanisms, but
when incorporated into the workstation environment, these mechanisms
must be used in the context of a complete security system, including
network security. Network security is a problem that is at least as
complex as computer system security and has its own collection of
mechanisms. For an excellent treatment of the network security
problem, see Steve Kent's book chapter [3].
Carl
-------
References:
[1] Dijkstra, Edsger W., "The Structure of the
"THE"-Multiprogramming System", Communications of the ACM, 11(5), pp.
341-346, May, 1968.
[2] Schroeder, Michael D. and Saltzer, Jerome H., "A Hardware
Architecture for Implementing Protection Rings", CACM, 15(3), pp.
157-170, March, 1972.
[3] Kent, Stephen T., "Security in Computer Networks", part of
Protocols & Techniques for Data Communications Networks editted by
Franklin F. Kuo, Prentice-Hall, Inc., Englewood Cliffs, NJ, 1981.
------------------------------
Date: 1 May 1982 (Saturday) 2048-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Protection systems (an implementation)
The Dialcom Tickler program, which is a personal and group calendar
management, scheduler, tickler, diary program from Dialcom
International (Silver Spring, MD) running on a Prime 750/780 has 13
levels of "protection", taking into account Secretaries, Bosses,
Bosses-bosses, peers, project leaders of one project but not of others
that you are doing, other people in a project but not in all projects,
etc. It is VERY complex, but they have some programs which
conversationally ask for the relationships of users and then create
the protection levels for you. Kinda neat... I have been told,
though, by Dialcom sales reps that only about 3 levels are used:
Peer - Can see times I'm busy, can't know what I'm doing unless
specifically allowed (can switch it so default is can always
see what I'm doing unless not allowed)
Boss - Can see times, what I'm doing unless private or personal
(lunch with secretary at Sleepy Hollow Motel), and can add
things without my permission (so boss can stuff something
on my calendar w/o asking me first)
Secty- Can see times I'm busy, can see what I'm doing, can
"tentatively" add things (are marked as added by secretary),
unless I'm said no.
-Dave
------------------------------
Date: 2 May 1982 1141-PDT
From: CAULKINS at USC-ECL
Subject: Cost Driven Architectures
I (Dave Caulkins) am the manager of the data processing facilities for
a small SF Peninsula startup; we have a V7 UNIX running in an Onyx and
a CP/M based system running in a Dirac, manufactured by Molecular
Engineering. It's this last machine I'd like to talk about. Its
architecture is interesting - a 34MB hard disk with a smart
controller, talking to up to 32 Z80-with-65K-RAM processors via a
parallel CSMA bus. See the Dirac Description below for detailed size
and cost numbers. Each user gets his own processor and 65K, and in
consequence adding users doesn't degrade performance nearly as much as
in a system in which one central processor dances around among 8 - 32
users. We've done some loading studies, and under medium load
conditions (15 users all working with files >65K via an editor) the
users-vs-response-time curve is almost flat. Under high load
conditions (each user requsting a large number of disk accesses per
second) the curve is roughly linear from 3 out to 15 users.
The Dirac doesn't quite make it. CP/M is nice in that there is a
great deal of 3rd party software available, some of which is good
quality (caveat emptor !). The CP/M file structure is painfully
primitive and hard to work with.
I think an attractive architecture would be as follows: A UNIX based
multiprocessor with 68000-and-512K per user, with 80 - 160 MB of
common hard disk available to all users. The 68000-and-512K ought to
be doable for less than $2K. Such a system should offer a very
attractive multi-user work station environment for a lot less than
CEI, Fortune, or others of the $5K standalone UNIX workstation flavor.
Standalone devices have a significant part of their cost in the case,
keyboard, CRT, and other non-computer elements. The terminal
manufacturers are beginning to do reasonable designs and realize good
economies of scale; seems to me that the natural division between
workstation terminal and computational resources offers real cost
adavantages.
Does anyone know of a company that has or is planning a system like
this?
Dirac Description
Cost: $15K for the basic box - 34MB disk, disk controller, power
supplies, 8" floppy drive and slots for 32 Application Processors
(APs); one required for each user. APs cost $1K each, less in
quantity. The AP price is rather high - manufacturing cost is
certainly well under $200.
Size: basic box - 24" high x 12.5" wide x 31" deep.
AP - 4" x 9"; 44 ICs
This may be where Dirac went astray. They put a lot of effort in
making the system quite small; the AP board is very tight. I for one
wouldn't mind a system 2X or 3X as big, but with the enhanced
capability discussed above.
------------------------------
End of WorkS Digest
*******************
-------
∂06-May-82 2306 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #52
Date: 6 May 1982 2354-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #52
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 7 May 1982 Volume 2 : Issue 52
Today's Topics:
Call for Information on the Olivetti WorkStation
Call for Information on the Spice Sun WorkStation
Ether Connection for MV/8000
Cooperative Personal Computers (3 msgs)
The Corvus Concept
Cost Driven Architectures
----------------------------------------------------------------------
Date: 3 May 82 11:10:39-EDT (Mon)
From: Ron Minnich <minnich.EE@UDel-Relay>
Subject: Olivetti info?
Anyone here seen the new Olivetti 'workstation'? There was an
article about it in a recent Electronics magazine. The article said it
was Z8001 based, had bit-map graphics, up to sixteen windows, and
came with 128 Kb memory and two floppies for under $3000. An Olivetti
salesman could not give me any solid info. The station was designed
by the Olivetti research group in Palo Alto.
ron
------------------------------
Date: 6 May 1982 21:49-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: SUN Terminal
Does anyone have experience with the forward technologies SPICE? (one
of the three flavors of the SUN terminal). Is anyone considering
buying it? What were your considerations, and how do you rank it via
other workstations? What are your positive and negative feelings?
- Steven Gutfreund
------------------------------
Date: 6 May 1982 1447-PDT
Sender: RENTSCH at USC-ECL
Subject: Ether connection for MV/8000
From: RENTSCH at USC-ECL
Message-ID: <[USC-ECL] 6-May-82 14:47:49.RENTSCH>
Anybody out there have any information on products available to hook
an MV/8000 up to a standard 10Mb ether wire? One obvious possibility
is an ether board that drives a Nova bus, since there is a Nova bus in
the MV/8000. I have written to 3Com, Interlan, Octothorpe, and (sigh)
Data General, but I am sceptical of a positive response.
In this regard, "product" might be too strong a word. We only want
ONE board (that works). So if someone has done one, it might be
possible to just duplicate it, at nominal cost.
Tim Rentsch
------------------------------
Date: 3 May 1982 2257-PDT
From: Steve Crocker <Crocker at USC-ISIF>
Subject: Cooperative Personal Computers
At the Aerospace Corp, where I run the computer science lab, I am
being peppered with queries about whether to get "terminals" or
"workstations."
The corporate computing facility runs large CDC and IBM mainframes.
Terminals exist around the company, but they are not located in
individual offices and are shared among all who need access.
Consideration is being given to acquiring a substantial number of
additional terminals, but there is concern that additional terminals
will lead to increased load on the mainframe with poor consequences.
It has been observed that workstations and personal computers cost
only slightly more than terminals, so it has been proposed that we buy
personal computers instead of terminals. While this sounds
attractive, I don't see any product line that combines the known
advantages of the personal computer with the known advantages of
large-scale central computers. Users who move from the corporate
machine to a personal machine -- even one with communication
facilities -- are going to be pleased that they get immediate and
consistent response from the machine, but they will be horrified that
they can't do real work, they can't coordinate their work with the
"real" computer, they don't have a fully developed file system, etc.,
etc.
I have a miniature version of the same problem cropping up within my
lab. We're bringing up a large VAX under UNIX. Everyone has his own
terminal, and we expect to support some experiments in electronic mail
and word processing with a few people outside of the lab. These
people too are asking why they shouldn't get personal computers and
tie them in to our lab computer instead of settling for simple HP2621
style terminals. While their impulses are understandable, how do I
explain to them that the editors and formatting systems available on
their personal computers are far less powerful and completely
incompatible with the corresponding facilities on the VAX. On the
other hand, I certainly do not want to support an arbitrary number of
users on the VAX...
Any ideas?
------------------------------
Date: Tue May 4 14:45:09 1982
From: decvax!harpo!ihnss!ihuxl!ignatz at CCA
Subject: Re: Cooperative Personal Computers
Article-I.D.: ihuxl.122
Source-Info: From (or Sender) name not authenticated.
I understand your problem; however, there is a solution which seems
reasonable. With judicious selection of your personal computer, it is
possible to offer services through your mainframe to expand the
function of the PC without unduely loading the mainframe. I refer you
to, at least, the Gamesmaster net, as well as efforts by companies
such as Datalogics in Chicago (a phototypesetter manufacturer). The
basic approach is to allow the mainframe, when so requested, to use
the micro as an intelligent terminal (granted, normally a waste of
resources; but if you know what the micro is, and how to access its
resources, you've got a terminal with floppies or whatever, ports,
etc., etc.). Going farther along your integration scheme, the approach
used (at least in part) by the above-mentioned firms is to download
either the entire utility requested, or a communication protocol
handler. For instance, if the micro user requires a sophisticated text
editor, the portion handling just the modifications to the current
buffer ('page', 'segment', whatever) is downloaded initially. This
then requests buffers as required, which are sent to the terminal
after modified buffers are returned. This isn't just whistling; it's
been done. Obviously, such an approach presupposes high-speed
communication and an efficient I/O handling scheme in the mainframe.
But I think you see my point.
Dave Ihnat
Analysts International Corp.
Bell Telephone Laboratories
Indian Hill, IL
(312) 979-6747
ihuxl!ignatz
------------------------------
Date: 4 May 82 13:12:52-PDT (Tue)
From: menlo70!sri-unix!hplabs!hansen at Berkeley
Subject: Re: Cooperative Personal Computers
Article-I.D.: hplabs.373
Source-Info: From (or Sender) name not authenticated.
...The HP-125 is a personal computer that has a built-in RS232 port
and a real, honest-to-goodness, terminal mode, rather than some awful
terminal emulator program. The terminal mode has very similar
features to the HP2621 terminal, and the HP-125 has the same package
as the HP-2621.
<End of advertisement>
------------------------------
Date: Tue May 4 08:14:20 1982
From: decvax!harpo!ihnss!ihuxl!marks at CCA
Subject: The Corvus Concept
Article-I.D.: ihuxl.121
Source-Info: From (or Sender) name not authenticated.
I just saw a new product announcement (DATA COMMUNICATIONS, April '82)
for a workstation to be produced by Corvus Systems (of Corvus Disk
fame) called the Corvus Concept. Vitals:
68000 processor
512KB max memory
Bit-mapped display
Omninet interface (Corvus' local network product)
$5995
Does anyone have any further information on this godsend?
Mark Beckner
------------------------------
Date: 4 May 1982 16:42 PDT
From: Deutsch at PARC-MAXC
Subject: Re: WORKS Digest V2 #51
In-reply-to: PLEASANT's message of 3 May 1982 0031-EDT
To: CAULKINS at USC-ECL
I don't understand your argument about the cost savings of your
proposed architecture. Any interactive workstation is going to need
"case, keyboard, CRT, and other non-computer elements". So the
savings is strictly in (1) the extra packaging not required for the
processors and memories, and (2) the sharing of the disk. I don't see
that making the difference between "less than $2K" and $5K. What did
I miss?
------------------------------
End of WorkS Digest
*******************
-------
∂09-May-82 0014 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #53
Date: 9 May 1982 0200-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #53
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 9 May 1982 Volume 2 : Issue 53
Today's Topics:
Input for "Graphic Input Devices" Talk Sought
Corvus Concept WorkStation (2 msgs)
----------------------------------------------------------------------
Date: 7 May 1982 00:48-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Input for "Graphic input devices" talk sought
I'm supposed to give a talk at the NCGA conference on "Graphic Input
Devices." If you know of any devices that I should be sure to mention
in the talk, please let me know. Feel free to be verbose. I am well
versed in mice and have used most pointing devices at least once.
Replies will be compiled in MC:SK;INPUT DEVICES. Thanks.
------------------------------
Date: 7 May 1982 0027-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Corvus Concept workstation
cc: Zellich
From a recent issue of Information Systems News newspaper:
CORVUS UNVEILS PERSONAL OFFICE COMPUTER ENTRY
Corvus Systems Inc., a supplier of microcomputer networks and
peripherals, has moved into the personal office computer market with a
Motorola 68000-based system priced at $4,995 in single quantities.
Called the Corvus Concept, the unit can serve either as a standalone
personal computer when configured with a dedicated printer and
peripherals, or as a network workstation on Corvus's Omninet local
area network.
Omninet, a twisted-pair local network using the CSMA/CD access method,
operates at 1-Mbit per second and permits up to 64 Concept
workstations to be hooked together in a network up to 4,000 feet long.
Corvus, headquartered in San Jose, said the Concept is aimed at both
Fortune 1,000 corporations and medium-sized businesses with
distributed data processing and office automation needs. It also
expects the Concept to find applications in academic and scientific
environments.
Concept's $4,995 single-unit price includes the 32/16-bit Motorola
68000 microprocessor with 256K bytes of RAM, made up of 64K-dynamic
RAM chips. Main memory is expandable up to 512K bytes.
Concept also has a 15-inch, high-resolution, bit-mapped display
screen. It can be viewed in either the portrait (vertical) or
landscape (horizontal) position with either black characters on a
white background or white characters on a black background, at the
user's option.
In the portrait position, it displays a full 72 lines by 90
characters, while in the landscape position it displays 56 lines by
120 characters.
A detached IBM Selectric-style keyboard that includes a 10-key numeric
pad and 10 programmable function keys is also standard on the Concept.
The programmable function keys can control up to 40 functions at each
command level, with function names displayed in a window at the bottom
of the screen.
Peripherals such as printers and modems can be attached to the
Concept's four 50-pin card sockets, located in an access pull-out
drawer. Two RS-232-C connectors are also included, as is a built-in
calendar clock with six-month battery back-up.
Standard software includes the Concept's operating system, which
supports the ability to "window" or divide the screen for several
functions at once, Corvus said.
Also included is Corvus's proprietary word-processing package, called
Edword. Edword is said to offer a complete range of menu-driven word-
processing features, including templates, multiple cut and paste, and
various insertion and deletion capabilities.
It also features what Corvus said is a unique undo/redo capability
that allows a user to view all changes made in a file by moving
backwards and forwards.
During a special six-month introductory offer, included in the
Concept's base price will be the Corvus LogiCalc electronic spread-
sheet program, licensed from Software Products International Inc., San
Diego, and a CP/M-80 emulator package from Digital Research Inc.,
Pacific Grove, Calif.
After that time, LogiCalc and the CP/M emulator, which gives users
access to the over 2,000 applications programs written under that
operating system, will be priced at $250 and $295, respectively.
Concept languages include ISO Pascal with UCSD extensions, and full
Fortran-77. These are standard in the Concept price. Basic and Cobol
packages are also planned.
[Sounds great...Dig that rotating screen! The accompanying photo shows
a nice-looking white (or light-colored,anyway) unit with a separate
keyboard attached by a curly-cord. The screen appears not only to
rotate vertically/horizontally, but also to swivel on it's base; can't
tell from the photo whether it also tilts or not. -RWZ]
------------------------------
Date: 8 May 1982 0649-PDT
From: Jeffrey at OFFICE
Subject: Corvus Concept Rumors
I've heard the following rumors about the concept:
- its a 68k based workstation which includes a bit-mapped
display (something like 600x400) and is meant to
interface to a local net like omninet
- the software is window oriented and gives the impression of
supporting multiple windows a'la Smalltalk
- the software is based upon a relatively primitive single user
O.S. called Merlin which was originated by Silicon Valley
Software; Corvus has greatly enhanced Merlin, primarily
in screen handling facilities
- Merlin as enhanced by Corvus is still a single task system
- the Concept does not use multibus; it does provide some
connectors into which Apple II (yes that's Apple as in Apple)
peripheral boards may be plugged [remember, these are rumors].
I'm attempting to get more information and a demo.
Jeffrey Stone
Menlo Park
------------------------------
End of WorkS Digest
*******************
-------
∂11-Mar-82 1920 George.Coulouris at Cmu-10a Re: Unix really isn't the answer
Date: 11 March 1982 1843-EST (Thursday)
From: George.Coulouris at Cmu-10a
To: works at BRL
Subject: Re: Unix really isn't the answer
In-Reply-To: Nathaniel Mishkin's message of 10 Mar 82 21:49-EST
Message-Id: <11Mar82 184300 GC12@CMU-10A>
Via: Cmu-10a; 11 Mar 82 21:28-EDT
After 6 years working on user interface problems here at Queen Mary College
London in a UNIX environment. I agree wholeheartedly that UNIX is not suitable
(and was not intended by its designers) as a basis for workstation application
development. It isn't surprising that this is so, because 'dazzling user
interfaces' require quite a lot of computing resource, and they require
the resources to be allocated on a schedule that gives the user an illusion
of animation (see my earlier message on this bb 'what is a workstation').
Resource scheduling and process swapping are so deaply embedded in the
philosophy of a system like UNIX that it will be harder to change
it than to start again (I don't mean tinkering with the scheduling
algorithm, I mean altering the design so that process swapping
is as economical as procedure calling).
Is Mesa the answer? I don't know because I haven't used it, but how about
steering some of our discussion towards identifying our requirements for
the software environment of a workstation? Let me kick off with
a very incomplete wish-list:
1) Extensible application software. Working environments evolve,
and so do individuals' approaches to their work.
The old 'software releases' approach to software updating is clearly
laughable when applied in a distributed information pprocessing environment.
We need to be able to extend the software WHILE IT IS RUNNING, with a high
degree of confidence that our extensions are consistent with the existing system.¬
This requires modularity, interface checking, dynamic binding of symbols
to objects and strict typing (so that the objects passed across interfaces
can't spread infection to previously valid modules) I understand that
although Mesa is strongly typed in most areas, there are loopholes.
I don't think that is good enough because we require almost total confidence in our
interfaces. In passing, it is worth mentioning that C can never be strongly typed
because array bounds cannot be checked (amongst other reasons).
2) Concurrency. Workstations exist in a distributed information processing
environment (a local network containing workstations and server stations).
The environment is inherently less synchronous than a single central
system, so the program should be made up of many communicating sequential
processes. I think this also applies within a single workstation because
the CSP makes a very good modular building block, with the added advantage that the
decisions about which are executed concurrently can be left to the
scheduling and communication mechanism.
George Coulouris
Computer Systems Laboratory
Queen Mary College
London
∂29-Mar-82 0013 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #33
Date: 29 Mar 1982 0232-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #33
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Office: H055 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x4780
Home: 206 Easton Ave., New Brunswick, N.J. 08901, (201) 249-2748
Works Digest Monday, 29 Mar 1982 Volume 2 : Issue 33
Today's Topics: VDT Conference
GriD Systems Inc.
----------------------------------------------------------------------
Date: 28 Mar 1982 1439-PST
From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: VDT Conference
A good idea that a few people have already done a few times is to
report on conferences to this digest. For example, there was a
conference on "Visual Display Terminals" at Stanford last week. Here
are a few observations:
Deanna Bengston of Atlantic Richfield described a pilot project there.
The secretaries ended up with 860s, the executives with Stars, and the
820s disappeared to people's homes. She generally had favorable
impressions, except that Stars are too big, noisy, and slow, of
course.
Randall Tobais, VP of AT&T for residential telephone service made the
observation that the home video game market is already bigger than the
home telephone market.
Peter Keen of MIT's Sloan School of Management discussed aspects of
social inertia. Look at his article in January 81 C.ACM for more
details.
Jim Blair of BNR brought up the status and sex appeal aspects of
terminal design.
Stuart Card talked about his now-famous experiment with mice. He and
Tom Moran have developed a model of the human brain as a computer with
three processors and a 70 millisecond cycle time that is amazingly
accurate.
There were a bunch of sessions on health issues and standards. Ken
Knowlton of Bell Labs showed a videotape demonstration of his
half-silvered keyboard made into very flashy telephone operator's
console.
Finally, Doug Engelbart of Tymshare described himself as feelining
like a hermit on the mountain watching the wagon trains come in. 20
years after he started doing on-line workstations they are finally
getting out on the market in droves.
-- Bill
------------------------------
Date: 28 Mar 1982 (Sunday) 2358-EDT
From: MORGAN at Wharton-10 (Howard Morgan)
Subject: GriD Systems Inc.
The GriD product is indeed a neat one, with high computing power,
good communications, and graphics screen all in the portable package.
They have moved, and previously given phone is incorrect. Correct
number is 415/961-4800.
Several beta test installations will be made in May. All development
on the system has been in PASCAL, using the Intel 8086 pascal. GriD is
one of the first sites to have 8087 up as well. Watching the GriDplan
and GriDPlot programs with and without 8087 is like slow motion and
full speed - this is more than an Apple II in a briefcase.
There are some interesting questions brought up by this device in
terms of its "personal workstation" characteristics. For example, the
fact that you cannot use it without 110AC means it won't work on
trains or planes - Dynabook isn't quite here yet. Second, the memory
(actually appears that inital ship will be 256K RAM and 256K bubble-
with 1M ram and 1M bubble planned in the future), doesn't let you keep
all your programs locally. Sure, you can carry around their
lightweight Winchester package (they point out that the Grid and
Winchester together weigh less than the Osborne I), but I doubt many
folks will.
Some other things done well include some built in encryption stuff so
that you can get software sent to you from GriD Central - if your
machine serial number is authorized. And, you can't send it to any
other machine directly, since encryption keys are known at central
(They say they are using a public key system).
The screen is a little small for my taste, but very crisp and bright.
If you are at the NCC Office AUtomation Conference in San Francisco,
Grid will have a booth. Also, I am chairing a session on Personal
Workstations Wednesday morning - with Ellis Horowitz of USC, Dave
Nelson of Apollo, and John Ellenby of GriD. Will report on it after
the fact for those of you who can't get out there.
------------------------------
End of WorkS Digest
*******************
-------
∂01-Apr-82 0041 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #36
Date: 1 Apr 1982 0241-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #36
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Thursday, 1 Apr 1982 Volume 2 : Issue 36
Today's Topics: Lisp on Workstations Query
----------------------------------------------------------------------
Date: 31-Mar-82 1210-EST
From: John O'Donnell <Odonnell at YALE>
Subject: Lisp on workstations query
T is a new dialect of Lisp comparable in power to other recent
dialects such as Lisp Machine Lisp and Common Lisp, but fundamentally
more similar in spirit to Scheme than to traditional Lisps.
The goals of the language design are very much the same as those of
NIL and Common Lisp. We desire a powerful, expressive, portable, and
efficient language and implementation. T is to be a "modern" Lisp
suitable for a broad variety of applications, including symbolic,
numerical, and systems programming, on a variety of machines. The
serious desire to use T as a systems programming language, replacing
languages such as C, Pascal, or BLISS on "conventional" machines,
places special demands on the design of the language and its
implementation.
Compatibility with other Lisp dialects such as Maclisp and Common Lisp
is also a goal, but this is achieved by a very different method than
that used by Common Lisp. Rather than absorbing other dialects in a
direct manner, T provides for compatibility modes implemented by
providing alternate binding environments for names and possibly some
amount of preprocessing of source code. We believe we have solved some
of the problems which have made this approach fail in other Lisp
implementations.
T almost includes Scheme as a subset; it differs from Scheme in being
stack-oriented, that is to say that continuations can only be invoked
once (i.e., a particular evaluation of a CATCH expression can yield a
value at most once).
T provides the basic datatypes intended to support its utility as a
general-purpose programming language and to provide what has come to
be expected of a "modern" Lisp: vectors, arrays, structures, strings,
arbitrary-precision integers, and, of course, symbols and lists.
Coroutining, multitasking, and synchronization facilities will be
provided.
A simple facility for generic operations and "object-oriented
programming" is provided. This does not try to be as powerful or
"featureful" as, for example, the Lisp Machine's flavor system, but it
is flexible, concise, and is well integrated into the language.
A portable implementation is currently well under way. It is intended
for "conventional" large-address-space machines; initial targets are
the VAX and the Apollo. Targeting for two machines simultaneously has
proved to be very helpful in promoting portability. Most portions of
the system are now complete; the next several months will see
enhancements to the compiler, construction of system interface
packages (including window system and graphics packages for the
Apollo).
An optimizing compiler is an integral component of the implementation.
Our system code, written nearly all in T itself, assumes an
intelligent compiler and is often much cleaner and simpler for doing
so.
Preliminary benchmarks for compiled code on the VAX have T comparing
quite favorably to Franz Lisp. We are in the midst of our first
internal release for the Apollo and the VAX now; an external release
may be expected sometime this summer.
------------------------------
End of WorkS Digest
*******************
-------
∂18-May-82 0144 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #55
Date: 18 May 1982 0222-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #55
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Tuesday, 18 May 1982 Volume 2 : Issue 55
Today's Topics: What's a "Memorex 601"?
Multi-Bus M68k Systems
CPU-Per-User Architectures (6 msgs)
----------------------------------------------------------------------
Date: 17 May 1982 17:14 PDT
From: GWilliams at PARC-MAXC
Subject: What's a "Memorex 601"?
To: TonyWest, Pettit, Info-micro@Mit-Ai
cc: GWilliams
I am considering buying a Memorex 601 Winchester disk drive (14", 75
MB). Does anyone have anything to say about them before I jump in?
Rumor has it that they speak SMD.
Any comments are appreciated.
Glen
------------------------------
Date: 16 May 1982 17:46-EDT
From: Robert A. Morris <RAM at MIT-MC>
Subject: multi-bus M68k systems.
I've gleaned the following from conversations, literature, and
deduction. Anyone should hastily correct any mis-information I
present:
Three leading contenders for multi-bus Motorola 68k are: Codata
systems, Sunnyvale Calif; unix v7 system based on Stanford Sun
terminal cpu board. Unix port by Unisoft. The only (?) unix 68k
commercial system presently being delivered with memory mapping
implemented, hence the only (?) multi-programming one. base system is
about $12k, but with only enough hard disk for system (5mB). 80 mB
winchester scheduled for summer.
CM Technology. Similar in flavor to Codata, but own cpu board. Memory
mapped version not yet available. Have been heard to claim that they
improve on the sometimes criticised Stanford mapping scheme. Probably
ultimately lower in price. Unix port is also from Unisoft.
Wicat Systems, Orem Utah. Similar approach to CMT. Offer their own OS
also. Offer related bit mapped terminal hardware (they seem to have a
good reputation in display soft/hardware). Their own v7 unix port.
Also not working multi-programming (?)
--bob morris
------------------------------
Date: 5 May 1982 2250-PDT
From: CAULKINS at USC-ECL
Subject: Re: WORKS Digest V2 #51
To: Deutsch at PARC-MAXC
cc: CAULKINS
Date: 16 May 1982 2246-PDT
From: CAULKINS at USC-ECL
Subject: CPU-per-user architectures
cc: deutsch at PARC-MAXC
Here's a series of exchanges concerning my suggestion of
CPU-per-user architectures in WORKS Digest V2 #151. My
apologies for repeating some stuff from earlier digests, but I
don't believe the trains of thought would be clear otherwise.
In response to your message sent 4 May 1982 16:42 PDT
Any interactive workstation is going to need "case, keyboard, CRT, and
other non-computer elements". So the savings is strictly in (1) the
extra packaging not required for the processors and memories, and (2)
the sharing of the disk. I don't see that making the difference
between "less than $2K" and $5K. What did I miss?
[Several points:
1) The manufacturing wizards at my company tell me that the cost of
all non- silicon parts of a workstation type device (case, power
supply, et al) is 30 - 50% of the total cost of the device. These
things are not rapidly cost-declining technology like the silicon
parts.
2) The workstation folks have not gotten nearly as far up on the
economy of scale curves as the terminal manufacturers - I can get a
very respectable terminal for $450 today; about 10% of the $5K
workstation price. Until and unless a lot of shaking out takes place
the workstation manufacturers are unlikely to achieve terminal-like
scale economies.
3) Two important workstation/CPU-per-user architecture parts - hard
disks and power supplies - have decidedly convex
cost-per-unit-resource curves; $/amp and $/megabyte decrease markedly
as the capacity of the PS or disk drive goes up. The CPU-per-user
wins here because many users share bigger disks and power supplies.
Conclusion - cost/effectiveness favors an architecture taking full
advantage of economies of scale in terminals, disks, and power
supplies; and one with a maximum amount of value in silicon as opposed
to plastic, iron, and copper.
Dave C]
------------------------------
Date: 6 May 1982 09:20 PDT
From: Deutsch at PARC-MAXC
Subject: Re: WORKS Digest V2 #51
In-reply-to: Your message of 5 May 1982 2250-PDT
To: CAULKINS at USC-ECL
Hm. What you say about workstations and terminals may be true for the
current generation of character-display terminals. It certainly isn't
true (at least not yet) for bitmap displays. The price of $450 for a
character-display terminal (including an interface to some kind of
shared bus, Ethernet, or serial line) seems low to me, and the price
of $5K for a workstation is much too high if it doesn't include a
disk. I.e. I think you need to distinguish the disk-sharing part of
your argument (which I basically agree with) from the power-supply
part (which I am less sure about) and the processor/memory part (which
I think is more complex than you make it out to be).
------------------------------
Date: 6 May 1982 09:24 PDT
From: Deutsch at PARC-MAXC
Subject: P.S. Re: WORKS Digest V2 #51
In-reply-to: Your message of 5 May 1982 2250-PDT
To: CAULKINS at USC-ECL
It seems to me that your statement that "the cost of all non- silicon
parts of a workstation type device (case, power supply, et al) is 30 -
50% of the total cost of the device. These things are not rapidly
cost-declining technology like the silicon parts." actually suggests
the opposite conclusion from the one you want to draw. If the case,
keyboard, and CRT cost essentially the same for a workstation or a
terminal (which they do) and they represent a growing fraction of the
device cost (which you assert they do, i.e. their cost is declining
slower than that of memory and logic), then as time goes on it becomes
LESS important to share those parts of the device (the processor and
memory) whose cost is dropping.
------------------------------
From: CAULKINS at USC-ECL
Subject: Re: WORKS Digest V2 #51
To: Deutsch at PARC-MAXC
cc: CAULKINS
I (Dave Caulkins) finally get some time to continue this discussion:
One thing I think we've learned about the economics of modest (under
$5,000) computing equipment is that it is very price-elastic, and in a
non-linear way. The success of Apple, Sinclair, Tandy, etc. seems to
indicate that when the price for a particular unit of computational
capability is lowered by N% (where N is 10 - 50), the market for this
particular unit grows by much more than N%. This suggests to me that
it makes more sense (from a marketing point of view) to lower cost
than it does to expand capability, given that a particular
computational capability can be made available for a lower cost.
I'll apply some crude cost rules-of-thumb to illustrate:
Assumptions:
1) The ratio between the packaging (case/keyboard/CRT/power supply)
cost and the total cost (the packaging plus the electronic (ICs/PC
board/disk) parts) of a workstation (WS) type device is 0.4; i.e.
(total cost)*0.4 ~= packaging cost
2) The retail price of a workstation type device ~= 4 *(total cost).
3) A reasonable non-bit-mapped terminal has a current retail price of
$500, quantity 1. My entire case is based on non-bit-mapped systems;
it is not clear to me that bit-mapped displays contribute that much to
the value of a workstation. This is, of course, a highly subjective
judgement.
Using these numbers and a workstation price of $5000, then:
5000/4 = 1250, WS cost
1250 * 0.4 = 500, WS packaging cost
1250 - 500 = 750, WS electronics cost
750 * 4 = 3000, WS electronics price
3000 + 500 = $3500, WS electronics plus terminal price, the
approximate price per user for a CPU-per-user architecture. This
represents a 30% savings over the ordinary WS price, quite
substantial enough to induce the non-linear price elasticity
mentioned above.
------------------------------
Date: 17 May 1982 12:47 PDT
From: Deutsch at PARC-MAXC
Subject: Re: CPU-per-user architectures
In-reply-to: CAULKINS' message of 16 May 1982 2246-PDT
To: CAULKINS at USC-ECL
One thing about your figures doesn't make sense to me. If a
non-bitmapped terminal has a retail price of $500, then it must cost
$125 to make, electronics AND packaging together. How can a diskless
workstation have more than 4 times the packaging cost of a terminal,
when the package is essentially the same? I think the problem here is
that you're comparing apples and oranges -- terminal packages are made
in much larger volume than workstation -- but I don't see why they
HAVE TO be significantly different.
The other thing you aren't doing is allocating any cost for the
packaging (or more generally non-electronics cost) of the shared
system. Say you get an economy of scale such that the non-electronics
cost per user goes down by a factor of 4. (I actually think this is a
bit generous, but you know more about this area than I do.) Then the
per-user non-electronics cost of the shared system is an additional
$500/4, or price of $500/4*4, or $500. This puts the shared system
price up to $4000.
------------------------------
Date: 17 May 1982 13:01 PDT
From: Deutsch at PARC-MAXC
Subject: Re: CPU-per-user architectures
In-reply-to: CAULKINS' message of 16 May 1982 2246-PDT
To: CAULKINS at USC-ECL
I would be most interested in knowing about commercially available
non-bitmapped display terminals with upper and lower case, underlining
and/or reverse video, editing capability under computer control, some
kind of random positioning, minimum size 32 x 64 characters, and the
ability to work at 9600 baud or greater, that sell for $500 or less.
Terminals with less than these capabilities do not correspond to the
capability commonly available in workstations.
------------------------------
End of WorkS Digest
*******************
-------
∂16-May-82 0717 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #54
Date: 16 May 1982 0945-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #54
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 16 May 1982 Volume 2 : Issue 54
Today's Topics: Survey Information
More on the Olivetti WorkStation
Corvus Concept
----------------------------------------------------------------------
Date: 9 May 82 17:57:55-EDT (Sun)
From: Dave Farber <farber.EE@UDel-Relay>
Subject: Survey Info
WHo can supply some info on 68000 based systems that use the official
IEEE Multibus as their main bus?
Dave
------------------------------
Date: 11 May 82 12:40:36-EDT (Tue)
From: Ron Minnich <minnich.EE@UDel-Relay>
Subject: More on the Olivetti workstation
It is described in the April 21 issue of Electronics. It is known as
the M20. The picture shows a spiffy-looking all-in-one unit complete
with two 5 1/4" floppies. It has a standard keyboard and a numeric
keypad. A configuration including 2 fd's, monochrome display, 128 Kb
memory, and a printer costs about $4500. The display is bit-map and
supports up to 16 windows. The 'basic' machine-whatever that is-
costs about $3000. An Olivetti salesman claimed that the basic machine
included 2 floppies, 64Kb memory, and the display. Olivetti salesman
told me they will be available to end-users through distributors
(like Computerland) only.
ron
------------------------------
Date: 14 May 1982 1006-EDT
From: WITTMAN at RU-GREEN at RUTGERS
Subject: Corvus Concept
There seems to have been some recent interest in the Corvus Concept,
but not for the reason I expected (namely disk space).
Televideo has announced a distributed computing system wherein there
are several variations of "workstation" each with its own 4Mhz Z80A
and 64KB of memory. Cheapest is a satellite with no local filing
($1695 list) running to 7.5MB local hard disk with 1/3MB local floppy
($6995 ditto).
Up to 16 stations can attach to an 18MB disk with its own Z80A backed
by a 14MB tape drive. ($12,995).
(All figures are AVAILABLE space after formatting).
The facilities are not exactly state-of-the-art, but they do seem to
offer promise as a relatively standard distributable system.
(Just in case anyone's interested).
Barry
------------------------------
End of WorkS Digest
*******************
-------
∂21-May-82 0041 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #56
Date: 21 May 1982 0155-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #56
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 21 May 1982 Volume 2 : Issue 56
Today's Topics: Workstations vs Terminals
Bitmap Displays
Multi-Bus M68k Systems
CPU-Per-User Architectures (2 msgs)
CM Tech System
----------------------------------------------------------------------
Date: 18 May 1982 0757-PDT
Sender: BILLW at SRI-KL
Subject: Re: Workstations vs Terminals
From: BILLW at SRI-KL
Message-ID: <[SRI-KL]18-May-82 07:57:12.BILLW>
In-Reply-To: Your message of 18 May 1982 0222-EDT
Many of you are wrong. The packaging for most modern workstations is
NOT that similar to the packaging for a terminal, to wit:
1) The CRT: Workstations with bit-map dispays generaly require a
special high resolution CRT with an increased horozontal scan rate.
These are currently abot 4 times as expensive as the monitors
required for a typical 24*80 display (about $500 each, I have
heard). Ordinary terminals benifit greatly from the mass
production of televison and video-tape equipment.
2) Keyboards: Have you ever SEEN a lisp-machine keyboard ? This may
be excessive, but a bottom of the line workstation ought to have a
keyboard that is as good as a top of the line terminal. Also, if
you have a bit-map graphics display, you NEED a mouse or other
similar pixel resolution pointing device.
3) Power suppplies: Up to current requirement of about 3 amps, you
dont NEED a distinct power supply, as a tranformer and a simple
monolithic regulator suffice. When you start talking about a CPU
board that draws 3 amps, plus memory plus disk or network
interface, OR you have a bus structure, your power supplies quickly
get more complicated and much more expensive.
4) Other things:
A multi-card worstaion needs a card cage and a backplane. Most
current workstations have a pretty big box somplace, in addition
to the keyboard/CRT.
Enjoy
BillW
------------------------------
Date: 18 May 1982 1400-EDT (Tuesday)
From: Bob.Colwell at CMU-10A
Subject: bitmap displays
Message-Id: <18May82 140040 BC70@CMU-10A>
A "heresy detected" light went on when I read the remark that perhaps
bitmapped displays are not really necessary for a personal
workstation. I have drawn quite the opposite conclusion from working
in CMU's computer environment. We use Altos and Perqs for creation of
drawings, schematics, and the like, and timesharing facilities for
word processing. When creating a document, I find myself constantly
running back and forth between the two systems, shipping "picture"
files to the word processor for inclusion in the document. I would
much rather have all of the facilities on the personal workstation,
and I can't get that without a bitmapped display to do my drawings
with.
------------------------------
Date: 18 May 1982 1642-MDT
From: JW-Peterson at UTAH-20 (John W. Peterson)
Subject: RE: multi-bus M68k systems.
To: RAM at MIT-MC
We have been working with a Wicat here at Utah. They do not have
their UNIX running for it yet, instead they have been porting Unix
utilities to MCS, their operating system. MCS looks like an attempt
at emulating VAX/VMS, with a few Unix features tacked on (e.g., I/O
re-direction but no concept of pipes, etc).
Their bitmap display is around 512x512 in resolution, not 1024x1024.
jp
------------------------------
Date: 18 May 1982 2024-PDT
From: CAULKINS at USC-ECL
Subject: Re: CPU-per-user architectures
To: Deutsch at PARC-MAXC
cc: CAULKINS
In response to your message sent 17 May 1982 13:01 PDT
I would be most interested in knowing about commercially
available non-bitmapped display terminals with upper and lower
case, underlining and/or reverse video, editing capability
under computer control, some kind of random positioning,
minimum size 32 x 64 characters, and the ability to work at
9600 baud or greater, that sell for $500 or less. Terminals
with less than these capabilities do not correspond to the
capability commonly available in workstations.
I have two candidates: the ADDS Viewpoint ($450 at 1), and the Kimtron
ABM85. I don't have good pricing yet on the second, but have reason
to believe it will be in the $600 range for quantity 10. Both of
these have all of the above with one exception; both are 24 x 80, the
quasi-standard for character oriented terminals.
Both have detachable keyboards; the ADM85 has a non-glare screen, a
status line, and a bigger keyboard.
------------------------------
Date: 19 May 1982 (Wednesday) 2127-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Flaming on CPU per user stuff
1. Prices of computer power are a function mostly of what the market
will bear. People like Osborne are proving same by making money
by selling $1,000 software plus full "workstation" (not too great,
but about as good as a $500 terminal, quantity 1... if you don't
like his screen I just say an add in Priority One for an Osborne
lookalike with full screen for the exact same price including
software) for $1,795... and that INCLUDES disk drives. What this
says is exactly what you were trying to reverse-prove (and which
someone pointed out) that the incremental cost of the intelligence
is VERY small. (Hence kits to change your H19 or VT100 to a
microcomputer) Prices of terminals are also a function of what
the market will bear, but the market won't bear quite as much
(unless we are talking about a 3278 terminal (IBM... remember
them) which IBM sells for over $5,000 (nothing fancy, just big
blue's initials on it.) Prices of workstations will come down as
the market demands it.
2. It is far easier (from both a hardware and software viewpoint) to
design a single user system than a timeshared system. Therefore,
this added cost goes into R&D expense of the big system. The
overhead involved from a machine standpoint (swapping, resource
allocation, etc.) gets hairy.
3. My office has compared standalone systems (integrated office
systems for both DP and Office Automation), networked systems (a
la Ethernet), mainframe and dumb terminal systems (DEC & VT100s),
mainframe and "smart terminals" (Wang VS 100 and Wang terminals),
mainframe and controller and dumb terminal systems (IBM) and have
found that comparable functionality generally costs the same
thing. This makes economic sense... if one system was inherently
better, we'd all have that system! Vendors, who make tremendous
margins on the cost of goods of their equipment, sell at whatever
they can. Therefore, discussing what you can buy is less
interesting than discussing what it OUGHT to cost to buy once
vendors get pushed.
4. Relevant example --> DEC just cut the price of their DECmate
workstation (and I know I have used the term workstation
incorrectly by our group's standards throughout this discussion,
but then it was used the same way in the previous messages) by
45%!!! Is this because they suddenly reached an economy of scale
where it now costs 45% less to manufacture than last month? No...
it's because they just announced the DECmate II personal computer,
and therefore they HAVE to cut the price of the DECmate I.
-Dave
------------------------------
Date: 18 May 82 9:16:19-PDT (Tue)
From: decvax!microsof!gordon at Berkeley
Subject: CM Tech System, correction
Article-I.D.: microsof.216
A recent news item mentions a CM Tech 68000 multibus system, "Unix
port is from Unisoft". CM Tech is using a Unisoft port to their
unprotected board. No protection means no relocation, so pipes, etc.,
force a swap each time the pipe fills.
Their protected system, with full multi-tasking and multi-user
capability, will run Microsoft's XENIX (V7/System III superset), not
unisoft.
------------------------------
End of WorkS Digest
*******************
-------
∂21-Sep-82 1825 AVB WORKS Digest V2 #59
∂12-Jun-82 1103 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #59
Date: 12 Jun 1982 1301-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #59
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 12 June 1982 Volume 2 : Issue 59
Today's Topics:
Call for and Responses to Information on Mice (3 msgs)
DEC Personal Computer
z8000 Unix vs. 68000 Unix
----------------------------------------------------------------------
Date: 2 Jun 1982 1803-PDT
Sender: LEAVITT at USC-ISI
Subject: Mice for sale?
From: Mike Leavitt <LEAVITT at USC-ISI>
Message-ID: <[USC-ISI] 2-Jun-82 18:03:15.LEAVITT>
I asked this question many months ago to no response (except people
wanting to share the results). Perhaps now.... Does anyone have any
information on good quality Mice for sale? Interface requirements,
sources, prices, etc. would be most welcome. I will be happy to share
results (if any) with the List.
------------------------------
From: decvax!watmath!csc at Berkeley
Subject: Information on mice
Article-I.D.: watmath.2548
Anticipating (based on past experience) some trouble with mailing to
the person requesting mouse info and thinking that the general
populace might be interested...
The May 10, 1982 issue of Infoworld (the one with a horde of
multicoloured mice on the cover) contains an article on mice made by
Jack Hawley, "a self- described ''great inventor'' and proprietor of
The Mouse House in Berkeley". The article states that Hawley started
out by redesigning mice for Xerox workstations and now sells the X063X
Mouse which goes for $415.
The Univ. of Waterloo Software Portability Lab received a bunch of
mice recently and is currently interfacing them to the multibus. They
are very nicely made. As I believe the interfacing effort is not
finished yet (though I work at the lab, I'm not involved with mice
yet), we'd be interested in anyone's experiences with these mice.
The Infoworld article concludes with the mention of optical mice,
developed at Xerox and apparently being made into a product by Steve
Kirsch of Sunnyvale.
Peter Rowley, Univ. of Waterloo. (decvax!watmath!csc)
------------------------------
Date: 3 Jun 82 9:40:32-PDT (Thu)
From: menlo70!sri-unix!hplabs!hp-pcd!rich at Berkeley
Subject: Re: Mice for sale?
Article-I.D.: hp-pcd.163
Jack Hawley of the Mouse House (formerly Hawley Laboratories) is
taking orders for mice. The cost is around $400. Jack used to make a
variation of this mouse for Xerox Parc. His phone number is (415)
525-5533. His address is 1741 8th St. Berkeley. I would not waste
time on any of the other groups that are advertising mice until they
can prove they are at least as good as Jack's.
------------------------------
Date: 10 Jun 1982 1944-EDT
From: Kimberle Koile <KK at MIT-XX>
Subject: DEC Personal Computer
I have a couple of questions about the DEC personal computer:
Is there any way to hang more than one terminal off of it?
Is the file handler provided by DEC adequate for a database
of about 2000 records, record size about 1000 bytes?
------------------------------
Date: 11 Jun 82 18:44:31-EDT (Fri)
From: decvax!harpo!floyd!peri!andy at Berkeley
Subject: z8000 Unix vs. 68000 Unix
Article-I.D.: peri.110
Hi,
I would like to get in touch with people who have ported Unix
to either a z8000 or a 68000 microprocessor. I would like to find out
the problems that they found and whether or not they optimized the
object code for the specific microprocessor, e.g., did they write a
compiler for the z8000 that uses the string manipulation facilities,
etc. ?
Is there any general feeling within the community which micro
is easier to port to, and which version of Unix runs better?
Thanks,
Andrew T. Rodnite
Periphonics Corp.
4000 Veterans Memorial Hwy.
Bohemia, NY 11716
(516) 467-0500 ext. 356
decvax!harpoo!floyd!peri!andy
------------------------------
End of WorkS Digest
*******************
-------
∂20-Jun-82 0206 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #61
Date: 20 Jun 1982 0338-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #61
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 20 June 1982 Volume 2 : Issue 61
Today's Topics: Mice from Switzerland?
ALSPA Micro
Books on Personal Computers/Computing?
Announcing the Xerox 1100 (Dolphin) User Group
----------------------------------------------------------------------
Date: 14 June 1982 23:12-EDT
From: Leonard N. Foner <FONER at MIT-AI>
Subject: Mice from Switzerland?
I am interested in finding out about a type of mouse that apparently
comes from Switzerland. I have heard that people in the Jericho group
at BBN are using such things... can anyone from that group or
anywhere else tell me more? I am interested in what it's like, where
one can get one, how much, etc. I don't have any more information
about what exactly I'm looking for than this... I'm relaying this
request for a friend.
Thanx much!
<LNF>
------------------------------
Date: 15 Jun 1982 1044-PDT
Sender: LUNDQUIST at USC-ISIE
Subject: ALSPA Micro
From: LUNDQUIST at USC-ISIE
Message-ID: <[USC-ISIE]15-Jun-82 10:44:32.LUNDQUIST>
Has anyone any information on the ALSPA micro-computer and its
associated word-processing package? It is made by QSA Corp of San
Diego, Cal. Any comments , leads, or other information would be
appreciated.
Chuck L.
------------------------------
Date: 18 Jun 82 15:40:47-PDT (Fri)
From: decvax!duke!harpo!floyd!trb at Berkeley
Subject: books on personal computers/computing?
Article-I.D.: floyd.290
Can you recommend a text on personal computers for a businessman who
is interested in learning about the subject so that he can get into
the field?
Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491
------------------------------
Date: 18 Jun 1982 2123-PDT
From: T. C. Rindfleisch <Rindfleisch at SUMEX-AIM>
Subject: Xerox 1100 (Dolphin) User Group
To: Dolphin-Users at SUMEX-AIM
cc: Rindfleisch at SUMEX-AIM
This is to announce formation of a network user group for Xerox 1100
workstations (Dolphins). Its purpose is to stimulate communication
and sharing between computer science research groups that are using or
are interested in these machines. It differs from the WORKS group in
that it will focus on issues particular to Dolphins rather than on
workstations in general.
Xerox PARC and EOS people are included in the distribution list to
facilitate communications about new developments, bugs, performance
issues, etc. As with all network interest groups, however, this is
*NOT* to be used as a vendor advertising vehicle.
User Group Mechanics --
1) Network Addresses:
Dolphin-Users@SUMEX-AIM For mail distributed to the
entire user group
Dolphin-Requests@SUMEX-AIM For distribution list
maintenance, i.e., additions,
deletions, problems, etc.
2) Mail Handling: SUMEX-AIM will serve as the expansion point for
routing messages to group members. We run XMAILR and so can route
between most of the current internet community.
3) Administration: Initially, messages will be sent to the list as
submitted. Depending on the volume of mail, content, etc., messages
may be collected and digested in the future.
I have assembled a list of known Dolphin users and liaisons from
various sources for this initial announcement. Please pass the word
on to others you think might be interested.
Tom R.
------------------------------
End of WorkS Digest
*******************
-------
∂08-Jul-82 0005 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #63
Date: 8 Jul 1982 0123-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #63
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
WorkS Digest Thursday, 8 July 1982 Volume 2 : Issue 63
Today's Topics:
What does DEC Want with 1000 Mice??? (2 msgs)
Cheap Track Balls?
$68K Question
End User Interface Query
Defining the Next Generation MicroComputer Operating System
Mailing-List for "List of lists" Update Notices
----------------------------------------------------------------------
Date: 30 June 1982 23:37-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: What is DEC doing with 1,000 mice?
By early next year, DEC will have over a thousand mice. Does anyone
know what they will be used on? A graphics terminal perhaps? I heard
their Smalltalk effort was a failure (too slow).
------------------------------
Date: 2 July 1982 02:13-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Mice at DEC
I just found out that the mice are for the VAX Station 100.
------------------------------
Date: 30 Jun 82 17:55:34-PDT (Wed)
From: decvax!utzoo!utcsrgv!ralph at Berkeley
Subject: Cheap track balls?
Article-I.D.: utcsrgv.446
We are looking for a tracker ball for our human factors lab. We have
found one at $4000! I find it hard to believe that video games use
devices that are of this quality and price. Therefore, anyone know of
a source of cheaper track balls?
thanks
ralph hill
computer systems research group
University of Toronto
10 King's College Road
Toronto Ontario
Canada M5S 1A4
...!decvax!utzoo!utcsrgv!ralph
------------------------------
Date: 2 Jul 82 0:29:50-EDT (Fri)
From: Frank J Wancho <wancho@BRL>
Subject: $68K Question
After wading through the intermixed series of exchanges on the MC68000
"page fault problem" some time back, I was recently asked what the
outcome was, and I wasn't sure. Would someone care to briefly
summarize without starting another flame series (if that's possible)?
The reason for concern here is that some people are proposing to
standardize on the Motorola "68" family, possibly into the late '90's.
That bothers me alot - not just because of the discussion referred to
above, but because hardware is not the thing you want to standardize -
and maybe not software either - at least not for the next twenty
years! Five years - maybe.
Anyway, the second question was: how well done are the current
implementations of the 68000 in handling the supposed page fault
"problem", especially, the Unix ports. Does the Z8000 series fare
better in this aspect? What should we look out for when evaluating
these systems for use in small-scale (4-6 user) environments?
--Frank
------------------------------
Date: 2 Jul 82 10:55:22-PDT (Fri)
From: decvax!harpo!eagle!mhuxt!mhuxa!mhuxh!mhuxm!pyuxjj!pyuxcc!adi
at Berkeley
Subject: Query : End user interface
Article-I.D.: pyuxcc.285
Does anyone in the <net-land> have some experience or thoughts on the
question below ?
Given an intelligent terminal or local/personal computer
with graphics capability (including mouse and/or touchpad
devices), which of the following is a preferred way to put
an application together for a non-computer but technical
user ? (i.e. the user is a college graduate, perhaps in EE,
ME, or some other engineering or related field, but has had
very little contact with computers.)
1. A powerful command language ( a la Unix )
2. menu driven application - usually single letter or single
word responses required.
3. menu driven - menu consisting of graphics characters
4. menu driven, but allowing pointing to an entry by the
pointing device
5. Some other method (please explain)
If you have direct answers or some pointers to literature
(preferably making definite recommendations), please respond by
mail.
Please accept my thanks in anticipation.
A. D. Ingle
...!pyuxcc!adi
------------------------------
Date: 5 Jul 82 18:13:45-PDT (Mon)
From: menlo70!sri-unix!hplabs!Peter at Berkeley
Subject: defining the next generation microcomputer operating system
Article-I.D.: hplabs.518
It is becoming clear that the state of teh personal computer,
and for that matter, the small business computer, is becoming limited
not by the hardware that abounds in the field, but by the software
that has, in some glaring examples, been written by individuals or
groups that appear to have had little idea of what the market desired.
Operating systems for microcomputers (at least the two leading ones,
CP/M and Unix, and their respective generics) have been greatly
maligned, to the point where one wonders when someone will set out to
define and implement something better.
I would like to do just that. However, one way to avoid the
problems of the "first generation" operating systems that have
prevailed in the past is to look at the market FIRST.
What I am wondering is: how many individuals out there who use
microcomputers regularly would be willing to attend a semi-formal
conference with, say, a scheduled 20-30 hours of meeting time, with
the specific intent of formulating a specification for the next
generation operating system. The intent is to base the system on what
the conference attendees decide is the need of the current and future
market.
I am willing to organize such a conference if there is a reasonable
amount of interest in attending. I would like to limit the attendance
to less than 5 individuals, if at all reasonable. Probably the best
way to do so would be to limit attendance to San Francisco Bay area
professionals. (Any thoughts on this?)
In any case, if you have any interest in this at all, send me mail,
and I will be glad to provide more details; things are currently in
the idea stage only.
Peter Henry
hplabs!pdh
PDH@SAIL (Arpanet)
real mail:
Peter D. Henry
PO Box 9932
Palo Alto, CA 94305
------------------------------
Date: 6 Jul 1982 2330-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Mailing-list for "List of lists" update notices
cc: ZELLICH
For those of you not previously aware of it, I maintain a master list
of ARPANET mailing-lists/digests/discussion groups (currently 756
lines or ~29,000 characters) on OFFICE-3 in file:
<ALMSA>INTEREST-GROUPS.TXT
For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS
login within FTP, with any password.
To keep people up to date on the large number of such lists, I have
established a mailing list for list-of-lists \update notices/. I do
not propose to send copies of the list itself to the world at large,
but for those ARPANET users who seriously intend to FTP the updated
versions when updated, I will send a brief notice that a new version
is available. For those counterparts at internet sites who maintain
or redistribute copies for their own networks (DECNet, Xerox, etc.)
and can't reach the master by ARPANET FTP, I will send out the
complete new file. I do \not/ intend to send file copies to
individual users, either ARPANET or internet; our system is fairly
heavily loaded, and we can't afford it.
There is no particular pattern to the update frequency of INTEREST-
GROUPS.TXT; I will occasionally receive a burst of new mailing-lists
or perhaps a single change of address for a host or mailing-list
coordinator, and then have a long period with no changes.
To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the
mailing-list this message appears in.
Cheers,
Rich
------------------------------
End of WorkS Digest
*******************
-------
∂10-Jul-82 2118 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #64
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #64
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 10 July 1982 Volume 2 : Issue 64
Today's Topics: 68000 Page Faults (2 msgs)
Convergent Technolgy (2 msgs)
End User Interface (2 msgs)
----------------------------------------------------------------------
Date: 8 Jul 82 14:49:43-PDT (Thu)
From: decvax!harpo!eagle!mhuxt!mhuxa!mhuxh!mhuxm!mhuxv!phw at Berkeley
Subject: Re: 68000 page faults
Article-I.D.: mhuxv.1004
References: sri-unix.2034
I have in my grubby little hands a product information sheet published
by Motorola Semiconductors on the MC68010. This processor has the
capability to run in both virtual memory mode and virtual machine
mode. It is upward compatible with the MC68000 and MC68008
processors. I have no idea of the development schedule of this
processor, but at the time of the writing of the sheet (4/82) it was
still under development.
------------------------------
Date: 8 Jul 1982 0051-PDT
Sender: BILLW at SRI-KL
Subject: 68000
From: William "Chops" Westfield <BillW @ SRI-KL>
To: wancho at BRL
Message-ID: <[SRI-KL] 8-Jul-82 00:51:11.BILLW>
Motarola has anounced 68xxx chips planned well into the mid 80's. The
68010, which will support virtual memory by instruction continuation
(so that you can read in new pages on the instruction fetch, first
operand fetch, AND second operand fetch, if need be) will be sampled
towards the end of this year or early 83. The 68010 is Pin and
software compatable with the 68000. It also includes relocateable
interupt vector tables and instructions to move data in between (for
example) user and system address spaces. Going downwards, the 68008
will be available about the same, and features an 8 bit bus and a 48
pin package, with 60% of the preformnance of the 68000. Going
upwards, they have the 68020 and the 68881. The 68000 is a full 32
bit CPU with a 32 bit data path, a 32 bit address path, on chip
instruction cache and a co-processor interface that can handle up to 8
or 16 co-processors. The 68881 is a floating point co-processor that
works with this interface. It will handle all the IEEE formats and
functions, and can be used as an IO device with earlier model 68xx(x)
processors. All the processors are upward object code compatable with
the 68000. Motarola is definitely trying to say "The 68000
architecture is good, and we are going to continue to improve and
expand upon it, so that if you commit yourself to our chips, you wont
be sorry..."
I've attended a bunch of free motarola seminars recently, and can
probably provide more detailed information if anyone is interested.
Bill Westfield
------------------------------
Date: 8 July 1982 22:31-EDT
From: Michael A. Bloom <MCB at MIT-MC>
Does anyone on this list have any experience with the workstations
offered by Convergent Technologies, Inc.?
Michael Bloom, mcb@mit-mc
------------------------------
Date: 8 Jul 1982 (Thursday) 2306-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: Re: Convergent Technolgy.
Their workstation is called the B20 and is being marketed by Burroughs
corporation.
Hank
------------------------------
Date: 8-Jul-82 0:13:12 PDT (Thursday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Query: End user interface
To: Hamilton.ES
How about ALL of the above? Why restrict the user? In the Mesa
Development Environment at Xerox, the best tools have all sorts of
combinations of command-line interfaces, forms fill-ins, "helper"
menus, programmatic interfaces, etc. True, you need to start with a
few standards, since people move between workstations at times, but
the ideal environment both permits the user to specify in his profile
his preferred setup, and also leaves the option of using other
interfaces at any time.
--Bruce
------------------------------
Date: 7 Jul 1982 2354-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Query : End user interface
To: decvax!harpo!eagle!mhuxt!mhuxa!mhuxh!mhuxm!pyuxjj!pyuxcc!adi at BERKELEY
cc: ZELLICH
I definitely would \not/ go with a menu interface of any kind; even if
it could be turned off when the user became familiar with the system.
A "menu" that can be requested by the user at any time with a
question-mark or some such, is a different thing entirely. Menus tend
to be quite cumbersome when the system has been learned, and only get
in the way of an experienced user; if turned off, then you end up with
a user interface that is too different from what the user just
learned, which isn't such a hot idea.
I don't like the UNIX style of commands because of the mnemonic (or
sometimes not so mnemonic! - but that doesn't have to be a problem
with an interface you're designing yourself) rather than English
commands. I \do/ like the pipes in UNIX, and would like to find some
way of implementing them in a system that uses English command words
with single-character-recognition/command-word-completion.
A good example of the style of command interaction I think is good is
the one used by Tymshare's Augment (or SRI Int'l or ISI's NLS). NLS
(or Augment) is a difficult system to learn, but that's because of the
new concepts required by using structured files, not because of the
style of command interaction. It is a single-character-
recognition/command-completion system, styled in a Verb-Noun pattern
(using a mouse to point to objects on the crt).
-Rich Zellich
------------------------------
End of WorkS Digest
*******************
-------
∂20-Jul-82 2236 AVB WORKS Digest V2 #64
∂18-Jul-82 1146 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #64
Date: 18 Jul 1982 1245-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #64
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 18 July 1982 Volume 2 : Issue 64
Today's Topics: Mice for Plain People
End User Interface ala Augment/NLS (2 msgs)
Correction to MicroComputer OS Conference Call
Convergent Technology Workstation Query
----------------------------------------------------------------------
Date: 10 July 1982 23:00-EDT
From: Andrew Scott Beals <BANDY at MIT-AI>
Subject: mice for plain people
I know that they are avaliable, but what is the price of a mouse a)
with approp hardware (requiring just a parallel port on the main cpu),
and b) just a bare mouse, roll your own hardware?
- Andy
------------------------------
Date: 12 July 1982 17:27 edt
From: SSteinberg.SoftArts at MIT-MULTICS
Subject: NLS
Sender: COMSAT.SoftArts at MIT-MULTICS
*from: SAS (Seth A. Steinberg)
Original-date: 12 JUL 1982 08:12:36
I noticed that NLS was mentioned. From what I have seen of it the FYI
product is more or less NLS with explicit opening/closing of subitems.
It has a MESA-like (or so I was told) editor with explicit input mode
but otherwise presented an interactive outline form which was freely
modifiable.
------------------------------
Date: 12 Jul 1982 1128-PDT
From: Feinler at SRI-NIC
Subject: End User Interface ala Augment/NLS
I have worked with several different user interfaces over the years
and I too prefer the command completion mode used by AUGMENT/NLS and
MSG. The single character (or enough characters) recognition I find
less winning because one almost always has to type spaces between the
characters which means thousands of extra keystrokes over a period of
time. In AUGMENT/NLS or MSG one types one or two letters and the
commands are completed and displayed, thus if one made a typo it is
obvious. I have never found that the command completion slows me down
although I have heard that argument from time to time.
Also, I feel I must dispell a myth about AUGMENT/NLS because I have
heard it so many times and it just isn't true. It is NOT a difficult
system to learn. I have trained several people who don't even LIKE
machines to do useful work with less than a day's training. It is
much easier to teach someone to use than say EMACS, in my opinion.
AUGMENT/NLS is a very rich set of tools all under one 'umbrella' and
it is true that for someone to learn to do everything that is doable
under AUGMENT would take quite some time since it has text editing,
programming, text processing, mixed text and graphics capabilities,
data base management, etc., etc., etc. A user can do most of what she
wants with the system rather nicely, which has nothing to do with the
fact that if one wants to program this may take somewhat longer to
learn than if one wants to do simple text editing. The point I am
making is that when comparing apples with apples (text editing with
text editing, for instance) AUGMENT/NLS is quite user friendly,
powerful, and easy to learn.
Jake Feinler
------------------------------
Date: 16 Jul 82 22:07:26-PDT (Fri)
From: menlo70!sri-unix!hplabs!Peter at Berkeley
Subject: correction to microcomputer OS conference call
Article-I.D.: hplabs.543
In my recent message to the net regarding the definition of the next
generation of microcomputer operating systems, I made an embarassing
typo that may have caused concern. When I said that I'd like to
organize a conference with about 5 people at the most, I meant fifty
(50) people! I have received several interested responses, most of
which questioned the judiciousness of a five person conference...
sorry about that.
Also, I should note that this is being done on my own personal benefit
and edification, and the project is not (currently) related to any
company.
Peter Henry
(PDH @ SAIL)
------------------------------
Date: 15 July 1982 22:27-EDT
From: Michael A. Bloom <MCB at MIT-MC>
Subject: Convergent Technology Workstation Query
To: info-micro at MIT-AI
Date: 12 July 1982 06:03-EDT
From: Steven T. Kirsch <SK at MIT-MC>
what do you want to know?
I'm particularly interested in knowing what comments or opinions other
people who have used the various versions of the CT may have. Things
such as:
* How radically has their software changed since it's introduction.
* Have other people been experiencing what Convergent refers to in
their editor documentation as 'editor crashes'?
* Have any users had problems with the file system?
* Although Convergent's documentation is fairly readable, in my
opinion, it has not always been representative of the products it
describes. In particular, Ive found that the documentation
describing process and task management facilities does not refer to
the version of the software that it came with, but rather to some
imiginary version lying somewhere in between the current version and
an as yet unreleased version (7.0). I'd like to know what
additional areas people may have found this to be true in?
* Do the Borroughs and NCR systems based on the CT use the same
operating system (CTOS)? Or do they use XENIX (as the TRW version
will, I am told)? Or still something else? Perhaps another OS built
on top of CTOS? And what experiences do have people had with
these?
* Has anyone written a decent memory management facility for CTOS?
Having to deallocate memory in the exact reverse order of allocation
regardless of what process you are just doesn't cut it.
* Has anyone written a replacement for the Convergent executive?
Especially one that spawns additional processes rather than chaining
to the desired program? What were the difficulties involved? Was
it possible with a pre- 7.0 release of CTOS?
* What opinions have you (if any) of the hardware?
* I've been experimenting with a CT workstation for a little while
now, and would like to hear what other peoples opinions of it are.
My own opinions so far are that they have some flashy software,
what looks to be a decent screen management facility, some other
good software, some pretty poor software, and overall a very poor
integration of the the various parts of the system. Particulary
troublesome have been editor crashes, HUGE task and task file sizes,
and difficulty in obtaining customer support. (They are friendly
but overloaded to the point that they /never\ return phone calls and
are almost always unavailable when called. (have others had
trouble getting customer support?) I dont feel qualified to judge
the hardware... does anyone have any particularly good or bad
feelings in this area?
I'm cc'ing this to works and info-micro, hoping to reach some
others who have experience with the CT workstation. (If you saw this
in INFO-MICRO, please reply directly, as I am not on that list.
Thanks)
Michael Bloom (mcb @mit-mc)
------------------------------
End of WorkS Digest
*******************
-------
∂23-Jul-82 1156 AVB WORKS Digest V2 #65
∂22-Jul-82 2200 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #65
Date: 22 Jul 1982 2324-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #65
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 23 July 1982 Volume 2 : Issue 65
Today's Topics: Local Swiss Mice Distributor
Low-Cost Trackballs
Lowest Possible Resolution Full Page Displays
End User Interface ala Augment/NLS (2 msgs)
Call for Papers - ACM Transactions on Office Information Systems
----------------------------------------------------------------------
Date: 19 Jul 1982 1941-PDT
From: Ignacio Zabala <IAZ at SU-AI>
I just learned of one company that sells the "swiss mouse" made by
DEPRAZ. Their address is:
LOGITECH Inc.
165 University Ave.
Palo Alto, CA 94301
Tf (415)326-3885
This mouse provides serial or parallel output and they quoted a price
of $275 per unit, lower in large quantities.
------------------------------
Date: 22 Jul 1982 1702-PDT
From: Patrick Milligan <CSD.Milligan at SU-SCORE>
Subject: Low-Cost Trackballs
To: decvax!utzoo!utcsrgv!ralph at UCB-C70
In a recent issue of Electronic Engineering Times (Issue 238, July 19,
1982, page 43), two sources of low-cost trackballs are given:
Disc Instruments
102 E. Baker St.
Costa Mesa, CA 92626
(714) 979-5300
Cost: $65.00 (single quantities?)
Litton Systems, Encoder Div.
20745 Nordhoff St.
Chatsworth, CA 91311
(213) 341-6161
Cost: $286.00 (hundreds)
------------------------------
Date: 21 Jul 1982 1353-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Lowest possible resolution full page displays
To: hedrick at RUTGERS, josh at RUTGERS
I sent a letter to the INFO-MICRO bboard a short while back about the
Corvus Concept workstation. I made a comment about the resolution
being rather low for a full page display. Admittedly I am spoiled and
ill-informed, only having experience with two full page display
devices (the BitGraph and Dolphin) each of which have 1k by 800
screens.
The question I'd like to pose is: what IS the lowest possible graphic
resolution for a full page display, assuming you are going to write
into the bitmap to create characters, and want to do things like
italic and small sized (footnote type) characters?
If possible I'd love specific observations about doing fancy
characters on a Corvus Concept (anyone a beta test site for it?).
(ron)
------------------------------
Date: 19-Jul-82 10:50:49 PDT (Monday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: End User Interface ala Augment
To: Feinler at SRI-NIC, Hamilton.ES
We've had lots of experience at Xerox with both command completion and
single character (or enough characters) recognition. We are, due to
popular demand, about to change one of our last minimum-character
command completion interfaces (the Mesa debugger) to unique prefix
recognition/ completion, for at least two reasons:
(1) command completion is more likely to drive you crazy if you ever
want to add/ delete/ rename commands or change the kind of
confirmation required. For example, with the last release "LIst
Processes [confirm]" became "List Processes" (no confirmation
required). This meant that folks typing "LIP<CR>" by habit got "List
I? Proceed [confirm]" and instantly trashed their debugging session.
(2) command files should be able to contain complete command names,
rather than cryptic characters-to-be-automatically-completed, and
should be immune to changes in the number of characters required to
disambiguate a command.
--Bruce
------------------------------
Date: 22 JUL 1982 0404-PDT
From: Reynolds at AMES-67
Subject: Re: End User Interface ala Augment/NLS
Yes Indeed, I agree...
Although I have never used AUGMENT/NLS, I did borrow the ISIS film
from Doug Englebart a few years ago and was impressed with the power
of NLS. The film does misslead one though, into assuming that you
have to learn to deal with all the complexity of NLS just to get
started, when only a subset is needed. We have had the same effect
here bringing up our interactive users on TSS, a powerful but somewhat
user unfriendly system. One has to spend some careful thinking in the
TSS case in developing a beginning subset of system commands so as not
to overwhelm the user.
Another feature (problem?) of TSS is that users can define their own
system commands (one letter commands if they wish), as a combination
of existing system commands with desired parameters, or merely rename
system commands according to their desires. This feature makes
command completion really difficult to implement. What makes it
impossible is the IBM penchant for half-duplex data communications to
ASCII start-stop, asynchronous terminals. Logging on TSS over the net
requires one to set the TIP to "transmit-on-linefeed". If one only
uses locally connected IBM 3270 (full screen CRT) terminals one can
live with a fairly crude editor, and the user interface is tolerable.
Updating a full screen at a time at channel rates kind of spoils a
person, I suppose.
Maybe this topic belongs on HUMAN-NETS, but I'm interested in inputs
on user interfaces. Let's keep them coming.
Best,
Don Reynolds
(415) 965-6444
(Reynolds at Ames-67)
------------------------------
Date: 19 Jul 1982 08:06:34-PDT
From: allegra!rba at Berkeley
CALL FOR PAPERS
The Association for Computing Machinery announces a new quarterly
acm Transactions on Office Information Systems
(TOOIS)
John Limb, Editor-in-Chief
SCOPE:
Significant and original work on analysis, design, specifications,
implementation, and experience concerning all aspects of office
information systems, including:
communication systems
data management
distributed processing
office organization
user interfaces.
SECTIONS:
TOOIS will contain the following sections:
Research Contributions
Practice and Experience
Technical Correspondence
FREQUENCY:
Quarterly. First issue dated early 1983. Projected content:
400 pages annually.
Send four copies of all papers to:
John Limb
MH 3D-479
Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ 07974
------------------------------
End of WorkS Digest
*******************
-------
∂24-Jul-82 1036 AVB WORKS Digest V2 #66
∂23-Jul-82 2314 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #66
Date: 23 Jul 1982 2336-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #66
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 24 July 1982 Volume 2 : Issue 66
Today's Topics: Administrivia
Command Completion
End User Interface a la Augment/NLS (2 msgs)
Display resolution (2 msgs)
----------------------------------------------------------------------
Date: 23 Jul 1982 2319-EDT
From: Mel <Pleasant at RUTGERS>
Subject: Administrivia
Due to a system crash, some of you may have received two
copies of the WorkS Digest Volume 2 issue 65 while others may not have
received it at all. If you did not receive your copy of the digest,
just drop me a note and I'll get it to you right away. My apologies
to those who received two copies.
------------------------------
Date: 23 Jul 1982 0836-EDT
From: Larry Seiler <SEILER at MIT-XX>
Subject: Command completion
To: Seiler at MIT-XX
A friend of mine (Mark Matson) designed a graphics editor with a type
of command completion I haven't seen discussed here. You can type as
much of the command word as you want. The command completion occurs
when you type a space or a carriage return. Then it either fills in
the rest of the word or else complains. His command set includes a
lot of multi-word commands. For example, "Set Origin 45 67" could be
typed as just "S O 45 67". With this method, adding new commands can
only cause the user to get "ambiguous abbreviation" warnings, not
accidentally trigger the wrong command. Also, it allows new users to
type the full commands, which are rather mnemonic, instead of having
to remember the abbreviations. And, of course, it has the normal
advantage of command completion - I always know what I've just done.
Larry Seiler
------------------------------
Date: 23 Jul 1982 0529-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: End User Interface a la Augment/NLS
To: Hamilton.ES at PARC-MAXC, Feinler at SRI-NIC,
cc: Reynolds at AMES-67, Zellich
True, you may have problems if you drastically change commands; this
has zapped us a few times in using Tymshare's evolving version. It
helps a lot though, if you advertise the "gotcha" type changes when
you field the new release.
Note that the Augment/NLS interface uses \full words/ in command
files, rather than single command-characters. Thus, the command files
are not at all cryptic, and tend to just bomb out rather than doing
the wrong thing if the command language changes and you forget to
update a command file.
There is no real problem renaming commands with the Augment/NLS user
interface (if the particular program is designed that way - the
"regular" subsystems aren't). The grammar parser is working from a
table describing what is to be collected from the user next, and what
to do with it. It allows not only literals in the command table, but
also variables and list-variables. Thus, in some of our subsystems,
we have allowed the users to change the standard command words by
simply carrying them as useroptions and stuffing the words into a list
structure which is passed into the grammar-table environment. You
still have the problem of a particular user not thinking too clearly
and defining duplicate command words, but that can be checked for in
the "Define" (or "Rename" or "Change Command-word", or whatever you
want to call it) command. You could \also/ check for first-letter
duplicates, and warn the user if you wanted to, so multiple characters
wouldn't be required to invoke the duplicate commands.
There are problems possible with single-character command invocation,
but you can solve most, if not all, of them by careful design.
Cheers,
Rich
------------------------------
Date: 23-Jul-82 07:50-PDT
From: Barns at OFFICE
Subject: End User Interface in NLS and Augment
Identifier: TYM-WWB-1288Q
Posted: 23-Jul-82 10:50-EDT
As one involved in the maintenance of the current Augment system, let
me add a few notes on its past and present behavior and rationale:
1) A good short description of the NLS interface is found in R. W.
Watson, "User interface design issues for a large interactive system",
AFIPS Conference Proceedings, 1976 NCC, Vol 45, pp. 357-364. It
isn't up to date, but the discussion of philosophy covers all the
issues raised in this Works exchange and is still mostly valid.
2) As that paper explains, the command recognition system was/is wired
to allow a multitude of different forms. These are derived by
run-time interpretation of a single "grammar" specification. Until
recently, the user was allowed to choose any one of 7 modes of
keyword recognition. Nowadays we do not allow this because
practically everyone used "terse-terse" and it seemed wasteful to
document and explain the other modes which hardly anyone cared about.
The machinery is still there, under program control. In fact,
additional flavors now exist.
3) The interface for direct keyboard (human) use and for process use
need not be the same. I contend that an interface which is optimal
for one is inherently bad for the other because the bandwidth of the
interfaces are so different. Processes (command files, other
programs interacting through "pipes", etc.) are relatively fast but
stupid sources of input. Humans are slower but (one hopes) more
flexible. Augment copes by using "demand" recognition (=what
Tenex/Tops Exec uses) when accepting stored commands as input,
instead of the "terse-terse" mode.
If anyone's interested in hearing more, message me...
Bill Barns
------------------------------
Date: 22 Jul 1982 2333-PDT
Sender: BILLW at SRI-KL
Subject: Re: WORKS Digest V2 #65
From: BILLW at SRI-KL
Message-ID: <[SRI-KL]22-Jul-82 23:33:00.BILLW>
In-Reply-To: Your message of 22 Jul 1982 2324-EDT
Minimum resolution for text:
Well, the minimum that most people consider a readable font is a 5x7
dot matrix, in say a 6x8 box. If you consider a full page 60 lines by
80 characters, this means the minimum you need is is 480 x 480 dots.
(not that id want to have to read that, nor does it give you much room
to play with fonts). Now you can decrease the number of horizontal
dots you nead by doing proportional spacing - I have heard of programs
for the APPLE ][ that give you 72 characters accross in only about 300
dots (?). The worst case of dor conservation ive seen was a program
for the RCA 1802 microprocess/1861 graphics chip where they tried to
cram a usable amount of text into somthing like a 64*80 bit map. A
lowercase "a" looked something like:
xx
x x eg, 3x3 dots.
xxx
It all depends on what you're willing to put up with, and how much
imagination you have. I gather what corvus has done is squeze out as
mush resolution as possible without going to a high preformance (read
modified scan rate) monitor...
Comand parsers:
I've had some experience with a beast called (modestly enough) "The
Ultimate command parser". The idea was that the parser filled in as
much of a comand as was unique as the user typed it. eg:, given
commands EXIT and EXPUNGE, when the user typed an "E", the parser
filled in the X. If the user then typed a "P", "UNGE" would be filled
in. The parser waited for a break character to confirm the commands.
The really neat part was that the parser kept track of which
characters had been supplied by who, and if the user typed characters
that had already been filled in, they were accepted and ignored. It
was interesting to use th delete key, in which case, nothing was
deleted until the command became non-unique, when it rubbed out a
whole lot. I think an example is necessary: use EXIT and EXPUNGE...
display action explanation
> prompt
>eX user typed "E" parser fills in "X"
>eX↑G user typed "F" "F" is not valid
>eX user typed "X" "X" is ignored
>eXpUNGE user typed "P" command is filled in
>eX user typed DEL rubbed out until unique
>eX user typed DEL portion is unique even without "X"
> user typed DEL all characters have been rubbed out
I beleive this parser was used in an early version of MM. I've seen it
run on TENEX, TOPS-20, TOPS-10, and APPLESOFT systems....
Enjoy
BillW
------------------------------
Date: 23 Jul 1982 0934-PDT
From: Jeff La Coss <JLACOSS at USC-ISIB>
Subject: Display resolution
To: Fischer at RUTGERS
Ron,
Your question about display resolution is one that has been
investigated for quite a long time. Basically, there are two ways to
approach the problem.
One is to have a very high resolution display. The Bitgraph
and the D0 have about 80 dots/inch resolution. The displays look ok,
right? Well, how would you feel about a book printed with EXACTLY
those fonts. Pretty crummy now, isn't it?
If you have access to a PERQ or a SYMBOLICS LISP machine, take
a look. The displays on those machines is about 100 dots/inch. Still
better, but not perfect.
The best resolution on a raster display machine that I've seen
(but not irectly) is on our Xerox penguin, which has about 300
dots/inch resolution. Looks pretty good, but it has been determined by
a bit of quickie measurement that the minimum resolution required for
"book quality" output of whatever medium is about 400 dots/inch.
The trouble with all of this is that the video bandwidth
required to do any of this is cosmic. No problem generating it (well,
maybe no problem) but displaying it is quite another matter. Building
a monitor that can swing the beam fast enough to do 1000 lines/frame
is a trick only a few vendors have managed. 300 lines/inch resolution
will require 3000 lines/frame. Ouch. In addition, the beam is going to
have to be modulated at about 250 MHz. The only way to do this will be
to up voltages/currents in the amp circuit and increase the anode
voltage- don't sit in front of this tube if you ever want to
procreate.
The other method is to do gray-scaling of the video. This
allows good apparent resolution without hairy requirements for actual
output resolution. The final product of a 512x512 display doesn't look
as good as a high-res single-layer bitmap due to the inherent
defocusing of the character edges, but it still compares favorably to
a D0 or Bitgraph.
Gray scaling does have some drawbacks- you've got to have n
bits of gray value for every displayed bit and you have to do =>
considerable <= munching to get your gray values right. "Right" is
something that is probably determined empirically. You also need a
good high-speed (relatively) D-A converter and a linear video amp in
you monitor unit to minimize tweaking of your fonts.
Further curiosity can be sated by a scanning of INTERACTIVE
RASTER GRAPHICS by Newman and Sproull- it is still the definitive text
on the subject.
Jeff
------------------------------
End of WorkS Digest
*******************
-------
∂01-Aug-82 1513 AVB WORKS Digest V2 #67
∂28-Jul-82 0128 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #67
Date: 28 Jul 1982 0257-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #67
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 24 July 1982 Volume 2 : Issue 67
Today's Topics: Books on "C" and UNIX
Command Completion (2 msgs)
Comments from Andrew Lippman's Thesis on Gray Scale Video
Monitor Resolution & Apple 72 Column Displays
Display Resolution on the BBN Bitgraph Display
----------------------------------------------------------------------
Date: 27 Jul 1982 0550-PDT
Sender: WMARTIN at OFFICE-8
Subject: Books on "C" and UNIX
From: WMartin at Office-8 (Will Martin)
Message-ID: <[OFFICE-8]27-Jul-82 05:50:35.WMARTIN>
I'd appreciate receiving any recommendations people might have as to
textbooks or reference books on the "C" language and on the UNIX
environment. My agency is just moving into UNIX; we are getting
training from Western Electric, and we have the standard Kernighan &
Ritchie book on "C"; we were wondering if anyone else has had
experience using any other materials for training or reference, either
on top of the standard documentation, or in place of it.
I'll send a summary of responses back out to the list in a week or
two, depending on the volume.
Regards,
Will Martin
USArmy DARCOM ALMSA
------------------------------
Date: 27 July 1982 05:56-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: Command completion
To: BILLW at SRI-KL
I have an alternative suggestion (for use on very-fast terminals
only): Display the complete menu of possible completions when it will
fit on the screen, otherwise prune it to show only the most popular
completions possible. (Show the n most popular commands where n is the
number that will fit on the screen.)
------------------------------
Date: 24 Jul 1982 1230-EDT
From: Larry Seiler <SEILER at MIT-XX>
Subject: More on command completion
Suppose I'm working with a command completion system and I don't know
for sure how many characters I have to type to uniquely identify a
command. Next, suppose that the system if heavily loaded. In that
case, I'll either end up typing too many characters and backing up out
of extra commands I didn't want, or else I'll type a character and
then sit and wait for the command completion to pop up. I would much
prefer a system where I can easily understand the circumstances in
which the computer is going to do something - either because ALL the
commands are abbreviated to the same length, or because commands don't
complete until I type a space, or because they don't complete until I
type something special (escape). Basically, I don't think users
should be required to memorize abbreviations, especially if those
abbreviations are subject to change. Abbreviations should be there to
speed type-in for commands the user is familiar with. Command
completion should be there to reassure the user that the abbreviation
was correct. Any comments?
Larry
------------------------------
Date: 25 July 1982 21:18 edt
From: SSteinberg.SoftArts at MIT-MULTICS
Subject: gray scale video
Sender: COMSAT.SoftArts at MIT-MULTICS
*from: SAS (Seth A. Steinberg)
Local: works at rutgers
Original-date: 25 JUL 1982 13:30:36
Andrew Lippman's doctoral (or was it his masters) thesis was on
resolution and image processing and he did a lot of stuff on drawing
lines and characters using n bits per point. From what he gathered,
having more than one gray level (in B+W:letters+lines) doesn't buy you
much. Also, the actual gray level made the screen look different but
didn't do too much to what could be read. Having an intermediate gray
level makes a lot of difference on poorly converged color monitors.
------------------------------
Date: 26 Jul 1982 at 1045-PDT
To: BillW at SRI-KL
Subject: Monitor resolution & Apple 72 column displays
From: chesley.tsca at SRI-UNIX
People often underestimate what can be done with a normal 525
line monitor. My home-built terminal can get 26x80 using an 8x10 font
(7x9 with a blank dot between characters) with a non-interlaced scan
(i.e., 262 lines). With a 6x10 (5x7 with descenders, like my
DataMedia at work), I could get 26x106. Using a slower phosphor (to
prevent flicker when using interlace), it would be possible to get
52x106 (somewhat small) characters. This isn't as nice as you can do
with an 800x1024 portrait monitor, but it's a lot cheaper...
Re Apple 72 column display: Without going into the (very)
gross details of how the Apple graphics work, you can effectively get
560x192 dots out of the Apple with certain limitations (each block of
seven dots must all be at either an even or odd locations). This
gives you approximately 7x8 dots per character to play with.
--Harry...
------------------------------
Date: 27 Jul 1982 12:51:15 EDT (Tuesday)
From: Carl D. Howe <cdh at BBN-UNIX>
Subject: Display resolution
In reply to Jeff La Coss' message concerning the resolutions
of various displays, I would like to clarify a misunderstanding that
he had. He claims that a BBN BitGraph is comparable to a D0 with a
display resolution of about 80 dots/inch. In fact, the BitGraph
resolution is almost identical to that of the PERQ and the Symbolics
machine at around 100 points/inch. The BitGraph I am typing this on
has a usable display area of 7.75"x10.75" and is 768 points x 1024
points, yielding a resolution of 99 points/inch horizontally and 95
points/inch vertically.
Carl Howe
------------------------------
End of WorkS Digest
*******************
-------
∂03-Aug-82 1204 AVB WORKS Digest V2 #68
∂01-Aug-82 1901 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #68
Date: 1 Aug 1982 1930-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #68
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 1 August 1982 Volume 2 : Issue 68
Today's Topics:
Administrivia
More on Command Completion
Menu Systems
Display Resolution (6 msgs)
----------------------------------------------------------------------
Date: 1 Aug 1982 1918-EDT
From: Mel <Pleasant at RUTGERS>
Subject: Administrivia
Hi folks,
In the past few digests, there has been some discussion on
command completion. I have also gotten some submissions concerning
bandwidth, encoding, abbreviations and Command Language Design in
general. All of these areas are relevant to the world of work
stations, however our discussions have tended to be in the more
general realm of computers at large. Since the Human-Nets digest is
alive again, I'd like to suggest that we move the more general
discussions over to it and keep our discussions more closely related
to the work stations.
-Mel
------------------------------
Date: 28 July 1982 04:39-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: More on command completion
To: SEILER at MIT-XX
Especially since we're talking about workstations here, there's no
reason in the world for command completion to be slowed down by a
"heavy load". There's only one user on each workstation (or there's
enough cpu power on a shared system to support simultaneous command
completion by all users). In a distributed system where real jobs are
done by a shared mainframe but user interfacing is done by individual
workstation micro-computers, the command completion should be done in
the micro, not in the mainframe. If possible the user interface should
do as much for the user as the DFTP program did (Those who didn't use
the Datacomputer FTP program may ignore that.), and more. The protocol
for talking between workstation and mainframe should be terse and
logical, not English; it should use short numbers (8 bits for example)
instead of strings of text to identify commands and arguments. This
reduces the load on the mainframe cpu to the bare minimum. In essence
the mainframe should execute UUOs/JSYSs/SVCs instead of
monitor/EXEC/shell commands. The user interface should translate
between text-string commands and binary UUOs. I.e. the workstation
should include all the shell. The workstation should also provide all
the user customization.
With most cpu-intensive tasks done by the single-user workstation,
i.e. there's no mainframe used normally, user-services should be the
highest priority, so that any cpu-intensive task yields to command
completion and the load presents no problem.
<Above my opinion>
------------------------------
Date: 28 July 1982 10:00-EDT (Wednesday)
From: Sam Hsu <FHsu at BBNG>
To: Robert Elton Maas <REM at MIT-MC>
Subject: Menu systems
Since this was brought up as a suggestion, what sort of experience do
people have with menu systems? Were they effective? Are they really
easier to use? I've used a Wang system (for playing games, though) and
found the menu system somewhat restrictive, slow, and tedious after a
short time, although it was helpful at first. Suppose the menu system
kept track of command usage, and displayed only a subset of commands,
say, the useful ones but not yet used a lot (assuming the often used
ones were already mastered), or the appropriate ones in a certain
context.
comments?
------------------------------
Date: 30 Jul 1982 1418-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Display resolution
Here are the responses I've gathered to my "lowest possible
resolution" query. Some of the stuff was pretty interesting.
[The first two messages have been duplicated from previous digests.
This was done so that the readers could read the entire discussion in
one sitting - Mel]
------------------------------
Date: 23 Jul 1982 0934-PDT
From: Jeff La Coss <JLACOSS at USC-ISIB>
Subject: Display resolution To: Fischer at RUTGERS
Ron,
Your question about display resolution is one that has been
investigated for quite a long time. Basically, there are two ways to
approach the problem.
One is to have a very high resolution display. The Bitgraph
and the D0 have about 80 dots/inch resolution. The displays look ok,
right? Well, how would you feel about a book printed with EXACTLY
those fonts. Pretty crummy now, isn't it?
If you have access to a PERQ or a SYMBOLICS LISP machine, take
a look. The displays on those machines is about 100 dots/inch. Still
better, but not perfect.
The best resolution on a raster display machine that I've seen
(but not directly) is on our Xerox penguin, which has about 300
dots/inch resolution. Looks pretty good, but it has been determined by
a bit of quickie measurement that the minimum resolution required for
"book quality" output of whatever medium is about 400 dots/inch.
The trouble with all of this is that the video bandwidth
required to do any of this is cosmic. No problem generating it (well,
maybe no problem) but displaying it is quite another matter. Building
a monitor that can swing the beam fast enough to do 1000 lines/frame
is a trick only a few vendors have managed. 300 lines/inch resolution
will require 3000 lines/frame. Ouch. In addition, the beam is going to
have to be modulated at about 250 MHz. The only way to do this will be
to up voltages/currents in the amp circuit and increase the anode
voltage- don't sit in front of this tube if you ever want to
procreate.
The other method is to do gray-scaling of the video. This
allows good apparent resolution without hairy requirements for actual
output resolution. The final product of a 512x512 display doesn't look
as good as a high-res single-layer bitmap due to the inherent
defocusing of the character edges, but it still compares favorably to
a D0 or Bitgraph.
Gray scaling does have some drawbacks- you've got to have n
bits of gray value for every displayed bit and you have to do =>
considerable <= munching to get your gray values right. "Right" is
something that is probably determined empirically. You also need a
good high-speed (relatively) D-A converter and a linear video amp in
you monitor unit to minimize tweaking of your fonts.
Further curiosity can be sated by a scanning of INTERACTIVE
RASTER GRAPHICS by Newman and Sproull- it is still the definitive text
on the subject.
Jeff
------------------------------
Date: 27 Jul 1982 12:51:15 EDT (Tuesday)
From: Carl D. Howe <cdh at BBN-UNIX>
Subject: Display resolution
In reply to Jeff La Coss' message concerning the resolutions
of various displays, I would like to clarify a misunderstanding that
he had. He claims that a BBN BitGraph is comparable to a D0 with a
display resolution of about 80 dots/inch. In fact, the BitGraph
resolution is almost identical to that of the PERQ and the Symbolics
machine at around 100 points/inch. The BitGraph I am typing this on
has a usable display area of 7.75"x10.75" and is 768 points x 1024
points, yielding a resolution of 99 points/inch horizontally and 95
points/inch vertically.
Carl Howe
------------------------------
Date: 28 July 1982 12:47-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
I am building text editor/formatters for personal workstations and
have also run into the problem you have mentioned.
A 1024 line 15" monitor will give you a resolution of about 100/in.
This is about right for text processing applications, though it will
be nice if someday we go to higher resolutions. At this resolutions,
most characters (even tiny ones as in super and subscripts) are
identifiable by their type face. However, strainless reading of such
text is another matter. On hardcopy, 10 point size text is easily
readable. This is not so, even on a 100/in monitor because of glare,
flicker, scintillation, discreteness of dots, light-emitting property
of CRT's and a host of other problems. My approach has been to
provide for a slightly larger than real life page size and character
size. I think most people do prefer larger characters on CRTs.
With 17" monitors your resolution is lowered to 75/in. It is still
possible to show full page text, though type face will have to be
sacrificed. Again, my approach here will be to blow up the document
even more than a 15" monitor (hence less info on page, but who cares
since there is larger screen area and a proper editor MUST have
windowing capability.
I would appreciate to share in other responses.
Bern
------------------------------
Date: 28 July 1982 12:49-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
I have not answered you question directly. I believe that 72/in
resolution is lowest minimum acceptable (Hence an 800 horizontal lines
display is the minimum). Anything less than this is really not worth
the effort.
Bern
------------------------------
Date: 30 July 1982 12:41-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Re: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
Date: 29 Jul 1982 0026-EDT
From: Ron <FISCHER at RUTGERS>
In-Reply-To: Your message of 28-Jul-82 1247-EDT
Ben,
Thanks for the reply. Sounds like a reasonable approach. I
will summarize all the replies I get to the original question and
notify the WorkS digest. Yours is the second reply. The first one
mentioned "book quality" resolution (about 300dpi) and why that is
difficult to achieve in a CRT display.
Once again, thanks very much.
(ron)
-------
I think I made a mistake in my calculations of screen resolutions.
The 19" monitor with 800 x 1024 should have a resolution of 77/in.
The 17" monitor with 800 x 1024 should have a resolution of 89/in.
The conclusions still hold though. 75/in is the absolute minimum
required for medium-quality output of typographic information. For
high-quality output, you will need either 2 bit/pixel at 75/in, or
about 140/in resolution. For book quality, I would think 200/in at
2 bit/pixel would be minimally sufficient.
------------------------------
End of WorkS Digest
*******************
-------
∂07-Aug-82 1252 AVB WORKS Digest V2 #70
∂05-Aug-82 2355 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #70
Date: 6 Aug 1982 0135-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #70
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 6 August 1982 Volume 2 : Issue 70
Today's Topics:
Menu Systems
Display Resolution (3 msgs)
----------------------------------------------------------------------
Date: 5-Aug-82 13:49:18 PDT (Thursday)
From: Hamilton.es at PARC-MAXC
Subject: Re: Menu Systems
cc: mo at LBL-UNIX (Mike O'Dell [system]),
smb.unc@udel-relay (Steve Bellovin), Hamilton.es
Folks seem to be talking about menus in what is still basically a
single-window, TTY style of interaction. I don't doubt that they
usually lose in such an environment. But having worked for several
years in the Mesa environment, where many tools let the user use any
combination of typein and pop-up "hint" menus, I can say that mouse
plus pop-up menu always wins if the typein is more than two or three
characters -- and I'm a good typist. (Assuming the menu pops up
instantly; sometimes it can take several seconds to paint, due to
swapping.) The menu item can typically be called up and invoked in
less than one second, with a single click-sweep-release of the mouse.
I believe similar figures would apply to Interlisp-D and Smalltalk.
--Bruce
------------------------------
Date: 4-Aug-82 20:42:23 PDT (Wednesday)
From: Kosower at PARC-MAXC
Subject: Display Resolution
1400 lpi seems to be the point at which further increases in
resolution are nearly impossible to detect (even for experts).
Several photocomposers (Autologic, Compugraphic, and Mergenthaler)
generate ~1400 lpi output. Although 1000 lpi might possibly be
adequate for some applications, 1400 is probably the only adequate
resolution for truly high-quality publications (e.g. books). 200 lpi
(as mentioned by Bern Niamir) is completely inadequate, as anyone who
has ever looked at XGP output will readily admit. Furthermore, while
increasing the number of gray-scales improves the effective resolution
for bit graphics (e.g. photos), it does little good where sharp
outlines are required, as in typeset material or symbolic graphics.
Making the outlines fuzzy is hardly a substitute for increasing the
resolution.
David.
------------------------------
Date: 4 Aug 82 9:46:06-PDT (Wed)
From: decvax!pur-ee!ecn-pa.rick at Ucb-C70
Subject: Re: more on display resolution
The SIGGRAPH article utzoo!henry mentions is:
Human Vision, Anti-aliasing, and the Cheap 4000 line display
William J Leler
Texas Instruments
Box 1433 M/S 617
Houston, TX 77001
It is contained in the SIGGRAPH'80 Conference Proceedings, which were
published as
Computer Graphics Volume 14, Number 3, July 1980.
It is definitely worth reading for those concerned with increased
display resolution.
Rick Adams
Purdue University
------------------------------
Date: 5 Aug 1982 07:21:35-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: resolution
In any known printing process which works by transferring pigment onto
paper, the max effective resolution is about 400 lines/inch. Note,
this is a very analog process. There is an inherent integration and
smoothing process which makes the dots disappear. As Henry Spencer
said, the printers look at the originals which are silver-based
photographic images under 100 power magnifiers and at 5000 lines/inch
they will grudgingly admit they have a hard time seeing the jaggies.
But maybe their point is well taken. While the physics of the
transfer process (surface tension, mainly) tend to round-out and
fill-in, there may be serious interaction. Maybe with smoother
initial edges you get smoother edges on the final product. I haven't
looked enough to know, and getting printers and typopgraphers to tell
you such things objectively is VERY hard. Anyone out there have any
first-hand experience?
-Mike
------------------------------
End of WorkS Digest
*******************
-------
∂07-Aug-82 1402 AVB WORKS Digest V2 #69
∂04-Aug-82 2119 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #69
Mail-from: ARPANET site RUTGERS rcvd at 4-Aug-82 1849-PDT
Date: 4 Aug 1982 2146-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #69
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 4 August 1982 Volume 2 : Issue 69
Today's Topics:
Menu Systems (3 msgs)
Display Resolution
Display Resolution - Plasma Panels (2 msgs)
Display Resolution - Phototypesetting (2 msgs)
----------------------------------------------------------------------
Date: 2 Aug 1982 08:51:22-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: Re: WORKS Digest V2 #68
In reply to Sam Hsu's question about menus....
We have used a version of "Menunix" for training a couple of new
secretaries and have had interesting experiences. (FYI, Menunix is a
menu-based shell done by Gary Perlman, et al, at ucsd.) For the first
day or two, the people liked the menus very much. However, one of
them actually wandered in and asked "Isn't there some way I can just
type the command I want to do instead of having to do the menus?" We
think this means the menu interface is nice for rank beginners, but as
soon as they learn what the most frequently-used menus have to say,
they just want to type the command and not be prompted and prodded by
the machine. On occasion, the people go back to the menu interface
when they want to learn something new, but really seem to be using it
as a help system with the ability to support examples and
experimentation. They are generally back in their normal shell within
a few minutes.
My personal biases are similar (and may be coloring the
interpretations!). The menus are nice when you are trying to get a
feel for something very alien, but as soon as you have a "working set"
in your head, you just want to type the commands. I don't care how
fast you can repaint the menus, and that I can read very quickly; I
simply want to type the commands.
-Mike
------------------------------
Date: 2 Aug 82 14:12:44-PDT (Mon)
To: works at Rutgers
From: decvax!duke!unc!smb at Ucb-C70
Subject: Re: WORKS Digest V2 #68
The specific failing of menu-based systems is that they force multiple
"mental actions" by the user. That is, even if the system responds
instantly to present a new menu, I then have to take another step --
which implies thinking about it, and probably a cursor movement (by
whatever technology you want). A simple typed command, on the other
hand, may be more work, physical and mental -- but it's one thought
sequence, and one action sequence.
--Steve Bellovin
duke!unc!smb
smb.unc@udel-relay
------------------------------
Date: 3 August 1982 03:19-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: Menu systems
To: FHsu at BBNG
It seems to me there are two main uses for a menu a) list of commands
for browsing, i.e. online documentation and b) fast invocation, i.e.
you just press one numbered key or invoke the mouse once, instead of
having to type the spelled-out command name. The first of these can
be handled by the traditional help-key instead of having an intrusive
(always there even if you don't want it) menu. In the case of the
second, the ones you use most often are exactly the ones you want in
the intrusive menu, the opposite of what you proposed.
Date: 28 July 1982 10:00-EDT (Wednesday)
From: Sam Hsu <FHsu at BBNG>
Suppose the menu system kept track of command usage, and displayed
only a subset of commands, say, the useful ones but not yet used a
lot (assuming the often used ones were already mastered), or the
appropriate ones in a certain context.
The ones you use all the time are the ones you want in the menu,
immediately available always, with minimal keystrokes/mousestrokes.
The useful ones you haven't used recently are the ones you want in the
optional help you get only when you ask for them. <My opinion of
course.>
------------------------------
Date: 1-Aug-82 18:54:57 PDT (Sunday)
From: Hamilton.es at PARC-MAXC
Subject: Re: Display resolution
To: Jeff La Coss <JLACOSS at USC-ISIB>, Fischer at RUTGERS
"The trouble with all of this is that the video bandwidth
required to do any of this is cosmic. No problem generating it
(well, maybe no problem) but displaying it is quite another
matter. Building a monitor that can swing the beam fast enough
to do 1000 lines/frame is a trick only a few vendors have
managed. 300 lines/inch resolution will require 3000
lines/frame. Ouch. In addition, the beam is going to have to
be modulated at about 250 MHz. The only way to do this will be
to up voltages/currents in the amp circuit and increase the
anode voltage- don't sit in front of this tube if you ever
want to procreate."
One answer seems to me to have multiple guns on one tube. Why not
divide the screen into nine squares and drive one high-res gun for
each? I realize adjusting all the edge convergences could be a slight
problem, but I don't see why it shouldn't be within the state of the
art.
--Bruce
------------------------------
Date: 2 Aug 1982 1445-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Re: Display resolution
To: Hamilton.es at PARC-MAXC, JLACOSS at USC-ISIB
Another way to build really high resolution displays is to keep from
using a technology that requires refreshing the screen.
One way might be with plasma panels, which are effectively their own
memory. Each dot on the display is similar to a neon bulb, with an
anode and a cathode and neon gas in the gap between. Dots are turned
on with a short higher voltage pulse and then continue to glow because
of a constant background voltage. The initial pulse ionizes the neon
in the gap, which then stays lit using the lower "maintaining"
voltage.
I assume the problem with building a high resolution display with a
plasma panel would be that as the cell size goes down it gets dimmer.
I wonder what the practical limits are for the narrowness of the gap
between the cathode/anode in a plasma panel and or the closest spacing
between cells? (do existing panels isolate the display cells with
walls of a dielectric?) Or we might be limited by the amount of
energy to be dissipated in each cell (the glow of the glass panel
cannot be brighter than the cells in it...)
Or how about other technologies; liquid crystal and electroluminescent
to name two? The Grid/Compass portable computer (or workstation if
you prefer) has an electroluminescent display of low resolution.
(ron)
------------------------------
Date: 3 Aug 82 13:28:12-PDT (Tue)
From: decvax!pur-ee!uiucdcs!grunwald at Ucb-C70
Subject: Re: Display resolution - (nf)
Having use plasma panels for 6 years (PLATO rears its ugly head), I'll
toss in what little I know about it:
The main problem with plasma panels is dot density, since when you
increase the density of the dots too much, you get "accidental"
firings of some dots. This also happens when the panels get older. At
last report, the Army had a three foot by three foot panel constructed
for high-altitude / high-resolution applications. I don't know how
many pixels wide and high it was, but I imagine it was either
1024x1024 or 2048x2048.
Additionally, several Japanese companies (Nippon Bell is one, I think)
are getting into the plasma panel market. They are trying to get color
plasma panels to work, as well as develop other fast panels. The
color panels work by putting phosphores where the dots light up and
using that energy to excite the phosphore (or so they said). The
"fast" panels they were working on at the time they came and talked to
us were called "shift panels" -- they were slightly different in
design from the standard panel. They create an image at the far right
on a 16 pixel tall space and then "shift" it over to where it should
be. This causes some really strange effects and seems to only be very
useful for alphanumerics or customized character sets. Their main
advantage is that they are much flatter than normal plasma panels and
it would be practical to make a plasma based TV.
------------------------------
Date: 2 Aug 1982 0946-EDT
From: G.Tech at MIT-EECS at MIT-AI (The Tech)
Subject: Display Resolution
Sorry this is late (coming after the summary), but seeing all the
references to "book quality" made me want to add my 2 cents:
In the phototypesetting business, very few people will accept less
than 1000 lines/inch for their originals. Two typesetters, the
Alphatype CRS and the Compugraphic 8600, generate 5000 lpi. It's
possible to generate 1000+ newspaper lines/minute at 1000lpi using a
text window of 1 inch for $70,000. (The photographic paper moves past
the window.)
Someone with better contacts in the industry may be able to provide
more info, but I'd say "book quality" is a long way off for
workstations...
-Rich$alz
------------------------------
Date: 3 Aug 82 19:34:00-PDT (Tue)
From: decvax!utzoo!henry at Ucb-C70
Subject: more on display resolution
Actually, display terminals are a *worse* problem than
phototypesetters. People doing phototypesetting have one big
advantage: almost all their stuff is intended to be reproduced by
printing processes, which cannot reproduce 1000 lines/inch. (In fact,
it's a bit peculiar that people bother investing in 5000 lines/inch
phototypesetters when all that extra resolution is totally wasted on
the final product.) Trouble is, the human eye can see 1000 lines/inch
jaggies. If you want a screen that looks like a printed page, yea
unto the very limits of the human eyeball, you are going to need *even
higher* resolution.
On the other hand, if you are a reasonable man rather than one of the
graphic-arts types who buys a 5000 lines/inch phototypesetter because
when he looks at the original (*not* the mass-production product) with
a magnifying glass he can see the dots in 1000 lines/inch output, then
you may be able to content yourself with much lower resolution. I
have heard that the critical resolution for "smooth looking" output is
somewhat dependent on the dynamic range of light intensities, and CRTs
actually are somewhat better off than paper (i.e. need less resolution
to look good).
There was a *very* interesting paper in Siggraph a year or two ago.
The author (alas, I don't remember his name, and my Siggraphs aren't
handy) claimed that standard NTSC resolution actually approaches the
limits of the human eye, if used *right*. You need a good monitor,
plus possibly some hardware fiddling so the scan lines touch each
other (normally there is black space between them). You need *at
least* 8 bits of gray scale, and your software must *USE* it properly.
Oh yes, and your D-A conversion must be calibrated properly so that
that 8-bit range really does turn into the right sort of range of
light intensity. The explanation of why this works relies on things
like halftoning effects, and I can't reproduce all of it off the top
of my head; the key fact is that the resolution of the human eye is
not a single number, but a complex phenomenon, and by doing things
right you can do an end-run around resolution limits. Don't flame to
me that it's impossible, read the article first. It's in one of the
Siggraph conference proceedings, probably two years ago, titled
something like "The 8000-line display".
Henry Spencer
utzoo!henry
------------------------------
End of WorkS Digest
*******************
-------
∂10-Aug-82 2143 AVB WORKS Digest V2 #71
∂09-Aug-82 0202 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #71
Date: 9 Aug 1982 0218-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #71
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Monday, 9 August 1982 Volume 2 : Issue 71
Today's Topics:
Menus vs. Commands vs...? (2 msgs)
Detectable Resolution after Printing (2 msgs)
Display Resolution is Relative
Pointing Device Report Request
Wanted: Info on the Pixel 100/AP...
----------------------------------------------------------------------
Date: 5 Aug 1982 1355-CDT
From: Jonathan Slocum <LRC.Slocum at UTEXAS-20>
Subject: menus vs. commands vs...?
Rather than arguing the merits of one method vs. another -- all of
which have their good points in some context -- why not center the
discussion on how the machine can "grow with its user"? It seems
obvious to me (and the loosely anti-menu folks have pointed out one
instance) that one needs a lot of help getting used to a system, but
as that happens one needs less and less help. N'est pas?
In a similar vein, it would surely be most winning to allow the user
to tailor the interface (e.g., command completion style) to his own
preferences -- and change them over time -- without writing programs/
shells/whatever.
This makes WRITING the interface more difficult, to be sure. But only
ONE need be written -- not a different one in each style. If the job
is done right, (almost) everyone should be happy.
So how does one integrate the styles in a reasonable manner? It would
seem to me that the software basis would have to be object-oriented
programming.
------------------------------
Date: 8 Aug 1982 0219-EDT
From: MINSKY at MIT-OZ at MIT-AI
Subject: menus
To: minsky at MIT-OZ at MIT-AI
I have a copy of FinalWord editor by Mark of the Unicorn staff. They
have a great, simple idea: for commands that require more than one
character, the menu appears only if you hesitate after beginning a
command. Thus the menus never bother you once you get good at using
the system.
------------------------------
Date: 6 Aug 1982 09:14 CDT
From: Johnston.DLOS at PARC-MAXC
Subject: Re: detectable resolution after printing.
I have seen, in the earlier days of computer-GENERATED typesetting
(i.e., four years ago), a printed flier from Mergenthaler advertising
their digital photocomp machines. I don't know what resolution they
used, but the rough edges COULD be detected, even after printing.
They weren't really bad enough to prevent using the system, but close
examination (no magnification, just paper close to face) revealed the
roughness. This was also from a relatively inexpensive machine (as
such equipment goes) and the fonts were recorded in only one point
size. The rest were synthesized by software from that one master,
which was loaded from floppy disk. This may have also had something
to do with the visible rough edges, more than the resolution.
Rick
------------------------------
Date: 6 Aug 1982 0713-PDT
Subject: Re: Display Resolution - PhotoTypesetting
From: NCrawford at DARCOM-KA
In response to Mike O'Dell's comments on what typographers and
printers have to say about images on photographic paper that are made
by computers - I would like to make a few comments. First, I would
like to say it has been almost 3 years since I have done any
typography, however I do understand the problems of the quality of
type produced by computer typesetting. The type of computer that sets
type a whole character at a time gives a better image than the faster
types that scan and set a line or page at a time as
- they set from the top of the characters to the base of the
characters and
- hence not giving the quality of the single image of the character
passing through the lense and onto the paper.
I can tell the difference with my eyeball without the aid of a "100
power magnifier" the laser or "jet ink" types' problem with the
fuzziness is brought about when you pick up the speed. To me, the slow
methods should be used for the "quality" applications and the faster
methods for "newspaper" quality. Maybe my knowledge is not on the
level with you guys, speaking in terms of "inherent integration", but
I do know that the "smoother initial edges" do cause a "smoother final
product", especially when talking about ruling and graphics images.
Are there any computers now that can rule forms with the quality that
an artist attains with a 0000 rapidograph? I would like to see that
kind of quality and the ability to drop type in the forms centered or
flush within those lines. Does anyone know anything about the Xerox
computer that claims to do this (saw an ad in newsweek about it)?
- Cheryl G.
------------------------------
Date: 6 Aug 1982 01:01:11-PDT
From: ihnss!houxp!dvorak at Berkeley
Subject: Display resolution is relative
All of this talk about resolution is interesting, but some notions are
not accurate--or at least not relevant. At the risk of confounding
things . . . One must be careful what types of images are used when
"resolution" is discussed; phototypesetters usually look at a greater
variety of images than (at least for the present) most of us using
workstations. For example, setting thin, oblique lines and halftones
requires higher resolution than viewing 10-12 point text (normalized
for viewing distance) on a video display. This brings up two points;
first, viewing distance must be taken into account; and second, film
and CRTs are drastically different display media.
With respect to viewing distance, humans typically view text at a
more-or-less constant subtended angle; if the text is too small, you
want to get closer; if too large, you want to move back. It all has
to do with how our eyes move when we read (the assumption is that lots
of text is to be read--a few isolated words here or there do not
matter). This is why text in books is typically 9 to 11 points (1
point = approx. 1/72 inch)--people view it from somewhere around 35-40
cm, depending upon the quality of their vision (which depends on age
even if no refractive errors are present). At 40 cm, 10 pt. type
subtends approx. one-half degree of visual angle. Stating it this way
makes things independent of the medium being viewed, which is
important because CRTs are viewed at different distances. For sake of
argument, let's say CRTs are viewed at twice the distance we read
hardcopy. Then we only need half the resolution on the screen than we
need on hardcopy. BUT this assumes the physical properties of
light-emitting phosphors scanned by a raster beam are the same as the
light-reflecting/absorbing properties of paper and ink, which is
clearly not the case.
This brings up the issue of image quality and its dependence upon the
medium used. Here I would like to argue against those that contend
that phototypesetters are not "rational "people because they want 5000
LPI on film, when that resolution is not achieved by the actual
process of printing. The graphics arts people know a LOT more about
what it takes to make high quality images than most of us; i.e., there
is a method to their madness. I won't run on about this, but given
the wide variety of images they deal with (text to halftones) and the
extreme difficulty of reproducing some of them (halftones), their
demand for >1000 LPI is reasonable. This is especially true in light
of the fact that a formal knowledge about halftone reproduction by
digital means, and our perception thereof, does not exist. This does
not justify the phototypesetters' demands for high resol., but it
makes it hard for us less-experienced to criticize (or at least it
should). And don't forget that the detail on a 2500 LPI film image is
somewhat degraded in making the master, again in the offset process,
and again in the ink-paper interaction; thus to get 500 LPI on
calendared paper might well take much more on the original film. Yet
another consideration is that they work at various % of original. So
let's withhold at least some of the slander; those guys are in
business, so their bucks are where their LPI are.
Getting back to the generic issue of 'resolution' -- I have visually
scaled a variety of text images at various resolutions, with final
reproductions on high-resolution photo paper. Images above about 600
per inch were essentially indistinguishable from images at about
1200. Remember--these are photographic comparisons--and other display
media (CRT, laser printing, etc.) will not be as high quality as
photography--so that on a CRT, 300 per inch might well be
indistinguishable from an "analog" image on a phosphor at "infinite
resolution," and 200 per inch will look pretty darned good. Once
again, the qualifier is that the displayed image is text of various
point sizes, styles and faces.
By the way, up until recently, phototypesetters laid out pages using a
display that was not a bit-mapped representation of the final page,
but a crude symbolic representation thereof. While 200 per inch on a
CRT wouldn't hold a candle to images on film, any typesetter would
like to have a terminal that could display 200, thereby affording a
more realistic "preview" of what the page was really going to look
like.
In summary, resolution is relative, and what resolution is "necessary"
is dependent upon the image being displayed, the medium used to
display it, the observer viewing it, and the application. This is why
200 per inch would suffice as high quality for most CRT-based
workstations, but 800 per inch is insufficient for phototypesetting
pages with pictures.
Chuck Dvorak (houxp!dvorak)
Bell Labs
------------------------------
Date: 7 Aug 1982 at 0027-PDT
From: hampton at ACC
Subject: Pointing Device Report Request
cc: UNIX-Wizards at SRI-UNIX
Can anybody out there remember a (Bell Telephone Labs, I think) report
contrasting the various pointing devices ( Trackballs, light-pens,
mice, etc.)? A copy of the report or a pointer to it would be
appreciated.
------------------------------
Date: 5 Aug 82 16:37:13-PDT (Thu)
From: decvax!harpo!npoiv!npois!cbosgd!nscs!jpj at Ucb-C70
Subject: Wanted: Info on the Pixel 100/AP...
Greetings! I just received some information about a UNIX/System III
Multi-user configuration built around a machine called the Pixel
100/AP. This is what the system looks like:
100/AP (sic) Supermicrocomputer (68K/8 Mhz)
1 mByte 150ns dynamic RAM
128k I/O processor memory
40 mByte Winchester disk w/controller
2 x 630k Diskette drives
8 x Pixel terminals (!)
8 x RS232 ports
2 x parallel ports
UNIX System III
Choice of programming language (includes 'C', UCSD Pascal...)
(And the bottom line ...) Price = $19,900.00
Well! Has anyone heard of these folks? Better still, does anyone
have any experience with this stuff? To get 8 users on a UNIX system
for ~ $20K seems hard to believe. Comments please - I'm in a bit of a
hurry!
Thanks in advance...
Jim Jenal
BTL/CB (but not for long...)
------------------------------
End of WorkS Digest
*******************
-------
∂11-Aug-82 1313 AVB WORKS Digest V2 #72
∂11-Aug-82 0136 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #72
Date: 11 Aug 1982 0227-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #72
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 11 August 1982 Volume 2 : Issue 72
Today's Topics:
Response to Queries - Pointer Device Report Request & Pixel,
References - Mice-&-Men & Resolution,
Languages - Ada on LISPM,
Display Resolution - Typography,
Menu Systems - Bandwidth Problems
----------------------------------------------------------------------
Date: 9 Aug 1982 17:45:26 EDT (Monday)
From: David Mankins <dm at BBN-RSM>
Subject: re: pointer device report request
To: hampton at acc
Two papers discussing selection of text using various pointer devices
(mouse, velocity joystick, light different flavors of function keys):
CARD:
Card, S.K., English, W.K. and Burr, B.J., "Evaluation of mouse,
rate-controlled isometric joystick, step keys, and text keys for text
selection on a CRT," in \Ergonomics/, 21, 8 (1978), pp. 601-613.
ENGL:
English, W.K., Engelbart, D.C., & Berman, M.L., "Display selection
techniques for text manipulation," \IEEE Transactions on Human Factors
in Electronics, HFE-8/, 1 (March 1976), pp. 5-15.
CARD, in summary (from a human factors tutorial I took at Siggraph):
for time to locate text:
mouse < velocity joystick < text keys < step keys
for errors in locating text:
mouse < text keys < joystick < step keys
learning improvement:
beginner expert
mouse 2.2s 1.3s
joystick 2.2s 1.6s
text keys 3.9s 1.9s
step keys 3.0s 2.3s
"Step keys" are the little arrow keys, up, down, left, right, one
step. "Text keys" are function keys "next word", "next paragraph",
"next page", etc.
ENGL, in summary:
For experienced users:
mouse < light pen < joystick (time)
mouse < light pen < joystick (errors)
For inexperienced users:
(mouse, light pen) < joystick (time)
mouse < light pen < joystick (errors)
The human factors guy didn't know of any studies comparing track balls
to mice, et. al.
------------------------------
Date: 10 Aug 1982 01:08:12-PDT
From: G.dag at Berkeley
Subject: Pixel
Pixel is put out by a company in Andover Mass called Instrumentation
Labs. I remember at one time (Marchish) seeing their system and being
un-impressed. The Unix implementation works rather well, but I did
not see it with many users. At the time, they were producing
relatively few and focusing much time on getting stuff out the door.
I do remember I was somewhat disproportionally upset with their
terminal...I believe it was 80 by 24 or 25 and looked kind of pretty,
but I don't think it had any function keys or any other additional
neat features. That's about all my foggy memory will tell me.
By the way, Pixel is a division of IL, as well as being put out by
them.
Good luck,
David Gewirtz
------------------------------
Date: 9 Aug 1982 1153-EDT
From: WITTMAN at RU-GREEN at RUTGERS
Subject: mice-&-men, resolution
The JULY Mini-Micro Systems magazine has a list of suppliers of
graphics equipment such as track-balls, mice, joysticks, etc - (Page
176, I think).
That issue also says a few words about resolution, more or less off
the cuff. (I believe it occurs in the discussion of 3-D simulation
and how to fool your brain).
Barry
------------------------------
Date: 8 Aug 1982 2316-EDT
From: Mark L. Miller <X.MILLER at MIT-OZ at MIT-AI>
Subject: Ada on LISPM
To: SSteinberg.Softwares at MIT-MULTICS
In reading over old WorkS mail, I noticed that you predicted that
someone would construct an Ada front end for the LISPM (as evidence
that LISPM's are not really limited to LISP at all). Purely as a
matter of information (and not for commercial gain), I thought it
might interest you to know that someone is. Computer*Thought
Corporation plans to have an Ada interpreter (via src-to-src
translation) within a few months, as one module of a larger project.
This would probably not be made available as a separate product unless
there were considerable interest. If interest were extreme, a
compiler and/or micro-code extensions might be developed as well. The
remarks about LISP's "semantic space" do indeed reflect some of the
considerations used in selecting the LISPM for our initial
implementation. (This is not to say that translation from Ada to LISP
is a simple matter!) I hope this contribution to the discussion helps
in understanding the unique benefits of LISPM-style workstations.
Anyone interested in more information about our projects or use of the
LISPM should probably contact me directly (214-424-3511) rather than
the whole list.
Regards, Mark
------------------------------
Date: 9 Aug 1982 08:43:20-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: Re: Display resolution
Heaven forfend that someone took my comments about typographers as
being slanderous!! The recent discussion about the inherent quality
decay through the reproductive processes forcing resolution are
clearly right. I was just trying to point out what the fundamental
physical limits of ink-on-paper resolution were. My comment about
"100-power magnifiers" intended to imply how demanding they are of
quality, not to ridicule them. As others have discovered, designing
beautiful typography is MUCH harder than you can imagine, and I have
the greatest respect and admiration for the people who make beautiful
fonts appear on the final page.
We have a graphics artists in residence here in CSAM and I will ask
him to submit some comments to this list.
-Mike
------------------------------
Date: 8 Aug 82 12:28:01-PDT (Sun)
From: decvax!utzoo!utcsrgv!utcsstat!wagner at Ucb-C70
Subject: Re: More on Menu Systems
I think the biggest problem with menu systems is display bandwidth
related. The first good menu system I used was SPF on channel
attached 3270s. The menus never got in the way - the data rate of such
a device is roughly half a megabyte per second. Try using the same
system at 4800 baud (i.e. about 500 chars/second - 3 orders of
magnitude slower) - suddenly I understood why the half of the computer
center located remotely couldn't stand SPF.
One of the features that ameliourates the problem a bit is a way of
stepping through common menu sequences without display of intermediate
menus. In SPF, if you remember where you want to go, you can
concatenate menu replies (sort of like UUCP routings - utzoo!decvax
means send to utzoo, having stripped off utzoo so the next guy will
re-read and send to decvax).
IMS is a menu based database system. One of the things you can do to
speed up menu response is run your remote terminal on a micro called a
system/3 (which supports 8 or so terminals and a line back to the
mainframe). In the morning, when IMS wakes up, it sends prototype
menus down the phone lines to all its system/3 sites, who store it
locally on disk or in memory (i don't remember which). Then, when IMS
feels the need to show the user menu X with fillins, menu X is
condensed to 3 characters from the more normal 100 or so, and flash!
up it goes. The fillins, of course, still go up slower. Too bad it
can't huffman encode them.
Enough.
Michael Wagner, UTCS
------------------------------
End of WorkS Digest
*******************
-------
∂16-Aug-82 1005 AVB WORKS Digest V2 #74
∂15-Aug-82 1959 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #74
Date: 15 Aug 1982 2217-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #74
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 15 August 1982 Volume 2 : Issue 74
Today's Topics:
Menu Systems - Menus vs Typing,
Hardware - Mice Facts & Mice vs the World
----------------------------------------------------------------------
Date: 13 August 1982 1009-EDT
From: Hank Walker at CMU-10A
Subject: menus versus typing
I don't use an Alto often enough to know whether a menu-driven system
is the best for everyday use. I do know that it is the best when
you've forgotten all the commands for that particular system.
An area where I claim menus are preferable over a keyboard are in
graphics systems. In particular, VLSI layout systems. You spend most
of your time moving the mouse (tablet puck in our case) around
clicking tablet buttons. In the particular system that we use
(Caesar), there is no menu on the screen. The system is written so
that you can avoid the keyboard almost all of the time, but as the
design becomes more and more complete, I find myself using the
keyboard more often, since I need to use more complex commands.
Everyone that I know who uses Caesar complains about this. They want
a menu for the most common commands. Setup and cleanup commands can
of course stay on the keyboard since they are rarely used.
From my own experience using other layout systems that are menu
driven, I know that they increase your performance by eliminating the
need to take your hand off of the puck (I don't type well with only my
left hand).
------------------------------
Date: 13-Aug-82 10:52-PDT
From: DAUL at OFFICE
Subject: Mice Facts
If anyone is interested in going for references, you might go to the
source, Doug Engelbart (Engelbart@office). He is the mouse-daddy.
------------------------------
Date: 11 Aug 82 9:00:53-EDT (Wed)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
Subject: Mice vs. the world
There was a paper at the Human Factors in Computer Systems conference
recently held at Gaithersburg, MD which reported that mice were a win
only if the operator's gaze never left the screen. For applications
where the operator does look back and forth from on screen to off
screen (such as order entry or forms fill out) re-acclimatization was
needed each time the hand returned to the mouse. The problem
apparently was that there is no necessary connection between the mouse
and the screen position, so that hand-eye coordination must be
re-established each time the eyes leave the screen. Cursors arrows
and light-pens have no such problem (only other problems..). The
study was by a group at Social Security evaluating Xerox Alto's for
forms fill out.
This may not matter for personal workstations, since the
screen should be a sufficiently powerful and rich environment that
looking away should not be necessary. All I can think of is entering
text, which can't be done with anything but a keyboard anyway.
------------------------------
End of WorkS Digest
*******************
-------
∂18-Aug-82 2239 AVB WORKS Digest V2 #73
∂13-Aug-82 0541 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #73
Date: 13 Aug 1982 0029-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #73
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 13 August 1982 Volume 2 : Issue 73
Today's Topics:
Queries - Positioning Device Hookups,
Response to Queries - Pointer Device Report,
Display Resolution - Paper on anti-Aliasing,
Hardware - Mouse Controllers,
Menu Systems - Recall vs Recognition &
Intelligent Menu Syntax & Is it Worth it?
----------------------------------------------------------------------
Date: 10 Aug 82 11:03:12-PDT (Tue)
From: decvax!wivax!ss at Ucb-C70
Subject: Positioning Dev. Hookup?
Cursor positioning devices interest me, but I don't know how they
attach to a system/terminal. Would anyone enlighten me? Is it
attached to a terminal, or a tty-port, or directly to a bus? For
example, if I wanted to use a cursor-positioning-device with my vt100
attached to my unix system, how would it be hooked up?
Thanks, in advance
Sid Shapiro -- decvax!wivax!ss -- Wang Institute -- (617)649-9731
------------------------------
Date: 10 Aug 82 22:13:09-PDT (Tue)
From: decvax!pur-ee!purdue!cak at Ucb-C70
Subject: Re: pointer device report request
I seem to recall that there was an invited lecture by Allen Newell of
CMU at this year's Computer Science Conference (in Indianapolis) in
which he talked about research they (or someone else) performed
showing that the mouse was the lower bound for a pointing device; you
can't get better than one.
Sorry, but I don't have a more specific reference.
Chris Kent, Purdue CS
------------------------------
Date: 10 Aug 82 18:04:11-PDT (Tue)
From: decvax!duke!unc!smb at Ucb-C70
Subject: Paper on anti-aliasing
William Leler -- the author of the paper on "the Cheap 4000 line
display" -- is now at the University of North Carolina. His mailing
address is:
duke!unc!wm (uucp)
wm.unc@udel-relay (ARPA)
He's out of town at the moment, but is checking in to read his mail.
------------------------------
Date: 11 August 1982 0758-EDT (Wednesday)
From: Alan.Lesgold at CMU-10A (N981AL60)
Subject: mouse controllers
A friend of mine, Dick Wolf, has been building a variety of mouse
controllers for smaller microcomputer systems (e.g., ibm pc, apple,
s-100 bus). These allow attachment of the Hawley mouse to systems
otherwise unable to use them. In development are controllers with
greater intelligence, more modes of operation, and standard
interfacing (e.g., rs232). For information, contact Random Access,
Inc., 246 Highland Road, Pittsburgh, PA 15235.
------------------------------
Date: 11-Aug-82 12:01AM-EDT (Wed)
From: John Black <Black at YALE>
Subject: Menu systems
People have been talking as if menus were necessarily good
things, except that they might sometimes slow down expert users. I
submit that menus can also lead to worse performance than merely
allowing users to generate commands. This relates to an issue in
cognitive psychology called recognition failure of recallable words.
Menu systems rely heavily on recognition memory: i.e., you have to
look at the list of commands on a menu and recognize the appropriate
one. Without a menu, on the other hand, the user has to recall the
appropriate command.
Well, for a while psychologists thought that recognition was
always better than recall (i.e., that menu systems were better), but
then cases were found where people could recall something learned
earlier while failing to recognize it. This somewhat paradoxical
behavior occurs when the context in which a person is trying to
recognize something emphasizes a different perspective than that in
which the material was learned. Let me give an example using a
fictional text editor. Suppose this editor uses the standard sort of
terminology -- namely, insert, delete, replace, etc. Now, if a user
wanted to add a letter on the end of a word (e.g., make the word
plural), then he or she would probably have little trouble recalling
"insert" as the correct command. However, suppose the user was
confronted with the following menu:
insert
delete
replace
append
preface
Now the user might well fail to recognize the correct command --
probably even erroneously choosing "append." But surprise, append and
preface refer to adding lines to the end and beginning of a file. The
problem here is that the presence of append and preface on this menu
emphasize the meaning of insert as putting something in the middle
rather than as adding anything. Thus unless one is very careful it is
easy to design menus that users will find confusing in this way --
particularly, novice users that the menus are supposed to be so
helpful for. This example is simple, but the potential confusions are
not always so easy to see.
------------------------------
Date: 11 Aug 1982 22:31-EST
From: cak at Purdue
Subject: Menu Systems
I have good things to say about my past experience with menu systems,
but the application I was involved with was a little bit different
from what we've been discussing.
About 5 years ago, I worked on a menu-based system of applications to
help engineers to do their jobs better. The applications were
typically either database access routines (find the drawing number for
machine foo at plant bar that does grog) or calculations such as belt
length or a desk calculator -- they were all fill in the blanks, and
the computer fills some more in for you.
The applications were arranged in a tree-like structure; menus at
internal nodes, applications at the leaves. The system started you at
some level, usually within a menu. At this point, you could choose an
item on the menu by typing the number that appeared next to it, or
could go directly to any application or menu by typing in its name.
This was key to satisfying more experienced users. Once they knew
what they were doing, they could move around the tree very easily
(getting up a level was one keystroke). They didn't have to go down
the tree one level at a time, if they didn't want to.
Of course, these types of applications are different from typical
programming tasks. I'm not convinced that an analogous system can be
developed. Filling in the blanks for simple commands like "delete
this file" is a pain, once you know how to do it.
For example, National Semiconductor builds a microprocessor
development workstation called the Starplex; it provides menu front
ends for all the system commands, but has a command line processor as
well. If you type the command with no arguments, you get the menu.
That's pretty nice; we were able to sit down and use it right away,
without the manuals. Unfortunately, the command line syntax is so
cryptic that you end up using the menus all the time -- which is
unfortunate. (Actually, the only thing really nice about the Starplex
is the menu system; the rest is pretty painful. Microprocessor
companies are very much behind the current state of the software and
workstation art.)
Cheers,
chris
------------------------------
Date: 11 Aug 82 9:50:19-PDT (Wed)
From: decvax!harpo!ihps3!ihldt!ll1!jmr1 at Ucb-C70
Subject: RE: menus and commands
The system that you described regarding a menu driven system that
allowed the experienced user capability to by-pass the tedious
stepping through the menus sounds pretty nice....except...I wonder is
it really worth all the overhead it would cost to make it as flexible
as you say.
I'm one that believes in menus (what I like to refer to as intelligent
menus) to interface to users who should not be expected to understand
or learn commands and all their options (menus are ideal for use in
application systems), but......they do take-up a lot of overhead...
My feeling is that if it can be avoided menus should only be used as
interfaces to certain complex programs or tasks that require a lot of
options.
John Reese
ATT Long Lines
Chicago
------------------------------
End of WorkS Digest
*******************
-------
∂23-Aug-82 0545 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #75
Mail-from: ARPANET site RUTGERS rcvd at 22-Aug-82 2329-PDT
Date: 23 Aug 1982 0230-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #75
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Monday, 23 August 1982 Volume 2 : Issue 75
Today's Topics:
Queries - The New Wicat 150 System,
Replies to Queries - The New Wicat 150 System,
Programming - ADA on LISP Machines,
Hardware - Mice vs the World,
Technology - The Apple "Lisa"
----------------------------------------------------------------------
Date: 13-Aug-82 4:05PM-EDT (Fri)
From: John Black <Black at YALE>
Subject: Wicat
Does anyone have any experience with the new redesigned Wicat 150
M68000 based system running Unisoft Unix? Does anyone know how
different it is from the older Wicat systems?
------------------------------
Date: 21 Aug 1982 0624-MDT
From: Martin.Griss <Griss at UTAH-20>
Subject: Wicat 150
We have just received a Wicat System 150, after having a System 100
for some 9 months. We have not had much time to experiment with it
yet, and are still running the MCS operating system. The package
seems MUCH improved (we have 1 floppy, 15Mb disk and 1.5 Mb memory)
in the single desk-top unit, and it is attracting more interest than
the 100 did.
We are moving our Portable LISP (PSL) to it, and will gain
experience rapidly. Our LISP runs on Apollo DOMAIN's, and a smaller
version does run on the System 100. We hope to receive Wicat's Unix
shortly (I thought it was internal, not UNISOFT).
I expect to have some more opinions in a few weeks.
------------------------------
Date: 17 August 1982 19:27-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: Ada on the Lisp Machine
To: INFO-ADA at MIT-MC, X.Miller at MIT-OZ
(Response to 8 Aug message to Apollo list, redistributed to Ada
list.)
It's interesting to hear about the Ada front end for the Lisp
Machine, but what -are- the "unique benefits of Lispm-style
workstations" here? And for that matter, why perform
source-to-source translation? You presumably lose the main
advantage of interpretation, namely being able to debug in the
source language. I can understand re-microcoding LispMs to support
Ada, but then how much of the Lispm environment would remain
applicable? After all, there are lots of user microprogrammable
machines around.
Stavros Macrakis
Harvard and Intermetrics
------------------------------
Date: 17 Aug 82 9:15:37-PDT (Tue)
From: G.cliff at Ucb-C70
Subject: Re: Mice vs. the world
This article ended with "...I can think of is entering text, which
can't be with anything but a keyboard anyway.". Ugh. How many
times have you been frustrated with this incredibly slow way of
entering things? Everytime I want to copy a published algorithm I
either have to copy it by hand (tiring and error-prone) or send away
for a tape and go through that hassle. Or maybe you only have a
printout of an old file you never thought you'd want... The uses
for a data-reading machine are endless, when are we going to get one
for a reasonable price? Or maybe that question should be when is
this type of machine going to be considered an integral part of any
computer center, at (almost) any price? (oops, I mean integral) I
hope soon...
-Cliff (ucbvax!g:cliff)
------------------------------
Date: 19 Aug 1982 2207-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Good rumors
To: info-apple at BRL
I have heard from a reliable source that there will be a
SmallTalk-80 implementation for the Apple "Lisa." There is however
some question as to whether it will be fast enough. This aside from
the problem of what Xerox will decide to do with SmallTalk as a
whole (sell it, public domain, etc.).
This lends weight to arguments that the "Lisa" will have a fabulous
graphic display. I believe it was mentioned here that it is
supposed to cost about $10k. This is unfortunately becoming a
"market price" for workstations, i.e. personal machine of reasonable
power with graphics display.
Anyone want to expand on the "MacIntosh" rumor, that there will be a
stripped down Lisa built for home use (or at the least be cheaper)?
Please reply to WORKS at RUTGERS also.
(ron)
------------------------------
End of WorkS Digest
*******************
-------
∂19-Sep-82 1453 AVB WORKS Digest V2 #77
∂08-Sep-82 1844 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #77
Mail-from: ARPANET site RUTGERS rcvd at 8-Sep-82 1105-PDT
Date: 8 Sep 1982 1406-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #77
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 8 September 1982 Volume 2 : Issue 77
Today's Topics:
Technology - User Interfaces,
Hardware - Mice vs the World & Swiss Mice &
The Fortune WorkStation,
Programming - Screen Editors
----------------------------------------------------------------------
Date: 20 August 1982 2038-PDT (Friday)
From: davidson <sdcsvax!davidson@nprdc>
To: Human-nets at Rutgers
Subject: Text input CAN be done with other than 2 handed keyboards
You can use a chord keyboard with one hand and a mouse with the
other (5 buttons on the left hand plus three on the mouse gives you
plenty of codes). If you're using a light pen, you can use either a
chord keyboard or simply handwrite. Hand printing recognition is a
solved problem (at least for a known writer), although it is
certainly slower than a keyboard -- although I don't know if anyone
has investigated the possibilities raised by augmenting the alphabet
with special (drawn) symbols for special purposes. Does anyone know
of any workstations which make significant use of handwritten input?
I suspect that a mouse plus chord keyboard is the best available
technology for general computer work. You can also shift your mouse
hand to a second chord keyboard when you're typing straight text:
The extra codes allow you to use lots of abbreviations.
------------------------------
Date: 23 Aug 82 11:11:44-EDT (Mon)
From: Don Cates <dcates@Darcom-HQ>
Subject: Re: Mice vs the World
The first time I saw a system that allowed the input of documents
with other than keyboard or magnetic entry was at Micronet, Inc.,
"the Paperless Office", Watergate Mall, 2551 Virginia Ave., N.W.,
Washington, D.C. 20037 telephone (202) 333-4800. They have an
Optical Character Reader (OCR) Scanner that is programmable to
accept new fonts. Output from the system can be placed on microforms
in an OCR font that can be printed by an OCR reader/printer and
scanned again for re-entry. The equipment prices are obviously
above that of a home computer system for the time being but
organizations may be able to use it with service center or contract
approaches. Micronet continually schedules tours through their
facilities if your interested.
Don Cates
------------------------------
Date: 31 Aug 1982 11:45:19-EST
From: Chris Kent <cak at Purdue>
Subject: Swiss Mice
Could someone send me the address of the company in Switzerland that
is purveying mice? I can't seem to find it in my records. I want to
put a mouse on my new terminal, but the $415 Jack Hawley is charging
is a bit too steep for my budget. I seem to recall a figure of $275
from Switzerland.
Cheers,
chris
------------------------------
Date: 5 Sep 82 14:40:09-EDT (Sun)
From: Ron Minnich <minnich.EE@UDel-Relay>
Subject: Fortune workstation and the $10K question
I finally got around to seeing a Fortune the other day. It is a
real nice little machine, and appears to be running a fairly
straightforward, up-to-date version of Unix(there is even a
/usr/ucb directory). The machine I saw had an eight Mb hard disk, 5
1/4" floppy, 1/4 Mb memory, eight unused expansion slots, and a
price of about $9500. Available options are high-res display (no
numbers on this), 2 or four RS-232 ports per expansion slot- 2/$395
or 4/$495, more memory and of course more hard disk. The built-in
controller will support up to three more hard disks. It does not
look like they sell different Unix's for single and multi-terminal
users, so one could buy an RS-232 board, hook up a terminal, and
run. All the pieces are connected by phone-company style modular
jacks.
Does anyone out there know what sort-if any- memory management
this machine provides. Is it possible for a runaway program to write
over the kernel?
Which brings me to the $10K question:
Are there other machines that provide more for the money? The
Wicat 150 looks like a pretty good deal. How is the Unix that runs
on it? Will the Lisa run Unix? Smalltalk is all well and good, but
for that price I want Unix as well.
Comments, anyone?
ron
------------------------------
Date: 29 August 1982 06:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: There's no such thing as a screen editor..
To: DEG at SCRC-TENEX
It is true that most programs treat their terminals like model 35 or
37 (not 33) TTYs (i.e. upper and lower case, unlike the 33). That
is because most systems don't implement primitives for screen
management, but do implement primitives for reading and printing
characters sequentially TTY-style.
TTY-style does have two advantages:
(1) It's easier to document a program if interactions run down the
page, so you can simply print the input and output in two colors
to explain the whole example. Mouse/cursor interactions are harder
to document in hardcopy.
(2) When you make a mistake you can see it still in the transcript
before it rolls off the screen. With screen-editing the stuff you
did wrong isn't in any particular place and in fact might be
totally invisible even immediately after the error.
Thus if it isn't strictly necessary for the application to use
random screen access, TTY-style access may be chosen even when
random screen access is available.
------------------------------
End of WorkS Digest
*******************
-------
∂21-Sep-82 1815 AVB WORKS Digest V2 #57
∂28-May-82 0131 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #57
Date: 28 May 1982 0219-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #57
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 28 May 1982 Volume 2 : Issue 57
Today's Topics: Cost Driven Architectures
WorkStations vs Terminals
Distributed 8's vs Shared 16's
UNIX on a SUN board? (2 msgs)
68000 Smalltalk Query on SUN WorkStations
Sun WorkStations
----------------------------------------------------------------------
Date: 25 May 1982 03:25-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Cost Driven Architectures
To: CAULKINS at USC-ECL
cc: Deutsch at PARC-MAXC
Sharing disks via Ethnernet or other local net is one thing, but
sharing power supplies is quite another. Workstations have to be VERY
close together to share power supplies effectively. Like I could
imagine an Ethernet spanning an apartment complex or highrise office
building, but running 5-volt 12-volt and CRT power from the basement
to the top floor of a highrise or between apartments probably couldn't
be retrofitted into existing buildings safely. Thus I would imagine
there's a market for self-contained (except for disk&printer)
workstations.
------------------------------
Date: 25 May 1982 19:02 PDT
From: Deutsch at PARC-MAXC
Subject: Re: WorkStations vs Terminals
Re BILLW's points:
1) Be careful not to compare apples and oranges. I deliberately chose
to compare character-oriented terminals with character-oriented
workstations, not with bitmap workstations which are more expensive
for many reasons. I assumed that Dave Caulkins was doing the same.
Bitmap terminals are still quite expensive, e.g. the BBN BitGraph
which sells for about $3K.
2) Same point about the mouse -- not comparable to terminals. The
Lisp Machine "space cadet" keyboard is not at all typical of
workstations.
3) Power supplies: The Sun workstation -- bitmapped, mind you, and
based on the Multibus -- uses only a single +5v supply. It may not be
typical, but it is an existence proof. The other point about needing
a non-trivial power supply in the first place is well taken.
------------------------------
Date: 21 May 1982 1050-EDT
From: WITTMAN at RUTGERS
Subject: distributed 8's vs shared 16's
Can anyone out there discourse on the relative merits of a distributed
8-bit system (DataPoint's ARC, Televideo's 800 series, etc) versus a
16-bit multi-user micro (eg, LSI-11 or MC68000 systems)? My guess is
that the distributed 8's become more cost-effective for some
relatively small number of users, but my main interest is response
time on concurrent access to a central (shared) file with a server.
Just how much more responsive is 16 over a competent 8 (user
perception)?
Wittman at Rutgers
------------------------------
Date: 22 May 82 8:13:00-PDT (Sat)
From: decvax!harpo!zeppo!whuxlb!mhb at Berkeley
Subject: UNIX on a SUN board?
Article-I.D.: whuxlb.258
Rumor-control says that someone (at MIT?) has brought up some flavor
of UNIX on a SUN-board based computer. We would like to buy one.
Mike Bianchi
harpo!whuxlb!mhb
(201) 386-2988
------------------------------
Date: 24 May 82 15:41:28-PDT (Mon)
From: decvax!harpo!floyd!vax135!lime!houxg!houxi!houxn!hsc at Berkeley
Subject: Re: UNIX on a SUN board?
Article-I.D.: houxn.163
We also would like to buy one.
H. S. Cohen
houxn!hsc
LZ1C314 x6059 or FJ1A132 x5062
------------------------------
Date: 25 May 1982 1624-PDT
Sender: RENTSCH at USC-ECL
Subject: 68000 Smalltalk query
From: RENTSCH at USC-ECL
To: Sun at USC-ECL
Message-ID: <[USC-ECL]25-May-82 16:24:36.RENTSCH>
USC has toyed with the idea of doing a Smalltalk implementation on our
soon to be delivered Suns. Recently I got a query about just how to
do a Smalltalk implementation (he wanted pointers to more specific
information than the BYTE articles) for the 68000. (The query came
from outside the ARPA community.) We got to wondering if anybody else
out there is planning a Smalltalk implementation for Suns, or any
other workstations for that matter.
I understand that any implementation will probably be dependent on the
Smalltalk-80 System release tape, which is still not yet available as
far as I know. What I want to know is if anyone is planning to do a
Smalltalk implementation on a workstation at such time as the system
release tape is available?
Thanks in advance,
Tim Rentsch
------------------------------
Date: 25 May 1982 01:02:41-PDT
From: ARPAVAX.wnj at Berkeley
Subject: Sun WorkStations
SUN Microsystems is the holder of the license for the SUN Workstation
(TM), which was originally developed at Stanford University by Andy
Bechtolsheim and Forest Baskett. Earlier versions of the design were
manufactured by Andy's company VLSI Systems, which has been superseded
by SUN Microsystems. Andy is one of the founders of SUN Microsystems.
A number of other companies were licensed to manufacture the earlier
design. In particular, CADLINC and Forward Technology are selling
workstations containing these boards, and CODATA has a multi-user UNIX
machine using the cpu board.
SUN was launched in February, 1982 with a multi-million dollar venture
financing. The company was founded with Andy Bechtolsheim the chief
technical person; Vinod Khosla, who was a founder of Daisy Systems, a
electronics CAD company, as president; and Scott McNealy, who was
director of operations at Onyx systems, in charge of manufacturing. I
agreed to join the company shortly thereafter, with my employment at
SUN to begin in July, 1982, when I will begin working half-time. I
will be working full time for SUN after the 4.2bsd distribution (the
distributed version of Berkeley VAX/UNIX) is complete.
The SUN Workstation is a high-performance graphics workstation aimed
primarily at computer science research, scientific/engineering and
CAD/CAM applications. It consists of a high-resolution bitmap
display, a local network interface, and a powerful processor executing
the Bell UNIX operating system (UNIX TM Western Electric). The system
is contained as a desk-top unit with a detachable keyboard and a
separately packaged disk subsystem. An optional mouse pointing device
may be connected for graphical input.
The display is a 17" wide-format screen with 1024 by 800 points
resolution. It can display two pages of characters and graphics,
including proportionally spaced characters, foreign alphabets, and
mathematical symbols, as well as lines, curves, and shaded images.
High-speed "RasterOp" hardware assist can write a full screen of
variable-width characters in less than 100 milliseconds.
The processor is based on the Motorola 68000/68010 CPU, extended with
a powerful virtual memory management unit that allows demand paging
and rapid task switching between multiple processes.
The design allows the 68010 processor to operate at 10 MHz at full
speed without wait states. Main memory is based on 64K technology and
starts from 256 kilobytes, expandable in 768 kilobyte increments.
The SUN workstation normally uses Ethernet as its local network
interface. It is currently equipped with an interface to the
experimental 3 MBit/sec Ethernet. Commercially available 10 Mbit/sec
Ethernet interfaces for the Multibus (TM Intel Corp) can also be used.
A color display option extends the basic workstation with a high-speed
color capability, offering a 640 by 480 display area with 256
simultaneously displayable colors from a palette of over 16 Million.
An optional disk controller interfaces the workstation to
high-performance SMD disk drives.
The SUN Workstation uses the Intel Multibus (TM Intel Corp) as a
system bus, providing hardware expandibility with a wide number of
board-level products and allowing a user to configure a system to his
particular needs.
A SUN Workstation physically consists of the 17'' monitor (which is
the same monitor as is used in the Xerox STAR office product), a box
of electronics which sits under the monitor, and a detachable
keyboard. In the box are a power supply and a 6-slot MULTIBUS card
cage. The workstation normally uses three of these slots for the CPU,
the frame buffer (for the display) and an Ethernet interface.
Currently available prom software allows use of the SUN workstation to
emulate a TEKTRONIX 4014 graphics terminal or a crt terminal, and to
download programs into the workstation over a serial line. If you add
a disk subsystem you can run UNIX version 7, as distributed by
UNISOFT. Serial i/o ports and tape interfaces are also available for
the Multibus.
The boards manufactured by SUN have a number of improvements over
other versions of the design currently being manufactured. In
particular, the other versions of the workstation operate at 8Mhz
rather than 10Mhz and allow only a limited amount of on-board memory.
SUN has also redesigned the boards to get higher reliability and noise
immunity, and is using only burned and tested components.
One warning: some other vendors have offered the 8Mhz design CPU
boards running at 10Mhz. This works only marginally and should be
avoided. The only 10Mhz design that we know of today for 10Mhz is the
one offered by SUN Microsystems.
The software group at SUN is porting the Berkeley UNIX kernel and user
software from the VAX to the 68000/68010. Window management
facilities and a complete set of routines for raster and both 2 and 3
dimensional vector graphics will be added to the basic 4.2bsd system
for use with the SUN.
The concept of the SUN Workstation running the new version of UNIX is
to place clusters of workstations on an Ethernet with other resources
such as a file server and a printer, using the systems networking
facilities to access these resources. This gives each user a
high-quality display and a powerful local processor on which programs
can be run at low cost while sharing the higher cost of the server
resources (disks, tapes, printers, etc.) among a number of users.
Mice, digitizing tablets, color frame buffers and other devices will
be supported by this system.
Using the high-resolution display and mice for input it is possible to
run applications with nice user-interfaces incorporating multiple
windows, vector and raster graphics, variable width fonts and other
highlighting. Because each SUN Workstation will be running a full
UNIX system with multiple processes, a SUN can be used as a file
server (by adding disks), as a timesharing node (either by plugging in
terminals or accessing it over the network) or as a inter-network
gateway (by plugging in several network interfaces).
Besides myself, other people at SUN who may be known to the UNIX
community are: Tom Lyon, who was previously at AMDAHL and was one of
the principals in the AMDAHL UTS UNIX product; Bill Shannon, who
previously worked in the UNIX Engineering Group at DEC and wrote many
of the VAX drivers; and Laura Tong, who was previously working at the
Computer Systems Research Group at Berkeley, administering the project
and coordinating the 3bsd and 4bsd distributions. Other software
people at SUN include John Gilmore (previously with Data General),
Marty Rattner (previously with National), and Mike Shantz (previously
with Deanza Graphics).
SUN will be cooperating closely with the Computer Systems Research
Group at Berkeley in development and enhancement of UNIX on the SUN.
SUN is also working very closely with John Seamons, Bill Reeves and
others at Lucasfilm who did the first UNIX port to the SUN
Workstation, are continuing to do a good deal of pioneering work on
UNIX there. We expect that other cooperative arrangements with
Universities, research labs and commercial organizations will be of
benefit to all users of UNIX and of the SUN Workstation.
The SUN is currently in production. For more technical information,
or for information on prices and delivery schedules, contact:
SUN Microsystems, Inc.
2310 Walsh Avenue
Santa Clara, CA
or phone (408) 748 9900.
Billy Joy
------------------------------
End of WorkS Digest
*******************
-------
∂21-Sep-82 1827 AVB WORKS Digest V2 #60
∂13-Jun-82 1327 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #60
Date: 13 Jun 1982 1429-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #60
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 13 June 1982 Volume 2 : Issue 60
Today's Topic: Micro LISP w/Compiler??
Window Management Part I: Bibliography
Window Management Part II: Personal Communications
----------------------------------------------------------------------
Date: 12 June 1982 18:54-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: micro LISP w/compiler??
Does anybody know of an 8080/z80 LISP that has a working compiler? I
was leaning toward TLC-LISP but the last I heard they didn't yet have
a compiler, only an interpretor. Is there a working
LISP-with-compiler (other than PSL) on any micro?
------------------------------
Date: 11 Jun 82 2:19:21-PDT (Fri)
From: decvax!watmath!csc at Berkeley
Subject: Window Management Part I: Bibliography
Article-I.D.: watmath.2583
A few months ago, I sent out a request over fa.works for information
and opinions on window management systems. Only recently have I had
time to summarize the material in a form that does it justice. Thanks
go to all the people who sent material in. The summary is in two
parts: a bibliography and a compilation of "personal communications",
contained in the next news item. Here's the bibliography:
August 1981 issue of BYTE: articles on Smalltalk
March or April (not sure which) 1982 BYTE: article on The Xerox Star
Teitelman: Interlisp Programmer's Assistant, IEEE Computer, sometime in '81
Halbert: Programming by Example, Xerox Tech. Report/Stanford CS Dep't Report
Myers: Displaying Data Structures, Xerox Tech. Report
Latz & Rashid: paper in 7th Symp. on Operating System Principles (Dec 79)
???: "BRUWIN", in Proc. of the 8th SOSP (Dec 81)
1982 NCC Proceedings: article on the Star user interface (possibly that
which appeared in BYTE this year)
The papers by Halbert and Myers relate to the CEDAR Programming
Environment developed at Xerox. The SOSP Proceedings are published as
issues of Operating Systems Review, the ACM SIGOPS periodical.
------------------------------
Date: 11 Jun 82 2:19:50-PDT (Fri)
From: decvax!watmath!csc at Berkeley
Subject: Window Management Part II: Personal Communications
Article-I.D.: watmath.2584
As promised in the preceding item, herewith is a compilation of
personal communications relating to window management strategies. I
was fortunate to hear from quite a number of people, so this may well
be a good summary of the current state of things. The answers I
received were, however, somewhat oriented to a specific question I
asked: are overlapping windows useful? I also asked for details on
window cataloguing schemes.
Henry Lieberman at MIT-AI:
I've used 2 systems incorporating overlapping windows: the Lisp
Machine at MIT and Smalltalk at Xerox PARC. It's a sexy feature, but
I and others don't find myself using it as much as might be expected.
For situations where you want to share screen among several programs,
some "window made of windows" construct seems better (Frames in the
Lisp Machine, PanedWindow in Smalltalk). Overlapping windows are good
when the screen layout is more dis- organized; you want to pop up
temporary windows, etc.
Paul Johnson at MIT-XX:
My own feeling on overlapping windows is that not providing them would
greatly limit users' flexibility in managing their own work space in a
manner that suits their work style. Forcing non-overlapping windows
on people is not that great a step forward from our glass tty's..
Tim Rentsch at USC-ECL:
I think you would like overlapping windows if you tried 'em. It seems
a common (intellectual) reaction to prefer the non-overlapping kind,
but after an hour of use you will probably be convinced. The problem
with windows that don't overlap is that there is NEVER enough room on
the screen because there is always something of global importance that
is of little local importance. This is not something that most
computer users have been exposed to, since most computers are heavily
into modes.
Jim Guyton at rand-unix:
[who wrote the original window package for the Star] ...Nothing ever
published unfortuneately; there were some nifty ideas used for screen/
window management. For example, an "algebra of rectangles" developed
for adding/subtracting rectangles and a relatively easy method of
hiding window clipping problems from the programs that live in them.
Cluttered windows: A good window system should allow the user to have
as many windows as wanted-- and no more. One thing that is still
debated within Xerox is what to do upon opening a window-- should all
the other windows make room for it (to minimize overlapping windows)
or should the new window just go on "top"?
Star took the first approach. The major windows (that were expected
to stay around for a while) were allocated a large chunk of the
screen. If there wasn't room, then all the major windows were shrunk
a little and moved in order to make room. There was (at least
initially) a limit of how many of these windows could be up at once.
Advantage: usually does the right thing and frees the user from
always having to move/size new windows. Disadvantage: may spend too
much real time doing something "nice" for the user that isn't really
what is wanted.
Other programs have taken the other approach. While much more
flexible, people have complained that they spend a lot of their time
setting the screen up to be exactly what they want.
The basic problem of course is coming up with one set of rules for
what everyone wants in a window package. What I'd like to see is a
"profile-able" window package-- such that I can supply the rules.
Bruce Hamilton at Xerox PARC:
Re overlapping windows: Star doesn't have them, but the Mesa
development environment that we use to create Star does, and I love
it! [Regarding the inquiry on] "cataloguing schemes": each window has
three states: big, tiny (an icon about 1/2" square) and deactivated.
A tool can be quickly changed back and forth between the tiny and the
big states by clicking the mouse in the top of the window, and
preserves all its internal state. A tool can be deactivated by
bringing up a window manager menu and selecting "deactivate". A
deactivated tool may lose much of its internal state. It gets put on
the "inactive" menu which can be called up whenever the mouse is
outside all windows. I like the fine control of being able to grow
and overlap my windows arbitrarily. It is true that tools in the tiny
state may tend to get lost. Tiny windows can be moved around but by
default they go to the bottom of the screen and don't overlap (unless
they've been moved). All this is much easier to demonstrate than to
talk about.
Larry Rosenstein at MIT-XX:
[I am working on a display manager for the Etude office workstation,
as a Master's thesis.]
[Because of limited time and hardware resources] our model of windows
is NOT the conventional one of arbitrarily overlapping windows. We
also wanted to avoid as much inherent overhead as possible, in order
to get adequate response time from the system, and felt that a simple
display model would be adequate (whether this is so still remains to
be seen).
Part of the reason was philosophical. It was not immediately clear
that overlapping windows are needed in an office workstation (as
opposed to a general purpose programming workstation). I think that
goals such as response time and consistent display layout are more
important to office workers than the ability to control the screen
layout precisely.
In our workstation, windows can be created anywhere on the screen, but
the system does not automatically resolve conflicts between
overlapping windows. What we do is dynamically change the size and
position of windows, so that they do not overlap. Each application
can create whatever windows it needs; in Etude, for example, there
will be one window for each element (text column, figure, etc.) on a
page and the windows are arranged to model the desired page layout.
The system takes care of creating "top-level" windows for new
applications, menus, and help information. For simplicity, these
top-level windows are constrained to use the entire screen width.
[Thus, the user sees] horizontal bands, each containing a different
application, menu, or help message. (This approach also avoids
horizontal scrolling when an application's window is too narrow. If
you think about it, most applications are more sensitive to their
windows width than its height-- if the window's height decreases, the
application simply displays fewer lines.)
[When a new top-level window is allocated, existing top-level windows
are shrunk to create space, and the corresponding applications are
notified of their new window sizes so that they can act accordingly.]
The Xerox Star does support overlapping windows, but does not allow
windows to be arranged arbitrarily. Different types of windows appear
in different positions, by default. [Usually windows are designated
by the user to appear in one of two columns. Users may also specify
the distances between windows.] ...Menus that were associated with a
window were an exception--- they appeared in one corner of the window.
One disadvantage ... (and advantage of arbitrary screen layouts) is
that the user must develop [an icon-organizing methodology] because
some parts of the screen are more accessible than others.
~ ~ ~ ~
Again, thanks to all, mentioned and not, who sent in material.
For those who are wondering why I'm interested in all this, I am
currently working for the Software Portability Lab in the Department
of Computer Science at the University of Waterloo, which is developing
general purpose, reasonably portable, workstation software. All
software is written in "Port" (a direct descendant of the UW language
"Zed", itself a BCPL descendant) and makes extensive use of a
message-passing kernel.
The user interface, certainly the most heatedly debated part of the
software, is still in its early stages and not well defined yet. The
goal is to develop something that will be easily learnt, allow
applications all the freedom they need, and run reasonably on an 8086
Multibus machine. I will try to get something on the net about it
when it becomes more interesting.
Peter Rowley, U. Waterloo, (decvax!watmath!csc)
------------------------------
End of WorkS Digest
*******************
-------
∂21-Sep-82 1830 AVB WORKS Digest V2 #62
∂30-Jun-82 0001 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #62
Date: 30 Jun 1982 0104-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #62
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 30 June 1982 Volume 2 : Issue 62
Today's Topics: Mouse Supplier Summary
Information on Mice from Switzerland (3 msgs)
Elite Corporation
Interactive Editor and Formatters for WorkStations
Various WorkS Related Information
General Workstation Query
----------------------------------------------------------------------
Date: 20 June 1982 20:22-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Mouse supplier summary
To: SK at MIT-MC
Rodent Associates, Sunnyvale, CA $150-$286
Mouse House, Berkeley, CA $280-$415
Depraz SA CH-1345 Le Lieu, SUSSIE $160-$221
Product Associates, Redwood City, CA $172-$225
ALPS Electric ???
Kinetronics, Boston, MA $500
Somebody in Oregon ???
Notes:
Rodent makes an optical (no moving parts) design. Deliveries start in
October. OEMs ONLY at this point due to licensing restrictions (which
may change). Rodent's mouse will be on the SUN workstation at
SIGGRAPH.
All the other designs are mechanical.
Mouse House has a 3 month wait.
Kinetronics made the MIT mice. The owner wants to punt the mouse
business though.
Product Associates makes an SRI/Tymshare/ISI looking mouse. They have
a new digital (i.e., like all the other mice) mouse out now. They are
probably your best bet in the short run.
Depraz is very slow. Don't expect to get anything unless you go to
Switzerland to pick them up.
ALPs has a prototype. One button though. Feels and looks cheap.
John Markoff at Infoworld said they got a letter from someone in
Oregon who makes mice, but he still hasn't sent me a copy of the
letter.
Of course, Apple, Xerox, and Avera all make their own mice for
internal or "with product" use only.
------------------------------
Date: 20 Jun 1982 1159-PDT
From: Richard Furuta <Furuta at WASHINGTON>
Subject: Re: Swiss mice
To: foner at MIT-AI
cc: Furuta at WASHINGTON
Do you suppose that the mouse you ask about is the same that is being
used with the Lilith machine? The one we have looks somewhat larger
than a tennis ball cut in half, has three buttons on the top, and is
made from red plastic. I understand they're being made in a garage in
Switzerland by a former watchmaker. If this sounds right, I may be
able to track down some more source information. Incidentally,
they've been a bit hard for us to get used to manipulating as the size
and design of the mouse requires you rest your hand entirely on the
mouse (rather than partially on the mouse, partially on the table)
which seems to make fine positioning movements a bit harder to do.
--Rick
------------------------------
Date: 21 Jun 1982 10:40 PDT
From: TonyWest at PARC-MAXC
Subject: Where to find Swiss Mice
To: Leonard N. Foner <FONER at MIT-AI>
(Look for the holes...)
About your enquiry:
"I am interested in finding out about a type of mouse that apparently
comes from Switzerland."
These must be the mice originally made by Prof. J.D. Nicoud, of the
EPFL in Lausanne. These little creatures are hemispherical with three
buttons on the front (not top).
They have become quite popular with several groups, including Niklaus'
Wirth's group working on the Lilith personal computers at the ETH in
Zurich.
I am not too familiar with BBN's plans, but I have also heard that
they are using them for the Jericho (unverified).
Anyway, the address of the company is:
Depraz SA
CH1345 Le Lieu
Switzerland
Phone (011-41) 21 851533.
Telex 24 310
At one time, I remember seeing something about a US distributor, but
I can't find a reference to them. Perhaps the Digest can help.
Tony West
PARC-CSL
------------------------------
Date: 20 Jun 1982 11:12:23-PDT
From: ARPAVAX.wnj at Berkeley
Subject: mice from switzerland
When I was in Europe for the Paris Unix Users Group meeting, I went up
to Lausanne, Switzerland and visited the Ecole Polytechnique there
where the Swiss mice were designed, and met with Prof. Nicoud, the
designer. The mice are being produced by a small company in
Switzerland called DEPRAZ, and are quite nice. Although they are
mechanical, they seem to be extremely well-constructed. I brought
three of the mice back which we are looking at at SUN. The group at
Bell Labs which made the BLIT terminal (Rob Pike and Bart Locanthi at
Murray Hill Computer Science Research Group) are also using some Swiss
mice, and they have told me that they like them. I have heard a rumor
that Teletype (which will be making BLITs as a commercial product)
will also be using the Swiss mouse.
The mice are more reasonably priced then other more commonly known
alternatives ($250 each in quantity 3, $175 in large quantities). The
other mice I know of are priced around $400. Better and cheaper, I
think. The current problem is small-scale production. When I
visited, production was limited to about 25 per day. Better tooling
was planned for this summer if demand justifies it. The price might
even drop from current levels with better tooling and large
quantities.
If people are interested, I can make copies of a short technical
description that I have and mail it to them. Just send me a U.S. mail
address.
Bill Joy
------------------------------
Date: 29 June 1982 16:31-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Elite Corp.
From Electronics, June 30, p. 145:
National 16023 based (!); 90 day delivery; under $13,000. Hi-res 12"
screen; 5M hard + 5M cartridge (40 ms avg access). 256K bytes RAM;
LISP (from Iowa Mountain Software; does anyone know anything about
this?); Poet (which they say is like Emacs); 8080 code interpreter;
utilities; diagnostics; PL/Basic, Pascal, and SMPL. Op sys is
multi-tasking. Color graphics is an option.
Their address is:
Elite Corp.
906 N. Main
Wichita, KS 67203
(316) 265-0959
------------------------------
Date: 28 Jun 82 16:13:28-PDT (Mon)
From: decvax!utzoo!utcsrgv!alee at Berkeley
Subject: editor-formatter
Article-I.D.: utcsrgv.432
APOLOGIES TO THOSE WHO HAVE ALREADY SEEN THIS. I HAVE GOTTEN NO
RESPONSE AND IT IS POSSIBLE THAT THIS IS NOT GETTING THROUGH, AND I AM
TRYING THIS AGAIN.
I would like to get some feedback about work that is being done on
interactive editor-formatters. Specifically, I am interested in views
on a number of issues which I have listed below.
1) There has been a number of articles discussing the interface of
a number of these interactive editor-formatters (abbreviated as
i.e-f) which are currently under development at various academic
and research institutions. I am especially interested in those
that are being designed for office workstations although this should
not deter response to more general i.e-f. Can people out
there give me some ideas about progress in these and other i.e-f
(e.g. ETUDE (MIT), PEN (Yale), POLITE (IBM), STAR (Xerox)) since
last year.
2) Many of the above i.e-f utilize an hierarchical data structure
which is central to edit, format, and display operations. I would
like to know whether other data structures (e.g. graph) have been
considered in other systems? If so, which ones and why? Systems
using hiearchical data structures; how difficult are they when
implementing them and what kind of response times or performance
times are you getting?
3) Most literatures that I have read have been relatively high-level.
I would like to get some pointers to literatures concerning
redisplay techniques, formatting schemes, representation, and
window management for high resolution bit mapped displays.
Views and experiences with designing, developing, and
using these i.e-f systems will also be appreciated. Also, pointers
to more recent articles (this year) describing abovementioned i.e-f
and others will also be appreciated.
I have just recently become interested in i.e-f and apologize for my
lack of knowledge. Hopefully, this will help me to get abreast of
recent developments. Please respond by mailing directly to me (path
is provided). If there are enough respondents or interest, I will
post a summary as well as a bibliography of papers I get.
[Please note that there is an EDITORS-PEOPLE digest for those of you
who are interested in discussions on editors. I included this request
because I believe that part of the discussion can carry over into
WorkStations. Please be mindful of the fact that this list concerns
itself with WorkStations when you respond. thx - Mel]
Thank you
decvax!utzoo!utcsrgv!alee
------------------------------
Date: 21 Jun 1982 (Monday) 1817-EDT
From: ROSSID at Wharton-10 (David Rossien)
Subject: Various WorkS related information
Wharton has been off the net for a while, so I have not yet caught up
with what's been said, but I thought I might mention a few WorkS
related points of interest:
1. The Olivetti M-20 personal computer is another example of
reasonable (not great) hardware and NO software. The "high"
resolution graphics is about IBM PC level, the operating system
is PCOS (proprietary Olivetti), the primary working language is
CBASIC, and the word processing software (WHEN IT IS AVAILABLE,
not now) is a (slightly) modified WordStar. Yeeeeech. The
CPU is a Z8000, which might have had potential (sigh).
2. The Fortune is a bit cuter in terms of software (it sure seems
like full Unix when I fiddled with it), communications (3274/8
is announced for availablility this summer), and word processing
(Wang lookalike). They said they are reverse engineering
a Chromatics color graphics package, which I will see when it
is available.
3. The new Star software does speed up processing to the point that
it is now usable, but I still think (you listening Xerox guys?)
that there is NO need for things like sending mail to be done it
foreground, where it ties up the terminal for several minutes!
-Dave
------------------------------
Date: 10 Jun 82 1:37:50-PDT (Thu)
From: menlo70!sri-unix!cca!decvax!harpo!npois!houxi!houxz!dman at
Berkeley
Subject: workstation query
Article-I.D.: houxz.196
I've been reading the material in this newsgroup for about a half a
year, and have seen all sorts of various mumblings about this machine
and that, but I have yet to see any real opinions on what people want
workstations/personal-environments to be able to do. Everyone who has
any kind of association with these beasts has some notion of ultimate
workstation, the one which they would love to use.
Please mail me a partial/full list of the characteristics you would
have in your workstation. In about 10 days I'll summarize the replies
and then we can all have a good argument.
[We have actually carried this discussion on once before. I have
elected to include this message anyway because many of you may have
changed your minds in terms of what you expect from a WorkStation
after seeing the responses of other readers. It should be interesting
to see what the new responses will be like. - Mel]
Dave Anderson houxz!dman
BTL Holmdel 201-949-5552
------------------------------
End of WorkS Digest
*******************
-------
∂21-Sep-82 1839 AVB WORKS Digest V2 #76
∂25-Aug-82 1026 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #76
Mail-from: ARPANET site RUTGERS rcvd at 24-Aug-82 2234-PDT
Date: 25 Aug 1982 0126-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #76
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 23 August 1982 Volume 2 : Issue 76
Today's Topics:
Technology - The Apple "Lisa",
Publications - There is No Such Thing as a Screen Editor? &
16-Bit MicroSystem Survey Article
----------------------------------------------------------------------
Date: 23 Aug 1982 08:28 PDT
From: Deutsch at PARC-MAXC
Subject: re: Smalltalk-80 for the Lisa
In reply to Ron Fischer's question:
There is indeed an implementation. The performance figures
submitted by the implementors for publication (in a forthcoming book
written primarily by and for Smalltalk implementors) indicate that
the performance is between 30% and 60% as fast as the Xerox 1100.
Informal conversations with Apple folk indicate that they have done
additional tuning since these measurements were made. The Lisa uses
a 8 MHz processor, which is slowed down to an effective speed of
about 5 MHz by memory interference from the display.
The Lisa has a Xerox-quality black-and-white bitmap display. I
don't know how big it is. I too have heard prices in the $10K
range.
There is indeed a Mackintosh project at Apple. I know very little
about it, and the Apple people are being very close-mouthed about it
(compared to the Lisa, about which considerable information has
trickled out into the rumor mill). I believe it is also
68000-based.
------------------------------
Date: Tuesday, 24 August 1982, 00:29-EDT
From: David E. Goldfarb <DEG at SCRC-TENEX at MIT-MC>
Subject: There's no such thing as a screen editor..
Anyone care to respond to the following piece (an editorial in the
August '82 issue of computer design)? I find it hard to believe
that the author is in the same world I am!
THE TOWER OF BABYL REVISITED
The software revolution has finally hit. Due to the desperate need
for software that utilizes all of the hardware being churned out,
venture- capital people are well on their way to creating a new wave
of hi tech high-flyers in the software field. Spurred on by the
attention of the millionaire-makers, new software firms are
sprouting even faster than hardware firms did in the high-flying
days of the 60s, because software startups are not as capital
intensive as hardware startups.
The new software high-flyers face the same problems that hardware
people do when introducing new products that work reliably. The
difference is that nonworking hardware is a lot easier to detect
than nonworking software. Sure, blatant bugs, resulting in software
that doesn't do what the manual says it should, are easily detected
by even the non- computer professional. but, the sometime-bug, the
unexpected and usually undocumented result, is really the killer.
How does the non- computer professional explain the often complex
sequence of events that led to a surprise result?
The number of professionals and just plain folks waiting for
computers equipped with software that will work for them is growing.
It is only a question of time before something has to give, and that
something -- perish the thought -- could even be legislation under
the consumer protection laws. That would lead to some really fun
cases in court. Have any of you verbally proficient programmers
given thought to becoming tomorrow's generation of software lawyers?
In the same vein, have you ever looked at the software manuals that
are popping up in slick binders, encased in poly-film? I have
watched some of my professional friends hassling with the complex
sequences of keyboard events that fill so many of these programs.
Sure, the ASCII character set is rich in control functions that most
computer people are now used to, and the magic multicharacter ESCAPE
code sequence opens up an unlimited set of possibilities to the
control hungry programmer. But, really now, if the industry is
going to take the pains to document things for the lay-user in plain
language, why doesn't it try to make the programs communicate more
in plain language too?
If you have an UP cursor control key, don't call it CTRL-U or some
other seemingly appropriate mnemonic. Make it the word UP. Even an
ESC-UP would be more understandable to the non-jargon minded.
Remember that typical users just want to use this stuff. they are
not counting key- strokes per function -- that's a programmer's
syndrome or an office efficiency expert's hangup. Faced with that
problem, the user should expect to see, and pay for, a keyboard that
looks like the one on a pipe organ.
While on the subject of keyboards and terminals, have you ever
noticed how most of that software seems to treat the terminal as if
it were a model 33 teletype? Many marvelous things can be done with
a screen, but there isn't a decent screen oriented editor in the
lot, except for those that come from some of the hardware
manufacturers. Sure, there are many different terminals with little
or no compatibility between control codes, but with all of the
memory space available these days, why not configure the programs to
the terminal by asking a set of questions with an installation
routine? For proprietary-minded programmers, you could even
secretly destroy the configurator after successful installation.
Just to make sure the hardware people don't get too smug about their
marvelous equipment: a terminal configurator probably wouldn't work
because most terminal manuals do not explain, in plain language,
just what control codes make the terminal do its wonderful things.
So the typical user probably couldn't answer the questions anyway.
Saul B. Dinman
Editor in Chief
* * * End of article * * *
Well, I won't say any more.
- David
------------------------------
Date: 21-Oct-85 21:53:10 PDT (Monday)
From: Hamilton.es at PARC-MAXC
Subject: 16-bit microsystem survey article
To: HomeComputing↑.pa@PARC-MAXC
One of the most remarkable, pithy, knowledgeable articles I've ever
seen (and readable by semi-technical types) is in the current
(Sept/Oct) issue of High Technology. It's called "Microcomputers:
the second wave", by Cary Lu, Managing Editor of High Technology.
The article describes the various commercial 16-bit microcomputer
systems now available. It features extensive tables of comparisons
as well as a no-nonsense human-factors approach, with special
emphasis on what's wrong with all the different (nonstandard)
keyboard layouts.
Most people in these forums would not learn much from the article,
but it's excellent background for less sophisticated people
considering a purchase.
Reprints @ $1/ea (quantity discount also offered) are available from
Randi Straus, High Technology, 38 Commercial Wharf, Boston, MA
02110 (617)227-4700.
--Bruce
------------------------------
End of WorkS Digest
*******************
-------
∂26-Sep-82 1035 AVB WORKS Digest V2 #78
∂24-Sep-82 0606 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #78
Mail-from: ARPANET site RUTGERS rcvd at 23-Sep-82 2018-PDT
Date: 23 Sep 1982 2317-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #78
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Thursday, 23 September 1982 Volume 2 : Issue 78
Today's Topics:
Hardware - Swiss Mice (4 msgs) &
DEC Professional 350 (2 msgs) &
Impressions of a GRiD Compass Computer &
68k Machines Running Unix,
Summary of Responses - Books on "C" and UNIX
----------------------------------------------------------------------
Date: 8 Sep 1982 16:45:02 EDT (Wednesday)
From: Tony Lake <lake at BBN-UNIX>
Subject: Swiss Mice supplier
To: cak at purdue
Chris,
The manufacturer of the Swiss mouse is:
DePraz S.A.
CH 1345 LeLieu
Switzerland (Suisse)
We have had a hard time getting any significant number out of
Depraz, because of their limited production capacity.
However, you may also try their (supposedly exclusive) U.S.
distributor:
LOGITECH Inc.
165 University Ave.
Palo Alto CA 94301
415-326-3885
Logitech are currently quoting prices of:
Quantity 1 2-9 10-99
Price $295 $275 $255
but I cannot verify their delivery.
//Tony
------------------------------
Date: 9 Sep 82 22:14:01-EDT (Thu)
From: Mark Weiser <mark.umcp-cs at UDel-Relay>
To: cak at Purdue
Subject: Swiss Mice
The ~$300 Swiss Mouse is just the mouse electronics with no
interfacing. It generates pulses as it rolls along. They have no
immediate plans send a brochure describing a planned RS-232c
interface, but upon inquiry quote no time frame and don't even
promise it "eventually". I think Swiss mice are out.
------------------------------
Date: 10 Sep 1982 12:02:29-EST
From: Chris Kent <cak at Purdue>
Reply-to: cak at Purdue
To: mark.umcp-cs at UDel-Relay
Subject: Re: Swiss Mice
The Hawley mouse is exactly the same -- it just generates pulses as
it rolls along, for ~$150 more. I want to do my own interface; using
a separate RS-232 line for a mouse is a lose, as far as I'm
concerned.
Does anyone know when Xerox is going to start marketing their
optical mice, either as chips for homebrewers, or as a package?
Should be much cheaper.
chris
------------------------------
Date: 15 Sep 82 7:53:36-PDT (Wed)
From: harpo!ihps3!ixn5c!inuxc!nwuxc!otuxa!we13!lime!burdvax!hdj at Ucb-C70
Subject: Optical mouse update
I haven't heard anything about Xerox marketing their optical mouse,
but I do have in front of me a document entitled "Preliminary Mouse
Systems Corp M-1 Mouse Specification," which describes an optical
mouse produced by MSC. I have used it (though briefly) attached to
a SUN workstation, and it is quite nice. It will be able to detect
rotation as well as translation.
Price: $286, qty 1 (??)
Apple-II interface: $51
IBM-pc interface: $51
RS-232 interface: $40
Availability: 2nd Q, '83.
The address: Mouse Systems Corp.
655 Fairoaks Ave., Suite D-313
Sunnyvale, CA 94086
408-730-2132
Have fun,
Herb Jellinek
(lime!burdvax!hdj)
------------------------------
Date: 9 September 1982 1016-EDT
From: Hank Walker at CMU-10A
Subject: more for the money
A DEC Professional 350 might give more for the money. It's features
are:
LSI-11/23 CPU (11/34 architecture)
256K memory
5MB Winchester (I think that this is included in the price, but not sure)
Dual 5.25 in floppies
Graphics, including graphics processor (around 720 x 240 pixels)
The graphics can be expanded to 3 bits/pixel, plus more memory, etc.
It costs around $5000. It may be more if the hard disk isn't
included in that price. It runs POS (Professional Operating
System), which is built on top of RSX-11M+. The thing that I find
neat about the system is that it is entirely user-serviceable. A
pencil or pen is sufficient to assemble and disassemble the whole
thing. In fact it comes disassembled. It also takes up very little
space on the desk when the CPU box is on the floor.
------------------------------
Date: 10 Sep 82 16:43:07-PDT (Fri)
From: decvax!pur-ee!CSvax.cak at Ucb-C70
Subject: Re: more for the money
Yah, but there's still that 16 bit address space. That's the only
bad thing about the Pro 350. If it weren't for that, I'd be saving
my pennies for it.
A UNIX port is being/has been done inside DEC, but won't be a
product (aw).
Chris Kent, Purdue CS
------------------------------
Date: 20 Sep 1982 (Monday) 2225-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: Impressions of a GRiD compass computer
**********************************************************************
NOT FOR PUBLIC DISTRIBUTION, FOR RESEARCH PURPOSES ONLY
Henry Dreifus
The Wharton School
**********************************************************************
GRiD Impressions
----------------
For about two weeks I have been using the GRiD compass computer for
our research project on a Beta-test basis. The computer itself
consists of two portions: A computer and a Winchester/floppy drive
box. They are connected with a GPIB (better known as a HPib)
general purpose bus.
Computer: Disk:
Weight: 8 lbs Floppy: 320K double sided 5.25"
Size: 10.5 x 8.5 x 1.8 inches Winch: 5 MB
Processor: Intel 8086 + 8087 co-processor
Memory: 256 K bytes ram
Storage: 256 K bubble memory
General opinion:
The system is intended to be a portable computer. This they
have accomplished. I have successfully used it in over 10 cities,
traveling by air, train or car.
With the built in Modem (vadic triple 34xx, with autodial) I
have communicated with the ARPAnet, telenet, tymnet etc. without any
difficulty, much better than carrying a silent 700.
The basic packages (GRIDTERM - terminal emulator, GRIDWRITE
- word processor, GRIDPLAN - a visiclone, GRIDPLOT - graphics
auto-plot package, and GRIDFILE - a simpleton, but useful
'relational' data manager) are pretty good from a user standpoint.
GOOD:
The system is truly portable. It folds into a size suitable to fit
in my briefcase - and carry anywhere.
The display - "electro-luminescent" graphics is surprisingly crisp
and easy to read.
Documentation is good. Cross consistency (there are still a few
crocks) is more or less solid. That is to say if I type CODE+<left
arrow> it will behave the same in any application by moving the
cursor to the left one word (or cell).
BAD:
Computer tends to run "warm" or hot. The case itself is the heat
sink.
Only 256K in bubble really is a cramping factor. Only one
application can "go on the road" with the computer at a time.
As an applications development machine it is very poor. It takes
approximately 10 minutes to cycle through a program compilation and
load. I can do better with MT pascal and floppy disks.
Overall I believe it has a potential, and will truly set a trend
towards portable - I mean really portable - computers. The ideas
are good, the execution is fairly well done, their overall approach
is in the right direction.
In about two weeks I shall give further comments and impressions as
I begin to seriously develop a few applications.
Henry Dreifus
------------------------------
Date: 11 Sep 82 3:09:51-EDT (Sat)
From: Dave.umcp-cs at UDel-Relay
Subject: 68k machines running Unix
The following comments are strictly my opinions and
observations. The reader is obliged to confirm the accuracy of my
statements.
I was recently, last May, faced with deciding amongst the
68k processor machines running Unix. I eliminated Wicat from the
running immediately, because they didn't have Unix working at the
time; they didn't even have MCS working very well. (Since, I have
observed mention of them in this digest-- has Unisoft really done
their Unix port for them?) I set aside consideration of the Forward
Technologies machine, because their market seemed to be the high-res
graphics industrial applications, and the $25k price reflected that.
So, I considered Fortune and Codata. Fortune didn't want to deal
directly with me; rather, they sent me to Computerland, who didn't
even have the distributorship contract signed at the time. My
local Computerland dealer had heard of the machine, but I knew more
about it than he. Codata, on the other hand, was extremely
responsive with technical details of their CTW-300 machine running
Unisoft Unix. I chose the Codata machine for the following reasons:
a) I know the reputation of the guys at Unisoft, and trust
their capability in porting Unix.
b) I consider the Multibuss architecture to be superior to
that of the Fortune's proprietary one. (What about the press
Fortune has recently received on their misfortune in the hardware
department)?
My experience, 3.5 months after buying the machine from
Codata, has been very satisfactory. No doubt, there are glitches,
bugs, and "features" in the software that would cause some
consternation on the part of the owner who didn't have any Unix
wizardry in-house, but this is being remedied over the 12 month or
System III implementation completion, which ever comes last. The
hardware has performed remarkably well.
No, I have no association or affiliation with Codata; I
really like the machine! In some consulting work, I encouraged
another business to buy one also. No problems over a sample of two.
Since I bought the machine, another Unix on a 68k processor
has popped up, the Hawk 32 by Computhink. I've heard bits and
pieces about the Sun machine Bill Joy is working on, but don't have
any details.
- Dave Stoffel
------------------------------
Date: 20 Sep 1982 1359-PDT
Subject: Summary of responses -- Books on "C" and UNIX
From: WMartin at Office-8 (Will Martin)
To: Info-Vax at SANDIA
I am very late in distributing this summary of responses to my
inquiry in late July regarding references to UNIX and "C" other than
the standard documentation and the Kernighan & Ritchie "C" book.
Sorry about that... Anyway, here it is:
Quite a few people (including the authors!) pointed to A USER GUIDE
TO THE UNIX SYSTEM, by Rebecca Thomas and Jean Yates. Independent
evaluations rated it "Absolutely first-rate", "Great", "Excellent
for the beginner", "Nice, "Easy to read", etc. No one seemed to
dislike it. The authors mentioned that they were working on four
more UNIX and XENIX books now, and planning two others, aimed at
business users and programmers. This book is intended as an
introductory book for non-programmers, by the way. It is published
by Osborne-McGraw-Hill.
Several people pointed to an article in the ACM SigPlan Notices, Vol
16 (12), Dec '81, by P. A. Fitzhorn and G. R. Johnson -- "C: Toward
a Concise Syntactic Description". One mentioned that it discussed
ambiguities and problems. He also mentioned an earlier article in
the same journal: SigPlan Notices, Vol 15 (3), [March?] '80, no
author mentioned -- "Type Syntax in the Language 'C'".
I received a copy of a long review of Richard L. Gauthier's USING
THE UNIX SYSTEM (Reston Pub. Co., Reston, VA 1982, $18.95) from W.
H. Huggins, via the CSNet. (Also a review of the Thomas & Yates
book, which he praised -- I'll forward a copy of these reviews to
anyone who asks and to whom I can mail.) The most succinct summary
of the Gauthier book is "a disaster in its execution"; the objective
was laudable but the language and production resulted in a poor
product.
A number of respondents mentioned C NOTES from Yourdon; no author
specified.
Alan R. Feuer's THE C PUZZLE BOOK (Prentice Hall, 1982, $16.95) was
described as a companion workbook for the Kernighan & Ritchie "C"
book. One contributor, who teaches "C", recommended it as
"excellent".
The Bell System Technical Journal special UNIX issue (July-Aug
'78) is still available direct from the Labs for $2.00 each,
according to a couple people; some bookstores are selling it at
$5.00. We had acquired a pile of these prior to my inquiry, but
I had forgotten to mention that in my original message.
A highly-praised but somewhat peripheral document is DEC's manual
for VAX-VMS v3.0 "C", PROGRAMMING IN VAX-11 C, (DEC order code
AA-L370A-TE). This is a paperbound book, and describes a "C" much
like the Berkeley "C". It was recommended as a "stellar
documentation job".
Last comes news of a new UNIX book by Steve Bourne, to be published
by Addison-Wesley about January '83. No other info yet available.
Hope this is of help to you, and my thanks to all who responded.
Will Martin
------------------------------
End of WorkS Digest
*******************
-------
∂05-Oct-82 1721 AVB WORKS Digest V2 #79
∂02-Oct-82 0654 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #79
Mail-from: ARPANET site RUTGERS rcvd at 1-Oct-82 2200-PDT
Date: 2 Oct 1982 0059-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #79
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 2 October 1982 Volume 2 : Issue 79
Today's Topics:
Programming - Screen Editors (3 msgs),
Summary of Responses - Books on "C" and UNIX,
Hardware - 68K Machines Running Unix &
UNIX on DEC Personal Systems (2 msgs) &
DEC Professional 350 Systems (2 msgs) &
The INTEL 80286
----------------------------------------------------------------------
Date: 9 Sep 82 22:28:54-EDT (Thu)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
To: REM at Mit-Mc
Subject: TTY-style
A recent comment suggests that TTY-style might win over full-screen
style because (1) TTY-style makes interactive sessions easier to
describe on paper, and (2) TTY-style makes your mistakes easier to
see.
I can't agree with either of these points. The first is putting the
cart before the horse--a program should not be distorted for ease of
documentation, only for ease of use. These are not the same.
Furthermore, using documents to describe programs is the wrong way
to go. Let the program describe itself, if it doesn't exist yet,
rapid-prototype up a demonstration system so people can try out a
little of what the program would feel like if it did exist. I
never managed to learn emacs from a written description--but with
teach-emacs I had no problem.
Point (2) I think is really an argument for infinite undo. When a
mistake is made the most important thing is to be able to correct it
and try again, not just see it. Infinite undo means that no matter
how far back you goofed you can undo back to there and proceed
forward again. TTY-mode still only lets some mistakes be seen.
I certainly don't think that these two points mean TTY-style is the
method of choice unless random screen access is "strictly
necessary". The opposite is true: unless these advantages(?) of
TTY-style interaction outweigh the disadvantages (low bandwidth,
single text stream, lack of context), use random access screen.
Who's Let these machines
------------------------------
Date: 10 September 1982 16:43-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: TTY-style
To: mark.umcp-cs at UDEL-RELAY
(The last part of your message seems to be garbaged and/or missing:
Date: 9 Sep 82 22:28:54-EDT (Thu)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
...
...
I certainly don't think that these two points mean TTY-style is
the method of choice unless random screen access is "strictly
necessary". The opposite is true: unless these advantages(?) of
TTY-style interaction outweigh the disadvantages (low bandwidth,
single text stream, lack of context), use random access screen.
Who's Let these machines
and that's where it ended, two incomplete sentence and two blank
lines, at the end of the message as received here.)
Re the subject of your message... I agree an infinite UNDO is
needed, but first of all I don't believe anyone has figured out how
to do it right. InterLISP does it wrong. Infinite UNDO really
requires something akin to potential infinite ordinals as described
in Hofstadter's latest column in Scientific American. You need to
be able to undo and have the stuff really go away instead of leaving
an UNDO blip on your undo stack, but you also need a way to *META*
your context, step back and view it from "God's view", to see that
you did something then undid it, i.e. see all that still there, i.e.
to see a *real* transcript of what you *really* did instead of just
what was left after you did it. I.e. you need to be able to
meta-edit, to step out of your edit and to edit what you typed
during your edit. When done, you need to be able to step back into
your original context and have things AS IF you had originally done
your edited transcript of commands to the editor instead of what you
originally did. Note this really is a meta-edit. When you type
stuff at the end of a file, you're just entering data. When you see
a mistake and go back to fix it, it's equivalent to going back in
time and changing what you typed, as if you typed the right stuff in
the first place. When you write out the file, there's no record of
your mistakes, it's as you had typed it right in the first place.
Well, UNDOing mistakes in editing commands is the same idea but one
META level deeper.
Now, what if you are deep into fixing up a bad editing session by
editing the transcript, i.e. meta-editing, and you make a real gross
mistake. You want to be able to enter another level of meta, i.e.
you want to meta-meta-edit. Continuing in this way we have omega
(infinite ordinal number) editing levels.
But this assumes there's one reserved key for going META and one
reserved key for going UN-META (or one key as prefix for the two).
But what if you want to re-define what key is the META prefix, to
customize your keyboard? What if you accidentally change the META or
UN-META key to something you can't type? You need a way to escape
that context and fix it. This starts getting into OMETA+1 etc.
editing levels. I have no idea what the complete solution to this
problem is.
Note, META as used here has nothing to do with the meta key on
various Stanford/MIT keyboards, except the name is derived from the
mathematical (example, "Metamagical Themas") usage in both cases.
Also, a reasonable way to go into META-edit mode is to go into
roll-time mode, where you can roll time forward and backward in your
original edit and see what was on your screen and what command you
typed to effect that screen-change, as real time in your META-edit
moves forward as it always does in this Universe. You may then
either mark some point in the original edit as <NOW>, causing all
steps after that point to be lost from the original edit, or you may
delete erroneous steps from the edit sequence, keeping later steps
that were good so you don't have to redo them. Having finished
that, when you return to your original edit it's as if you hadn't
done the erroneous step(s).
Anyway, I'd like to see a mathematical specification for an UNDO
system that doesn't have bugs or inconsistencies. It's ok if it has
potentially-infinite regress providing that during normal use it
doesn't regress too deeply.
------------------------------
Date: 11 Sep 82 14:00:58-EDT (Sat)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
Subject: the REAL Meta key
Yes. I think losing the Meta key by redefinition is a red herring.
This can always be worked around by reserving a meta valid in all
universes.
I think you stated the basis for a mathematical theory of meta and
undo in your letter: time. (Shades of Heidegger and existential
philosophy!) A meta level has a very simple relation to the
previous levels: it freezes the previous level as a closed universe
with all times spread out on the time line, and then allows editing
at any point in that time (with subsequent causality edited
implicitly). Meanwhile, "real" time moves to the new meta universe
where the past is immutable and the future flexible (until meta is
struck again...).
Mathematically I think everything will be fairly simple since
computers are mathematically trivial (finite state machines and all
that).
About implicit causality editing: should the future vanish as the
past is edited, or should as much of the future be preserved as
possible, consistent with the edit?
------------------------------
Date: 23 Sep 82 18:15:02-PDT (Thu)
From: menlo70!sri-unix!fortune!megatest!sun!henry at Ucb-C70
Subject: Forthcoming Books on UNIX
There is another book on the UNIX system in the works. It is called
'An Introduction to the UNIX System' and is written by Rachel
Morgan (Member of Scientific Staff at BNR, Mountain View) and Henry
McGilton (Member of Technical Staff at Sun Microsystems, Santa
Clara).
The Book has 14 chapters and is about 600 pages long. It is at the
typesetters now, and should be published around the end of the year.
Publishers are McGraw-Hill (the real McGraw, not Osborne).
------------------------------
Date: 24 Sep 1982 14:53 PDT
From: Deutsch at PARC-MAXC
Subject: Re: WORKS Digest V2 #78
Both manufacturers of the Sun (68k) workstation offer Unix, although
I don't know whether either has delivered a system with Unix yet.
Sun Microsystems Inc. offers (or will very soon offer) a version of
Berkeley Unix, while CadLinc currently offers version 7.
------------------------------
Date: 28 Sep 1982 0119-PDT
Subject: UNIX for DECs "personal" 3xx computers
From: William "Chops" Westfield <BillW @ SRI-KL>
To: unix-wizzards at CSL, info-micro at BRL
We at SRI had the privilege of having the business manager (or some
such) for the DEC 350 series give a lengthy (about 3 hours). He
explained where the 300 came from and why, and where it was going.
He stated that unix WOULD NOT EVER be a product for the 350.
Overall, I was rather disappointed in DECs attitude. They are
screwing programmers and hardware hackers in an attempt to attract
"business" type users. They think that this is the only way to get
lots of users. Maybe they are right. I hope not.
BillW
------------------------------
Date: 30 Sep 1982 09:55:45-EST
From: Chris Kent <cak at Purdue>
Reply-to: cak at Purdue
To: BILLW@SRI-KL
cc: unix-wizzards at CSL, info-micro at BRL
Subject: Re: UNIX for DECs "personal" 3xx computers
At the Boston Usenix, there was a lengthy talk given about the Pro
300 and the Unix port that was being done for it. It was strongly
stressed that this would NOT become a product, much to the chagrin
of the audience.
I think that the best we might hope for is for the DEC Unix
Engineering Group to release an unsupported tape sometime, or for
someone to find a tape "in the middle of the road" or "in a garbage
can" (how many of you remember the "50 fixes" tape?).
Too bad. It's a nice package, even if it's only a 16 bit machine.
Cheers,
chris
------------------------------
Date: 25 September 1982 1040-EDT (Saturday)
From: Hank Walker at CMU-10A
Subject: more for the money
Eliot Moore pointed out to me that the 5MB Winchester option on the
DEC Professional 350 costs $3500 extra over the $5000 standard
price.
- - - - Begin forwarded message - - - -
Mail-From: ARPANET host MIT-MC received by CMU-10A at 25-Sep-82
Date: 25 September 1982 00:37-EDT
From: Eliot R. Moore <ELMO at MIT-MC>
Subject: more for the money
To: Hank Walker at CMU-10A
cc: ELMO at MIT-MC
The Winchester is $3500 (gulp!) extra.
Elmo
- - - - End forwarded message - - - -
------------------------------
Date: 25 September 1982 11:34-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: more for the money? DEC PC350
To: Hank Walker at CMU-10A
The $5000 price does not include the 5Mbyte Winchester, which costs
around $3000. Two 400 KByte floppies are standard.
------------------------------
Date: 26 Sep 1982 0925-PDT
From: Jeffrey at OFFICE
Subject: Intel's 80286
To: info-cpm at BRL
The most recent edition of Computer Architecture News (CAN) includes
an article which compares the performance of Intel's 80286 with
other processors. Its a short article consisting primarily of a
couple of tables.
The tables seem to indicate that a 10MHz 80286 performed five or six
small benchmarks much faster than all other tested processors
including a 16MHz 68000 and a VAX 780!
I've been reading some literature on the 80286 and it appears
overcome most of the limitations of the 8086 including limited
address space for processes and lack of protection.
From where I stand, the smaller 80186 (a single chip coupling the
8086 with some support functions) and the 80286 look like parts of a
pretty large comeback for Intel and the 8086-family in the
microcomputer marketplace.
Maybe its not really a comeback since Intel was never really behind.
However, for a while (before the announcement of the IBM PC) it
looked as if the 68000 was going to steal the show.
I would appreciate hearing from people with information and/or
opinions about the 80286.
Thanks,
Jeffrey Stone
Menlo Park, CA
------------------------------
End of WorkS Digest
*******************
-------
∂12-Oct-82 1731 AVB WORKS Digest V2 #80
∂12-Oct-82 0052 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #80
Date: 12 Oct 1982 0101-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #80
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Tuesday, 12 October 1982 Volume 2 : Issue 80
Today's Topics:
Hardware - 68K Machines Running Unix (2 msgs) &
Intel 80286,
Programming - Screen Editors (4 msgs)
----------------------------------------------------------------------
Date: 24 Sep 1982 1537-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Unix planned for Corvus concept
To: hedrick at RUTGERS, josh at RUTGERS
I spoke with a Mr. Dick O'Shay at "The Microcomputer Store" in Conn.
today about the Corvus concept. He informs me that Corvus has just
developed a way for Unix systems to share an Omninet disk. It is
probably a "C" program that implements their Omninet protocols. He
also mentioned that Corvus is working on getting Unix on the
Concept. Details are not clear, but they will probably buy the
implementation from someone else.
This would make the Concept a very inexpensive Unix based
workstation indeed, at $4995 per Concept, plus $4800 for a 6Mb
Omninet server and disk {excluding Unix software and VCR for
backup}, or you could get a vanilla 8" disk drive with 1Mb for
$1500.
(ron)
------------------------------
Date: 2 Oct 1982 10:38-PDT
From: lee at usc-cse
Subject: Re: WORKS Digest V2 #78
To: Deutsch at PARC-MAXC
We (the computer science department at USC) have Suns from Sun
Microsystems with Unix, delivered and running. It is Unisoft, soon
(?) to be replaced by Berlix 4.2. So there are some.
-- Lee
------------------------------
Date: 5 October 1982 01:49-EDT
From: "James Lewis Bean, Jr." <BEAN at MIT-MC>
Subject: Intel's 80286
To: Jeffrey at OFFICE-2
The iAPX-286 will indeed be a great improvement over the 8086 as far
as protection is concerned, but it has the same major flaw that all
intel processors to date have. They base the entire memory system
around 64K segments. Even the iAPX-432 has the same problem. There
are advantages to using segmented memory, but as far as I am
concerned the disadvantages outweigh the advantages.
lewis
bean at mit-mc
------------------------------
Date: 4 Oct 1982 2224-EDT
From: Tim <WEINRICH at RUTGERS>
Subject: Screen terminals versus hardcopy terminals
I wasn't able to follow most of Mark Weiser's comments about
screen terminals versus hardcopy terminals. He responded to the
comment "TTY-style makes your mistakes easier to see" by saying:
[This,] I think is really an argument for infinite undo.
When a mistake is made the most important thing is to be
able to correct it and try again, not just see it. Infinite
undo means that no matter how far back you goofed you can
undo back to there and proceed forward again. TTY-mode
still only lets some mistakes be seen.
I don't see how this addresses the comment. If I make a mistake, I
want to be able to see it. I'd like to be able to see it without
too much trouble. If you want to supply me with an UNDO command,
infinite or otherwise, that would sure be neat, but in either case I
want to be able to see what I did. More generally, I'd like to be
able to see things that went on earlier in the session (or, perhaps,
earlier in the week) whether or not they happen to be errors. I'd
like to be able to compare the results I got at 4 random points in
the session, whether or not I realized in advance that I'd be
wanting to compare these things. Screen terminals make this sort of
thing unreasonably difficult.
I've been working for about 2 years on a screen terminal (DM2500
at 9600 baud) while my office-mate uses a hardcopy terminal (TI
Silent 700 at 300 baud.) For these 2 years we've been informally
comparing notes on the pros and cons of the terminals. Perhaps we
should write up a summary. In general, tho, only one consistent
thread stands out in my mind. Usually, when my office-mate needs a
screen terminal, he notices the problem \in advance/ which enables
him to walk over to a screen terminal and continue the session. On
the other hand, I continually find myself saying "%$[@*!!!, I wish
that operation which I did 15 minutes ago had been done on a
hardcopy!" I am therefore lead to believe that, if a person had
both a screen terminal and a hardcopy terminal available, that
person might do most of his/her work on the hardcopy terminal,
reserving the screen for times when fast output or a video editor
was essential.
Twinerik
------------------------------
Date: 4 Oct 1982 15:08:44-EDT
From: mullen at NRL-CSS (Preston Mullen)
To: REM at Mit-Mc, mark.umcp-cs at UDel-Relay
Subject: Infinite regress
"Excuse me while I go get some more punch."
I suggest that every meta-editor have a special key that will
auto-dial Hofstadter (at a toll-free number) in case you run into
meta-problems you can't handle, or just get confused. (You could
either talk to him about it or simply have a modem scream at him to
express your frustration.) Naturally there would be a different
phone number for each level of difficulty.
P.S. Structured document editors probably are the only practical
way to provide the flexibility you think necessary.
P.P.S. I am not sure that such flexibility is necessary or even
desirable. Perhaps we should instead simply encourage people to be
more aware of what they are doing. Remember, in the old days people
wrote with pen and ink, and they often (I know this seems
impossible) wrote things from start to finish without revision;
amazingly, many of the products of such a ridiculously outmoded
process are now considered to be some of the finest examples of
lucid writing! A little forethought not only improves organization
and prevents errors, it also prevents a lot of drivel from getting
out. [Will the notebooks of today's Leonardos be floppy disk
transcripts of all their editing sessions, with every keystroke
preserved for posterity?]
P.P.P.S. to REM: Why not torment the folks at Editor-People with
this?
------------------------------
Date: 10 Oct 82 16:29:55 EDT (Sun)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
Subject: Re: Infinite regress
To: (Preston Mullen)mullen at Nrl-Css, mark.umcp-cs at UDel-Relay,
REM at Mit-Mc
I don't think people ever wrote from start to finish without
revision, even with pen and ink. If nothing else their memories for
text were better (from practice) and revisions could be made in
one's head.
------------------------------
Date: 6 Oct 1982 (Wednesday) 2310-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: Software Programming Environments
A few comments on the design of a SPE:
o Multi-window. The ability to look at more than one place in a
program, or accross programs for easy reference.
o Source Level debugging - with sourb∂ code in corresponding window
(a la Jericho)
o Auto-document - to assist in quick documentation of program(s).
o Software Breadboard - just as we breadboard hardware before we
cut it onto silicon or onto a PC board, we should have some
mechanism for (almost interpreted) studying code fragments.
o Library of calls/database. Have library functions in a database
with "fill in the arguments"/on line descriptions prompting.
o Software acceptance/ A.T.E. of programs. Each time a change is
made, a testpattern is run accross it to verify that changing the
program has not broken another section.
I am beginning to collect comments and write up a futuristic SPE
which takes us beyond the mundaine tools of the trade (i.e. full
screen editing, simple source code debugging etc.) and would like to
discuss this topic on WorkS. It is especially possible to implement
these types of working environments on a personal workstation class
machine.
Henry Dreifus
------------------------------
End of WorkS Digest
*******************
-------
∂17-Oct-82 1054 AVB WORKS Digest V2 #81
∂14-Oct-82 2028 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #81
Date: 13 Oct 1982 2206-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #81
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Thursday, 14 October 1982 Volume 2 : Issue 81
Today's Topics:
Hardware - Swiss Mice,
Programming - Screen Editors (8 msgs)
----------------------------------------------------------------------
Date: 11 Oct 82 14:55:18 EDT (Mon)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
Subject: optical mice
I just got a description of these mice from Mouse Systems
Corporation, 655 S. Fairoaks Av. Suite D-313, Sunnyvale CA.
Delivery is January 1983, price is $312 with RS-232C interface and
power supply. Senses rotation in place. Brochure is cute, claims
that their mice will be second-sourced soon by another manufacturer,
says they plan to offer a full line of accessories and
customizations, including cheeses. Requires a special surface,
included in the price. Has 3 buttons.
Has anyone actually tried one of these? The DePraz mouse is
apparently very nice ergonomically (fits into the hand, has the
buttons in the right place)... How about these optical mice? The
sales literature has no picture.
------------------------------
Date: 12 Oct 1982 0308-EDT
From: V. Ellen Golden <ELLEN at MIT-XX>
Subject: "Undo"
What ever happened to editing and filing? When I am editing, I make
use of filing my buffer out on disk VERY frequently (I also of
course clean up after myself, as soon as I am happy with the
results). If you have filed your buffer, and you do something which
messes up the world... "undo" is very simple, you just read the file
from disk again! Now, I know this is simplistic, but it is VERY
effective.
------------------------------
Date: 12 Oct 1982 10:20-EDT
From: Hank.Walker at CMU-VLSI at CMU-10A
Subject: CRT vs hardcopy
Why not have the best of both worlds? I can fork a shell from
Gosling's Emacs and have it attached to a window. I can do all
sorts of nice things in it, like edit command lines, go back, etc.
You can save an arbitrary amount of your session, depending on how
big you make your buffer. So you get a screen plus the ability to
go back in your terminal session.
Re software breadboards: No one breadboards hardware anymore, they
simulate it (or at least a lot of people don't breadboard anymore).
------------------------------
Date: 12 October 1982 16:38-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: Screen terminals versus hardcopy terminals
To: WEINRICH at RUTGERS
Transcript windows are standard on Apollo and I believe Xerox. You
don't need to have hardcopy to be able to review past work.
------------------------------
Date: 12 Oct 1982 1426-PDT
From: Dick Gillmann <GILLMANN at USC-ISIB>
Subject: Screen Editors and UNDO
To: Weinrich at RUTGERS
I've been using an Apollo node for a few months now and one of its
nicest features is that it allows you to scroll back all the way
back to when you logged on. So even though it's a video display,
you can see everything you did all day. If you use cursor
addressing to write things on top of earlier things, the system
still preserves the whole sequence so you can look at it. So it's
even better than an HP terminal with infinite scroll back memory.
/Dick
------------------------------
Date: 12 Oct 1982 1821-EDT
From: Tim <WEINRICH at RUTGERS>
Subject: Re: Screen Editors and UNDO
To: GILLMANN at USC-ISIB, MACRAK at MIT-MC
Yes, I've used terminals which store things which scrolled off
the screen. This isn't a new idea, by the way. I used such a
terminal at least 4 years ago, and the terminal looked like it had
seen a few years of use even then. One advantage that hardcopy
units had over many video terminals is that I could save copies of
my work from yesterday, last week, or last year without taking up
huge amounts of disc space. (Of course, after a while they started
to take up huge amounts of closet space...)
If I had to choose between a hardcopy terminal and a video
terminal as my only medium for working on, I'd probably choose the
video terminal. My comment was somewhat more specific: If I had
both terminals available all of the time, I would probably do most
of my work on the hardcopy unit. I don't see how your note disputes
this point. Why should I use a video terminal which, using amazing
technical breakthroughs, manages to almost emulate the features of a
hardcopy unit, when I can just use the hardcopy unit? (I mentioned
before that one thing I want to be able to do is compare the output
I got at 4 different points in my session. I want to be able to
\look at them simultaneously/. Think about what you have to do on
an apollo in order to get this information on the screen all at once
(assuming it will all fit) and then try to figure out why I should
go thru this trouble when I could have just used my hardcopy
terminal.)
Twinerik
------------------------------
Date: 12-Oct-82 8:05PM-EDT (Tue)
From: B.J. Herbison <Herbison at YALE>
Subject: Re: WORKS Digest V2 #80
To: WEINRICH at RUTGERS
Cc: Herbison at YALE
Usually, when my office-mate needs a screen terminal, he notices
the problem \in advance/ which enables him to walk over to a
screen terminal and continue the session.
You never "need" a screen terminal, it just makes the computer a
potentially nicer environment.
On the other hand, I continually find myself saying "%$[@*!!!, I
wish that operation which I did 15 minutes ago had been done on a
hardcopy!"
Being able to go back and look at what you did before is a big
advantage, which is not necessarily lost when you work on a video
terminal. Keeping a record of the output that goes on the terminal
is trivial for a computer to do.
I am therefore lead to believe that, if a person had both a
screen terminal and a hardcopy terminal available, that person
might do most of his/her work on the hardcopy terminal,
reserving the screen for times when fast output or a video
editor was essential.
If I had both available, I would not use the hardcopy terminal
except for a hard copy output device (and not very often for that).
A video editor is never needed, but they are much easier to work
with. I spend over 75% of my time in the editor. I always *want*
fast output. The rest of my time is spent running programs, with
the output being recorded by the editor. There is no problem of
losing the output from 15 minutes ago. The only reason I can see
for preferring a hardcopy terminal over a video terminal is
ignorance of what can be done with a video terminal with a good
environment.
Of course, it's not nearly as good as what can be done on a micro
with a bit mapped display.
B.J.
------------------------------
Date: 12 Oct 82 19:08:46 EDT (Tue)
From: Andrew Scott Beals <andrew.umcp-cs@UDel-Relay>
Subject: ``... or a video editor was essential''
wha??? a screen editor is ABSOLUTELY essential! I found that going
from cp/m's ed (a ``context editor'') to WordStar (still, in my
opinion the best fse/wp around (I learned it w/o doc)), my
productivity doubled.
------------------------------
Date: 13-Oct-82 1:53PM-EDT (Wed)
From: M-C vanLeunen <Vanleunen at YALE>
Subject: writing in one's head
Date: 4 Oct 1982 15:08:44-EDT
From: mullen at NRL-CSS (Preston Mullen)
... Remember, in the old days people wrote with pen and ink, and they
often (I know this seems impossible) wrote things from start to
finish without revision; amazingly, many of the products of such
a ridiculously outmoded process are now considered to be some of
the finest examples of lucid writing!
I know of only one author whose work we now consider a fine example
of lucidity who did not revise with pen on paper (Edward Gibbon).
He is regarded as a marvel and a freak precisely because of his
bizarre ability to compose in his head. The notion that this
ability is necessary or desirable does considerable harm to writers
-- and readers.
------------------------------
End of WorkS Digest
*******************
-------
∂21-Oct-82 1207 AVB WORKS Digest V2 #82
∂20-Oct-82 0922 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #82
Date: 20 Oct 1982 0119-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #82
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 20 October 1982 Volume 2 : Issue 82
Today's Topics:
Hardware - Optical Mice,
Programming - Screen Editors (7 msgs)
----------------------------------------------------------------------
Date: 14 Oct 82 12:18:07-PDT (Thu)
From: menlo70!sri-unix!fortune!megatest!sun!shannon at Ucb-C70
Subject: Re: optical mice
We have used the Mouse Systems optical mice and they seem to work
pretty well. The prototype design was a hemisphere shape with three
buttons on the front. Everyone who had never used a mouse before
though it was the best design and the most comfortable. The
production design will be flat with three buttons on the top, sort
of your canonical mouse shape. We'll be selling a parallel
interface version on the Sun Workstation in the near future. Since
we only have one mouse available in-house so far we really don't
have that much experience with them but initial impressions are
favorable.
Bill Shannon
sun!shannon
Sun Microsystems Inc.
------------------------------
Date: 14 Oct 1982 1441-EDT
From: Larry Seiler <SEILER at MIT-XX>
Subject: Up with hard copies, down with hard copy terminals
I haven't had to work on a hardcopy terminal for a long time,
and I hope I never have to again. Quite aside from the fact that
you can't screen edit on them, I find them annoying for at least
three reasons: they are noisy, they are slow, and the print head
gets in the way.
On the other hand, I appreciate the arguments in favor of having
a hard copy record of my work to look at. I know that some people
are able to write a paper with a screen editor without ever looking
at a hard copy. I can't work that way. After an editing session,
in which I have made mostly local changes to my document, I print it
out so that I can consider global changes. (Should I switch the
positions of sections 2 and 4? If I do, how does that affect
section 3?) To do this efficiently, I need to be able to have
several different parts of the document in my field of view at once,
and a display screen would have to be 2' square (at least) to do the
same thing I can do easily with pieces of paper.
So to me, the ideal situation is to do all my work at a display
terminal and have a fast printing device somewhere close by. But
given a choice between working at a printing terminal, and having a
screen without any printer nearby, I would almost always choose the
screen. To me, the advantage of having all my work automatically
printed out doesn't even match the irritations of using a hard copy
terminal, much less match the advantages of using a screen.
Larry Seiler
------------------------------
Date: 14 October 1982 20:56-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: "Undo"
To: ELLEN at MIT-XX
I too save my edit to disk just before I do something I think will
be dangerous, and I also save my edit to disk every few minutes.
But phone line noise doesn't first save my edit, so sometimes I am
in the middle of a long delicate edit and just before my next
regular save something horrible happens and I have to either lose my
last 5-10 minutes of edit or find some way to UNDO the phone line
noise damage. (Someday I'll do all this thru a PCNET link, and have
zero error rate except for my clumsy fingers, but for now...)
Perhaps on workstations with error-free communication internally
and/or to remote processor, this problem will be lessened.
------------------------------
Date: 14 October 1982 21:01-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: Screen terminals versus hardcopy terminals
To: WEINRICH at RUTGERS
Transcript is standard in EMACS too. You can do ctrl-meta-? L at
almost any time to get a printout of the last 50 characters you
typed or the phone line noise typed for you or your fingers
accidentally bumped. But then you have to figure out yourself how to
undo the strange unexpected thing that happened (but at least you
can find out what happened. some commands can be undone by yanking
killed text, others by MM UNDO command, a few you just lose on).
------------------------------
Date: 14 October 1982 21:07-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: Re: Screen Editors and UNDO
To: WEINRICH at RUTGERS
cc: GILLMANN at USC-ISIB
One very good reason for using CRT instead of hardcopy is speed. If
you're browsing WORKS digest, a fast CRT is about ten times as fast
as the fastest printing terminal, even faster than most line
printers. Another reason is quiet, the only noise is the keyclicks
of your fingers and the music you have playing (and maybe the fan
and of course the bell when needed to get your attention).
------------------------------
Date: 15 October 1982 00:51-EDT
From: Ittai Hershman <ITTAI at MIT-MC>
Subject: Screen Editors and UNDO
To: WEINRICH at RUTGERS
cc: MACRAK at MIT-MC, GILLMANN at USC-ISIB
Most terminal users want hardcopy for 2 reasons. One, already
mentioned, is to review something (a program, terminal session,
whatever) in a convenient manner. Two, is to "jot something down"
for reference when a terminal is unavailable (e.g. on the bus going
home from work) or to communicate with someone who has no access to
the computer in question.
Clearly, in an optimal situation, hardcopy is always desirable to
COMPLEMENT a display terminal. A hardcopy terminal hardly qualifies
for either task, though.
Most display terminals have printer ports. Connecting a suitable
printer to your terminal should solve all the problems. Suitable?
Well, if you need fast (really fast) "down-n-dirty" hardcopy, then
buy an EPSON, OKIDATA etc. type dot-matrix printer, and perhaps one
of those new-fangled tiny spooling devices to free up your terminal.
If you write letters and the like, you should consider one of the
faster (~55cps) daisy-wheel printers. The price will be comparable
to the cost of a hardcopy terminal. It will be more efficient in
that you benefit from the increased productivity of display editors,
and you benefit from the increased quality/speed of the hardcopying
process.
I fail to see the point being made. This letter took no great
insight to write--am I missing something. Surely a good
TERMINAL/PRINTER complement is more efficient than a crufty printing
terminal. I do agree, though, that hardcopy is useful. Yow, what a
stimulating piece of news!!!
-Ittai
BTW doesn't HP have a display terminal with a thermal printer stuck
into the top of the unit?!
------------------------------
Date: 15 Oct 1982 0042-MDT
From: Chip Maguire
Subject: Re: WORKS Digest V2 #81
Sender: MAGUIRE at UTAH-20
Re: Apollo windows and Hardcopy
I have been using an Apollo for the purpose of porting a
LISP system (PSL) and for use with a graphical programming
environment that I'm designing and building. I thus produce both
text and pictures (actually graphs) and like to have hardcopies (for
people to write comments on and for use in a dissertation). I
simply implemented a screen dumping program which dumps the bit map
as a run length encoded file. You can now file these files for later
use - or immediately ship it over a line to a VAX that has a
Versatec printer on it an about 1 min after the file gets to the VAX
you have a sheet of paper. The time to ship is a function of screen
complexity, system load on the 2 machines, and the representation
chosen for encoding (I have chosen a printable subset of ASCII which
results in runlength encodings of nibbles which are self delimiting
- and can go through a vanilla flavor file transfer program - which
gets routed through a LOCALNET 20 Tbox). The time for a typical
text plus line drawing transfer is 2-10 minutes at 9600 baud.
Pictures are available 1-to-1 dot wise (a quarter Versatec page) or
1-to-1 inches - looks just like the screen.
A big advantage of this approach is that you can format the
page the way you want AFTER the output was generated, i.e. arrange
the relative window sizes, their locations, etc. Also, you only get
hardcopy of the pages that you want - this keeps my 54 sq. ft.
office space from being buried in paper.
Chip
------------------------------
Date: 15 Oct 82 9:07:59-PDT (Fri)
To: works at Rutgers
From: hplabs!hao!csu-cs!bentson at Ucb-C70
Subject: Re: Up with hard copies, down with hard copy terminals
I once was able to use a terminal with a 19' diag screen and vector
drawn characters. It could display two pages of 66+ lines of about 130
characters. I found that I felt even more productive and sure of my
changes when using a full screen editor because I had a better
understanding of the context in which I was operating.
Has anyone else used a terminal with such a large screen? Can they
confirm my observations?
Randy Bentson
Colo State U - Comp Sci
hplabs!csu-cs!bentson
------------------------------
End of WorkS Digest
*******************
-------
∂24-Oct-82 2037 AVB WORKS Digest V2 #83
∂22-Oct-82 1900 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #83
Date: 22 Oct 1982 0001-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #83
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Friday, 22 October 1982 Volume 2 : Issue 83
Today's Topics:
Programming - Screen Editors (2 msgs),
Publication - CMU Distributed Computing (2 msgs)
----------------------------------------------------------------------
Date: 20 Oct 82 23:48:44 EDT (Wed)
From: Craig Stanfill <craig.umcp-cs@UDel-Relay>
Subject: Hardcopy Terminals
I am currently using a Tektronix 4025 terminal. In many respects,
it is a thoroughly awful terminal - if you have ever used the thing,
you understand. However, it does have four very useful features:
1. Programmable keys. The 4025 is well provided with
special function keys, which can be programmed to send
arbitrary text to the host.
2. Large scrolling region 'above the screen'. When using
the terminal as a 'glass tty', the last hundred or so
lines of text will be retained.
3. Hardcopy device. If you really want to, you can take
hardcopies from the screen/scrolling region.
4. Convenient editing of screen contents. You can move
around on the screen, reverse the scroll, delete lines
etc. with minimal trouble.
The result of these features is that I have the best of both worlds
- both hardcopy and screen functions. On the one hand, it is
possible to run a screen editor on the terminal. (I refuse to work
with a non-screen editor - I guess I'm thoroughly spoiled). On the
other hand, when I am doing non-editor tasks (running lisp, the
shell, debugging programs), the terminal usually retains the last
5-10 minute's work. I find that I am constantly referring to the
region above the screen. I use this region for three purposes:
1. Referring back to what I have just done.
2. Holding output longer than one page. For example, if I
list my files, one to a line, and I have more than one
screen's worth of files, it is very convenient to let
the information scroll off the top of the screen and
look at it later.
3. Scratchpad. I can, for example, list all my files then
erase (from the screen) any files I am not interested
in. Impossible on hardcopy terminals.
In summary, I find that a hybrid terminal, which supports screen
functions yet keeps old scrolled information, to be extremely
useful.
------------------------------
Date: 21 Oct 1982 0356-EDT
From: Stephen Hancock <SFH at CMU-20C>
Subject: Transmition Line Noise & Undo
What we need are editors that will undo the last N character bursts.
This applies to both screen and paper style editors. A crude but
effective method would merely invisibly replay the editing commands
since the last save before the interruption.
------------------------------
Date: 20 Oct 1982 1627-EDT
From: DAVID.LEWIN <LEWIN at CMU-20C>
Subject: CMU Distributed Computing Agreement with IBM
To: Human-Nets at RUTGERS
The following are the news release and semi-technical backgrounder
on Carnegie-Mellon University's plans for a distributed personal
computing network which will be developed with IBM.
--David I. Lewin <LEWIN at CMU-20C>
Dir. of Science & Technology Information
Dept. of Public Relations
CMU
Contact: Don Hale For release: 1 p.m., Wednesday,
Carnegie-Mellon and IBM Sign
Joint Development Contract
PITTSBURGH--A prototype distributive computing project designed to
give every student at Carnegie-Mellon University direct personal
access to the full information resources of the university will be
developed jointly by CMU and International Business Machines
Corporation (IBM).
Dr. Richard M. Cyert, president of Carnegie-Mellon, said the goal of
the three-year agreement signed today is to lay the technological
foundation, in equipment and programming, for powerful computer
workstations and communications services to be available to students
and faculty, whether at home in an office or in a laboratory. The
development effort will build on existing software research done by
the CMU Department of Computer Science.
By 1986, several thousand personal workstations for the university's
staff, faculty and 5,500 students will be in place, CMU officials
predict.
"The comprehensive computing environment planned by the university
differs greatly from the traditional way computer facilities have
been used in higher education," Dr. Cyert said.
"For example, in 1991, we expect to have about 7,500 personal
workstations, each with its own powerful computer and graphics
display, all interconnected through a high-speed local area network.
In addition to communications between every workstation, there will
be a unified data file system and a central computing facility
available to all workstations.
"Our objective is to extend this computing system and supporting
network for faculty and students beyond the CMU campus to the
greater Pittsburgh area through cable television or telephone
lines," he said.
The agreement with IBM, which involves a commitment through a
three-year development phase, calls for the establishment of an
Information Technology Center (ITC) at the university. It will be
staffed by both IBM and CMU personnel. The agreement also expresses
the intent of IBM to continue its support through 1987, based on
progress of the project.
IBM will provide funds and equipment for the ITC. IBM and CMU
personnel will work together at the center to develop the
programming for the prototype computing environment.
"Carnegie-Mellon is aware that it now costs more than $10,000
annually for someone to attend college," Dr. Cyert said. "We want to
provide students with a competitive edge, and this is the next step
in meeting the challenges of the future.
"The university remains committed to a financial aid policy that
makes it possible for any qualified student to attend the
university."
"Carnegie-Mellon is an appropriate campus for this prototype
computing environment because it is a leader in computer science and
technological innovation," said Dr. Lewis Branscomb, IBM vice
president and chief scientist. "The university is large enough to
test this concept in all disciplines, yet small enough to make the
test economically feasible."
The agreement with IBM provides for the establishment of a
consortium of universities, with each university designating a
person as primary liaison with the CMU-IBM project. Regular meetings
of these designated individuals will be held and, as elements of the
integrated computing environment become operational, they may be
made available to members of the consortium.
###
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Carnegie-Mellon University's Personal Computing Environment
The personal computing environment at Carnegie-Mellon University
will be implemented in two stages, a two-year transition phase
introducing personal workstations into the CMU computing
environment, and an advanced phase, introducing a distributed
computing environment.
To get experience in working with personal workstations, a
substantial number of existing machines will be brought into the
Carnegie-Mellon computing environment over the next two years. These
transition machines will be linked to the current computing
facilities.
Currently under evaluation as the transition machine is a
workstation with a 16-bit (Motorola 68000) processor and a
bit-mapped graphic display, manufactured by the IBM Instruments
Division. Initially, over a hundred transition machines are
expected to be available on campus in the fall of 1983, growing to
several hundred in following years. Software, including an editor
and text processing facilities, will be developed at the
Carnegie-Mellon Computation Center to function in an environment
based on the UNIXtm operating system. It is expected that FORTRAN,
Pascal and the C programming languages will be supported.
While the transition system is implemented and evaluated, work will
be in progress within the joint CMU-IBM Information Technology
Center on software for the second phase of the university's personal
computing plan. During the transition period, IBM will work on
networking and advanced workstations.
Carnegie-Mellon's objective is to begin deploying the computing
environment resulting from integrating all these elements, including
a new operating system environment for distributed personal
computing, in late 1985.
The workstations will have a 32-bit processor with virtual memory
capable of executing 0.5-1 million instructions per second (MIPS),
from 500,000 to 1 millions bytes of random access memory, a
high-resolution bit-mapped graphics display, and a graphics tablet
and keyboard input. Both an on-board disc memory and color display
will be options.
Rather than using built-in disc storage, clusters of 50 to 100
workstations will share a file server through a local area network;
the clusters will be linked together--and to the university's
mainframe computers--through a backbone network. Users will be able
to access files from any workstation in the network.
------------------------------
Date: 20 Oct 1982 1633-EDT
From: DAVID.LEWIN <LEWIN at CMU-20C>
Subject: Personal Computing
To: cmu-bboards at CMU-10A, Human-Nets at RUTGERS
The overall design of the personal computing plan is a direct
outgrowth of CMU-CSD's SPICE Project, though I'm sure this is clear
from the official statements.
------------------------------
End of WorkS Digest
*******************
-------
∂26-Oct-82 1821 AVB WORKS Digest V2 #84
∂26-Oct-82 1134 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #84
Date: 25 Oct 1982 1938-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #84
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Monday, 25 October 1982 Volume 2 : Issue 84
Today's Topics:
Programming - Screen Editors (4 msgs),
Publications - CMU Distributed Computing &
Brutal Game of Survival
----------------------------------------------------------------------
Date: 21 Oct 82 14:56:16-PDT (Thu)
From: harpo!esquire!cmcl2!philabs!sdcsvax!laman at Ucb-C70
Subject: Re: Up with hard copies, down with hard copy terminals
I used a Tektronix 4014, and they had to drag me away from it. I
really liked the large screen! (It was at 9600 baud too). It was
great (even if it were at a slow baud rate) for editing programs. I
could lots of the surrounding code, so I didn't need list so
periodically. I am still trying to get used to 24 line screens.
Mike Laman
...sdcsvax!laman
P.S. There were 66 lines a TWO (count them TWO) columns! Sigh.
------------------------------
Date: 22 October 1982 10:58-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Hardcopy Terminals
To: craig.umcp-cs at UDEL-RELAY
cc: FJW at MIT-MC
The one respect that our TEK4025 is awful is that our version of the
PROM doesn't appear to be fast enough to handle incoming cursor
commands while I type outgoing characters. Do you know if that
misfeature has been fixed in any later release?
One reason I suspect for its slowness is the long sequences of
cursor commands it is designed to accept. Another, I suppose, is
the programmable keys - not only are the function keys programmable,
ALL the keys are!
On the plus side, that large screen memory can be used for prompted
file transfers between machines on a clean line. The only other
"terminals" I'm aware of that can also do that are the HP2648A, the
TI-765, and the Computer Devices MiniTerm, if ordered with that
option. The HP doesn't have nearly enough memory as the TEK to make
that review capability reasonable, and the long persistence of the
TEK's phosphor is annoying. Both the HP and the TEK are last resort
terminals - I prefer to use the good old ADM3A sitting next to the
HP when there's a choice...
--Frank
------------------------------
Date: 23 Oct 1982 17:36 EDT
From: Sherry.HENR at PARC-MAXC
Subject: HardCopies vs Hardcopy terminals
To: Ittai Hershman <ITTAI at MIT-MC>
After working on a variety of systems, I have noticed that the type
of SYSTEM and the way it is being being used determines the terminal
requirements. I have encountered four types of systems so far.
WorkStations: (i.e. alto, star) These systems are not
designed to have a normal terminal and you CAN'T attach a hardcopy
terminal to them. Fortunately, they usually have large screens that
can hold a lot of information, and they do have provisions for
printing many things. We have found that the large amount of
information on the screen can be confusing, and the rapid display
rate actually rushes the viewer. We have also noticed a LOT of our
people working on altos printing their mail and taking it home
instead of reading it on the screen and deleting it. I speculate
that this is because we do not have the time to read all of our mail
at work, and we do not have workstations at home to read it on.
Treating-the-screen-as-an-electronic-punchcard-systems:
These systems are designed for hardcopy terminals and make very
little use of CRT based functions (such as backspace deleting and
screen editing). An example of such a system is CP-V on our SDS
Sigma Mainframes. Since the system wasn't really designed for CRT
type terminals, few of the utilities in the system are intended to
be used by a system that can not remember everything you typed, and
you end up having to write everything down. For example, if you
batch a job with a job file called J:MYJOB, it will respond with
something like `JOB 31 ENTERED'. All references to the job from now
on MUST use that number, and when the job finally prints out on the
line printer, its ID is that number, NOT the job file name. Thus, a
printing terminal is called for.
Screen Oriented Systems: Many such systems are
designed around a special screen (such as HP systems that really
need an HP terminal). These systems allow you to keep logs of what
you are doing and almost always allow you to re-direct output so
that you can get a hardcopy from a common printer. A hardcopy
terminal would only slow you down, and you would lose your
screen-editing ability. On HP-1000 systems, when you delete a
character, it just backspaces over the character and lets you
re-type it, even if you are on a hardcopy terminal (very messy).
Development systems: When developing and debugging a
system, you often need to dump huge amounts of raw data to your
terminal. Sometimes it would be nice to be able to print what's
going on (as in the case of unexpected crashes), so you can have a
permanent record of what happened. Other times, the lack of speed
while printing would slow you down. On such systems, it would be
nice to have both capabilities.
Speaking of both capabilities, HP DOES make a display terminal that
has a thermal printer 'stuck' on the top. It is called the HP2621P
(there is a cheaper model called the HP2621B). This terminal will
work with HP screen editors, and also allows you to print in two
basic modes. For those who occasionally need a hardcopy of a piece
of information on the screen, you can stop output and position the
cursor at the line you wish to print, and print that line, or all
the lines from there to the bottom of the screen. for those of you
who want it to look like a plain hardcopy terminal, you can
LOG-BOTTOM and print each line automatically just as it scrolls up
off of the last line on the screen. (It does not print a character
at a time, so you can use backspace to correct the line before
printing.) We have a few of these for use on most of our systems
and they are usually in high demand. They are especially useful on
development systems, however, the thermal paper is much more
expensive than cheap line printer paper. This means that you might
want a cheap hardcopy terminal for systems designed for hardcopy
terminals (and for operator consoles).
Randy Sherry
------------------------------
Date: 24 October 1982 02:08-EDT
From: Ittai Hershman <ITTAI at MIT-MC>
Subject: HardCopies vs Hardcopy terminals
To: Sherry.HENR at PARC-MAXC
Well, obviously line oriented, pre-CRT, systems are an exception,
but even there-you'd be surprised. The first mainframe I used was
an Amdahl V6 running WYLBUR, and believe it or not--even there
people found CRTs much easier to work with (being able to see under
the print-head was one small advantage...).
I have a laser printer at work, so I do not need much else.
However, I may buy a cheap OKIDATA (like EPSON but with integral
serial port) and a new gadget I heard about that works with the H19
(which is my home terminal). This device allows me to print an
entire screen off in one shot--it catches the data from the terminal
at a fast baud rate, buffers it and prints at the printers
speed--this frees me from the physical specs of the printer and
allows me to proceed with my work. All this costs about the same as
an LA36 (yuch!). Indeed many terminals come with this standard.
The best of both worlds.
BTW if people hardcopy their mail to read at home, how do they
respond? I tend to doubt that they pencil their thoughts on paper
at home, and then type it into the system...
-Ittai
------------------------------
Date: 22 Oct 1982 1246-EDT
From: DAVID.LEWIN <LEWIN at CMU-20C>
Subject: CMU-CSD and the CMU/IBM plans
The following is from comments on the relationship between the
CMU-CSD Spice Project and the CMU/IBM Personal Computing Environment
sent to me by Scott Fahlman <Fahlman at CMU-20C>, reprinted with his
permission:
"Spice and the CMU campus computing plan are separate efforts with
distinct goals, though we expect a lot of cross-fertilization of
ideas. Spice is aimed at developing a very powerful personal
computing environment for the research community, while the campus
computing plan is (initially) aimed at somewhat smaller machines for
the general university environment, with emphasis on making the
machines accessible to less experienced users.
One possible point of commonality is that the kernel of the Spice
operating system, called Accent, may become the basis for the
operating system used in the campus-wide system. It is important to
emphasize, however, that Accent is just a part of the total
environment that makes up Spice, and that some parts of Spice will
not be portable to the campus-wide system, at least until more
powerful machines are available for campus-wide use.
We in the Spice project look forward to cooperating with the
university-wide computing initiative, but we want to take care to
keep our own goals and our own identity intact."
------------------------------
Date: 24-Oct-82 17:46-PDT
From: DAUL at OFFICE
Subject: THE ULTIMATE WORKS STATION (sorry about the length)
To: menlo70!herriot at ucb-c70, menlo70!johnston at ucb-c70
From TIME magazine August 16, 1982
BRUTAL GAME OF SURVIVAL
A select group of 15 U.S. Army officers went to Livermore,
Calif., last year to do what on one had done since Hiroshima and
Nagasaki: set off nuclear weapons in a battlefield situation.
The action took place, TRON-like, entirely within the circuitry
of a large research computer, but the officers sitting in front
of the machine's display screens were not just playing video
games. They were in Lawrence Livermore National Laboratory at
the Pentagon's request to test the world's most powerful combat
simulator. The fate of the earth after the fallout cleared is
classified information, but it is no secret that the
sophistication of the computer program that created the war game
made a big hit with the brass. Says Lieut. Colonel Robert
Crissman of the Army's Training and Doctrine Command: "It
exceeded out expectations."
The five-week session was the start of a $2.45 million Army
project called Janus, after the two-faced god that guarded Rome
in wartime. Beginning next year, the U.S. Army War College in
Carlisle, Pa., which trains high-ranking officers for tip
command positions, will use a copy of the Janus program as a
regular part of its ten-month curriculum. "Janus," says one of
its Livermore admirers, "is light-years ahead of any Atari game."
Conventional war games date back to the late 18th century, when
they were laboriously played with wooden blocks on colorfully
painted boards. Today's high-speed computers, with their
prodigious memory banks and supersmart silicon processing chips,
can paint realistic playing fields and speed the action up to
nearly "real time." While aspects of the Janus program remain
classified, it could be described as a computer-age variation of
the children's sea game, Battleship. Janus, which is played on
land, pits the U.S. against forces modeled after the Soviets'.
Two teams of players divided into separate rooms in Livermore's
Combat Simulation Laboratory. Sitting at $100,000 battle
stations jammed with the latest computer hardware, they slide
plastic "pucks" across electronic graphics tablets to command the
full paraphernalia of modern war: tanks and personnel carriers,
jets and helicopters, artillery pieces, chemical munitions and
an arsenal of tactical nuclear weapons. A few typed commands to
a VAX 11/780 minicomputer conjures up rivers, mountains and
cities.
Drawing on the resources of the Defense Mapping Agency, the
machine can display in full topographical detail any 15-square
mile slice of the earth, from the Straits of Hormuz to the
Falkland Islands, although the game is most often played on the
West German real estate near the Iron Curtain.
A Janus computer war typically starts with a column of Soviet
tanks (red symbols on the video screen) lumbering into sight and
rolling through pastureland toward the town of Bad Hersfeld,
some 120 miles east of Bonn.
The tanks skirt green-shaded woods and head for the blue line of
the Fulda River. The Livermore programmers have lavished
colorful detail on their simulation: as the action mounts, land
mines explode in flashes of white, and helicopter symbols appear
over enemy outposts. Artillery fire slashes across the screen
like a laser sword. The flight time of the shells is
preprogrammed to the millisecond; even reloading is figured in.
The computer, executing 2 million programming instructions per
second, takes 20 seconds to analyze the effects of a ten-kiloton
blast. Towns are reduced to rubble. Forests erupt in flames,
represented by flickering red dots. Temperature, humidity and
wind speed must be reconed with; they affect the way fallout
will blow and how fast a fireball will spread. "You get a real
feeling for the dynamics and time pressures of combat." says
Lieut. Colonel Crissman.
The Defense Department believes that the Janus program can train
officers to think more clearly about the costs and benefits of
battlefield strategies. As one retired officer puts it: "You
don't learn about these weapons on the rifle range." Certainly
participants learned some pointed lessons at Livermore. One
was the tendency of even veteran offices to "go nuke"
indiscriminately. "If they were caught out of position, they
would try to retrieve the battle with nuclear weapons," says
Janus Director Donald Blumenthal, a retired Army colonel working
at the California weapons-research laboratory. One offices who
let his position deteriorate beyond recovery reached into his
megaton arsenal, picked the weapon and dropped it where he
guessed the Red Army had massed. The bomb detonated in a flash
of orange. A growing white circle indicated that he had
destroyed his opponent's forces. But the weapon he chose was so
powerful that it also wiped out his own troops. His only
comment: a subdued "Holy smoke." Says George Smith, one of the
program's designers: "The rapidity of casualties surprised them
all."
The Army argues that such lessons are best learned well in
advance of real-life combat situations. "It's a fantastic tool
for training," says Lieut. Colonel Robert Turner, a
nuclear-weapons specialist at the Pentagon. Others are not so
sure. Jerome Wiesner, former president of the Massachusetts
Institute of Technology and sometime presidential science
adviser, suggests that no amount of computer training will enable
U.S. generals to prevent Europe from being "turned into a big
lake" if there is a nuclear war on the continent. One young
computer buff who recently used Janus found the experience
extremely unsettling: "It's all so cold-blooded. I felt like I
was looking into a coffin."
Says M.I.T. Sociology Professor Sherry Turkle, an expert on the
psychological impact of computer games: "The training could go
two ways. It could have a numbing effect, making nuclear war
more thinkable, or it could heighten the revulsion. The
computer is confronting us with something we tend to repress: the
brute fact that we are playing with the survival of the planet."
--By Phillip Faflick Reported by Dick Thompson/San Francisco
------------------------------
End of WorkS Digest
*******************
-------
∂06-Nov-82 1840 AVB WORKS Digest V2 #85
∂04-Nov-82 2035 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #85
Date: 28 Oct 1982 2243-EDT
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #85
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Thursday, 28 October 1982 Volume 2 : Issue 85
Today's Topics:
Programming - Screen Editors (5 msgs),
Hardware - Swiss Mice,
Queries - Information Wanted on Desktop UNIX Systems
----------------------------------------------------------------------
Date: 26 Oct 82 05:04:27 EDT (Tue)
From: Chris Torek <chris.umcp-cs@UDel-Relay>
Subject: Tek 4025 terminals
The problem someone mentioned -- that the terminal gets confused in
the middle of escape sequences if the user types while this is going
on -- is generally not a problem at 4800 or 9600 baud. If you're
using the Tek over a phone line, you're out of luck.
I talked to a Tek repairman, and he said that the ROMs we had were
probably 2.5 (try !DFO 31; if it crashes the terminal you've got the
same ROMs) and that Tek has a new version out, with at least the
delete font bug fixed. It may have some new features too. Ask your
local Tek representative.
- Chris
P.S. If anyone out there has the new version, how does it compare
to the old version?
------------------------------
Date: 26 Oct 82 22:29:28-EDT (Tue)
From: Ron Natalie <ron@BRL>
To: FJW at Mit-Mc, wancho at Brl, craig.Umcp-Cs at BRL-BMD,
hardware at Brl
Subject: Tektronics 4025/4027
Frank:
I may be wrong but I perceived it is not a timing problem
that is wrong with the 4025/7s. As you may have noticed you may
type commands (beginning with the definable command character) from
either the host or the keyboard. Commands from the keyboard
(starting with the command character and proceeding up to a carriage
return or another command character) are intercepted and interpreted
without sending them to the host at all. However, it seems that
when a command has been initiated, the string that follows the
command character is received from both the keyboard and the host,
regardless of who sent the command character to initiated it. This
means that if a command has been sent from the host and you type a
character on the keyboard, it gets inserted into the command string.
Frequently this causes an error, aborting the command (since your
inserted letter makes the command sequence incorrect). The
remainder of the command from the host gets dumped on your screen as
normal text from the host. We first noticed this while trying to
get the search game to work. The game is continually updating the
screen while the player asynchronously spews characters at it to
move around.
All in all I like the 4025/7. It is as nice of a text
terminal that I have used with the scrolling memory, and is a good
graphics terminal too. (usually graphics terminals are lousy to use
for text terminals). The programmable keys and the general nice
feel of the keyboard are wonderful. We also had a gizmo from
Versatec that could plug in to up to four terminals via the hardcopy
port. This made a regular Versatec plotter look like the Tek
hardcopy device without the expense or the bother of the
photographic process they use (and they don't fade and turn yellow
like the Tek prints do). The device was transparent to the versatec
when it wasn't printing and you could therefore chain them together
or put them in line with the cable coming from the computer
interface.
We had early models, and as a result each seemed to have a
different firmware in it. I suppose this has been fixed. In
conclusion, I'd like to mention a little thing I set the 4027 (color
4025) to do with the programmable keys. I set the screen up to have
a background color of dark green, and set the "ink" color to be
bright green. Therefore in 4010 emulation mode it really looks like
a 4010. I programmed the erase button to momentarily make the
entire screen bright green while erasing it, giving the
characteristic Tektronix flash. I showed it to the Tek salesman and
he got sick.
CIAO
-Ron
------------------------------
Date: 26 Oct 82 01:56:38 EDT (Tue)
From: Craig Stanfill <craig.umcp-cs@UDel-Relay>
Subject: Tektronix 4025 misfeatures.
To: Frank J Wancho <FJW@Mit-Mc>, craig.umcp-cs at UDel-Relay
Cc: FJW at Mit-Mc
You have complained that your version of the TEK-4025 firmware is
too slow to handle incoming cursor commands while you are typing.
Is your host echoing your typing? If the host echoes text from the
keyboard inside of a cursor motion or other command the result will,
of course, be garbled.
By the way, I have a unix-to-tek synchronization filter; the TEK
doesn't know the x-on/x-off protocol, but there are ways of
synchronizing communication which partly make up for this problem.
The terminal is slow, but this is less of a problem than two
misfeatures in the firmware.
1. The screen may be divided into two regions, the Workspace
and the Monitor. The Workspace has cursor addressing and
special visual attributes; the Monitor has scrolling.
Unfortunately, whenever the cursor is in the Workspace,
text goes directly into the workspace, not the host.
This makes the Workspace useless for most interactive
tasks - editing, for example. It is possible for the
Host to talk to the Workspace without displaying a
cursor, but a display without a cursor is almost useless.
The terminal is usable only because our visual editor
('vi') is smart enough to use the limited number of
cursor motion commands which work in the monitor.
2. Visual attributes are done wrong. With most terminals,
the host sends a command which means 'display all
following text underlined', (or blinking, or reverse
video, etc.). With the TEK 4025, you send a code which
gets inserted in the screen, and means "underline from
here to the next attribute code, or the end of the line."
A program which is written assuming an interface similar
to the 'normal' cannot be made to work; if underlined
text spans two lines, the text on the second line will
not be underlined. Programs which update the screen
become unworkable; old attribute codes interfere with
each other. Inserting a single underlined character in
the middle of the screen may cause the rest of the line
to become underlined. In fact, inserting a single
underlined character in the display is safe only if you
have a complete model of everything that has been done to
the screen. This problem is a result of hardware
decisions, but the firmware could have compensated for
the hardware design.
I would like to know exactly how tektronix came up with the
interface to this terminal. I tend to think they didn't do much
homework. They should have taken care not to write firmware which
made their terminal incompatible with most software.
------------------------------
Date: 28 Oct 1982 2227-EDT
From: Mel <Pleasant at RUTGERS>
Subject: Administrivia on the Tektronics 402x terminals
Office: H028 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x2287
Home: 81 Gage Road, East Brunswick, NJ 08816, (201) 828-4266
I've included the three former messages on this digest so as to not
leave the discussion in mid-stream. However, I'd like to ask that
those of you who are interested in continuing the discussion do so
without cc'ing the WorkS digest. Unfortunately, I believe the
discussion has wondered too far away from the topic of workstations to
continue on this list.
-Mel
------------------------------
Date: 26 Oct 82 11:06:32-PDT (Tue)
From: decvax!duke!unc!wm at Ucb-C70
Subject: I come not to praise ASCII, ...
Isn't the ASCII character set long overdue for a major overhaul? I
keep seeing people complaining about funny escape sequences required
for terminal control and so on. We've got the 8th bit to play with,
come on, let's use it. Furthermore, don't you think that instead of
leaving a standards committee to come up with some outdated
standard, the net would be an interesting vehicle to formulate a
standard? I propose that the following additions be made to the
ASCII character set.
Reserve the use of the 8th bit. If clear, the remaining 7 bits
should form an existing ASCII code. If set, then the remaining 7
bits form one of 128 characters, divided into 4 groups of 32
characters. These groups are:
Extended control characters. These should include (at least), modem
control (i.e., autodialing, handshaking), CRT terminal screen
control (cursor addressing, etc.), terminal identification codes (so
a system can tell what kind of terminal you are on), terminal memory
management for terminals with multiple pages of screen memory,
controls for super- and sub-scripting, alternate character sets, and
so forth.
Workstation control characters. Support for advanced (i.e. bit
mapped) terminals. I'm not sure all that is needed, but it should
at least include control for changing fonts and point sizes, support
for proportional spacing, window management, characters to control
input devices such as mice. Maybe support for color and enough
graphics commands to change a pixel, write a window with a raster of
pixels, draw a line, etc. (in other words, enough to do some simple
graphics such as graphs and charts). The keyword here is
extensibility. Assume we will not know all that will be required in
the future. For example, some control characters for networking may
be valuable.
Function key characters. Function keys are underused. If they were
standardized they could be used in such things as screen editors
where they are invaluable.
Extended characters. Things such as the copyright sign that is
required to be displayed in copyrighted software, but is not
available in the current character set. I can think of many other
characters that would be nice to have: arrows, simple math symbols,
editing symbols, etc. Note that these characters are not for an
alternate character set (such as APL), those should be available
using an extended control character to change character sets.
This list in incomplete, and is mainly designed to invite
discussion. What are the pitfalls here? I know there will be some
compatibility problems, but these seem reasonably easy to overcome.
Wm Leler, UNC - Chapel Hill
------------------------------
Date: 19 Oct 82 11:20:39-PDT (Tue)
From: menlo70!sri-unix!fortune!megatest!sun!decwrl!baskett at Ucb-C70
Subject: ergonomic mice
While the Depraz Mouse looks cute and feels nice, the hemisphere is
so large that it is difficult to have your fingers on the buttons
and the heel of your hand on the table at the same time. Having the
heel of your hand on the table makes fine positioning with the hand
easier. Also, having the buttons move in the plane of the table
instead of perpendicular to it means that there is a tendency to
move the mouse inadvertently when pushing the buttons. But the
insides appear to be superior in principle to other mechanical mice
I have seen and the insides are much smaller than the current
hemisphere.
------------------------------
Date: 26 Oct 82 16:49:39-PDT (Tue)
From: harpo!ihps3!houxi!houxn!hsc at Ucb-C70
Subject: Info. wanted on desktop UNIX systems
I am compiling a set of descriptions of desktop,
microprocessor-based UNIX systems. Pointers to manufacturers,
distributors, magazine articles, reports, personal comments, sales
literature, etc. would be appreciated. If there is sufficient
interest I will publish a summary.
Harvey S. Cohen (houxn!hsc)
1C314 Bell Labs
307 Middletown/Lincroft Rd.
Lincroft, NJ 07738
(201)576-6059
------------------------------
End of WorkS Digest
*******************
-------
∂16-Nov-82 1230 AVBα WORKS Digest V2 #87
∂13-Nov-82 0036 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #87
Date: 13 Nov 1982 0149-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #87
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 13 November 1982 Volume 2 : Issue 87
Today's Topics:
Queries - Combinations of Telephones and Terminals (2 msgs),
Programming - Extending the ASCII Character Set (4 msgs)
----------------------------------------------------------------------
Date: Tuesday, 9 Nov 1982 10:35-PST
To: Human-Nets at RUTGERS, TELECOM at USC-ECLB, Info-Terms at MIT-MC,
Lauren at UCLA-SECURITY
SUBJECT: Combinations of Telephones and Terminals
From: norm at RAND-UNIX
I am looking for products which combine a CRT terminal and a
telephone. I recall seeing several advertised but can't recall the
vendor names.
Any pointers to the makers of such gadgets would be appreciated.
(I already know about Northern Telecom and Mitel.)
I am:
Norm at Rand-Unix
or
Norm Shapiro, 1700 Main Street, Santa Monica CA 90406
or
(213) 393 0411 - Norm Shapiro
------------------------------
Date: 10 Nov 82 17:04:35-EST (Wed)
From: Ron Natalie <ron@BRL>
To: norm at Rand-Unix
cc: TELECOM at Usc-Eclb, Info-Terms at Mit-Mc,
Human-Nets at Rutgers, Lauren at Ucla-Security
Subject: Re: Combinations of Telephones and Terminals
Bell makes this CUTE little CRT which is part of a telephone, and
has a little full ascii keyboard detached from it. I think it's
called a Datascan? Anyhow, the DoD DEERS project is interested in
them for putting ASCII terminals in cramped quarters (I believe the
application was pharmacy counters in Veteran's centers).
------------------------------
Date: 9 Nov 1982 12:27 PST
From: Deutsch at PARC-MAXC
Subject: SUPDUP protocol, Xerox protocols
The SUPDUP protocol is unsuitable for use with proportionally spaced
fonts, multiple fonts, or general bitmap graphics. It is a nice
protocol for fixed-pitch, "matrix of characters" type displays. I
think it has been used with proportional fonts, but you can't really
use its editing capabilities in that case.
The Xerox page composition standard (Interpress) is not designed as
a dynamic protocol: it is designed only to express the appearance of
a static printed page. I have this from one of its designers.
There might be a way of adapting it to a dynamic display, but I am
inclined to think this would require major changes.
People often make the mistake of confusing keyboard protocols with
display protocols. The link between what combinations of buttons
one can depress on a keyboard and what images one can present on a
display is a tenuous one at best. For example, notions like
"meta-bits" make sense only in the keyboard context, while notions
of font and face make sense only in the display context.
------------------------------
Date: 10 Nov 1982 0217-PST
From: Les Earnest <LES at SU-AI>
Subject: 8 bit ASCII versus 16 bit supercode
I come not to praise ASCII but to bury it. It was a nice solution
to the limited need for (predominantly English) communication among
teleprinters with paper tape punching capability. It shows signs of
strain when one extends or modifies it to work with other European
languages or more advanced terminals.
ASCII doesn't cope with Greek, Russian, Hebrew, or Arabic alphabets
and is incapable of dealing with ideographic languages such as
Chinese and Japanese. Closer to home, it doesn't let you use
integral signs or many other symbols that mathematicians have come
to know and love, nor can it deal with the special symbols of
meteorologists, astronomers, astrologists, electronic engineers, or
whatnot.
If we extend it to include control codes appropriate to today's
terminals, we will have to modify or perhaps repudiate it for the
next generation. Is it hopeless, then, to try to standardize symbol
codes? Certainly not.
What we need is standardization on a much grander scale. For
example, a 16 bit code (65K symbols) would provide enough space to
allocate codes to all the symbols currently in use on planet Earth
with quite a bit of room to spare. Of course, developing a standard
of this sort would be a nontrivial exercise, but I believe that this
issue must be faced in some form before truly worldwide
communications and digital libraries can come into existence.
In addition to representing various symbol sets, the standard should
also include graphical primitives in the form of control codes with
parameters.
Obviously, it would not be as efficient to communicate with 16 bit
codes as with 7 or 8 bit codes. Fortunately, we can have both
generality and efficiency if, instead of standardizing communication
codes, we standardize a "code definition language" -- i.e. a way of
describing a certain communication code in terms of the 16 bit
standard. A simple form of this idea would be to preface a
communication with a list of (say) 7 bit codes and their 16 bit
supercode equivalents. Once the correspondence had been given, the
rest of the communication could be given in the 7 bit code.
Using this scheme, the more common variants of ASCII could each be
unambiguously defined in terms of the supercode, as could EBCDIC and
other abominations. The existence of such a standard would
substantially aid the writing of translation programs among the more
commonly used codes.
Of course, it should not be necessary to redefine codes in every
transmission if the recipient can preserve code definitions. Once a
code has been defined, it can be made the default for a given
sender, or can be given a short name that is invoked at the
beginning of transmission.
If we had a standard code description language, it could also aid in
achieving more compact representations of text without loss of
information. For example, we could code certain letter sequences so
as to exploit redundancies in the particular language. As long as
the code definition is preserved with the text, the latter can be
fully reconstructed.
In summary, what we need is not an 8 or 9 bit ASCII but a standard
that can hold *all* the symbols that are used to represent the
accumulated knowledge of this planet. A 16 bit supercode is about
right. We also need a code description language that is both
efficient and sufficiently general to represent the more useful
communication codes.
Even if we can achieve a consensus on the need for such standards,
there would remain a great deal of work in assigning codes to the
major alphabets and ideographic sets. Fortunately, there would be
enough room in the symbol space so that this task could be
partitioned and tackled in parallel by the interested parties.
Anyone want to start?
Les Earnest
------------------------------
Date: 10 Nov 82 17:55:06-PST (Wed)
From: harpo!duke!bcw at Ucb-C70
Subject: Re: 8 bit ASCII versus 16 bit supercode
From: Bruce C. Wright @ Duke University
Re: 16-bit codes
While I think this effort would be laudable, I think that a 16-bit
code would probably be too inefficient for most purposes, even with
prefixed headers and so forth. What would probably be more
efficient (and would also remove the silly restriction of 65K
symbols which may run out some time - Chinese has a *lot* of
symbols, and you might want to encode some Western words like
articles and even idiomatic phrases as codes so as not to store the
individual characters) would be to make the code a variable- length
code (sort of like PDP-11 instruction op codes). It wouldn't be
necessary to make the code variable down to the bit level; it would
probably be sufficient to make it variable to something like the
byte level or thereabouts. It might even be possible to make ASCII
or even (shudder) EBCDIC be special modes with lead-in codes.
The only problem with this is the enormous amount of software which
doesn't know about such things...
Bruce C. Wright @ Duke University
------------------------------
Date: 10 Nov 82 20:59:30-PST (Wed)
From: decvax!ittvax!sii!drd at Ucb-C70
Subject: Re: 8 bit ASCII versus 16 bit supercode
Is there any basis for thinking that 64K characters would be enough?
------------------------------
End of WorkS Digest
*******************
-------
∂25-Nov-82 2109 AVB WORKS Digest V2 #88
∂23-Nov-82 0603 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #88
Date: 22 Nov 1982 0028-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #88
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Monday, 22 November 1982 Volume 2 : Issue 88
Today's Topics:
Notes - Communications Breakthrough,
Hardware - The Corvus Concept,
Programming - Extending the ASCII character set (6 msgs)
----------------------------------------------------------------------
Mail-from: ARPANET site PARC-MAXC rcvd at 10-Nov-82 2233-EST
Date: 10-Nov-82 19:36:21 PST (Wednesday)
From: Hamilton.es at PARC-MAXC
Subject: Communications Breakthrough
To: Human-nets @ Rutgers
Mail-from: Arpanet host CMU-10A rcvd at 10-NOV-82 0826-PST
Date: 10 November 1982 1126-EST (Wednesday)
From: James.Morris at CMU-10A
To: csl↑ at PARC-MAXC, isl↑ at PARC-MAXC, junk↑ at PARC-MAXC
Subject: Communications Breakthrough
Message-Id: <10Nov82 112614 JM90@CMU-10A>
Because you can't see the person who is sending you electronic
mail you are sometimes uncertain whether they are serious or
joking. Recently, Scott Fahlman at CMU devised a scheme for
annotating one's messages to overcome this problem. If you turn
your head sideways to look at the three characters :-) they look
sort of like a smiling face. Thus, if someone sends you a
message that says "Have you stopped beating your wife?:-)" you
know they are joking. If they say "I need to talk to you :-(",
be prepared for trouble.
Since Scott's original proposal, many further symbols have bee
proposed here:
(:-) for messages dealing with bicycle helmets
@= for messages dealing with nuclear war
<:-) for dumb questions
oo for somebody's head-lights are on messages
o>-<|= for messages of interest to women
~= a candle, to annotate flaming messages
So you see, bit-map displays are really quite unnecessary :->
------------------------------
Date: 21 November 1982 05:51-EST
From: "James Lewis Bean, Jr." <BEAN at MIT-MC>
Subject: The Corvus Concept
Does anyone have anything good to say about one of these machines?
I went to see one at a "Computer Store" and seemed to know more
about the machine than the sales people did, oh well. It looks
great! The price is great. The problem seems to be there is no
documentation on the software that exists. And there doesn't appear
to be much software for it.
For those of you who do not know what a corvus concept is...
The concept is an under $5K workstation.
68000 based with 256K standard.
15 inch 35mhz video
Bit mapped 720x560 display.
120x56 in landscape mode
90x72 in portrait mode
Two serial ports.
One omninet interface (1mbps serial rs422)
Detached Keyboard with lots of extra keys.
Anyone know where I can get unix for it?
lewis
bean at mit-mc
------------------------------
Date: 13 Nov 1982 09:12:38-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: SUPER ASCII
Flame on!
The folks who are grossly misspeaking about what ASCII is and is not
should look at the full specification. A while back there was a
series of articles in IEEE Computer written by one of the prime
movers in the ASCII effort talking about just such things. All the
(serious?) extension people have mentioned [mathematics, other
(non-English!!) languages, some graphics symbology] are included
in the ISO code structure, of which 7-bit ASCII is only a TINY
subset. There are defined codes for escaping to a great many
alphabets, and if you layer NAPLS on top (which does so quite
cleanly as it was designed with full knowledge of the ISO code
structure) you can even define the glyphs represented by new codes.
There are in fact TWO issues here - do you seriously want to define
a discrete character code for every character in every font in every
point size?? If so, 32-bit will barely suffice. The ISO code
structure contains provides ways for "escape" mechanisms for getting
to other protocols. One of these other protocols would be a
presentation protocol like NAPLS or something similar which will
specify glyph representation, font, pointsize, etc. The base
alphabet would only represent the character which is presented in
the form "current" in the presentation protocol. This means there
is a tight coupling between the layers when handling real data, but
a cross-product structure is surely more desirable than a flat
enumeration of "all symbols needed for man's knowledge!" (excuse
possible mis-quote.)
A good friend of mine has a quote which I dearly love:
"Creativity is no substitute for knowing what you're doing."
Flame off!
-Mike
------------------------------
Date: 13 November 1982 15:22-EST
From: "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC>
Subject: Character codes
ISO standard 222 (?) specifies a standard method for extending the 8
bit Teletex code by swapping in an alternate 128 character set.
Already 45 different alternate character sets have been registered
with the ISO including Greek, Russian, Arabic, etc. Efforts are now
underway within the CCITT Study Group VIII to define a new extension
technique which would allow for two bytes to specify a single
character -- i.e. a 16-bit code. The primary reason for going to 16
bits is to encode Kanji (Japanese and Chinese) characters.
Marvin Sirbu
------------------------------
Date: 15 Nov 1982 at 1100-PST
Subject: Re: Supercodes
From: chesley.tsca at SRI-Unix
One very simple way to allow extended codes is to define the
8th bit as a "select character set" bit. If on, the lower 7 bits
select a new character set (a sort of super shift-out). The default
could be ASCII, thus keeping compatibility with existing standards.
A couple of additional features allow even more expansion:
(1) Reserve one of the character set numbers to mean "select
second level character set"; i.e., next byte has character set
number. This can be repeated indefinitely to allow an arbitrary
number of character sets.
(2) Divide the character sets into groups, each with a
different number of bits per character: 8, 16, 24, 32. This allows
arbitrary size character sets.
Bucky bits can be handled by having "ASCII", "Meta-ASCII",
etc. And it's quite simple at the keyboard interface to translate
top bit set (i.e., meta) into "change-set,character,change-set".
So this could be added to an existing system with very
little work, and people can go off and start defining new character
sets right away...
--Harry...
------------------------------
Date: 16 Nov 82 8:35:40-PST (Tue)
To: works at Rutgers
From: hplabs!hao!csu-cs!bentson at Ucb-C70
Subject: Re: Supercodes
See ANSI standard X3.41 "...Code Extension Techniques..." for a
general structure upon which to hang an extensible character set.
There's also a proposed ISO/DP 6937 "Coded Character Sets for Text
Communication".
I would like to see more of the "technocrats" in the standards
committees; the last meeting I attended, there was a strong push
towards restricting a "page image format" character set to a great
deal LESS than the 128 char ASCII set because of the number of dumb
terminals in existence! Fortunately it was finally recognized that
the standard wouldn't be published for years so we would be able to
(and were obliged to) look ahead to that time.
If you have a real interest in all this, contact:
Thomas N. Hastings
Chairman, X3L2
Character Sets and Coding
Digital Equipment Corp
Mailstop MK1-2/J05
Continental Boulevard
Merrimack, N.H. 03054
603 884-6767
He should be able to point you to the proper working group. I have
been out of the "establishment of standards" activity for some time
now, so I hope the above address is still correct.
Randy Bentson
Colo State U - Comp Sci
{ucbvax!hplabs, menlo70!hao}!csu-cs!bentson
------------------------------
Date: 17 Nov 1982 0657-EST
From: Marc Shapiro <Shapiro at MIT-XX>
A recent message to WorkS discussed the CCITT/Teletex extensions to
the Ascii alphabet, correctly noting that it allows all diareses
combinations (i.e. accents and pronunciation marks on letters) plus
a lot of new symbols (arrows, greek letters, math symbols), colors,
underlining, etc.
- the standard does *not* require a code per diaresis combination.
Rather, there is a code for the letter + a code for the accent
mark. The same is of course true for underlined text, colored text,
etc.
- the message stated that the standard needs 8bits/char., and hence
is unsuitable for systems where the 8th bit is reserved for parity
or doesn't exist (DEC equipment). Not quite true. The standard
provides both for 8-bit and 7-bit encoding, the latter with longer
escape sequences.
The standard is compatible with Ascii. Reference:
CCITT yellow book
Volume VII - Fascicule VII.2
Telegraph and Telematic Services Terminal Equipment
Recommendations of the Sand T series.
or:
Presentation Level Protocol
Videotex Standard
Bell System, May 1981
PS The standard also defines mosaic graphics "a la" bit-map.
------------------------------
Date: 18 Nov 1982 1603-PST
From: Pierre MacKay <MACKAY at WASHINGTON>
Subject: Range of ASCII, alias ISO 646-1973
To: LES at SU-AI
cc: Furuta at WASHINGTON, Binding at WASHINGTON,
Your 8 bit ASCII message of 10 Nov 1982, found its way to me by a
somewhat roundabout route, since I am not on the WorkS list, and,
given the size of my mail file as it is, I am hesitant to get there.
You underestimate the range of even 7-bit ASCII. In conjunction
with the appropriate escape sequences from ISO 2022-1973, alias (for
all practical purposes) ANSI X3.41-1974, the good old 7-bit table
speaks several languages. For instance:
Greek---ISO 5428-1980 (I haven't actually seen this yet.
Japanese---National standard C6220-1969 (katakana only, of
course, and this, in the form JISCII is a true 8-bit code,
with ASCII residing in columns 0..7 and katakana in columns
10..13.
Russian---GOST 13052-67, a dreadful aberration set up for
the use of SO and SI coding, with the Cyrillic alphabet
scrambled to match the visually similar Latin letters. Why
even a Commissar would want to do that to his own language
is beyond me, but it is AUTHORITATIVE, under the
circumstances.
The Arabic case is chaos. There is no reason why a good, efficient
Arabic script coding table cannot be included in a 7-bit range. I
am working with one now, but it is rather my own invention. It
resembles some of the work done by ISO TC-46 and similar work done
at the Library of Congress. There was a fine suggestion put forward
at Riyadh, Saudi Arabia, about two and a half years ago, but it came
to nothing, and a dreadful Moroccan notion, cobbled up out of a set
of linotype matrices now has a certain currency, in that it has been
registered, whatever that means, as Number 59, dated June 1, 1982
with ISO. It includes 4 ISO 2022 escape sequences to identify G0,
G1, G2, and G3 graphic sets, but does not say what is to be done
with all these alternatives. ECMA has plunged into the same waters
with an entirely different proposal, which may even be worse. They
all seem to assume that all Arabic ligature forms must be shown in
the coding table, rather as if Don Knuth's TeX were to require the
elimination of the open and close brace character positions so that
you could code the double-f ligatures directly. The implications of
microprocessor technology have not yet got through.
Urdu, Pashto and Sindhi would probably overload a 7-bit table, since
you are really dealing with two incompatible alphabets mashed into
one in those cases. Malay and Chinese-Turkish (as seen on the lower
right corner of PRC banknotes) will fit. Persian, of course will
fit easily, as will Ottoman Turkish, a language for which I have a
bizarre atavistic affection. Western Europe and Hungary have
national versions of ISO 646 to account for heavily used
diacriticals. I don't know about Czech, which is a bit overloaded.
Modern Turkish is a nice problem too.
I believe the Sanskrit-derived Indian languages would fit, and the
Tamil family would certainly fit in a 7-bit table. Chinese, and
Japanese Kanji would not. The Japanese use a manageable subset of
Chinese ideographs, and have already established a multi-bit code.
One proposal for Chinese uses the 94 cells available in the Graphic
area of ISO 646 in a three level code. There are 94 books of 94
pages each of 94 characters each, or 94 to the third power possible
characters. That should suffice even for Chinese.
--Pierre MacKay
------------------------------
Date: 18 Nov 82 15:30:53-PST (Thu)
From: hplabs!intelqa!omsvax!bc at Ucb-C70
Subject: Re: Supercodes
The address given for Tom Hastings of the ANSI X3L2 character codes
committee was out of date. The correct address is:
Thomas N. Hastings
Chairman, X3L2
Character Sets and Codings
Digital Equipment Corp.
Mailstop ML1-2/H26
146 Main St.
Maynard, Mass. 01754
As member of the standards community (X3H3, computer graphics, and
liaison to X2L2), I implore anyone planning on extending the ASCII
(or any other) character set to contact Tom and get information from
him. There are far too many partly or wholly incompatible
"standards" in the world now, more are not needed. Besides which,
someone out there may have already solved your problem, and saved
you a lot of work. I think it was Robert Heinlein who said that a
good engineer is adept at recognizing good work, and using it, with
the serial numbers filed off as appropriate.
Bruce Cohen
...{pur-ee,hplabs}!intelqa!omsvax!bc
------------------------------
End of WorkS Digest
*******************
-------
∂01-Dec-82 2224 AVB WORKS Digest V2 #89
∂29-Nov-82 1926 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #89
Date: 27 Nov 1982 1235-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #89
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Saturday, 27 November 1982 Volume 2 : Issue 89
Today's Topics:
Queries - 68K Virtual Memory Systems,
Hardware - Terminals & Trackballs & The Corvus Concept,
Education - Utah and WICATs
----------------------------------------------------------------------
Date: Mon, 22 Nov 82 08:00:02 EST
From: barkley at NBS-SDC
Subject: 68k virtual memory systems
Does anyone have a SUN workstation from SUN microsystems? Is
there any other 68k system which will run Berkeley Unix? Any
information would be appreciated.
thanks
------------------------------
Date: 22 Nov 1982 1809-EST
From: WITTMAN at RU-GREEN at RUTGERS
Subject: Re: PR1ME computer
To: DREIFU at WHARTON-10
Henry,
Thanks for your comments. All PR1MEs terminals are "expensive"
compared to independent suppliers and they pretty readily admitted
that. I think the major problem is not the expense of the terminal
but that the OA systems seemed not to partake of PR1MEs "software
first" philosophy. There were many incarnations with many problems,
and they were external products to begin with. PR1ME builds systems
tools, NOT applications packages.
I'm unfamiliar with the capability of the 2250 (Rabbit) but know it
is more than a Workstation (and less that the traditional
time-sharing PR1ME) so I can't make many comments at this juncture.
You'll probably see it before I do; what do YOU think of it.
Regards,
Barry
------------------------------
Date: 22 Nov 82 14:33:00-PST (Mon)
From: decvax!utzoo!utcsrgv!ralph at Ucb-C70
Subject: Trackball followup
Some time ago I put a request out on this news group (I think) for
information on sources of inexpensive track balls. There were
several good suggestions, but I did seen any sources that got the
price down as low as I would think possible.
Subsequently we have found several CHEAP (!) trackballs, but some
were not real trackballs (it didn't roll). The following supplier
makes fairly good trackballs that are inexpensive. We have been
quoted just under $200 (Cdn) in Canada (i.e., after duty, currency
conversion, etc.). In the U.S. I would think <$100 in quantity one
should be expected. (In case you are wondering what "fairly good"
means, it can be translated into "good enough for us". We have
ordered one).
Disc Instruments
102 E. Baker Street
Costa Mesa CA 92626
(714)-979-5300
------------------------------
Date: 23 Nov 82 14:49:57-PST (Tue)
From: harpo!ihnp4!ixn5c!inuxc!pur-ee!CSvax.Pucc-H.Physics.hal at Ucb-C70
Subject: Corvus Concept review
I posted this review of the Corvus Concept about a month ago but
since there have been a couple of requests for information since
then and I can't get mail through to the ARPA net, here it is again.
A couple of new items are included (in particular, the predefined
nonstandard Pascal type "string").
I've had my Corvus Concept since August, so here are a few
comments. Here's a list of what's in my system:
Corvus Concept workstation (256Kb memory)
Corvus 5.7Mb hard disk
Corvus 8" disk drive (SSSD)
Okidata ML84 printer
First, the bad news:
The Corvus advertising says that the 8" diskette is 1.0Mb
(formatted). It isn't. It stores 256Kb. When I talked to the
Corvus marketing people, it was the first they had heard about it!
So much for communication between engineering and marketing. I
settled with Corvus when they agreed to supply a Mirror interface so
I can backup the hard disk on my video cassette recorder.
The 8" drive is capable of double density operation and Corvus
says they will have a DD driver for it in the future.
For the rest of this review, I'll divide things up into Hardware,
Software, and Documentation. I will make a few comments on the
printer at the end of this review.
Hardware:
The workstation uses a Motorola MC68000 microprocessor at 8MHz.
It comes with either 256Kb or 512Kb of memory, clock/calendar
with battery backup, 2 RS-232C ports, an Omninet interface
(RS-422 1Megabit/ sec.), 4 interface slots (Apple compatible), a
15" 35MHz display monitor.
Sockets are already on board for the second 256Kb of memory.
The chips used are MC6665L20 64K DRAMs.
The battery backup for the Clock/Calendar does not work
properly. This is true not only of my unit but also for the
unit purchased by a friend at the same time. On my unit, the
clock appears to run at about half speed when the power is
turned off. On the other unit, the date jumps about two days
when the power is turned off.
There are two serial ports on the Corvus but only one of them
can be used at a time. Bummer!
The display screen may be used in either a horizontal or
vertical orientation. Horizontally this yields 56 lines x 120
chars/line. Vertically: 72 lines x 90 chars/line.
Display updating uses DMA but with a 50Kb display that means a
lot of bus cycles are being stolen from the processor. Since
this is a workstation and not a multiuser system, however, this
isn't too bad and I haven't noticed any objectionable delays in
running programs.
Software:
The operating system claims to run up to ten processes. It does
not do time multiplexing however. What it does is let you do is
nest program executions ten deep. Unfortunately, the suspended
programs are not swapped out to disk but remain in memory. So,
the deeper you nest the less memory space available.
IO redirection works as it does in the UNIX shell.
There is only one level of directories.
Device drivers can be loaded while the system is running.
Pipes are implemented using temporary files written to a
directory called /PIPES.
A very nice character set editor is provided for defining
character fonts. New font files can be loaded while the system
is running.
The Pascal compiler supports most of the UCSD extensions. In
particular, UNIT IO and separate compilation (using units).
Unfortunately, the compiler enforces the strict rule of all
const definitions first, then all type definitions, then all var
declarations, etc. This means the use of include files loses
most of its benefits.
The terminal driver supports window management and graphics.
Pascal units are provided to support these.
The predefined type "string" is not only a predefined type but a
reserved keyword as well!! This means you cannot pass variables
of type "string" as procedure parameters since the syntax scan
of the compiler expects a parameter type to be an identifier not
a keyword. I worked around this, by defining:
type pstring = string[80];
Documentation:
The documentation provided is pretty good as far as it goes.
However, it took some requests to Corvus to get to get system
documentation: description of operating system, LINKER and
LIBRARY manuals, ASM68K manual, description of Pascal Units for
accessing system functions.
Some of the documents are missing chapters. For example, the
EDWORD (EDitor/WORDprocessor) manual contains seven chapters but
has references to chapters up to ten!
No information on memory locations of hardware interfaces, etc.,
etc., etc.
Okidata Printer:
The Okidata ML84 printer is great! Some features:
Fast. 200cps (bidirectional, logic-seeking)
Near Letter Quality mode. (unidirectional, two passes per line).
This not only overlaps the dots but puts the little sariphs on
the characters.
Underlining, emphasized, super/sub-scripts, graphics.
3 print densities and double width.
Down loadable character fonts. (Doesn't work!)
Electronic VFU and horizontal tabs. (No way to set or recognize
Bottom-of-Form!)
SUMMARY
Overall, I am quite pleased with the Concept hardware and rather
disappointed with the software. Function keys and menus are fine
when you are learning a new system but a pain once you know what you
are doing and have nest down thru several windows to get the
functions you want to execute. I am presently working on
implementing Software Tools using their Pascal compiler.
These are a few points that come to mind. If you have any
questions about the system, send me some mail and I will be glad to
answer them.
Hal Chambers
pur-ee!pur-phy!hal
pur-ee!Physics:hal
------------------------------
Date: 26 Nov 1982 2305-MST
From: JW-Peterson at UTAH-20 (John W. Peterson)
Subject: Computers for school
Those of you who reacted to CMU's plans to require students to
purchase computers may be interested in this one:
The "World Institute for Computer Assisted Teaching" (better known
to WORKS readers as WICAT) currently has a proposal before the Utah
state board of Education asking the state of Utah invest $15 million
in Wicat, for them to develop a standard CAI system to be used in
most/all of Utah's public schools. The state would be the sole
owner of the program and receive the royalties (6% of the sales
commissions) on the software. According to the proposal "the
royalties would continue [at >$3 meg a year] for a 15-year period
... meaning the state fund would be fully reimbursed and the state
would receive $30 million for the hardware acquisition."
The courseware would include subjects such as "English, Writing,
Calculus, Biology, History and Foreign Languages (with Audio)."
These programs are to run on a "System 300 (the Hydra System)" that
has 30 terminals "with audio, graphics and animation" and a CPU with
an 80 meg disk. Price (w/ discount) is given at $67,000.
WICAT's proposal also states they would be willing to "translate"
the programs to other hardware vendors at the states option (the
state would pay extra for this service).
While the proposal does list some of the reservations about such a
move (such as WICAT's current marketing capability, and having one
company as a sole source), Utah's executive directory of
administrative services claims "there are strong, positive feelings
about WICAT's offer and it's potential role in assisting the State
of Utah to develop and utilize CAI materials."
The proposal is set to go before the '83 session of the Utah state
legislature. The source for the above quotes is a Utah State Office
of Education newsletter.
-jw peterson
------------------------------
End of WorkS Digest
*******************
-------
∂17-Dec-82 2139 AVB WORKS Digest V2 #90
∂15-Dec-82 1336 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #90
Date: 12 Dec 1982 1503-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #90
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 27 November 1982 Volume 2 : Issue 90
Today's Topics:
Queries - Apollo on Ethernet &
Data Base Management Systems for Workstations &
Hardware Suggestion Request,
Hardware - Inexpensive Trackballs &
Xerox Star Workstation & Corvus Concept,
Call for Papers - Computer Architecture for Non-Numeric Processing
----------------------------------------------------------------------
Date: 10 Dec 1982 2128-PST
Subject: Apollo on Ethernet?
From: Dick Gillmann <GILLMANN@USC-ISIB>
Has anyone tried putting an Apollo node on a 10 MHz Ethernet? I
know there is a Multibus card set that implements the Ethernet
interface (from Intel). We are considering connecting our Apollo
ringnet to an Ethernet via a gateway node, mainly for file transfer.
/Dick
------------------------------
Date: 10 Dec 1982 at 0858-CST
From: Keith Pyle <pyle@UTEXAS-11>
Subject: Data Base Management Systems for WorkS ?
Does anyone have recommendations for data base management systems
for use on 68000 based workstations running UNIX (e.g., the Sun)?
We need a system that will handle 6000 - 8000 records with a total
size of 3 - 6 Mcharacters, have access through procedural language
programs, and not place an inordinate load on the workstation's
resources. We are presently using a hierarchical DMS (System 2000 on
a Cyber mainframe) but a relational model system would also be
acceptable.
Thanks.
Keith Pyle
(pyle@utexas-11)
------------------------------
Date: 5 Dec 1982 at 1737-CST
From: Keith Pyle <pyle@UTEXAS-11>
Subject: Introductory Info Request
My research group is conducting a clinical data collection and
analysis project for the National Institutes of Health. We have
been using the UTexas Cyber system and the System 2000 data base
management system but for several reasons must move to an off-campus
system. We would like to buy a system with 250K - 1M of main
memory, 15 - 20M of hard disk storage (expandable to 30 - 40M), and
the ability to handle 2 - 4 users. We deal with relatively large
amounts of data, so the system should be relatively fast. We will
be limited to spending about $30,000 (exclusive of terminals,
printer, etc.).
My question: Where does a reasonably competent user-type with
minimal knowledge of current hardware begin when faced with this
sort of problem? I'm justifiably cautious of sales people and their
claims (the recent review on WORKS of the Corvus Concept backs this
up). I have talked with some of the UT Computation Center staff
with some results but would like comments from a larger group. If
anyone has experience with a system(s) that might fit our needs, I
would appreciate your comments.
W. Keith Pyle
Director
CAPD Data Coordinating Center
------------------------------
Date: 29 Nov 1982 0127-EST
From: Ron <FISCHER at RUTGERS>
Subject: Inexpensive trackballs
To: decvax!utzoo!utcsrgv!ralph at UCB-C70
I am not sure what your interface requirements are, however there is
a company making trackballs for home computers like the Apple/Atari
and it sells for about $40. That company is:
WICO Consumer Division
Niles, ILL. 60648
800-323-4014 (Ill. residents call 312-647-7500)
The ad copy I found on p. 249 in Jan. '83 issue of Creative
Computing explains that this is: "Made by the world's largest
manufacturer of controls for the commercial arcades."
These trackballs probably only send out pulses, i.e. they don't keep
an interrogatble cursor position inside them (as some mice do).
(ron)
------------------------------
Date: 3 Dec 82 13:33:30-EST (Fri)
From: Gene Spafford <spaf.gatech@UDel-Relay>
Subject: Xerox Star Workstations
Not too long ago, the folks at Xerox very kindly donated two small
Star systems to Tech. One of them wound up in our research lab
(School of Information and Computer Science). We've been pretty
impressed by the graphics and the print quality. The software also
indicates a lot of careful thought. However, I'm curious as to a
few points, and would appreciate comments on the following:
The Star is painfully slow to the point of positive annoyance.
Some of us have grown to hate that little hourglass cursor.
Xerox is (said to be) currently working to speed the little
bugger up, but an 8085A can only do so much. We have some users
who have stopped using the Star for anything not requiring
graphics since virtually anything else we have is faster.
However, these people are experienced computer users. I'm
curious about users who haven't used other systems before --
what do they think about the speed? Any ideas?
Anybody out there with Parkinson's disease or arthritis? I'm
curious as to how well you could use that mouse and cursor to
select small characters on the screen. How about people with
poor vision? One of our secretaries who is using the system has
to type everything in in a larger font than what she needs to
print because she cannot see the small characters on the screen;
somebody has to go through later and increase the type size and
reformat the pages accordingly. Anybody else out there have
less than perfect co-ordination and vision?
Does anyone out there have difficulty knowing when to use "copy"
and when to use "move"? We've had some interesting problems
because there is no such thing as "read-only" and someone
"moved" when they should have "copied." Also, some things copy
but don't move, and some things move but don't copy.
Anybody found why the system keeps crashing when you do complex
and wonderful things with graphics frames?
I guess the first two points might be asked of any workstation. We
would probably have use for another 3 or 4 workstations, despite
their current shortcomings. I guess it is a question of what kinds
of things are users willing to put up with in exchange for perceived
advantages.
Comments?
------------------------------
Date: 6 Dec 82 9:18:55-PST (Mon)
From: harpo!ihnp4!ixn5c!inuxc!pur-ee!CSvax.Pucc-H.Physics.hal at Ucb-C70
Subject: Corvus Concept update
I would like to update my comments about the battery backup on
my CC's clock/calendar not working. I got it to work this Saturday.
Boy, is this dumb!! Saturday morning it occurred to me that the
Nicad pack on a calculator takes 12-14 hours to charge fully and
that I had never had the Concept on for that long. So, I left the
workstation on for 24 hours and the date and time remains correct
when the power is off (over night, at least).
My only consolation is that neither the dealer nor the engineers
at Corvus thought of this first.
Hal Chambers
pur-ee!pur-phy!hal
------------------------------
Date: 28 Nov 1982 0620-MST
From: Lee Hollaar <Hollaar at UTAH-20>
Subject: Seventh Workshop on Computer Architecture for Non-Numeric Processing
To: arpanet-bboards at MIT-ML
cc: info-graphics at UTEXAS-20, info-vlsi at SANDIA, local-nets at MIT-MC,
CALL FOR PAPERS AND WORKSHOP INFORMATION
SEVENTH WORKSHOP ON COMPUTER ARCHITECTURE FOR
NON-NUMERIC PROCESSING
Snowbird, Utah, March 6-9, 1983
Sponsored by: ACM SIGARCH, SIGIR, and SIGMOD
Computer Science Department, University of Utah
As the costs to design, implement, and maintain a large scale system
change from a situation where hardware costs predominate to one where
software costs do, it is reasonable to explore computer architectures
which differ from the classic numerically-oriented machine. Front end
processors, performing protocol translations, are now common in data
communications systems, and a variety of backend processors for
database and information retrieval applications are available or
currently under development. New architectures are being developed
for robotics, image processing, searching and sorting, artificial
intelligence, highly available systems, workstations, and text
processing.
In the past, this workshop has been a primary avenue for those engaged
in research and development of a variety of specialized non-numeric
systems to discuss their current activities and future directions. It
has proved invaluable to students conducting research in computer
architecture, allowing them to present preliminary results of their
work, and to receive comments and suggestions from others in the
field.
Workshop Location and Registration Information
The workshop will be held at the Snowbird Ski and Summer Resort,
located in Little Cottonwood Canyon near Salt Lake City, Utah.
Transportation is available from the Salt Lake airport. The
registration fee of $300 includes double occupancy rooms for three
nights, breakfast, and the workshop banquet. The remaining meals and
any skiing expenses are the responsibility of the participants. Rooms
will be available for check-in at 3:00 PM Sunday, March 6, and the
first workshop session will be held at 7:30 that evening.
Because of severely limited space, attendance at the workshop will be
by preregistration only. Rooms have only been reserved for the
workshop participants. If you wish to bring along family members, you
should contact the Workshop Chairman as soon as possible. For those
wishing to arrive on Saturday, rather than Sunday, a limited number of
rooms are available for an additional $45.
To register for the workshop, write the Workshop General Chairman by
January 1, 1983, indicating your name and affiliation, mailing address
and telephone number, your interest and background in computer
architecture for non-numeric processing, and whether you have
submitted a paper. Include the appropriate registration fee ($300
normally, $345 for early arrival). Acceptances will be sent out on
January 15, 1983, and registration checks for those we are unable to
accommodate will be returned. Priority on registration will be given
to those submitting a paper for presentation. We urge you to submit
your request for registration early.
Instructions for Authors
We invite papers on current or proposed work in all areas of
specialized computer architecture for non-numeric applications, such
as: image processing data communications, information management and
retrieval, workstations, highly available systems, robotics,
artificial intelligence, searching and sorting, and text processing.
Presentations will last from 30 to 45 minutes, with half the time
devoted to the presentation of the paper and half to discussion. In
addition, a final session, to be organized at the workshop, will
consist of a number of short presentations for those wishing to
present or discuss a concept, but unable to prepare a full length
paper.
The deadline for submission was November 15, 1982. Since the program
will be determined by the end of December, if you wish to present a
paper you should contact the Program Chairman immediately to discuss
your submission. It is anticipated that the workshop proceedings will
be published as a special joint issue of the newsletters of the
sponsoring SIGs.
Workshop General Chairman: Workshop Program Chairman:
Lee A. Hollaar Roger L. Haskin
Department of Computer Science IBM Research Laboratories, K52/282
University of Utah 5600 Cottle Road
Salt Lake City UT 84112 San Jose CA 95193
(801) 581-3203 (408) 256-6353
Hollaar@Utah-20 Haskin.ibm-sj@Udel-Relay
------------------------------
End of WorkS Digest
*******************
-------
∂20-Dec-82 0048 AVB WORKS Digest V2 #91
∂19-Dec-82 2220 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #91
Date: 19 Dec 1982 2141-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #91
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Sunday, 19 December 1982 Volume 2 : Issue 91
Today's Topics:
Administrivia
Review - HP9000 SuperDesktop System
----------------------------------------------------------------------
Date: 19 Dec 1982 2132-EST
From: Mel <Pleasant at RUTGERS>
Subject: Administrivia
Hi folks,
Due to the length of the review of the HP9000 SuperDesktop
System, it will be the only message contained in this digest. I'd
like to thank Jeff Stone for taking out the time to give us such a
detailed report.
-Mel
------------------------------
Date: 9 Dec 1982 2129-PST
From: Jeffrey at OFFICE
Subject: HP9000
HP's SuperDesktop System, the HP9000
Today in Palo Alto, Hewlett Packard presented a seminar highlighting
Computer Aided Engineering applications of its small computer
products. After an hour's worth of rather interesting
presentations, the crowd was turned loose to examine about twenty HP
desktop workstations upon which a number of third party software
applications were being demonstrated.
I headed directly for the HP9000 which was half hidden by a large
projection screen that had been used during the presentations.
The HP9000 is obviously HP's new pride and joy. One of the
presentations had been a glossy video taped presentation which
recounted some of the history of the 9000. HP's primary
representative, Mike Radisich of HP Ft. Collins CO (the home of the
9000), introduced the video tape as HP's answer to DG's "The Soul of
a Machine". I didn't find the tape to be very interesting even
though it did contain a number of interviews with HP people who had
participated in the development of the 9000. The machine itself is
something else.
The 9000 is described by HP as a real technological breakthrough.
This claim stems from the super density VLSI chips which are used to
implement the processors and memory of the system. The system's
processor is implemented by over 450,000 devices (transistor
equivalents) which are packed on a square chip whose side measures
about a quarter of an inch. The 9000's I/O processor is implemented
on a similar chip ws. For comparison, remember that the Motorola
68000 contains about 68000 devices.
HP is taking orders for the system and is currently promising
delivery in twelve weeks. Thus it appears that HP is able to
produce these dense chips in production quantities. According to
the local (Palo Alto) HP sales people, orders for the 9000 have been
moving very well since its announcement several weeks ago.
-- System Overview
The HP9000 is a desktop computer which, according to HP, has the
power of a mainframe. The system is implemented as one or more
processors, one or more I/O processors, and up to 2.5MB of memory -
all connected by a high speed bus. All of the subsystems are 32-bit
oriented; this is the first true 32-bit micro.
The configuration I saw contained one processor board, one I/O
processor board, 1MB of memory, a 10MB winchester, a 256KB floppy
disk, a color display with light pen, a full keyboard, and a dot
matrix printer. All of these components were integrated into a
single housing.
The keyboard (not detachable) sits in front of a larger but yet low
rectangle box which contains the two disk units, the electronics
card cage, and the printer. The display was perched on top of this
box behind and above the printer. The footprint of the system must
be something like 18 inches (width) by 18 inches (depth) - its not a
particularly small desktop. Inside the main box, the printer and
disks take up most of the space. The card cage holding the system's
processors and memory is a small unit perhaps 8 inches by 5 inches
by 5 inches. It looks as if this unit can be easily removed. The
boards themselves are each are about 7 inches by 4.5 inches.
-- Processors
Each system processor runs at 18MHz and includes logic to implement
32-bit and 64-bit floating point operations. I copied some figures
from an HP data sheet:
32-bit 64-bit
------------ -------------
f.p. add 4.66 6.00
f.p. multiply 5.11 10.40
f.p. divide 6.44 15.95
(times in microseconds for floating point operations)
One of the faster instructions is the LDA (Load A) which was rated
at .56 microseconds.
The processor chip includes logic to help detect processor failures.
This came in handy when HP debugged the chip design. HP claims that
this logic will also help diagnose failures in the field.
Interestingly, the HP processor chips are not mounted in ceramic or
plastic casings to be attached to boards. Rather, the little (1/4")
chips themselves are mounted directly on the teflon coated copper
boards. Using this technique, the 9000 boards pack a great deal of
power into a small area. For example, the memory boards support
256KB of memory in an area of approximately 30 square inches. In
that area are mounted, 16 memory chips as well as some other
interface and integrity support chips. The copper substratum of the
boards is required to help dissipate heat.
The I/O processors each implement eight independent DMA channels.
HP's data sheet suggests that an I/O processor can transfer data at
up to 1MB per second.
-- Memory
The HP-9000 can accommodate up to 2.5MB of RAM in a single processor
system. Each additional processor board decreases the maximum
memory by 256KB since less slots are available for memory.
Memory boards hold 256KB of RAM configured from 128K RAM chips. I
was told that the memory had a cycle time of 110 nanoseconds and
that the memory was multi-ported. Apparently, in a multi-processor
system, different processors use different ports to increase the
overall memory bandwidth of the configuration. Even though the
memory is multi-ported, all memory accesses do travel over the
system bus.
I was told that the processors did map memory and that virtual
memory would be supported under Unix. This is one area, however,
where the otherwise confident HP representatives did not seem sure
of themselves. One silicon valley hi-tech watcher has a possible
explanation. Apparently, HP's processor architecture has some minor
flaws in the memory mapping area. In particular, virtual memory
supporting process stack frames may have to be tied to physical
memory and cannot be paged. Even if this is the case, it probably
will not seriously impact performance in a system that is primarily
meant to serve a single user.
The 9000's memory integrity features are interesting. The system
continually runs high speed checks utilizing Hamming codes to detect
temporary degradations caused by alpha particles. If such a
temporary malfunction is found, then the system remembers the erring
memory cell in an associative location which is used to stand in for
the bad cell. If the associative store becomes full, erring cells
are "forgotten" on a FIFO basis. The explanation given by HP was
that alpha particle problems are transient (i.e., do not cause
permanent hardware damage). The associative memory serves as enough
of a buffer in time to allow failing memory cells to regain there
proper operational characteristics (i.e., to heal themselves).
The 9000 also includes power up memory diagnostics that can detect
malfunctioning memory in blocks of 16k. If any bad blocks are
found, the system automatically configures itself around these and
continues on its way. A startup message notifies anyone watching,
as to how much memory is actually available for use and how much is
not operational. Startup is said to take about 15 seconds during
which time memory and presumably other tests are conducted.
-- Displays
The configuration I saw included HP's fancy color monitor. The
diagonal measurement of the monitor is about twelve inches. This
monitor is integrated into the desktop enclosure and is a raster
scan device displaying 455 x 560 pixels. The output for each pixel
is specified by a 16-bit quantity. Twelve bits select a color from
4096 possibilities. The remaining four bits control intensity. The
display has its own display memory which is organized into three
planes corresponding to R(ed), G(reen), and B(lue). Any of the
planes may be enable/disabled for display under software control.
The bottom of the display frame is segmented into eight buttons
which serve as function keys. This feature is very well done
(mechanically) and is very well utilized in demonstration software.
A black and white display may be substituted for the color display
to effect considerable savings (about $10,000). Alternatively, HP
has a separate color monitor available (separate enclosure) with
double the resolution of the integrated color monitor.
Up to 15 additional consoles may be connected to support users.
These will all consist of ASCII terminals connected through RS-232
ports. Only the first user interface (i.e., the built-in monitor
and keyboard) will have the 9000's special graphics features.
-- Matrix Printer
A black and white dot matrix printer is (optionally) included in the
desktop enclosure. HP is working on color ink jet printers but
these will not be available for some time. I wonder why they didn't
include a color dot matrix printer (several of these were displayed
at Comdex with prices well under $1000).
The resolution of the B/W printer is near that of the display and
the demonstration software I saw could copy anything showing on the
display to the printer.
I don't have any hard figures on the speed of the printer but it was
able to print an image of the display in a few seconds.
-- Software
The demonstration system was called "HP Rocky Mountain Basic". Its
a single user Basic-oriented system.
HP is porting Unix III to the 9000. They expect the port to be
complete in a few weeks and are planning to release Unix as a
product in the summer. Fortran and Pascal will come with Unix.
HP's graphics package from the HP1000 is reportedly integrated into
the Unix system. ISSCO, a leading business graphics software
vendor, will receive a HP9000 in a few weeks. They are going to
bring DISSPLA and TELL-A-GRAPH up using the 9000 as host and display
device.
HP said that it will also bring some important applications for the
9000 including IC layout, SPICE, and Nastran.
As soon as Unix is running, HP will try to ascertain how many users
the system can support. The current estimate is 10-16. Adding
extra processor boards should improve multi-user performance since
HP says that the system will "automatically" share the processors
among the users. Since the memory has provision for multiple
processors, this may actually work out quite well. Extra processors
do not back each other up to provide graceful degradation.
-- Hardware Options
HP did not describe the complete set of options which would be
available for the 9000. They did mention that larger winchester
disks with streaming tape backup were under development.
A local area network system based on the IEEE 802 CSMA proposal
(Ethernet) will also be provided.
-- Today's Demonstrations
All of the demonstrations I saw were graphic. The quality of the
demonstrations were fine. Many of them involved dynamic creation of
complex figures, curves, or shapes where the calculations required
were done on the fly. One of the demonstrations caused a complex
line image to be rotated. The image consisted of several hundred
line segments; rotational movements (several degrees) occurred
several times each second. That's got to require a great deal of
computation. The machine obviously has some muscle.
The colors displayed by the demonstration programs were quite
absorbing but the medium resolution of the monitor distracted from
what would have otherwise been very striking displays on high
resolution systems.
One very nice facet of the demo package was how well the function
keys were used. Each demo showed function key labeling at the
bottom of the display (directly above the eight integral function
keys). Normally the rightmost key was labelled "next menu" and the
leftmost key "exit". Depressing "next menu" did get you to another
menu of sub-options. The demos were nice to use.
-- Pricing
The price of the demonstrated configuration is about $50,000.
The color display of that configuration is listed at approximately
$10,000. The light pen is an additional $1,500.
The winchester and floppy count for another $10,000 bite.
A configuration with no disk, a B/W display, no printer might come
in at HP's advertised base price of $28,000.
Additional processor boards run about $10,000. It seems as if HP
has decided that anyone interested in this product should not flinch
at $10,000-size chunks.
-- Opinion
HP's 9000 product will probably find its niche in the high powered
workstation marketplace.
More important, however, is HP's current capability to develop,
manufacture, and utilize extremely dense circuitry. I expect to see
more applications of this capability from HP. It will be very
interesting to see how fast and in what manner HP brings its new
resources to the marketplace.
Jeffrey Stone
Menlo Park, CA
7 December, 1982
------------------------------
End of WorkS Digest
*******************
-------
∂30-Dec-82 1311 AVB WORKS Digest V2 #93
∂29-Dec-82 1532 Mel Pleasant <WORKS at RUTGERS> WORKS Digest V2 #93
Date: 29 Dec 1982 0037-EST
From: Mel Pleasant <WORKS at RUTGERS>
Subject: WORKS Digest V2 #93
Sender: PLEASANT at RUTGERS
To: WorkS: ;
Reply-To: WORKS at RUTGERS
Works Digest Wednesday, 29 December 1982 Volume 2 : Issue 93
Today's Topics:
Queries - Software Development on the Fortune &
Call for Opinions on Instrumentation Lab's New Pixel 100/AP &
Forward Technology Gateway WorkStation &
High Density Memory,
Hardware - XAVAX & HP9000 SuperDesktop System,
Software - VAX/VMS CRT Drivers,
Call for Papers - Human Factors in Computing Systems
----------------------------------------------------------------------
Date: 23 Dec 1982 0444-EST
From: HAUTIN at RUTGERS
Subject: fortune,micromega,smalltalk
We are interested in software development on the FORTUNE micromega.
Is there a special group for this? who knows people interested in
SMALLTALK on micromega?
------------------------------
Date: 21 Dec 82 20:55:38-PST (Tue)
From: decvax!utzoo!watmath!bstempleton at Ucb-C70
Subject: Who has used the New Pixel 100/ap from Instrumentation Labs
I am considering purchasing one of these new systems. Has anybody
made extensive use of one and can tell me:
1) Performance information, ie. how well does it handle N users with
1/2 meg of memory on it. What about disk speed.
2) Satisfaction with manufacturer on support etc.
3) How does it compare to others, notably Onyx and Spectrix
Please mail me directly. Brad Templeton
decvax!watmath!bstempleton
------------------------------
Date: 20 Dec 82 10:01:01-PST (Mon)
From: decvax!cwruecmp!pjd at Ucb-C70
Subject: Forward Technology Gateway
Does anyone have any experience with the Gateway workstation from:
Forward Technology
Santa Clara, California
(408) 988-2378
Please send responses directly to me and I will put together a
bulletin for net.micro[uucp] and net.works[arpanet - WorkS].
Thanks!
pj drongowski
decvax!cwruecmp!pjd
FYI: From Electronics, November 17, 1982, pg. 133-136:
Pc: 68000 8 MHz, 256 Kbyte RAM, 2 RS-232 ports, 1 16-bit parallel
port, timer, Multibus with 5 expansion slots.
Display: 1024 x 800 resolution, separate 128 Kbyte display memory,
raster op hardware, 15" monochrome display, VT100 keyboard.
Software: Microsoft Xenix, Core graphics.
Options: RAM to 1.5 Mbytes, 10 Mb 5.25" Winchester, 84 Mb 8"
Winchester, Backup tape, mouse, desk-high rack, Ethernet.
------------------------------
Date: 28 Dec 1982 1602-PST
Subject: High-tech dilemma (INFO-HARDWARE?)
From: Jeff La Coss <JLACOSS@USC-ISIB>
To: Info-pc@USC-ISIB
I have to consider the unappetizing possibility of making a custom
high-density memory array out of high-speed RAMs in leadless chip
carriers. Most of the LCCs that I've seen have their leads available
only on the bottom of the package, requiring either sockets (ruining
the density) or reflow soldering.
Does anyone out there know about reflow soldering and/or who to
talk to?
Also, does anyone out there know of any short-run or
fast-turnaround multi-layer PC board houses?
Preferably suggested people will be in the LA area, but I'm open to
trans-continental dealings.
Thanks,
Jeff
------------------------------
Date: Monday, 20 Dec 1982 11:18-PST
To: Bill Lee <lee@Utexas-11>
Cc: Unix-Wizards at Sri-Csl
Subject: Re: XAVAX
From: lacasse at Rand-Unix
I talked with them once. They sell a reconfigured WICAT. I think
they pull out WICAT's CPU board, and put "the Stanford Board". It
is a VERY small company. The top guy in the Co. was the 'salesman'
I got. He wouldn't even tell me whose boards he was putting in the
system he was trying to sell me. I stayed away.
I like the Sun, Callan, and Fortune. The Sun has BSD, and a high
price. The Callan has Standard V7 Unix (Unisoft port), and a low
price (9K with 10 Meg. hard disc and floppy). They have an editor
called "j" (where is it from?) and Berkeley's vi, csh, etc. The
Fortune has about the same price as the Callan, and greater
popularity and marketing muscle. They also have a nice menu shell,
and a pretty good editor (FOR:WORD). But they charge you $500 about
five times over just to get the standard Unix software tools. (C
compiler and As - $500; Lex and Yacc-$500; small Berkeley
collection-$500; etc.)
Mark LaCasse
Rand Corporation
1700 Main Street
Santa Monica, CA 90406
213/393-0411
------------------------------
Date: 20 Dec 1982 2001-MST
From: Chip Maguire
Subject: Re: The Hp9000 SuperDesktop System
Sender: MAGUIRE at UTAH-20
**** Some flame - but a word to the wise ****
The local HP rep showed the tapes here last week and several
weeks before gave a product announcement. After the first visit I am
amazed that he was foolish enough to come back. The over all
impression that he left was they they were very premature announcing
the product. The 12 week delivery was for a single user BASIC only
system, with UNIX (TM - Bell labs) not available till summer. This
was not clear from their initial presentation - until they were
pressed on the matter. They did not have any programming manuals or
system manuals - they alluded to HPUX - being HP extensions to UNIX
- but did not know what these extensions were. The local area
networking was abysmal as they more or less said "Whatever everyone
else settles on we will have to." Given the Apollo DOMAIN units
which have a local area net, virtual memory, multiple windows and
processes - all working now - why does HP believe that anyone will
buy their product on the basis of a slick video tape and promises of
software this summer? While the HP9836s, HP9826, and HP3000 (which
we had) all had hardware that was robust - the software and
packaging was dreadful. The HP9836 and HP9826 were definitely
designed by people who had only used desktop calculators and not DEC
System-10s and 20s or Apollos or Xerox D-machines, etc.
To run the same LISP programs that we run on the Apollo
(with 1/2 Meg) required adding an expansion cage to the 9836 and
adding in about 6Meg of memory. Note that this remark may not apply
if the 9000 has gotten the virtual memory working right - but proof
to the contrary should be a small concern.
Although the 9000 has great promise for the future - I think
that pressure needs to be applied now - to help the product out and
produce something which is really nice - rather than a first attempt
at a real machine. If the 9000 is HPs analogue to the DG new machine
then they should take a look at the number of machines which DG sold
vs. the VAX! The days of people buying simply for the flash - nnnK
transistors/chip are hopefully passing - I hope that the days of
user friendly well engineered integrated SYSTEMS has arrived.
G. Q. Maguire Jr.
------------------------------
Date: 17 Dec 82 23:40:49-PST (Fri)
From: Bruce C. Wright <harpo!duke!bcw at Ucb-C70>
Subject: Re: VAX/VMS CRT Drivers
I have a foreign terminal package for VAX/VMS which hooks into the
VMS screen package and which does a pretty good job for ADM's and
HP's, which I would be willing to let go of (no guarantees about bug
fixes etc).
Now for the bad news - EDT does not use the VMS screen package. At
all. Therefore you can't even use the non-keypad version of the
screen editor available under EDT, on non-DEC terminals. I have
suggested to DEC that they at least have EDT use the VMS screen
package for output so that the non-keypad screen mode on EDT would
work, but DEC doesn't seem to be too eager to do this.
There are some other places to look for screen editors for VMS:
1) You could hack up a version of the VTEDIT TECO macro which
would handle non-DEC terminals. Probably this would be a
lot of trouble since the VTEDIT macro 'calls' functions
inside TECO which know about the DEC terminals ... of
course, you could modify TECO if you don't mind hacking a
lot of badly-written assembler code ... And then TECO
macros (especially of this size) aren't too easy to write
anyway. And to add insult to injury, the result would
probably prove a real CPU hog on the VAX.
2) You could get something like Eunice or Unity which will run
the VI editor from Berkeley under your VMS system. It seems
to work reasonably well - I use it on my hp2648 all the
time.
3) You could get something like the MASS11 word processing
system which has support for non-DEC terminals. Some of
these are pretty nice - we looked at MASS-11 but decided
against it not so much because it wouldn't do what we wanted
(it's a very nice word processing system) but because it was
too expensive to justify considering the amount of word
processing which takes place on our VAX. Other systems are
also available.
Hope this is of some use and/or interest ...
Bruce C. Wright @ Duke University
------------------------------
Date: 22 Dec 82 3:29:11-PST (Wed)
From: harpo!floyd!cmcl2!philabs!sdcsvax!phonlab!sdcsla!norman at Ucb-C70
Subject: Call for papers: HFinCS Conference
CALL FOR PAPERS
Human Factors in Computing Systems
Dec 12-15, 1983 Boston, Massachusetts
Sponsored Jointly By
ACM SIGCHI and The Human Factors Society
This conference will focus on the presentation of empirical findings
and theory related to usability in interactive systems. Papers
which address human factors issues in software, hardware, and
documentation are welcomed. Papers which relate to the following
topics are particularly encouraged.
Methodology: Interface and Language Design:
----------- -----------------------------
Interface Design Methodology Human Factors Issues in Object-
Interface Evaluation Methodology Based Programming
User Cognitive Models Graphics-Based Interaction
Programmer Performance Measurement Voice Interaction
Novel Interface Interaction
Novel Language Design
System Performance Evaluation: Application of Intelligent
----------------------------- Systems to Enhance Usability
Usability of Programming Language
Critical, Formal Evaluations of Working Systems
Organizational Impact of Interactive Systems
Interested authors should submit four copies of the paper by May 1,
1983. Papers should be approximately 2500 words in length and
should contain an abstract of 100-150 words. All submitted papers
will be reviewed and will be judged with respect to their quality
and relevance. Proposals for session and tutorials are also
invited. Papers should be sent to the Program Chairman, Richard W.
Pew, Bolt, Beranak & Newman, Inc., 10 Moulton Street, Cambridge, MA
02238 (617-497-3557). General chair for the conference is Raoul N.
Smith, GTE Laboratories, Inc., 40 Sylvan Road, Waltham, MA 02254
(617-466-4044 or 617-890-8460).
Deadline for Submission of Full Papers......May 1, 1983
Notification of Acceptance .................July 1, 1983
Camera-Ready Manuscript Due.................August 1, 1983
Conference..................................Dec 12-15, 1983
------------------------------
End of WorkS Digest
*******************
-------