HDTenEightyP/NetNews huggingface dataset:
From: glenn@cs.utexas.edu (Glenn G. Lai)
Newsgroups: comp.unix.sysv386
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Date: 6 Apr 1992 11:49:55 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: syrian.cs.utexas.edu

In article <ktvo25INN7il@neuro.usc.edu>, merlin@neuro.usc.edu (merlin) writes:

> Please note this is in no way a challenge to Glen's approach to distributing
> his software.  But, I am curious about the use of copyright law to "protect"
> the free distribution of software to certain classes of user while retaining
> the right to resell the same software to other classes of user (or vendors).

I don't ask for royalties, at least not in the usual sense, from vendors.  All
I want is a chance to look at the result of what they've done with my code--and
only if I choose to.  This is different from DJ Delorie's stand on DJGPP, a DOS
version of GCC/CPP, for which he asks for a 5% royalty for commercial purposes
and none if they're non-commercial.

> Glenn's product is clearly not an unpublished work.  It is not a privileged
> communication to others.  Clearly the price for this published work has been

P. J. Plauger has published his C library in the book _The Standard C Library_
and has stated that "I [Plauger] retain all rights."

> set at $0.00 per copy.  If it is given away for free to even one user -- and
> that one user then decides to make copies for friends -- and at some point a
> friend decides to use the software for commercial purposes -- then where is
> the copyright law applied?  The use of copyright law to control circulation
> of software has always seemed problematic to me.  Is this usage appropriate?

Maybe it is, maybe it isn't.  If a person chooses to go against my wish, I'll
NOT do anything about it, but I hope that he/she will at least show the courtesy
of respecting it.


Glenn
glenn@cs.utexas.edu
From: bwg@cypress.com (Butch Griffin)
Newsgroups: comp.unix.sysv386
Subject: Re: bootlegging hurts Unix
Date: 8 Apr 92 18:53:29 GMT
Reply-To: bwg@cypress.com
Organization: Cypress Semiconductor Southeast Design Center

I agree that stealing is stealing no matter what context it is taken in.  One problem
with **IX based platforms and SUNs specifically is that all of the software is tied to
a hostid to prevent theft.  That means that I have no flexibility as an adminstrator 
for transfering machines from one group to another unless I wish to transfer the software
as well.  

To move software from one machine to another there is usually a fee of some type.  For our 
CAD software that is used to design our parts, the tranfer fee is more expensive than most 
PC software and this is a transfer from one machine to another in the same class (e.g. from
a Sparc II to another Sparc II).

---
Jack (Butch) Griffin
Cypress Semiconductor
Southeast Design Center
Starkville, MS (Yes, that's right Mississippi!)
bwg@cypress.com        (601-324-4603)


Newsgroups: comp.unix.sysv386
From: bill@unixland.natick.ma.us (Bill Heiser)
Subject: RE: C news multi-FS patches posted to alt.sources
Organization: Unixland Public Access Unix  (508) 655-3848
Date: Wed, 8 Apr 1992 23:01:08 GMT

Thanks to John Levine for posting the multi-filesystem Cnews patches 
for SVR3 systems with the 65K inode limit.  I am not using his patches,
but someone elses (sorry, the name escapes me right now, I will find it
if you are intersted).

Anyway, my point to this message was to mention my experiences with 
multi-filesystem news on ESIX 3.2.  I first tried the patches by
branching off the rec hierarchy onto a separate filesystem.  That worked
fine for rec, but still left the main news partition way short on inodes.
Recently I repartitioned, using four partitions:  alt, rec, comp,
and everything else in one partition.  I have quickly discovered that
while I have LoTS of inodes free (over 160K inodes), I have problems
with actual disk space in several of the partitions.

In short, this allocation is an exercise in experimentation to see
what kind of partitioning is best for you.  Based on my experiments
(with about 2,000 groups), it looks like 3 partitions, maybe alt/rec,
comp, and everything else, sized proportionally, might just about do it.

Hope this helps.

Bill

-- 
bill@unixland.natick.ma.us   ...!uunet!{think,world}!unixland!bill
Public Access UNIX / USENET / E-MAIL Accounts are available! (508) 655-3848
5 lines  -  Located in Natick, MA   USA    Supporting V.32/PEP/V.42bis, etc.
Newsgroups: comp.unix.sysv386
From: kherron@ms.uky.edu (Kenneth Herron)
Subject: Re: svr4 asy, uucico and ttymon hints (was: Sys V R4, Async 
    problems...)
    <1992Apr6.124517.18988@werple.pub.uu.oz.au> 
    <JHPB.92Apr7230655@sarto.budd-lake.nj.us>
Followup-To: comp.dcom.modems
Distribution: na
Date: Wed, 8 Apr 1992 13:21:14 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
X-Bytes: 

>...ttymon will fork on just plain data bits without any CD at all.
>This is extremely annoying, because my modem sends RING whenever
>someone calls.  This causes ttymon to lock up the port waiting for CD,
>which never comes, because it was a voice call, not a modem call that
>occurred.
>
>my only recourse is to turn off command echo completely, to get rid of
>the incoming RING.
>
>Since leaving command echo off causes problems for outgoing calls (no
>way to figure out exactly when the modem connects to the remote?),
>though, what I need to do is turn command echo on to make the call,
>then turn it off when the session is done.  Since BNU doesn't support
>any means of resetting the modem to a know state when a call is
>complete, I will have to hack something up.

[Followups are directed to comp.dcom.modems, where they handle
questions like this regularly]

Your modem should have two features; if it doesn't then this won't
work:

	1)	A section of nonvolatile (battery-backed) memory
		used to retain modem settings
	2)	A command to have the modem hang up & reset to the
		battery-backed settings every time DTR drops.  This
		command is usually AT&D3 on Hayes-compatibles.

Set up your modem to work with incoming calls.  This means NO
command echo, NO result codes, and NO CONNECT messages.  Set the
modem to hang up & reset when DTR drops.  Save these settings in the
nonvolatile memory (usually with AT&W).

For outgoing calls, make the first command string sent to the modem 
be something that turns result codes back on.  I typically put a
factory-reset command in as the first string, then go on to change
every setting that needs changing.  It makes for longer chat strings,
but the modem isn't off-hook yet so so what?

Eventually whatever is dialing the modem will finish/give up/whatever
and close the serial port, at which time DTR drops and the modem reloads
the stealth settings from its RAM.

[As long as you're programming the modem, make sure to set it to
only raise DCD when connected to another modem.  This is necessary
for the system to detect people who hang up without logging off,
as well as outgoing calls that are disconnect unexpectedly.]
-- 
Kenneth Herron                                       kherron@ms.uky.edu
University of Kentucky                                  +1 606 257 2975
Department of Mathematics
                                              Flame early, flame often.
Newsgroups: comp.unix.sysv386
From: rfarris@rfengr.com (Rick Farris)
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Organization: RF Engineering, Del Mar, California
Date: Wed, 08 Apr 92 01:05:22 GMT

In article <RAYMOND.92Apr6115808@cobra.es.ele.tue.nl>, raymond@es.ele.tue.nl (Raymond Nijssen) writes:

> The performance depends *significantly* on the throughput of the IO bus.
> A faster processor for X speedup is a waste of money without fast IObus.

Au contraire!  If that faster processor happens to be a 'co'
processor, then the benefits are staggering.  I/O bandwidth
disappears from the equation, because the processor says
things like "go to point (7,3) and draw a circle of radius
15, and then fill it with green," instead of doing all the
calculations and then moving each pixel change across the
bus.

I *really* see the difference in X when starting a new
window to reply to a message.  With a coprocessor board (#9
GXi), the window and the text appear simultaneously.  With
VGA, first the window appears, then it gets decorated and
then, finally, the text appears.

--
Rick Farris  RF Engineering POB M Del Mar, CA 92014  voice (619) 259-6793
rfarris@rfengr.com     ...!ucsd!serene!rfarris      serenity bbs 259-7757

