In article <01HBEJ4NSDLK99EY1A at NIEHS.NIH.GOV>, STAFFA at NIEHS.NIH.GOV writes...
>To my vast sorrow, there is a move from on high at this institution to
>put GCG on a Unix platform. This machine is not yet bought.
>The question is:
>What platform, hardware and operating system, would you recommend for
>GCG?
Have the people "on high" provided any rationale for the move? If you've
got a large group of VMS acclimated users you're going to lose productivity
for a time while they reacclimate themselves to Unix. After a while they
will get back to roughly the same as before. All religious arguments aside,
there isn't much difference in how much work nonprogrammers get done on
Unix versus VMS. In any case, the underlying OS matters less and less as
the applications move up to menu systems and GUI interfaces. I've not yet
seen the GCG GUI, but I suspect that when you're using it you can't tell
what you're running on (except for filenames). If you're making the move
because "Unix is cheaper" forget it - machines like the DEC 2000 and 2100
AXPs are at least competitive with any of the Unix boxes. Heck, they *are*
Unix boxes if you want to dump VMS and load OSF/1.
One reason to stick with VMS, that hasn't been mentioned in this string
yet, is that you don't have to worry (as much) about hackers shutting you
down. To my knowledge, all of the machines that have been broken into on
our campus were Unix machines of one flavor or another. Unfortunately,
once one of those has been compromised they are usually set up to sniff the
net for username/password combinations, which then compromises the security
of everything else on the net. It is much, much harder to break into a VMS
machine. As long as you never logon over the net to a privileged account
on a VMS machine that machine will be relatively safe even on a compromised
subnet. The worst that could happen is that a captured username/password
would be used to delete a user's files, which would then be restored from
the backup tapes. On a Unix machine, you might very well be reinstalling
the whole operating system - and wondering whether the backup that you are
using is already full of trojan horses and trap doors.
As a management issue, to my mind, this represents a fairly big problem.
Staying on top of all the Unix security patches (for each flavor of Unix
you run :-() is time consuming to the point of impossibility. Basically I
think you've got two options - forget about it and hope for the best, or
spend wads of time researching, obtaining, and applying patch after patch.
Now, your users won't appreciate that you are doing this - it takes time
away from other activities. But if you take the easy way out, when the
shit hits the fans, guess who gets to clean it up?
In contrast, keeping on top of VMS security is almost no work at all.
In terms of integrating PCs and Macs, VMS is pretty easy. Can't say much
about Unix in this regards since I've not tried it there.
One down side to sticking with VMS is that you'll often not have the latest
and greatest software. This is actually a mixed blessing. True, you'll be
a bit behind the curve, but by the time somebody gets around to porting the
software to VMS a lot of the bugs will have been wrung out of it. If you
really need something, generally porting code isn't too bad unless it
contains lots of OS specific calls, that is, above and beyond standard C.
(Personal experience). DECWindows is a sore point in this regard, but I'm
hoping that Motif 1.2 will bring that up to speed too. On the way down
side, some code can't be had, and if the developer isn't interested in VMS,
you won't be running their application.
The bottom line: users get their work done on either system, Unix is a bit
more work to manage, and a lot more work to manage "securely".
Regards,
David Mathog
mathog at seqvax.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
