[comp.os.misc] UNIX vs. the world

jlg@cochiti.lanl.gov (Jim Giles) (06/16/91)

I'll still try to forward this to comp.os.misc.  The last time I had
an OS argument on this newsgroup, I defended it on the grounds that
this was the newsgroup where the issue came up - and everyone kept
flaming me for that position.  This time, I try to forward it to 
some other group, and UNIX _supporters_ keep switching it back here.
Can't win for losing.

In article <1991Jun15.143436.5574@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
|> [...]
|> The reason UNIX has become so popular is not because it's efficient and
|> not because it's user-friendly, but because it is the first hardware-independent
|> operating system, modulo SysV vs. BSD.  [...]

Nope.  That's an after effect.  The _reason_ UNIX became popular was for
no _technical_ advantage at all.  It became popular because, at a critical
time in the 70's, it was _free_ and _open_ and avalable on the _cheapest_
useful hardware: PDP-8/11 and VAXen.  Since, in that time frame, many 
universities were starting up CS departments for the first time and
many other schools were expanding their CS curriculum, the choice many
of them faced was between the vendor's system (not open, so they couldn't
teach internals), developing as system themselves (incompatible with 
everyone and not immediately available), or UNIX.  I was at school in
the mid 70's when this very debate came up.  No one at the time thought
UNIX was even remotely well designed or appropriate for any _real_
applications - but the _price_ (essentially free) won the day.  The 
system is _almost_ (but not quite) worth that price.

|> [... long argument about the desireability of a common environment ...]

I would agree _if_ the common environment showed _any_ quality in its
design or implementation.  However, the present situation is rather like 
telling everyone to stop driving fuel efficient, fast, modern cars because 
the commonality of Model-T parts makes them easier to use and maintain.

|> [...]                                                    Taking the long
|> view, hardware has been moving so fast that transportability of my skills
|> is far more important to me than getting the most out of my machine;  in
|> two years I can buy another machine which will be faster, even with UNIX's
|> inefficiency, than my present machine would be with an optimal OS -- and it
|> will cost me less than my existing machine as well.  [...]

The _same_ argument could be advanced in favor of _any_ portable system.
So why do we have to stick with the _first_ one that became portable? 
Why not insist on a truly well designed, efficient, easy to use system
- and then insist that _it_ be made portable.  We are the consumers after
all.  Again, the _first_ mass produced cars were Model-Ts and Model-As
(I always forget which came first) - should we still be driving those?

As for expense: it is becoming clear (from my experience anyway)
that UNIX is one of the most expensive systems to install and maintain
of any that I've seen.  This is true of both mainframes and smaller 
machines like workstations.  I'm not aware of any other system on micros
which requires full-time employees - one per few-dozen machines or so - 
to be "system administrators" like UNIX does.  (I don't know what these
people do, and I don't want to know.  They always seem to be overworked
and the only time I see _any_ effect of their activities is when they
accidentally break something and bring my workstation down.)  If you 
"administer" your own machine, it takes a higher percentage of your 
time than any other micro system I've seen (or, so I understand from
friends of mine that do so).  How is this an advantage?

J. Giles

sef@kithrup.COM (Sean Eric Fagan) (06/17/91)

In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>Nope.  That's an after effect.  The _reason_ UNIX became popular was for
>no _technical_ advantage at all.  It became popular because, at a critical
>time in the 70's, it was _free_ and _open_ and avalable on the _cheapest_
>useful hardware: PDP-8/11 and VAXen.  

UNIX wasn't available on vaxen until the '80s (not surprising, considering
that vaxen weren't available until the '80s).  When vaxen were available,
unix was a good OS to port to them because the system was largely written in
a portable fashion, in a high-level language which, by luck, happened to
move nicely to the larger vax.

As for unix being free:  when you bought a vax, you bought a license for
VMS.  It's kinda silly to argue that unix is free, considering that unix had
to be ported, while vms was already there for the cost of the machine.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

david@llustig.palo-alto.ca.us (David Schachter) (06/17/91)

In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>[UNIX] became popular because, at a critical time in the 70's, it was _free_
>and _open_ and avalable on the _cheapest_ useful hardware: PDP-8/11 and VAXen.

I don't believe any form of UNIX ran on the pdp8 line of computers.

-- 
                                               David Schachter
|
| internet:    david@llustig.palo-alto.ca.us
| uucp:        ...!{decwrl,mips,sgi}!llustig!david

lhsux@Sequoia.uucp (Lorne Schachter) (06/17/91)

In article <1991Jun17.050847.23968@llustig.palo-alto.ca.us> david@llustig.palo-alto.ca.us (David Schachter) writes:
>In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>>[UNIX] became popular because, at a critical time in the 70's, it was _free_
>>and _open_ and avalable on the _cheapest_ useful hardware: PDP-8/11 and VAXen.
>
>I don't believe any form of UNIX ran on the pdp8 line of computers.
>
>-- 
>                                               David Schachter