Newsgroups: comp.unix.sysv386
From: mikebe@i88.isc.com (Michael G. Beirne)
Subject: Re: Installing TCP/IP on ISC3.0.
Keywords: ISC TCP/IP v.3.0
Organization: Interactive Systems Corporation, Naperville,IL
Date: Mon, 13 Apr 1992 17:28:57 GMT

In article <1992Apr11.223836.40897@yuma.acns.colostate.edu> ogden@lamar.ColoState.EDU (Fred Ogden) writes:
>Hello fellow netters,
>
>I recieved my upgrade to ISC ver. 3.0 a couple of weeks ago, and I've been
>able to get everything up but the TCP/IP.  I've installed it according to 
>the book.  When I boot the machine, I get a message:
>
>I'm starting from scratch on a 486/33 ISA with a WD8003e card set at IRQ 2.
								      ^^^^^
>If anyone has encountered this problem, please tell me how to fix it.  

You mean IRQ 9 don't you?
IRQ 2 is the cascade from the second Interrupt Controller chip(Intel 8259)
so that you can have 15 interrupts instead of just 8.
The board should be jumpered to use IRQ 2 and the software should be set
to use IRQ 9.

>Thanks 1E+06,
>***************************************************************************
>Fred L. Ogden
>Engineering Research Center
>Colorado State University
>Fort Collins, CO 80523
>ogden@lamar.colostate.edu
>***************************************************************************

Mike Beirne
mikebe@i88.isc.com or beirne@limerick.chi.il.us
-- 
mikebe@i88.isc.com or beirne@limerick.chi.il.us
Newsgroups: comp.unix.sysv386
From: pbh@jake.cc.wayne.edu (Patrick Haggood)
Subject: Where can I purchase Interactive?
Originator: pbh@jake
Organization: Wayne State University, Detroit
Distribution: usa
Date: Wed, 8 Apr 1992 14:28:28 GMT

I realize that mergers are not known for their smoothness, but I'm 
having some difficulty in finding a company that can sell Interactive
Unix for the 486.  Sunsoft in California recommened this company in 
Michigan, which recommended *another* company in Michigan, which 
said they really couldn't help me.  Is there a mail order place I can 
get this software?  Any place that also offer university discounts would
be very appreciated.  Interactive is looking very attractive to me, 
especially with the upgrade offer to Solaris 2.0 for Intel on purchases
prior until June 15th (said one company, Sunsoft said June 30.  *sigh* 
Mergermania, our legacy from those wild and wooly 80s).  

Thanks for your info.
-- 
"Again, the kingdom of heaven is like unto a net," | DoD #1966	
	Matthew 13:47                              | 81 Honda CB400T Hawk
From: carroll@ds12.scri.fsu.edu (Troy Carroll)
Newsgroups: comp.unix.sysv386
Subject: ESIX 5.3.2.D and modem status register
Summary: How do I get at the modem status bits?
Keywords: msr modem ESIX
Date: 10 Apr 92 06:15:02 GMT
Reply-To: carroll@ds12.scri.fsu.edu (Troy Carroll)
Organization: SCRI, Florida State University

Could one of the ESIX gurus out there help me with a small problem?
I'm trying to read the Modem Status Register (MSR) off of one of my
serial ports (looking for DCD status).  I'm almost certain it's just
a matter of the right ioctl() call, but the manuals have *NOTHING*
to say on the matter.  However, they do throw you a few bones in
/usr/include/sys/asy.h and /usr/include/sys/easy.h just to show you
all that COULD be done if only you knew the ioctl calls!  Annoying...

Any help would be greatly appreciated.

Thanks,
  - Troy
From: merlin@neuro.usc.edu (merlin)
Newsgroups: comp.unix.sysv386
Subject: Re: Sugestions on a good/fast X11R* video card
Date: 12 Apr 1992 04:46:38 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: neuro.usc.edu

