Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site polaris.UUCP
Path: utzoo!linus!philabs!polaris!herbie
From: herbie@polaris.UUCP (Herb Chong)
Newsgroups: net.followup
Subject: Re: Unix from a snob's point of view!
Message-ID: <228@polaris.UUCP>
Date: Wed, 23-Oct-85 21:43:39 EST
Article-I.D.: polaris.228
Posted: Wed Oct 23 21:43:39 1985
Date-Received: Sun, 3-Nov-85 14:17:54 EST
References: <298@weitek.UUCP>
Reply-To: herbie@polaris.UUCP (Herb Chong)
Organization: IBM TJ Watson RC
Lines: 111
Keywords: valid and invalid criticisms
Summary: 

In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes:
>It's become soooo fashionable to put down Unix.  So why don't you ever hear
>valid criticisms of Unix?  You always hear chicken---- like:

>1.  It has cryptic command names.  (So what?  They work!  Alias them if
>    you'd rather say 'search' to call 'grep'!  What do you want, a menu-driven
>    shell?  It would be easy to give you one if that'll put this stupid
>    criticism to rest!)

but then you are paying the price of compatibility.  your commands and your
documentation don't correspond.  i switch between three different operating
systems during a single day's work.  renaming commands would play havoc with
remembering what things do even though i have been using two of the systems
for more than a year as a programmer and am considered an expert (but not
a guru) on two of them.

>2.  It has bad documentation.  (Have you tried to read it?  It is oriented
>    to working programmers so it does tend to be terse and easy to scan.
>    But if you need some one to hold your hand, there is an abundance of
>    books at your local technical bookstore.  The books range from ultra-
>    beginner to advanced topics, specialized to generalized, verbose "user
>    friendly" to dry reference tomes.  What do you want?  Unix has been
>    described from every conceivable angle.)

which was fine in the good old days when dennis ritchie was the only one
using the system or in the small group that worked on version 6.  nowadays,
there is a much larger user community and the average level of expertise
is lower.  as a user consultant when i was with the university of waterloo,
i had to interpret the documentation for ordinary users on our 4.2 bsd 
system.  about 10% of the manual pages were clarified locally and still
most ordinary users couldn't understand what the documentation meant.
all too often, i had to look at the source in order to figure out what
was really going on.  i was fortunate that i was priviledged enough
to be able to look at it.  i save said this many times on the net and i
will say it again, the unix documentation was written to remind the
person who wrote the program what everything does.  it also happens
that some of the time, an ordinary user can understand it and that
most of the time, a system hacker or guru knew what was meant.

>3.  It's a hack.  (Dead wrong.  Operating systems from the manufacturers are
>    hacked --- RSX11 for an extreme example.  When I started using Unix ten
>    years ago, most multitasking operating systems were much larger.  They
>    were also highly restrictive.  Things like the command interface were
>    part of the OS.  The SYSTAT program (in DEC parlance) was part of the OS.
>    The file copy program was part of the OS.  The revolutionary thing about
>    Unix back in 1975 was that it only supported critical functions in the OS.
>    Everything else was a disc-resident program.  Thus you could write your
>    own shell, your own SYSTAT, your own everything.  And people did.  Unix
>    in 1985 is encrusted with all kinds of cute additions.  The Unix environ-
>    ment today is the OR function of everbody's ideas on how to 'improve' the
>    shell and the system utilities.  BUT THE UNDERLYING ELEGANT STRUCTURE IS
>    STILL THERE.  You can delete the extensions if you wish, but it's easier
>    to turn them off.  When I was given my account on the Weitek VAX, the SA
>    had provided me with .cshrc and .login files that turned on most of the
>    cute features. Like the funny characters after the file names when you
>    do an 'ls'.  I immediately deleted those files and logged back in.)

but it's not the underlying structure that people deal with.  it's the interface
that we see.  do you really care that you could write your own shell to
handle commands in your own prefered manner?  maybe you do, but there are
an awful lot of people who not only don't care, but would use any system
as long as it got the job done and on time.  the design of a system alone
doesn't make it wonderful to use.  multics is not bad, from what i hear, and
the layered approach to design has been emulated by many other systems, but
do you see many out there?

>I'm not love-blind to the weaknesses of Unix.  There ARE valid criticisms of
>Unix, but you won't hear them from these pseudo-intellectual snobs.
>
>1.  Unix does not support the traditional scientific computing environment 
>    well.  This means compute-bound FORTRAN programs.  If you want to program
>    in FORTRAN or if you want to run crunching FORTRAN programs like DRACULA,
>    get VMS.  At Weitek we run one VMS machine solely for this reason.


it doesn't support the interactive environment very well either if you get
larger.  unix does not scale up well, and that's where many people are
taking the design.  they are running it on bigger and bigger machines and
the fundamental algorithms used are beginning to chew up a larger and larger
percentage of the CPU.  admittedly, this is an implementation problem more
than a design problem, but it's there.

>2.  Unix does not support the traditional business computing environment well
>    This means sequential I/O bound COBOL programs.  Unix does not even have
>    sequential I/O.  It's random-access I/O is so fast that it is used to fake
>    sequential I/O.  But it does not fake it as fast as the real thing.  So
>    get an IBM computer if you want that (or look up a back issue of Computer
>    Graphics to see how Tom Farrin made Unix support true sequential I/O).

it's partly a function of hardware as well.  tradition has it that all disk
blocks are 512 bytes.  this is fine on a smaller machine where there was
only 64K to work with, the CPU and memory are slow, and so was the disk.
you can make block sizes bigger, but still you have to live with hardware
that doesn't understand it.  2K or 4K blocks make better sense on the
machines of VAX size with 4M, 8M, or even 12M or memory.  VM/CMS's file system
is basically block oriented much like unix's (with certain restrictions)
and yet I/O performance is almost an order of magnitude better in terms
of byte/s.  mind you, CMS never has to lock on I/O because the filesystem
is private to each user.


Herb Chong...

I'm still user-friendly -- I don't byte, I nybble....

New net address --

VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH
UUCP:  {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie
CSNET: herbie.yktvmh@ibm-sj.csnet
ARPA:  herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa