From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Organization: Los Alamos National Laboratory
Date: Thu, 27 Aug 1992 16:58:56 GMT

In article <1992Aug26.231251.17181@zooid.guild.org>, Ross Ridge <ross@zooid.guild.org> writes:
|> [...]
|> In terms of finding a job providing user support for, they, UNIX, MS/DOS,
|> and other single user and/or obsolete OS'es, are pretty much are the only
|> alternatives.
|> 
|> You seem to have an axe to grind.  Just what OS suits your fancy?

Cray CTSS is also obsolete (but by only 10 years instead of 20
like UNIX).  It has many features which *should* be incorporated
in *any* multiuser system - 

 1) crash recovery - the ability of the system to keep user process
    running normally across system failures.  This is trivial for
    all *planned* downtime (though UNIX can't do it), and on CTSS
    was usually accomplished even for *unplanned* downtime (like
    lightning on the power supplies).  Yes, the user *can* waste
    a lot of time and resources making restart dumps periodically,
    but it's more efficient and more convenient for the system to
    this chore.  And with restart dumps you still lose all the 
    work the process did between the most recent dump and the time of
    system failure - as well as having to manually run a utility
    to actually restart your code, or write a daemon to periodically
    attempt this - but this assumes your daemon continues running
    across the failure!  ->  No wonder UNIX users usually just
    rerun from scratch.

 2) security - nuff said.

 3) load balancing - that is, the ability to move a running process 
    from one machine to another (see item 5 below as well).

 4) restartable images when processes abnormally terminate - possibly 
    from a different place than the site of the failure and possibly 
    after altering register or variable contents.  *Great* debugging 
    aid, and sometimes you can even recover a dead process without 
    rerunning from scratch (a good deal if you process just dropped
    after consuming several hours of Cray time).  The ability to 
    conditionally execute parts of the code (under a debugger) in 
    the same context as the error is a *very* handy thing in tracking 
    bugs - in UNIX, the only way to do this is to rerun the problem 
    from scratch under a debugger with a breakpoint set just prior to 
    the point of failure (*if* you can identify in which iteration the 
    failure occurred from an examination of the core file - and *if*
    you can remember and duplicate all your interaction with the process).

 5) process archival - the ability to suspend a process, store it 
    and its working files to archival storage and bring it up 
    later - maybe even at a different site.  This is similar to
    load balancing, but is useful for different reasons - among
    other things: debugging.  If you're in the middle of a debugging
    session which took you a long time to step forward to the 
    interesting point of failure, but you don't have time to
    finish before the weekend (or the conference you're going
    to, etc.) you can save it and continue later - or take it
    to the conference with you on a tape!

etc...

The system is much _smaller_ even though it has this additional
set of features.  The users who are unaware of these features
need learn little or nothing about them if they don't want to
use them - the system is easier to learn and use.  CTSS has
a full set of interprocess communication capabilities, I/O
that is not `file-typed' by the kernel, etc.: that is, *most*
of the features UNIX supporters rave about (differently 
implemented and with simpler interfaces - but they're there - 
including two different ways to implement pipes).  I said 
*most* features, because not all are there - but then UNIX 
doesn't have the features mentioned above either.

Once you're familiar with these features, they are every bit
as important and useful as UNIX users find pipes to be.  And 
their convenience is apparent in *all* contexts, though emphasized
for large, long-running production processes.
    
To be sure, CTSS is hardly perfect and is missing some *very*
important features itself (like a tree structured file system!).
But it's certainly a better *starting point* for future system
designs than UNIX is.  If for no other reason than it's greater
overall power with a simpler user environment (and its smaller size).  
Yes, even *some* ideas from UNIX are important to incorporate (pipes 
and tree-structured file systems, for example), but they don't require
or justify carrying the rest of UNIX along.

-- 
J. Giles
Newsgroups: comp.lang.c