Text File

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 <jgoerzen@complete.org> 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.