In article <1992Apr12.071427.13572@thunder.mcrcim.mcgill.edu> bruno@lightning.McRCIM.McGill.EDU (Bruno Hall) writes:
>In article <HCOBB.92Apr11135352@fly1.berkeley.edu> hcobb@fly1.berkeley.edu (Henry J. Cobb) writes:
>>
>>	Try the Ati 8514a along with a cheap VGA card.  Text is very fast
>>with Dell's driver.
>
>OK, but you need a monitor which can handle 8514/A output, too.

No Problemo!!  Try the ATI Graphics Vantage (50 % slower version of
the ATI 8514 + ULTRA) -- software sees it as interlaced -- monitor
sees it as noninterlaced with reasonable clock rates.  Works find
with my SONY 1304 and also with a couple of cheap CTX NI monitors.

I don't think there should be any compatibility problems on 8514/a.

Newsgroups: comp.unix.sysv386
From: bei@dogface.austin.tx.us (Bob Izenberg)
Subject: Experience with Xtree for *nix wanted
Organization: The Fortress of Ultimate Dorkiness
Distribution: na
Date: Sun, 12 Apr 1992 09:38:12 GMT
Followup-To: poster

	The subject tells all...  If you've used Xtree for Unix, please write
with your opinions and experience.  Please reply by email, and I'll summarize.
Thanks!

Bob
-- 
 ==============================================================================
 DOMAIN-WISE: bei@dogface.austin.tx.us  BANG-WISE: ...cs.utexas.edu!dogface!bei
 ==============================================================================
From: Scott Weikart <scott@igc.org>
Newsgroups: comp.unix.sysv386
Date: 07 Apr 92 20:48 PDT
Subject: Re: low-level SCSI formatter for unix.
Nf-ID: #R:1992Mar29.203837.2107@skynet.uuc:-1871386515:cdp:1372100012:000:1219
Nf-From: cdp.UUCP!scott    Apr  7 20:48:00 1992


> Scott's method here is flat-out dangerous.  One tape error will leave you
> with a very challenging multi-megabyte jigsaw-puzzle of a file system.

You're right, my method is dangerous.  That's why I put the caveat
at the top.  I probably should have PUT IT IN ALL CAPS.  And, I
should have include the following two paragraphs:

   If you're gong to try to use my method, you'd probably want to
   make more than one dd tape, just in case a tape is bad.  You should
   *definitely* make multiple tapes if you ever have trouble reading
   tapes.

   You should have a normal tar or cpio backup to fall back on, in case
   your dd tapes produce problems.

You're right, compression is dangerous, since a bad spot on a
non-compressed tape can probably be handled with the conv=noerror
option to dd (I assume that conv=noerror will try to produce a
block of zeroes for each bad block on the tape; if conv=noerror is
liable to produce the wrong number of blocks, then a compressed
tape is no more dangerous than an uncompressed tape ... i.e. a
read error will kill you).

Scott Weikart			Community Data Processing (CdP): 415-322-9069
Internet: scott@igc.org		Bitnet: scott%igc.org@stanford
UUCP Mail Net: uunet!cdp!scott

Newsgroups: comp.unix.sysv386,comp.unix.bsd,comp.os.mach,comp.unix.wizards,alt.folklore.computers
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: SVr4 and clone hardware buyer's FAQ
Organization: Kithrup Enterprises, Ltd.
Date: Fri, 10 Apr 1992 08:36:13 GMT

In article <1992Apr8.190957.3875@sun44.synercom.hounix.org> mattair@sun44.synercom.hounix.org (Charles Mattair) writes:
>One thing that this thread is
>doing is calling it SCO 3.2 version 4.  WRONG...  it is SCO 3.2 release 4.
>subtle difference.  

Right.  Are you really this stupid?

Try reading some *SCO* advertisements and documentation.  It is *always*
referred to as '3.2v4' or some variation -- just as the previous released
version was "3.2v2."

	kithrup 1> uname -X
	System = Kithrup
	Node = Kithrup
	Release = 3.2v2.0
	KernelID = 90/06/10
	Machine = i80386
	BusType = AT
	Serial = sco000000
	Users = unlim
	OEM# = 0
	Origin# = 1
	NumCPU = 1

