HDTenEightyP/NetNews huggingface dataset:
From: mills@ccu.umanitoba.ca (Gary Mills)
Subject: Re: SERIOUS BUG: SunOS' YP/NIS password daemon
Organization: University of Manitoba, Winnipeg, Canada
Date: Thu, 31 Dec 1992 03:14:08 GMT

In <RATINOX.92Dec30162148@splinter.coe.northeastern.edu> Gone with the Lemming <ratinox@meceng.coe.northeastern.edu> writes:

>Specifically, if an existing password contains colons (":"), then the RPC
>calls from yppasswd to yppasswdd (on the YP/NIS server), fails when you
>attempt to change a password. 

This is fixed in the following patch:

Patch-ID# 100564-03
Keywords: C2 Jumbo rpc.yppasswdd rpc.pwdauthd
Synopsis: SunOS 4.1.2, 4.1.3: C2 Jumbo patch
Date: 30/Sept/92

SunOS release: 4.1.2, 4.1.3

Unbundled Product:

Unbundled Release:

Topic: C2 Jumbo patch


>A bug report has been sent to Sun, and should show up in the next bug
>report book.

   bug 1039587:
   rpc.yppasswdd does not accept ":" characters
   as a valid passwd character when changing an existent passwd entry.



-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.sys.sun.misc
Subject: Re: Etherfind details
Date: 22 Dec 1992 21:08:04 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Dec21.233654.12476@pacdata.uucp> jimh@pacdata.com (Jim Harkins) writes:
>Will etherfind display packets that are an invalid packet when the host option
>is used?  I'm writing a tool that writes to the network, and I'm talking 
>directly to the network via a pc.  It's ethernet address is aa:55:aa:55:aa:55,
>and I transmit a 1200 byte packet consisting of sequential bytes (00,01,02, ...,
>fe, ff, 00, 01, etc).  The first 12 bytes are my source and destination.
>I've got a Sun3 on my test network and if I use 'etherfind greater 1000' it
>sees the packet, but if I use 'etherfind host jimstest' it doesn't see the
>packets.   If I use my real sun to ping jimstest then etherfind sees the
>packets.

The "host" option in etherfind looks at the IP addresses, not the ethernet
addresses.  So if you're sending a raw ethernet packet rather than an IP
packet, it's not going to match that specification.

