Favorite operating systems query
s...@valid.uucp
Multics, and that Honeywell's customers are screaming and hollering. The
reason this was interesting to me is that Multics, like UNIX(TM), is a
``cult'' operating system, by which I mean that it has a hard core of
rabid, fanatical defenders. (Of course, none of us on the net is a drooling
OS groupie; we all have sound technical reasons for preferring some
systems to others.)
For the last few years I've been a UNIX (ahem) user/fan/implementor, but
recently my work -- I'm maintaining a schematics editor -- has led me
into VMS. Now, to me, VMS is "just another vendor-supplied operating
system." I don't like it as well as I like UNIX, but then again, I
don't know it as well as I know UNIX, either. However, I've recently
heard that there is a breed of VMS partisan every bit as intense as
the most stalwart UNIX die-hard. So, finally to get round to the point,
I have some questions:
1) For the VMS fans out there: what's your favorite feature(s) of
the system? Why do you like it? How does it help you?
2) Likewise UNIX and Multics fans. (How do I get to a Multics
site? I'm not on the MILnet...)
3) For anybody out there: what's your favorite system, or most
fondly remembered, or the one you were most fanatical about?
Why did you like it so much?
Part of my reasons for posting are individual: I'm interested in learning
more about VMS so that I can do my job better. But I'm also interested
in the sociology of the thing, and if you are too, post or mail me.
"After changes upon changes, we are more or less the same."
-Paul Simon.
S.
(TM)UNIX is a trademark of AT&T Bell Laboratories.
VMS is a trademark of the Digital Equipment Corporation.
Larry McVoy
>
> 1) For the VMS fans out there: what's your favorite feature(s) of
> the system? Why do you like it? How does it help you?
I think that the main complaints with Unix from VMSites are
1) the BSD fortran compiler is the worst excuse for a compiler the world has
ever seen (reports of 4 to 400 times slower than VMS fortran).
2) Related to (1), VMS fortran is a SUPERSET of ANSI Fortran 77 *and* is the
defacto scientific standard. There are very few scientific research
centers (remember science includes physics, math, chemistry; computer
science is only questionably a science) that don't have Vaxen running VMS
with the VMS fortran compiler. A great deal of established software depends
on the extensions provided by DEC.
3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity.
*Large* DCL programs exist (my father who is a physicist has a modelling
program with an enormous dcl frontend, like 10-15K lines. Unfortunately,
stuff like this is not uncommon). This could be solved by writing a dcl-like
shell.
4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs
interface to emulate EDT.
5) Real time support. Other than Masscomp's RTU, VMS is the only company that I
know of which supplies real time support.
[From here on out they are my personal complaints; 1-5 were complaints that I
have to listen to everytime I bump into a VMS person. They are as of yet
blissflly ignorant of #6].
6) File system. Why, oh, why, must the Unix file system be so fragile? VMS
never loses your files. And it's faster to boot up. I have no idea what
the difference is in design but somebody ought to have a look & see what
could be done.
7) IPC. Shared memory, sockets, pty's, pipes, ioctls all over the place. And
the only one that's not been hacked in as an after thought is pipes. IPC in
Unix bytes the giant weenie. Talk to the guys at CMU, they've got all kinds
of literature defending Mach based on this (and other design) problems.
8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You
damn near can't survive without source because you're always fixing
something. DEC has never handed out VMS src. Unix is the ultimate example
of "the quick fix solution"; those solutions always turn out to be wrong
in the long run (trust me, this is the voice of experience talking. Sigh).
9) Related to (7), networking support. Sockets are gross. This isn't just
my opinion, ask the DoD what they think of sockets. Remote filesystems,
remote devices, etc, are all being kludged in by every OEM in the field.
Have fun trying to make them all work together. Design? We don't need no
stinkin' design, we got 10,000 lines of code.
OK, now that I've got all the fanatics foaming at the mouth, let me throw in my
disclaimer. I've been a Unix fanatic myself for the past 4 years. I'm just
not blind to the problems that exist in Unix. As a research vehicle, as a
development system, it's the nicest thing I've ever used. However, I have
real problems recommending Unix as a "users" system. It needs a nursemaid
to survive properly. Read net.mail - every time the postmaster at some large
site leaves his job the mail gets all fouled up. What happened to programs
that run themselves, without being nursed? Unix has too much folklore &
guru-ness about it to be accepted into the mainstream.
--
Larry McVoy
-----------
Arpa: mc...@rsch.wisc.edu
Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry
"Just remember, wherever you go -- there you are."
-Buckaroo Banzai
M.HAAS
"just other vendor supported products". They all have been
or will be "de-supported". It doesn't matter a bit what
is good or better about any of them (unless, of course, there
is a good idea or two there to incorporate into the portable
operating systems - UNIX and PC-DOS). To have a favorite
among these is to be stuck with just what the single vendor
sells. Fine, if that suits your purposes now, but will it
in the future? Is it worth your professional future to be
expert in one of these albatrosses?
They have a saying in real estate, "Value is measured by three
factors: location, location, and location." A similar saying
in computing is, "Value is measured by three factors: portability,
portability, and portability."
Mel Haas , odyssey!mel
Jon Krueger
(Steven Brian McKechnie Sargent) writes:
> the system? Why do you like it? How does it help you?
My favorite VMS feature is its all-around functionality: you can put batch
streams, high-end number crunching, transaction processing, real-time data
acquisition and process control, document processing, graphics, simulation
and number crunching, database management, casual use and computer
education, highly interactive applications like spreadsheets and exploratory
data analysis, software developement, expert systems, network interface, and
so on through the entire gamut of applications ON A SINGLE MACHINE!
With networking and clustering, you can put all of the above on a single,
homogenous, manageable network or cluster. All your code will execute on
any node. Needs for speed can be balenced against price of a given node.
In other words, VAX is a good general-purpose computer, and VMS is a good
general-purpose operating system. You can buy one box, support your
applications and users under one environment, and stop there. The costs of
fragmenting applications and user communities are just too high to justify
any other way of doing business. The costs of maintaining a heterogeneous
network are currently high, but may drop someday, which will change the
picture.
Other bright stars in VMS world: the debugger, sharable object and image
libraries, the BACKUP, INSTALL, MONITOR, SYSGEN, ACCOUNTING, AUTHORIZE
utilitiies for system management and tuning, the common calling standard
(call a C run-time library routine and get printf from FORTRAN, COBOL,
assembler, PASCAL, run a mixed FORTRAN-C or FORTRAN-COBOL shop), the
transparency of file access in a DECnet.
> 2) Likewise UNIX fans.
My favorite Unix feature is vendor independence: getting cheaper, faster
hardware to execute all my software. VMS cost DEC a lot, and DEC has to
charge this back to its customers. Will Unix development and porting
continue to add functionality to Unix faster and cheaper than DEC's hardware
innovations can support cheaper copies of VMS? Probably. Right now, I see
advantages to either system.
Much of the chances for and rate of a swing to either system depends on the
vendor. If DEC comes out with more VAX options, gets more competetive on
hardware pricing, drops the BI bus fascism, and continues enhancing VMS, and
ATT continues to give non-3B2 boxes second-class citizenship as Unix hosts,
then Unix may end up being known as the first portable operating system, and
of great historical and zero commercial significance. If ATT doesn't try to
make us buy ATT hardware to get vmunix, but supports commodity hardware
markets based on their licensed software, and DEC continues its BI bus
childishness and hardware pricing, then VMS may end up as the last
proprietary operating system, of interest only to a small and unhappy group
of VAX owners.
Todd Aven
In article <3...@valid.UUCP> s...@valid.UUCP (Steven Brian McKechnie Sargent) writes:
>
> 1) For the VMS fans out there: what's your favorite feature(s) of
> the system? Why do you like it? How does it help you?
In article <4...@geowhiz.UUCP> mc...@rsch.wisc.edu (Larry McVoy) writes:
> I think that the main complaints with Unix from VMSites are
> 3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity.
> *Large* DCL programs exist (my father who is a physicist has a modelling
> program with an enormous dcl frontend, like 10-15K lines. Unfortunately,
> stuff like this is not uncommon). This could be solved by writing a dcl-like
> shell.
DCL (which stands for Digital Command Language) is, like /bin/sh and variants,
inappropriate for 10-15K programs. DCL, sh, csh, etc. are *interpreted*
languages, and hence are REAL SLOW. The reason that command languages are
used so widely is that one has no choice but to learn an operating system's
command language, while on the other hand most people trying to do research
hate like hell to learn a new programming language and will avoid it by writing
10-15K lines of command language 'script'. CLs are typically very forgiving
of syntactical mistakes, too. I don't quite understand what problem is to
be 'solved' by creating a DCL shell for UNIX, but I think that it would
be neither interesting nor useful. On the other hand, a UNIX shell for
VMS has been very helpful to me for those times that I just 'had to have a
pipe' (:-).
> 4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs
> interface to emulate EDT.
Why would anyone want the full-screen interface of EDT in GNU Emacs???
I admit that I use EDT, but ONLY in line mode for a quick one-line change.
I'm trying to get SED to work so I never have to touch EDT!
> [From here on out they are my personal complaints; 1-5 were complaints that I
> have to listen to everytime I bump into a VMS person. They are as of yet
> blissflly ignorant of #6].
My bliss is due to knowledge, not ignorance, of #6.
> 6) File system. Why, oh, why, must the Unix file system be so fragile? VMS
> never loses your files.
BULLSH*T! I take great offense to that comment, having once spent an entire
weekend trying to straighten out a royal mess. VMS allowed me to rename the
root directory to be a sub-directory somewhere else. I was an idiot for doing
it, but that proves that VMS is not idiot-proof. No OS is!
> And it's faster to boot up. I have no idea what
> the difference is in design but somebody ought to have a look & see what
> could be done.
By the time you added the UNIX equivalent to RMS (Record Management Services)
onto your favorite brand of UNIX, you'd have crashes as the rule, not the
exception. The difference in design is actually in the philosophy. VMS was
not so much designed *for* the VAX as it was designed *with* the VAX. The
basic VAX-11 processor was designed concurrently with it's operating system.
My best guess is that UNIX was designed for the user, and the guru's have
learned to tweak the source to the benefit of the machine.
> 8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You
> damn near can't survive without source because you're always fixing
> something. DEC has never handed out VMS src. Unix is the ultimate example
> of "the quick fix solution"; those solutions always turn out to be wrong
> in the long run (trust me, this is the voice of experience talking. Sigh).
Come now, where are you getting your information? VMS crashes when people
start poking into its guts as much as any other system (believe me!).
You can survive without VMS source by groaning and moaning and waiting for
the next release of VMS, which ain't so pleasant at times. But DEC absolutely
***DOES*** provide VMS source. It is distributed on microfiche under most
licensing agreements, and for a price (a BIG PRICE) you can buy it in
machine-readable form. As far as quick-fix solutions, I've written a few
for VMS. I've even written some based on information provided in the fiche.
> OK, now that I've got all the fanatics foaming at the mouth, let me throw in my
> disclaimer. I've been a Unix fanatic myself for the past 4 years. I'm just
> not blind to the problems that exist in Unix. As a research vehicle, as a
> development system, it's the nicest thing I've ever used. However, I have
> real problems recommending Unix as a "users" system. It needs a nursemaid
> to survive properly. Read net.mail - every time the postmaster at some large
> site leaves his job the mail gets all fouled up. What happened to programs
> that run themselves, without being nursed? Unix has too much folklore &
> guru-ness about it to be accepted into the mainstream.
Just in case anybody has gotten confused about which side I'm really on,
read on...
VMS is the nicest operating system I've ever used (out of a sample of
about 7, which isn't all that many). Period. I just wanted to clarify
and correct the points made in the parent articles. Most of the
complaints that I hear fro
Paul Campbell
respect for VMS, it has many good features no Unix has how ever I have to
disagree with Larry on some points.
In article <4...@geowhiz.UUCP> la...@geowhiz.UUCP (Larry McVoy) writes:
>
>6) File system. Why, oh, why, must the Unix file system be so fragile? VMS
> never loses your files. And it's faster to boot up. I have no idea what
> the difference is in design but somebody ought to have a look & see what
> could be done.
>
It is in reality almost as fragile as most Unix systems .... its just that the
system ALWAYS runs its own version of fsck when the system comes up after a
crash. It too looses files, trashes them and puts them in a "lost+found"
directory. VMS is more robust than Unix because it DOESNT have a block cache,
it writes through directly to disk. All buffering is done at the record level.
>8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You
> damn near can't survive without source because you're always fixing
> something. DEC has never handed out VMS src. Unix is the ultimate example
> of "the quick fix solution"; those solutions always turn out to be wrong
> in the long run (trust me, this is the voice of experience talking. Sigh).
>
DEC will sell you source for about the same price as AT&T (commercial price
that is). If you have support you get uptodate source listings on fiche ...
beleive me after you have typed in all of the print symbiont (in assembler)
paying for source seems like a much better idea ......
>9) Related to (7), networking support. Sockets are gross. This isn't just
> my opinion, ask the DoD what they think of sockets. Remote filesystems,
> remote devices, etc, are all being kludged in by every OEM in the field.
> Have fun trying to make them all work together. Design? We don't need no
> stinkin' design, we got 10,000 lines of code.
>
Here here, DECnet has a good user interface including particularly good support
for user servers and protection, a (relatively slow) distributed file system
comes with it. (I know I helped write a DECnet implementation ...)
Let me add my own pluses for VMS
+) It has a far better user memory management interface than Unix, many
things you can do under VMS are IMPOSSIBLE under Unix, unless you get
into the kernel of course
+) Much of the kernel is paged
And my one BIG minus about VMS
-) Processes are far too expensive. Many things we take for granted under
Unix are missing from or just too plain slow under VMS. The real
problem is two-fold
1) VMS processes carry around too much context
2) The manner of creating a new process is such that transfering
information from the old process is expensive. It happens
automaticly in a Unix fork()
On the whole I prefer Unix but I do find myself missing many features of VMS ...
Thats all folks ......
Paul Campbell
..!ucbvax!unisoft!paul
tho...@utah-gr.uucp
> ever seen (reports of 4 to 400 times slower than VMS fortran).
>
>3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity.
>4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs
> interface to emulate EDT.
See (3).
>6) File system. Why, oh, why, must the Unix file system be so fragile? VMS
> never loses your files.
I can count on the fingers of one foot the number of times I have lost a
file due to "file system fragility" in the last 5 years on a Unix
system. This "myth" is just that, and it's time to lay it to rest.
>8) Robustness. VMS almost *never* crashes. Unix crashes all the time.
See (6). Well, not quite that good. But the number of crashes not
related to something like device driver development or installation of a
half-baked remote file system has been VERY small at our site. I have
seen a Vax stay up between PMs (every three months).
Re: mail (one of your unnumbered comments). I think that a system that
requires a remote machine to be up in order for you to send mail to
someone on that system s**ks the big one. Maybe they've fixed it, but I
doubt it. I remember watching a friend in France trying to send mail to
Massachusetts, and having it fail because a connection couldn't be
established to the remote machine *at that time*. No queueing, just try
to send it later! Sheesh!
Also, when was the last time you could run VMS on a Sun, or an Apollo,
or a Gould, or a Pyramid, or a Cray, or ....
'Nuff said.
--
=Spencer ({ihnp4,decvax}!utah-cs!thomas, tho...@utah-cs.ARPA)
Jan Steinman
>VMS, Multics, MVS, CMS, Kronos, TOPS-10, Ibsys, etc. are all
>"just other vendor supported products". They all have been
>or will be "de-supported". It doesn't matter a bit what
>is good or better about any of them (unless, of course, there
>is a good idea or two there to incorporate into the portable
>
>"Value is measured by three factors: portability, portability,
>and portability."
Last I heard, PieceofCrap-DOS is portable only as long as Intel
"supports" 80x86 processors, and as long as Microsoft sees money
in it. This makes it "just (an)other vendor supported product"
in my eyes!
--
:::::: Artificial Intelligence Machines --- Smalltalk Project ::::::
:::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 ::::::
:::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
Kenneth Ng
> 3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity.
> *Large* DCL programs exist (my father who is a physicist has a modelling
> program with an enormous dcl frontend, like 10-15K lines. Unfortunately,
> stuff like this is not uncommon). This could be solved by writing a dcl-like
> shell.
REXX to DCL. REXX is a moderately structured interpreted lang
which is the front end of a LOT of IBM applications. I've also
seen it as the entire program in some cases.
--
Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken
soon uucp:k...@rigel.cccc.njit.edu
bitnet(prefered) k...@njitcccc.bitnet
soon bitnet: k...@orion.cccc.njit.edu
(Yes, we are slowly moving to RFC 920, kicking and screaming)
New Jersey Institute of Technology
Computerized Conferencing and Communications Center
Newark, New Jersey 07102
Vulcan jealousy: "I fail to see the logic in prefering Stonn over me"
Movie "Short Circuit": Number 5: "I need input"
Garry Wiegand
over the years (is WYLBUR still out there somewhere?), and I'm a VMS
partisan. What comes to mind quickly:
1) Command names and switch names are reasonable, in English, and consistent
across all the different programs. I don't have to carry a stupid encoding
table around in my head.
2) The on-line Help is well-indexed, and it's HUGE. They've recently started
digesting the language references into Help entries; I rarely need
to page through a manual anymore.
3) The source-line debugger is exceedingly useful for program development and
(after several years of hard work at DEC) I can say it works well.
4) The system services are logical, consistent, and well-documented. Anything
a utility can do, a user program can do too. (And if you want to tickle the
kernel, there *is* a thick manual on the system internals.)
5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
just keeps running along. It's pretty trustworthy.
I like MacIntoshes too, but that operating system is still in its infancy -
"Inside the Mac" is not recommended light reading.
PS - I don't buy the argument about "portable systems"! This industry is much
too young to constrain itself to just one way of doing things. In the
graphics system I designed last winter, I stole good ideas wherever I
found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
all the "graphics packages" that had gone before.
In diversity there is much richness.
--
garry wiegand (garry%cadi...@cu-arpa.cs.cornell.edu)
Harry Edmon
which allow dynamic linking to libraries, and user specified search rules
for the libraries. It is also easy to add your own command processor.
I just wish they would implement some Unix features in Primos (like uucp).
Primix (Prime's attempt at Unix :-(, is too crippled at the current release.
--
Harry Edmon uw-beaver!geops!uw-atm!harry
(206) 543-0547
Department of Atmospheric Sciences
University of Washington
Brooks Gelfand
This doesn't hold for the I.B.M. operating systems. While other
manufactures fit the operating system to the hardware, since the
introduction of the 360 I.B.M. has fitted the hardware to
the operating systems and the application programs. Thus the operating
system and computer evolve together. By placing microcode between
the user and the hardware the user of the latest 3090 still "sees"
a 360. In other words a program that was written and compiled on
an old 360 will run on 3090. Is this "good"? If you are running a
large data processing center with many millions of lines of source
code, you don't want to have to recompile it just to upgrade machines.
There is a price paid in raw speed.
Perhaps your saying should be compatibility, compatibility,
compatibality.
Brooks Gelfand
David Fetrow
...and what about other Primos niceties:
As in UNIX much of the operating system is in high level language(s). The
older versions were relatively compact and written in FORTRAN IV...this may
no longer be considered all that wonderful but it sure made it easy for a
numbercruncher to make changes (like putting in real passwords).
PRIMOS 16 was one of the nicest first software playthings a person could ask
for. Warning: I use Unix, VMS, MS-DOS, TOPS-10 and CMS every day which makes
me something of a dillettante. The only systems I've played with the guts of
are Primos 16, MS-DOS and UNIX 4.X and never at the kernel level.
--
- Dave Fetrow
"Don't ask me how it works or I'll start to whimper" - Arthur Dent
"CP/M is nice because it has no more than 64K*8 errors per tick."
-Dave Fetrow
{ihnp4,tektronix}!uw-beaver!entropy!fetrow :UUCP
entropy!fet...@uw-beaver.arpa :ARPA
fetrow@UWALOCKE,7833117@UWAVM :BITNET
74175,1724 :Compuserve
Dave Hsu
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>
>garry wiegand (garry%cadi...@cu-arpa.cs.cornell.edu)
WYLBUR is alive and well at various government institutions.
Aside from Montgomery County Community College, is MUSIC still out
there anywhere?
-dave
--
David Hsu (301) 454-1433 || -8798 "It was Dave, not me..honest!" -eneevax
Communication & Signal Processing Lab / Engineering Computer Facility
The University of Maryland -~- College Park, MD 20742
ARPA:h...@eneevax.umd.edu UUCP:[seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu
"Unlike me, many of you have accepted your situation and will die here like
rotten cabbages..." -Number 6
Rick Ace
> > never loses your files.
> I can count on the fingers of one foot the number of times I have lost a
> file due to "file system fragility" in the last 5 years on a Unix
> system. This "myth" is just that, and it's time to lay it to rest.
>
>
> =Spencer ({ihnp4,decvax}!utah-cs!thomas, tho...@utah-cs.ARPA)
Well, almost a myth. UNIX filesystem implementations (even the touted
one in 4.2bsd) trade off filesystem integrity for speed in places
where other operating systems give you the guarantee that your data
is safe. For example, when you issue the CLOSF JSYS to close a file in
TOPS-20, you are assured that your data is safely out on the disk when
the JSYS returns. The close(2) syscall, however, does *not* give you that
guarantee, and I have gotten screwed at least once like this:
Edit a file with my text editor
Write the file out and exit editor
Power failure (or other abrupt termination of UNIX) before next sync
Reboot, fsck finds my file and claims it has no data blocks
(the data was floating in the buffer cache when UNIX went down)
Even more infuriating: neither the pre-edit nor the post-edit copy
of the file remained after the crash, because the creat() syscall
issued by the editor when writing out the file truncated the inode!
I have since enhanced that editor to fsync() the file before close()ing
it, but many people would argue that the operating system should take
more responsibility for ensuring the safety of users' files. And what
does one do on a UNIX variant without fsync()? The sync() syscall
isn't really acceptable because 1) there is no way to limit the overhead
to just one specific file, and 2) the return of sync() to the user program
means only that the flush-to-disk operation has begun (i.e., you can't
determine when it has completed).
-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY 11568
(516) 686-7644
{decvax,seismo}!philabs!nyit!rick
ra...@rtgvax.uucp
In article <3...@valid.UUCP>, s...@valid.UUCP (Steven Brian McKechnie Sargent) writes:
First of all, for certain applications, comparing un*x and vms would
be like comparing a three-legged hemorrhoidal cat and the earwax inside
Zaphod Beeblebrox's left ear(s) (go figure...)
For real-time applications (I know, you've probably heard this one before),
the standard (BSD 4.[23], S[V7etc...]) don't, how shall I say,
"lend themselves" to real-time processing... Most notably, a decent paging
mechanism, proper locks, a fine resolution clock, shared memory (or
memory mapping to disk) and other distributed support are missing...
(On the flip side, ultrix 1.2, which claims to be BSD4.3 plus SVID enhancements
has the shared memory, and semaphore support, so things are looking up there).
There is also a great deal of resistance to having to play with the kernel
when adding support for some new type of peripheral... And many many more...
On the other hand, VMS has some dandies too: Process creation is not unlike
pulling a knee-cap out. Mailboxes are S-L-O-W, and mapping to disk-files
by more than one process is not encouraged if both are writing...
DECnet's user-level interface (as in DCL) is bogus as hell (YOU MEAN
I HAVE TO TYPE MY PASSWORD ON THE SCREEN EVERYTIME I COPY FILES ACROSS?
GO PROXY YOURSELF YOUNG MAN!!!). DCL is a joke of a shell (though it's
getting better) with a funny idea for redirection...
File naming syntax is VERY convoluted (there is actually a system call to
VALIDATE the syntax of a filename!!!)... And many many more...
Now that I'm done bitching about the two systems I must point that this
type of questioning is rather misleading since preference for each system
is basically a matter of use and a sprinkling of faith... If you like to
see source code of the command you're using, don't look at vms (unless
you have strong micro-fiche reading eyes). If you like your program to
getup and run when you buy it, try vms (:-). Religiously, most will say
that VMS is THE system for "serious" work, i.e. vs. play with source all
day... If you're the end-user vms gives you more robust software, but
less variety and definitely less support if things break. If you're
the developer unix lets you do so many things faster and easier...
So in conclusion.... I would buy a unix system with a vms cross-tool
set. i.e. where I could develop on a unix, but the end result would
run on vms...(:-)
This is all too silly... I'm going out for a drink...
ramin...
> UNIX isn't but should be a trademark of D.M.Ritchie.
> VMS should be the name of some type of plastic resin...
--
=--------------------------------------=-------------------------------------=
: alias: ramin firoozye' : USps: Systems Control Inc. :
: uucp: ...!shasta \ : 1801 Page Mill Road :
: ...!lll-lcc \ : Palo Alto, CA 94303 :
: ...!ihnp4 \...!ramin@rtgvax : ^G: (415) 494-1165 x-1777 :
=--------------------------------------=-------------------------------------=
"Your wife is a genius. It's hard getting used to my furniture moving around."
ste...@fai.uucp
>>
>> 1) For the VMS fans out there: what's your favorite feature(s) of
>> the system? Why do you like it? How does it help you?
>
>I think that the main complaints with Unix from VMSites are
>
>1)
>9)
I thought it was an excellent list Larry, with one omission (the problem
I'm grappling with now). DEC has over the years developed an excellent
layered system of hardware and software that allows the addition of more
machines without putting one bunch of users off by themselves on a separate
machine. In fact to the users, Vax-clustering makes many machines look like
one. There's no graceful way with UNIX to add a machine and not find that
you have to segregate some users from others.
--
--
Steven A. Minneman (Fujitsu America Inc, San Jose, Ca)
!seismo!amdahl!fai!stevem or !ihnp4!pesnta!fai!stevem
The best government is no government at all.
Leo Wilson
The real problem with VMS is that it takes !screwdrivers and wrenches!
to install it. I don't even see it as really being a *software* product
(from a consumer's point of view) unless it is available for all my
current and future hardware.
VMS is really a GREAT os, with lots lots of plusses and only (count 'em)
ONE detractor: It's locked into a single vendor's hardware. (Oh, yeah,
expensive hardware, and pretty much state of two years ago's art, too.)
Oh, I have my druthers & UNIX answers lots more of them than VMS does,
but as far as I can see VMS has UNIX whipped all to hell in any work
environment other than ed or r&d. I have been looking, too. I'll
never actually USE it, tho, until I have the option to buy other companies'
*competitively* priced hardware.
How about it, DEC, turn VMS into purely a software product and "remember
UNIX" will become ONE word!
Trademarks: UNIX is a registered trademark of AT&T
VMS is a registered trademark of Digital Equiptment Corp.
DEC is probably a trademark of Digital Equiptment Corp.
(if i left anyone out, sue me & i'll move out of the
country before it gets to court.)
MKR
>
> 1) For the VMS fans out there: what's your favorite feature(s) of
> the system? Why do you like it? How does it help you?
>
> 2) Likewise UNIX and Multics fans. (How do I get to a Multics
> site? I'm not on the MILnet...)
>
I am somewhat enamoured of UNIX, although I currently use VMS for
most of my work. I tend to dislike VMS as much as I like UNIX, but I didn't
come here for a religious argument. (One jab - VMS users love to point out
that VMS commands are English. That always struck me as meaningless when
I can't remember *which* English word gets rid of a file - let's see... is
it DELETE, REMOVE, PURGE, KILL, or what? How do I look at the contents...
is it PRINT, TYPE, SHOW, LIST, DISPLAY, OUTPUT, CAT (heh heh) or what?)
Anyway, what I wanted to point out was that if you want to learn
all about UNIX, go to B. Dalton's or the equivalent. You can find row after
row of books explaining UNIX, most of which do the job just fine. I wanted
to learn more about VMS, and all I could find were the DEC manuals. Yechh!
I find it hard to throw the 5 or 6 large binders I need into my briefcase
to take them home for easy reading, even if the company would let me. And
I'll be damned if I'm going to shell out a coupla grand to get my own copies.
Nahhh - I'll take UNIX anyday.
--MKR
Sandra Loosemore
under VMS, though, and I must admit that I like VMS a bit better. There
are a lot of operating systems that are a whole lot worse than Un*x though.
(Fortunately, I don't have to use those every day....)
I think the greatest advantage VMS offers over Un*x is the networked/shared
file system. VMS has had transparent network file access for at least 5
years, and this is just now working its way into Un*x. (They just installed
this as a "local hack" on the machines at the University of Utah -- it is
by no means a standard feature yet.) The VMS machines I use at work are
clustered, so the file structure looks exactly the same no matter which
machine I'm using. Given the current trend towards distributed computing
environments with personal workstations and compute servers, shared file
systems are very important things for an operating system to support.
Another thing I like about VMS is the documentation. There is a great deal
of tutorial information and examples in the manuals. It seems like when
I find I need to do something obscure with Un*x, I can never find the
right command to do it (or the documentation is so terse that I'm never
really sure whether it's the right command or not), and I end up having
to ask a "wizard". (Unix sites without "wizards" are really in trouble.)
I also wish Un*x had on-line help on how to use the shell, instead of
just the utilities!
I don't think that either VMS or Un*x has serious problems with file system
reliability; I've never lost a file under either OS. File versions under
VMS have saved me more times than I can remember, though. Again, this is
just another place where DEC has taken the trouble to try to "idiot-proof"
things, and we users appreciate it.
Of course, there are bad things about VMS too: as others have pointed out,
processes are incredibly slow to start up, the mailer is not too great (but
neither is the Un*x mailer, for that matter), all of the DEC editors are
pretty awful (but so is "vi"), etc. On the whole, though, Un*x is fine if
you want an "open" operating system where you can tweak everything in sight,
but if you just want to get a job done, VMS is a lot less hassle.
-Sandra Loosemore, Evans & Sutherland Computer Corp.
{decwrl, utah-gr!uplherc}!esunix!loosemor
loos...@utah-20.arpa
[Insert usual disclaimers]
w...@lewey.uucp
> machines without putting one bunch of users off by themselves on a separate
> machine. In fact to the users, Vax-clustering makes many machines look like
> one. There's no graceful way with UNIX to add a machine and not find that
> you have to segregate some users from others.
>
The above is not really true with respect to UNIX any longer.
Several vendors offer working distributed file systems for UNIX.
For example, NFS from SUN and TRFS from Integrated Solutions both
allow easy expansion to new machines without segregating users.
Also, Todd Brunhoff's RFS is included with 4.3 BSD, and has been
distributed to the network. It works with both 4.2 BSD and 4.3 BSD.
Even AT&T will eventually release their RFS for System V Release 3.
UNIX today, especially BSD UNIX, is much more sophisticated in this
area than it was a few years ago.
William J. Earl
American Information Technology, Cupertino, CA
408-252-8713
...!decwrl!nsc!voder!lewey!wje
--
William J. Earl
American Information Technology, Cupertino, CA
408-252-8713
...!decwrl!nsc!voder!lewey!wje
Brandon Allbery
Quoted from <7...@eneevax.UUCP> ["Re: Favorite operating systems query"], by umd...@eneevax.UUCP...
+---------------
| VMS is the nicest operating system I've ever used (out of a sample of
| about 7, which isn't all that many). Period. I just wanted to clarify
| and correct the points made in the parent articles. Most of the
| complaints that I hear fro
+---------------------------^ Does anyone see a line-eater around?
I don't have ANY experience with VMS, so I cannot comment. I am familiar with
Unix and have used TOPS-20; Unix I like for its simplicity and power, TOPS-20
for its user interface (but the CLI reminds me of CP/M-80 <ecch!>). Neither
is perfect.
I think it's about time for another Unix-birthing type of brainstorm: someone
sit down and write a new operating system using the basic principles of Unix,
combined with all that we have learned in 16 years. Since it'd be a new
operating system, the writers wouldn't have to maintain ``compatibility'' with
the various mistakes taht Unix has accumulated; although I'd suggest
compatibility libraries to (attempt to) translate Unix facilities into
equivalent ones in the new OS.
I'd try my hand at it myself, but the only computers I can program for this
purpose are an ITT XTRA (nice machine, but a multitasking OS for an 8088
is a contradiction in terms, Xenix notwithstanding) and a TRS-80 Model I
(nice processor, TERRIBLE machine!). I'd be shot at dawn if I tried to use
TDI'd P/60 for the experiment -- although it'd be a nice machine if I could
get my hands on one of my own...
Anyone know if maybe this new genesis is already going on?
--Brandon
--
ihnp4!sun!cwruecmp!ncoast!allbery ncoast!all...@Case.CSNET ncoast!tdi2!brandon
(ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101
Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time)
Daniel R. Levy
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>partisan. What comes to mind quickly:
>
>1) Command names and switch names are reasonable, in English, and consistent
> across all the different programs. I don't have to carry a stupid encoding
> table around in my head.
Oh yes, and along with those verbose commands goes a command line which can't
be over 255 characters long, and a library-archiver, compiler, and linker
which can't take wild cards. Real nice when you have a 100-module program.
Most Unix programs will print out a line or so of "usage" diagnostics if you
invoke them with bogus arguments. Do VMS programs do this?
>
>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
> digesting the language references into Help entries; I rarely need
> to page through a manual anymore.
Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems,
we did indeed have a detailed online help for Fortran, and we have such a
help now for C, but not for Fortran. Did someone just forget to install it,
(system manager is baffled) or is it an "extra" (cost) item, or what?
Unix online help need not be "HUGE" because the system interface isn't "HUGE."
I think VMS is marvelous from many user points of view (despite my criticisms
herein) but the system interface is a monstrous headache because of the
complexity.
>
>3) The source-line debugger is exceedingly useful for program development and
> (after several years of hard work at DEC) I can say it works well.
That's nice, BUT what do you do when the program dies in an alpha-test
environment? You get a nice stack-dump printout, but do you get a "core"
which can be analyzed (especially if the sequence leading up the the crash
is not easily reproducible?). (I _think_ there was supposed to be an option
to RUN which would cause a program to produce the VMS equivalent of a core
dump when it dies, but then can you pass parameters to the program, which
as best as I understand cannot be done with RUN?)
>
>4) The system services are logical, consistent, and well-documented. Anything
> a utility can do, a user program can do too. (And if you want to tickle the
> kernel, there *is* a thick manual on the system internals.)
Could you then do me a favor. Show me how, in Fortran, I would go about
setting the protection (no fancy ACL stuff, just basic RWED protections)
on a file which I am creating. (In C it's easy enough, since the protec-
tion is specified when the file is created, which of course is tied to the
straightforward Unix way of doing things!) Please show actual code, such as
a USEROPEN program, together with the OPEN() statement that calls it, to run
on VMS 4.2. Or even show me how I can do it in assembler. (I hesitate to
say show me how to do it in the system programming language, since Bliss-32
is an "extra-cost" [and not really very commonly used outside of DEC, unlike
C which is commonly used outside of Unix systems, let alone AT&T machines]
option which I don't have. I think the analogy fair since that is what I
would probably do if I needed to change the protection of a Unix file from
Fortran [I would call chmod() in a C routine].)
See also my comments under 2) about the system interface. It is massive,
complex, and cumbersome, as well as introducing kludges into common pro-
gramming languages, to be blunt. VMS does indeed pride itself on
accessibility of system routines from "any" language, but this occurs at
the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
%val()s and %loc()s) to common programming languages, that a user would
actually WANT to program in. C, which is a fairly common, "ordinary"
programming language and sees wide use and portability even in non-Unix
environments, fits the UNIX system interface very naturally and needs no
such kludges to use it. (It is commendable that DEC has seen fit to switch
rather than fight, and has provided an extensive UNIX-like interface to
the VMS system within C.)
>
>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
> just keeps running along. It's pretty trustworthy.
Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
being able to crash the system by entering certain line-editing sequences
in response to a prompt (involving ^B and some other escape codes). I
succeeded in doing this once from DCL, and we have a plain VMS system, no
special private kernel drivers installed. VMS 4.2 also kicked the bucket
on me the other week when I was trying to access the help library. The
system just barfed, and the console dump contained my process name. And
I wasn't even trying any funny business or having any special privileges.
Needless to say, Unix has never done this kind of thing.
It is indeed possible for Unix files to get trashed if they have been "writ-
ten" on (to the buffer cache) at a time which is less than the periodic system
buffer flush period (typically 10-20 seconds) before a physical failure. It
is however possible under SysV (and maybe BSD, but I'm not sure) to
open() a file with an O_SYNC option, which will not return from the write()
until the data has physically gone onto the storage medium. To do this is,
unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
which is paid for security. Any user also can tell the system to flush the
entire buffer cache with the sync() call, if they are worried about the
integrity of what they have just written.
>
>I like MacIntoshes too, but that operating system is still in its infancy -
>"Inside the Mac" is not recommended light reading.
>
>PS - I don't buy the argument about "portable systems"! This industry is much
> too young to constrain itself to just one way of doing things. In the
> graphics system I designed last winter, I stole good ideas wherever I
> found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
> all the "graphics packages" that had gone before.
>
> In diversity there is much richness.
If so, I am exceedingly glad that UNIX is part of that richness.
(Diversity of hardware, too, spell that "vendor independence.")
>
>
>--
>garry wiegand (garry%cadi...@cu-arpa.cs.cornell.edu)
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer or the administrator of any computer
| at&t computer systems division | upon which I may hack.
| skokie, illinois |
-------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
vax135}!ttrdc!levy
Daniel R. Levy
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>partisan. What comes to mind quickly:
>
>1) Command names and switch names are reasonable, in English, and consistent
> across all the different programs. I don't have to carry a stupid encoding
> table around in my head.
Oh yes, and along with those verbose commands goes a command line which can't
be over 255 characters long, and a library-archiver, compiler, and linker
which can't take wild cards. Real nice when you have a 100-module program.
Most Unix programs will print out a line or so of "usage" diagnostics if you
invoke them with bogus arguments. Do VMS programs do this?
>
>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
> digesting the language references into Help entries; I rarely need
> to page through a manual anymore.
Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems,
we did indeed have a detailed online help for Fortran, and we have such a
help now for C, but not for Fortran. Did someone just forget to install it,
(system manager is baffled) or is it an "extra" (cost) item, or what?
Unix online help need not be "HUGE" because the system interface isn't "HUGE."
I think VMS is marvelous from many user points of view (despite my criticisms
herein) but the system interface is a monstrous headache because of the
complexity.
>
>3) The source-line debugger is exceedingly useful for program development and
> (after several years of hard work at DEC) I can say it works well.
That's nice, BUT what do you do when the program dies in an alpha-test
environment? You get a nice stack-dump printout, but do you get a "core"
which can be analyzed (especially if the sequence leading up the the crash
is not easily reproducible?). (I _think_ there was supposed to be an option
to RUN which would cause a program to produce the VMS equivalent of a core
dump when it dies, but then can you pass parameters to the program, which
as best as I understand cannot be done with RUN?)
>
>4) The system services are logical, consistent, and well-documented. Anything
> a utility can do, a user program can do too. (And if you want to tickle the
> kernel, there *is* a thick manual on the system internals.)
Could you then do me a favor. Show me how, in Fortran, I would go about
>
>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
> just keeps running along. It's pretty trustworthy.
Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
being able to crash the system by entering certain line-editing sequences
in response to a prompt (involving ^B and some other escape codes). I
succeeded in doing this once from DCL, and we have a plain VMS system, no
special private kernel drivers installed. VMS 4.2 also kicked the bucket
on me the other week when I was trying to access the help library. The
system just barfed, and the console dump contained my process name. And
I wasn't even trying any funny business or having any special privileges.
Needless to say, Unix has never done this kind of thing.
It is indeed possible for Unix files to get trashed if they have been "writ-
ten" on (to the buffer cache) at a time which is less than the periodic system
buffer flush period (typically 10-20 seconds) before a physical failure. It
is however possible under SysV (and maybe BSD, but I'm not sure) to
open() a file with an O_SYNC option, which will not return from the write()
until the data has physically gone onto the storage medium. To do this is,
unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
which is paid for security. Any user also can tell the system to flush the
entire buffer cache with the sync() call, if they are worried about the
integrity of what they have just written.
>
>I like MacIntoshes too, but that operating system is still in its infancy -
>"Inside the Mac" is not recommended light reading.
>
>PS - I don't buy the argument about "portable systems"! This industry is much
> too young to constrain itself to just one way of doing things. In the
> graphics system I designed last winter, I stole good ideas wherever I
> found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
> all the "graphics packages" that had gone before.
>
> In diversity there is much richness.
If so, I am exceedingly glad that UNIX is part of that richness.
>
>
>--
>garry wiegand (garry%cadi...@cu-arpa.cs.cornell.edu)
joh...@batcomputer.uucp
>Could you then do me a favor. Show me how, in Fortran, I would go about
>setting the protection (no fancy ACL stuff, just basic RWED protections)
>on a file which I am creating. (In C it's easy enough, since the protec-
>tion is specified when the file is created, which of course is tied to the
>straightforward Unix way of doing things!) Please show actual code, such as
>a USEROPEN program, together with the OPEN() statement that calls it, to run
The following is a trivial (and slow) way to do this. I'm sure there is a
better way but sitting here this is the best I can do.
OPEN()
...
Close()
Call Lib$Spawn('Set Protection=....')
Personally I love to play with UNIX. It is a lot of fun to poke around in.
On the other hand when I need to get things done I like VMS. It is easy
because I don't need to think about how to do thinks, only about what I'm
trying to get done. When I first started on VMS I just sat down at a terminal
and started to see if I could make it go. My first command was EDIT TEST and
it worked! Love at first sight. I would never have guessed vi.
Now that I know a little about UNIX I like it. What I like about VMS is
that I didn't need to take two weeks of workshops to learn enough to be
able to use it.
John Thurtell
Tom Haapanen
>> you have to segregate some users from others.
> The above is not really true with respect to UNIX any longer.
>Several vendors offer working distributed file systems for UNIX.
>For example, NFS from SUN and TRFS from Integrated Solutions both
>allow easy expansion to new machines without segregating users.
>Also, Todd Brunhoff's RFS is included with 4.3 BSD, and has been
>distributed to the network. It works with both 4.2 BSD and 4.3 BSD.
>Even AT&T will eventually release their RFS for System V Release 3.
>UNIX today, especially BSD UNIX, is much more sophisticated in this
>area than it was a few years ago.
Supposedly SCO's just-announced XENIX-Net (developed with Microsoft who
will sell it for the 68000 and other non-brain-damaged architectures)
will provide transparent file sharing between a number of XENIX machines,
using Sytek cards or something equivalent.
Even just using Ethernet to hook up a bunch of VAXen without file sharing
doesn't really amount to segregation. At University of Waterloo, we had
over a dozen VAXen (plus uVAXen etc.) hooked together. You didn't feel
segregated, because it was very easy to do things over the network: rcp
(remote copy), rlogin, rsh, rwho and other commands make things easy. Mail
would figure out what machine the recipient was on, and full-screen talk
between machines made it really feel like just one big system. If I had
to do some big makes or something, I'd find the machine with the smallest
load, rcp the files over, do my work, and rcp the results back (no need
to type in any passwords: your .rhosts file defined the authorized users).
This was all running on all kinds of VAXen (uVAX, uVAX2, 750, 780, 785,
8600) using 4.2 BSD and Ultrix.
--
\tom haapanen looking glass software ltd.
syn...@looking.UUCP waterloo, ontario, canada
watmath!looking!syncro (519) 884-7473
"These opinions are solely mine, although even I would like to deny them..."
Brandon Allbery
Quoted from <3...@lewey.UUCP> ["Re: Re: Favorite operating systems query"], by w...@lewey.UUCP...
+---------------
| > ... DEC has over the years developed an excellent
| > layered system of hardware and software that allows the addition of more
| > machines without putting one bunch of users off by themselves on a separate
| > machine. In fact to the users, Vax-clustering makes many machines look like
| > one. There's no graceful way with UNIX to add a machine and not find that
| > you have to segregate some users from others.
| >
| > Steven A. Minneman (Fujitsu America Inc, San Jose, Ca)
|
| The above is not really true with respect to UNIX any longer.
| Several vendors offer working distributed file systems for UNIX.
| For example, NFS from SUN and TRFS from Integrated Solutions both
| allow easy expansion to new machines without segregating users.
| Also, Todd Brunhoff's RFS is included with 4.3 BSD, and has been
| distributed to the network. It works with both 4.2 BSD and 4.3 BSD.
| Even AT&T will eventually release their RFS for System V Release 3.
| UNIX today, especially BSD UNIX, is much more sophisticated in this
| area than it was a few years ago.
+---------------
Not to mention Plexus NFS, which is a separate product from Sun NFS and has
been available for (at least) two years, running under System III and now
System V; it is Plexus's major product (look up ``plexus'' someday in the
dictionary). Many computer companies now offer networking (Yes, Plexus NFS
supports an rlogin-type interface; it's called ``vtty''.)
I do not work for Plexus; in fact, I'm currently having an argument with
them. I only mention this to show an example of network abilities other than
the major ones (Sun, 4.xBSD). There are no doubt other companies with this
kind of product.
ji...@tekcbi.uucp
What about RSTS?????????? |-) |-)
In particular, V9 (earlier versions don't count)
the wharf rat
> when adding support for some new type of peripheral... And many many more...
>
> I HAVE TO TYPE MY PASSWORD ON THE SCREEN EVERYTIME I COPY FILES ACROSS?
> GO PROXY YOURSELF YOUNG MAN!!!). DCL is a joke of a shell (though it's
> VALIDATE the syntax of a filename!!!)... And many many more...
>
passwords....
And one good thing about checking file-names: You can't write
files with control-chars in the names by mistake.
W.rat