Looks like "SCO UNIX 3.2 Version 2.0" to me.

From the messages file (where boot-time messages are kept):

Wed Sep 4 12:08:27

		     UNIX is a registered trademark of AT&T
		       Portions Copyright 1976-1989 AT&T
		Portions Copyright 1980-89 Microsoft Corporation
	    Portions Copyright 1983-90 The Santa Cruz Operation, Inc
		   Portions Copyright 1988-90 SecureWare, Inc
			      All rights reserved

		SCO System V/386 Release 3.2v2.0 Operating System

Gosh.  Once again, it looks like it's "version," not release.

>Quoting from an official DEC publication:
>     SCO UNIX System V/386 V3.2 Release 4       (on cover)
>     SCO UNIX System V/386 V3.2 Release 4       (top of page 7)
>     RELEASE 4 [in bold]                        (top of page 8)
>     SCO UNIX System V/386 V3.2 Release 4       (twice on page 9)
>
>Toward the middle of page 7, we find
>     SCO UNIX System V/386 is a fully licensed version of UNIX Software
>     Laboratories, Inc.'s UNIX System V Release 3.2.

DEC is also wrong, and I would suggest calling them and lying.  *All* SCO
literature refers to it as "version," not "release."  There's a good reason
for that.

-- 
Sean Eric Fagan  | "One form to rule them all, one form to find them, one
sef@kithrup.COM  |  form to bring them all and in the darkness rewrite the
-----------------+  hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.unix.sysv386,comp.windows.x
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.unix.sysv386
Subject: Infamous System V inode bug explained
Date: 11 Apr 92 22:18:09 GMT
Organization: SDRC, Cincinnati

You asked for it....  Here's the explaination of the dreaded System V
inode bug and the test to see if your system has it:

Replied: Thu, 03 Mar 88 02:04:40 EST
Replied: sharkey!mailrus!rutgers!ksuvax1.cis.ksu.edu!scott (Scott Hammond)
Forwarded: Thu, 03 Mar 88 02:02:17 EST
Forwarded: Jeff Lewis <pur-ee!lewie>
Return-Path: uucp 
>From mailrus!rutgers!ksuvax1.cis.ksu.edu!/dev/null  Wed Mar  1 12:17:45 1989 remote from sharkey
Received: by mailgw.cc.umich.edu (5.59/1.0)
	id AA10725; Wed, 1 Mar 89 12:17:45 EST
Received: by mailrus.cc.umich.edu (5.59/1.0)
	id AA04178; Wed, 1 Mar 89 12:22:13 EST
Received: from ksuvax1.UUCP by rutgers.edu (5.59/SMI4.0/RU1.1/3.03) with UUCP 
	id AA07118; Wed, 1 Mar 89 12:05:02 EST
Received: by ksuvax1.cis.ksu.edu 
	(5.59++/CIS1.1) id AA05544; Wed, 1 Mar 89 11:04:53 CST
Date: Wed, 1 Mar 89 09:02:24 PST
From: sharkey!mailrus!rutgers!ksuvax1.cis.ksu.edu!scott (Scott Hammond)
Message-Id: <8903011702.AA07131@rdahp.UUCP>
To: mailrus!sharkey!teemc!wayne, mailrus!sharkey!teemc!wayne
Subject: Re: Dreaded System V inode problem
Newsgroups: comp.bugs.sys5
Organization: R & D Associates, Marina del Rey, CA
Cc: 

In article <39256@teemc.UUCP> you write:
>
>	Several months ago, there was a discussion here about the way 
>System V eats inodes under certain circumstances (notably on the news
>partition).  Could someone who has corrected this please mail me a complete
>description that I could forward to my vendor?  I saved what I believed to
>be pertinent articles at the time but they appear insufficient for him to
>locate and correct the problem.
>

This is the article I saved describing the problem.  I have System V
source code, and this explanation was sufficient for me to be able to
find the bug myself.  Unfortunately I haven't been able to 'fix' the
problem because our source does not correspond to the release running
on our news machine, nor does it match the hardware.