>If etherfind won't do what I want does anyone have any suggestions?  Spending
>money is out :-(, but I've got both a Sun 3 and a PC I can run software on.

Get tcpdump from an FTP server.  It has "ether src" and "ether dst" options
that let you filter based on ethernet addresses.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.sys.sun.misc:5960 comp.sys.sun.apps:2846 comp.windows.news:805 comp.windows.open-look:4893
From: gohel@zeus.csee.usf.edu (Himanshu Gohel)
Newsgroups: comp.sys.sun.misc,comp.sys.sun.apps,comp.windows.news,comp.windows.open-look
Subject: NeWSprint2.0 / PreLimn questions
Keywords: nptool ; manual feed ;
Date: 16 Dec 92 15:42:24 GMT
Followup-To: poster
Organization: U of South Florida, Department of Computer Science and Engineering

A few questions about Newsprint 2.0/PreLimn:

1. I can't get "nptool" to start up with a printer of choice.  It takes
   the first entry in the printcap file, even if I say:

   nptool -Psp  (where sp is our SPARCprinter)

2. I can't seem to get the "Manual Feed" option (from nptool) to 
   *always* work.  Sometimes it will work and take the sheet that I put 
   in, other times the "C5" message doesn't flash and it will use paper 
   from the tray.

   On the other hand if I use "pl file.ps :manualfeed", that will
   always work!

3. Sometimes I'd like to print a PostScript file double-sided.
   Is there any program/options that will first print the front-sides
   (odd pages) and then wait for those sheets to be put back in the tray?
   Such a program would be very useful, not to mention paper saved.

4. The fonts in the "small_openwin" directory are/should be in the
   OpenWin3 installation on our machines.  Has anyone tried to just
   put a link to the $OPENWINHOME/... directories to save disk space?

Answers much appreciated.

Himanshu

--
Himanshu Gohel, Gohel@csee.usf.edu
U of South Florida, Tampa, FL 33620-3140
Newsgroups: comp.sys.sun.misc
From: kbibb@maui.qualcomm.com (Ken Bibb)
Subject: Re: Is Sun losing touch with its customers?
Organization: Qualcomm, Inc., San Diego, CA
Date: Sun, 27 Dec 1992 20:14:14 GMT

In <1992Dec27.031931.10598@eskimo.com> nanook@eskimo.com (Robert Dinse) writes:

>In article <1992Dec22.080719.16062@eskimo.com>, johnn@eskimo.com (John Navitsky) writes:
>> In article <BzI0Ls.GGo@shakti.ncst.ernet.in> riyer@shakti.ncst.ernet.in (Rajappa Iyer) writes:
>> >
>> >Isn't anybody at Sun doing their homework right?
>> 
>> I really suspect that Sun is trying to set themselves (and us) for the 
>> long haul.  Unfortunatly this means (among other things) some pain, as
>> in the move to SV4 derived Solaris.  It would seem to me that they want
>> to get it over with.  

>     Nah, don't see any big advantages to System-V4r for the customer for
>either the short or long haul.  I do see some big advantages to AT&T.

First, it's SVr4 not SV4r.  It means: system five release four.

>[deleted]

>     So they get together, they say to Sun, (mind you this IS speculation
>and nothing more), they say, "Gosh, we can help you with your short-term
>cash difficulties, if you'll just agree to make the next major release of
>Sun/OS system-V4r based so that we can continue collecting outrageous
>royalties from your customer base.

Main problem with this theory is that Sun and AT&T helped write SVr4
*together* (as I recall, there was a third vendor who was also involved
with the SVr4 development).

>     The position I've taken, is to condition any purchases of Sun
>equipment upon it being able to run 4.1.x.  I write this right into the
>purchase order.  So far, 4.1.x has worked on all of the boxes we've
>purchased (mostly 4.1.3), though I'm told it won't run on mutli-processor
>SS10's.

And it won't run on the LX, SPARCclassic, or SPARCcenter 2000.  

-- 
Ken Bibb                "he heard the snow falling faintly through the
kbibb@qualcomm.com	 universe and faintly falling, like the descent of
jester@crash.cts.com     their last end, upon all the living and the dead."
				--"The Dead", James Joyce
From: Gone with the Lemming <ratinox@meceng.coe.northeastern.edu>
Subject: SERIOUS BUG: SunOS' YP/NIS password daemon
X-Posting-Software: GNUS 3.14.1 [ NNTP-based News Reader for GNU Emacs ]
X-Signature-Virus-Protection: Version 1.51
X-Get-A-Clue: Have two, they're small.
Organization: 3WA, Boston Office. Or Nu Meta Chi. Take your pick.
Date: Wed, 30 Dec 1992 21:22:48 GMT

We here at Northeastern have discovered a serious bug in SunOS' yppasswdd
daemon under SunOS 4.1.2 and up, and probably earlier versions.

Specifically, if an existing password contains colons (":"), then the RPC
calls from yppasswd to yppasswdd (on the YP/NIS server), fails when you
attempt to change a password. Here's the error reported (tanelorn is one of
our local YP servers and home to the YP password file, dworkin is a YP
client)

[dworkin] ~> yppasswd
Changing NIS password for ratinox on tanelorn.ccs.northeastern.edu.
Old password:
New password:
Retype new password:
RPC: Server can't decode arguments

yppasswd couldn't change entry (rpc call failed)
[dworkin] ~>

A bug report has been sent to Sun, and should show up in the next bug
report book.

This only shows up under YP; running "passwd" locally works fine. It also
works fine if you change an existing password without colons to one with
colons. The problem only occours if the "old" password contains colons.

Diagnosis:

Without having source code to check over, it seems that yppasswd is feeding
an unencrypted "old" password to the yppasswdd daemon via RPC. Then
yppasswdd chokes because colons are the password file delimiters. Since
yppasswdd doesn't fail when setting a password with colons in them, the new
passwords are being transmitted encrypted.

--Rat                               PGP Public Key Block available upon request
||||| | | | |  |  |  |   |   |    |    |    |   |   |  |  |  |  | | | | | |||||
Northeastern's Stainless Steel Rat          ratinox@meceng.coe.northeastern.edu
Remember, no matter where you go, there you are.              --Buckaroo Banzai
From: daryl@piano.adept.ih.att.com (55000-Daryl Monge(ih1439)392)
Newsgroups: comp.sys.sun.misc
Subject: Customers and Vendors (Was sun and customers)
Date: 23 Dec 92 18:50:48 GMT
	<1992Dec22.203852.8733@news.arc.nasa.gov> <16052@auspex-gw.auspex.com>
