X Window Interface [long], [and getting longer...]

Ernest Retzel 1535 49118 ernest at lenti.med.umn.edu
Sun Apr 19 13:41:14 EST 1992

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

> 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? 
> [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 don't mean to be critical, but this is not really what those machines
were meant to be used for.  They are still workstations, generally considered
to be single-user environments.  Certainly they are multi-user and
multi-tasking, but they are not servers.  If you are going in this direction,
you will be disappointed, and be unhappy with Sun and DEC or whoever your
workstation manufacturer is.  The only environments that I know where they
have made this conscious decision are using an eight-processor SGI as the
compute server and X-client, and it is crammed full of memory [256 MB] and
fast [IPI] disks.  And Sun3's as X-terminals [see below].

> 3. How are you going to put X servers on all of those Macs and PCs? 

We aren't.  We don't really think this is a particularly good solution.
In general, the minimal configuration for a PC class machine is a 386/
4meg; for Mac, ci plus same.  And an ethernet card [CAP and a Kinetics 
or Gator box don't count].  The screens generally don't have enough
pixels to be particularly useful, certainly not when we are using
a full megapixel screen for data.

> [Putting _legal_ copies of commercial X server packages on all of our
> PCs and Macs is going to cost serious money. 

Putting pirate copies up could cost more, in terms of copyright infringement.

> 4. Do any of your users dial in to use your systems? 
> [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.] 

The only realistic way to do this is with a dedicated X-terminal designed
for the purpose.  The only ones where this has been a consideration are 
GraphOn [great remote X idea, but expect to return your monitor for 
repair every 3-4 months when the video dies], and NCD [not as good an 
implementation, but at least you can throw away the shipping box].  
Both of these need v.32 or higher [14.4/19.6 kbaud], the NCD particularly.

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

No, and most of the commercial emulators don't do a very good job,

<Missives to developers follow...>

> 1.  ALWAYS put in a character mode interface.  

We used to do this.  Until we realized that people would wait for an X
environment rather than use the character mode.  So we stopped.
Basically, X is not being used as a pretty front end; it is being used
the way it was supposed to be used, as an extension to the process of 
designing programs, and as a means of inter-client communication.  It is
integral to the function of the program, not just something cute.

> Yeah, I know, low
> tech, stone age, etc., but guess what, a lot of us still have to work
> at this level. 

I can appreciate that, but that is not the point of what we are trying to
do.  We use InterViews and X to *make new things possible* rather than to
provide a pretty front end for previous solutions.

> 2.  When you add graphics

We don't *add* graphics; the graphics we use are designed in to change the
way that you interact with and think about the data you are looking at.
What we are working toward is, among other things, non-text representations 
of information, primary and derived, and are trying to put the tools in 
place that do that.

> But then, how much interactive
> graphics does one _really_ need in a database? 

I would turn that question around, and ask, "How little text can one get
away with in a database, particularly at the level that the user needs to
interact with it?"

> 3   Have mercy on those users who have B&W or 4 bit grey scale
> screens.  Ditto for those without 1000 x 1000 screens. 

All I can say is, there are better solutions out there, for not very much
money [certainly in the vicinity of what you are talking about].  A small
[small is 14"...] mono NCD can be bought for less than 1 k$.  Sun 3/50's
[a technology that is about to die as a compute environment with the next 
major OS release] can be bought used from commercial sources for $500, 
and the streetprice from the people they bought them from is $250.  These 
are Dandy X-terms: ethernet built-in, 4 megs of memory, million pixel 19" 
displays...and a 3-button mouse!

> 4   Mice come with 3/2/1 buttons.  

See above. 8^)

> Using option up-arrow mouse-button
> is a miserable way to access a program option.  

Couldn't agree with you more.  That's why mice have 3 buttons....
[ 8^)--lighten up!!! ]

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

I will go back to the original premise; this is not a good solution.
It is not even a practical one.  Even the commercial emulators, where the
developers have spent a lot of time doing very clever things to optimize
performance, are only just comparable to X-terminals.  And all that
optimization costs time to them, and therefore money.  For which you have
to pay.  And it still doesn't get you where you want to be.

I should probably stop now, but I won't [probably bad judgement on my part].
I would go a step further, and take issue with Don Gilbert [from a few
months ago], saying that Mac/AUX was a better solution than, say, putting
a Sun on a researcher's desk.  We prefer to do the latter, and so do many of
the researchers here.  It can be done more cost effectively and extensibly
than putting Unix on personals, and if you are *really* attached to the
Mac or PC environment, you can run all those programs under an emulator
[assuming they are sufficiently well behaved to operate there].  Not mention
that you can run all those other Unix programs as well....

[Standard disclaimers about DEC, GraphOn, NCD, Sun, Mac and anyone else
I might have mentioned in passing.]

Ernest F. Retzel
Dept. of Microbiology
Univ. of Minnesota
Minneapolis, MN

ernest at lenti.med.umn.edu

More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net