I think Ken and Dennis got started on an 8 (or maybe a 7), the released
system ran on an 11.

						Lorne Schachter
						(no relation, I think)

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/17/91)

In article <25791@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> So why do we have to stick with the _first_ one that became portable? 

Same reason we stick with c**p like the internal combustion and Fortran.
Too expensive to re-tool.

> Why not insist on a truly well designed, efficient, easy to use system
> - and then insist that _it_ be made portable.

Portability, like quality, is not something you can bolt on afterwards.

There are N teams out there trying to design better operating systems.
(The NeXT doesn't run UNIX, although it looks as if it did.
DEC were talking about providing a POSIX *interface* on top of VMS.
DEC have an experimental OS called TOPAZ, which sounds interesting.
And so it goes.)
The most convincing way for you to INSIST on a truly well designed
apple pie is with your MONEY.  Tell people what would make you evaluate
an operating system as "truly well designed and efficient and easy to
use", and tell them what you will PAY for it, and how many others feel
likewise.

> If you 
> "administer" your own machine, it takes a higher percentage of your 
> time than any other micro system I've seen (or, so I understand from
> friends of mine that do so).

I'm sure your friends are wonderful people, but I ran SunOS 3.5 on a
Sun-3/50 at home for a year, and never did *anything* to it except
switch it on and off (ok, so I made backups).  There's a charity I'm
in touch with that have an 80386 box running UNIX V.3.  System
administration?  They can't even spell it.  They can switch it on and
off, they can make backups on the floppy drive, and that's _it_.  I'm
still waiting for them to call me for help, and it has been 18 months.

This all started with a complaint about compiler listings.
It was observed that this is not an OS issue, it is a COMPILER issue.
It was further observed that there are UNIX Fortran compilers available
which DO make listing files.

As for me, what I want is a compiler which dumps the information into
a few relations so that I can extract precisely the information I want.
If it comes with a tool for generating listings from this, fine, as long
as I can turn the wall-paper machine OFF.  I had a gutful of listings
that went 10 times around the house 12 years ago.  Never again!
Give me Masterscope, I say!
-- 
Q:  What should I know about quicksort?   A:  That it is *slow*.
Q:  When should I use it?  A:  When you have only 256 words of main storage.

jlg@cochiti.lanl.gov (Jim Giles) (06/18/91)

In article <6373@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
|> In article <25791@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
|> > So why do we have to stick with the _first_ one that became portable? 
|> 
|> Same reason we stick with c**p like the internal combustion and Fortran.
|> Too expensive to re-tool.

All the more reason for those of us who are just switching _TO_ UNIX
to avoid doing so.  Expecially since what we are switching _FROM_ is
already better.

|> [...]
|> > Why not insist on a truly well designed, efficient, easy to use system
|> > - and then insist that _it_ be made portable.
|> 
|> Portability, like quality, is not something you can bolt on afterwards.

The UNIX is really a doom of major proportions.  You are saying that it
can _never_ be modified to be quality environment.

|> > If you 
|> > "administer" your own machine, it takes a higher percentage of your 
|> > time than any other micro system I've seen (or, so I understand from
|> > friends of mine that do so).
|> 
|> I'm sure your friends are wonderful people, but I ran SunOS 3.5 on a
|> Sun-3/50 at home for a year, and never did *anything* to it except
|> switch it on and off (ok, so I made backups).  [...]

I have absolutely _NO_ experience with standalone UNIX boxes.  So, from
your testamonial, I can only assume that the major problems arise either
from networking or system upgrades or both.  If you run a standalone
system, you can decide not to upgrade until the _new_ system offers
improvements that you desire - in a networked environment, one machine
upgrades, they pretty much all have to.  That's the major source of
grief from my perspective - every Sun OS upgrade makes the system 
slower (and brings my workstation down for 1-2 days during the upgrade).
The thing that most of the "system administrators" seem to spend most of
their time worrying about is the network - who knows why.

J. Giles

dmturne@PacBell.COM (Dave Turner) (06/18/91)

In article <1991Jun17.112423.8970@porthos.cc.bellcore.com> /devel/develop1.0/user@hercules.UUCP (Lorne Schachter) writes:
>>I don't believe any form of UNIX ran on the pdp8 line of computers.
>
>I think Ken and Dennis got started on an 8 (or maybe a 7), the released
>system ran on an 11.

Here are the words of Ritchie and Thompson:

	"  There have been four versions of the UNIX time-sharing system.
	The earliest (circa 1969-70) ran on the Digital Equipment Corpora-
	tion PDP-7 and -9 computers. The second version ran on the unpro-
	tected PDP-11/20 computer. The third incorporated multiprogram-
	ming  and ran on the PDP-11/34, /40, /45, /60, and /70 computers;
	it is the one described in the previously published version of this
	paper, and is the most widely used today. This paper describes
	only the fourth, current system that runs on the PDP-11/70 and the
	Interdata 8/32 computers."

Quoted from "The UNIX Time-Sharing System" by D.M. Ritchie and K. Thompson
in BSTJ July/August 1978 Vol. 57, No. 6, Part 2.  The earlier paper
appeared in Communications of the ACM, 17, No. 7 (July 1974), pp. 365-375.


-- 
Dave Turner	415/823-2001	{att,bellcore,sun,ames,decwrl}!pacbell!dmturne

jms@unix386.Convergent.COM (John Sully) (06/18/91)

jlg@cochiti.lanl.gov (Jim Giles) writes:

>As for expense: it is becoming clear (from my experience anyway)
>that UNIX is one of the most expensive systems to install and maintain
>of any that I've seen.  This is true of both mainframes and smaller 
>machines like workstations.  I'm not aware of any other system on micros
>which requires full-time employees - one per few-dozen machines or so - 
>to be "system administrators" like UNIX does.  (I don't know what these
>people do, and I don't want to know.  They always seem to be overworked
>and the only time I see _any_ effect of their activities is when they
>accidentally break something and bring my workstation down.)  If you 
>"administer" your own machine, it takes a higher percentage of your 
>time than any other micro system I've seen (or, so I understand from
>friends of mine that do so).  How is this an advantage?

I have to disagree here.  I run UNIX on my workstation an maintain it
myself.  After setting up news, mail, networking and RFS, it really takes
very little of my time to maintain; really no more time than it take to
make backups.  

I a prior job I maintained a small network (~12) of UNIX machines and found 
that it really took no more time than that necessary to do backups in normal
circumstances.  The problem arises when you have hardware or cable problems
in a network.  Then trouble shooting can take quite some time, but this is
not the fault of the OS you are using as it is just a fact of life that
hardware is going to break.  When a system administrator is responsible for
large numbers of machines and peripherals, there is almost always something
wrong with one machine or another, and that is why they are overworked.

--
John M. Sully                      
Unisys Corporation                 
2700 N. First St.                  
San Jose, CA 95150                 
                                   
Phone : (408) 435-3129             
E-Mail: jms@unix386.convergent.com 

jlg@cochiti.lanl.gov (Jim Giles) (06/18/91)

In article <1991Jun16.184815.17898@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
|> [...]
|> As for unix being free:  when you bought a vax, you bought a license for
|> VMS.  It's kinda silly to argue that unix is free, considering that unix had
|> to be ported, while vms was already there for the cost of the machine.

My comment was that UNIX was _free_ and _open_.  Further, I gave another
criterion later - it was available without a lag for development time.
The "and" in the phrase "_free_ and _open_" is a conjunction, not a 
disjuction.  VMS didn't satisfy that criterion.  In fact, for schools,
the _open_ criterion was the most important one.

And, when VAXen came out, sure UNIX had to be ported, but most schools 
continued to use (and buy) PDP-11s until after that port had been 
completed.  So, as for "already there", that's what it was for _most_ 
schools who eventually bought VAXen.

We'd all be better off now if the schools had mostly decided to develop
their own systems peicemeal - by now some system with real _quality_
would probably have shaken out of the competition between such separate
developments.  One of the recognized pitfalls of designing things for
human use is the problem of standardizing to soon.*  That's what happened
with operating systems.

*"The Psychology of Everyday Things"; Norman, Donald A.; Basic Books;
1988.  I recommend it.  Of course, nearly everything in UNIX violates
the principles espoused by this book.

J. Giles

tim@ohday.sybase.com (Tim Wood) (06/18/91)

In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>
>(I don't know what [ system administration personnel ]
>do, and I don't want to know.  They always seem to be overworked
>and the only time I see _any_ effect of their activities is when they
>accidentally break something and bring my workstation down.)  
>

Too bad you don't have a greater appreciation of system admin.  Have you
ever sent or received mail?  Have you ever dialed out on a modem under
UNIX?  Have you ever had a file restored?  Have you ever wondered how
machines get on the network?  Do you have any notion of shared computing
resources?  If it weren't for system admin people, you
would likely be hacking on an isolated machine with files at the mercy of
the first power or disk failure to happen.  Open the old eyes...
-TW
---
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608	  415-596-3500
WORK:tim@sybase.com     {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
PLAY:axolotl!tim@toad.com		       {sun,uunet}!hoptoad!axolotl!tim
Dis claim er dat claim, what's da difference?  I'm da one doin da talkin' hea.

sef@kithrup.COM (Sean Eric Fagan) (06/18/91)

In article <25849@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>I have absolutely _NO_ experience with standalone UNIX boxes.  

Therefore you are not equipped to judge them.  So shut up about them.

>So, from
>your testamonial, I can only assume that the major problems arise either
>from networking or system upgrades or both.  

I've run non-standalone *nix machines, some with lots of users, some with
only one or two.  All have had networking.  My home computer in on a
network, and runs *nix.  My administration consists of:  reading mail sent
to system accounts, deciding 99% of it is just informative stuff that I
don't need to do anything about, and deleting it.  The last thing I had to
do anything about was when news told me that it couldn't write to a
directory, and that was because I'd misconfigured news (silly me).

System administration varies from unix system to unix system.  It is a part
of the system, but is no longer a part of UNIX(tm).  (Some machines don't
even use /etc/passwd for account names.  No more standards in that respect,
although it will, hopefully, change if POSIX can come up with a decent
administration standard that everyone likes and/or can live with.)

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

dylan@ibmpcug.co.uk (Matthew Farwell) (06/18/91)

In article <13331@sybase.sybase.com> tim@ohday.sybase.com (Tim Wood) writes:
>In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>>(I don't know what [ system administration personnel ]
>>do, and I don't want to know.  They always seem to be overworked
>>and the only time I see _any_ effect of their activities is when they
>>accidentally break something and bring my workstation down.)  
>
>Too bad you don't have a greater appreciation of system admin.  Have you
>ever sent or received mail?  Have you ever dialed out on a modem under
>UNIX?  Have you ever had a file restored?  Have you ever wondered how
>machines get on the network?  Do you have any notion of shared computing
>resources?  If it weren't for system admin people, you
>would likely be hacking on an isolated machine with files at the mercy of
>the first power or disk failure to happen.  Open the old eyes...

I always think the definition of a good sysadmin is someone you don't notice
is there, because he prevents all of the crises...

Dylan.
-- 
Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan
	But you're wrong Steve. You see, its only solitaire.

peter@ficc.ferranti.com (Peter da Silva) (06/19/91)

In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
> Nope.  That's an after effect.  The _reason_ UNIX became popular was for
> no _technical_ advantage at all.  It became popular because, at a critical
> time in the 70's, it was _free_ and _open_ and avalable on the _cheapest_
> useful hardware: PDP-8/11 and VAXen.

Jim, you don't help your argument by making major technical blunders. UNIX
has never run on a PDP-8. It ran on the PDP-11, and the earliest ports were
actually to other 16-bit minicomputers like the Interdata. The VAX at that
time was *not* a cheap machine.

But what has made *commercial* versions of UNIX popular is because it's
the first widely available O/S (and there are other machine independent
systems... I luckily avoided a chance at working on one in COBOL in 1979)
to have a simple API. There are no more than 35 system calls that define
the behaviour of the UNIX kernel... which is a major breakthrough. The
programmer's reference manual fit in one volume! Amazing!

Sure, it has technical limitations. But these are correctable. The basic
design is sound.

> I would agree _if_ the common environment showed _any_ quality in its
> design or implementation.

The basic design of the *interface* that is the real core of UNIX is realy
quite good. The implementations have not always been up to the same quality,
though some of the weirder design decisions do seem in retrospect not quite
so bad: compare the performance of V7 with MINIX: they both have the same API,
but MINIX's single-threaded filesystem really hurts multitasking disk I/O.
An *efficient* message-passing kernel is a far more complex beast.

> The _same_ argument could be advanced in favor of _any_ portable system.
> So why do we have to stick with the _first_ one that became portable? 

We didn't. The first one was Forth.

> I'm not aware of any other system on micros
> which requires full-time employees - one per few-dozen machines or so - 
> to be "system administrators" like UNIX does.

I don't know of any other system on micros that provides usable multiuser
support. I know that multiuser MS-DOS environments (netyworks) do require
full-time support. I also know that our other multiuser systems here at
Ferranti (VAXes and Sperry mainframes) require as much support... and don't
get anywhere near the variety of users.

The main problem with your workstation, if it's at all typical, is that it's
running a version of UNIX that has had no work on improving the system
administration side of things in 10 years. It's a BSD-based system, right?
Probably a Sun. We have a couple of those, and they're nightmares compared
to our modern System V, or even our older System III, based systems.

Yes, your DOS PC doesn't require as much support, so long as you just leave
it in isolation. But then it doesn't do much.

> If you 
> "administer" your own machine, it takes a higher percentage of your 
> time than any other micro system I've seen (or, so I understand from
> friends of mine that do so).  How is this an advantage?

Try administering a DOS network some time. We have as many people working to
support our PCs as all our Xenix systems combined... and they have far
fewer users.

Excuse me... I have to go install some networking software on a DOS PC. This
will be about the fourth attempt, and I don't expect it to work. I may have
to go back to an earlier version of the network, because I can't upgrade it to
the latest version of DOS because other software on the system won't support
it.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

peter@ficc.ferranti.com (Peter da Silva) (06/19/91)

In article <1991Jun17.112423.8970@porthos.cc.bellcore.com> /devel/develop1.0/user@hercules.UUCP (Lorne Schachter) writes:
> I think Ken and Dennis got started on an 8 (or maybe a 7), the released
> system ran on an 11.

It was a 7. And it was a *very* minimal system. Just enough to play Space
War.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

peter@ficc.ferranti.com (Peter da Silva) (06/19/91)

In article <25855@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
> We'd all be better off now if the schools had mostly decided to develop
> their own systems peicemeal

They mostly did, well into the '80s. SAIL and ITS, for example. Berkeley
did their own variant of NOS for the Cyber series. Home grown operating
systems were a dime a dozen. UNIX *replaced* these, because it was easier
to maintain and, more importantly, teach.

> One of the recognized pitfalls of designing things for
> human use is the problem of standardizing to soon.*  That's what happened
> with operating systems.

Yep. That's why we're stuck with IBM-PCs and MS-DOS.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

dennisc@tigger.Colorado.EDU (Dennis Colarelli) (06/20/91)

In article <25855@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>
>*"The Psychology of Everyday Things"; Norman, Donald A.; Basic Books;
>1988.  I recommend it.  Of course, nearly everything in UNIX violates
>the principles espoused by this book.
>

From the chapter "Cognitive Engineering", in "User Centered System Design,
New Perspectives on Human-Computer Interaction", Norman writes about UNIX:

	The underlying philosophy is to provide a number of small, carefully
	crafted operations that can be combined in a flexible manner under
	the control of of the user to do the task at hand.  It is something
	like a construction set of computational procedures. 
	...the interface has good ideas...
	Elsewhere I have scolded it for its shortcomings, but we should not
	overlook its strengths.

--------------------
Dennis Colarelli

jlg@cochiti.lanl.gov (Jim Giles) (06/21/91)

In article <RI0CQT5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> [...]
|> The basic design of the *interface* that is the real core of UNIX is realy
|> quite good. [...]

To be sure, the system interface is much better than the shell/tools 
level of the system (I regard _both_ levels as part of the system
because _both_ are meant by most UNIX supporters).  But, there are
_obvious_ deficiencies:

  No way to bypass the system's I/O buffers - even though sophisticated
     users often need to do so for efficiency. This also makes real-time
     programming a bitch.

  No asynchronous I/O.  Though this is a common _extension_ to UNIX,
     no two extensions do this the same way.  And the most common UNIXes
     don't allow it at all.

  The lseek() call is a separate system call.  So, programs doing random
     I/O must spen roughly twice the system overhead by making _two_
     system calls for each I/O request.  (The seek address should be
     an optional argument to the read/write system calls.)

  Signals are not stacked.  That is, if more than one of the same signal
     arrives before the program has a chance to handle one, the program
     will only recieve _one_.

  Most security people I know regard the very _concept_ of SUID to be
     inherently insecure.  Apparently, any new SUID program added to a
     system will invalidate a B-level security rating until you're
     recertified with the new SUID program in place.

  Etc..  The list is _long_.

|> [...]
|> I don't know of any other system on micros that provides usable multiuser
|> support.  [...]

I _still_ don't.  The idea of more than one user on a microprocessor
version of UNIX is ludicrous - and irrelevant to this discussion.
If you're comparing single-user systems, UNIX loses because it's got
so much system overhead and allows so little user freedom (ie. the 
system does lots of scheduling abd other decisions that a single-user
system should let the user have some control over).  If you're talking
multi-user systems, UNIX is just not as good as several of the other
mainframe systems available - including some with UNIX look-alike 
kernel interfaces (which, thankfully, can be bypassed on such systems
to get at some _real_ power).

|> [...]
|> Yes, your DOS PC doesn't require as much support, so long as you just leave
|> it in isolation. But then it doesn't do much.

Depends on what you mean by "doesn't do much".  It does _more_ as a
single-user system.  There are (I'm told - I've never seen them) tools
available on UNIX to do text manipulation and other things as well as
my DOS system at home does them.  They are all expensive, second-source
tools.  Most of them are actually transplants _from_ DOS or Apple/MACs.
The same software is cheaper for the DOS machines and does the same job.

For real horsepower, I might use my Sun (except that I have Crays at
my disposal).  But, for this kind of application, UNIX is more a burden
than a blessing.  I want to get around it more often than use the "tools"
I'm intended to use.

J. Giles

jlg@cochiti.lanl.gov (Jim Giles) (06/21/91)

