🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

1 total messages Started by ucbvaxworks Fri, 12 Mar 1982 11:54
Re: Unix really isn't the answer
#114
Author: ucbvaxworks
Date: Fri, 12 Mar 1982 11:54
46 lines
2938 bytes
>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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads