[linux-elitists] Re: Linux ports

Jason Spence jspence@lightconsulting.com
Tue Oct 28 15:17:12 PST 2003


On Wed, Oct 22, 2003 at 10:09:07PM -0400, Modus Operandi wrote: 
>   Doesn't OpenVMS have the world record for uptime? (I think it was the
>   Irish Railway running VMS V3.0 on a VAX 11/750 for 17 or 18 years.)
> 
>   Not that uptime is the only consideration ... what are some advantages
>   of GNU/Linux over VMS, or vice-versa?
> 
>   (I'd be surprised to find a bunch of OpenVMS-elitists on the
>   Linux-elitists list ... but those people are out there!)

I've been kinda-sorta exposed to VMS since I was in grade school
because of the sorts of work my parents did and the sorts of people
they hung around.  Only over the last few years or so have I actually
done really hard core stuff with it due to various things that have
happened like meeting Fred van Kempen, consulting for SCADA firms,
etc.

VMS (what's this f*cking Open bit, eh?) is, um, different from Linux.
Among other things it's a lot more commercial in the same way a WISP
is different from a commercial telco.  A lot of design decisions were
done to satisfy business requirements rather than make the programmer
happy.  One nice thing about the POSIX API is that you can usually fit
entire subsystems in your head, just like with C.  It's very rare to
find anyone with 5+ years of UNIX experience that can't write a
buffering cat(1) from scratch without looking at the man pages [1].

VMS isn't like that at all.  The APIs are a lot like Win32 or the
OS/390 in that you regularly find functions that take a dozen or more
mandatory arguments and you are required to think about other aspects
of your code like multithreading and security instead of having the
system provide you with reasonable defaults.  I have found this has
the effect of making all the software written for the platform
"commercial quality" because it's just impossible not to write
software that hasn't been really thought about.  In other words, the
ability to trade of reliability, scaleability, maintainability, etc in
favor of lower implementation time just doesn't exist on VMS.

But the one huge advantage is that VMS has been around forever (prior
to VMS we had RSX-11 and friends, and prior to that there were similar
operating systems) and it will probably continue to be around, maybe
even outliving all of us and the people who originally implemented it.
So if you write a big iron type application like traffic light
arbitration or environmental control on VMS, you can be pretty sure
it'll still be running in 30 years or so if there's commercial demand
for it (although it might change hardware platforms a few times).  The
SCADA firm I'm consulting for at the moment has people who think that
15 year old code is "immature" by their standards.  Some of their
customers still have DEC OSs running their industrial control package
on PDP/11s overseas, which should give you an idea of what kind of
timescale they think about with.

I can't even concieve of Linux, OS X, or Windows continuing to run
applications with that kind of backwards code-level compatibility for
that period of time.  Eventually they'll probably mature to the point
that application programmers get the performance (*cough* aio
*cough*), clustering, management features, etc that they need out of
the APIs and some backwards compatibility will be available for a long
time past that point, but at the moment they just don't exist.  VMS
has had all that stuff since before I was born, and the Fortran
programs written on it before the 64 bit era usually only take a
recompile to go to a newer platform (C programs are another story
because of types and the tendency to do stuff like depend on a custom
alloca(3) implementation).  I've been looking real hard at VMS 8 on
Itanium and it looks like the transition from Alpha to Itanium is
going to be roughly as hard as the transition from VAX to Alpha, which
is to say it's basically a recompile and a documentation update.

However, I don't run a car factory or a nuclear weapons facility at my
house, so I have a big collection of UNIX, Mac OS, and Windows
machines which I use for playtime :) Although you can use Perl and
bash on my VMS machines, you just can't escape DCL and EDT, and when
you have to use them it always feels like more like work than play.

-- 
 - Jason             Last known location:  13.5 miles southeast of OAKLAND, CA

With a rubber duck, one's never alone.
		-- "The Hitchhiker's Guide to the Galaxy"

[1]
// cat(1) in 60 seconds
// Copyright 2003 Jason Spence <jspence@lightconsulting.com>
// [2]
int main(int argc, char * argv[]) {
  int rc, src;
  char buf[BUFSIZ];
  src = open(argv[1], O_RDONLY);
  while((rc = read(src, buf, BUFSIZ)) > 0) { // [3]
    write(STDOUT_FILENO, buf, rc);
  }
  return rc; // [5]
} // [6]

[2] Remembering which headers to include is left as an exercise to the
reader.

[3] 10 points to whoever points out how to do portable (OS X, Win32,
Linux, and BSD) error checking on the read(2) call by outputting the
strerror(errno) value here without increasing the number of lines in
the program. [4]

[4] Hint - the CRT has to store it somewhere...

[5] Note that this returns the correct error value to the shell
whether an error occurs or not, but you can't use this as an answer to
[3].  Always check your $?s or You'll Be Sorry...

[6] 20 points if you can figure out how to get the utime and stime
using wait3 OR wait4 (on Linux and BSD) without using a wrapper
process with its own main in another module AND with dynamic detection
of which API is available on the current platform.  And you can't use
ltdl.




More information about the linux-elitists mailing list