In article <WI0CX-5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> In article <25855@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> [...]
|> > One of the recognized pitfalls of designing things for
|> > human use is the problem of standardizing to soon.*  That's what happened
|> > with operating systems.
|> 
|> Yep. That's why we're stuck with IBM-PCs and MS-DOS.

"Everyone knows that IBM set microcomputing back at least 5 years", so
said an add for a magazine that I immediately subscribed to for making
that very statement.  Now, unfortunately, UNIX is doing the same thing 
to operating systems, but its aim is more ambitious - 15 years is the
setback it is accomplishing.

J. Giles

scottl@convergent.com (Scott Lurndal) (06/21/91)

In article <RI0CQT5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> In article <25791@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> > Nope.  That's an after effect.  The _reason_ UNIX became popular was for
|> > no _technical_ advantage at all.  It became popular because, at a critical
|> > time in the 70's, it was _free_ and _open_ and avalable on the _cheapest_
|> > useful hardware: PDP-8/11 and VAXen.
|> 
|> Jim, you don't help your argument by making major technical blunders. UNIX
|> has never run on a PDP-8. It ran on the PDP-11, and the earliest ports were
|> actually to other 16-bit minicomputers like the Interdata. The VAX at that
|> time was *not* a cheap machine.
|> 
Truth, as the VAX didn't exist when UNIX was developed (except as a gleem
in Ken Olson's eye).

To quote the BSTJ, Vol 57, No 6, Part 2:

pp 1899:  The UNIX story begins with Ken Thompson's work on a cast-off 
	  PDP-7 minicomputer in 1969.  [...]

pp 1900:  Until mid-1977, the UNIX operating system and its variants ran
	  only on computers of the Digital Equipment Corporation PDP-11
	  family.  In an interesting exercise in portability, Johnson 
	  and Richie exploited the machine-independence [really! -ed] 
	  of C to move the operating system and the bulk of its software
	  to a quite different Interdata machine.

amos@SHUM.HUJI.AC.IL (amos shapir) (06/21/91)

[Quoted from the referenced article by sef@kithrup.COM (Sean Eric Fagan)]
>In article <25849@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>>I have absolutely _NO_ experience with standalone UNIX boxes.
>
>Therefore you are not equipped to judge them.  So shut up about them.
>

We've already been through this very argument, with the same participants, in
other groups.  The conclusion seems to be that:
- Jim Giles doesn't like buses; they're big, noisy, smelly, and almost
 impossible to park;
- Jim Giles has never had any need to drive a bus, doesn't know how
 to drive one, nor wishes to learn;
- Therefore, Jim Giles believes nobody should ever make, drive, or ride in
 a bus.

More to the point: UNIX is far from perfect, and I'll gladly replace it
with anything else that's as versatile, cheap, and - most important - as
easy to port to any new architecture.

-- 
	Amos Shapir		amos@cs.huji.ac.il
The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
Tel. +972 2 585138 GEO: 35 11 46 E / 31 46 21 N

numb@dcs.qmw.ac.uk (Matt Newman) (06/21/91)

In <25849@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

[ stuff deleted ]

>upgrades, they pretty much all have to.  That's the major source of
>grief from my perspective - every Sun OS upgrade makes the system 
>slower (and brings my workstation down for 1-2 days during the upgrade).
>The thing that most of the "system administrators" seem to spend most of
>their time worrying about is the network - who knows why.
>J. Giles

Network installs of SunOS have usually taken between 45mins and 3 hours
depending on the system, personally I find SunOS installs dead easy, as
long as you approach them in a methodical way.
--

Matt Newman

jlg@cochiti.lanl.gov (Jim Giles) (06/21/91)

In article <1431@shum.huji.ac.il>, amos@SHUM.HUJI.AC.IL (amos shapir) writes:
|> [...]
|> We've already been through this very argument, with the same participants, in
|> other groups.  The conclusion seems to be that:
|> - Jim Giles doesn't like buses; they're big, noisy, smelly, and almost
|>  impossible to park;
|> - Jim Giles has never had any need to drive a bus, doesn't know how
|>  to drive one, nor wishes to learn;
|> - Therefore, Jim Giles believes nobody should ever make, drive, or ride in
|>  a bus.

An interesting analogy.  However, your conclusion is wrong.  The line
beginning "Therefore" should read:

   Therefore, Jim Giles believes that no one should force the use of busses  
   onto other drivers.  Nor should anyone convince powerful political 
   organizations that busses are the only type of vehicle that should
   be allowed on the road (such as the NSF being hoodwinked into only
   supporting software development on UNIX).  Nor does Jim Giles believe
   that anyone who makes extravagantly exaggerated claims about the speed,
   efficiency, capacity or driving ease of busses should be allowed to get 
   away with it unchallenged.

