Subject: Linux-Misc Digest #925
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Wed, 12 Oct 94 22:13:27 EDT

Linux-Misc Digest #925, Volume #2                Wed, 12 Oct 94 22:13:27 EDT

Contents:
  Information on Linux (Manish Desai)
  Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Steve Kneizys)
  Re: getting linux to work dail-up (Hugh Emberson)
  Re: getting linux to work dail-up (Carlos Irigaray)
  Linux's future support for ATA/IDE development thoughts... (George Shin)
  Re: Mystery Chip...AMD (H. Peter Anvin)
  Re: Mystery Chip...AMD (Jeff Kesselman)
  [Q] Best PCI video card for XFree86 3.1 and Linux (Jeffrey Lessem)
  Re: Word (Text) processors for Linux? (Steve Dunham)
  Re: Is linux a multithreaded operating system? (Jeff Kesselman)
  Re: Weakest Linux Box (H.J. Lu)
  Re: SW Technologies (Tim Bass (Network Systems Engineer))
  Help with suck+++.tar.gz (Ian Colquhoun)

----------------------------------------------------------------------------

From: manish@.chem.uh.edu (Manish Desai)
Subject: Information on Linux
Date: 12 Oct 1994 03:29:32 GMT

Hi,

   I am trying to set up a linux box as a backup server. I have gone through
the most of the docs. available on net. Now I would like to know the 
experience of anyone who is running linux in a networked environment with 
all or one of the following demons/servers.
1) Named
2) bootp
3) NSF
4) gopher server and
5) Mosaic server

  the configuration of the system will be a 486DX/50 MHz processor with local
bus arch. It will have 16Mb of RAM with 210 MB of Harddisk (IDE). Also I want 
to mount 1 GB hard disk from a IBM RS6000 running AIX running 3.0. 
The ethernet card will be eitherNE2000 or from HP .

    In particular I will like to know response time , reliability etc. Please
let me know if the above configuration is ok or not.

Please reply to [email-masked].

Thanks in advance,
Manish Desai.

------------------------------

Crossposted-To: comp.os.linux.help,comp.os.linux.development
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
From: [email-masked] (Steve Kneizys)
Date: 7 Oct 94 22:11:57 EST

Yuri Trifanov ([email-masked]) wrote:

: > We are using SLIP!  And the problems we see are not *after* a connection
: > is successfully opened, it is one of the system *refusing* connections
: > (apparently).  Nearly all functions handled by inetd seem affected: 
: > telnet logins, rlogins, ftp attempts, smail connections, attemps to do
: > zone transfers from named by our provider's router, you name it.  Things
: > work fine *most* of the time, but the login problems are the most
: > persistant and visible.  In those cases, the system log *usually* shows
: > 'connect from...' but the user never gets a prompt, or never gets a
: > password prompt after entering username.  Netd entries in the log are
: > 'connection refused' mostly. 

:  you could be having problems with the resolver and tcpd, which comes
: turned on by default in at least some distributions. if it can't
: resolve the inaddr of the connecting host it will refuse the
: connection.

I see the freeze and I only use Etherlink III 3c579 cards on the same
wire as 3 VAXes, including our domain's name resolver.  Telnets from
the domain resolver VAX to the Linux freeze, as does FTP, finger,
smtp, rlogin.

Steve...

------------------------------

From: [email-masked] (Hugh Emberson)
Crossposted-To: alt.os.linux,comp.os.linux.help
Subject: Re: getting linux to work dail-up
Date: 11 Oct 1994 04:58:44 GMT

>>>>> "Carlos" == Carlos Irigaray <[email-masked]> writes:

Carlos> ttyS2 stands for com3 (under DOS) and is for incoming calls
Carlos> (difference between cua2 and ttyS2)