Organization: 5ESS(TM)-US Project Management
In-reply-to: guy@Auspex.COM's message of 23 Dec 92 04:08:32 GMT


   Yup.  For example, 68K-based HP machines may have a longer life than
   68K-based Sun machines did, but I suspect HP likes HP-PA more than the
   68K architecture, and that the most interesting HP-UX machines will, in
   the future, be PA machines rather than 68K machines.

It should not really matter what HP, Sun, or Dec likes.  What really matters is
what the customer wants/needs.  Any customers that do not want to make a 
complete architecture switch from 68K machines were screwed by sun and not
by HP.  Not everyone needs a 50MIPS workstation.  68040 machines are quite
capable for many customers.  It really boils down to $$$$.  And cost is more than
the price of the next box that comes out.

I would bet that long ago if Sun had licensed a third party to produce new SUN3
architecture machines, there would still be SUN3 machines.  But of course that
is totally counter to their product strategy.

Daryl Monge			AT&T Bell Labs
EMAIL: daryl@adept.att.com	VOICE: 708-713-4696
GEnie: D.MONGE
PAPER: Rm 2A-448   P.O. Box 3050, Naperville, Il 60566
Newsgroups: comp.sys.sun.misc
From: singer@ll.mit.edu (Matthew R. Singer)
Subject: PC disks
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Date: Tue, 22 Dec 92 19:45:19 GMT


--

I know that you can read ms-dos floopy disks on a Sparcstation.  Does anyone
sell a driver that would allow you to read a SCSI hard disk written on a PC?

I want to build a custom data recorder that would write to SCSI disk's but
I'd like to then plug the disk into a Sparc 10 for data analysis...




-----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
-----------------------------------------------------------------------------
Newsgroups: comp.sys.sun.misc
From: "David Herron" <david@twg.com>
Subject: Re: Is Sun losing touch with its customers?
Sensitivity: Personal
Encoding:  20 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Wed, 23 Dec 1992 00:57:33 GMT

     * HP has 4 architectures: PA-RISC, 3000, 68xxx, x86
     * DEC has 4 architectures: Alpha, VAX, MIPS, x86
     * IBM has ? architectures: RS/6000, ...

All the water behind one balloon (or is that wood behind one arrow.. I forget).

	* Sun has 1 architecture: SPARC

(or is it 2: SPARC, x86)

I don't fault them for jumping from Motorola chips.  If Motorola couldn't
stand the heat, so Sun shoved 'em out of the kitchen.  (Heat in this case
being a performance gain curve where system performance is supposed to
double every 1.5 years).

I don't fault them for switching OS bases.  SysV is much closer to POSIX
anway and having API compatibility is an EXTREMELY GOOD thing.  Makes our
skills MUCH more widely applicable.

Why're y'all scared to learn a few new commands anyway??

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- "Unix is a great idea being sold by companies who couldn't sell
<- fast food in Somalia." - bill davidsen <davidsen@ariel.crd.GE.COM>
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Is Sun losing touch with its customers?
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 29 Dec 92 05:51:57 GMT

In <1992Dec28.005345.28237@siemens.com> aad@siemens.com (Anthony Datri) writes:

| >Depends on what the customer is doing. If they are really into (trying
| >to) standardizing their environment, they will appreciate a common base.
| 
| Is any other non-peecee vendor doing svr4, though?  Many are going the OSF
| route, so svr4 instead of SunOS/BSD isn't different.  Those of use who may
| have to spend time back-porting BSD stuff to svr4 aren't as appreciative.

Yes, Siemens, among others!  Surely given your email address you
are aware of that!?

Also, SGI is going to SVR4 compatibility (which I regard as a mistake,
but I don't make the decisions; at least SVR4 is *far* better than OSF,
at least as of last year when I last worked with the OSF code, in terms
of code quality and performance).  For better or worse, many vendors seem
to be rushing towards SVR4 compatibility, in terms of interfaces, SVID,
and ABIs, if not necessarily code base.

--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.sys.sun.misc
Subject: Re: Sun's ANSI C
Date: 31 Dec 92 19:59:33 GMT
Organization: Auspex Systems, Santa Clara

>Does anyone know if the unbundled compiler being sold with Solaris 2.x is
>fully ANSI-compliant? 

Not unless it comes with libraries. :-)

