On Fri, 15 Jul 2016, Ethan Dicks wrote:
It was a huge deal in the late 80s and into the 90s.
I was on both
sides, so mostly, I watched.
This thread has definitely been the most civil discussion and set of
anecdotes I've seen when folks discuss VMS and Unix in the same thread. I
usually don't bring up VMS because I'm not that well versed in it, and
when I make one mistake in the nomenclature or some other triviality,
someone usually gets butthurt and tries to make a fool out of me or just
scream bloody murder. However, folks have been nice this time, for which I
breathe a sigh of relief.
Of course there is still time for someone to troll... :-)
I've written device drivers, system utilities, and
application code for
both.
From your experience and depth on both platforms, it
sounds like you have
a well rounded perspective. I have merely hours of experience
in VMS but
years in UNIX. I've never written any device drivers outside of stubs or
proof of concept stuff I've done in tutorials. However, I've written a lot
of C utilities and app code and most of that was on UNIX platforms, but a
little in DOS or on the Amiga.
If I have choice, I'll grab something UNIXy to do
my work on - I'm not
particular as to flavor.
I'll reach for NetBSD first, FreeBSD second, and then it's just "whatever
will work" if those are off the table. For play, I love to work with
obscure, obsolete, specialized, or otherwise interesting UNIX variants.
How well do you think it would go if all you had was
SLIP and PPP?
Do you mean versus some other point-to-point protocol or versus just using
serial terminal emulation? If it's versus DECnet, I'd say that it'd go
quite well. I've used both SLIP and PPP (and loads of others) to build
networks with Unix boxes and/or Cisco routers. When I worked for Cisco I
implemented a LOT of PPP links. They work great. They create a nice
interface for you to apply ACLs, routing rules, etc.. I have zero problem
with either. In fact, there are extensions to PPP such as multi-link and
VJ compression that make it rock even harder. Personally, I've had
super-wonderful experiences with the protocol. My only doubt is that if it
was used on very old equipment it might have been too CPU or memory
intensive versus something much more simplistic or efficient.
All serial, all day. We still got a lot done.
There isn't anything wrong with serial, as far as I'm concerned. It's got
it's place and it did a great job for folks. It still does in many cases.
That said, it was easier (to me) to write full-on apps
and utilities in
DCL than sh or csh.
Well, I'm a C programmer, as I mentioned, as well as a UNIX zealot and I
am pretty allergic to csh. Again, it's just a style issue, but I wish that
Bill Joy didn't name it "csh" because it's not something I'm happy
to see
associated with C coders (folks automatically assume you want csh if
you're a c-coder sometimes). I'll definitely take any form of Bourne shell
(sh ksh zsh bash) before I resort to csh. Fortunately, most folks seem to
agree and csh is pretty niche these days. That's not to say there aren't
very enthusiastic users of csh, too.
As far as DCL goes, I'll just say this, without 'while' and 'for'
I'm
sorry, it's a PITA. As a programmer, I find shell scripting to be much
more flexible due to more language features and sugar. Sure, you can use
'if'-statements to cobble together a replacement for most situations, but
it's clumsy & ugly from what I've seen.
It would be a fairer comparison to develop a complex
app in Perl vs DCL
(Perl would win, but it has a lot going for it).
Feature wise, I don't see much of a comparison. Perl would trounce DCL in
a comparison involving functionality. It's not a fair fight or apples to
apples in my mind at all. Plus, Perl isn't a CLI interpreter (though I
suppose you could try it that way). DCL is. Hence, I'd compare it to shell
script. However, you don't have as many opportunities to write line-noise
in DCL (joke!). :-)
The regularity and predictability of args and options
is definitely a
strength in DCL. Args are entire words, not letters which change from
app to app.
That is the big thing that DCL has going for it, if you ask me.
Next thing - how about those args to 'dd'?
Crazy. Now how about
'tar'... etc., etc. I use this stuff every day, but I have internalized
a massive amount of UNIX trivia to be able to do so.
This is always the criticism of UNIX environments versus VMS & DCL. It's
valid, I think. I agree with you about the whacky args to 'dd', 'tar', and
others (SysV vs BSD 'ps', I could go on and on).
VMS requires far less random factoid knowledge to get
stuff done on the
command line. There's a system command line parser, and it helps with
the consistency.
I've also been told that the way the help is put together in VMS tends to
make the CLI args and switches more consistently well-documented. That's a
lesson for some clever UNIX variant to learn, or perhaps it's the "wild
west" nature of UNIX that actually attracts some people. It's the whole
"less regulation" idea, maybe. I don't know. However, I would like to see
some improvements here and there. UNIX isn't perfect. There are plenty of
dingy spots. However, to me it's like democracy - it's the best of a bunch
of bad systems.
Much stronger. There are dozens of privileges you can
grant so someone
can do their job and not overstep things. UNIX says, "all or nothing.
Don't screw up."
Well, while I agree VMS is much stronger when we talk about it in the
context of the 1990s. However, it's certainly not "all or nothing" even in
older UNIX variants. There *are* 'group' and 'other' permissions, not just
'owner'. The problem for that model is when you need an exception. Ie..
someone wants to write to a file that they don't own, aren't in the proper
group for, and you can't add them to the group for some reason, PLUS you
can't open up the file permissions. That's the the most common situation
that serves as an argument for POSIX ACLs. It's the "textbook example".
Having said that, let's talk real for just a sec. The current crop of Unix
variants often have equal or better authentication/authorization systems.
Take a look at SElinux, Cgroups, Capabilities, and POSIX ACLs. Put those
all together and you can do everything that VMS can plus a ton more.
The modern discussion also mirrors the storage capabilities of VMS. It has
has shadow-sets (essentially RAID1) for a long time and they nailed that
functionality very early on as well as made the ODS file system aware of
it. However, post LVM2, ZFS, BTRFS, DRBD / HAST, and/or compared to modern
VxVM & VxFS, VMS is lacking a very long list of valuable and important
features that are freely available now in many UNIX variants.
OTOH, I learned a *lot* porting utilities and games
from
comp.sources.unix and comp.sources.games to VMS. Some things were a lot
harder than others.
I think the biggest stumbling block is the lack of fork() in VMS. They
have threads and some hacks like LIB$SPAWN, instead. However, in most
cases, I'll take a fork() model over threads any day. Concurrency and
marshalling threads has always been a PITA, IMHO. It's not that fork()
gets out of it, it just forces a more simple structure/design (again, just
my opinion based on experience).
-Swift