HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (Peter da Silva)
Subject: Re: SVr4 and clone hardware buyer's FAQ
Organization: Xenix Support, FICC
Date: Thu, 9 Apr 1992 17:05:28 GMT

In article <3893@airs.com> andrew@airs.com (Andrew Evans) writes:
> Who's "everyone?"  Do you really think that Joe Executive, charged
> with the duty of acquiring a System V Release 4 operating system, will
> notice the difference when looking at SCO System V Version 4?

If Joe Executive has been charged with the duty, and doesn't have the
resources to specify the system properly, he's probably better off with
SCO than SVR4 anyway. I'd say he got off lucky... he could have ended
up buying Solaris.

> The corporate buyer who has no idea what the
> distinguishing features of an SVR4 operating system are ...

... shouldn't be specifyuing the system in the first place.
-- 
/F{/Times-Roman findfont exch scalefont setfont}def /M{moveto}def /S{show}def
8 F 24 24 M (Sugar Land, TX  77487-5012; +1 713 274 5180)S 60 0 rmoveto(`-_-')S
12 F 24 32 M (Peter da Silva, Ferranti International Controls Corporation)S
0 -6 rmoveto 20 F ( Have you hugged your wolf today?)S showpage
Newsgroups: comp.unix.sysv386
From: coffler@jeck.amherst.nh.us (Jeff Coffler)
Subject: Re: SVr4 and clone hardware buyer's FAQ
Reply-To: coffler@jeck.amherst.nh.us (Jeff Coffler)
Organization: Private system
Date: Wed, 8 Apr 1992 12:09:55 GMT


In article <1992Apr08.001429.27487@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:

|>>The corporate buyer who has no idea what the
|>>distinguishing features of an SVR4 operating system are could easily
|>>get befuddled into buying SCO's product.
|>
|>What are they?  Why does the "corporate buyer" *care* what the base OS is,
|>if it has the features (s)he needs?  The only reason to care about SysVr4
|>vs. SysVr3 is:  for kernel programmers, for device drivers, for compiler
|>writers, for applications which require SysVr4.  Guess what:  there aren't a
|>whole lot of applications which *do* require SysVr4!  Almost everybody still
|>writes for XENIX/286, XENIX/386, or, growing in numbers now, UNIX/386 3.2.

Regardless of *your* opinion of what the "corporate buyer" needs, it is clear
to me that SCO's current naming of their product will confuse SOME, who, for
whatever reason, decide that they do want SVR4.

|>>I think it's deplorable of them to want to charge $400 for what
|>>amounts to a bunch of bug fixes and detail improvements that no one
|>>should have had to put up with in the first place.  
|>
|>Bullshit.  Since you didn't work on the code, I seriously doubt you know
|>what went on with it.  The long filename work and symbolic links were *not*
|>trivial; the kernel work was the *easiest* part, and still took a while to
|>get right.  The compiler and company had to be changed to allow longer
|>filenames (bet you didn't think of that, did you?), as did about a dozen
|>other utilities.  I came up with an initial list, for the base OS
|>distribution, but just grep'ping in the entire source tree for DIRSIZ.  And
|>that wouldn't cover half of the work.

Jesus, Sean, this is absolutely unbelievable!

A tremendous favor was done by posting the SVr4 and clone buyer's FAQ.  Many
many really confusing aspects of buying were answered by that FAQ.  And yet,
you complain about *ONE* thing within it!

I never considered the buyer's guide to be gospel.  It's a posting that is one
man's opinion.  While I happen to agree with much within it (based on my own
conclusions, and based on my own research), it is still one man's opinion
about the Unix market on Intel processors.

If you don't like that one man's opinion, then you are free to do better.  But
rather than pick apart what was done, why don't YOU go and research the entire
market, and then post a VERY long, and VERY informative buyer's guide.  As it
is, you're just someone spouting off cuz' you don't care for what a poster had
to say.  Not much meaning to me, since I don't see you contributing such useful
things to the net ... especially in comparison to the buyer's guide.
-- 
Jeff Coffler                            UUCP:      ...{decvax,mv}!jeck!coffler
Southern New Hampshire                  Internet:  coffler@jeck.amherst.nh.us

                {Disclaimer: What I say is my personal opinion}
From: kew@timesink.spk.wa.us (Keith Walker)
Newsgroups: comp.unix.sysv386
Subject: Is there life after Bell Tech?
Summary: Bell Tech Unix 3.2.1 doesn't know what a vga card is
Date: 11 Apr 92 06:45:29 GMT
Organization: CIMS Inc; Spokane, Washington

After years of working with a 386 box with only a monochrome
screen, I just bought a new 386/40 with a VGA (Trident 8900C
chipset, I believe) screen. Unfortunately, Bell Technologies
Unix R3.2.1u doesn't know what a vga card is, much less how
to deal with it.

When the system boots, the screen goes inverse (black chars
on a white background), and some of the features like color
and underlines don't work. Otherwise, it is working -- I
mean, at least I can use the machine.

Is there an easy fix to this problem? Like a new console
driver or something? I hasten to point out that after
purchasing the computer, I have little money left, so the
cheapest solution may be the best for me.

I'm kinda VGA illiterate (couldn't you tell?), so go easy on
me, folks!

-- 
kew@timesink.spk.wa.us | I have no doubt that is is a part of the destiny of
Keith Walker  	       | the human race, in its gradual improvement, to leave
                       | off eating animals, as surely as the savage tribes
(509) 466-9384         | have left off eating each other when they came in
From: robert@alicia.sdata.de (Robert Ebe)
Newsgroups: comp.unix.sysv386
Subject: "Select failed" with ghostview 1.1
Date: 14 Apr 92 18:55:22 GMT
Organization: C. Splittgerber Datentechnik, Denkendorf, Germany

Hello,

I compiled ghostview 1.1 successfully with gcc 2.1 on ISC 2.0.2.
When running it in a xterm on Roell's X386R4 1.1b I get an endless
stream of the following message:

Warning: Select failed; error code 25

The README file tells that users reported the occurrence of this bug on
systems with a SYSV and a BSD library. It is stated that ghostview 
shoult be linked with the BSD lib rather than the default SYSV lib.

Hmm, don't have such a BSD lib.

Any hints?

Thanks, Robert

-- 
++++++++++++ Memorial line for Miles, the man with the horn +++++++++++++
robert@alicia.sdata.de      (...!uunet!mcsun!unido!alderan!alicia!robert)
Robert Ebe, 2:241/7401.17@fidonet.org  (Germany)    Voice: +49 7121 83335
From: pbryant@ukelele.UUCP (Patrick Bryant)
Newsgroups: comp.unix.sysv386
Subject: Re: Where can I purchase Interactive?
Date: 9 Apr 92 21:23:36 GMT
Distribution: usa
Organization: GAU Technologies, Fairfax County, VA

pbh@jake.cc.wayne.edu (Patrick Haggood) writes:

>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* 

  I suggest you contact the company directly and ask for purchasing information 
from them.  The Interactive SysV/386 (3.2.2) that I am using was purchased 
through the company Sysorex.  You can contact them at:

	Sysorex Information Systems
	560-A Brooke Road
	Winchester, VA  22601
	(703) 662-1736

-- 
Patrick E. Bryant
pbryant@ukelele.UUCP

 - Is there anyone else out there?
Xref: sparky comp.unix.sysv386:8742 comp.unix.questions:6265 comp.unix.admin:2825
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Newsgroups: comp.unix.sysv386,comp.unix.questions,comp.unix.admin
Subject: Is there an equivalent of FIONREAD for writing?
Date: 16 Apr 92 20:29:26 GMT
Followup-To: comp.unix.sysv386
Organization: ISCA

I'm using TCP stream sockets and reading/writing data from/to them.  I know I
can use the FIONREAD ioctl to determine how many characters are awaiting a
read, but is there a way of determining how many characters are available for
a write, so that I can postpone my writing until there is enough room to
actually write the whole block of information?  It seems to me that would be
more efficient than slowly stuff data in bit by bit as each successive write
call only writes a portion of my remaining message.  Any ideas?

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                | "I don't have to take this abuse from you --  |
|                             |  I've got hundreds of people waiting in line  |
| dsiebert@icaen.uiowa.edu    |  to abuse me."  -  Bill Murray, Ghostbusters  |
\-----------------------------------------------------------------------------/
SIGNATURE VIRUS 3.0b, NEW AND IMPROVED -- NOW EVEN LOUDER AND MORE ANNOYING!!!!
Xref: sparky comp.unix.sysv386:8345 comp.dcom.modems:6402
From: wht@tridom.com (Warren H. Tucker)
Newsgroups: comp.unix.sysv386,comp.dcom.modems
Subject: Prerelease of ECU 3.20 available for ftp
Date: 5 Apr 92 21:46:04 GMT
Reply-To: wht@n4hgf.Mt-Park.GA.US
Organization: Tridom Corporation, Marietta GA

For the next few days, there will be a prerelease of ECU 3.20
available for ftp as ftp.uu.net/ecu31833.tar.Z.

There are several functional enhancements in 3.20, but
it has primarily been a hardening and portability release.
The ISC and SunOS support is better. Several problems with
XENIX support for 3.16 have been addressed.

I do not have time to document all the changes or to do
much hand holding in getting it up and running.  You should
have less difficulty in getting this version going than
previous versions, for sure.  I have tried to update the manual
and READMEs, but I have certainly missed something.

1. new commands (procedure and interactive)
   a.  autorz
   b.  dcdwatch

2. dial command reworked
   a. new sub menu for entry add/edit
   b. phone number size increased from 25 to 40 characters
      (some modems limit input string size to 40 characters total
      excluding AT and trailing CR)
   c. Trailing dollar sign '$' appends ~/.ecu/.credit to dialled number:
      .credit has:
          ,,,167167002
      Home dial 1234 sends to modem
          1234,,,167167002

3. help cmd improved: you can stay in a category and ask
   for help with multiple commands and use F1 to return to
   category menu.

4. Major rework inside to reduce but not eliminate the likelihood
the chances ecu will abnormally terminate when the dial command
needs to change to a new line and the new line is not available.
If the new line is busy (in use by another dialout or login),
the request to change is rejected and the old line is retained,
the program survives.  If the new line is unavailable because
of other reasons (read/write denied [chmod] for instance), ecu still
dies. hopefully this will all be handled by the time of release.

5. Gcc 2.1 has been tested and appears to produce an even smaller
binary than 1.40.  This compiler continues to be the big winnder
in my book, shaming many big-buck commercial efforts.  If you
do not have and use gcc, you are really missing out !!!

What I want from you
--------------------

1. Does it work?  Where bdoes it fall down?
2. Where is the manual or on-line help inaccurate?
3. What else is broken in the SunOS version :-)?  I have had
   only a mediocre async environment to test the SunOS version.
4. Flames, comments, large sacks of unmarked tens and twenties,
   etc. appreciated.

--------------------------------------------------------------------
Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US
Hacker Extraordinaire  d' async PADs,  pods,  proteins and protocols
-- 
----------------------------------------------------------------------------
Warren Tucker, Mountain Park Cartography   n4hgf!wht/wht@n4hgf.Mt-Park.GA.US
A remote debugging human who appreciates Howard Rourke, Leonard Cohen and PI
Newsgroups: comp.unix.sysv386
From: apl@world.std.com (Anthony P Lawrence)
Subject: Re: Memory Cache and Unix
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 9 Apr 1992 12:28:31 GMT

In article <1992Apr5.234603.3083@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>In fact, I know that disabling the internal 8k cache on a 486 has had a
>significant detrimental effect on performance on all of the systems we 
>have tested (ranging from 25% to 3,000% depending upon the application).
>
I now understand that the 16-32-64-whatever caches do not work the same: 
if I've got this right, the 8k is just a pre-fetch queue just like the 
little bitsy ones on 8086's.  That queue is subject to flushing and refilling 
on any branch. The large external caches are more intelligent and don't
necessarily flush all out just because some new data is being accessed.  While
my gut tells me that such schemes tend to work better under test than they
do in the real world, I'm ready to believe in the theory.  I guess I'm more
willing to believe that a CPU cache could do some good than I am about a
(hardware) disk cache, anyway.

But here you talk about disabling the pre-fetch, and not about the
other (external).

Have you done any testing of 16k vs 32K etc?  I have not, but have
been told by someone I usually trust that he measures "No Difference"
on anything over the 8k internal queue.

Tony 


Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle

 
Newsgroups: comp.unix.sysv386,comp.windows.x
From: mark@snark.itc.gu.edu.au (Mark Hessling)
Subject: Solution to strange video behaviour on X386 with ET4000
Keywords: X386 ET4000
Organization: ITC, Griffith University, Brisbane, Australia
Date: 11 Apr 92 00:50:13 GMT


Firstly, thanks to those people who responded with assistance in resolving
my problem of getting X386 to run under ESIX v4 with a new ET4000 SVGA card
purchased especially for X386. The solution follows:

Firstly The Problem:
-------------------
The symptoms I was getting was a VERY out of sync image, but when I did get
an image that was stable, 4 images were displayed.

The Cause:
---------
The clock chip on my video card was actually running at twice the speeds that
clock.exe and X386 were telling me. This is apparently common with some newer
ET4000 based cards.

The Solution:
------------
- Apply the follwing source patch (if you have source) and/or obtain the X386
  binary from physics.su.oz.au in /tmp (called x386.test.Z) (This is the binary
  for ESIX v4)

*** mit/server/ddx/x386/drivers/et4000/driver.c.STD     Thu Apr  9 19:11:22 1992
--- mit/server/ddx/x386/drivers/et4000/driver.c Thu Apr  9 19:11:55 1992
***************
*** 346,352 ****
    new->std.CRTC[23] = 0xAB;
    new->StateControl = 0x00;
    new->AuxillaryMode =
!     (mode->Clock > 45) && !(mode->Flags & V_INTERLACE) ? 0xEC : 0xAC ;
    new->ExtStart = 0x00;
 
    new->OverflowHigh = (mode->Flags & V_INTERLACE ? 0x80 : 0x00)
--- 346,353 ----
    new->std.CRTC[23] = 0xAB;
    new->StateControl = 0x00;
    new->AuxillaryMode =
!     ((mode->Clock > 45) && !(mode->Flags & V_INTERLACE)
!      || !strcmp(vga256InfoRec.vendor,"hiclock")) ? 0xEC : 0xAC ;
    new->ExtStart = 0x00;

    new->OverflowHigh = (mode->Flags & V_INTERLACE ? 0x80 : 0x00)

- Change your Xconfig to include the following line after the Virtual Screen
  line:

Vendor  "hiclock"

- For those using the binary X386.test, it was compiled with SpeedUp-1.1
  patches applied so you need to make your virtual screen size to be 
  1024 1024.

- copy the X386.test server to the directory where your other servers are
  and point the symbolic link of X386 to it and start up X386.

- I was able to get good initial results with the standard video modes and
  they just needed some tweaking afterwards.

- If you intend creating custom video modes do all of your calculations with
  the figures reported by clock.exe and X386.

GOOD LUCK!

NB

*** ALL OF THE INFORMATION ABOVE HAS BEEN SUPPLIED BY David Dawes,
*** dawes@physics.su.oz.au WHO IS ALSO THE PERSON RESPONSIBLE FOR SUPPLYING
*** THE X386 PORT TO ESIX.  ALL PRAISE AND THANKS TO HIM, I JUST HAPPENED
*** TO BE THE FIRST TO BENEFIT FROM HIS GENEROSITY.
------------------------------------------------------------------------
Mark Hessling                         Email: mark@snark.itc.gu.edu.au
ITC                                   Phone: +617 875 7691
Griffith University                   Fax:   +617 875 7877
Nathan, Brisbane QLD 4111 Australia
------------------------------------------------------------------------
From: paulr@email.sp.unisys.com (Paul Raulerson)
Newsgroups: comp.unix.sysv386
Subject: Re: SVr4 and clone hardware buyer's FAQ
Summary: SVR4 vs. SCO
Date: 16 Apr 92 16:45:23 GMT
Article-I.D.: email.5986
Organization: UNISYS - Eagan, MN

In article <id.Q3RO.UCL@ferranti.com>, peter@ferranti.com (Peter da Silva) writes:
> In article <3893@airs.com> andrew@airs.com (Andrew Evans) writes:
> If Joe Executive has been charged with the duty, and doesn't have the
> resources to specify the system properly, he's probably better off with
> SCO than SVR4 anyway. I'd say he got off lucky... he could have ended
> up buying Solaris.
> 


Since on a pure application basis, Solaris will have a heck of a lot more 
applications avaiable; and on an upgrade path, there is little comparison
betwen a 80586 and a SPARC- I would say you probably got that reversed. 

SunOS is probably the best supported UNIX variant in the world. 

-Paul
Xref: sparky comp.unix.sysv386:8327 comp.unix.bsd:700 comp.arch:4812 comp.sys.ibm.pc.hardware:13402
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.unix.sysv386,comp.unix.bsd,comp.arch,comp.sys.ibm.pc.hardware
Subject: Cyrix CX486SL
Date: 6 Apr 92 13:30:44 GMT
Reply-To: rob@wzv.win.tue.nl
Followup-To: comp.unix.sysv386
Organization: Sex, UNIX & Rock 'n Roll

I read in a magazine lately that Cyrix has announced a new processor,
the CX486SL, a clone of the Intel i486. The article stated that
apart from the price ($119 vs. $400 for a real 486 (both 25 Mhz)),
its main strength is the fact that it has a casing compatible with
the Intel 386SX. This made me wonder:
- I assumed that the 386SX is a surface-mounted component which is
glued/soldered onto the motherboard. If true, this makes upgrading
your 386SX motherboard rather difficult.
- A typical 386SX motherboard has a 16-bit databus, does this mean
that this processor is also only 16 bits external ?
- Does it have a coprocessor, like a real i486 ?

The concept isn't as interesting as I first thought, almost all
SX boards and PC's are 16 or 20 Mhz, 25 Mhz SX'es are rare, so
why go for this strategy ? Has any manufacturer announced a
motherboard based on this processor yet ?

Anyway, I've lost track on all the (clone and official) 386SX,
386DX, 486, etc chips available, so if you have any information,
please send mail, and I'll prepare a summary. I'm especially
interested in the chips which are n ot plain vanilla clones, like
a chip I heard about recently, which is a 25 Mhz component with
an internal speed of 50 Mhz. This sounds interesting, but muddles
the PC market. Nowadays, if you buy a 486, you might risk not
getting a real 486, but discover at home that your 50 Mhz machine
is really a 25 Mhz machine with that chip, or that your 25 Mhz
machine has a 16-bit 386SX design...

Rob
From: ukrainec@nimios.eng.mcmaster.ca (Andrew Ukrainec)
Newsgroups: comp.unix.sysv386
Subject: Re: ISC Install disk problem
Date: 14 Apr 92 20:36:07 GMT
Organization: Communications Research Laboratory, McMaster Univ

In article <1992Apr14.003531.6306@ccu.umanitoba.ca> umcarls9@ccu.umanitoba.ca (Charles Carlson) writes:
>In <1992Apr9.160958.27180@maccs.dcss.mcmaster.ca> ukrainec@nimios.eng.mcmaster.ca (Andrew Ukrainec) writes:
>
>>Question 1: Has anyone had problems with ISC 3.0 Install disk?
>>Question 2: What program (DOS diskcopy, cpdisk, dd ...) did you use
>>            to back up the disk?
>
>>I'm on my third disk.  The first had an unreadable block, and wouldn't copy.
>>The second and third floppy replacements from the distributor, and they both
>>have file system problems.  Any suggestions?
>
>The install instructions (for 2.2)state you cannot use DOS's diskcopy to back up
>the install disk, you must use dd.
>
>Any other DOS program that can handle odd sector and track formats should
>work as well.
>
>Charles

The results are:

1.) The problem I had was with a VGA card in the 16-bit slot.  When
    running install, you need to first move the card to an 8-bit slot.
    Afterwards, you can move it back.

2.) diskcopy versions prior to MSDOS 3.3 can be used.  Otherwise, you
    need to use dd or the sysadm function to copy a disk.  But how are
    you suppose to back it up the first time you install unix? 
    Also, the installation instructions in 3.0 say you can back it up using
    DOS diskcopy (no mention of version).  This should be corrected.
    Perhaps a DOS disk duplicating utility would work?
 
Thanks for all the responses.  Things are working again ...
-- 
         Andrew Ukrainec                 ukrainec@nimios.eng.mcmaster.ca 
          <    (*) >               /  \             < (*)    >           
Communications Research Laboratory      McMaster Univ, Hamilton, Ontario
Xref: sparky comp.unix.sysv386:8588 biz.sco.opendesktop:392 biz.sco.general:1803
From: losecco@undpdk.hep.nd.edu (John LoSecco)
Newsgroups: comp.unix.sysv386,biz.sco.opendesktop,biz.sco.general
Subject: What does SCO "2 user limit" mean with ODT?
Summary: How to count to 2...?
Keywords: sco odt 2 user limit logins
Date: 13 Apr 92 18:04:45 GMT
Article-I.D.: news.1992Apr13.180445.15776
Distribution: na
Organization: Notre Dame High Energy Physics

How many logins are allowed under SCO-ODT with a 2 user license?
When running X I can indeed utilize other multiscreens but if I attempt
to telnet back from another node I get :

telnetd: Attempt to exceed system login limit.


System V.3.2 UNIX (undpdk.hep.nd.edu) (ttyp00)

Now indeed if I inquire about the number of logins I get:

 12:55pm  up 9 days, 23:31,  2 users,  load average: 5.60, 5.66, 5.36
User     Tty       Login@  Idle   JCPU   PCPU  What
losecco  tty02     1:37pm        95:59         xinit /bin/sh /u/losecco/.startx
losecco  ttyp2     2:15pm  1:29     41     41  telnet undhe9.hep.nd.edu


But the listed telnet session is an outbound one to undhe9.  In fact 2 other
outbound sessions are not listed perhaps because they were started with rcmd
to another workstation.  Still I know I can initiate more than 1 outbound
telnet session.

This has been an annoyance until now but I would like to leave a session runningon the console and be able to log in over internet.  This seems like 2 logins
(not even 2 users since I will use the same uid and gid).

What is wrong?  Have I misunderstood something?  We have other workstations
with a 2 user limit.  For them it means 2 different uid's regardless of
the number of processes.

Thanks for any advice.

-- 
John M. LoSecco			Phone:(219)239-6044          Fax:(219)239-5952
Physics Department		HEPnet/SPAN: UNDHEP::LOSECCO or 47344::LOSECCO
University of Notre Dame		Internet: losecco@undpdk.hep.nd.edu
Notre Dame, Indiana 46556 USA		Bitnet: losecco@undhep
From: dag@atomica.fi (Dag Nygren)
Newsgroups: comp.unix.sysv386
Subject: Re: Interactive and the 486
Keywords: Interactive 486 DX SX EISA ISA
Date: 15 Apr 92 12:55:41 GMT
Organization: Oy Atomica Ab, ESBO, FINLAND

larry@news.rn.com (Larry Snyder) writes:


>few OS's have drivers to take advantage of the enhanced mode on
>the 1742 -- most of them run the 1742 in the 1540 emulation mode
>(which I've been told is slightly slower than a real 1542)

NOT TRUE. The 1740 in emulation mode is 1.5-2.0 times FASTER than
any 1540 or 1542!


-- 
Dag Nygren					email: dag@atomica.fi
Oy Atomica Ab				or     santra!atomica!dag
Box 22 (Ahventie 4A)
02170 Esbo
Newsgroups: comp.unix.sysv386