jec@iuvax.cs.indiana.edu (James E. Conley) (12/09/88)
X Window System Bug Report
xbugs@expo.lcs.mit.edu
VERSION:
R3 (with fixes 1 and 2 installed, casey@ucla-cs mods for Apollos installed)
CLIENT MACHINE and OPERATING SYSTEM:
Apollo DN3000 running DOMAIN/OS 10.0
DISPLAY:
Apollo 4 plane
WINDOW MANAGER:
uwm
AREA:
xterm
SYNOPSIS:
xterm freezes and does not accept keyboard input and must be killed due
to a strange interaction with curses (?) or tty settings (?).
DESCRIPTION:
When starting xterm from uwm with an "rlogin" to our local vax (Ultrix
2.2 VAX8800) various programs that diddle with curses cause xterm to
freeze up in such a way that the window must be killed.
REPEAT BY:
% setenv DISPLAY pwp
% xinit uwm
... start a normal xterm ...
x% xterm -bw 4 -bg yellow -bd blue -T iuvax -n iuvax -e rlogin iuvax &
... new window opens on "iuvax" ...
iuvax% moria
... hit ^C and freeze city! (If this doesn't work, move around a
little in the town level) ...
SAMPLE FIX:
Buy a SUNadam@loki.cs.cornell.edu (Adam Feigin) (12/09/88)
In article <15672@iuvax.cs.indiana.edu> jec@iuvax.cs.indiana.edu (James E. Conley) writes: > > X Window System Bug Report > xbugs@expo.lcs.mit.edu > >VERSION: > R3 (with fixes 1 and 2 installed, casey@ucla-cs mods for Apollos installed) > >CLIENT MACHINE and OPERATING SYSTEM: > Apollo DN3000 running DOMAIN/OS 10.0 ......mucho deleto....... > >SAMPLE FIX: <------ > Buy a SUN <------ ****flame on******* I, for one, do not appreciate this, and furthermore, dont think its the slightest bit funny......I doubt the folks at MIT will think its funny either. If you're going to submit a bug report to the with a sample fix, then INCLUDE A SAMPLE FIX, not some stupid remark because you cant figure out how to fix it. *****flame off***** If you think X is bad on Apollo's, just try to run it on a Sun with 4 MB of memory...You'll get lots of work done.....You know things a bad when X runs faster than SunView/Suntools (whatever it's called) on a Sun. (This is the case for the 386i, and almost for the 3/60 !!) AWF Internet: feigin@tcgould.tn.cornell.edu Adam Feigin Bitnet: feigin@crnlthry Workstation Consultant UUCP: {backbones}!cornell!batcomputer!feigin Cornell National Supercomputer MaBell: (607) 255-3985 Facility, Visualization Group
jec@iuvax.cs.indiana.edu (James E. Conley) (12/10/88)
>> my original posting > adam@cs.cornell.edu (Adam Feigin's) reply >> >> X Window System Bug Report >> xbugs@expo.lcs.mit.edu >> ... > >****flame on******* > >I, for one, do not appreciate this, and furthermore, dont think its the >slightest bit funny......I doubt the folks at MIT will think its funny either. >If you're going to submit a bug report to the with a sample fix, then INCLUDE A >SAMPLE FIX, not some stupid remark because you cant figure out how to fix it. > >*****flame off***** > First of all, I have nothing against the people that distribute X. They are doing all of us a service and for free at that! I understand that they are providing sample servers and that they stated that the sample server they ship with R3 is only tested under SR9.7 and DOMAIN/IX 9.5. *** my turn, flame on *** What I am unhappy about is Apollo's SR10. After all the hype and hoopla of how this was going to pull Apollo into the realm of "real UNIX" (to quote our Salesman), it turns out that it is riddled with bugs, is unbearably slow, and takes a huge amount of disk space. Now it turns out that they've managed to break X (part of this turns out to be compiler bugs, part missing include files, and yet another part broken tty code). It has taken us one and a half years to get the Apollos working in a sensible matter. It took us a total of 3 weeks to get our SUNs up and running. I suspect that if you only have to worry about an environment full of Apollos, you don't need to run X and tcp so things might be okay, but in a hetrogeneous network the Apollos don't cut it. They are getting better and I do hope that they get their act together since we have a lot of their workstations, but if they don't do it soon we might be using them more effectively as landfill. I hope your clients that have Apollos get the most out of them, but for our environment they are not up to the task. Hopefully Apollo will rectify this. I won't hold my breath. James Conley Indiana University Computer Science jec@iuvax.cs.indiana.edu
benoni@ssc-vax.UUCP (Charles L Ditzel) (12/10/88)
>> SAMPLE FIX : >> Buy a Sun. > If you think X is bad on Apollo's, just try to run it on a Sun with 4 MB of > memory...You'll get lots of work done.....You know things a bad when X runs > faster than SunView/Suntools (whatever it's called) on a Sun I have used MIT's X on Apollos and seemed *really* slow to me...and I just imagined that the MIT tape was just not optimized for Apollos or Suns... Incidentally, I worked on Apollos for two years before I did *just* that... I decided to buy a workstation...I bought a 4 megabyte Sun 3/50 ...and it *did* fix my problems. I now use Apollo and Suns daily. SunView's programmatic and user interface is light years ahead of the DM...(goodbye dm_$etc_etc and gpr_$etc ) and it seems relatively fast to me ... but a couple of things come to mind ... whether you have a Sun or Apollo :it is worth the effort to make sure you don't have lots of unnecessary system processes running .. (that could slow down any machine) as for X...I haven't even bothered to load the tape...(I'll wait for Sun's X11/NeWS/ and Open Look merge)...I also use NeWS and find it much faster than X on the Apollo ... not to mention that NeWS allows all sorts of things that X11 cannot do ... but that's another story entirely). Oh, and I run it on 4 megabyte Sun 3/50 (that's their low end machine). _____ My Opinions are my own and not my employers.