From: doelz@comp.bioz.unibas.ch (Reinhard Doelz)
Newsgroups: bionet.software
Subject: RE: Re: X window interface (long) [even longer]
Keywords: hopeless future, X Window.
Date: 16 Apr 92 19:24:42 GMT
Distribution: bionet
Organization: EMBnet Switzerland [Basel]

| 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.

Making me think that you have huge resources. I'm supporting about 300 
people on-site and more in the country who have nearly all plain 
VT100 type of access. The problem is threefold (see below). 

> 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.
 
1) Costs for the groups. 
Starters in the business (young group leaders) often face the problem 
of having too little resources for their scientific work anyhow. Cutting 
budgets merely starts with cutting at the computer/result processing part, 
i.e. either the old vt100 is honoured or they try to catch up with 
Public Domain PC/MS-DOS utilities. 

2) Costs in terms of software. 
Reasonable software is still a price issue. Whereas it is impossible at this 
site to get a commercial Mac or PC package for $1000 each at 100 Macs, 
the mainfraime solution is more cost-effective still. No doubt that 
established packages lack flexibility and comfort (e.g., the current 
GCG does not support GUI's) but it is much better to have a few licenses 
for 300 users than 100 licenses for 300. 

3) Costs in terms of networking. 
The initial setup was paid by the university. This is a plain serial 
connectivity. Any attempt to get ethernet in each room would be to be 
paid by individual research groups --> impossible. The last proposal I made 
for ethernetting the building would have been $300K and was rejected. 
Yes, it could be cheaper. But it doesn't make sense to forget the 
electronics (routers), staff (maintenance!), and running cost. In addition 
to the extra cost for workstations (not mentioned here but see above ). 

> 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. 

ACEDB is really an excellent piece of software. I will support it for 
another university here on my machine so that they can use it across 
the net. This is already a typical example: The group is 15 people, and 
they have budgets for a workstation only next year. But even if they had 
it now, they are totally depending on external help for system management
and maintenance. 

|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.

We use MacX only a little. On localTalk it is too slow, and the small 
screen is difficult to use. In order to get real benefit out of it 
you will need to have larger screens than the usual Mac. I cannot imagine 
that the situation is better on PCs. 

> 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.

It is mainly a question of memory. We are using up to 10 X sessions on 
a VAX 8xxx and it gets difficult if the machine starts swapping. On UNIX, 
the situation is less critical with number of processes but worse in terms 
of that these guys use all goodies they can get (xbiff, xclock, xeyes, etc) 
to clutter the memory with useless things. 

> [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.] 
>

I have made good experience with (SGI) Indigoes. These small beasts are the 
fastest Xterminals I've ever seen and can support others rather easily 
(if you've gotten about 4 Megs of RAM per X session). 
 
> 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.
 
A reasonable Mac doing this is nearly around $10K. Once someone wants to 
do this I recommend to spend another $5K and get a workstation with UNIX 
on it. Prices are dropping, and the permanent blowing up of small 
device engines up to the limit is not extendable easily without further
investment. Once you've gotten a reasonable UNIX baby you can upgrade it 
with less effort than a high-powered PC. 


> 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.
 
That breaks some necks. I don't think that site deals are possible 
everywhere, and you should not forget that these high-end PCs and low-
end Workstations are real costy in mainetence!

> 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.
 
I am just tryoing 9600 SLIP from the indigo across LAT and modem. It 
sort of works for Xterm and cheap clicking. Once you've gotten more 
complicated software which does an entire redraw each time it takes 
very long. It would be extremely useful to have better compression in 
SLIP than the standard (i.e., lower protocol overhead). 

> 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.
 
And even if they would: You get what you deserve. Public domain is 
nice for niche software. But I hate to build a strategy on a hack 
which isn't supported and costs me more work than a reasonable product
costs. 

> 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. 
 
Not at all. besides the few sites who can afford X right now the potential 
of migration is severely depending on the availability of the software 
to the poor masses. 

> 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? 
>

ACEDB is excellent. With some caching tricks the server can be more 
effectively used. However, the question is also COLORS. Once you omit 
the colors you need to put in more gimmicks to emphasize or strengthen 
things. Once you can trust in colors, the need for interactivity is 
less because you can order information much mor epacked without the 
permanent need to have bubbles or whwtever popups. This also applies 
for the screen resolution. 
 
> 3   Have mercy on those users who have B&W or 4 bit grey scale
> screens.  Ditto for those without 1000 x 1000 screens. 
>

No mercy - see above. If you have a terminal vt100 and want to migrate
to X then do it right. Don't pay lots of money and stop half-way. 
 
> 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. 
>

Gets me to the motif style guide. Have ESC or other mnemonics ALWAYS 
buolt in in case that it gets more convenient to use key shortcuts 
rather than clicking. 
 
> 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@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

I'd love to share experience but I know that these dreams are 
currently miles away from today's budgets. We'd develop software for 
tomorrow but need it NOW. 

Regards 
Reinhard 


-- 
+----------------------------------+-------------------------------------+
|    Dr. Reinhard Doelz            | RFC     doelz@urz.unibas.ch         |
|      Biocomputing                | DECNET  20579::48130::doelz         |
|Biozentrum der Universitaet       | X25     022846211142051::embnet     |
|   Klingelbergstrasse 70          | FAX     x41 61 261- 6760 or 2078    | 
|     CH 4056 Basel                | TEL     x41 61 267- 2076 or 2247    |   
+------------- bioftp.unibas.ch is the SWISS EMBnet node ----------------+
               -----------------------------------------