Sun-Spots-Request@RICE.EDU (William LeFebvre) (10/05/87)
SUN-SPOTS DIGEST Monday, 5 October 1987 Volume 5 : Issue 47
Today's Topics:
Administrivia: more delays
A pat on the back
Sun-4 upgrades don't support Sun-3 peripherals
OS installation slower than necessary (2)
Installation/upgrade scripts can easily run twice as fast
Re: troff previewer (3)
WYSIWYG editor for the Sun
NeWS and Postscript previewers
Re: disk drives
Re: fpa with MAGIC and Eagles with 2333
Putting Mac SCSI Disks on SUNs?
DES hardware for Suns?
----------------------------------------------------------------------
Date: Mon, 5 Oct 87 14:15:19 CDT
From: William LeFebvre <phil@Rice.edu>
Subject: Administrivia: more delays
Our mailer is still having problems coping with Sun-Spots digests.
Please bear with us as this delays mailing the digests out. Also,
please make sure you are up to date: this is issue 47. If you
have missed any, they are available in the archives.
------------------------------
Date: 28 Sep 87 22:51:48 GMT
From: root@hamachi.LGN.UUCP (Gary K. Sloane)
Subject: A pat on the back
I would like to publicly thank Julie Martin, a regional tech rep for Sun
Microsystems. We have had our share of problems with Sun technical
support, and *every* time we have been seriously frustrated, a call to
Julie has (instantly) straightened things out. Thanks Julie!
Sun could use a few more like Julie...
Gary Sloane
LOGICON Inc.
4010 Sorrento Valley Blvd.
San Diego, CA 92131
...!nosc!hamachi!root
------------------------------
Date: Mon, 28 Sep 87 17:42:38 PDT
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Sun-4 upgrades don't support Sun-3 peripherals
I've been wrangling with Sun over upgrading my Sun-3 to a Sun-4. Besides
the usual delays and frustrations of trying to get Sun to sell you
something :-) another issue has arisen.
Various peripherals that were supported on Sun-3's are not supported on
Sun-4's:
SCSI disks
130 MB SMD drives
1600 BPI tape drives
FPA floating point boards
parity memory boards
1152x900 monochrome monitors
For the last three, there's a clear technical reason for the lack of
support: if you plug them in, they don't work. But the first three work
just fine, Sun just won't support them any more.
Now, what does "not supported" mean? It seems to mean that you can't get
a support contract on a system that contains these peripherals. They'll
sell you parts, but not a service contract. The I/O drivers are probably
there and probably work, but no guarantees.
Now Sun will sell you a support contract on a system containing third
party disks or third party serial ports or third party tape drives or any
other third party I/O gear (as long as there is access via ether to
Sun-supplied tape and disk), but they won't sell you a support contract on
a system where THEY SUPPLIED ALL THE HARDWARE!
I've brought this up with both Chris Saleh, the Sun-4 marketing manager,
and other people within Sun. Their response is that they don't want to
support these systems because customers will not be happy with the
performance of these I/O devices on a Sun-4, and because the Sun-4 SunOS
binaries will not fit on the smaller disks. I think this is a job for the
configuration guide, not for the support policy!
For my system, it's a moot point because Sun support is too expensive for
me to want it. But as a stockholder I see Sun shooting itself in the foot
with this policy. It's hard for a company to claim to be the leader in
open architecture systems, where you can plug in anybody's gear and make
it all work, when they won't even support the I/O gear they sold you last
year.
So far they think I'm alone on this issue. Nobody else has complained.
It could be that nobody else has been told that their peripherals are not
supported, or it could be that nobody is buying Sun-4 upgrades, or it
could really be that nobody else cares. If you do care, please send an
email message to Chris Saleh (sun!csaleh or csaleh@sun.com), telling him
how many Suns you have, and how this policy affects you as a customer.
Send me a cc on it (sun!hoptoad!gnu or gnu@toad.com) so I can see whether
I'm crazy or not.
John Gilmore
------------------------------
Date: Tue, 29 Sep 87 14:07:07 PDT
From: amdcad!phil@decwrl.dec.com (Phil Ngai)
Subject: OS installation slower than necessary (1)
I have noticed that installing Sun OS 3.2 from a 1/4 tape requires
rewinding the tape for each "file", presumably to read the table of
contents. Considerable time could be saved if the excessive backwards
motion were eliminated.
1) I am aware that the tape drive has to reposition the tape by a small
amount, a few inches, each time a read completes. I am talking about a
much greater tape motion, almost to the beginning of the tape, where the
TOC is.
2) File is used in the sense of tape files, each of which is presumably a
tar file holding many disk files. Each file corresponds to one of the
subsystem choices such as uucp software, versatec software, games, etc.
I would guess Sun doesn't notice because they do most of their loading
over the network. But for small sites, time on the order of hours is being
wasted.
------------------------------
Date: Tue, 29 Sep 87 15:56:18 PDT
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: OS installation slower than necessary (2)
I noticed this last time I did an upgrade (3.0 to 3.2). One problem is
that the 'tar' command does not read to EOF, but only to a block of zeros
in the archive; this leaves the tape positioned almost at the next file,
but not quite. Another is that due to this sort of problem, people are
never quite sure of the tape's position, so the installation shell scripts
were written to be safe rather than fast (rewinding to the start of the
tape, and forward-spacing to get to where they want). The effect of
getting the wrong tape archive would be a very odd system (e.g. if you
extracted the fortran compiler into /etc).
However, it is possible to fix 'tar' to make its tape position reliable;
I've done it. I sent the following bug report in to Sun. I don't know
whether any of it is done for 4.0 or will ever be done.
John
------------------------------
Date: Wed, 13 May 87 18:31:48 PDT
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Installation/upgrade scripts can easily run twice as fast
While reading the shell scripts used to install the 3.2 release, I noticed
a few things that can speed it up.
(1) There is a loop that deletes all the old files before reading in the
contents of the tape. This loop has a bunch of tests in it simply to
avoid removing a few files. It would be better to move those files
elsewhere, remove things, then move them back; or grep their names out of
the list of files. Doing it the way the UPGRADE script does it, invokes
rm hundreds of times when it really only needs to call it once with a
large arg list. If you're afraid that argv will overflow (and haven't
fixed that bug by 4.0) then you could just feed the list of files to
"xargs rm" now that we have xargs.
(2) The biggest waste of time in the upgrade is the constant rewinding
and spacing of the tapes. There is a pretty easy way to fix this, but the
fix is in several places:
(2a) Fix the tar command so that it does not write garbage
after the zero records that indicate end-of-archive. Currently
you get whatever data was out there. It should be all zeros all
the way through the end of the last block.
(2b) Provide an option on tar to ignore the zero records, and
only actually stop when it sees EOF on the archive. If you invoke
tar this way in the upgrade scripts, this option will cause it to
read the entire tape file, leaving the tape positioned at the
start of the next file, ready for the next 'tar' command.
Unfortunately, this must be an option rather than the default, for
compatability with shell scripts that expect the previous
behaviour; and because reading the garbage produced by old tar's
after the zeros can often cause it to try to re-create a file that
the previous block created, often producing a truncated file.
*** I have implemented the above two changes in my public
*** domain 'tar' command and there are no complications or
*** undesirable side effects from them.
(3) Fix the "verify" and "extracting" scripts to keep track of
which tape is mounted and which file within the tape has just been
read. This info can be kept in a file in /tmp (in the miniroot).
Verify can rewind the tape if the file in /tmp does not exist, or
if its tape number is not the one requested, or if the file number
desired is low (say 0, 1, or 2). Extracting can avoid the 'mt
fsf' operations if the file in /tmp indicates that it is
positioned at the desired file; and can update the file in /tmp
when it is done. It could remove the file while it is actually
spinning the tape, to make sure that if the user aborts, the tape
position is known to be unknown.
The effect of all of this is that the tape will just move forward and will
never have to rewind. Currently "to be safe" is is constantly rewound and
forwardspaced. The upgrade can be done in half the time without this
waste.
I presume the same kind of checking has been put into the scripts run by
'setup' too. It can benefit the same way.
John
[[ Good suggestions. Have you sent them to Sun? --wnl ]]
------------------------------
Date: Wed, 30 Sep 87 15:13:54 EDT
From: ted@braggvax.arpa
Subject: Re: troff previewer (1)
There was a troff previewer called tseetool on the Sun User's Group 1985
tape. It was originally for sun 1.X, but seems to work (without
recompilation) through sun 3.X. A useful tool.
Ted Nolan
ted@braggvax.arpa
------------------------------
Date: Tue, 29 Sep 87 10:20:11 pdt
From: Jeff Lo <ucbcad!ames!elan!jlo@ucbvax.berkeley.edu>
Subject: Re: troff previewer (2)
Elan Computer Group, Inc. sells a ditroff previewer to run under either
SunView or X-Windows (currently V10R4, V11 is in the works). It supports
all of DWB 2.0 (including pic, grap, tbl, eqn, font and size changes) and
Elan's troff enhancements (including bitmap graphics inclusion). Call or
write for details.
Jeff Lo
ELAN Computer Group, Inc.
410 Cambridge Avenue, Suite A
Palo Alto, CA 94306
(415) 322-2450
..!{ames,hplabs}!elan!jlo
------------------------------
Date: 30 Sep 87 00:43:51 GMT
From: roy@uunet.uu.net (Roy Smith)
Subject: Re: troff previewer (3)
Jon Kay <mwh_adev%JHUNIX.BITNET@wiscvm.wisc.edu> wanted to know about
troff previewers for Suns. Well, it's pretty grotty, but I've been known
to just do "troff -a | more". You get an ascii aproximation which means
that all the line and page breaks are in the right places, even if the
spacing is all screwey and the font and size changes aren't there.
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Thu, 01 Oct 87 08:55:26 NOR
From: Jeremy Cook <JMC%NOCMI.bitnet@jade.berkeley.edu>
Subject: WYSIWYG editor for the Sun
Maybe I'm missing something but I've just ordered what looks to be the
best thing since sliced bread in desktop publishing packages. I have not
actually seen the real thing yet so maybe someone out there who has will
be flaming on soon but...
In TUGboat Vol 8, Numbers 1 and 2 (April and July 87) ArborText inc
advertise {\it The Publisher}. This is a desktop publishing system that
uses TeX as its mechanism internally but displays your formatted documents
on the screen of a Sun 3. I phoned a very nice lady at ArborText (Jill)
who assured me that you can also import and export TeX documents to
{\it The Publisher}. The announcement also promises that you can create
equations and tables "without entering a single backslash" with their
WYSIWYG equation maker and table maker. Also promised is an integrated
paint and draw program which can also grab portions of the Sun screen for
inclusion in documents.
Orders placed before October 31st will receive their copy for half price
(that's $750 with 25% educational discount).
ArborText's number is (313) 996-3566 and I spoke to Jill who knew all
about it. Hope this is of help. (My copy is on its way, will let you know
how good it is soon...)
-- Jeremy
[[ For those not familiar with TeX: "{\it The Publisher}" sets
"The Publisher" in italics. --wnl ]]
------------------------------
Date: Tue, 29 Sep 87 13:55:33 EDT
From: lear@aramis.rutgers.edu (eliot lear)
Subject: NeWS and Postscript previewers
With NeWS comes a program called psview which allows you to preview
PostScript files. You would probably have to remove any machine specific
code as might be encountered when using the latest version of dvi2ps.
There is also a PostScript previewer available for X users.
Eliot Lear
[lear@rutgers.edu]
[[ As several people have informed me, NeWS has been available for several
months already. Shows you how well informed I am! But I have been told
by a reliable source that neither previewer (the NeWS 1.0 and X versions)
can handle the output from Transcript or from MacDraw. --wnl ]]
------------------------------
Date: 30 Sep 87 00:43:51 GMT
From: roy@uunet.uu.net (Roy Smith)
Subject: Re: disk drives
In v5n45, Root Boy Jim <rbj@icst-cmr.arpa> said, regarding cabling up SMD
drives on a Sun: "Also, beware of Sun's funny cabling. Run Standard A & B
cables directly from the controller to the drives. Good luck."
I don't think that's correct. Don't the command (I forget which is A and
which is B, but I know the skinny one is the command) cables run radially
from the controller to each drive and the data cables daisy-chain from
drive to drive? That's the way I have my twin 2351's on a XY-450 and it
works fine.
Now, for a question. We just shipped back a (different) DOA 2351 which we
got from S&S electronics (who claim to be the people from whom Sun buys
their drives). The man in tech support at S&S tried to explain to me on
the phone how to set the sector-count jumpers. The configuration he gave
me is for 595-byte sectors, which he says is how Sun wants their drives
shipped to them. According to the XY-450 manual, you set the sectors for
600 bytes which gives you 46 full sectors and a runt. I did this on my
last drive and it worked like a charm. The 595-byte/sector setting
doesn't even appear in the big table in the 2351 CE manual. Does the tech
support guy know what he's talking about?
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Mon, 28 Sep 87 16:21:47 PDT
From: Brent Chapman <koala!brent@lll-tis.arpa>
Subject: Re: fpa with MAGIC and Eagles with 2333
>From: Root Boy Jim <rbj@icst-cmr.arpa>
>> From: Steve Levitan <levitan%pitt@relay.cs.net>
>> We are thinking of hooking up a M2351 (eagle?) onto our machine. The
>> eagle has been used for the past 3 years on a VAX/750 and the vms users
>> claimed it was a 450 meg device. Sun setup claims that a M2351 is a 500+
>> meg device. Is this a formating issue?
>Probably. Also be aware that Sun only uses 46 sectors instead of 48, at
>least on an XY450. However, even on a VAX, I get (48*20*842)/2=404Mbytes.
>Even allowing for the fact that 1024 != 1000, I only get 413Mbytes. With
>46 sectors/track, you are down to 388Mbytes.
Sun sells two Fuji "Eagle" drives: the original M2351 "Eagle" and the
M2361 "Super Eagle". The M2351 is 380MB formatted, and the M2361 is 575MB
formatted. Are you sure you weren't reading the line for the M2361 from
the "setup" line? If you're sure, then chances are there's a typo in the
setup program.
-Brent
Brent Chapman Senior Programmer/Analyst
ucbvax!lll-tis.arpa!koala!brent Capital Market Technology, Inc.
koala!brent@lll-tis.arpa 1995 University Ave., Suite 390
Phone: 415/540-6400 Berkeley, CA 94704
------------------------------
Date: Mon, 28 Sep 87 15:12:26 EDT
From: dean@systems.cs.cornell.edu (Dean Krafft)
Subject: Putting Mac SCSI Disks on SUNs?
Does anyone out there have any information on the possibility of putting
Mac SCSI disk drives on SUN-3/50s or 3/60s? As I look through the latest
MacWorld, I find, for instance, Jasmine Technologies selling 80MByte SCSI
hard disks for $1399. This compares favorably with the net $3000 list
price for the 71MByte SUN disk (when packaged with the 3/50 or 3/60) or
even with the $2100 price after a 30% discount. I also suspect that the
Mac prices are headed nowhere but down.
Dean Krafft (dean@gvax.cs.cornell.edu)
Department of Computer Science
Cornell University
------------------------------
Date: Mon, 28 Sep 87 13:58:25 PDT
From: weiser.pa@xerox.com
Subject: DES hardware for Suns?
There is a device driver, there is a command 'des(1)' which discusses
hardware, but there is not on the sun price list any mention of DES
hardware for suns, and my Sun salesperson says she never heard of such an
option.
Presumably this is just a chip one plugs into the board, plus some
documentation. Any one know how to order it?
-mark
------------------------------
End of SUN-Spots Digest
***********************