As a bus, UNIX is more like a minivan with too few seats and badly in need
of a major engine overhaul.

J. Giles

shore@theory.TC.Cornell.EDU (Melinda Shore) (06/22/91)

In article <numb.677519716@guinness> numb@cs.qmw.ac.uk writes:
>personally I find SunOS installs dead easy, as
>long as you approach them in a methodical way.

You're probably over-constraining the problem :-)
-- 
                    Software longa, hardware brevis
Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edu

jlg@cochiti.lanl.gov (Jim Giles) (06/22/91)

In article <1991Jun20.104642.27164@colorado.edu>, dennisc@tigger.Colorado.EDU (Dennis Colarelli) writes:
|> [...]
|> From the chapter "Cognitive Engineering", in "User Centered System Design,
|> New Perspectives on Human-Computer Interaction", Norman writes about UNIX:
|> 
|> 	The underlying philosophy is to provide a number of small, carefully
|> 	crafted operations that can be combined in a flexible manner under
|> 	the control of of the user to do the task at hand.  It is something
|> 	like a construction set of computational procedures. 
|> 	...the interface has good ideas...
|> 	Elsewhere I have scolded it for its shortcomings, but we should not
|> 	overlook its strengths.

Yes, and I suppose if I were to heap a great deal of abuse on, say, 
Hitler except at one point I say "but he does have a cute little
Charlie Chaplin mustache," you would probably quote that as my main
thoughts on the subject of Hitler!

Yes, UNIX has a number (a _HUGE_ number) of small utilities.  A very
_few_ of them are carefully crafted.  Pipes are a very limited and
inflexible form of interprocess communication, but they do allow
pretty much arbitrary linking together (rather inefficiently) of 
these tools.  The interface _does_ have good ideas - _IF_ they had
been applied with consistency, _IF_ they provided a complete range 
of functionality, _IF_ they had assured correctness, etc..

The fact that someone says that a produce has _some_ good ideas is not
to be taken as a recommendation of the product.  Usually this kind of
statement is an attempt to bend over backward for something nice to 
say about the product.  From Norman's other statements about UNIX, I
suspect that may be the case here.  (By the way, Hitler's mustache _IS_
about the only nice thing I can thing of about him - and most of the
time I actually regard it as a mark against Chaplin instead.)

J. Giles

gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (06/22/91)

In article <26202@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>.  Nor should anyone convince powerful political 
>   organizations that busses are the only type of vehicle that should
>   be allowed on the road (such as the NSF being hoodwinked into only
>   supporting software development on UNIX).

Gee, I never even realized that I, as a user of an NSF supercomputer
center, was hoodwinked into prefering Unix over CTSS by a powerful
political organization.

Thanks for pointing that out.

gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) (06/22/91)

In article <26202@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
#   Nor should anyone convince powerful political 
#   organizations that busses are the only type of vehicle that should
#   be allowed on the road (such as the NSF being hoodwinked into only
#   supporting software development on UNIX).

If the NSF has been "hoodwinked" into support software development
exclusively under Unix, then why has one of our faculty members, who
has a perfectly adequite color Sun workstation, had to buy an
expensive Macintosh in order to run a software package that could not
be run under Unix?

I think you are letting your prejudices blind your logic.


--
-Greg Hennessy, University of Virginia
 USPS Mail:     Astronomy Department, Charlottesville, VA 22903-2475 USA
 Internet:      gsh7w@virginia.edu  
 UUCP:		...!uunet!virginia!gsh7w

bernie@metapro.DIALix.oz.au (Bernd Felsche) (06/22/91)

In <26207@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>Yes, UNIX has a number (a _HUGE_ number) of small utilities.  A very

And you only have to learn about the ones you have to use.

>_few_ of them are carefully crafted.  Pipes are a very limited and

What's so complicated about "cat" for example, that requires careful
crafting? If the only replacement part for your car was a new car,
you'd be upset, wouldn't you? Even if you only want to replace a fuse?

UNIX is the programmer's constructor set. Lots of little bits with
well tuned functions, and pieces held together by the operating
system.

>inflexible form of interprocess communication, but they do allow
>pretty much arbitrary linking together (rather inefficiently) of 

Pipes allow data to flow from one filter to another. They do what they
do in the best possible way in which they can be implemented on a
particular machine. The "inflexibility" you refer to is ludicrous.
What more can you expect of a pipe than to allow data to flow from one
point to another.

>these tools.  The interface _does_ have good ideas - _IF_ they had
>been applied with consistency, _IF_ they provided a complete range 
>of functionality, _IF_ they had assured correctness, etc..

I know of no other operating system which comes close to an "ideal"
programming environment.

>The fact that someone says that a produce has _some_ good ideas is not