This is becoming a urban legend :-) I used to believe this and it
caused lots of trouble.  You can and should use ttyS? for dialin and
dialout.  From the mgetty+sendfax docs (by Gert Doering):

       *Important note:* Use the `/dev/ttyS*' devices for getty and
    for dial-out (that is, for kermit, uucico, cu, seyon, ...) -
    *never* use `/dev/cua*'. Dialing out on `/dev/cua*' will result in
    the error message "device busy". (There are reasons why `mgetty'
    cannot use the "`ttyS*' vs. `cua*' kernel locking mechanism", see
    below), and dialing in (ugh) on `/dev/cua*' will result in dozens
    of strange things happening because the process won't get a
    controlling tty.
        
       Some guys seemingly can't resist posting misinformation to the
    net all the time, don't believe 'em. The `/dev/cua*' devices are
    *not* different from the `/dev/ttyS*' devices concerning data flow
    or modem control lines. The only difference is how the device
    reacts if you do an `open()': Opening `/dev/ttyS*' normally blocks
    until the "carier detect" line goes active (unless `open()' is
    called with the `O_NDELAY' flag; `mgetty' and all dial-out
    programs do that), and opening `/dev/cua*' will return an error
    message (`errno=EBUSY') if another process has the device already
    open, thus *preventing dial-out on `/dev/cua*'* if `mgetty' is
    active on `/dev/ttyS*'.
    
       We use `/dev/ttyS*' all the time for dial-in *and* for
    dial-out, and believe me, it works, and it's the *only*
    combination that will work properly. The kernel locking mechanism
    only works if you use modem auto-answer (the getty process sleeps
    until the modem gets a carrier), and mgetty uses manual answer (it
    waits for the RING message from the modem), which will save your
    callers a lot of grief because their calls will only be answered
    if your computer is ready to receive a call. Part of the
    motivation for writing mgetty was being tired of losing lots of
    money for useless calls to a hung machine.
    
BTW I can't recommend mgetty+sendfax highly enough.  Its excellent.

Cheers,
        Hugh
-- 
Hugh Emberson              | ... from the end of the Information 
[email-masked] | Super-four-wheel-drive-track.

------------------------------

From: [email-masked] (Carlos Irigaray)
Crossposted-To: alt.os.linux,comp.os.linux.help
Subject: Re: getting linux to work dail-up
Date: 9 Oct 1994 01:03:00 -0400

Jacob Zielinski ([email-masked]) wrote:
: Has anyone be able to hook their modem up so that you can dail into linux?

: The people on #linux suggested agetty, and mgetty. But I didn't get to far
: with those to commands. Could somebody who as done this explain how or at
: least point me toward some docs.

The best is to use uugetty or mgetty. You have to add to your 
/etc/inittab file the following line (as an example):

s1:45:respawn:/sbin/uugetty ttyS2 9600

ttyS2 stands for com3 (under DOS) and is for incoming calls (difference 
between cua2 and ttyS2)

ttyS0 for com1
ttyS1 for com2 and so on....

9600 is a label corresponding to an entry on the /etc/gettydefs file.

After, you should create a file called uugetty.ttyS2 (under /etc/defaults)
with the following lines:

INITLINE=cua2
WAITFOR=RING
CONNECT="" ATA\r CONNECT\s\A
DELAY=1
 
and that's it.

For more information read the man pages for getty. uugetty is at the end 
of the manual.

Note: I put ttyS2 and cua2 as an example. Your configuration might be 
different.

Hope this helps!

 ____________________________________________________________
|                                                            |
| Carlos Irigaray - [email-masked] - [email-masked] |
|                                                            |
|____________________________________________________________|

------------------------------

Crossposted-To: comp.os.linux.development,comp.os.linux.help
From: [email-masked] (George Shin)
Subject: Linux's future support for ATA/IDE development thoughts...
Date: Tue, 11 Oct 1994 04:52:34 GMT

Hello Linux net-folks,

I've been following pretty closely on some of the discussions relating
to Enhenced IDE/Fast ATA topic and would like to maybe continue on
to see how it's and will effect Linux support for ATA drives. I don't
intend to do all at one shot so here goes the first two attempts...

But first some base-line terminology so we start out at the same ground:

I would like to use the term ATA rather than IDE since to me even SCSI
drives are candidate for IDE. Also, i tend to talk register mode
versus BIOS support when interfacing to the drive, i.e. direct I/O port
programming against BIOS ISR provider. Finally, if i may i would like
to include DIOW-/DIOR- interface signals when discussing various PIO
timing modes.  Oh, BTW at the host-end i tend to call the drive card,
host adapter card (HAC) whereas most people use the terminlogy of 
controller card.  Most ATA HAC's are pretty much "brainless" and does 
nothing but data buffering in between the host and the target drive.

