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?
|>
Seriously, I'd say it doen't matter if you restrict you evaluation
with respect to GCG _exclusively_. If you go for a (supported)
platform, i.e. if you use a commerical rather than a beta or other test
release, you should be quite happy with any of the supported machines.
There will be gripes, different for each platform, but these are minor
with respect to other items (see below). If you know how many users
are expected, and the software requirements, formulate a 'call for tender'
and let vendors offer you solutions in a preset margin of price. You
may then compare before you evaluate individual products.
|> I've noticed on INFO-GCG that people with Unix systems are always
|> having some kind of trouble.
This might be because UNIX sysops are more honest and open with respect
to debating their malfunctions on the net rather than calling support
service :-)
|> I've always thanked God for VMS and
|> deleted these messages without paying them much mind. The questions:
|> What unique problems arise when running GCG on Unix?
End user:
The basic UNIX pitfalls are case dependency of the OS and difficulties
with semicolons and other extra characters during migration. Vocabulary
is different but may be learnt easily with cookbooks. Editors are messy,
if you happen to spoil users with X the emacs is pretty good as it
allows mouse operation, while also being useful on VT100 type terminals.
Version numbers are gone on UNIX, some users find this irritating that
they can't access previous versions. You might want to alias the rm to a
mv in a dumpster but this is costy with respect to disk space.
GCG is pretty much the same, but uses - rather than / accrding to the
UNIX general flavour. Same with controls, <CRTL><Z> replaced by <CTRL><D>.
GCG has a pretty good 'new users' section in the users manual, also
on-line, and if users would ever read it they would learn a lot.
Manager:
Hardware side: Buy as much memory and disk as you can afford.
Leave gimmicks like sound, video and smell, as those aren't hot in
biology yet. If they become hot in a year or two, you might still want
to buy a new machine.
Bad news for all scripts; as DCL is expensive on UNIX: You need to by
very sophisticated and pricy packages to have it run. It's not for long
anyway, so better rewrite everything. It is a good chance to restart...
You should consider purchasing a batch queuing system, to have GCG with
-batch run really in batch mode. The cron-based 'at' is insufficient.
Quotas can be enforced on most systems, you should, however, keep in mind
that the mechanism is slightly asynchronous.
|> What sort of user-unfriendliness would I have to be warning my clients
|> about when they are forced to make the transition?
We run GCG here on a VAX/VMS, a AXP/VMS, and a Silicon Graphics cluster.
Currently (pre 8), GCG supports a browser (called GCG navigator) ONLY
on Unix, so users who need it like it. You should allow for a 'smooth'
transition of a year or so, or tell them very long in advance.
Cookbooks like my 'biocomputing survival guide' :-) are very helpful.
I have written software for other GCG installations on each of the OS they
currently support. Silicon Graphics at our site was fine, but we use
molecular modelling as well, so it was the only possible buy at the time.
We're happy with Digital hardware as well and intend to run it additionally
on OSF/1 as a GCG version for this becomes available, and I would discourage
ULTRIX and SUNOS as these are dying systems. Go for Solaris and OSF/1, resp.
The final platform to choose is much dependent on your other requirements,
as mentioned, SGI is a good buy if you do modelling, if your site runs
DEC to a large extent maintenance and service might be cheaper with DEC
platforms. Solaris is reported to be much better with 2.3 as it used to be
with ealier versions and runs very fast on their large mp servers; if you
want to run GDB then a SUN is a must (with some additional quirks).
Software engineering/porting:
As all vendors move from 32 to 64 bit OS's there is a problem with old
applications (also with VMS migrating VAX to AXP), so don't expect that
PIR software from 1970 still runs in the future, and it wouldn't do for
sure on UNIX anyway as they used VMS specific code. ATLAS, their most
recent software, is running on UNIX as well. Consider any PASCAL or
similar DEC-spoilt language to be very time-consuming to port, so if
you have other software besides GCG make sure that you get (a) new versions
and (b) see whether you want the additional software at all. UNIX is nice
for X as aprocess is less costy than on VMS, but, a process on VMS is
much more luxory, so any inheritance of process attributes or other
system-related functions is a problem, e.g. timing in general might
become difficult to port if you have applications to port which used
SYS$QIOW or similar.
Maybe this helps. Please understand that these opinions are my own and
do not necessarily reflect my employer's view, or claim to be objective.
regards
Reinhard
DISCLAIMER
Note that the software mentioned resembles Computer Program(s) which
require a license in order to be run unless stated otherwise in a state-
ment codistributed with the software. The use of the program(s) was men-
tioned within a specific problem or example and must not be used to con-
clude that other software products cannot possibly do a similar job. Same
applies to all hardware or vendor products mentioned.
--
+---------------------------+-------------------------------------------+
| Dr. Reinhard Doelz | Tel. x41 61 2672247 Fax x41 61 2672078 |
| Biocomputing | electronic Mail doelz at urz.unibas.ch |
|Biozentrum der Universitaet+-------------------------------------------+
| Klingelbergstrasse 70 | EMBnet embnet at comp.bioz.unibas.ch |
|CH 4056 Basel SWITZERLAND | Switzerland gopher.embnet.unibas.ch |
+---------------------------+------------- http://beta.embnet.unibas.ch/
