HDTenEightyP/NetNews huggingface dataset:
From: gemini@geminix.in-berlin.de (Uwe Doering)
Subject: Re: FAS2.10 and fd problems??
Keywords: fas2.10
Organization: Private UNIX Site
Date: Mon, 14 Sep 1992 10:25:19 GMT

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes:

>Has anyone but me seen problems trying to use the floppy disks while
>FAS2.10 is doing a file transfer at high speed? I thought my 3-1/2 drive
>was going bad, but I don't believe that both drives or the FD portions
>of two controllers are all bad.
>
>I hope this isn't the case, but before I take the system down again,
>I'll ask if others are having this problem.

It doesn't happen on my system.

Are you sure that it happens only with serial i/o and not with heavy
hard disk i/o, too? I ask because serial i/o will often cause disk
i/o as well. If you receive data you dump it to disk, and if you
send data, you read it from the disk.

With the Adaptec 1542B there is a problem with concurrent fd i/o
if the BUSON time is higher than 5 usec. I've once set it to 7
on my system and promply got fd errors when there was activity
on the hard disk. After setting BUSON to 5 the problems were gone.

Another reason, especially if you have the problems even in an
interactive dialup session (dialing out with cu etc.), could be
that your 16 bit VGA card interferes with the 8 bit fd DMA channel.
This seems to happen especially with ET4000 cards. The solution
would be to try a different VGA card, or to plug the VGA card into
an 8 bit slot.

     Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Date: 10 Sep 92 17:56:25 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <437@comix.UUCP>, jeffl@comix.UUCP (Jeff Liebermann) writes:

| >right, and the fact that Xenix CONSISTENTLY OUTPERFORMS the bulky, slow,
| >overgrown SVR4 kernel is meaningless ... and if the client is NEVER
| Yep.  The "real" problem with Unix is that it does too much
| for most of my customers.  I guess the price of success is
| bloat and pollution.

  I'm not sure how you measure outperform, so I can't say for sure if I
disagree, but the UNIX compilers produce code which runs faster (for me,
20-30 apps measured) and disk i/o is somewhat faster with the same disk
hardware. Obviously UNIX uses more memory and takes up more disk, but
UNIX runs stuff faster than Xenix, and I'm comparing Xenix to both SCO
UNIX and Dell V.4.

| comix runs SCO Unix 3.2v4.1 with every last patch, sls, app, fix,
| and kludge I can find.  I want to know what it will do BEFORE
| it gets delivered.  The name of the game is uptime and reliability.  
| I rotate the latest vendor supplied cards and drivers through
| it constantly.  The suprises are endless.  The latest 3.2v4 development
| system is now 4 times slower than the 3.2v2 dev sys.  I guess it's
| more "standard" now.  When my one and only developer/customer
| found out, he went into hysterics.

  Now I have to ask, slower by what measure? I haven't found a compiled
program yet that runs more than a percent slower, and have many which
run up to 50% faster using the new SCO compilers. If you mean compile
speed, I'll beg off that issue, since I haven't measured the timings in
that area. But 4X? I think I would notice 4X slower on long compiles, so
I'll state that I don't see that. I would like to see how you got the 4X
number before I agree or not, but I certainly don't see much difference
in a 10K line package with multiple compiles and links.
| 
| Some day, some vendor will produce "Unix Lite" (not Destiny) that's
| designed as a business platform.  I'll be the first in line.
| This is what I hoped SCO would position Xenix, but didn't.

  I suspect that SCO has mixed feelings about Xenix. If they didn't have
to support it they could do lots of other things. If they didn't sell it
they wouldn't be nearly as profitable, I suspect, based on both
estimated sales shown in various magazines and some things SCO people
said at various times, that Xenix brings in at least 1/3 of the profits,
since development costs are almost nil. SCO probably won't confirm this,
and I don't blame them.

  I like Xenix for some apps because it runs nicely on a 2MB machine
(say "notebook").

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.unix.xenix.sco,comp.os.linux,comp.unix.sysv386
From: erc@unislc.uucp (Ed Carp)
Subject: Re: Consensys Powerports
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Fri, 11 Sep 1992 23:58:58 GMT

Rob McAteer (rob@csi.on.ca) wrote:

: Carp Systems International                    Voice: (613) 592-5780

Sorry, I just *had* to followup to this one... :)
-- 
Ed Carp, N7EKG     erc@apple.com                801/538-0177
"This is the final task I will ever give you, and it  goes  on  forever.   Act
happy, feel happy, be happy, without a reason in the world. Then you can love,
and do what you will."           -- Dan Millman, "Way Of The Peaceful Warrior"
Newsgroups: comp.unix.xenix.sco
From: david@dynamix.com (David L Jarvis)
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Organization:  SOFTWARE / DYNAMIX
Date: Wed, 9 Sep 92 17:20:40 EDT
X-Received: by usenet.pa.dec.com; id AA10985; Wed, 9 Sep 92 14:49:13 -0700
X-Received: by inet-gw-2.pa.dec.com; id AA25723; Wed, 9 Sep 92 14:49:11 -0700
X-Received: from dynamix.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)id AA06159; Wed, 9 Sep 92 17:44:51 -0400
X-Received: by dynamix.com (smail2.5c)id AA16672; 9 Sep 92 17:20:41 EDT (Wed)
X-To: comp.unix.xenix.sco.usenet (comp.unix.xenix.sco)
X-In-Reply-To: <Bu6216.8p8@mudos.ann-arbor.mi.us>; from "Marc Unangst" at Sep 6, 92 5:03 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> >So what exactly have you found out there that will work for Unix that won't
> >work for Xenix?
> 
> It's not really an issue of "working" or "not working".  If you have
> the source and are willing to hack on it long enough, you can make
> almost anything work under Xenix.  It's just an issue of how much time
> and effort you're willing to invest.

Shall we forget the fact that much of it is already available for Xenix?
If I remember correctly, this came from someone who said they used Xenix
for a public access BBS, and you argued that they wouldn't have access to
the world of pd software.  So I'm asking, what is it that someone, ANYONE,
might want to put on a public access Xenix BBS that you can't readily find?
(I'm talking *normal* usage here, obviously there are things that can be
found for Unix and not for Xenix, but under normal conditions)
Elm? Smail? Nope, they're both readily available all over the net, as is a
TON of other pd stuff - all Xenix ready.  
I'm not talking about hacking on it long enough - as you put it - 
but rather finding it out there already ported (not hacked) to Xenix?

 

#----------------------------------------------------------------------#
#          David L. Jarvis                 SOFTWARE  /                 #
#          david@dynamix.com                       /  DYNAMIX          #
#----------------------------------------------------------------------#
Newsgroups: comp.unix.xenix.sco
From: hermit@dastari.uucp (Mark Buda)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Date: 9 Sep 92 19:39:56 GMT
Reply-To: hermit%dastari.uucp@devon.lns.pa.us
Organization: Avalon Computing

In article <Bu6Bpp.AG8@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>Sure, you *can* get domain-based e-mail running on a Xenix system, but
>it's an unbelievable amount of trouble to rip out the Xenix e-mail
>system and replace it with your own.

No, it isn't. Grab sendmail and mush, compile, replace. Granted,
sendmail 5.61 needs a whack on the head or two to work under Xenix,
but it works.

And you only need to whack it that one time.
--
Mark Buda

I get my monkeys for nothing and my chimps for free.
Newsgroups: comp.unix.xenix.sco
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: Mailer replacement for Xenix
Date: Tue, 15 Sep 1992 02:55:30 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <1992Sep14.161119.25498@Celestial.COM> bill@Celestial.COM (Bill Campbell) writes:
>I'm glad you told me that Marc!  I've been running smail 2.5 on
>camco for several years now with over 50 connections pumping
>about 5MB of mail traffic every day, and we're the smart-host for
>most of these sites.  I wonder where all the mail has been going!

Well, there's an exception to every rule. :-)

Granted, it *is* possible to do complex e-mail setups with smail2.5,
as you have demonstrated.  However, it has been my experience that
smail3 is easier to port, easier to install, and easier to maintain
than smail2.5.  Many of the parameters that are compiled into smail2.5
are in config files under smail3, which makes it easier to test config
changes and make changes on-the-fly.  smail2.5's aliasing features are
somewhat limited; smail3 implements aliases in one of the
configuration files, which makes the possibilities practically
limitless.

And, as you mention, smail2.5 does not do SMTP.  Note that SMTP !=
Internet; there are some very interesting things you can do with
batched SMTP over a UUCP link.  (Batched & compressed e-mail, anyone?)

-- 
Marc Unangst                | Real men don't use Windows.  Real men use X. 
mju@mudos.ann-arbor.mi.us   | Only a real man would use a GUI where the
                            | shift keys after "Alt" are "Super" and "Hyper."
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Consensys Powerports
Date: 14 Sep 92 15:53:39 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1201@consult.UUCP>, bob@consult.UUCP (Bob Willey CDP) writes:

| One side note: On the Boca's since they are new and not built into
| the SCO stable of "built-in" support, you need to find an address
| scheme that does not conflict with the preset defaults.  We found that
| Address: 240 & IRQ (any high one) like 11, 12  works just great.

  Sounds good to me, and obviously they support the high addresses.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: bill@bilver.uucp (Bill Vermillion)
Subject: Re: '/etc/wtmp' how to control it's size
Organization: W. J. Vermillion - Winter Park, FL
Date: Sat, 5 Sep 1992 01:36:08 GMT

In article <BtyEyJ.HrE@hsi.com> kanakis@hsi.com (Tony Kanakis) writes:

>/etc/wtmp was at 14Mb and filled up the file system.

>Is there any mechanism in place that should control the size of this file?

If you don't need the file, just rm /etc/wtmp.   If the file doesn't
exist it will not be created.

If you need to keep track of logins - I do - just put something in your
cron file like this.


/bin/cp /etc/wtmp /etc/owtmp; cat /dev/null >/etc/wtmp


Set that to execute once a week, or month, or whatever time
period you prefer.

Don't mv /etc/wtmp to /etc/owtmp because the file is opened for writing
and you will be writing to the old file.

-- 
Bill Vermillion - bill@bilver.oau.org  bill.vermillion@oau.org
                - bill@bilver.uucp 
                - ..!{peora|ge-dab|tous|tarpit}!bilver!bill

Newsgroups: comp.unix.xenix.sco
From: chip@chinacat.unicom.com (Chip Rosenthal)
Subject: Re: '/etc/wtmp' how to control it's size
Organization: Unicom Systems Development, Austin, TX
Date: Sat, 05 Sep 1992 23:06:57 GMT

In article <1992Sep5.013608.21192@bilver.uucp>
	bill@bilver.uucp (Bill Vermillion) writes:
>Don't mv /etc/wtmp to /etc/owtmp because the file is opened for writing
>and you will be writing to the old file.

I do not think this is an issue.  The wtmp file is only opened briefly
at the time getty, init, etc. need to log an event.  So, yes, you
introduce a brief subsecond race condition.  However, I can't see
where that would cause any problem unless you are doing some sort of
multi-pass processing of the old wtmp file and there happens to be a
blue moon out this evening.

Further, if you are doing some sort of major processing of the wtmp
file, there is an even bigger problem to this scheme.  By blindly
copying and emptying the wtmp file, you will have wiped out the login
information for current sessions.  That means that tomorrow night when
you generate your reports you won't have any login records for all
the people who were on the system at the time last night's cleanup
was run.  That's a more significant problem.

In theory the right way to handle wtmp file cleaning is to prune out
everything but the few records for the active sessions.  This is much
more complicated to do, and I've yet to run into a situation where I
really needed it.  Further, this is extremely difficult (if not
impossible) to do without introducing race conditions.