Well, i'm not an expert in ATA drive land, however getting lot's of
practice at the work so maybe share some information with fellow 
Linux'ers and get plenty of feedbacks hopefully.  I've been funning
Linux for quite some time starting with ATA drives then with all
the advantage with SCSI, now am running Linux entirely from 1GB SCSI
drive.  However following thoughts come to me when thinking about
ATA drives + Linux:

1. Since ATA-2 spec is on its way of being finallized we'll expect to
   see more drives with support for fast PIO timing modes especially
   PIO mode 3 and yes, PIO mode 4.  For user to take advantage of these
   high speed data transfer rate one would need local-bus (VLB or PCI)
   ATA HAC that can strobe DIOW-/DIOR- at that frequencies.  Most if
   not all have special on-board ATA interface chip that's capable of
   interfacing at that high speed as well as BIOS extension or
   installable device drivers.  At very minimum these BIOS or device
   drivers will initialize various timing registers of interface chip
   to talk at that high data rate of ATA interface.  My concern is that
   since Linux is doing all ATA talking at non-BIOS, register level
   will this have to be changed later when supporting specific high-speed
   ATA HAC's?  I've done some measurement at work and having these
   cards power up and doing all register level drive access there after
   will NOT produce fast transfer.

   Looks as though these BIOS/driver routines have some special code
   besides your average "rep outsw" and "rep insw" instructions. So does
   this mean Linux now has to support specific ATA HAC's???  I guess
   days of generic ATA interface talking is over then...

2. ATA-2 has announced additional I/O ports for 2 more HAC's besides your
   current primary and secondary.  This results to total of 8 ATA drives
   under PC.  Any interest in supporting this under Linux... Hmmm, maybe
   i should get involved in this... I can't recall whether IRQ's are also
   defined or suggested...

- george

PS How do you REALLY know that your high-speed 1GB ATA drive is doing PIO3 or
   PIO4??? You REALLY don't unless...

PSS BTW, check out ftp://fission.dt.wdc.com's /pub/ata and /pub/standards for
    ATA/SCSI papers...  These really make very good bed-time readings... :-)

------------------------------

Crossposted-To: comp.sys.ibm.pc.hardware.systems,comp.os.linux.admin
From: [email-masked] (H. Peter Anvin)
Subject: Re: Mystery Chip...AMD
Reply-To: [email-masked] (H. Peter Anvin)
Date: Sun, 9 Oct 1994 07:20:02 GMT

Followup to:  <[email-masked]>
By author:    [email-masked] (Daniel Zappala)
In newsgroup: comp.os.linux.admin
> 
> But doesn't Intel sell a chip that upgrades a 486DX-33 into a 486DX2-66?
> How do they manage that?
> 

It's just a 486DX2-66 with a 487 pinout that fits in a 487 socket.  It
switches off the DX-33, so if you keep it in the system it is only
going to sit there like a heating pad.

It was part of an Intel scheme to sell these "upgrade" parts without
causing a messy aftermarket of used DX-33 chips, which might affect
profit margins.  Fortunately, both consumers and MB manufacturers
rejected this as an expensive ploy and waste of MB space.  However, if
you buy an "Overdrive" chip from Intel, make sure to get the one with
the right pinout (486 or 487).  Of course, the 487 itself is just a DX
chip with different pinout.

Conclusion: Intel marketing sucks.

        /hpa

-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
Keyboard not found, press F1 to continue

------------------------------

Crossposted-To: comp.sys.ibm.pc.hardware.systems,comp.os.linux.admin
From: [email-masked] (Jeff Kesselman)
Subject: Re: Mystery Chip...AMD
Date: Sun, 9 Oct 1994 06:13:34 GMT

In article <[email-masked]>,
 <[email-masked]> wrote:
>> 
>> I have an AMD 486DX-40.  Any news on an add-in from AMD to turn this into a
>> 486DX2-80, or do I need to buy a whole new chip?
>> 
>> Daniel
>
>Yes you have to buy a WHOLE new chip.
>

I'm DYING to know what the original poster meant  by this?  How would you 
ADD-IN to a sealed piece of silicon?????

Could you explain please?

JK

------------------------------

