[fa.human-nets] HUMAN-NETS Digest V6 #9

Pleasant@Rutgers.arpa (02/14/83)

HUMAN-NETS Digest        Monday, 14 Feb 1983        Volume 6 : Issue 9

Today's Topics:
      Queries - Intelligent Interfaces to Operating Systems &
          PC Uses for the Handicapped & Unix on Burroughs,
                  Response to Queries - Crosstalk,
                   Programming - Unix (5 msgs),
        Computers and People - Information Systems (3 msgs)
----------------------------------------------------------------------

Date: 8 Feb 1983 at 1322-CST
From: KM< <korner@utexas-11>
Subject: Reply to: human-nets digest   v6 #8

        I am compiling a bibliography of intelligent interfaces to
operating systems (intelligent help systems, programmer's assistants
at an OS level, self adapting user interfaces, command language
"coaches", etc.). A pointer to your favorite work in this area would
be appreciated. If there is enough response, I will summarize and
post the results. Thanks-

                Kim Korner
                korner at utexas-11
                cc.korner at utexas-20

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

Date: Fri 11 Feb 83 10:59:49-PST
From: Guillermo A. Loyola <CSL.Lantz.Gmo@SU-SCORE.ARPA>
Subject: PC uses for the handicapped.

I'd like to hear from anybody doing work in the area of Personal
Computer uses by handicapped persons.  We have a coworker with
cerebral palsy.  Some software has been written for him using a
speech synthesizer but a lot more is needed.  The guy who wrote the
software (who has no access to the net, but I can set up the
contacts) would really start a dialog with people working in this
areas.

Please replay to me directly with a U.S. Mail address and/or phone
number.  Thanks.

Guillermo.

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

Date: 9 Feb 83 0:07:46-EST (Wed)
From: Randall Gellens <randall.udel-cc-unixa@UDel-Relay>
Subject: Unix on Burroughs?

I've heard, at various times, rumors of attempts to get some sort of
Unix running on Burroughs (large) systems (B5000, B6000, B70000).

Anyone know of any actual attempts?

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

Date: 13 Feb 83 17:00:26-EST (Sun)
From: the soapbox of Gene Spafford <spaf.gatech@UDel-Relay>
Subject: CrossTalk

Les Freed and Bob Strong wrote the first version of CrossTalk in
1978 for a Northstar computer.  The first CP/M version was circa
fall 1980.  The current version of CrossTalk runs on over 80 CP/M
machines, and a major revision is currently underway, principally
for 16 bit micros.  Les has been the maintainer of CrossTalk for
years.

Les Freed's company which markets CrossTalk is
        Microstuf
        1845 The Exchange
        Atlanta, GA 30339
        (404) 952-0267

Larry Hughes is the author of C-Link, another terminal emulator for
micros.
                                        -- Gene

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

Date: 7 Feb 1983 12:46:20-EST
From: csin!cjh at CCA-UNIX
Subject: re VMS vs UNIX

   I'm not sure what you mean about real-time process control; I've
just spent a weekend tying up several terminals on a VMESS because
even the hacker who wrote a chunk of the typesetting system I was
using couldn't get stuff to run in the background (the way I
trivially can on UNIX).

   Also, I don't think of myself as a hacker (if I did, the people I
