HDTenEightyP/NetNews huggingface dataset:
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: It's Time for a Shakedown (was Re: A few answers to Dell Unix FAQ)
Date: 12 Jan 93 19:08:52 GMT
Organization: Auspex Systems, Santa Clara

>This situation is not techno-geek failure, it is
>techno-geek success

That's precisely what I was *saying*.

I *don't* want UNIX to remain the province of techno-geeks such as me
who use C compilers (and, as some people probably don't realize, not all
"techno-geeks" who use UNIX compile C code; some of them compile Verilog
code into chips, or design automobile suspensions, or...) and if that
means the C compiler becomes unbundled, so be it....
Xref: sparky comp.unix.pc-clone.32bit:996 comp.unix.sys5.r4:1180
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sys5.r4
Subject: Re: It's Time for a Shakedown (was Re: A few answers to Dell Unix FAQ)
Date: 9 Jan 93 02:29:51 GMT
Followup-To: comp.unix.pc-clone.32bit
Organization: Auspex Systems, Santa Clara

>Univel is far from perfect. To its credit, the company has developed a
>entry-level desktop version that will probably have a street price of
>about $375US, which is less than anything available based on AT&T/USL
>code.

Except, presumably, for UnixWare, which will, as far as I know, be based
on AT&T/USL code, and which will, from what you say, probably have a
street price identical to that of entry-level desktop version you
mention. :-) :-) :-)

(I.e., I presume you didn't intend to imply that what Univel developed
*wasn't* based on AT&T/USL code....)

>My premise here is that the comptetition/choice issue is now larger than
>"this R4 versus that R4", it's "UNIX versus NT" or "R4 UNIX versus Solaris
>and SCO", and that requires companies with at least a fighting chance of
>taking on SCO, Sun and Microsoft in the marketing trenches.

Actually, it'd be Somewhat Nice if Solaris 2.x didn't become *too*
different from other SVR4-based releases - i.e., if they're perceived as
"another variant" from the standpoint of many developers (both of
commercial apps and of people putting stuff in "comp.sources.*"), I
think they've screwed up; the whole point behind the original Sun/AT&T
deal was to *reduce* the number of ways in which UNIX variants
differed....
Newsgroups: comp.unix.pc-clone.32bit
From: borchert@walt.MsState.Edu (Chris Borchert)
Subject: Advice needed on Unix/Motif for PC
Organization: /home/grad/borchert/.organization
Date: Wed, 6 Jan 1993 13:37:04 GMT

I am not sure about where to post this, but I am trying to get a PC up to
speed for some Motif programming.  I have several years experience on Suns
but am doing some charity work with only a PC.  It is a 386/33 with 8 Meg
RAM and a 130 Meg IDE harddrive.  I have no experience with Interactive or
SCO Unix/Xenix.  Can someone send me some info about the less expensive
options on running Unix/X/Motif on a PC.  I would appreciate any info, 
and especially pricing on the platform, C/C++ compilers, and Motif libaries
available for the PC.

Thanks,
Chris Borchert
borchert@CS.MsState.Edu

--
Chris Borchert
borchert@CS.MsState.Edu

--
Chris Borchert
borchert@CS.MsState.Edu
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.sys5.r4
From: bryan@uhura1.uucp (A. Bryan Curnutt)
Subject: Re: It's Time for a Shakedown (was Re: A few answers to Dell Unix FAQ)
Reply-To: bryan%uhura1@uunet.uu.net
Organization: Stoner Associates, Inc./DREM Incorporated, Houston Texas
Date: Fri, 8 Jan 1993 04:45:34 GMT

In article <2B4AF334.5E9A@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
>
>NetWare is not UNIX. Neither, for that matter, is TCP/IP.

Geez, you obviously haven't been listening to Sun.  Remember,
"The network is the computer."  :-)

