SUN-Spots Digest, v3n15
Scott Alexander
Sun-Spots-Request at RICE.EDU
Sat Dec 14 09:34:09 AEST 1985
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 at 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 at sri-candide>
Subject: Multibus boards on Sun-3
Reply-To: Fernando Pereira <pereira%sri-candide at 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 at 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 at 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 at 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 at cit-vax.arpa
-----------------------------
Date: 9 Dec 1985 15:34-PST
Subject: SPICE Users Group & Its Newsletter
From: MBALAMUT at 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 at USC-ECL.
-----------------------------
Date: 9 Dec 1985 20:05:29-EST
From: Ralph.Hyre at 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 at 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 at cit-vax.arpa
-----------------------------
Date: Mon, 9 Dec 85 13:07:35 est
From: allegra!phri!roy at 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 at 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 at 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 at 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
***********************
More information about the Mod.computers.sun
mailing list