Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!linus!philabs!cmcl2!acf4!tihor
From: tihor@acf4.UUCP
Newsgroups: net.unix
Subject: Re: Why do Unix people gag at VMS?
Message-ID: <12700013@acf4.UUCP>
Date: Fri, 23-Nov-84 15:13:00 EST
Article-I.D.: acf4.12700013
Posted: Fri Nov 23 15:13:00 1984
Date-Received: Sun, 25-Nov-84 04:08:22 EST
References: <361@gitpyr.UUCP>
Organization: New York University
Lines: 41
Nf-ID: #R:gitpyr:-36100:acf4:12700013:000:2263
Nf-From: acf4!tihor    Nov 23 15:13:00 1984


	My colleagues do not like the idea of being tied down to
	one type of interprocess communication (the pipe) 

Sad but true.  The standard Unix's do not support as right a selection 
of IPC mechanisms, in large part I believe because Unix was not designed
for Real Time programming whereas VMS having grown out of RSX had several
generations of Real-Time facilities builtin.   Several versions of Unix 
have at least one other IPC mechanism, so if you aren't too concerned
about portability you can have two.  And of course if you have source
you can add whichever of {Shared Memory, Common EVent Flags, Shared 
Mailboxes (aka named pipes/fifo's), etc} are needed.

						           or the fact that
	so many sub-processes are spawned when executing relatively trivial
	tasks.  

True but not as imprortant as it sounds since Unix is optimized for 
quick process creation relative to VMS.  Large number of processes 
connected by narrow channels was a reasonable approach to overcome the
small address space of the PDP-11 et al, it is not a necessary tool
for large virtual address space enviornments like the VAX though it
is still has the virtues of simplicity.  ( And it is still a useful model
for tightly coupled multimicroprocessor systems.)

		Does unix trade-off efficiency for elegence?  

And for portability.  But a key question to ask is "What are the real needs
of your user community?"  If you can only address those needs economically
with a IBM 3081 running MVS then you should grin and bear it.  We have 
a variety of systems here supported by a small systems group.  Different
communities need different things.  Our number crunchers need a good 
Fortran and not too much more, a lot of people use large tools that are 
only available for a few types of systems, so we have to support them 
at that.  Aside from some folks who believe in Unix witha deep and religious
ferver its greatest value is that if we have a Brand X supermini forced on
us for reasons of price/performance we can minimize the support cost 
and the communications load by insiting that it support BSD 4.2 and IP/TCP
over an ether.  Of course only one out of three is doing a decent job
of it (Pyramid) but the other's keep promising it (even advertising it)
Real Soon Now.