(Oh, wait.  I guess they never said "the network is the operating
system...")
-- 
Bryan Curnutt                                  Stoner Associates, Inc.
bryan%uhura1@uunet.uu.net       (713)626-9568 voice  (713)622-7832 fax
From: aland@informix.com (Colonel Panic)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: PC-clone UNIX Software Buyer's Guide
Summary: more Consensys SVR4.2 info
Date: 12 Jan 93 08:02:57 GMT
Organization: Helen Keller Bondurant's Performance Driving School for the Blind

In article <1k2kwy#5zsP0p6W6lKc547rFM3cLmts=esr@snark.thyrsus.com> esr@snark.thyrsus.com (Eric S. Raymond) writes:
>Archive-name: pc-unix/software
>Last-update: Tue Jan  5 23:04:41 EST 1993
>Version: 10.0
>
>   * Info on the Consensys 4.2 port.
>
>Consensys System V Release 4.2			abbreviated as "Cons" below

It seems the info on the Consensys SVR4.0 product (Consensys Release 1.3)
has now been deleted.  Why?  Because it's no longer supported?

Note the price corrections below: 

>Vendor          Cons      Prices on their current price sheet:
>
>Base version:   4.2           
>USL support?    ??           
> 
>System price:
>  Run-time
>   2-user      495         395
>   Unlimited   755         995
>  Complete
>   2-user      1270        995
>   Unlimited   1025       1495   (original doesn't even parse -- how could
>                                  unlimited be cheaper than 2-user???

X and Motif development set is $395; MoOLIT development is $995; C2 Security
set is $395.

They have an upgrade offer for Consensys SVR4.0 (1.2 or 1.3) customers:
they credit you back the full price you paid them, up to $495 for 2-user
or $695 for unlimited, plus they throw in X and Motif development sets for
no cost.

>(m) Consensys explicitly refuses to release this information.
>(n) There's an $80 media charge for the diskettes equivalent to the normal
>    60MB distribution tape.

FYI, for Consensys SVR4.2, it's $120, not $80.  For SVR4.0, it was $40 when
I bought it -- I don't know where the $80 figure came from...


--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland
 Disclaimer: These opinions are mine alone.  If I am caught or killed,
             the secretary will disavow any knowledge of my actions.

    Never trust a UNIX programmer who can't spell "kernel".
Xref: sparky comp.unix.pc-clone.32bit:958 biz.sco.general:4985
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Newsgroups: comp.unix.pc-clone.32bit,biz.sco.general
Subject: Re: Setting up NNTP server on SCO 3.2 and TCP/IP 1.2
Date: 5 Jan 1993 11:55:01 -0500
Organization: The Programmers' Pit Stop, Ann Arbor MI
NNTP-Posting-Host: mudos.ann-arbor.mi.us

In article <C0Dtyr.3ro@watserv1.uwaterloo.ca> kmacinty@watserv1.uwaterloo.ca (Kevin MacIntyre - Conestoga College) writes:
>We are looking for a solution which will allow us to set up an NNTP server
>on SCO 3.2 with TCP/IP 1.2.  We plan to have users access the news thru a
>PC based newsreader such as Trumpet.

Well, you could always try obtaining some free NNTP software (either
the reference implementation, or INN), compiling it, and installing
it.

Or were you looking for a different kind of solution?

-- 
Marc Unangst, N8VRH         | "Of course, in order to understand this you
mju@mudos.ann-arbor.mi.us   |  have to remember that the nucleus of the atom
                            |  is squishy."
                            |    -W. Scheider, from a Physics lecture
Newsgroups: comp.unix.pc-clone.32bit
From: chip@chinacat.unicom.com (Chip Rosenthal)
Subject: Re: Changing serial port characteristics under SCO
Organization: Unicom Systems Development, Austin, TX
Date: Thu, 07 Jan 1993 06:38:58 GMT

In article <78@mhinfo.UUCP> rwc@mhinfo.UUCP (Ralph Callaway) writes:
>I know that there is an easy way to permanently change a serial
>ports default characteristics at startup time

No, there really isn't.  That's why some vendors provide an extended
stty command.  For example, the DigiBoard cards allow you to lock
down rtspace and ctspace with their `ditty' command.  Many other vendors
do this too.  Check out the docs that came with your serial board.

Actually, calling this stuff permanent is misleading.  It isn't.  It
does persist across a close/open, and because it uses proprietary
extensions your average everyday application won't know where to find
the settings much less screw with them.

Here are a couple of things to consider:

1)  Complain to your software vendor.  Not supporting the print spooler
    is bogus.  Tell them to stick to DOS software if they are that
    badly lacking in clues.

2)  Consider doing the printing to a pseudo-device, and then using a
    daemon to slurp down the print job and shuffle it off to the spooler.
    If your idiot software vendor isn't doing anything with terminal
    control, then a simple named pipe will do as the device and the
    daemon can be a dozen line shell script.  If these morons do try
    to do terminal settings than you'll have to use a pseudo-tty.

By the way, you are doing the public a grave disservice by not mentioning
the name of the application vendor.  I for one would like to know who
they are so that I can avoid any of their products.
-- 
Chip Rosenthal  512-482-8260 | Ergonomic (adj) - Designed to ensure
Unicom Systems Development   | maximum discomfort in left-handed people.
<chip@chinacat.Unicom.COM>   |
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386
From: jdpierc@netcom.com (Jerry D. Pierce)
Subject: CDROM & VP/ix headache
Followup-To: poster
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 9 Jan 1993 06:22:10 GMT


Must be my week for weird hardware problems.

I just installed a Toshiba CDROM drive on a 486 at
work which we're running Interactive UNIX 3.0 on.

I used the Future Domain controller which came with
the CDROM drive, and it was surprisingly easy to get
it working with unix.

After going through and configuring the hpdd, I rebooted
the box and there it was.  Mounted up a cd and was able
to peruse files no problem. 

Since I need to be able to run some dos software (under
vpix) on the CDROM drive, I fire up vpix.  OK so far, but
in order to run the demo software that came with the
CDROM drive, I need to add a line to the config.sys
that points it towards a device driver, and then another
line to the autoexec.bat which runs a general setup 
of some sort based on finding the previously loaded
driver.  

Still no problem, I edit the config.sys and autoexec.bat
and put the driver (something.sys) into the /usr/vpix/dosbin
along with the program which'll be called from the autoexec.bat
file.  Fire up vpix again, and get:  "BAD OR MISSING XXXXX.SYS
DRIVER".

Now UNIX appears happy with the device/controller, and to a
point, vpix appears happy.  (I can access files on the cdrom
from within vpix, just not run the included software...)

Suggestions?

Oh, and I discovered initially that going into vpix and doing
a "dir" on the mounted CDROM showed no files - it was a bug in
the "high sierra" drivers shipped with Interactive 3.0 and
needed to get a fixdisk to correct that problem.   (This,
at least, works now)

   Jerry D. Pierce
   jdpierc@netcom.com

Newsgroups: comp.unix.pc-clone.32bit
From: rwj@dogtag.uucp (Rob Janes)
Subject: scsi tape problems on isc 3.0
Reply-To: rwj@bsoh.wimsey.bc.ca
Organization: BSOH Enterprises
Distribution: na
Date: Mon, 11 Jan 1993 01:34:07 GMT

I've been kind of banging my head against the wall here- I can't figure
out how to get this archive viper tape drive recognized by the kernel.
A scsi probe reveals scsi 1 and 2 are hard disks, and scsi 4 is the
archive viper.  The light on the viper comes on, so it looks like the
hardware is working to some extent.

I followed the instructions in the manual for tape devices, however,
it's for the previous release of interactive.  So what I've done is
1 added to pack.d/gendev/space.c
   extern int tape_init();  under disk_init()
   and
   tape_init, to the gdev_init_routines table.
2 fixed up the pack.d/tape/space.c that wouldn't compile, even after
  following the instructions and removing unused driver entries.
  I ended up copying the one from the web, and using that.
3 rebuilt the kernel, rebooted, there was no /dev/tape, so I made
  one, major 41, minor (scsi id 4*16+8) 72.  Guess the node.d/tape wasn't
  set up.
none of the above did the trick, so I looked a bit harder.
4 copied the tp0t drivers from the web, and installed them.
  made sure the sdevice and mdevice entries for tape and tp0t matched
  those on the web.  Assigned an unused major number for tp0t in mdevice.
  (Where do these drivers come from?  They don't seem to be on the base
  system.  They look like they're from interactive, they've been in all
  the kernels since the upgrade to ix 3.0.)
this didn't work.
5 compared pack.d/gendev/space.c on my machine and the web-
  3 defines were different, mainly 
  GDEV_MAXDRIVS to 14 on web, 13 on my machine
  GDEV_MINORMAPS to 224 on web, something smaller on my machine
  GDEV_MAJORMAPS to 58 on web, 1 on my machine.
  also, web's had an extra entry had been added to the gdev_iobufs table,
  as indicated by the instructions about GDEV_MAXDRIVS.
  So, changed my defines, and the table, to match the web's.
  Still didn't work.
6 The major number for tp0t is 62, whereas the major number for tp0t on
  the web is 57.  major 58 is lockd on web, probably some nfs function.
  It seems likely nfs stuff would be routed through the hpdd, so maybe
  GDEV_MAJORMAPS has to be set large enough to encompass all the major
  numbers it has to handle.  So I bumped GDEV_MAJORMAPS in
  pack.d/gendev/space.c up to 62.
  Still didn't work.
So I'm at a loss.  I'm going to try one more thing.  I'm going to bump
GDEV_MAJORMAPS up to 63, on the assumption that it needs the extra
room, and nfs has nothing to do with the hpdd (high performance disk drv).
I don't think it's going to work though.
... later ... - It didn't!
Any suggestions would be much appreciated.
Thanks!
   Rob Janes
-- 
Rob Janes
rwj@bsoh.web.apc.org
From: dougm@boulder.Central.Sun.COM (Doug McCallum)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Shared Memory or DMA ethercards for UNIX on a PC
Date: 8 Jan 93 09:18:48
Organization: SunSoft, Inc.
NNTP-Posting-Host: boulder.central.sun.com
In-reply-to: bad@flatlin.ka.sub.org's message of Wed, 6 Jan 1993 23:00:06 GMT

In article <C0GFw7.C7u@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:

   The best choice would be a card that is supported with a driver by your
   UNIX. That said, I know of no ethernet card driver for UNIX that does
   DMA (if someone knows better please correct me).

Racal Datacomm (Interlan) has SCO and ISC drivers for their NI6510 bus
master card that uses DMA.  Bus mastering DMA is much better than
standard AT DMA.
Newsgroups: comp.unix.cray
From: jones@chpc.utexas.edu (Willaim L. Jones)
Subject: Re: Cray EL
Organization: The University of Texas System - CHPC
Date: Wed, 6 Jan 93 18:11:11 GMT


>From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
.
.
.

>    The slowest NFS server I've ever used!!  And after one full year
>of operations, Cray still hasn't managed to fix this.  Also the least stable,
>though to be fair Cray seems to have finally succeeded in providing
>us with a stable machine.  You wouldn't believe how often it used to
>crash in the first few months.

Just as stable as their large machines.  

I sure wish cray would really put in the effort that is needed to fix 
their operating system.

Bill Jones
jones@chpc.utexas.edu

The long suffering!
From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
Newsgroups: comp.unix.cray
Subject: Re: Cray EL
Date: 6 Jan 93 17:03:26 GMT
Reply-To: brossard@sic.epfl.ch
Organization: Ecole Polytechnique Federale de Lausanne

In article <BzL9CC.9E@rex.uokhsc.edu>, ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:
|> 
|>        I am curious as to what anybody thinks of the Cray EL.  I am
|> looking over some stuff, but I was wondering what other people think of
|> it -- especially people who have worked with it. 

    The slowest NFS server I've ever used!!  And after one full year
of operations, Cray still hasn't managed to fix this.  Also the least stable,
though to be fair Cray seems to have finally succeeded in providing
us with a stable machine.  You wouldn't believe how often it used to
crash in the first few months.

    
-- 

Alain Brossard, Ecole Polytechnique Federale de Lausanne,
	SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
brossard@sic.epfl.ch
Newsgroups: comp.unix.cray
From: anderson@prowler.navo.navy.mil (Douglas T Anderson)
Subject: System Stability [Was Re: Cray EL]
Nntp-Posting-Host-[nntpd-14647]: prowler.navo.navy.mil
Reply-To: anderson@pops.navo.navy.mil
Organization: POPS Facility Managment
Date: Thu, 7 Jan 1993 14:45:24 GMT

In article <1993Jan6.181111.14914@chpc.utexas.edu>, jones@chpc.utexas.edu (Willaim L. Jones) writes:
|> 
|> >From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
|> .
|> >Also the least stable, though to be fair Cray seems to have 
|> >finally succeeded in providing us with a stable machine.  You 
|> >wouldn't believe how often it used to crash in the first few 
|> >months.
|> 
|> Just as stable as their large machines.  
|> 
|> I sure wish cray would really put in the effort that is needed to fix 
|> their operating system.
|> 

These messages got me to thinking, we have 3 Cray systems here on
site (YMP8/8128, YMP2E/116, XMPEA-116) and over the past 3 years we
have experienced what I consider to be pretty good stability.  We
have significantly more failures caused by shooting ourselves in the
foot other then Cray caused failures, I dont have the numbers here
in front of me, but our MTBF (Mean Time Between Failure) is 
on the order of 800 hours on the Y's and about 500 hours on the 
X.  We run 24 hours a day/7 days a week and have experienced a 
99.86% up time over the past 3 months.

CUG statistics show, what to me as a Computer Center manager, would
be good numbers for stability (though not as high as we are ;~) ).  

With our experience, and what appears to be the "average" from the
CUG reports, I think the system/OS stability is pretty good, but
more work needs to be done on System Operations/Administration tools
to help us in the data center.  Users dont care if its a CPU
failure, Disk head crash, memory failure, or the operator "pulling
the plug", down is down.

-- 
Douglas T Anderson
Technical Services Manager/Chief Engineer
POPS Program

All opinions expressed are mine and mine alone.  They do not
reflect the opinions of Grumman Data Systems, the US Navy or any
one else, unless they want them to.
Newsgroups: comp.unix.cray
From: tjg2946@ritvax.isc.rit.edu
Subject: WHY IN THE WORLD
Reply-To: tjg2946@ritvax.isc.rit.edu
Organization: Rochester Institute of Technology
Date: Sun, 10 Jan 1993 08:44:01 GMT

	would a Cray crash quicker than a simple hard drive?  Can anyone
detail me what kill Cray so much?
From: Michel Reymond
Newsgroups: comp.unix.cray
Subject: Re: Cray EL
Keywords: performance
Date: 8 Jan 93 15:36:38 GMT
Reply-To: whom it may concern
Organization: EPFL

In article <1993Jan6.180326@siisun.epfl.ch> brossard@siisun.epfl.ch (Alain
Brossard EPFL-SIC/SII) writes:
>In article <BzL9CC.9E@rex.uokhsc.edu>, ben@rex.uokhsc.edu (Benjamin Z.
Goldsteen) writes:
>|> 
>|>        I am curious as to what anybody thinks of the Cray EL.  I am
>|> looking over some stuff, but I was wondering what other people think of
>|> it -- especially people who have worked with it. 
>
>    The slowest NFS server I've ever used!!  And after one full year
>of operations, Cray still hasn't managed to fix this.  Also the least stable,
>though to be fair Cray seems to have finally succeeded in providing
>us with a stable machine.  You wouldn't believe how often it used to
>crash in the first few months.
>
>    
>-- 
>
>Alain Brossard, Ecole Polytechnique Federale de Lausanne,
>	SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
>brossard@sic.epfl.ch
>
factoids on cray-el at lausanne polytech (epfl):
- feb92: inst. of worldwide first system at epfl s/n 5110. worlds most
  complex EL file-server only configuration, 62 GB disk including alpha
  testing RAID technology and STK 4400 1.2 TB cartridge robot system.
  ethernet, fddi, hippi.
  2 months collaboration with cray to debug this alpha system.
- may 92 - nov 92: production with alpha prototype: uptime 99.14%
  nfs performance bugs and raid disk bugs fixed.some crashes due to
  hardware not yet uprev'd but known; tape-deamon bugs.
- nov92: replacement of alpha prototype by fully up-rev'd system: no
  unplanned interruption since then. hippi still delayed by third party.
- nfs performance: compare apples with apples - el is average in stand-
  alone, but much better than others with heavy load (average keeps up!).
  this using nfs standard waiting write ack. testing witout write ack
  will be performed soon.
- general cray uptime: cray-2 99.82 % (9 out of 12 months no interrupt)
  y-mp/4e 99.57 % including installation in may 92. this blows the socks
  off other supercomputers installed in switzerland by other vendors.
- information: michel jaunin, head computing center epfl: e-mail
  jaunin@sic.epfl.ch
michel h. reymond, director scientific computing center epfl
e-mail: reymond@sic.epfl.ch
From: karell@cs.Helsinki.FI (Esa Karell)
Newsgroups: comp.unix.questions
Subject: Calcomp plotter mode switching
Date: 7 Jan 1993 20:50:15 +0200
Organization: University of Helsinki, Department of Computer Science
NNTP-Posting-Host: hydra.helsinki.fi

Has anyone figured out how to switch Calcomp's
plotter modes ("users") by a command?
In case interested, calcomp has several modes
for different types of plots e.g. AutoCad etc..
It's a pain to go to the plotter and manually
do the switch. Docs that came don't discuss
this.

Esa
-- 

Esa Karell karell@cs.Helsinki.FI
Tel. +358-0 513 081 /home
From: steve@sbrorens.equinox.gen.nz (Steve Brorens)
Newsgroups: comp.unix.questions
Subject: Using GROUPS to control access ????
Distribution: world
Date: Tue, 12 Jan 93 19:04:17 GMT
Organization: Communication Architects

A couple of questions on the use of group membership to control
access to directories:

BACKGROUND: A while ago I was involved with a fairly complex commrcial 
install of SCO UNIX (v3.2.2). Coming from a NetWare (no flames plse!) 
background, I'm used to being able to set up (using Directory Trustee Lists) 
a structure like:
	Directory: /data/accounts
	Members of group ACCOUNTS are granted full access
	Memebrs of group MANAGERS are granted read only rights
	User FRED is granted full access 
	....so if SUE is a member of groups ACCOUNTS and MANAGERS, then she
	has full access.
I gather the std term for this approach is AccessControlLists. (?)

In SCO v3.2.2 as shipped a user can belong to multiple groups, but only the 
one he is "newgrp"d to at the time is checked when access is attempted. BUT
when we set up a script:
	newgrp accounts
	cd /data/accounts
	fireup accountsprog
	cd 
	menu
...then it fails on the first line 'cos newgrp does a FORK and the script is 
"left behind" in the old shell
(I understand that NOW...in the current version... all of the groups that a 
user is a member of are checked for file access, and that the current 
"newgrp" group is used just where we are creating a new file/dir)

QUESTIONS:

Q1: Do most Unix flavours check all the groups that the user belongs to when 
	determining access rights?... and what is the "correct" behaviour?

Q2: How common is it for unix flavours to implement a type of "Access Control
	List" (I beleive AIX does) and how widely are they used (I've been
	told that this type of control under VAX VMS (Yes I KNOW it's not a
	unix!) is seldom used for performance reasons)

    






Cheers,
 
   Steve Brorens CNE                       (STEVE@sbrorens.equinox.gen.nz)
   Christchurch 
   NEW ZEALAND

Newsgroups: comp.unix.questions