Sun-Spots-Request@RICE.EDU (Scott Alexander) (12/14/85)
SUN-SPOTS DIGEST Friday, 13 Dec 1985 Volume 3 : Issue 15 Today's Topics: Re: Sun-2's versus Sun-3's Multibus boards on Sun-3 Re: Sun-3 floating point Re: lisp won't die and bucky bits Re: Lisp and SunWindows SPICE Users Group & Its Newsletter Second source for Sun-3/75 and Sun-3/160 memory expansion boards? NFS for VMS local disks on 3/75's Sun Printers Fun with 2.0 ------------------------------------------------------------------------ Date: Thu, 12 Dec 85 12:52:58 PST From: rose!nowicki@sun.UUCP (Bill Nowicki) Subject: Re: Sun-2's versus Sun-3's There have been many incorrect rumors about mixtures of Sun-2 and Sun-3 machines. The truth is that Sun-2s and Sun-3s work very well together. There are two possible causes for this confusion. First, you need release 3.0 (or later) software to run on Sun-3s. If you ordered your Sun-3s last month, then you have a release called "3.0 Pilot" with your Sun-3s. The problem is your Sun-2s are probably running a 2.x release of software, and 3.y binaries will not run on 2.x systems. Note that 2.x binaries of user programs DO run on 3.y systems, and 3.y binaries compiled and linked on Sun-2s will run on Sun-3s. (Binaries compiled and linked on Sun-3s may sometimes not run on Sun-2s, if they use any of the instructions particular to the 68020. For example, a Sun-3 kernel will not run on a Sun-2, even though they are compiled from the same source.) Note also that Sun-3s do not use the ND protocol for their initial bootstrap; instead they use the standard DARPA TFTP protocol. This diagram illustrates the situation: Executing system: Sun-2 2.0 Sun-2 3.0 Sun-3 3.0 ------------------------------------------------------------------------ Software: | Built on | Yes Yes Yes Sun-2 2.0 | (Except some system programs) | | Built on | No Yes Yes Sun-2 3.0 | | | Built on | No Yes, if no 68020 Yes Sun-3 3.0 | Instructions are used ------------------------------------------------------------------------ Note: floating point is another potential incompatibility. For example, programs linked with -fsky will not work without a sky board, and -f68881 will not work on Sun-2. Programs that depend on the page size or kernel data structures are probably not portable either. This means that until 3.0 software is released for Sun-2s, you need to have a Sun-3 ND server (or a disk) for your Sun-3s. On the other hand, if you are just ordering now, don't worry about this, since by the time you get your machines 3.0 software should be finished with Beta testing. In the meanwhile, NFS, rlogin, and rcp, etc. all work fine between Sun-2s and Sun-3s, and any other 4.2BSD system. The other minor problem is that 3Com Ethernet controllers are too slow for Sun-3s. Note that only a few old Sun-2/120s and Sun-2/100s and Sun-2/170s used 3Com controllers. You can either use small buffers, or upgrade to Sun Ethernet controllers for a very small fee. ----------------------------- Date: Mon 9 Dec 85 16:02:40-PST From: Fernando Pereira <PEREIRA@sri-candide> Subject: Multibus boards on Sun-3 Reply-To: Fernando Pereira <pereira%sri-candide@sri-iu.arpa> Sun sells a Multibus->VME adaptor for $500 or so. -- Fernando ------- ----------------------------- Organization: The MITRE Corp., Bedford, MA Date: Wed, 11 Dec 85 21:13:39 est From: Sid Stuart <linus!sid@mitre-bedford.ARPA> Subject: Re: Sun-3 floating point From the Sun 3 Architecture guide, quoted without permission, "The FPA is software transparent in that binary application programs are transportable between machines with and without the FPA option. To achieve the highest performance, applications do need to be recompiled." sid at linus ----------------------------- Date: 9-Dec-85 17:04:08-PST From: jbn@FORD-WDL1 Subject: Re: lisp won't die and bucky bits Re: Lisp Won't Die: The "lisp won't die" problem is not confined to Lisp; whenever a child process of a tool continues to run, the phenomenon of the child surviving the demise of the window can appear. Try, for example, executing "perfmeter -v cpu &" in a window, then exit suntools or log out. The meter will remain displayed. Re: Bucky Bits: Mark Crispin, (formerly the systems programmer for SU-SCORE and one of the leading hackers of the PDP-10 era), in his book ``The Hacker's Dictionary'' attributes this term to Niklaus Wirth, who was at Stanford when the SAIL keyboard with its many shift keys was introduced, and whose nickname was Bucky at the time. Some of the Lisp machines have SHIFT, TOP, UPPER, SUPER, META, and HYPER shift keys, and all combinations are distinguishable by the software. This is known as the ``MIT Space Cadet Keyboard'' arrangement. The true EMACS fanatic can set things up so that any command can be accomplished by pushing some combination of shift keys and a single character key simultaneously. John Nagle ----------------------------- Date: Mon, 9 Dec 85 00:43:20 pst From: daver@cit-vax.ARPA (David Robinson) Subject: Re: Lisp and SunWindows I cannot explain the strange behavior of Lisp in SunWindows but I have experienced troubles using the Berkeley VLSI tool "magic" with SunWindows. After quite a bit of use of magic the system will die with "file table full". It appears to happen when people "Exit" from the master menu with processes that are still running. By checking the process table I discovered that 20-30 abandoned entries for the special files /dev/mouse and /dev/kbd are still around hogging file table entries. Somehow suntools is not correctly killing/closing tools. This could be related to the annoy accurance of extra utmp entries from unclosed tools running ptys. The result is phantom users that appear to be logged in when they are not. -David Robinson daver@cit-vax.arpa ----------------------------- Date: 9 Dec 1985 15:34-PST Subject: SPICE Users Group & Its Newsletter From: MBALAMUT@USC-ECL.ARPA The SPICE Users Group publishes a quarterly (sometimes) newsletter called the SPICE Rack. The SPICE Rack will be published both in hardcopy and electronic formats. Volume 4 number 1 has recently come off the press. It will be available electronically in a few days. Back issues will be made available early in 1986. Contributions of news, informations, hints, problems, questions, answers, comments and other miscellaneous tidbits are solicited from anyone who cares to contribute. machine readable submission are especcially welcome. Morris Balamut, Editor SPICE Rack SPICE Users Group %HUGHES AIRCRAFT P.O. Box 9399 - C5/2039 Long Beach, Ca 90810-0465 (213) 513-5829 >>>> MBALAMUT@USC-ECL. ----------------------------- Date: 9 Dec 1985 20:05:29-EST From: Ralph.Hyre@IUS2.CS.CMU.EDU Subject: Second source for Sun-3/75 and Sun-3/160 memory expansion boards? Is there one? Does LCF only make multibus expansion boards? - Ralph Hyre ----------------------------- Date: Mon, 9 Dec 85 00:33:34 pst From: daver@cit-vax.ARPA (David Robinson) Subject: NFS for VMS Does anyone know of a port of NFS to a VAX/VMS system. No flames please, but I am associated with people who have VMS Vaxen and SUNs that would like to share LARGE (Megabytes) files between machines and it is VERY inconvienent to ftp them back and forth. I have so far gotten very little from SUN on the topic, mostly circular references that lead back to SUN marketing. Pointers to commercial or private parties that are doing this or considering doing this would be helpful. Comments on porting the "portable" Vax 4.2 version would also be desireable before I dive into the possible porting of it myself. -David Robinson daver@cit-vax.arpa ----------------------------- Date: Mon, 9 Dec 85 13:07:35 est From: allegra!phri!roy@seismo.CSS.GOV (Roy Smith) Subject: local disks on 3/75's I keep hearing that I'll be seriously unhappy with just 2 Mbytes of ram on my soon-to-be ordered 3/75's. 4 Meg, however, just seems excessive to me for a single-user station. Maybe I'm being naive, but I keep looking at my 4 Meg 11/750 that almost never pages even with 12 people on it. Looking at the Sun pricelist, it occured to me that I can get a 71-Mbyte disk for just about what 2 2-Mbyte memory boards cost. What if I got one small disk for each pair of 3/75's with 2 Mbytes ram each? Maybe doing swap on so many disk arms (we're looking at about 10 stations) and not going over the net for paging will more than offset the performance hit from not having enough ram? Not to mention the hefty local /tmp partitions I'll be able to give each node, and the CPU cycles I'll be saving in my 3/180 server. Anybody care to comment on this idea? ----------------------------- From: Ralph Martin (on ICF GEC 4090 at Cardiff) <XACF03%geca.cardiff.ac.uk@cs.ucl.ac.uk> Date: Mon, 9 Dec 85 12:34 GMT Subject: Sun Printers I am not sure if this has been discussed before, but anyway, here goes: We wish to use a laserprinter on both a Sun, and a Macintosh (1 of each), and it is not obvious to us whether to buy an Apple Laserwriter, and an interface kit to tie it up to the Sun, or to buy a Sun Laserwriter. Can anyone comment on (a) Price advantages in doing either (b) Any technical diffculties either way (c) Any other reasons to go one way or the other Thanks, Ralph ----------------------------- Date: Mon, 9 Dec 85 17:47:24 pst From: ia-sun2!smeagol!root@cit-vax.ARPA (Operator) Subject: Fun with 2.0 First off, regarding the Sun 2 vs. 3 discussion: Are we overlooking the (seemingly) obvious? If you have a Sun-3 server serving Sun-2 clients, presumably the clients will be running a few programs off of the server. Also, presumably Sun had the presence of mind to recompile a lot of the programs, in order to use the 68020 instruction set. Guess what happens when you run 68020 code on a 68010, kiddies! Ka-BOOM. "Gee, what's this strange instruction? Barf." I would imagine that the 'bridge' product might be none other than a flag to the (new) cc telling it to not use any 68020 code, so either machine can run it. Enough said. Anyhow, now for the fun stuff ... I would be EXTREMELY interested in getting SysAdmin's responses to these little gems, that have been found under 2.0 : (1) How do you S.A.'s out there do dump(8)s under 2.0?? When we had 1.2, things were easy: take the machine (and any nd clients) down to single user, and then do the dump, either to local or a remote tape. No problem. Here comes 2.0, and Sun tells us that we "no longer need to have the files /etc/{protocols,services,netgroup,networks,etc.} anymore. If you feel squeamish about doing this, move them to filename-." Damn right I feel squeamish. Try to do a dump to a remote machine's tape drive while single user, without the existance of /etc/services, or an entry for the remote machine in /etc/hosts (remember, Sun says "You only need have an entry for the host machine and a loopback entry in /etc/hosts - these are only consulted when booting."). It won't work. Maybe someone has an idea for ensuring that absolutely no filesystem activity occurs while doing the dump multi-user, but I sure haven't. Also, when I re-enabled these guys, I was able to do my remote dump. Went to another machine (which happens to be the main NFS/YP server) which still had a full 'hosts' and an unchanged 'services'. This time my remote shells just hung out to dry. Didn't even time out. I would be willing to attribute this to inetd not running, but then why did the other machine work OK??? If someone out there has a safe scheme for doing backups, speak up. (2) The Manuals also tell us that /etc/hosts.equiv can be editted down to a '+' entry if you have a 'friendly' net, and want to let all machines talk to one another. So I did. Later I suddenly find that my main NFS/YP server can't send print jobs to another 2.0 (standalone, NFS client) machine with a different printer on it. lpq -Pthatprinter yielded "other_machine: /usr/lib/lpd: remote printer access not allowed for your machine" or something similar. Eventually tracked this down to the fact that there was no entry for the sending machine in /etc/hosts.equiv. Well, the sender is the YP master server, and you can bet your a** that there was entry for itself in the YP. Figure that one out. So now the remote machine's host.equiv has 1 line for each machine that wishes to be able to send it print jobs, THEN the '+'. Thanks a whole lot. (3) On a trivial note, I have discovered that suddenly under 2.0, if you use 'tip' to transfer files (like from a PC, in our case), unless you are the super-user, the lock file (/usr/spool/uucp/LCK..ttyname) doesn't get removed. Pity the poor person that comes along next (after the S.A.'s gone home) who wanted to log onto that remote computer down the road using 'tip', and he/she gets 'all ports busy'. Can somebody explain this one? Also, I would have to say that Roy Smith's gripe about having to devote most of an Eagle to swap space is a reasonable one; however, the problem as I see it, is that you want to make a mega-swap space for all the clients. Now somebody (namely the server) is going to have to manage that swap space, and make sure that when one client swaps that it doesn't obliterate another client's previously-swapped stuff. How are you going to do that?? This immediately implies to me that the only prayer in h*** you'd have of doing that would make it necessary for the server to do all the managing of the swap space, and remember things about it (accesses? by whom? when? etc.). Which immediately implies a stateful server, the whole thing that Sun is avoiding with NFS in the first place ... This may cause howls of laughter from the kernel pros, but what about the idea of a dynamic swap allocation? I.e., the kernel, on starting up a process, could tell how big a space it would need to swap that process's page, page table, user page, etc.; and allocate a contiguous space on the disk for it. It could do this after it had linked the process in to the process table, allocated the page table for it, and all that other fun stuff. The kernel could re-claim the space on process termination. It seems like there might be some overhead problems, but I would be interested to see a discussion/rebuttal of this idea. To Sid Stuart: Why would anyone want to buy a Sun-2 now? How 'bout if you have a Sun that has a Heurikon 68k SBC in its backplane, that talks to a bunch of other SBC's stuck 5-6 in a chassis (Multibus); with 4 chassis' in a rack; that intercommunicate via Intel Multichannel boards ( {:=( ) between each chassis. I suppose we could buy a Sun-3 and put in the VMEbus to Multibus adapter; that sounds to me roughly equivalent to buying a Porsche Ruf 930 Turbo and then closing the Turbo Boost gate most of the way off ( (;-) ). We'll be buying 2's until somebody comes up with a replace- ment for the MultiChannels for communicating between Heurikon chassis'. (Heurikon already is now making VMEbus chassis' and SBC's, so there's no problem there.) Some of us are constrained by technology (or lack thereof). Greg Earle Jet Propulsion Laboratory UUCP: sdcrdcf!smeagol!earle -or- sun!tsunami!smeagol!earle ARPA: ia-sun2!smeagol!earle@cit-vax.arpa [On 2: In Vax 4.2, the line printer stuff checks to see that the remote machine is in the local /etc/hosts.equiv but does not check uids. (This idea is contrary to the meaning of the file and lpr should look at some other file, but that's a seperate topic.) Anyway, I would guess this one slipped by in the "what needs to be recompiled phase at Sun". On 3: This happens on the one system that I use which uses tip when the directory /usr/spool/uucp get set to a non-world-writeable mode such as 0755. It creates the file setuid to root and soon after does a setuid(getuid()). ----------------------------- End of SUN-Spots Digest ***********************