Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/18/88)
SUN-SPOTS DIGEST Wednesday, 19 August 1988 Volume 6 : Issue 190
Today's Topics:
Re: Whither 68030 (2)
Re: bm & super-egrep
NJ is really part of the US (We finally got 4.0)
Large distance between monitor and box
ypserv and sendmail.mx, revisited
wren IV query
Using a DELNI with a Sun - Will it work ?
double buffering with pixrect?
SIGIOT?
Questions about Exabyte on Sun
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Mon, 15 Aug 88 10:39:50 EDT
From: jas@proteon.com (John A. Shriver)
Subject: Re: Whither 68030 (1)
The 68030 does not look like an extremely likely candidate for use by Sun.
The primary feature of this chip over the 68020 is that it includes the
PMMU. This would not be of much use to Sun, since all of their machines
(expect the 386i?) use the proprietary "Sun" MMU, originally from
Stanford. They would have to redo a LOT of the MMU software, and probably
also devise an alternative to DVMA. (The software problems may be smaller
in SunOS 4.0, especially if it also supports the 386 MMU.)
After all this effort, the 68030 is not much faster than a 68020, the only
avantage being in a better cache. It may also be offered in faster clock
speeds. The 68030 has the same basic instruction box as the 68020 CPU.
Of course, Sun's competitors are charging ahead with the 68030. Apollo's
DN 4500 uses a 33 MHz 68030. They have long supported many different
MMU's, and they have used the PMMU before. For them, the 68030 offers a
cost advantage over using an outboard PMMU, which was the main goal of the
68030.
------------------------------
Date: Mon, 15 Aug 88 10:02:57 MST
From: "Gregg Townsend" <gmt@arizona.edu>
Subject: Re: Whither 68030 (2)
Steve Jay, in response to questions about a 68030 machine from Sun, says:
1) who cares?
2) do you really think Sun is going to continue to produce machines with
three (680x0, 386, and SPARC) non-compatible architectures?
We've found that many of our system maintenance costs are more
proportional to the number of different *architectures* than the number of
differrent machines. For example, we can add any number of Sun-3s fairly
easily by just copying some binaries. But when we bring in something new
we need to rebuild and then maintain TranScript, Ditroff, Emacs, Icon, and
all the other things that people around here expect. So, we care.
So, if Sun comes out with a 68030 machine, that will give us a compatible,
faster machine to look at. But when we need something more than Sun can
give us with compatibility, we'll start looking at ALL the vendors -- not
just the Sun 4. That's why it's to Sun's advantage, too, to keep the
68030 line alive.
Sun does seems to have decided on multiple architectures, else they never
would have brought out the 381i in the first place. (Yes, it surprised
me, too.)
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@Arizona.EDU 110 57 16 W / 32 13 45 N / +758m
------------------------------
Date: Sat, 13 Aug 88 10:11:54 EDT
From: attcan!utzoo!henry@uunet.uu.net
Subject: Re: bm & super-egrep
In fact, what you want is not "bm", but James Woods's super egrep, which
is faster than bm but preserves full egrep functionality. Alas, the
availability is the same: see comp.sources.unix.
Henry Spencer @ U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
------------------------------
Date: Sat, 13 Aug 88 01:33:26 EDT
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: NJ is really part of the US (We finally got 4.0)
We finally got our Sun source tape for 4.0. Unfortunately it turns out to
be the export version. This means that a few things in libc involving DES
are lobotomized so it doesn't run afoul of the US export restrictions.
The problem is, one of the main things I wanted to do was rebuild libc.so
so it has the resolver routines instead of the YP hostname junk. Without
source to all the routines in libc, it is impossible to rebuild libc.so.
I'm not sure whether they just sent us the wrong tape, or whether the
error is a general one. However I urge sites who get source to verify
that they have the real stuff. The simplest way is to check
.../lib/libc/des and make sure that des_crypt has real code in it. In the
export version cbc_crypt and ecb_crypt simply return errors. At least in
our copy, the correct versions of the des stuff is actually there. It's
just hidden. You'll find .../lib/libc/des/SCCS, which is where you'd
expect the code to be. (In 4.0 the source is supplied only in SCCS form.)
That directory has the export stuff. But if you look in
.../lib/libc/des/SCCS/SCCS, you'll find the real stuff. Unfortunately,
there are three more routines that have been lobotomized. They are
.../lib/libc/rpc/auth_des.c, .../lib/libc/rpc/svcauth_des.c, and
.../lib/libc/gen/common/_crypt.c. The real versions of these don't seem
to be hiding anywhere. Fortunately, all they did with these routines was
excise a few lines of code here and there. By comparing the .o files
produced from the source with the .o files in libc.a, I was able to fix
them up. I'd be happy to give diffs to any site that can convince me that
they have a Sun source license and are in the U.S. (I'm doing this
because it doesn't look like we're going to get a very quick resolution
from Sun.) Make sure that you fix this stuff up before building any
kernels from source, because the kernel makefiles grab some of the
lobotomized routines from the libc source area. This could lead to subtle
security problems, since in some cases it looks like you are getting
secure RPC, but they've just diked out the calls to the encryption
routines. (One would have expected that if they weren't going to provide
secure RPC, they'd make attempts to use it generate errors. Note however
that I haven't actually tried this, so I could be misreading the code.)
One thing I found is that the makefile for building libc does produce a
libc_pic.a. This is a library with all the libc routines compiled -pic.
It's exactly what you need to produce your own version of libc.so if you
don't have source. I can see no reason they couldn't put this on the
binary distributions. Probably they just didn't think of it. I'm not
sure quite who to ask to get it to happen, but somebody asked about this
in another message.
In response to the comment that things on sunspots seem to be getting more
negative: well, I don't know about sunspots, but I don't think overall Sun
is getting worse. But they are getting different.
In the last couple of years, Sun's field service has gotten much better.
Their sales support has gotten more organized and more professional.
The downside is that they've also become more bureacratic, and "open
systems" are in constant danger of turning from a reality into a slogan.
I'm not saying it has happened, just that it's a danger that some groups
aren't resisting.
The bureacracy shows up mostly in the difficulty of getting to the better
technical people. I've seen this happen to other companies as they grow
also. The problem is that as you get thousands of customers, inevitably
most of them are bozos, and you really do need bozo-catchers to filter
them out. Unfortunately, most companies' bozo-catchers don't understand
some of the more subtle technical issues. This is sometimes true at Sun
as well.
Open systems are actually doing fairly well. Their handling of NFS has
been very good. NeWS has languished, but not because of a commitment to
openness. As I see it, Sun is now putting their manpower into OPEN LOOK,
i.e. Sunview 2, rather than NeWS. This is a decision about priorities
which is almost certainly right, even though it will largely doom NeWS.
The main place openness is losing is in peripherals. It's clear that
somebody has decided Sun needs to stop losing as much disk business to
third parties. The normal Sun approach in such a situation is to come out
with high-speed controllers and find other innovative solutions. However
in this case, somebody has decided to make it difficult to put good disk
controllers into the system, and to force people to keep buying Xylogics
451's. This is bad for both the customers and Sun, and is not consistent
with the way Sun normally does business. I'm sure it will stop when
appropriate people in Sun think about it.
It's hard to grow rapidly and still keep a company's distinctive
character. Sun is doing at least as well as we could reasonably expect.
But there are places where they have failed, and they need to be pointed
out.
------------------------------
Date: Mon, 15 Aug 88 08:55 EDT
From: Sean Marrett McConnell Brain Imaging MNI 514-284-5830
<SEAN%PETVAX%medcor.mcgill.ca@moe.mcrcim.mcgill.edu>
Subject: Large distance between monitor and box
Back some time ago, I asked for help on the possibilities of installing
the monitor and keyboard of a monochrome 3/180 system more than 50 feet
from the system box. The response was overwhelming, and the answer was
yes. I won't try to quote all of the 25 replies (thanx, everyone), but
essentially all we had to do was make two long cables for our keyboard and
for the video output. I heard from site's that had cables as long as 150
ft from system to keyboard/monitor combo.
The cable to get for the video display is Belden 9891 AWM Style 2919 Low
Voltage Computer Cable. We used a second shielded, twisted pair cable for
the keyboard. Two weeks later, no problems yet.
------------------------------
Date: Mon, 15 Aug 88 15:18:44 EDT
From: jjb@gaea.cs.wayne.edu (Jon J. Brewster)
Subject: ypserv and sendmail.mx, revisited
I have resolved both nameserver kit problems which I reported to you.
(Actually that's an unfair characterization. Neither problem was with the
kit itself.)
First, ypserv was working properly. We have a slave and a master YP
server, and I only installed the new ypserv on the master for the purpose
of testing it. I neglected to do a ypwhich before trying out the query,
"ypmatch foreign.host hosts" and feel confident that the lack of results
was due to the query going to the unmodified server.
Secondly, the problem I was having with sendmail.mx was due to the host
database I was using with our nameserver. The construct $%y in
sendmail.cf would match any token at all (except, as I finally discovered,
"cs". Aha!). The nameserver would first try to find token.cs.wayne.edu,
and when that failed, it would try token.wayne.edu. Since there are no
hosts in that domain, I had never even put an SOA record in for it.
Surprisingly, the effect of not defining the domain is to make everything
a member of it. Everything except cs, of course.
------------------------------
Date: Sun, 14 Aug 88 16:21:57 PDT
From: (P. Graham) <pjg@solstice.unr.edu>
Subject: wren IV query
format.dat (this means 4.0 I guess) has an entry for the 344MB Wren IV.
This is the only entry with a cache field. Does this mean that using this
entry with format will turn on the Wren cache? Where did sun get the
geometry (it differs from the one posted earlier)? Does using a disk that
really has no geometry mess up the fast file system, or is it the case
that 90% of the speedup comes from the block size? Is it the imbedded
controller that causes my sd2 to appear to be unit #8? A reply via mail
would no doubt be best, but if anyone else wants these answers (and I get
any of them) I'll certainly forward them.
Another topic:
I need to run a uucp that supports the f protocol on a 4/110. I compiled
the 4.3-tahoe uucp on it but it dies immediately after making the
connection. Anybody have an answer for this one?
Just so I don't seem to be a total consumer:
When I installed 4.0 on my second disk, suninstall (which I sorta like)
made a nice little fstab that pointed to sd2 (I should have realized this
of course) so when I moved it to sd0 and booted it mounted usr from my 3.5
disk (now sd2) which placed the tools I now needed out of reach. No
problem I thought, I'll just boot off of unit 8. I don't remember seeing
anything that says you can't boot off of 8 but I sure can't. A minor
agony I'd like to spare someone else.
Paul Graham -- University of Nevada-Reno
uucp - uunet!unrvax!pjg
internet: pjg@solstice.unr.edu (MX mailing only)
------------------------------
Date: Mon, 15 Aug 88 08:55 EDT
From: Sean Marrett McConnell Brain Imaging MNI 514-284-5830
<SEAN%PETVAX%medcor.mcgill.ca@moe.mcrcim.mcgill.edu>
Subject: Using a DELNI with a Sun - Will it work ?
In the never-ending battle to save money, I am trying to piggy-back our
two new Suns (3/180, 3/280) onto a DELNI ethernet conentrator/transceiver
from DEC, which we have just received as part of another computer system.
Are we stupid to do this ? - and, if this can be done, where should we
purchase the ethernet controller-transceiver cable ?. We tried using DEC
PVC but it was just terrible - It didn't want to stay attached to the Sun
connection at ALL.
All comments/responses would be greatly appreciated.
Thanx
Sean
-------
Sean Marrett
McConnell Brain Imaging Centre
Montreal Neurological Institute
3801 University Street
Montreal, Quebec
Canada, H3A 2B4
(514)-284-5830
<sean%petvax@medcor.mcgill.ca>
<sean%petvax%medcor.mcgill.ca@moe.mcrcim.mcgill.edu>
<neuro@moe.mcrcim.mcgill.edu> <--- your best bet ?
------------------------------
Date: Sat, 13 Aug 88 20:09:16 PDT
From: adgrover@hac2arpa.hac.com (A. Dean Grover)
Subject: double buffering with pixrect?
Does anybody have a simple example of using double buffering with pixrects
under 4.0 ?
Thanks in advance,
Dean Grover
adgrover@hac2arpa.hac.com
Hughes Aircraft Co.
------------------------------
Date: Sat, 13 Aug 88 15:08:06 EDT
From: ghoti@cauchy.mit.edu
Subject: SIGIOT?
I ran a program on a SUN3 and it bombed out with a message about signal 6
SIGIOT. According to the online documentation, signal 6 is not generated
on SUNs. How then could I have gotten such a message ?
Also, what does that mean I should look for in debugging my program ?
I don't subscribe to this mailing list so please reply to me directly at
the address below.
Allan Adler
ghoti@cauchy.mit.edu
------------------------------
Date: 13 Aug 88 20:42:50 GMT
From: emory!km@gatech.edu (Ken Mandelberg)
Subject: Questions about Exabyte on Sun
I have a few questions about running an Exabyte 8mm tape drive on a Sun:
1) Two vendors tell me that the Sun SCSI driver in 3.5 and 4.0 are just
fine for the Exabyte. They supply only the drive and cables, and you use
the existing driver to treat it as a big fast st0. A third vendor tells me
that the Sun SCSI driver in 3.5 and 4.0 does not have all the
functionality needed to properly run the Exabyte, and I need their custom
software. Which is the case?
2) The great bulk of our disks are on our Sun 4 server, which has no SCSI
adapter. We do have a number of Sun 3/50 and 3/60s however, on the same
ethernet. This ethernet is very quiet during the hours the tape backups
would be done. Should I break down and buy a SCSI adapter for the Sun 4,
or will the performance over the ethernet be close enough. If we do get a
SCSI adapter for the Sun 4, is there any reason to go third party rather
than use the one Sun sells?
3) What's a good price for an Exabyte? The lowest of the three dealers I
talked to wanted $3700 for the Exabyte in a small shoebox including a
cable.
Any relevant comments or experience would be appreciated.
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963
------------------------------
End of SUN-Spots Digest
***********************