Sun-Spots-Request@rice.EDU (William LeFebvre) (01/15/88)
SUN-SPOTS DIGEST Wednesday, 13 January 1988 Volume 6 : Issue 2
Today's Topics:
rpcsrc files in the archives are fixed
Re: compiler(iropt) error: find_parent: couldn't find parent
Re: Quota problems (v5n70)
Re: incomplete loading of images
Re: Licensing question
Re: Delinquent ttyp* terminals
Confining users
Followup on Ciprico controller
Sun-4 delivered and performing well
SLIP and vt100tool are both on the '87 Sun User Group tape
Image Processing SIG
Dumps on Sun to 1/2 inch reels
Sendmail problems (where does the Sun.COM come from ?)
SunView Event Recorder?
Intel 386 cross development info?
OCLI filter on Sun workstations?
Looking for dvisun
----------------------------------------------------------------------
Date: Thu, 14 Jan 88 10:42:02 CST
From: William LeFebvre <phil@Rice.edu>
Subject: rpcsrc files in the archives are fixed
Stephen Nahm has sent me better versions of the two rpcsrc files that were
causing people trouble. These files (rpcsrc.doc.11 and rpcsrc.doc.13)
should now be transferrable via mail (and thus retrievable via the archive
server). Those who were getting truncated versions should try again.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Wed, 16 Dec 87 18:36:31 EST
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: compiler(iropt) error: find_parent: couldn't find parent
I suspect the error about T[966] really means that the compiler is trying
to find the parent node for tree entry 966. Most likely, when f77pass1 is
ripping out unused variables and associated expressions it sometimes mucks
up the node structure (at a guess: removing both a node and its parent
breaks subsequent nodes' parent refs). None of this really matters, since
Sun does not give out compiler sources.
> is there any documentation about the [following] compiling
> process available to joe user....
Most of this is stuff you would not want to deal with directly. The `f77'
command is supposed to handle all normal options. Of course, if you want
to debug the various pieces, you will have to deal with them individually.
But then, Sun does not give out compiler sources. This is all conjecture:
> /usr/lib/f77pass1 -O lines.f [tempfiles]
f77pass1 `parses' FORTRAN and compiles it to an intermediate node format.
-O is Optimise.
> /usr/lib/iropt -O -fc [tempfiles]
iropt is InteR?mediate OPTimiser: it works on this intermediate node
format, finds basic blocks, and does all those things that you find in
compiler books (Principles of Compiler Design, Aho/Sethi/Ullman, is the
standard reference around here).
> /usr/lib/cg -ffpa -mc68020 [tempfiles]
This is obviously the Code Generator. -ffpa says use the FPA floating
point code, and -mc68020 says generate 68020 assembly code.
> /usr/lib/inline -i /usr/lib/ffpa.il [tempfiles]
inline expands certain subroutine calls in line, as defined by the file
/usr/lib/ffpa.il. (4.3BSD has a similar program, also called `inline',
but it resides in /sys/vax/inline rather than /usr/lib.)
The next two are not conjecture; the Unix compilers have used these for
years:
> /lib/c2 -20 -dscheduling [tempfiles]
c2 is a peephole optimiser (again, look at various compiler books).
> /bin/as -o lines.o -mc68020 [files]
as assembles the assembly code into object code, ready for linking. You
can use the assembler yourself; there are several manuals for it in with
the stuff Sun distributes.
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
------------------------------
Date: Thu, 17 Dec 87 09:56:29 CST
From: "Matt Crawford" <matt@oddjob.uchicago.edu>
Subject: Re: Quota problems (v5n70)
See "man quota". Quota and noquota are not valid options for NFS file
systems. The server has sole control over whether quotas are enforced.
The client makes rpc calls any time it might want to know about quotas.
(If you have a filesystem mounted from a hung server, this can cause
logins to pause for a long time as all your quotas are checked.)
Matt Crawford
------------------------------
Date: Thu, 17 Dec 87 18:01:11 PST
From: bickel@nprdc.arpa (Steven Bickel)
Subject: Re: incomplete loading of images
I have had problems that are possibly similar to the incomplete loading
although mine have occured during runtime (more often with dbx).
My problems occured while running a 2 meg executable on a 3/160c. This was
a simulation program that appeared to consume too much of the virtual
memory (ram + swap) and was alleviated by any measure that reduced the
memory shortage problem: Increase swap space on disk, delete unused memory
from nearly full /usr partition (swap was on the same disk), run without
dbx, run in black and white instead of color, run with fewer memory
consuming variables (windows) ... etc. Our system consumes more memory
the further along its linear execution path it has progressed and the more
memory it appeared to have the further along it ran until some obscure
Segmentation fault or malloc failure/valloc failure occured. Running with
a graphics processor without a graphics buffer seemed to compound the
problem more that without either -?? My problems occured with and
without the fpa installed. I hope this helps. Any other info you find
helpful concerning this problem would be appreciated.
Steve Bickel bickel@pacific.arpa
Systems Engineering Assoc. (619) 553-7675
Naval Personel R & D Center.
------------------------------
Date: Wed, 16 Dec 87 16:15:17 EST
From: steinmetz!stpeters@uunet.uu.net (Richard L Stpeters)
Subject: Re: Licensing question
>If the Suns are not source-licensed, then you are violating your license
>if you put any licensed source on them. Furthermore, you should read the
>fine print on your non-source licenses very carefully: I think they
>usually say that updates to the licensed software must come from your
>vendor, or words along those lines. That is, no, you can't cross-compile
>on the VAX and copy the object modules.
I suspect things are not so simple. First, what's an "update"? If I've
got licensed source on my VAX for some utility not provided by Sun, it
would be hard to argue that cross-compiling on the VAX and copying object
code amounted to an "update". The original posting asked about source
code "with modifications". When does "modified source code" become a "new
program" incorporating parts of licensed source? After all, having a
reference on how to do things is part of why we pay money for source in
the first place.
Second, when does licensed source become "on my Sun"? If my Sun NFS-
mounts the partition where the VAX with the license keeps the source, does
that count? If I rlogin to the VAX from a commandtool and cat the source,
the source is then stored in my Sun's memory. Does that count? I wrote a
remote-editing GNUemacs package based on using rsh buffer processes (there
are others around based on ftp) - if I have the VAX-licensed source in an
emacs buffer, does that count?
How about the following:
vax% /lib/cpp <source.c | rsh sun '/lib/ccom | /lib/c2 >source.s'
Was the source ever "on the Sun"?
It's pretty evident there's a big gray area here - but there are also some
clear rights and wrongs.
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa
uunet!steinmetz!stpeters
------------------------------
Date: 18 Dec 87 05:14:49 GMT
From: elroy!david@ames.arpa (David Robinson)
Subject: Re: Delinquent ttyp* terminals
Unfortunately this problem STILL exists in SunOS 3.4! It is indeed an
*OLD* problem that I first saw in SunOS 0.4 back in 1983.
It is a tricky problem with no easy solution. Normally programs such as
rlogind clean it up when the slave (login) process is killed. The trouble
in suntools etc is that if you kill the master process it has no way of
cleaning things up.
David Robinson elroy!david@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!
------------------------------
Date: Wed, 16 Dec 87 13:25:04 CST
From: Keith Cooper <cooper@rice.edu>
Subject: Confining users
At Rice, we have encountered this problem in the context of undergraduate
education. Junior computer abusers are dealt with by a disciplinary
committee; one of the punishments that they select is to place the user in
a "padded shell" (name due to Mike Caplinger, original SunSpots editor).
The padded shell simply does a chroot(2) to the user's home directory and
then invokes the standard shell. Of course, the code that does the
chroot() must be installed setuser to root, so it is short and simple.
This has the overall effect of limiting the user to precisely the set of
commands that the system manager provides in his/her bin directory. It
has proven to be a successful way of stopping undergraduate students with
a tendency to raise hell. Of course, using this punishment once or twice
appears to have had a nice socializing effect - our hacking problems seem
greatly diminished.
Anyway, here's the source code for chrootsh.c
====
#include <stdio.h>
#include <pwd.h>
#include <sys/types.h>
#include <sys/stat.h>
main(argc, argv, envp)
int argc;
char *argv[], *envp[];
{
register struct passwd *pp;
register char cl[512];
register int i;
register int uid;
register int gid;
struct stat st;
uid = getuid();
gid = getgid();
pp = getpwuid(uid);
seteuid(0);
setegid(0);
if (chroot(pp->pw_dir) != 0)
{
fprintf(stderr, "CHROOT(2) unsuccessful.\n");
exit(1);
}
seteuid(uid);
setegid(gid);
if (stat("/bin/csh", &st) != 0)
{
perror("chrootsh");
fprintf(stderr, "No /bin/csh !\n");
exit(1);
}
execve("/bin/csh", argv, envp);
}
===
keith cooper
(cooper@rice.edu)
------------------------------
Date: Fri, 18 Dec 87 00:35:17 EST
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Subject: Followup on Ciprico controller
We now have a resolution on 2 of the 3 loose ends I mentioned in my review
of the Ciprico Rimfire. The most serious was that our Sun crashed about
once a day. This turned out to be a bug in the device driver supplied by
Ciprico. If you wrote a number of bytes that was not an even multiple of
a disk sector, it rounded down to disk sectors. It should be rounded up.
Almost all I/O is done in sectors. As far as I can tell, the problem
occurs only when swapping out text segments. So the result is that the
system crashes when a text segment has been swapped out and gets swapped
back in. The fix is fairly simple. Ciprico has it now. At about the
same time, our unexplained non-ECC data errors also disappeared. We now
consider the Ciprico controller to be solid.
[[ As someone at Sun said to me, for once it wasn't Sun's fault! --wnl ]]
------------------------------
Date: Wed, 16 Dec 87 20:40:31 CST
From: steve@ncsa.uiuc.edu (Steve Christensen)
Subject: Sun-4 delivered and performing well
In SunSpots v5n70 John Gilmore asks about Sun-4 deliveries. I have had my
Sun-4/260 for about 2 months now (the first one in Illinois I think). I
am extremely happy with it so far. First thing, I ran all of the usual
benchmarks to see if the numbers I saw quoted by Sun were realistic. I
found that they were accurate and in some cases a bit conservative. My
machine has 32 megabytes of memory and 560 megabytes of SMD disk. I am
running a high resolution monochrome monitor off the CPU board and a color
monitor on a CG3 color board. I run the two screens simultaneously using
"adjacentscreens". I am currently running the 3.2L beta release of the
OS.
Next after the benchmarks, I ported most of the standard Sun demos over to
the 4. This was done with very little effort in general, usually with
minor changes to the optimization flags in the Makefiles. The rpcmand
demo is particularly nice on the 4 since it runs 4 times faster than on
the 3/160C with FPA that I have sitting next to the 4 in my office. The
windows in Sun View are a joy to use now since they pop in and out so
fast. A textedit window bringing up a C code with about 1000 lines
appears on the screen almost instantly. The color monitor that I got with
the CG3 board is to my eye twice as bright as the color monitor I have on
the 3/160C.
I currently have only the C compiler, but expect FORTRAN and Lisp soon. I
and some people here at the University and the NCSA have ported several
large C codes (one a Cray/Sun emacstool, one a tool called Imagetool and
another a large symbolic manipulation code written in C). In general, if
one follows the information on porting a C code to the 4 in the manuals
provided, the ports are straightforward. The resulting code on the 4,
which is a mixture of integer and floating point, runs around 3 to 5 times
faster than on a 3/160 with FPA. I am really looking forward to running
NeWS on the 4 since I find it a bit slow on a 3/160.
32 megabytes of memory makes a big difference to performance as you might
expect.
So, cleary I am very happy with the 4 so far. It has been turned on
continuously for the weeks that I have had it and I have had no hardware
gliches of any kind. I am anxious to get the "real" operating system and
a lot more software. I will then happily give away my 3 to some less
fortunate person. Give me some faster floating point and I will be
challenging our Cray to a duel.
Perhaps I have just been lucky with an early machine. I will look forward
to hearing other reports.
Steve Christensen
Research Scientist
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
[[ Pierre Mackay, The UnixTeX co-ordinator at University of Washington,
reported on TeXHax that it took his Sun4 only 3 minutes to generate an
executable for initex. That's 3 minutes to go from Web to executable.
Anyone who has had to sit and wait for a "make initex" to finish will
certainly appreciate this news! --wnl ]]
------------------------------
Date: Thu, 17 Dec 87 13:10:56 PST
From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu>
Subject: SLIP and vt100tool are both on the '87 Sun User Group tape
SLIP and vt100tool (and lots of other good and useful stuff) are both on
the '87 Sun User Group tape, which SUG started making available at their
conference in San Jose earlier this month.
You can reach the Sun User Group at:
Sun Microsystems User Group, Inc.
2550 Garcia Avenue, MS 10-16
Mountain View, CA, USA 94043
+1 415 960 1300
sun!users
users@sun.com
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704
capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400
------------------------------
Date: Thu, 17 Dec 87 23:37:33 EST
From: berger@datacube.com (Bob Berger)
Subject: Image Processing SIG
There was a gathering of people at the Sun User's group who are interested
in Image Processing. I volunteered to collect and then send out the
people's names who are interested in staying in touch about Image
Processing and Suns. If you were not there and would like to be on the
mailing list please send the following information:
Name
Organization
US MAIL Address
Email address
What your Image Processing Interests are
Send it to:
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, rutgers!datacube!berger, ihnp4!datacube!berger
{cbosgd,cuae2,mit-eddie}!mirror!datacube!berger
------------------------------
Date: Wed, 16 Dec 87 15:39:52 CST
From: Chris Johnston <chris@gargoyle.uchicago.edu>
Subject: Dumps on Sun to 1/2 inch reels
Try increasing the blocksize. If the dumps don't go faster at least
you'll use fewer reels per dump.
A 6250bpi tape drive on a Sun3/280s here has a maximum block size of 126.
(That's 63 Kbytes).
Use something like...
dump 0undbf 6250 126 hostname.tape:/dev/rmt16 /dev/rxy0f
Warning: When using restore you must explicitly tell it the block size you
used when writing.
Note: When dump reports the number of tape blocks written it means the
number of kilobytes written.
cj
------------------------------
Date: 16 Dec 87 07:35:03 GMT
From: mcvax!crin.crin.fr!tombre@uunet.uu.net (Karl Tombre)
Subject: Sendmail problems (where does the Sun.COM come from ?)
We switched over to domain addressing here some time ago. We are in the
domain top-level domain .fr (France), sub-domain .crin. A sysadmin at a
french research lab wrote a sendmail.cf file which we installed (with some
hacking) on all our machines, with some differences of course between the
VAX (which has the actual uucp connexions) and the Suns, which are
allusing NFS and yp.
As the sendmail.cf is not completely stable, it sends a copy of all error
messages it produces to postmaster, that's me. Therefore, on all Suns I
put in the aliases a line like:
postmaster: tombre
In most cases it works. But sometimes (I haven't been able to find a
"common denominator" for these times) the error is not sent to me on my
favorite machine using the standard forwarding mechanism, but to
tombre@Sun.COM !!!! I checked our sendmail.cf : there is NO Sun.COM
mentioned in it. I then thought that it might be a default chosen by
/usr/lib/sendmail, for instance when the forwarding didn't work (you know,
when the machine having my diskspace is down...). But
strings /usr/lib/sendmail | grep -i 'sun.com'
didn't find anything either.
The problem is quite annoying: the message travels over to the US, to the
actual machine Sun.COM, and comes back. The error is mostly intercepted on
its way back by the mailer at inria (french backbone) and the mail admin
for inria complains regularly about this stuff.
My question is: what is generating this stupid Sun.COM address? And what
can I do to prevent it. I have thought of changing the postmaster alias to
include my full domain address (tombre@crin.crin.fr), but then I would
have to change it on all the Suns. Is it the right thing to do?
Please answer by E-mail preferably.
--- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy)
EMAIL : tombre@crin.crin.fr -- tombre@crin.UUCP
POST : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France
PHONE : +33 83.91.21.25
------------------------------
Date: Thu, 17 Dec 87 11:17:18 EST
From: sunrise!gotham!ursa!sugar!jeff@sun.com (Jeff Langer)
Subject: SunView Event Recorder?
I would like to be able to record all the events generated by someone
running my SunView application. Some time later I would like to be able
to play back the events to simulate the earlier run. The events that I am
interested in are mouse movement and mouse button clicks as well as
keyboard typing. Does any one have software that does some or all of this?
Mail may be sent to 'sun!sunrise!ursa!jeff'.
Thank you.
Jeff Langer
Bear Stearns
(212) 272-3046
------------------------------
Date: Wed, 16 Dec 87 15:18:31 -0500
From: uiucdcs!philabs.Philips.Com!hyw@uunet.uu.net
Subject: Intel 386 cross development info?
We are considering doing some cross development work for an Intel 386
machine from the Sun. In particular, we would like information on various
cross development tools namely,
1) C cross compiler/linker/assembler.
2) debugger/disassembler that runs on the Sun.
Any pointers/experiences will be greatly appreciated.
Thanks in advance.
------------------------------
Date: Wed, 16 Dec 87 14:51 EST
From: MARSELLE%gmr.com@relay.cs.net
Subject: OCLI filter on Sun workstations?
Anyone ever use a Sun with an OCLI filter for reducing glare? I'm trying
to decide if it's worth $500 on a Sun-3/60 monochrome workstation.
jim marselle
marselle@gmr.com
------------------------------
Date: Wed, 16 Dec 87 13:22:44 PST
From: pyramid!weitek!robert@decwrl.dec.com (Robert Plamondon)
Subject: Looking for dvisun
I heard a while back that there was a version of dvisun that ran under
suntools. Does anyone know where I can get it? I'm not on the Internet,
so anonymous FTP isn't an option. I can set up a uucp link to anywhere,
or use mail, though.
-- Robert
Robert Plamondon
UUCP: {pyramid,cae780}!weitek!robert
ARPA: pyramid!weitek!robert@decwrl.dec.COM
[[ I don't know if there is specifically a tool version of dvisun, but
there is the VorTeX system from Berkeley which includes "dvitool", a dvi
previewing tool. You can find out all the requisite information by
sending your U.S. Mail address to "dist-vortex@ucbvax.berkeley.arpa".
--wnl ]]
------------------------------
End of SUN-Spots Digest
***********************