Aucbvax.6464
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Fri Mar 12 11:54:23 1982
Re: Unix really isn't the answer
>From George.Coulouris@Cmu-10a Thu Mar 11 19:22:03 1982
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



-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.