Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!hsdndev!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.sys.apollo Subject: Re: Apollo problem list / tirade (U/Toronto) (LONG) Message-ID: <1991Feb22.070316.14195@alphalpha.com> Date: 22 Feb 91 07:03:16 GMT References: <1991Feb21.160623.7881@alchemy.chem.utoronto.ca> Organization: asi Lines: 138 In article <1991Feb21.160623.7881@alchemy.chem.utoronto.ca> system@aurum.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >in 'xclock'), mouse events were occuring randomly and quickly, >and all keyboard input was locked out. HOW DO THINGS LIKE THIS GET OUT? Unfortunately most of Apollo still thinks of X as a rather expensive way to display pictures behind your windows. This problem could be remedied if X had more DM-like support in it, and if running X applications wasn't so damned expensive. (I recently watched someone on a 16meg DN3500 running 3 DSEE builds and trying to use a Motif application. It was pitiful.) Given that kind of performance, it's not suprising that people shy away from using X. Then add to that the fact that Apollo no longer has an X development group and you've got major cultural problems. (BTW, I don't mean to be totally critical. Look for some positive suggestions in this space sometime soon.) >- network together easily. >- BSD user environment relatively complete, though some very useful > commands like 'script' and pipelines in C Shell don't work. Script *still* doesn't work?! I reported that bug the day after 10.1 froze. >- compilers on DN10000 with -O do good flow analysis. Apollo compilers are in general pretty good. My only complaint is that they put absolutely no priority on the performance of the compiler itself. Just the other day I tried to compile two files at once. Silly me, I promptly used up all 8meg of free space I had. >- X Windows server dies every few days on DN10000, every few weeks on > M68K nodes, forcing a reboot to recover the display. I've long since given up on sharemode. Given support it might have been good, but.... >- BSD C library calls are incomplete, and there is no /dev/kmem, which > has caused much grief in porting "BSD" packages to the Apollo. It's particularly frustrating when you consider that an extensible-stream version of /dev/kmem probably wouldn't be more than a few weeks worth of work. >- can't run vi/more in a DM pad. These has left our 2 DN580 nodes > useless for 1 1/2 years, since it takes 5 minutes to login using X. I have never seen either of these problems, but then I haven't used a 580 in a long time. >- no X11R4 support. I've seen claims that this is available now. Of course there was actually an implementation done unofficially at Apollo over a year ago, (works great) but Corvallis insisted that they owned X. >H28) delays specified in termcap entries are ignored at 38400 baud, >resulting in locked and/or scrambled screens on dumb terminals. >[Apollo response: fixed in SR10.3] APR # dde12. Interesting. I wonder where they found a dumb terminal to test it :-). >H43) using '~loginid' as part of a pathname fails. >[Apollo response: none] Call # AT000192, APR # 5b543b26. As in "cd ~nazgul"? That only works in the CShell and Kornshells as far as I know. I've never seen any problems with it. >H49) processes can not be killed with either 'kill' or 'kill -9'; they >then use 100% of a cpu until they are "blasted" (after "blasting" the >system must be rebooted, so this is not a useful alternative). We have >also had "unblastable" processes, where the system would not shut down >properly. Short of rewriting the kernel you aren't going to get a fix to the requirement of shutting down after a blast. Likewise you aren't likely to get 100% of processes to never hang. >M52) after using "dmio -off" to remove the DM windows from the X display, >the button can not be used to get them back to be able to logout. >[Apollo response: will not be fixed] Call # A2023624, APR # 5b54002f. Does your XServer's -K option specify that CMD is to be passed to the DM? Otherwise it will only work if you are in a pad. I haven't used sharemode in quite a while, but this used to work okay at 10.2. >M45) only the first DM pad has the proper 'set'/'stty' options set; they >are not propagated properly to subsequent pads or 'vt100' shells. >[Apollo response: "not a problem" since the environment variables are >copied; this is precisely the problem though since for csh, copying the >environment variables is not sufficient - either .cshrc must be re-read >or the 'set'/'alias' names must be copied too or the current shell must >be forked] APR # 5b54b627. I'm confused. Starting a new pad is a brand new operation that has nothing to do with the current pad except that the DM manages to include ENV variables and the current directory. In fact I think it's impressive that it even does that. I certainly wouldn't expect it to copy the set variables - it's not a forked shell. How would it do it? Poke inside of the shells address space and find them? >M69) the 'shutdown -r' and 'shutdown -h' commands do not work. >[Apollo response: none] APR #. I use these all the time! I will say that in share-mode, with X-owns-root, that any partial shutdown (to where you say "GO") will leave the keyboard hung. This is a known problem and I believe has already been fixed internally at Apollo. >M70) the xterm login window never appears if the mouse or keyboard is >touched after logging in to the display. Using share-mode? Dm login or xdm? >N69) no documentation or examples of how to have both the "Alt" and "F0" >keys act as X meta keys. I don't know if this helps, but... here's my XKeys files. This will leave you with the DEL key as |\, the |\ key as CNTRL and POP and REPEAT as ALT. add Mod1 = Repeat add Mod1 = Pop !Backspace -> Delete keycode 190 = Delete BackSpace !Delete -> backslash bar keycode 191 = backslash bar !backslash -> control bar keycode 222 = Control_R keycode 186 = Control_L add Control = Control_R Control_L > >N75) more informative messages than "command not found" should be given >when the command is not available due to network outage or node is down. >[Apollo response: claim the reason a command can not be found is "lost" >along the way; in my view, the reason a command can not be found is >extremely important and shells / system calls should not be throwing such >information away] APR # dcee6. Have you tried the following? export APOLLO_STATUS APOLLO_STATUS='' -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. Brought to you by Super Global Mega Corp .com