Sun-Spots Digest, v6n151
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri Jul 29 01:45:52 AEST 1988
SUN-SPOTS DIGEST Tuesday, 26 July 1988 Volume 6 : Issue 151
Today's Topics:
Re: Tek 41xx emulator
Re: Looking for feedback on 15-pin Ethernet connectors
Another security hole in "lockscreen"
Bug with cc -M
SunOS 4.0 warning
malloc
Cables for Suns
gettimeofday clock resolution
yp provided by Sun, DEC and who else?
adjusting kerning in Sun's Transcript for troff?
thanks for the ISIS information
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Wed, 13 Jul 88 14:12:13 PDT
From: Bill Randle <billr at saab.cna.tek.com>
Subject: Re: Tek 41xx emulator
Reference: v6n134
A company by the name of The Bristol Group Ltd. has a product that does
what you need. It's called 'iostek' and emulates a Tek4125, 4115B, 4107
and most other 41xx and 42xx terminals on a color Sun. What's really nice
is that the window is resizable (i.e. you can make a 19" 4107 window!). We
have evaluated isotek for use on our project and it looks like a nice
package.
The Bristol Group Ltd
PO Box 910
Londonderry, NH 03053
(603) 437-3700
-Bill Randle
Tektronix, Inc.
billr at saab.CNA.TEK.COM
[[ Thanks also to Brian Litzinger for a similar submission. --wnl ]]
------------------------------
Date: Thu, 14 Jul 88 09:09:26 EDT
From: shn at think.com
Subject: Re: Looking for feedback on 15-pin Ethernet connectors
I have two suggestions for fixing the problems these connectors
1. Lock washers under the binding posts. I have seen up to three lock
(split) washers on the little binding posts. Binding posts are those
little things on the cable ends where the screws are on RS-232 connectors.
The flimsy metal clip is supposed to catch the binding posts and hold the
connector in place. I have taken the washers off and put the posts back
in place. This allows the connectors to mate closer and still use the
metal clip.
2. Remove the binding posts and the clip altogether. Admit it, how many
terminals do you have at your site where the RS-232 connectors are not
even screwed in? I bet the screws for the keyboard cable to the Sun you
are using right now are not on tight :-) The truth of the matter is that D
connectors hold them selves in place rather well. So take that crap off
the connector and just plug it in. You will probably find the connector
goes in twice as deep and stays there just fine.
Sam Nuwayser (shn at think.com) Thinking Machines Corporation
------------------------------
Date: Wed, 13 Jul 88 10:20:36 EDT
From: brittain at aiu1.ic.ornl.gov (Carlton Ray Brittain)
Subject: Another security hole in "lockscreen"
lockscreen -e
adds an Exit Desktop option to the password screen. This should exit
sutools and logout the current user.
Instead, all open windows and some (but not necessarily all) of the icons
on the desktop disappear. Anyone is then free to open new windows and
continue as the user who was previously using the machine.
I am using Sun OS 4-3.2 on a 4/110 workstation. I'm not sure if other
machines and OS's have the same bug.
Carlton Ray Brittain brittain at aiu1.ic.ornl.gov
Oak Ridge National Lab
MS-8, Bld. 3500 Phone: (615)574-8949
P.O. Box 2008
Oak Ridge, TN 37831-6008
------------------------------
Date: Wed, 13 Jul 88 19:05:02 PDT
From: Craig Leres <leres at helios.ee.lbl.gov>
Subject: Bug with cc -M
Back in June I put up 3.5 and started compiling kernels from source. When
I installed Van's network code, I found it necessary to use the 4.3 style
"make depend" (which uses a mkdep script and cc -M instead of egrep and
awk). At this time, I discovered a bug with cc -M; as each file is
processed for dependicies, its name is incorrectly written to stdout (see
the example below).
I found and fixed the problem and sent the appended bug report to
hotline at sun.com. Within 24 hours, I got back a friendly acknowledgement
that said a software engineer had been dispatched to handle my problem and
requested me to phone back if I didn't get a response within the next 24
hours.
Today, I got a call from the "software engineer" (more than 24 DAYS
later). After spending 30 minutes on the phone with this guy, he was still
unconvinced that I had found a real bug. I explained that -M was a 4.3 BSD
feature and that the Sun code did not correctly implement this feature. He
seemed to think that SunOS is not 4.3 BSD and so there's no need for cc -M
to behave in exactly the same manner. He suggested that I use /lib/cpp -M
directly or "better yet" use some SunPro widget that would do the job much
more efficiently. I told him that that I was confident that if person at
Sun who had written /lib/compile saw my bug report, they would agree it
was a bug. He begrudging agreed to forward my bug report to the
developers.
Needless to say, this is probably the last bug report I make to the
hotline at sun.com. But I hope those of you who use 4.3 BSD makefiles under
SunOS will find it useful.
Craig
------- Forwarded Message
Date: Tue, 14 Jun 88 20:29:44 PDT
From: leres at helios.ee.lbl.gov (Craig Leres)
Subject: Bug with cc -M
To: hotline at sun.com
Index: lib/compile/setup.c SunOS 3.5
Description:
I've discovered a minor bug in "compile" after installing
version 3.5 of SunOS on my Sun 3/160 file server (system
serial number ???????, id prom ????).
The problem is that source file names are printed on stdout
when the -M (make dependency) flag is used with more than
one source file is specified. This is incorrect.
Repeat-By:
Attempt to determine the make dependicies of more than one
source file:
% cc -M a.c b.c
a.c: /* WRONG */
a.o: a.c
b.c: /* WRONG */
b.o: b.c
Note the gratuitous lines intermixed with correct dependency
output.
Fix:
A context diff follows.
RCS file: RCS/setup.c,v
retrieving revision 1.1
diff -c -r1.1 setup.c
*** /tmp/,RCSt1a00609 Mon Jun 13 03:01:03 1988
--- setup.c Sun Jun 12 20:34:12 1988
***************
*** 543,549 ****
super_intt save_produce;
for (cp= infile; cp != NULL; cp= cp->next) {
! if ((source_infile_count > 1) && ((cp->suffix->in_drivers&SOURC
E_SUFFIX) == SOURCE_SUFFIX))
(void)printf("%s:\n", cp->value);
status= 0;
reset_flag(doing_mod_file);
--- 543,551 ----
super_intt save_produce;
for (cp= infile; cp != NULL; cp= cp->next) {
! if ((source_infile_count > 1) &&
! is_off(do_dependency) &&
! ((cp->suffix->in_drivers&SOURCE_SUFFIX) == SOURCE_SUFFIX))
(void)printf("%s:\n", cp->value);
status= 0;
reset_flag(doing_mod_file);
------- End of Forwarded Message
[[ If it doesn't work *as documented* it is a bug. "-M" is documented to
"generate makefile dependencies and send the result to the standard
output." That would imply to me that the results on stdout would be
suitable for inclusion in a makefile. If it is not, it is a bug. No need
to even mention 4.3---the program is inconsistent with Sun's own
documentation. --wnl ]]
------------------------------
Date: Wed, 13 Jul 88 13:01:55 BST
From: mcvax!ritd.co.uk!mr at uunet.uu.net
Subject: SunOS 4.0 warning
The old bugs are still the best! Despite replacing the installation
program "setup" with "suninstall" (which I approve of), you should be
aware that suninstall cannot cope with terminal types "vt100" or "vt220".
This crops up when selecting the terminal type (choosing "4) Other") and
being invited to select something from termcap. Nett result is that you
type in all your setup details, start installation rolling and lo and
behold, we get a Bus error. Nifty trick (feel proud of this one): tar the
"files" directory off at this point so that you can restore it next time
round; saved much retyping.
Answer from Sun: use terminal type "ansi", NOT vt100/vt220/etc. Worked
fine from then.
FYI, this was an installation of 4.0Export on a 3/280 with a 7053(xd) disk
controller and 2xFujitsu 2344 drives (nothing like diving in at the deep
end). Drives already formatted so skipped that part.
Martin Reed, Racal Imaging Systems Ltd
uucp: mr at ritd.co.uk,{mcvax!ukc!ritd,sun!sunuk!brains}!mr
Global String: +44 252 622144
Paper: 309 Fleet Road, Fleet, Hants, England, GU13 8BU
[[ I think I heard from somewhere that this is caused by a program not
allocating enough space for the termcap buffer. --wnl ]]
------------------------------
Date: 13 Jul 88 20:37:53 GMT
From: hpda!sun!megatest!djones at uunet.uu.net (Dave Jones)
Subject: malloc
In Sun-Spots Digest v6n135, Torsten Beyer of the University of Dortmund,
West Germany, described a problem with malloc() under SunOS 3.4.2. He
said that a small program of his mallocked about 10Mb, freed it, and then
mallocked 10Mb again. The result, he said, was that "ps aux" told him
that the process was using 20Mb of virtual memory.
I could not duplicate the problem. (The test program is included below.)
Perhaps he could post the little program that is giving him trouble.
The problem I have had with Sun's malloc() is that it is very very
slowwww. Much slower than the BSD version. (The BSD version keeps a
linked list of fixed size packets for each small power of two: A free list
of eight-byte packets, a free list of sixteen-byte packets, etc..) I
have written a little package that gets large bunches of fixed size
packets from malloc() and then allocates them and frees them with a linked
list. Some programs run literally hundreds of times faster using that
technique, rather than using malloc directly.
-- Dave J.
[[ And everyone laughed when I said to ignore malloc and do your own
memory management! :-) --wnl ]]
____________________
#include <stdio.h>
void pause();
main(argc, argv)
char** argv;
{
int size = atoi(argv[1]);
char* ptr;
pause("None mallocked. ");
ptr = (char*)malloc(size);
pause("One packet mallocked. " );
free(ptr);
pause("Now it is freed. " );
ptr = (char*)malloc(size);
pause("Now it is mallocked again. " );
exit(0);
}
void
pause(str)
char* str;
{
printf("%s", str);
fflush(stdout);
getchar();
}
------------------------------
Date: Thu, 14 Jul 88 14:14:52 BST
From: Dr R M Damerell (RHBNC) <damerell at nss.cs.ucl.ac.uk>
Subject: Cables for Suns
S. Marrett's query (Sun-spots v6n134) prompts me to say what has happened
at my place (Maths, RHBNC). PLEASE NOTE I am ***NOT*** telling anybody
what to do, merely what happened here. I accept no liability if you do
something similar & it goes sour on you. I'd like to thank everybody who
gave me advice, especially H.Pelling of STC, Newcastle.
We have sun 3/60s, noisy, with monochrome screens, I think they are
Phillips (yes, I have heard about these) bought about 3 months ago.
SUN engineer said they supply 40-foot cables. Both monitor and keyboard
cables give problems if you try to make them too long. I think they are
made only by SUN UK. Each cable costs 200 pounds. I thanked him, then
ordered parts from Radio Spares.
Video cable: 4-core individually screened, R.S. 367-577, 9 pin D plugs &
sockets, R.F. shields & covers. Wired thus:
1 -> 1
2 N/c
3 -> 3
4 -> 4
5 N/c
6 -> 6
7 shield 7
8 shield 8
9 N/c
This cable comes in 50 metre lengths, so before cutting it I tried a 50
metre video cable. This gave a severely degraded picture: in Suntools
(with default fonts) most of the characters were illegible. With a 60-foot
cable, I think I can see some degradation of the picture, but I'm not
absolutely sure. I ought to say I am not very good at soldering; also
maybe SUN use a better quality cable than I did.
Keyboard: Sun engineer said the keyboard gets its power through the cable,
so I used a thicker cable ( R.S. part 367-735) than recommended in the
hope that it would work more reliably. This comes in 25 metre lengths; I
saw no problem with a 25 metre cable. The original cable is sealed into
the keyboard and I didnt want to tamper with it, so I just stuck the new
cable on as an extension, with jack screws.
Keyboard CPU
(male) (female)
1 ----> 1
2 ----> 2 -------|
3 ----> 3 |
4 -------+
5 ----> 5 | (Loop 2,4,6,8,9)
6 -------+
7 ----> 7 |
8 -------+
9 -------|
10 ----> 10 ------|
11 ------+
12 ------+ (Loop 10,11,12,14,15)
13 N/c |
14 ------+
15 ------|
I hope this is helpful.
(I will be out of contact for all of August)
Mark.
------------------------------
Date: Wed, 13 Jul 88 13:51:11 PDT
From: Lawrence Hall RCR <hall at pioneer.arc.nasa.gov>
Subject: gettimeofday clock resolution
I am running some simulations of a multiprocessor under a parallel version
of Lisp on the SUN. Using gettimeofday we get 20000usec updates from the
clock. This is not sufficient for our simulation. There is a patch under
UNIX for VAXEN which allows better (close to microsecond) resolution off
the clock from the default 10000usec resolution. Is there any similar
patch for a SUN to allow the user to get better resolution off a SUN
3/XXX? If so how good can the resolution be and how can the patch/upgrade
be obtained? Thank you in advance.
--Larry Hall
NASA-Ames Research Center
MS 233-14
Moffett Field, CA. 94035
(415)-694-6453
arpa: hall at pioneer.arc.nasa.gov
csnet: hall at usf.edu
------------------------------
Date: 13 Jul 88 23:36:30 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: yp provided by Sun, DEC and who else?
Aside from SunOS and Ultrix, what other vendors supply and support yp on
their Unix boxes and how up to date is their NFS/yp compared to SunOS?
(for example, Ultrix 2.2's NFS doesn't have the NFS lock daemons that
SunOS 3.? has).
Does Mt. Xinu's MORE/bsd support yp? If so, what hardware other than
VAXes is it known to run on?
Mike Khaw
internet: mkhaw at teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Thu, 14 Jul 88 10:34:22 EDT
From: jas at proteon.com (John A. Shriver)
Subject: adjusting kerning in Sun's Transcript for troff?
I've got a Sun LaserWriter with Sun's distribution of Transcript. It
works fine with troff. However, I find that the Transcript font width
files (/usr/local/lib/lw/troff.font/*) are kerning the letters in the
Times Roman font far too tightly. They are managing to squeeze about 6
more characters on a 6.5" line than AT&T did with the C/A/T
phototypesetter. The result is a noticeable decrease in readability, that
makes text much harder to read. The only workaround I have so far is to
make the font a point size larger, which makes up somewhat on the
readability front. Has anyone found a reasonable way to get/make
Transcript troff font width files with more reasonable widths?
------------------------------
Date: Wed, 13 Jul 88 14:43:04 EDT
From: jfjr at mitre-bedford.arpa (Freedman)
Subject: thanks for the ISIS information
I was unable to get through to those who replied to my ISIS request (me
and my mailer often don't see eye to eye) so thanks people - in particular
thank you Carlton Ray Brittain at Oak Ridge
Jerry Freedman, Jr
jfjr at mitre-bedford.arpa
(617)271-4563
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list