gilbertd@cricket.bio.indiana.edu (Don Gilbert) (02/13/91)
I've been learning How Unix Works over the past month, and thought that I'd share some of the highlights in relation to biology computing. Many of you are already enscounced in Unix and this may be Old Stuff. If so, you may have comments on useful points that I've missed or have garbled. One of the current interests in computational molecular biology is making the rapidly growing databases more accessible to scientists. One option is friendly software running on central or departmental computers, which seems easier than keeping personal computers supplied with up-to-date multi-megabyte data. X-Windows is the Unix (and VMS) sibling of a Macintosh or MS-Windows graphic user interface. The main attribute of X-Window software in my mind is that it is networkable -- software and data reside on a central computer where they can be better updated and shared among groups of researchers. I'd like to hear your comments on whether X-Windows software for molecular biology will grow in importance over the coming decade over personal computer software. Also, are you currently using X- Window software? Do you expect to in the next year or so? Object oriented programming languages, such as C++, provide a more rapid way of developing and updating complex software that manages a graphic user interface. InterViews is a good C++ based, X-Windows toolkit for Unix that provides an extensible program foundation, in much the same way as MacApp does for the Macintosh. The importance of an object oriented programming language with a good application skeleton, such as C++/InterViews or C++/MacApp, is that the general program and user interface handlers are already there. A programmer need only install functions specific to the task and customize it as needed, saving much labor. Installing Unix system, gcc and g++ compilers, X-Windows and InterViews software on an A/UX Macintosh took me about a week. Learning enough C++ and InterViews to build a simple Drosophila database browser took me another week. My strong impression is that the C++ / InterViews combination is a rapid and powerful way to build networkable programs, and is well suited to programmers developing biological applications. While InterViews is currently only available for X-Windows on Unix, it is designed so that other window systems may be incorporated in the future. This would let programmers develop one program to run on many window platforms, including Mac and MS- Windows. Software Cited: -- InterViews, a C++, X Windows toolkit. Anonymous ftp to interviews.stanford.edu. -- GNU C and C++ (gcc and g++) compilers. See Usenet newsgroups gnu.g++.* and gnu.gcc.* -- X Windows. See Usenet newsgroup comp.windows.x -- Don Gilbert gilbert@bio.indiana.edu biocomputing office, biology dept., indiana univ., bloomington, in 47405
kristoff@genbank.bio.net (David Kristofferson) (02/13/91)
> I'd like to hear your comments on whether X-Windows software for > molecular biology will grow in importance over the coming decade > over personal computer software. Also, are you currently using X- > Window software? Do you expect to in the next year or so? Don, As long as you are speaking in decades I am sure that the answer is yes 8-). I still think that the standard Mac interface remains the most popular for biologists in the near term and am unsure of the appeal of A/UX. I personally use an X terminal which serves off of one of our Sun fileservers for most of my work. X terminals utilize X windows (obviously). They have the advantage of being cheaper than a workstation (or a Mac loaded up enough to run A/UX) and allow one the same type of working environment, i.e., multiple windows, cutting and pasting, etc. However, within the windows themselves I am simply running the various standard character-based software on GOS. Others in the systems group here are running software written specifically for X windows in their environments, but I haven't had sufficient need yet to "upgrade" since my current set up handles my needs quite adequately (the old inertia problem again 8-)! But then, I am a humble administrator, not a software engineer, and my needs are not complex. From a commercial developer's standpoint the size of the molecular biology software market makes it essential to produce software that runs on as many different platforms as possible with minimal additional coding effort. This portability grail has been elusive in the past, but because of developments like X, it is rapidly becoming realizable. Dave
roy@alanine.phri.nyu.edu (Roy Smith) (02/14/91)
gilbertd@cricket.bio.indiana.edu writes: > I've been learning How Unix Works over the past month You must be a fast learner. It's taken me 10 years, and I'm still not sure I know what's going on all the time! > X-Windows is the Unix (and VMS) sibling of a Macintosh or MS-Windows > graphic user interface. There is nothing about X (in theory) that ties it to Unix (or VMS, or any other operating system). The big win, in my mind, will be that you can run an X server on your Mac and use an application on a Cray somewhere else in the world. There is another windowing system called NeWS which was being pushed by Sun a couple of years back as a competitor to X. There are lots of reasons why I thought (and still think) that NeWS is superior to X, but the basic fact is that X seems to have won out; even Sun has hopped on the X bandwagon, although they are walking a fine line trying to keep their NeWS customers happy too. I'm of mixed mind about whether X (or NeWS) will be a big thing in the laboratory environment. It takes quite a bit of horsepower to run an X server (or, for that matter, a NeWS server; my 8 Mbyte Sun-3/50 is pretty marginal for either). You really need something like a 12 Mbyte SPARCStation before you will be happy, from what I understand. I just don't see that much horsepower being common on benchtops and biologists' office desks anytime soon. What I do see is lots of Mac Plus/SE/Classics and the occasional Mac-IIcx/si/ci and lots of 286-based DOS machines, and the occasional 386. I don't see too many of them on high speed networks (i.e. ethernet; I don't think you would be very happy running X over LocalTalk) and I don't see that changing much in the next couple of years. Biologist who are really into computers already have the big machines needed to run X (Mac-IIfx, SPARCStation, Iris, DECStation, etc) and will continue to upgrade those machines, but I don't see them getting into the vast majority of the labs and offices. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
wrindone@bbn.com (Wayne Rindone) (02/15/91)
In article <1991Feb13.005957.3523@bronze.ucs.indiana.edu> gilbertd@cricket.bio.indiana.edu (Don Gilbert) writes: > >I'd like to hear your comments on whether X-Windows software for >molecular biology will grow in importance over the coming decade >over personal computer software. Also, are you currently using X- >Window software? Do you expect to in the next year or so? > I guess you can count me among those convinced of the growing importance of X-window software in these sorts of applications. I am a member of the group at BBN that works on the NIH Prophet System, which includes sequence analysis tools in addition to tools for a wide range of other life science computing applications - statistics, graphing, curve fitting, mathematical modeling, molecular structure analysis and display, among others. Our primary graphic support is for X-window environments. We also support Sunview displays and have not yet completely phased out Tektronix 4107 graphic support. The X-window displays work on all the platforms that Prophet runs on - Sun-3, Sun-4, SPARCstation, VAX Ultrix, and RISC DECstation (and a Mac II A/UX version that is nearly ready) and really pays off in networked multimachine environments like the one we have here. From our office workstations - Sun 3/50's running X11R4 or Macs with Mac-X - we can connect to a faster Sun-4 or DECstation (or a larger Mac II running A/UX) and get everything from molecular displays to Prophet's new graphical dialogs up on the workstations on our desks. When it comes to Prophet's graphical dialogs, we do have to utilize an X toolkit appropriate to the machine Prophet is running on. So far this has been the DECwindows toolkit for the VAX and DECstation, Xview (OpenWindows) for the Sun's, and we are working with a Motif toolkit provided for the Mac II by a company called Integrated Computer Solutions. The graphical dialogs also work using the Sunview toolkit, but not from a remote machine, and the old Tektronix is out of the picture when it comes to the graphical dialogs. The interconnectivity among the different types of Unix machines we maintain Prophet on has been critical to keeping the same version of Prophet running on all the platforms. Through the magic of nfs, every week night a new Prophet version is automatically built and a large suite of automatic regression tests are run on each different machine. Much of our enthusiasm for Unix and for X windows is of course based on how much easier it makes our job as software developers, but we also hear from assorted NIH funded operations that are considering or have obtained Unix workstations. Only in a few cases do they already have auxiliary X terminals in place, but in many more cases they are in the midst of getting funding to purchase X terminals, and in nearly all cases have at least factored them in to their long term plans. Nearly all, however, certainly have PC's as part of their picture for the foreseeable future as well. As PC's get more powerful, and Unix workstations get cheaper, it is likely to become more and more difficult to tell the difference. Should be fascinating to observe this continuing development over the coming years. Wayne Rindone
X03@psuvm.psu.edu (02/15/91)
I have a question about using X terminal. Currently we are using Silicon Graphics IRIS for protein structure manipulation. The programs we have are QUANTA, MIDAS,... My question is, if it's possible to run such programs from an X terminal, since these programs are graphics extensive applications. Do I need a special type of X ternimal, or, say, using MacX to turn a Mac into a X ternimal also works? BTW, read comp.windows.x for more technique discussions about X windows. Any suggestions? Xiaowu Chen Dept Chemistry Penn State
gilbertd@cricket.bio.indiana.edu (Don Gilbert) (02/15/91)
In article <91045.175752X03@psuvm.psu.edu> X03@psuvm.psu.edu writes: >I have a question about using X terminal. Currently we are using Silicon >Graphics IRIS for protein structure manipulation. The programs we have are >QUANTA, MIDAS,... My question is, if it's possible to run such programs from >an X terminal, since these programs are graphics extensive applications. Do I >need a special type of X ternimal, or, say, using MacX to turn a Mac into a >X ternimal also works? Molecular modelling software requires very intesive use of displays. X-Windows also has a very high computing and network "expense" associated with it. While putting the two together may be possible, it will likely lead to a very slow, unacceptably slow program. MacX adds an even greater drag on this system compared to using, say, an IRIS for your X-Terminal. But I'm no expert in this area. -- Don -- Don Gilbert gilbert@bio.indiana.edu biocomputing office, biology dept., indiana univ., bloomington, in 47405
dow@presto.ig.com (Christopher Dow) (02/15/91)
Ok, time for my $0.02. On the issue of C++: Currently, in most available implimentations, C++ is a translated language. This means that it is tranlated into some other language and then compiled into object modules. If the intermediate phase is saved (i.e. the translator translates C++ into C, then a C file is saved, which isn't always the case), when you go to debug the code (and you will have to do this), what you see is C code generated by a program. Programs don't write particularly readable code, and therefore, you end up not getting much useful information from the debugger. Even if you are able to figure out the C code, you still have to determine what that means in the C++ code that _you_ wrote. This makes debugging a nightmare. Also, C code generated by C++ translators is not known for its speed. Searching a 30 MegaBase chromosome is not something you want to do with a program that was written in C++. On the issue of X: First, the product is called "The X Window System" it is trademarked by MIT. The short form is "X". X was originally developed at MIT to integrate all their fancy fast hardware and their fancy neato graphics systems which at that time were not compatible at all. X consists of two basic units: the client, and the server. The server is a program which runs on the machine that has the graphics, keyboard, and mouse, since the service is access to them. The client is the program which requests these services through either inter-process communication or a network connection, depending on the location of the client and server (same machine: IPC, different machines: network connection). X is a very large system (the Sever is about 2 MegaBytes on a Sun workstation), so the number of platforms it can be ported to is small (i.e., no 8080's and it won't work well with 8088's). However, I will say that X is the wave of the future (IMHO), and if developers don't use it now they will have to use it later. I think that eventually computers that are X-capable will be cheap enough for everyone to have them. I personally own one now. So X is a great idea, whose time is about to come. On the specific case of InterViews: InterViews is a nice academic environment. By academic, I mean unsupported. If something goes wrong either you have to fix it, or wait until the author does (this is from experience). It does, however, do some things that impress me. One of them is IDraw. Take a look at it if you get a chance. We use it religiously for internal documents. As far as Unix goes, I think that not all of the molecular biology community are ready to maintain a unix system. That is why at IntelliGenetics, we have a commitment to covering as many platforms as we can. At Human Genome II, we showed pictures of a future product running on a Macintosh, a Sun, and MicroSoft Windows, in addition to the Sun version running on a Sun and the display going to a MacX server on a Macintosh, where the Mac version was also running. I hope that the two main groups working to standardize Unix and Unix-like operating systems (Unix International and the Open Software Foundation) will take the needs of users to be able to maintain the system into account, and I know that NeXT already has. However, until the more 'personal' operating systems have some of the same features that Unix and VMS have, I think that software on these platforms will be more powerful. Sorry, that was more like $0.60. Chris Dow IntelliGenetics Software Engineer 700 East El Camino Real icbmnet: 37 22' 39" N, 122 3' 32" W Mountain View, Ca. 94040 dow@presto.ig.com (415) 962-7320
brsmith@cs.umn.edu (Brian R. Smith) (02/16/91)
In <Feb.14.16.37.15.1991.4935@presto.ig.com> dow@presto.ig.com (Christopher Dow) writes: > On the issue of C++: > Currently, in most available implimentations, C++ is a >translated language. Get g++ and gdb. G++ is a native C++ compiler (NOT a translator), and gdb has c++ debugging support built in (recent versions, anyway). See their manuals for complete details. >[...] Also, C code generated by C++ translators is not known for its >speed. Searching a 30 MegaBase chromosome is not something you want >to do with a program that was written in C++. Depends on the program, methinks. You can, after all, write straight C code and compile it with a C++ compiler if you like. I'm of the opinion that well-written C++ should be *faster* than comparable C code - because the function disambiguation and subclassing takes place at compile time. I don't have any numbers to back me up, though. > On the issue of X: >X is a very large system (the Sever is about 2 MegaBytes on a Sun >workstation), so the number of platforms it can be ported to is small >(i.e., no 8080's and it won't work well with 8088's). Hmmm. My server (Xsun) is only at 1.3meg right now. That's smaller than my editor! (GNU emacs, of course - ok, it's a little bloated) Still, that's not *large* for a Unix system. No, it's not going to run on an ancient PC, but most Unix workstations being produced now can deal with it (and many have it pre-installed, in some form). > On the specific case of InterViews: > InterViews is a nice academic environment. By academic, I >mean unsupported. If something goes wrong either you have to fix it, >or wait until the author does (this is from experience). The same is true of the free distribution of X available from MIT. BUT, when you have source code (and when the software is that well written and tested), support isn't as much of an issue. Also, if I remember correctly, the X Consortium is adopting InterViews as the default X-C++ interface. I'm unsure of the exact details, but such a move would place InterViews right alongside X as a standard. >I hope that the two main groups working to standardize Unix and >Unix-like operating systems (Unix International and the Open Software >Foundation) will take the needs of users to be able to maintain the >system into account, and I know that NeXT already has. Funny, that: NeXT doesn't even allow you to use X as the default windowing system. You have to run it (at best) in a window under NeXTStep. I don't consider that very helpful. I should mention that this is hardly an unbiased opionion (even if there is such a beast). I program for and love InterViews and C++. -- Brian brsmith@cs.umn.edu <This space intentionally left almost blank.>
dow@presto.ig.com (Christopher Dow) (02/16/91)
In article <1991Feb15.202358.1984@cs.umn.edu>, brsmith@cs.umn.edu (Brian R. Smith) writes: > In <Feb.14.16.37.15.1991.4935@presto.ig.com> dow@presto.ig.com (Christopher Dow) writes: > > > On the issue of C++: > > Currently, in most available implimentations, C++ is a > >translated language. > > Get g++ and gdb. G++ is a native C++ compiler (NOT a translator), and > gdb has c++ debugging support built in (recent versions, anyway). See > their manuals for complete details. Unless, of course, you wish to _eat_ by selling what you write (my .sig ins wholly unambiguous). The Free Software Foundation makes it clear that they do not want, and can leagally prevent you from, using their software for commercial software > >[...] Also, C code generated by C++ translators is not known for its > >speed. Searching a 30 MegaBase chromosome is not something you want > >to do with a program that was written in C++. > > Depends on the program, methinks. You can, after all, write straight > C code and compile it with a C++ compiler if you like. I'm of the > opinion that well-written C++ should be *faster* than comparable C > code - because the function disambiguation and subclassing takes place > at compile time. I don't have any numbers to back me up, though. I wont argue this point with someone whose .sig leads me to believe he is a professor of computer science ;-). > > > On the issue of X: > >X is a very large system (the Sever is about 2 MegaBytes on a Sun > >workstation), so the number of platforms it can be ported to is small > >(i.e., no 8080's and it won't work well with 8088's). > > Hmmm. My server (Xsun) is only at 1.3meg right now. That's smaller > than my editor! (GNU emacs, of course - ok, it's a little bloated) > > Still, that's not *large* for a Unix system. No, it's not going to > run on an ancient PC, but most Unix workstations being produced now > can deal with it (and many have it pre-installed, in some form). Some in this thread have mentioned specific platforms which will not support X server software. However, I do stand corrected, as my X11R4 server is 704K (What did you do to make it so big?). > > > On the specific case of InterViews: > > InterViews is a nice academic environment. By academic, I > >mean unsupported. If something goes wrong either you have to fix it, > >or wait until the author does (this is from experience). > > The same is true of the free distribution of X available from MIT. > BUT, when you have source code (and when the software is that well > written and tested), support isn't as much of an issue. Also, if I > remember correctly, the X Consortium is adopting InterViews as the > default X-C++ interface. I'm unsure of the exact details, but such a > move would place InterViews right alongside X as a standard. However, it is much cheaper to purchase commercially developed software than to hire a programmer to support it. We are talking about biologists, and I don't think too many biology-related curicula require the coursework or experience needed to support such systems. > > >I hope that the two main groups working to standardize Unix and > >Unix-like operating systems (Unix International and the Open Software > >Foundation) will take the needs of users to be able to maintain the > >system into account, and I know that NeXT already has. > > Funny, that: NeXT doesn't even allow you to use X as the default > windowing system. You have to run it (at best) in a window under > NeXTStep. I don't consider that very helpful. Never said it did. I'm just saying that I believe they have a better approach to running a unix-like system than others, and I wish that UI and OSF would make creating this type of system a priority. > -- > Brian > brsmith@cs.umn.edu <This space intentionally left almost blank.> Chris Dow IntelliGenetics Software Engineer 700 East El Camino Real icbmnet: 37 22' 39" N, 122 3' 32" W Mountain View, Ca. 94040 dow@presto.ig.com (415) 962-7320
Davison@UH.EDU (Dan Davison) (02/17/91)
A comment about the Free Software Foundation's commerical software policy is not true: > Unless, of course, you wish to _eat_ by selling what you write > (my .sig ins wholly unambiguous). The Free Software Foundation makes > it clear that they do not want, and can leagally prevent you from, > using their software for commercial software > Chris Dow IntelliGenetics Wrong. Perhaps you should read the notice again? Or take a look at the software on the NeXT? You can use it commerically *if* you also distribute source code and make available the compilers for a media charge. MIPS, Alliant, NeXT haven't hand a problem selling their software. There are also restrictions I have not followed on the use of the g++ libraries, but this is not a particular problem to others, apparently. See gnu.misc for an ongoing discussion of the exact meaning of the FSF's General Public Licence. dan -- dr. dan davison/dept. of biochemical and biophysical sciences/univ. of Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU Disclaimer: As always, I speak only for myself, and, usually, only to myself.
jkramer@molbio.med.miami.edu (Jack Kramer) (02/17/91)
In article <9102161836.AA03122@menudo.uh.edu> Davison@UH.EDU (Dan Davison) writes: >A comment about the Free Software Foundation's commerical software >policy is not true: > > >> Unless, of course, you wish to _eat_ by selling what you write >> Chris Dow IntelliGenetics > >the software on the NeXT? You can use it commerically *if* you also >distribute source code and make available the compilers for a media >charge. MIPS, Alliant, NeXT haven't hand a problem selling their > The obvious solution would be for ALL vendors of major academic software packages to distribute the source as part of licensing. The most popular molecular biology package vendor already does and I believe that this is a primary reason for its popularity.
brsmith@cs.umn.edu (Brian R. Smith) (02/18/91)
In <Feb.15.15.02.46.1991.12254@presto.ig.com> dow@presto.ig.com (Christopher Dow) writes: >In article <1991Feb15.202358.1984@cs.umn.edu>, brsmith@cs.umn.edu (Brian >R. Smith) writes: > Unless, of course, you wish to _eat_ by selling what you write >(my .sig ins wholly unambiguous). The Free Software Foundation makes >it clear that they do not want, and can legally prevent you from, >using their software for commercial software Not exactly. You are not allowed to use parts of GNU software in commercial software UNLESS you supply source code (for the GNU part) and some way to re-link the binaries. (But don't take my word for it - FSF is pretty clear on this point.) You CAN, though, use GNU software to compile YOUR code without restrictions. I assume the same goes for g++. You do have to be careful not to use the GNU libraries, but that's not that hard for gcc. For G++, I admit, it could be tricky. [...Opinion volleying over speed of C++ code...] > I wont argue this point with someone whose .sig leads me to >believe he is a professor of computer science ;-). I guess I should take that as a compliment. I've only had my B.S. for eight months now... :-) > Some in this thread have mentioned specific platforms which >will not support X server software. However, I do stand corrected, >as my X11R4 server is 704K (What did you do to make it so big?). My X11R4 server is running on a 1600x1280 screen on a sparc-based system, which may be part of it. Yes, there are platforms that do not (or cannot) support X. I don't mean to sound snobbish, but I think they'll fall by the wayside. (Even if you get a Mac or PC X server, you still can't run a program on the Mac/PC and display on another X server - it's only a one-way support.) And, if they are replaced by Unix machines, many departments are going to HAVE to hire an experienced system administrator to care for and feed them. Even if workstation manufacturers manage to put a workable system administration layer over Unix (as NeXT is trying to do), the underlying software still must be understood. I can't see any way around it. Unix is already complex, and it's not going to get any simpler. > However, it is much cheaper to purchase commercially developed >software than to hire a programmer to support it. We are talking >about biologists, and I don't think too many biology-related curicula >require the coursework or experience needed to support such systems. I'll grant you that. But, even working as a part-time undergrad for the CS dept, I had time enough to find, patch, and report several minor (but annoying) bugs in the X release and surrounding programs. All in all, I'd say it took me less time to find the problem in the source and recompile than it would to phone a support center and explain the problem. Anyway, as to your original points: C++ produces slow (translated) code, and g++ is not suitable for your needs; I can only say that commercial native-C++ compilers (rather than the translators) should be available in the near-future, if they aren't already. X is the wave of the future; I think we agree there. I'd go further and say the X will also help Unix supplant various proprietary OS's. InterViews isn't yet production-quality or widely supported software; True. I think it will be, though, with MIT X consortium support. And, IMHO, it makes developing GUI-based tools much simpler and faster than anything else I've tried. (My experience is limited to Xview, Xt, and straight Xlib, however.) That should be enough opinion-mongering for tonight. -- Brian brsmith@cs.umn.edu <This space intentionally left almost blank.>
dow@presto.ig.com (Christopher Dow) (02/18/91)
(Whew! we've managed to keep the tone considerabley more civilized than that of other bionet groups lately [I won't mention names]) Final statement on gcc: We (Engineering at IG) have found that it is somewhat difficult to get gcc-compiled code to work with non-gcc-compiled libraries (a more technical explanation should be held elsewhere, but it has to do with differing ways to return structs on the stack). Unix: Well, it would be nice if departments would hire programmers to support unix and the source code to products that are distributed commercially or free of charge, but my own experience with organizations at two different universities -University of Oklahoma and University of Wisconsin-and my second-hand knowledge of another department at the latter, lead me to believe that it is difficult, if not impossible, to coordinate such efforts. Let me qualify that by saying that this is obviously not a good statistical sampling, and I'm sure that many, many, examples to the contrary exist. In general, I think that unix will only win the OS war (OS/2 1.0 2.0 3.0 , VMS, OSF/1, SysVR4, BSD 4.4, ad nauseum) if it becomes more palletable to the run-of-the-mill computer user. Certainly if any software pertaining to this group is to be commercialized, it will only be successful if it works in a world that the user can understand and deal with. X-windows: Actually, X clients have come to DOS, QuarterDeck has announced DesqView/X, an X server and multitasking environment which can allow clients to run on the same DOS machine as the server. I think this is truly a breakthrough, although I would rather see DOS roll over and die quietly. As an aside, some info on my personal preferrences: Windowing System: X Toolkit: Motif OS: SunOS Computer: Sparc of any flavor C Compiler: gcc Anything else: (5th Amendment, Const. of U.S. ;-) Also, I think that InterViews is extremely useful, and I find at least one of its demo programs to be invaluable. The opinions I have expressed in this thread are based on my experiences in a molecular biology lab (as the programmer), and making my living at writing/supporting software for such labs for more than four years. Chris Dow IntelliGenetics Software Engineer 700 East El Camino Real (ICBMnet address obsoleted by TLAM technology, address now suffices) Mountain View, Ca. 94040 dow@presto.ig.com (415) 962-7320
goldman@mbcl.rutgers.edu (02/20/91)
In article <91045.175752X03@psuvm.psu.edu>, X03@psuvm.psu.edu writes: > I have a question about using X terminal. Currently we are using Silicon > Graphics IRIS for protein structure manipulation. The programs we have are > QUANTA, MIDAS,... My question is, if it's possible to run such programs from > an X terminal, since these programs are graphics extensive applications. Do I > need a special type of X ternimal, or, say, using MacX to turn a Mac into a > X ternimal also works? > > BTW, read comp.windows.x for more technique discussions about X windows. > > Any suggestions? > > Xiaowu Chen > Dept Chemistry > Penn State The answer to this question is "probably no". The window manager on an SGI is called "4Sight", and while it can support X11 apps, most apps that I am aware of on the SGI are written in native 4Sight using the IRIS graphics library, so they could not be run from a server X-terminal. (Unless all you want is a text terminal, in which case, just rlogin.) Adrian Goldman -- Adrian Goldman | Internet: Goldman@MBCL.Rutgers.Edu Assistant Professor, | Bitnet: Goldman@BioVAX Waksman Insitute, | Phone: (908) 932-4864 Rutgers University, | Fax: (908) 932-5735 Piscataway, NJ 08855 USA |