newton@cs.utexas.edu (Peter Newton) (04/26/91)
Review of Mac X 1.1
Peter Newton (newton@cs.utexas.edu)
The opinions expressed herein are my own. I do not represent the
University of Texas.
From time to time, questions appear on the net relating to
X-terminal software for the Mac. Having just installed such software,
I am in a position to answer some of the more basic questions. This
article discusses what Mac X is, roughly how it works, and how well it
works.
Actually, I know of two X-terminal programs for the Mac, eXodus,
and Mac X. The former is by White Pines Software (I think). I know
nothing more about it. Mac X is an Apple product.
Notes for Those Who Don't Know about X:
X-windows is an industry-standard graphical window package and
more that runs on a large number of machines, mostly UNIX
workstations. Things like Motif and OpenWindows are user
interfaces that run on top of X. Among other things, X permits
you to run a program on a remote computer connected to yours via
a network. In this case, your computer is responsible only for
performing the graphical operations needed to support the user
interface. That is the idea behind X-terminal software like Mac
X. You run your program on a remote machine, probably a UNIX
workstation, but the graphical display appears on your Mac. It's
a great way to have only a Mac on your desk but still be able to
do X/UNIX things using a remote machine on your network.
One should note that Mac X does not, by itself, turn you Mac into
a complete X windows workstation. It does not allow you to
compile and run X applications directly on your Mac. I know of
no way to do that short of buying Apple's UNIX (A/UX).
This mostly from an Apple sales brochure...
System Requirements:
- Any Mac with at least 2 MB RAM.
- Two floppy drives (hard disk HIGHLY recommended).
- Mac OS 6.0.4 or later.
- A network connection to a remote machine that runs X.
- localtalk or
- ethertalk or
- straight ethernet.
Features:
- X 11.4 compliant.
- Works under multifinder (can run NCSA Telnet at the same time).
- Built-in window manager (it's nice, Mac-like).
- Both monochrome and color support.
- Copy/paste between X and Mac applications.
Mac X comes with the Mac X application, the communications toolbox,
MacTCP, Mac X font library software, complete documentation.
Misc. Facts:
- I know of no way to run it over SLIP. If there were a way, I
would worry very much about performance.
- Software installation is much more complex than usual for Mac
programs. If you do not know a little about networks and X-windows,
you could have a bad time. Are terms like IP address, domain,
subnet mask, xterm, client, and server meaningful to you? If
not, you may need to seek help. The installation documentation
is reasonably good. It leads you through the process in a step
by step manner and tells you what information you will need.
And now, my experiences with Mac X...
1. Getting Information about Mac X.
This is very difficult, which is why I wrote this. Most Apple
dealers I have spoken with have never heard of Mac X and do not
have the background needed to discuss it intelligently. I
suggest calling Apple's Customer Assistance Center at
1-800-776-2333 and asking for the names of SEVERAL Mac X dealers
in your area. You can also talk Apple into sending you a
brochure. You may have to ask for an A/UX (Mac Unix) dealer.
For some reason, Apple considers Mac X to be an A/UX-related
product. This is nonsense. You do not need A/UX to run Mac X.
2. Our Configuration.
I put Mac X 1.1 onto a Mac IIx with 8 MB RAM, a big hard disk,
Apple's standard 8 bit color display, and Mac OS 6.0.5. The
network connection is via an ethertalk NB card using straight
ethernet (none of this ethertalk protocol business). We have
hundreds of machines on our network, including Sun, HP, and IBM
UNIX workstations and various minis like Sequents and VAXen. I
tested Mac X running programs remotely on Sun 3s and Sun 4s
(SunOS 4.0.3), HP's, and an IBM RS/6000. All worked.
3. Installation.
As I have said, installation is somewhat complex. I had no
trouble, however, following the instructions. If you have
trouble getting it working, it might be a good idea to install
the Mac TCP version of NCSA Telnet. That program is simpler, and
you can use it to test your network connections. For example, it
responds to pings. You can also run it at the same time as Mac
X. You can use telnet to start X applications that will be
displayed under Mac X. (You know, setenv DISPLAY hostname:0)
This can be a way to work out problems with remote commands.
NCSA Telnet is free and is available via anonymous ftp from
zaphod.ncsa.uiuc.edu.
My installation process involved installing the ethertalk NB card
driver followed by the communications toolbox and Mac TCP. At
this point, set up IP addresses and such for Mac TCP and NCSA
telnet should run. Lastly, install Mac X and its fonts and
define your remote commands.
4. User's View of Mac X.
Mac X provides its own window manager. You will not be running
something like twm. The Mac X window manager is nice. It's
Mac-like and works well in the Mac environment. Most X things
assume a 2 or 3 button mouse. Mac X circumvents this problem by
defining arrow keys to work as the second and third buttons.
Users start X applications (like xterms) using Mac X's remote
command facility. The idea is that the Mac user defines a set of
remote commands. They then appear in a menu. You define remote
commands by means of a dialog. You will need the name of the
remote application (in fact its complete path name), the name of
the remote machine to execute it on, and a username and password
for the remote machine. I am told that remote commands are
implemented by means of rexec, if that means anything to you.
If you define an xterm as a remote command, then executing it
will open a terminal window on the remote machine. From that
window, you can start another X application in the usual X way--
by entering its name at the shell prompt.
I had a little trouble getting xterms to work on Suns due to
Sun's dynamically linked libraries. I had to add
setenv LD_LIBRARY_PATH /lusr/lib/X11
to my UNIX .cshrc to tell the Sun where to find its stuff.
5. Performance.
X graphics speed in our setup is adequate. The system responds
to mouse clicks quickly and screen updates are OK but not
spectacular. Performance is similar to that of using X on some of
our slower UNIX workstations directly.
I have no experience, but I would worry about using Mac X over
localtalk or on a 68000 based Mac. It might be too slow. If you
want to do this, try to get a positive testimonial from someone
who does this before you buy.
Also, in my experience, X applications expect large screens.
Most workstations have 17 inch monitors. Using Mac X on a
machine with a 9 inch screen may be inconvenient. It would be
all right if you only intend to run xterms, but you can get
terminal windows with NCSA Telnet (or MacLayers or uw over serial
lines) for free. MacLayers is available via anonymous ftp to
rascal.ics.utexas.edu. It works only with BSD UNIX hosts.
6. Where to Buy.
Like I said, call the Apple Customer Assistance Center to find a
dealer. We bought from
MicroSolutions
10670 North Central, Suite 110
Dallas, TX 75231
(I don't have a phone number)
but I have nothing to say either good or bad about them. We
asked for and received no technical support. They did have some
problem dealing with Texas state purchasing procedures. Perhaps
that's to their credit...
7. Conclusion.
To the extent to which I have tested it, it looks like Mac X will
work nicely for us-- on a high end Mac with an ethernet
connection. Given that it is a complex program that must operate
in a complex environment, it is easy to install and use. But
beware if you are a networking/X neophyte.
Actually, I have not tested it as completely as I'd like. I
can't because it's on someone else's machine. However, I had no
trouble running a number of monochrome X applications.
Everything worked smoothly. I did have some trouble with a color
app, but I did not have a chance (or a reason) to investigate it.
I have no reason to assume there is a show-stopper problem.
By the way, I cannot offer more help with Mac X. Like I said, I
put it onto someone else's machine so I cannot easily check
things out.ephraim@think.com (Ephraim Vishniac) (04/26/91)
In article <320@burr.cs.utexas.edu> newton@cs.utexas.edu (Peter Newton) writes: > Review of Mac X 1.1 > Peter Newton (newton@cs.utexas.edu) >The opinions expressed herein are my own. I do not represent the >University of Texas. And I don't represent Thinking Machines Corporation, which just purchased a site license for MacX. > Actually, I know of two X-terminal programs for the Mac, eXodus, >and Mac X. The former is by White Pines Software (I think). I know >nothing more about it. Mac X is an Apple product. White Pine Software is located in southern New Hampshire. They make several communication-related products for the Macintosh. >This mostly from an Apple sales brochure... >Features: > - X 11.4 compliant. Usually spelled "X11R4." >Misc. Facts: > - Software installation is much more complex than usual for Mac > programs. If you do not know a little about networks and X-windows, > you could have a bad time. Are terms like IP address, domain, > subnet mask, xterm, client, and server meaningful to you? If > not, you may need to seek help. The installation documentation > is reasonably good. It leads you through the process in a step > by step manner and tells you what information you will need. Actually, it's the installation of MacTCP that's complex. If you've already got MacTCP and the Comm Toolbox installed (as I did), installing MacX itself is a breeze. >2. Our Configuration. My configuration: Mac IIfx with Cayman GatorCard, Radius TPD. No problems. I believe we've got it installed on every model of Mac II at this point, and no-one's complaining. Many users have ethernet cards, some are operating over AppleTalk and through GatorBoxes to reach the ethernet. > 4. User's View of Mac X. > Mac X provides its own window manager. You will not be running > something like twm. The Mac X window manager is nice. It's > Mac-like and works well in the Mac environment. Most X things > assume a 2 or 3 button mouse. Mac X circumvents this problem by > defining arrow keys to work as the second and third buttons. This use of the arrow keys to act as the second and third mouse buttons, combined with Apple's crazed keyboard design, is just excruciating. Some X applications (such as xterm) use the mouse buttons alone for common operations including text selection and pasting, and use control+mouse button for the menus. This probably isn't too bad in MacX if you've got an extended keyboard, which has control keys on both sides. But those control keys are both out of normal reach, so people who actually use the control key (i.e., programmers who run emacs or gnu emacs) do better with the standard keyboard. It has only one control key, placed as God intended :-) to the left of "A." So, picture this: The control key is at the extreme left edge of the keyboard. The arrow keys are slightly more than an octave reach to the right. The mouse can be almost anywhere, but still requires a third hand. This is terminally stupid design. Obviously, nobody at Apple ever used MacX with a standard keyboard. APPLE ARE YOU READING THIS? Give users some *intelligent* choices for the second and third mouse buttons. Remember that not everyone has the poorly designed extended keyboard. How about command-mouse and option-mouse for the other buttons? Lord knows there's no shortage of modifier keys on the Mac keyboard. >5. Performance. > X graphics speed in our setup is adequate. On a IIfx, it's very snappy. On a IIcx, it's certainly adequate. Other observations: In a week of use, I've come across only one major glitch, which I haven't been able to reproduce. After running and quitting a number of applications, I noticed that the processes running on my host didn't match up with my remaining windows. There was one host process (client) with no window, and one window with no client. That window was unkillable, except by quitting MacX. I'd like to define commands which don't specify a host, and be prompted for the host when I execute the command. With well over a hundred Unix hosts in the building, it's not practical to set up separate commands even for the ones I use frequently. This feature might be present, but I haven't figured out how to do it. OOPS! I just gave it another stab while composing this, and bombed MacX. Here's how: 1. Compose a new command. You can't execute or set the command until you've pushed the Host... button and interacted with the dialog, but even cancelling from the Host dialog without picking a host seems to satisfy MacX. Save the new command. 2. Execute the command. I got an alert saying The connection tool "MacTCP tool" does not support the "RemoteAddress" macro used in the command "Random Xterm". 3. Edit the command. Push the Host... button. At this point, I landed in Macsbug with a message about an attempt to free an invalid or corrupt block. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.