UNIX is more of a theology than product. :-)
-- 
Bernd Felsche,                 _--_|\   #include <std/disclaimer.h>
Metapro Systems,              / sold \  Fax:   +61 9 472 3337
328 Albany Highway,           \_.--._/  Phone: +61 9 362 9355
Victoria Park,  Western Australia   v   Email: bernie@metapro.DIALix.oz.au

mike@bria.UUCP (mike.stefanik) (06/23/91)

In an article, jlg@cochiti.lanl.gov (Jim Giles) writes:
|"Everyone knows that IBM set microcomputing back at least 5 years", so
|said an add for a magazine that I immediately subscribed to for making
|that very statement.  Now, unfortunately, UNIX is doing the same thing 
|to operating systems, but its aim is more ambitious - 15 years is the
|setback it is accomplishing.

Prove it.  I want to see objective, quantitative proof of your assertion.
Jim, all I have been seeing you do is whine, moan, bitch and complain about
UNIX -- something which you demonstrate a remarkably limited knowledge of.
So why don't you quit flapping your gums and put up or shut the hell up?

-- 
Mike Stefanik, MGI Inc., Los Angeles -- Opinions stated are never realistic!
"To sin by silence when they should protest makes cowards out of men." -Lincoln

flee@cs.psu.edu (Felix Lee) (06/23/91)

>What's so complicated about "cat" for example, that requires careful
>crafting?

Well, first there's the basic issue of whether cat should have any
options.  SunOS has two cats with five and seven options.  Research
Unix (tenth edition) has a cat with no options---rather than saying
things like "cat -v" you use a different command like "vis" (which
also has no options).

What happens if you say "cat a > a" or "cat a >> a"?

Does "cat -s" squeeze blank but non-empty lines?

Does "cat -v" understand locale and language?

Should you be able to undo "cat -v" with an inverse tool?

Should the filename "-" mean standard input or is /dev/fd/0
sufficient?

Does cat buffer I/O?

Should cat use mmap()?  How much of a file should it mmap() at a time?

Does cat preserve record and block boundaries?
Can you say "cat /dev/tape1 > /dev/tape2" to copy a tape?
How about "cat /dev/disk1 > /dev/disk2"?

Should cat use a pool of buffers when reading or writing to slow
devices?

>What more can you expect of a pipe than to allow data to flow from
>one point to another.

Pipes are terrible for communicating structured data.  Perhaps rather
than streams of bytes, programs should be passing streams of ASN.1.

Pipes are terrible for communicating large amounts of data.  If I have
a large structure I need to send perhaps I'd stuff it in its own
segment, attach a capability, and pass the capability around.

>UNIX is more of a theology than product. :-)

Quite.  Which sect do you belong to?
--
Felix Lee	flee@cs.psu.edu

peter@ficc.ferranti.com (Peter da Silva) (06/25/91)

Seems more like "Jim Giles had a bad experience with an old beat-up
greyhound bus that made an extended trip a living hell, and thus believes
that anything larger than a passenger car is unsuitable for individual
drivers. Minivans included".
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

peter@ficc.ferranti.com (Peter da Silva) (06/25/91)

In article <pe9Hc?7+@cs.psu.edu> flee@cs.psu.edu (Felix Lee) writes:
> What happens if you say "cat a > a" or "cat a >> a"?

Horrible things, like what happens if you hook the output of your
amplifier to the input.

> Does "cat -s" squeeze blank but non-empty lines?

No such option should exist.

> Should you be able to undo "cat -v" with an inverse tool?

No such option should exist.

> Should the filename "-" mean standard input or is /dev/fd/0
> sufficient?

/dev/fd/0 is sufficient.

> Does cat buffer I/O?

	while((nread = read(...)) > 0)
		write(...);

You forgot: How big is the buffer size?

	At least 64K.

> Should cat use mmap()?

If so, should not be detectable from the user's standpoint.

> How much of a file should it mmap() at a time?

If you perform that optimisation, you're responsible for figuring that out.

> Does cat preserve record and block boundaries?

If it uses the loop above, yes.

> Can you say "cat /dev/tape1 > /dev/tape2" to copy a tape?

Depends on the largest block in the tape.

> How about "cat /dev/disk1 > /dev/disk2"?

Yes.

> Should cat use a pool of buffers when reading or writing to slow
> devices?

If so, it should be transparent to the user.

> >What more can you expect of a pipe than to allow data to flow from
> >one point to another.

> Pipes are terrible for communicating structured data.  Perhaps rather
> than streams of bytes, programs should be passing streams of ASN.1.

Streams have problems with structured data... you basically have to impose
your own format on the stream. Pipes are nice, but have their limitations.
But for script programming I don't know of any better tool.

> >UNIX is more of a theology than product. :-)

> Quite.  Which sect do you belong to?

UNIX is an API.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"