The better question to ask may be whether the combination of the
unbundled compiler sold by Sun *for* Solaris 2.x (it's not sold *with*
Solaris 2.x, which is why it's called "unbundled", and why some people
are ticked off at Sun), and the libraries and include files that come
*with* Solaris 2.x (you have to install some particular package, whose
name I don't remember, from the Solaris 2.x distribution, to get them),
is fully ANSI-compliant.

I think the answer is "that combination is supposed to be
ANSI-compliant, and probably is, modulo bugs and differing
interpretations of the standard".
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.sys.sun.misc
Subject: Re: Dumb question about at/batch
Date: 2 Jan 93 18:15:13 GMT
Organization: Auspex Systems, Santa Clara

>    It's the i-number of the file in "/usr/spool/cron/atjobs" containing the
>    commands to run.
>
>Are you sure?

Yes, I am absolutely certain; I've read the code - heck, I *wrote* that
part of the code.

>Then I'm very surprised that on my machines those "inode
>numbers" match exactly the time (GMT) in seconds when the job is to be
>started.
>
>What a coincidence :-)

What a *mysterious* coincidence; you must have installed a modified
version of "at"/"cron", then, because it sure as heck doesn't happen on
*my* workstation, which is running vanilla 4.1.1:

	bootme$ at 10:15
	at> <EOT>
	job 280520 at Sat Jan  2 10:15:00 1993
Newsgroups: comp.sys.sun.misc
From: Dean.Roth <Dean.Roth@mixcom.mixcom.com>
Subject: Sun X.25 and file transfer problems
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Distribution: usa
Date: Tue, 29 Dec 1992 18:44:47 GMT


Anyone using Sun's X.25/X.29 software and performing file transfers
using zmodem or xmodem?

System: Sparc Station
        OS 4.1.2
        Sun's X.25 and X.29 software

        zmodem (sz/rz) software

File transfers will not work using this combination of software.
Z and X modem fail. I've checked tty settings (8 bits, no parity).

The same zmodem software works fine with X.25/X.29 software 
on a 3B2.

Ideas?  Thank you.

Dean
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.sys.sun.misc
Subject: Re: Sun's ANSI C
Date: 31 Dec 92 20:01:09 GMT
Organization: Auspex Systems, Santa Clara

>The one that really got me was sprintf.
>In my application, I need to format a string via sprintf and know how long the
>resulting string is.  ANSI requires sprintf to return an integer representing
>the length of the formatted string, but in Sun's "ANSI" C, sprintf still 
>returns a char*.

Can "acc" be coaxed to compile stuff in the SV environment?  If so, try
that - the SV environment version of "sprintf()" returns the length of
the formatted string.

