NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/misc/3601

Text File | 1992-09-09 | 6.1 KB | 127 lines

Newsgroups: comp.unix.misc
Path: sparky!uunet!gatech!destroyer!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (Jim Giles)
Subject: Re: Giles' (Manual) Mania (getting longuish)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Los Alamos National Laboratory
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 9 Sep 1992 19:29:46 GMT
Lines: 115

In article <[e-mail]>, [e-mail] (Dik T. Winter) writes:
|>  > [...]
|>  > Scope *was* a lot smaller and easier to use than UNIX and provided more
|>  > features in the kernel for the use of hardware capabilities (like
|>  > asynchronous I/O).
|> Did the PDP-5 provide asynchronous I/O?  [...]

Yes, you're quite right, that's why UNIX doesn't have asynchronous
I/O.  It was designed on hardware that didn't have the capability
and was never *upgraded*.  It is easy to design a perfectly portable
*interface* in which asynchronous I/O is permitted - even though
particular hardware can't do it (you simply emulate).  It is very
difficult to *use* asynchronous I/O if your system's interface
*doesn't* allow it - even when the hardware *does*.

|> [...]                                     Asynchronous I/O makes sense
|> only on some processors, and if the manufacturer does his work well he
|> will provide it in the Unix environment.  [...]

Only as a non-UNIX *extension*.  Yes, UNIX can have non-UNIX features
added to it.  These can correct many of its failings.  To the extent
these failings have been addressed in a particular implementation, the
system is *not* UNIX.

|> [...]                                  I think Cray does, but I never
|> needed it (because most of my programs on the Cray have only one bit of
|> output, the number is prime or not).  I think also that Convex has it.
|> It can be put in the Unix OS without problems.

Yes, the Cray implementation you mentioned added it by *bypassing* all
the usual UNIX I/O stuff in the kernel.  They grafted it on, essentially
as an independent feature, completely distinct from UNIX I/O.  It's
a vast improvement.  If I were writing an I/O library for UNICOS (Cray's
unix) I would use *only* the non-UNIX extended I/O calls - they not only
provide asynchronous I/O, but synchronous I/O as well, and they're faster
from what I understand.

|>  >                     For messing with text filters, UNIX has more
|>  > power than Scope did - for most other things, UNIX does not.
|> That is an understatement, Scope had no power at all, you had to write
|> your own text filters.  Now please define "most other things".

Oh, Lattice guage theory (lots of multidimensional float arrays)
which needs asynchronous I/O and other direct hands-on control
of hardware capabilities to be efficient.  Or, how about really
sophisticated text handling (which MS/DOS does better than UNIX),
word processing and the like.  Or, how about human genome stuff
(lots of bit twiddling on large collections of data - again a
need for hands-on control of hardware capabilities, especially
I/O).  Etc..

Yes, Scope is obsolete for these as well as UNIX.  We shouldn't use
either *today*.  It's 20 years after that era.  At the time, Scope was
much better than UNIX (which was nothing more than a mini-computer
CP/M).  But, for the hardware that was then available, Scope was
easier to learn and to use for *real* programming.  If I needed
to have a Fortran engine again, I would still prefer Scope to UNIX.

|>  > [...]                                                       Due to
|>  > its checkered past, UNIX is also home to more (and more subtle)
|>  > inconsistencies.
|> There are many more inconsistencies in Scope than in Unix.  Unix has
|> only one command to copy a file.  Scope has: COPYBF, COPYCF, COPY,
|> COPYSBF, COPYRAN.  Now can you quickly explain what [... a relatively
|> number of examples ...]

Can you explain why the UNIX environment has two different pattern
matching syntaxes (wildcards and regular expressions) and why the
different tools which need to do pattern matching are rather
idiosyncratic about which they use?  Can you explain why, although
different, they use the *same* characters as meta-symbols (so each
has to be quoted to get through the other)?  Rational design requires
either that there be only one such syntax, or if there are two, they
should be completely disjoint if they are ever to be used together.

Can you explain why there are two different tools to inquire the
same database (the file directories): ls and find?  And can you
explain why their overlapping usages don't use the same option
names, etc.?

Can you explain why line-at-a-time text filters *exist* in UNIX (when
the brag is that UNIX imposes no structure on files)?  Can you explain
why such line-at-a-time filters have *different* line and files size
limits?  Can you explain why several of them have overlapping capability
but don't use the same syntaxes and/or option names for the same
features?

Can you explain why *no one* seems satisfied with UNIX text editors (since
there are so many of them - all incompatible)?  There wouldn't have been so
many written if any of them were any good.

Can you explain why I can't even write (even if I want to) a remote
`ls' command which lists files on a remote machine but which is
compatible with `ls':  I can't say

      rls machine-id a*

to find all files in my home directory on the remote machine whose
names begin with `a'.  *THIS* would be consistent, but the UNIX
environment won't even *let* me do it.  Why?  They *CLAIM* it's for
consistency!!  But, since that obviously *wasn't* a constraint in
the rest of the environment (and this is counter to consistency
anyway), this excuse is not valid.

Etc..

Yes, with as much extra development time as UNIX has had, I have
no doubt that Scope *could* have developed to be as huge and ill
structured as the UNIX environment.  I believe that CDC would
*probably* have taken the time to do something that was never
done for UNIX: *STOP*, streamline, rationalize, and clarify
the environment.

--
J. Giles