From: [email-masked] (Jeffrey Lessem)
Crossposted-To: comp.windows.x.i386unix
Subject: [Q] Best PCI video card for XFree86 3.1 and Linux
Date: 9 Oct 1994 07:27:18 GMT

Now that XFree86 3.1 has been out for a week, I would like to get
people's opinions on what would be the best PCI video card to get for
running X under Linux.  Currently I am using an ATI 8514 Ultra, and
the Mach8 drivers seem to work flawlessly, the performance is good,
but because this card has no VGA I am forced to use another card for
text screens etc., and requiring two ISA slots to run video is severly
limiting my options in upgrading.

I don't want to spend much more than $200, and I certainly don't want
to take a performance/stability hit.  The cheapest cards appear to be
the ET4000/W32p based ones.  I have seen some people reporting
problems with performance and pallet corruption, is this a server
problem, or just bad configurations?  What about the S3 based cards,
many of these are available relatively cheap, how stable is the X
server for those?  I know the Mach64 is not supported yet, but how
well do Mach32 based cards work?

I would be running the card at 1024x768x8, and would like the ability
to go to 800x600x16 or 24.  If I can do 1024x768x16+ for $200 please
let me know about it.  I am not interested in top of the line
performance, right now if I cat termcap it scrolls too fast to read,
and opaque window move works well, if opaque window move worked very
well on the new card I would be happy.

Thanks, if I get enough responses I'll summarize.

------------------------------

From: [email-masked] (Steve Dunham)
Crossposted-To: comp.unix.questions
Subject: Re: Word (Text) processors for Linux?
Date: 12 Oct 1994 20:59:38 GMT

Richard L. Goerwitz ([email-masked]) wrote:

: This is lovely news, but if it's the same news as I've heard, what we have
: here is not an internationalized/multilingual product, but rather one that
: has been hacked to include support for a language here and there.  So, for
: instance, things I do easily every day with MLS (or could with Nisus) on
: micros, I could not do with TeX.  This includes quoting Greek, Hebrew, Eng-
: lish, Arabic, etc. in the same document.  I believe that some versions of
: TeX do Hebrew/Arabic and English; others might do Greek and English.  The
: model here, though, is not that of a multilingual product.

: I really hope that the info I have is wrong.  Please correct me if it is.

You're wrong.  You can easily combine hebrew, arabic, english,,
classical greek, devenagari, aramaic, ... with TeX.  
  There is an extension to the TeX program proper which is called
Tex-Xet.  It is easy to apply the patch when you install TeX.  It
takes away no funtionality and adds on command which switches the
direction of text, making the macros for hebrew/arabic a lot cleaner.
It also adds a command to the DVI format but (1) many dvi printers
support it, and (2) there is a program which will change the dvi into
one which everything supports.  The modified TeX is commpletely
backwards compatible.
  In fact, TeX will allow you to use multiple hyphenation tables and
switch between them in the middle of your document.

Steve
[email-masked]

(I like TeX, but I would like to see a front end that allows me to see
my equations and Russian/Greek/Fraktur fonts on the screen while I am
typing.)

------------------------------

From: [email-masked] (Jeff Kesselman)
Subject: Re: Is linux a multithreaded operating system?
Date: Tue, 11 Oct 1994 05:15:16 GMT