Does "acc" come with its own libraries?  If so, does it link with them
by default, or do you have to ask it to do so?  If you have to ask it to
do so, try asking it to do so.
From: etxmesa@eos.ericsson.se (Michael Salmon)
Newsgroups: comp.sys.sun.apps
Subject: Re: Dumping OW and running X11R5(Was: Speed
Date: 23 Dec 92 08:49:37 GMT
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Organization: Ericsson Telecom AB

In article <1992Dec21.125413.7374@cbnewsh.cb.att.com>
wolf@merlin.mt.att.com (Thomas Wolf) writes:
|> In article 92Dec19221053@orangutan.cv.nrao.edu
|> pmurphy@nrao.edu (Pat Murphy) writes:
|> "> ""TP" == Thad Phetteplace x4461 <tdphette@mke.ab.com> writes:
|> "> "
|> "> "TP> I think all you need to do is copy your openwindows fonts into
|> "> "TP> your X11R5 font directory and rebuild your font database.  Check
|> "> "TP> out the man pages on xlsfonts and bldfamily.
|> "> "
|> "> "You can alternately add the OW fonts to your X server's font path with
|> "> "the "xset fp+" and related commands.  I run an X11R5 server, the tvtwm
|> "> "window manager, and with this command in the startup scripts all
|> "> "non-news OW applications seem to be happy.
|> "> "
|> 
|> OW used different font files than X11R4 (so the above wouldn't work).  Can the
|> X11R5 server read OW font files?

If I understand the situation correctly xnews uses postscript fonts
which are completely incompatable with X11 fonts however OW has
convertfont which can generate BDF format font files which can later be
converted to X11 server files. I have found that some editting is
required to achieve a correct file as the reported size is wrong.
Otherwise I have generated several fonts that I use regularly.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm
Newsgroups: comp.sys.sun.apps
From: revtek@world.std.com (Jacques A Vanschouwen)
Subject: PowerDrive now available for Sun workstations
Organization: The World Public Access UNIX, Brookline, MA
Distribution: all
Date: Mon, 4 Jan 1993 00:19:05 GMT


Revolution Technologies First To Unveil Transparent Low Cost
Disk Compression Software For SPARCr Workstation Users.

NATICK, Mass. -- January 4, 1993 -- Revolution Technologies (tm) today
introduced PowerDriveTM, a software product designed to transparently
increase the file storage capacity of SPARC workstations and servers.
With PowerDrive, users can store more files and applications at much
lower cost than purchasing additional disk drives.

+ DOUBLES DISK DRIVE STORAGE CAPACITY 

The PowerDrive product is intended for users who want to store additional
applications and files on their workstations than would typically fit.
With PowerDrive, files are compressed to 50% of their original size on
average. This significant reduction virtually doubles the drive's storage
capacity.

+ EASY INSTALLATION IN MINUTES

The PowerDrive software installs in minutes and allows the user to
immediately take advantage of the additional disk space. During
PowerDrive installation, existing files on the system are compressed
into the PowerDrive format -- making more room to store new files.
When a file bearing the PowerDrive format is accessed, it is
transparently decompressed for use by the user.  The PowerDrive
software is fully configurable and works easily with all file types
including text files, object files, and executables.

+ IMMEDIATE AVAILABILITY

PowerDrive is available now for the Solaris 1.0 (SunOS 4.1.x) operating
system.  A version for Solaris 2.x will be available in March, 1993.
Revolution Technologies is offering a special introductory price of $99
until March 31, 1993. PowerDrive is available via anonymous FTP at
world.std.COM (192.74.137.5) in the directory pub/revtek.  Download
files powerdrive.tar and powerdrive.README.

PowerDrive can also be ordered by calling Revolution Technologies at
(508) 650-1490 or by sending a FAX request to (508) 655-8860.

Users can try out PowerDrive at no cost for 30 days by obtaining a demo
license from Revolution Technologies.

Revolution Technologies and PowerDrive are trademarks of Revolution
Technologies.  SPARC is a registered trademark of SPARC International, Inc.
From: scott@freedm.UUCP (Scott Stratmoen)
Newsgroups: comp.sys.sun.apps
Subject: Re: WP5.1 SLOW in OpenWindows 3.0 ? Is it us or a general problem
Date: 31 Dec 92 02:49:14 GMT
Distribution: na
Organization: Northrop Corporation ESDRM

In article <1992Dec29.203238.16650@news.columbia.edu> willem@sparc-1.law.columbia.edu (System Admin) writes:
>
>One of the best things it has going for it is the file transfer accross
>diverse platforms!  There is no other wordprocessor out there which works the
>same under DOS, Mac, Unix, VMS or IBM.  File formats are the same etc!

Too bad that VMS WP files are *NOT* portable to other platforms.


-- 
Scott Stratmoen      ..!ast!freedm!scott   scott@freedm.dsd.northrop.com
Newsgroups: comp.sys.sun.apps
From: fgreco@cfdev1026.shearson.com (Frank Greco)
Subject: Re: X/Wans
Organization: Lehman Brothers
Date: Thu, 31 Dec 1992 16:52:48 GMT

In article <1992Dec21.030407.18901@ukw.uucp> lupe@ukw.uucp (Lupe Christoph) writes:
>fgreco@shearson.com (Frank Greco) writes:
>>>Also, does the X11/NeWS server implement backing store ? and would you expect
>>>backing store to improve the situation ?
>
>>	Yes it would allay the slowdown somewhat; but I really believe its
>>	an inherent problem in X's design that perhaps R6 might address more
>>	properly.
>
>I doubt that. Many features in X require an exchange between the client
>and the server. NeWS is much better for this kind of work, being able to
>run more parts of the application on the server. If it is at all possible,
>try converting the application to TNT; or just try one of the NeWS demos
>like jed on your link. This will tell you if the delays *are* the problem.

	I agree 10000000%.  However Sun has decided to pull NeWS/TNT out
	of the server for the next major release of OpenWindows, so I don't
	believe anyone is porting to TNT right now.

	Frank G.
--
+-On Assignment at: Lehman Brothers-+-Office: Mercury Technologies, Inc.-+
| World Financial Center, 11th Floor| PO Box 529                         |
| New York City, NY 10285 Desk: 1515| Fanwood, NJ 07023                  |
| email: fgreco@shearson.com        | email: fgreco@mercury.com          |