[I've been having some trouble with my main mail relay, so I'm sending
 this two ways.  My apologies if you get two copies.  Also beware the
 reply address.]
--
Scott Hammond
R & D Associates, Marina del Rey, CA
Email: rdahp!scott, rdahp!scott@sm.unisys.com, scott@harris.cis.ksu.edu
--
Article 1730 of news.admin:
>From: pjh@mccc.UUCP (Pete Holsberg)
Newsgroups: news.admin
Subject: Re: Alzheimer's Syndrome
Keywords: LONG!
Date: 26 Sep 88 16:35:54 GMT
Reply-To: pjh@mccc.UUCP (Pete Holsberg)
Organization: The College On The Other Side of Route 1

Here's what I found in my archives about the inode problem:
From: glenn@cs.utexas.edu (Glenn G. Lai)
Newsgroups: comp.unix.sysv386
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Date: 7 Apr 1992 08:56:19 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: syrian.cs.utexas.edu

In article <jim.702592380@piggy>, jim@ferkel.ucsb.edu (Jim Lick) writes:
* In <ku109jINNpgm@syrian.cs.utexas.edu> glenn@cs.utexas.edu (Glenn G. Lai) writes:
* >                      This is different from DJ Delorie's stand on DJGPP, a DOS
* >version of GCC/CPP, for which he asks for a 5% royalty for commercial purposes
* >and none if they're non-commercial.
* 
* How can he do this without violating the GNU license on gcc?

I didn't say it clearly enough.  He asks for royalties only for the part he's
written, a stub which acts as a DOS extender so that programs compiled with
DJGPP can access up to 256M of virtual memory on a DOS machine. 


Glenn
glenn@cs.utexas.edu
Newsgroups: comp.unix.sysv386
From: stu@mav.com (Stu Donaldson)
Subject: Re: gcc 2.0 for ISC 2.2.1?
Summary: gcc 2.1 works well
Organization: Maverick International Inc.
Date: Mon, 13 Apr 92 00:25:28 GMT

 I can't talk for gcc 2.0, but I have tried gcc 2.1 with very little
 difficulty to speak of.

 "configure i386-isc" worked out of the box.  I did have to change
 some bugs in the system include files.  Mainly 'memory.h' was defining
 things that were defined elsewhere if __STDC__ was set.  I made memory.h
 check __STDC__ first which seems like a reasonable thing to do.

 Also note that ulimit will need to be upped.  cc1 is larger thatn 2Mb,
 and cc1plus is larger than 3Mb until they are both stripped.  This
 could be fixed with a '-s' option when linking.  I set ulimit to 20000

 'gcc' now uses a file 'specs' in the GCC_EXEC_PREFIX directory for
 the command line options and parsing.  I modified this to use our
 own '-llocal' if '-posix' was not specified.  This is necessary, since
 gcc defaults to __STDC__ and the libc on 386ix 2.2 doesn't have 
 definitions for 'getc/putc' as as does libcposix.  (argh!)

 make bootstrap LANGUAGES="c c++" 

 This worked all the way through with the minor changes I made to the
 include files.  I only built for 'c' and 'c++' since I didn't need
 objective-c, and what I did use took a lot more disk space than I wanted.
 It has been 2 weeks since I did this, and I cleaned up some stuff since
 then.  However I recall it taking 25-30Mb of space.

 I also got libg++2.0 to compile.  There were several places where
 the configuration options I found didn't directly handle the ISC 
 system.  A couple of the Makefiles needed to be modified by hand.
 I also found an inconsistency with the system include files regarding
 the 'chmod' function.  I haven't got the test code to work yet, since
 there is a problem with the new streamio library in libg++ that I haven't
 been able to solve yet.  I get unresolved references to _vt.filbuf at 
 link time, and haven't found where that's supposed to be created.  I also
 haven't looked very hard yet.

 I did get 'groff' to compile and work pretty easily.  It only requires the
 include files with libg++ and not the actual library.

	-- Stu --

-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What happened?  Did you Fail Telepathy?"