So either you aren't doing any fancy processing and the race introduced
by the `mv' is not a problem, or you are doing fancy processing and
in which case there are bigger problems than this one to deal with.

With all that said and done, I pretty much do as Bill suggested.
I think the best scheme would be something along the following:

	>/etc/nwtmp
	chmod 644 /etc/nwtmp
	chown bin /etc/nwtmp
	chgrp bin /etc/nwtmp
	mv /etc/wtmp /etc/owtmp		# race condition opened here
	mv /etc/nwtmp /etc/wtmp		# race condition closed here

-- 
Chip Rosenthal  512-482-8260 | The secret to a long life is
Unicom Systems Development   | knowing when it's time to go.
<chip@chinacat.Unicom.COM>   |  - Michelle Shocked
Newsgroups: comp.unix.xenix.sco
From: bill@bilver.uucp (Bill Vermillion)
Subject: Re: '/etc/wtmp' how to control it's size
Organization: W. J. Vermillion - Winter Park, FL
Date: Sun, 6 Sep 1992 15:12:40 GMT

In article <1992Sep05.230657.7071@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes:
>In article <1992Sep5.013608.21192@bilver.uucp>
>	bill@bilver.uucp (Bill Vermillion) writes:

>>Don't mv /etc/wtmp to /etc/owtmp because the file is opened for writing
>>and you will be writing to the old file.

>I do not think this is an issue.  The wtmp file is only opened briefly
>at the time getty, init, etc. need to log an event.  So, yes, you
>introduce a brief subsecond race condition.  ....

>With all that said and done, I pretty much do as Bill suggested.
>I think the best scheme would be something along the following:

>	>/etc/nwtmp
>	chmod 644 /etc/nwtmp
>	chown bin /etc/nwtmp
>	chgrp bin /etc/nwtmp
>	mv /etc/wtmp /etc/owtmp		# race condition opened here
>	mv /etc/nwtmp /etc/wtmp		# race condition closed here

That's much cleaner. 

I seem to remember on an old system a long timg ago that I had problems
with a system if you moved the wtmp to owtmp and created a new wtmp the
pointer to the location for starting the write was the same as the last
location written in the old file.

So the copy and the >wtmp corrected that problem.  And I honestly don't
remember where/when I had the above problem, or on what machine/OS
version.

Thanks.


Bill

-- 
Bill Vermillion - bill@bilver.oau.org  bill.vermillion@oau.org
                - bill@bilver.uucp 
                - ..!{peora|ge-dab|tous|tarpit}!bilver!bill

Newsgroups: comp.unix.xenix.sco
From: terry@unx.ucc.okstate.edu (Terry J. Klarich)
Subject: Re: Mailer replacement for Xenix
Organization: Oklahoma State University Computer Center
Date: Sun, 13 Sep 1992 02:06:09 GMT

In article <11745@ember.UUCP> pacolley@ember.UUCP (Paul Colley) writes:
>In article <1992Sep10.114323.587@pubnet.com> paul@pubnet.com
>(Paul Telles) writes:
>
>>In article <Bu6Bpp.AG8@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us
>>(Marc Unangst) writes:
>>
>>>Sure, you *can* get domain-based e-mail running on a Xenix system, but
>>>it's an unbelievable amount of trouble to rip out the Xenix e-mail
>>>system and replace it with your own.
>>
>>First of all, you don't 'rip out' the existing SCO mail system...try adding
>>a simple line to /usr/lib/mail/mailrc and installing Smail 3.1/Elm 2.3.
>>

I run a xenix 2.3.3 system at home.  I have used mmdf for about 2 years on my
machine.  I ftped the sources and got it up and running without trouble.  mmdf
and mh makes for a nice mail system.

Terry
-- 
Terry Klarich (ki5zw)
Oklahoma State University Computer Center
Stillwater Oklahoma
Newsgroups: comp.unix.xenix.sco
From: david@dynamix.com (David L Jarvis)
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Organization:  SOFTWARE / DYNAMIX
Date: Sun, 6 Sep 92 10:59:25 EDT
X-Received: by usenet.pa.dec.com; id AA06568; Sun, 6 Sep 92 08:39:04 -0700
X-Received: by inet-gw-2.pa.dec.com; id AA11888; Sun, 6 Sep 92 08:39:02 -0700
X-Received: from dynamix.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)id AA24405; Sun, 6 Sep 92 11:35:55 -0400
X-Received: by dynamix.com (smail2.5c)id AA05592; 6 Sep 92 10:59:25 EDT (Sun)
X-To: comp.unix.xenix.sco.usenet (comp.unix.xenix.sco)
X-In-Reply-To: <1992Sep3.144328.25278@compu.com>; from "Fred Rump from home" at Sep 3, 92 2:43 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> Hey, give the guy credit. I wish I had a few highschool students with that 
> kind of spunk and writing ability here. Most I've met recently have a tough 
> time putting a paragraph together. Marc must be working for a friend of mine 
> up there in MI. Lucky guy!

Well Fred, if writing ability and spunkiness are your primary concern, then
I wish you all the Marc's you can handle ... here we look for people who
can correctly identify the clients' needs, and engineer the best possible
solution for the client - regardless of market hype and all the
irrelevancies that the computer industry confuses people with ...


#----------------------------------------------------------------------#
#          David L. Jarvis                 SOFTWARE  /                 #
#          david@dynamix.com                       /  DYNAMIX          #
#----------------------------------------------------------------------#
Newsgroups: comp.unix.xenix.sco
From: bill@bilver.uucp (Bill Vermillion)
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Organization: W. J. Vermillion - Winter Park, FL
Date: Mon, 7 Sep 1992 02:24:08 GMT

In article <9209061050.AA05570@dynamix.com> david@dynamix.com (David L Jarvis) writes:
>> So what are the "good reasons" to drop Xenix/286 support?  As far as I

>How about all those segmentation violations that arose from the 286 not
>having hardware memory protection?  The 286 was a bastardized 186, and both
>were brain-dead.  My opinions are based on the hardware, not the OS.
>But again, this is a digression.

Segmentation Violations!   Well I was working on a machine that kept
getting them.   Running Unix V.3.2 on a WE 32100 chip.  AT&T 3B series.
We couldn't figure it out, and AT&T finally went back to their code,
and it wasn't their either.

Turns out one of the application programs (fairly popular in the small
Xenix/Unix systems market, but left unamed) was responsible.

When AT&T said it wasn't their, we got tech support from the software
vendor.

Their conversation was something like this -

"Segmentation Violation - yes that's the error we print whenever we
can't figure out what the real error is".

Gimme a break!!!

-- 
Bill Vermillion - bill@bilver.oau.org  bill.vermillion@oau.org
                - bill@bilver.uucp 
                - ..!{peora|ge-dab|tous|tarpit}!bilver!bill

Newsgroups: comp.unix.xenix.sco
From: paul@pubnet.com (Paul Telles)
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Organization: PUBNET Communications Services
Date: Thu, 10 Sep 1992 11:43:23 GMT
Followup-To: /dev/null
Summary: Yeah, yeah, yeah, yeah......

In article <Bu6Bpp.AG8@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
[....]
>That's not the point.  We could all go run BSD/386 instead of SCO, or
>replace our entire /bin and /usr/bin with the GNU equivalents.
>Sure, you *can* get domain-based e-mail running on a Xenix system, but
>it's an unbelievable amount of trouble to rip out the Xenix e-mail
>system and replace it with your own.
[....]

First of all, you don't 'rip out' the existing SCO mail system...try adding
a simple line to /usr/lib/mail/mailrc and installing Smail 3.1/Elm 2.3.

The SCO binaries will co-exists peacefully and the original /usr/bin/mail
will continue to function, so Elm 2.3 is optional.  None of this is
time consuming or troublesome, assuming *you* are competent.  You have
consistently exaggerated all points, including this one.

[....]
>Yes, Unix is better than Xenix because it's the same as other
>Unix-based products.  Again, we're coming back the standards argument.
[....]

In your not so humble opinion.  UNIX is a pretty broad term in this day and
age.  Rather than address this comparison, let me say this...  The argument
is equivocal.  It is subject to too many interpretations.  It could be
applied to any two operating systems.  SCO UNIX vs. ISC UNIX, etc. etc. etc.

This thread has become tiresome.  It's ran its course.  If you would like
to pursue further avenues of pointless discussion, may I suggest an
attempt to convince the readers of comp.unix.bsd that SCO UNIX is superior
to BSD...don't let the door hit you on the way out.  :)

[....]
>The primary reason a lot of our customers use Unix on PCs is because
>it interoperates well with their other Unix machines.  Xenix *may* be
>appropriate if interoperability is not and never will be a concern,
>but I don't believe *anyone* can say that in this day and age.
[....]

Unless your complete interpretation of 'interoperability' is NFS, then the
above statement is completely false.  Assuming that NFS is not one of the
requirements of the given host, XENIX is quite capable of being a
productive part of any TCP/IP, X.25, Vines, or Novell network.

[....]
>Marc Unangst                | Real men don't use Windows.  Real men use X. 
>mju@mudos.ann-arbor.mi.us   | Only a real man would use a GUI where the
>                            | shift keys after "Alt" are "Super" and "Hyper."
-- 
Paul Telles, PUBNET, Honolulu, HI - paul@pubnet.com - 0004002682@mcimail.com
"UNIX is a simple, coherent system that pushes a few good ideas and models to
the limit." D. Ritchie, Communications of the ACM, Vol. 27, No. 8, August 1984
Newsgroups: comp.unix.xenix.sco