work with would soon correct me) and I found several other
disfeatures about VMESS---very limited typeahead, poor choice of
editors and the best of those subject to unpredictable hangups (on
cmd typos instead of just beeping that they don't understand), etc.
This seems true even on VAX VMESS as run at a DEC plant.

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

Date: 7 Feb 1983 1114-MST
From: Walt <Haas@UTAH-20>
Subject: Re: re VMS vs UNIX

I had specifically in mind the type of automated warehousing systems
I built for five and a half years.  The main requirement was that
the behavior of the system be highly predictable AFTER the software
development phase was finished.  Features such as demand paging and
"fairness" schedulers tend to make a system less predictable.  Thus
if the system is required eg. to divert a pallet moving on a
conveyor belt within N milliseconds, having to share the processor
or main memory with an unpredictable software development load may
cause the pallet to be mishandled.  This type of error can be
extremely expensive.  Of course, the limited typeahead, bad editors
etc.  also raise costs, specifically software development costs.
Hence my vote for a highly predictable OS with a better user
interface and utilities.

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

Date: 7 Feb 1983 14:43:16-EST
From: csin!cjh at CCA-UNIX
Subject: Re: re VMS vs UNIX

In response to your message of Mon Feb  7 13:17:24 1983:

   I see we stumbled over the meaning of the word "process"---you
were speaking of mechanical processes rather than computer ones. I
would have thought that control on that level would not involve a
high-level OS at all, given the general trend toward distributed
processing (obviously different companies have different ways of
attacking CAM, but this is what I got from interviewing with
Gould-Modicon, which was specifically pushing programmable boxes to
replace hardwired relay setups).

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

Date: 7 Feb 1983 1456-MST
From: Walt <Haas@UTAH-20>
Subject: Re: re VMS vs UNIX

Good point.  The company I worked for installed a number of such
distributed processing systems.  However the big payout of the
systems that I worked on came from keeping inventory records
literally up to the millisecond.  The micros attached to the
material handling machines were attached by fairly fast
communications links to the machine that maintained the inventory
database.  The database machine in turn made all the material
movement decisions that required inventory information as either an
input or an output; for example, if a pallet of widgets was to be
detected and diverted down a conveyor spur, the inventory records
needed to be consulted to determine that pallet NNN was the one with
the widgets, and then the inventory records for widgets in stock had
to be updated as soon as the divert had taken place.  If it seems
hard to understand why anybody would do things this way, the reason
is simple: money.  One of the major costs in a material handling
operation is the cost of the uncertainty in how much inventory you
have, and where it is.  Thus if you need to have quantity X of a
part to run your factory, and your material handling method
introduces an uncertainty of deltaX when it starts to move your
parts around, then you have to buy and pay for X+deltaX parts.  The
system I described reduces deltaX by a factor of about ten over
manual methods, ie. it saves about .9*deltaX of your inventory.
This translates into a payback period as short as eighteen months in
some multiM$ systems that we put in.  However, note that the whole
thing hinges on the CPU's being able to respond quickly and
predictably to the demands of the industrial process.

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

Date: 9 Feb 83 00:03:15 PST (Wed)
From: UCBARPA.fair@Berkeley (Erik E. Fair)
Subject: Fortran under VMS vs Fortran under Unix

        The Computer Systems Research Group at UC Berkeley (The
people who brought you 4.? BSD Vax/Unix) were or are working on a
version of f77 which is supposed to be comparable to Fortran under
VMS. The last I heard about it was 6 months ago, and it was (I
think) in beta test, but it was supposed to be just a shade slower
than VMS Fortran. For info, contact David Mosher, Technical Manager
for CSRG at mosher@Berkeley, ucbvax!mosher or (415) 642-7780.

        Besides, this gives me the chance to relate my VMS horror
story. I was trying to use a tape drive to change a 600' tape in
1600 bpi, into two 600' tapes in 800 bpi. I came out with one 1/4
full 600' tape in 800 bpi, with half the data that was left on the
tape being trashed. I have never touched VMESS since.

                Erik E. Fair    ucbvax!fair     fair@Berkeley

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

Date: Mon Feb  7 1983 18:27:23-PST
From: Lauren Weinstein <vortex!lauren@LBL-CSAM.ARPA>
Subject: EPCOT and UNIX

I'm not too sure where the big Honeywell computer fits into the
EPCOT framework, but...

I had a phone conversation fairly recently with one of the Bell Labs
persons who worked on the EPCOT information display systems that
were discussed in a previous digest.  He told me that they were
controlled by a large number of VAX 11/750's, all running Berkeley's
flavor of UNIX.  There was also a presentation regarding the EPCOT
systems at the most recent UNIX ("Unicom") conference, so it appears
that UNIX is well entrenched in the Experimental Prototype Community
Of Tomorrow.

--Lauren--

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

Date: 8 Feb 83 05:52:01 EST  (Tue)
From: Mark Weiser <mark.umcp-cs@UDel-Relay>
Subject: WorldKey at EPCOT.

World Key was cute, and it did help me find a place to eat one night
when my family was very hungry and every place was supposedly
closed.  But it had a crucial flaw:  it was a hierarchical menu
system, and some of the menu trees were rather deep, and there was
no  way to get quick access to deep in the tree even if you knew
where to go.  One could not walk up to one of these things with an
interest in an exhibit and get information about it without
wandering through a bunch of irrelevant questions first.
Furthermore,  it had the classic problem that has been exhibited
experimentally  in the British teletext systems: no multiple
pathing.   The teletext experiments (Maguire, pp. 350-354,
conference on Human Factors in Computer Systems, March 1982) cite
the case of someone looking for the Red Fox Inn.  Early in the
teletext menu they had to choose between looking for restaurants or
looking for hotels.  It turns out that the Red Fox Inn was known to
some people as one and some people as another, but could only be
reached down the hotel path.  (Looking again at the proceedings I
notice that this anecdote is only hinted at, so it is something I am
remembering from the talk.)   World Key had the same problem.  One
could not simply scan everything at a given geographical location,
but had to decide between entertainment  and food (and some third
category) early on.

But it was fun to use the first couple times.

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

Date: 12 February 1983 23:33 EST
From: Robert Elton Maas <REM @ MIT-MC>
Subject: EPCOT and WORLD-KEY information system

    Return-path: <@MIT-AI,@MIT-MC:gutfreund.umass-coins@UDEL-TCP>
    Date: 24 Jan 83 14:43-EST (Mon)
    From: Steven Gutfreund <gutfreund.umass-coins@UDel-TCP>

[Reply to message on WORKSTATIONS digest, re the "WORLD-KEY"
 information system available at EPCOT:]

    One can browse via four different perspectives: keyword, context,
    physical location, or category.

I have long been aware that neither category (tree-structured
subject classification) nor keyword methods of access are sufficient
in themselves, and that physical location is often a useful third
access method or limiting method. In an integrated system, citation
links and reverse links are also useful. XANADU's approach of being
able to create citation links to segments of quoted text instead of
only to complete quoted documents, seems to be a winner, and I hope
other systems adopt it. When you refer to context, what do you mean,
citation links and the like, or something totally different?

[I took the liberty of CCing to HUMAN-NETS instead of WORKSTATIONS
because I'm discussing the information-retrieval aspect instead of
the fancy-display aspect.]

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

End of HUMAN-NETS Digest
************************