Why do Unix people gag at VMS?
tihor at acf4.UUCP
tihor at acf4.UUCP
Sat Nov 24 06:13:00 AEST 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.
More information about the Comp.unix
mailing list