In article <[email-masked]>,
David Barr <[email-masked]> wrote:
>In article <[email-masked]>,
>Jeff Kesselman <[email-masked]> wrote:
>>So yes, UNIX is multi-threaded in the sens that there are multiple threads
>>of control operating in a time-sliced fashion.  The term 'threading' is
>>often used in multi-tasking system however to denote a 'lesser form' of
>>multi-taskign that goes on completely within a single process.
>
>Not quite.  Most UNIXes (including Linux) are not multi-threaded at all.
>
>Multi-tasking is simply multiple "tasks" (call them threads, call them
>processes, it doesn't matter) executing simultaneously.  Traditionally,
>the smallest schedule-able "task" is a process.  If you want two
>things to be able to execute simultaneously, you make two processes.
>
>Multi-threading extends this such that you can have multiple threads
>per process, and each thread can be scheduled on its own.  If one
>thread in a process performs a read() and has to wait, other threads
>can continue executing.

Pardon? Thats what I said, I believe, if you read the whole post.  I 
don't see that your read() is relevent, however.  As long as your kernel 
is not single-tasking and blocking (as opposed to waiting, an example of 
such a blocking kernel is OS-9) then you shoudl be able to process eitehr 
in another thread OR another process.

>
>The difference between a "thread" and a "process" in a multi-threaded
>system is that a "thread" shares the same address space as other
>threads in the same process.  With processes, in order to share memory,
>you need to use something like the SYSV shm*() family of syscalls.
>
>>thsi is
>>also sometimes called 'light-weight multi-tasking'.  UNIX (and Linux)
>
>I think you're thinking of what Sun calls "light weight processes",
>which is a hokey pseudo-threaded system for non-multithreading kernels.
>Under LWP, system calls in one thread block all threads in the process
>from executing.

No, actually, I was thinking about the BSD calls on the VAX (I mentioend 
BSD, though I may not have netioend the VAX) and what Modula2 does 
inhearently (as I also mentioned.)

>
>There are thread libraries for Linux (pthreads) that will allow this
>sort of multithreading for Linux, but don't confuse that with a
>multithreading operating system.  (Like Solaris)  These are called
>"user-level" threads, and are not nearly as useful as one with
>a kernel that supports threads.  (and if your kernel supports real
>threads, you can compile the pthread library to do real threading)
>
>--Dave

This blocking business is an implementation detail. I don't think its a 
terminology issue.  This whole discussion goes to illustrate my OTHER 
point (deleted) that the terms thread, task and process are often used in 
different ways.  The whole area of terminology is muddied, this is 
PARTICULARLY true when referrign to 'threads'.

JK

------------------------------

From: [email-masked] (H.J. Lu)
Subject: Re: Weakest Linux Box
Date: 12 Oct 1994 18:10:52 GMT

In article <[email-masked]>, [email-masked] (Linux Mac Daddy) writes:
|> I was just wondering who has the weakest Linux box?  What I mean by this 
|> is like anyone running Linux on a 386 with 3 megs of RAM...  I've got a 
|> 386sx-16 with 5 megs of RAM and it works great (tons faster than DOS).  
|> If anyone has a "weaker" machine that runs Linux (and you actually use 
|> it) let's hear it....
|> 

386sx/16 with 4 MB RAM. I am trying to upgrade and waiting for the price
to drop :-(.

H.J.

|> ------------------------------------------------------------------------
|> Slam Foot Neck!  Ride the wave.  Touch Touch Touch.  I'm cereal.
|> Internet: [email-masked]
|>    Bilbo: 137.112.200.75
|>   o__           o__           o__           o__           o__
|>   ,>/'_         ,>/'_         ,>/'_         ,>/'_         ,>/'_ 
|>  (_)\(_)       (_)\(_)       (_)\(_)       (_)\(_)       (_)\(_)

------------------------------

From: [email-masked] (Tim Bass (Network Systems Engineer))
Subject: Re: SW Technologies
Date: 12 Oct 1994 21:41:40 GMT

Jonathan I. Kamens ([email-masked]) wrote:

: All these insults are very nice, Bob, but they don't answer Jeff's question --
: "The question I am left with here is DOES Bob feel Mr. Wu acted improperly in
: bouncing this refund check, and not as a repsonsible vendor? Comments , Bob?"
              --------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^ ????

Well if you consider this to be NOT RESPONSIBLE then....

Selling merchandise at the lowest possible cost,
Having very little profit margin,
Working to insure linux runs on the platform,
Trying hard to please every customer.

THEN

: Well, Bob?  Comments?
: -- 
: Jonathan Kamens  |  OpenVision Technologies, Inc.  |   [email-masked]

------------------------------

From: [email-masked] (Ian Colquhoun)
Subject: Help with suck+++.tar.gz
Date: 12 Oct 1994 02:42:25 GMT

I downloaded suck+++.tar.gz from sunsite but I can't seem to get it to 
compile properly on my system.  It complains of improper pointer type to 
getbyhostaddr, finishes and does create an executable but when I try to 
run it it says Segmentation Fault.

Has anyone got this program to compile on their system or knows of 
another similar program to 'suck' news easily via NNTP?

Ian
[email-masked]

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Misc Digest
******************************