----------------------------------------------------------------------
Sender: Francis R.Rysavy, Head, Computing Services,
Organisation: Medical Research Council-Clinical Research Centre &
Human Genome Mapping Project Resource Centre
Address: Watford Road, HARROW, Middlesex, U.K. HA1 3UJ
Phone: 081-869 3291, Internat. + 44 81 869 3291
Telex: 081-923410, Internat. + 44 81 923 410
Fax: 081-423 1275, Internat. + 44 81 423 1275
Janet: f.rysavy at UK.AC.CRC
Internet: f.rysavy at CRC.AC.UK
Earn/Bitnet: f.rysavy%CRC at UKACRL
Usenet: ...!mcsun!ukc!mrccrc!F.Rysavy or F.Rysavy at mrccrc.uucp
-----------------------------------------------------------------------
We have been running a large client/server network for now about 1000
users. Details of the UK Humane Genome Mapping Project online computing service were just published in CABIOS, Vol.8.no2.1992,Pages 149-154.
> X windows seems to be replacing VT100/Tektronix as the new de facto
> "standard" environment for molecular biology (and other) programs. I
> don't want to discuss the technical merits of this trend, but I think
> that a little thought should be given to the cost, both for
> hardware/software and for effort integrating these applications. I'll tilt
> this discussion towards X window programmers and system managers (ie, those
> of us who have to make software accessible to a group of users.)
Facing and evaluating the same problem.
> Background. This is how things are here: we've got around 100 Macs
> and PC's, one (B&W) VaxStation console, and one (B&W) SPARCstation
> console. One or two of the labs have their own Unix boxes. So,if any
> significant number of these users are to have access to this new
> generation of X based software using existing hardware, they are going
> to need Mac and PC X window servers. At the moment, these users
> utilize VT100/Tektronix mode emulation for 99% of the software that
> runs on the Vax, but we've got a couple of people running MacX to use
> ACEDB on the SPARC.
We are running X applications such as databases of interest to
molecular biology and genetics scientists that have already have an
X version, including the cDNA database and the Mouse Backcross
database. The Genome Data Base (GDB) is expected to get the X
graphical interface soon. Other examples of currently available X
programs include xrn which provides a comfortable environment
for reading network news bulletins, the X version of the Staden
software, the nematode genome database system (acedb) and others.
We are using the eXceed X display software for IBM and IBM compatible
PC's, do not know enough about something similar for Macs.
> And now a few questions:
>> 1. Can your existing Unix and VMS machines support as many
> simultaneous X client applications as needed to keep the users
> happy?
Started doing some measurements, however the first guess is that a
separate processor will be needed. How big for how many people we dinot
know yet. Are prepared to share insights in due course.
> [Here, no way. We've only got a Sparc 1 and a VAXstation 3100m38,
> that's plenty for VT100/Tek, but not nearly enough horsepower for lots
> of simultaneous X sessions.]
>> 2. How many of your users' existing Macs and PCs could run X servers?
>> [Here, about a third. A lot of the existing systems either are too
> underpowered (Mac Plus, Original PC's) or don't have enough disk or
> memory. They can pretty much all run VT100 emulators and around 90%
> can also do Tektronix emulation.]
Similar situation if not worse. A "reasonable" configuration of a
personal computer should have a colour screen of the highest quality,
size 17 inches and resolution 1024 by 768 is recommended; an
appropriate graphics card; an ethernet card; not less than 4 Mbytes,
preferably 8 Mbytes of memory and a three button mouse. Not many of
those around. Very little if any experience with Macs.
> 3. How are you going to put X servers on all of those Macs and PCs?
>> [Putting _legal_ copies of commercial X server packages on all of our
> PCs and Macs is going to cost serious money. To give you a clue on the
> environment, a lot of ours are running NCSA Telnet, MacIP, or Kermit,
> ie, their owners either were not willing or not able to pay for
> commercial terminal emulators.]
We have a site deal for eXceed.
> 4. Do any of your users dial in to use your systems?
>> [Here, fewer and fewer since we've finally got the ethernet into all
> of the labs. However, quite a few people work on papers and such at
> home. Things are already pretty slow for them at 2400 baud in
> character mode. Maybe they could run X windows over SLIP, but I bet
> that they wouldn't like it.]
Yes and this might cause problem in due course. Any insights welcome.
> 5. Have you ever seen public domain X window servers for PC's running
> DOS and Windows, and Mac's running System 6 or 7?
>> [I've not encountered these programs, but I'd love to have them if
> they already exist.]
The answer is no.
> Now that I've grumped about the cost of the interface, here are my
> suggestions to X window program developers to help us minimize these
> costs:
>> 1. ALWAYS put in a character mode interface. This should be in two
> versions, instead of, and in addition to, the X interface. Your
> program will run on practically anything and TO practically anything.
> It will also be possible to access it via scripts. We can migrate to
> its X window capabilites as our budget permits. Yeah, I know, low
> tech, stone age, etc., but guess what, a lot of us still have to work
> at this level.
Might be to expensive for the developers.
> 2. When you add graphics, have some way for the character mode to
> send graphics to a file and to the screen. It doesn't matter so much
> if it is Tektronix, GKS, or whatever. If we can get our hands on it,
> then we can reformat it enough to look at it. Obviously, this isn't
> for interactive graphics applications. But then, how much interactive
> graphics does one _really_ need in a database?
>> 3 Have mercy on those users who have B&W or 4 bit grey scale
> screens. Ditto for those without 1000 x 1000 screens.
>> 4 Mice come with 3/2/1 buttons. Using option up-arrow mouse-button
> is a miserable way to access a program option. Set it up so that your
> program works reasonably with the number of physical buttons on the
> user's mouse. Also, stay away from weird control key mouse button
> combinations - they are user hostile.
>> 5 How about next time you get an urge to write a graphical DNA
> editor, write a public domain X server for either the PC or the Mac
> instead? Yeah, it's not a trivial undertaking (I know that I couldn't
> do it), but it would be really nice to have this software around. Just
> think, if you write this then you will have increased the "market" for
> your other X window software by about 10x !
>>> That's enough gasoline on the fire for one day.
>> David Mathog
>mathog at seqvax.caltech.edu> manager, sequence analaysis facility, biology division, Caltech
>>We stay in touch and when we have more experience, we will share it.
Kind Regards
Francis
