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