Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site weitek.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!cae780!weitek!mmm
From: m...@weitek.UUCP (Mark Thorson)
Newsgroups: net.followup
Subject: Unix from a snob's point of view!
Message-ID: <298@weitek.UUCP>
Date: Thu, 17-Oct-85 11:28:21 EDT
Article-I.D.: weitek.298
Posted: Thu Oct 17 11:28:21 1985
Date-Received: Sat, 19-Oct-85 06:52:12 EDT
Organization: Weitek Corp. Sunnyvale Ca.
Lines: 55
Keywords: valid and invalid criticisms
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!)
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.)
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.)
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.
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).
3. Unix security is eggshell-thin. In practice, Unix is usually run about
as securely as other OSes. But it is intrinsically easy to break. This
is one problem that Unix can't run away from. As Unix matures the other
problems will become less important, but this one will become more.
Mark Thorson (...!cae780!weitek!mmm)
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: her...@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: her...@polaris.UUCP (Herb Chong)
Organization: IBM TJ Watson RC
Lines: 111
Keywords: valid and invalid criticisms
Summary:
In article <2...@weitek.UUCP> m...@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.ykt...@ibm-sj.csnet
ARPA: herbie.yktvmh.ibm-sj.cs...@csnet-relay.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site wcom.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!wcom!frodo
From: fr...@wcom.UUCP (James Scardelis)
Newsgroups: net.followup
Subject: Re: Unix from a snob's point of view!
Message-ID: <942@wcom.UUCP>
Date: Sat, 16-Nov-85 20:40:54 EST
Article-I.D.: wcom.942
Posted: Sat Nov 16 20:40:54 1985
Date-Received: Sun, 24-Nov-85 04:40:56 EST
References: <298@weitek.UUCP> <228@polaris.UUCP>
Organization: Warner Computer Systems, Inc., Saddle Brook, NJ
Lines: 12
> 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.
On System V, the physical block sizes are 1K.
--
Jim Scardelis, SA
{vax135,ihnp4}!wcom!frodo
#include <favorite disclaimer>
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.followup
Subject: Re: Unix physical block size
Message-ID: <1638@cbosgd.UUCP>
Date: Tue, 26-Nov-85 00:29:18 EST
Article-I.D.: cbosgd.1638
Posted: Tue Nov 26 00:29:18 1985
Date-Received: Tue, 26-Nov-85 20:52:27 EST
References: <298@weitek.UUCP> <228@polaris.UUCP> <942@wcom.UUCP> <701@petrus.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 29
> > 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.
>
> On System V, the physical block sizes are 1K.
Unfortunately, in System V, the number 512 is thoroughly embedded into
nearly all levels of the system. At the physical level, disk sectors are
assumed to be 512 bytes. (This is true of 4BSD also.) When you do a "du"
or an "ls -s", the units reported to the user are "blocks", which everyone
knows are 512 bytes each. In fact, I often ask someone how much disk space
something takes up, and they tell me how many "blocks" it takes up, assuming
I know that "blocks" are 512 bytes.
Berkeley has attempted to change the units that people think in to "K", e.g.
1024 bytes. While I've changed my thinking to K and Megabytes, I still have
to translate from the old system because of all the people out there that
have 512 stamped onto their brains. It's like translating between the
traditional and metric systems - if we'd all go cold turkey at once it
wouldn't be any big deal.
The filesystems do work in bigger units, and this produces significant
speedups. System V typically does disk transfers in units of 1K (this
means that when it wants a disk block, it transfers two 512 byte sectors
at once.) 4.2BSD is similar, although it does 4K or 8K transfers by
doing 8 or 16 sectors at once. (There are exceptions, of course, some
systems still use 512, others use 4K, etc.)