rees@pisa.ifs.umich.edu (Jim Rees) (11/02/90)
I've just installed sr10.3. The only thing that really tripped me up was that tcpd wouldn't run until I changed the line in the rc.local file from /etc/tcpd >/dev/console to /etc/tcpd I recommend that you read your release notes, and that you check your transcript for any file names of the form foo.mm.dd. These are files that have been preserved or have changed in some way such that you may want to examine them to make sure they're still right. The new X multi-focus stuff is almost nice, but it's got some annoying bugs, like leaving mouse droppings all over and sometimes missing mouse transitions across window boundaries. No big surprises. It's way better than sr10.2 out of the box, but isn't much different from sr10.2 with all the necessary patches applied.
krowitz@RICHTER.MIT.EDU (David Krowitz) (11/03/90)
I have just finished trying SR10.3 on my systems ... It doesn't work on a DN560 -- the multi-focus stuff for X seems to have completely broken the DM. The DM cursor will track the mouse, but when you click a mouse button, depress a keyboard key, or try to actually do *any* work ... well, the system seems to think that the input focus is somewhere else. It makes is *real* hard to resize a window. This bug was reported during the beta-test, but HP's written reply was ... "it works on DN3xxx/4xxx and on DN570's". DN570's have a different graphics unit. If they're DN570 turbos, they have different CPU's as well. It doesn't work on diskless DN330's as well. The calendar program doesn't seem to be able to reset the time and date, and the system won't boot because the date always seems to go back to sometime in the year 2015, and the UID generator can't produce correct object UID's with a date that far into the future. This bug was also reported during the beta-test. It seems like HP is getting a jump on its reported plans for dropping support for the sau3, sau3, sau4, sau5, and sau6 machines in SR11. Considering that the C, Fortran, and Pascal compiler have not been able to generate floating point code for the sau4 machines since SR10.0 was introduced (we reported that the -cpu 460 switch will cause the compilers to bomb with fatal internal errors on almost any piece of code), and that this problem has not been fixed in over 2 1/2 years (we finally threw the machines out after 2 1/2 years of their 5 year lifetimes were spent running at 1/3 of their full power due to the lack of floating point support), I would expect to be able to install SR10.3.x sometime around 1992. SR10.3 may fix a lot of users' problems ... but I would procede with caution ... make full backups, do *not* overwrite your SR10.2 AA, test your individual hardware configurations by booting diskless off your SR10.3 AA machine *before* installing SR0.3 on your local disk, and above all, test your application software on *each* of your individual graphics configurations (E vs. F vs. 1280x1024 mono vs. 1024x800 mono) before you leap into SR10.3 This may be Apollos "highest quality release ever", but it is certainly not bug free. As with any new software release, procede with caution at your own risk. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (11/03/90)
In article <9011021601.AA06970@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes:
I have just finished trying SR10.3 on my systems ...
It doesn't work on a DN560 -- the multi-focus stuff for X seems to have
completely broken the DM.
This seems to be true on most machines. After struggling with multi-focus
on my dn3500 for a day, I finally had to turn it off (you can do this by
changing "S+r+" to "s+r+" in /etc/rc). Besides the annoying mouse
droppings, the cursor simply gets lost too often.
It doesn't work on diskless DN330's as well. The calendar program doesn't seem
to be able to reset the time and date, and the system won't boot because the
date always seems to go back to sometime in the year 2015, and the UID generator
can't produce correct object UID's with a date that far into the future.
I would try using the sr10.2 offline calendar program. If the problem is in
setting the time this should fix it. If the problem is that sr10.3 can't
read the hardware clock correctly, it won't.
Today's tip: Create the file /usr/X11/lib/XKeysymDB so you can use the gray
keys from X. Put the following into it:
LineDel: 1000FF00
CharDel: 1000FF01
Copy: 1000FF02
Cut: 1000FF03
Paste: 1000FF04
Move: 1000FF05
Grow: 1000FF06
Cmd: 1000FF07
Shell: 1000FF08
LeftBar: 1000FF09
RightBar: 1000FF0A
LeftBox: 1000FF0B
RightBox: 1000FF0C
UpBox: 1000FF0D
DownBox: 1000FF0E
Pop: 1000FF0F
Read: 1000FF10
Edit: 1000FF11
Save: 1000FF12
Exit: 1000FF13
Repeat: 1000FF14
KP_parenleft: 1000FFA8
KP_parenright: 1000FFA9herb@blender.uucp (Herb Peyerl) (11/15/90)
sasjfp@unx.sas.com (Jeffrey L. Phillips) writes: >An addendum to the release notes for sr10.3 says that they have made signifiga >changes to /etc/tcpd. So much so that it will not talk to any non-10.3 machine >unless it is run with the -c switch. In other words, it needs to be: > /etc/tcpd -c The changes they made to /etc/tcpd are not 'significant' so to speak. It says in the release notes that there was a slight problem with the occasional packet. It would seem that if the checksum on a packet was '0000' then according to some sort of spec, the checksum is supposed to become 'FFFF'. The old (<=SR10.2) tcpd didn't perform this... Odds are that you would lose 1 in 65k packets. The '-c' switch induces the old checksum action. So, regardless of whether you use the old tcpd or the new tcpd action, you can at least talk to other Apollo nodes.. Incidentally, our 10.3 nodes came in with '/etc/tcpd -c' as default. -- -------------------------------------------------------------------------- UUCP: herb@blender.UUCP || ...calgary!ajfcal!blender!{herb||root} ICBM: 51 03 N / 114 05 W || Apollo Sys_admin, Novatel Communications "I put instant coffee in the microwave oven & went back in time" S. Wright
sasjfp@unx.sas.com (Jeffrey L. Phillips) (11/17/90)
In article <4dc1a77e.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >I've just installed sr10.3. The only thing that really tripped me up was >that tcpd wouldn't run until I changed the line in the rc.local file from > /etc/tcpd >/dev/console >to > /etc/tcpd > An addendum to the release notes for sr10.3 says that they have made signifigant changes to /etc/tcpd. So much so that it will not talk to any non-10.3 machines unless it is run with the -c switch. In other words, it needs to be: /etc/tcpd -c -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ "Just because I don't know what it means doesn't mean I'm lying." Jeff Phillips Email: sasjfp@dev.sas.com
rees@pisa.ifs.umich.edu (Jim Rees) (11/20/90)
In article <1990Nov16.182247.14214@unx.sas.com>, sasjfp@unx.sas.com (Jeffrey L. Phillips) writes: In article <4dc1a77e.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >I've just installed sr10.3. The only thing that really tripped me up was >that tcpd wouldn't run until I changed the line in the rc.local file from > /etc/tcpd >/dev/console >to > /etc/tcpd > An addendum to the release notes for sr10.3 says that they have made signifigant changes to /etc/tcpd. So much so that it will not talk to any non-10.3 machines unless it is run with the -c switch. Hogwash. They make a big deal about this, but it only affects UDP packets, and then only rarely, and then only the first time (the first re-transmission will have a different checksum and should be OK). So the only things that are really affected are UDP users with bogus (missing) re-transmission algorithms. Not even worth thinking about, much less providing a compatibility switch for. My home directory is located on an AFS server, so the only way I can get to my files is by UDP. I get there just fine and I don't need no -c switch. The problem I had was more likely a tty IO problem. Something about the pgroup of the console getting switched to the tcpd, and then init can't write to it any more. That's why all lines that write to the console in /etc/rc should be done in a subshell, like this: (/etc/tcpd >/dev/console) I think they just made a typo in the rc file.