Subject: Linux-Misc Digest #609
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Mon, 15 Aug 94 00:13:12 EDT

Linux-Misc Digest #609, Volume #2                Mon, 15 Aug 94 00:13:12 EDT

Contents:
  Re: XON/XOFF (again) and "efax" HELP!!!! (Jamie Honan)
  TAMU (Daniel Golembiewski)
  Re: source of TCP/IP (was I hope this wont ignite a major flame ...) (Mark Newton)
  Re: comp.os.linux.hardware.* (Steffen W. Schilke)
  Suggestions on PCI or VESA video cards for use w/ XFree? (Ken Mcdonald)
  Re: CD-ROM vs Tape Distribution (was Re: Coherent & Linux  ...) (Rick Kelly)
  Re: WABI vs. SoftWindows? (Rick Kelly)
  Re: Multi-threaded linux-kernel (Brandon S. Allbery)
  color_xterm bug (Cheng-Tang Lee)
  Re: starting X automatically on installing linux distribution (Beverly J. Brown)
  Re: Linux & parallel tape bkup? (Senthil R. Kumar)
  Menu-oriented shell for dial-in users? (Serge Solski u)
  Re: Term Errors (Christopher Wiles)
  Re: WABI vs. SoftWindows? (Brandon S. Allbery)

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

From: jhonan@jolt.mpx.com.au (Jamie Honan)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: Re: XON/XOFF (again) and "efax" HELP!!!!
Date: 14 Aug 1994 22:24:46 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <32ea0d$jm8@inferno.mpx.com.au> jhonan@jolt.mpx.com.au (Jamie Honan) writes:

: >BTW, 1.1.42 (for me) excercises a limitation in efax. My modem
: >has large buffer sizes, and I suspect more data is being buffered
: >in the serial driver than previously. The author of efax is on holidays, so
: >I am taking the liberty of posting a small diff here, in case others
: >face a smilar problem. It is more noticable when connecting to fax devices
: >operating at low speeds (2400 and 4800 bps devices).

: >The author has assumed a maximum fixed time for the flushing of output data.
: >My patches are to simply calculate what that time should be more accurately.

: Indeed the new drivers buffer more data on output, I have also seen this
: with another application.
: However, the fix for this should IMHO not involve tricky timing.  You can
: wait for all data being physically sent to the serial port using a
: tcdrain(fd), and you will not be dependent on tricky timing issues.

I'd wholeheartedly agree, if you could be sure of the buffer size
of the modem.

The transmission timing in fax is based on the negotiated bit rate, 
independant of the interface rate between the modem and the serial port.

The author took a punt on 4K as being the buffer size. A modem could
equally have 20K. (most don't, simply because WinFax makes the same
assumptions)

Jamie


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

From: ddgole@unix1.circ.gwu.edu (Daniel Golembiewski)
Subject: TAMU
Date: 14 Aug 1994 18:52:42 -0400

Currently running TAMU/Linux with X.  All is fine except get a broken
pipe message when properly shutting down X and returning to Linux
command prompt.  Can anyone suggest how to correct this.  Otherwise
everything is working fine.  Thanks in advance.




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

From: newton@cleese.apana.org.au (Mark Newton)
Crossposted-To: comp.os.386bsd.misc
Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...)
Date: 13 Aug 1994 20:59:33 +0930

In article <Cu2oow.JHn@boulder.parcplace.com>, Warner Losh (imp@boulder.parcplace.com) wrote:

 > Linux does a great job at what it does, but some parts of it are icky
 > to look at.  Kinda like the plumbing in my house.


My FreeBSD plumbing is better than your Linux plumbing! 

   - mark
     [ grinning, ducking and running ]
-- 
====================================================================
I tried an internal modem,                newton@cleese.apana.org.au
     but it hurt when I walked.                          Mark Newton
===== Voice: +61=8=3735575 =============== Data: +61=8=3736006 =====

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

Crossposted-To: comp.os.linux.help
From: sws@tora.RoBIN.de (Steffen W. Schilke)
Subject: Re: comp.os.linux.hardware.*
Date: Sat, 13 Aug 1994 21:32:03 GMT

Bill Hogan (bhogan@crl.com) wrote:
: Dave Sill (de5@de5.CTD.ORNL.GOV) wrote:
: : I'm fairly new to Linux and the Linux newsgroups, so pardon me if I'm out
: : of line.

: : I've found it pretty hard to find answers to the kind of questions I have,
: : which are mostly about hardware compatibility.  Do they belong in
: : comp.os.linux.help?  How about comp.os.linux.misc?  For that matter,
: : exactly what is appropriate for these two groups?

: : Anyway, I propose an organization orthogonal to the
: : comp.sys.ibmpc.hardware.* hierarchy, e.g.:

: :     comp.os.linux.hardware.systems
: :     Which PC's do/don't run Linux.  What tweaks are required.  Will
: :     also cover other architectures if/when Linux is ported to
: :     them. ...

:  [...]

: : And the c.o.l.help and c.o.l.misc groups are just too busy to keep up
: : with.

: : What do you think?

: : -- 

:   I would like to see the following (in alphabetical order):

:       comp.os.linux.admin
:       comp.os.linux.announce
:       comp.os.linux.applications      (looks to "world outside")
:       comp.os.linus.beginners         (formerly 'comp.os.linux.help')
:       comp,os.linux.development       (operating system per se)
:       comp.os.linux.hardware          (new)
:       comp.os.linus.misc

:   I think the label 'comp.os.linux.help' is redundant; I believe that all
: of these groups are basically 'help' groups simply because they are places
: where people help each other. 

:   Bill
: -- 
:   Bill Hogan
: {echo "Subject: get bhogan@crl.com" | mail pgp-public-keys@pgp.mit.edu}

What a bout a group called comp.os.linux.kernel-problems or 
comp.os.linux.help.kernel ? A pain relief against "kernel of
the day" problems ;-)

--
[Standard Disclaimer] in addition I would like to speak with my lawyer ....
S. Schilke; PoBox 1213; 61102 Bad Vilbel; Germany  a.k.a  sws@tora.RoBIN.de
                  Sokonoke Sokonoke tora-sama ga touru
$@%9%F%U%'%s(J  $@CN2H!Z%7%k%1![(J  $@$=$3$N$1$=$3$N$18WMM$,DL$k(J
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

From: mcdonald@cs.sfu.ca (Ken Mcdonald)
Subject: Suggestions on PCI or VESA video cards for use w/ XFree?
Date: Mon, 15 Aug 1994 00:04:44 GMT


Well, after downloading the most recent FAQ's and deciphering them to the
extent of my ability . . .

. . . I am still confused :-)

I have a PCI-Pentium system coming in, and need to purchase a video card
with which I can run XFree.  While I have numbers for various chipsets which
work (from the XFree FAQ), I have no way of correlating these numbers with
actual video cards.  As well, I'm having a hard time finding many of the
video cards--for example, the ATI Mach 32 has its own XFree server, but
can I find it for sale in the Computer Shopper?  I suspect, but don't know,
that this is a low-cost card, and only the high-cost cards are being
advertised.  Finally, I have no idea what PCI means in terms of getting
XFree running.

What I'd really love are the names of some good, reasonably priced PCI (or
VESA, if necessary) video cards which will work nicely with XFree and also
give decent Windows performance.  If anyone else has a PCI system from
Quantex (where my system is on order), and can report a good video board
result, I'd be very happy to hear from them.  (The standard board with
the system I ordered is a 64-bit board which I will have to return, I think,
as my understanding is that NO 64-bit boards currently work with XFree.)
Since I'm not a multimedia fanatic, I don't have need for a real barnburner
of a board.

Thanks in advance for all the help,
Ken McDonald
mcdonald@cs.sfu.ca

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

Crossposted-To: comp.os.coherent
From: rmk@rmkhome.com (Rick Kelly)
Subject: Re: CD-ROM vs Tape Distribution (was Re: Coherent & Linux  ...)
Reply-To: rmk@rmkhome.com (Rick Kelly)
Date: Sun, 14 Aug 1994 20:10:42 GMT

Tom Oehser (toehser@cais.cais.com) wrote:
: >>>Every UNIX box has a tape drive.

: Yeah, ok, would you rather distribute a cdrom- or 5 kinds of DAT
: and 4 kinds of QIC and this and that.  Most unix boxes have some
: kind of tape backup.  Lots of them are 9-track.  There must be
: 50 different incompatible formats.  I don't think it will fly.

I work in an environment that has systems from about 150 different UNIX
vendors.  About 90% of them use QIC 150 tape cartridges to load the OS.

Sun and SGI seem to be pushing CD-ROM media now.  The Sun systems that end
up on developers desks are loaded from CD in a "setup" room where there is
exactly one CD-ROM drive.

One system, a Pyramid, uses 9 track tape.  Most of the DEC systems use
TKxx tape drives or have a built in CD drive.

: >CD-ROM is nice, but if I had to choose CD or Tape I'd take the Tape.  At
: >least you can back up your box.  Also with a tape distribution it's
: >easier to make a COPY of your distribution.  Someone cracks your

: Why?  You can copy CDROM to tape.  Tape distribution only makes sense
: on a 370 type box where *everyone* has a 3480 36 track tape driver.

A tape of a CD-ROM isn't much use if the installation scripts were
written with the assumption that the software is on a mountable
partition.





-- 

Rick Kelly  rmk@rmkhome.com  rmk@bedford.progress.com

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

From: rmk@rmkhome.com (Rick Kelly)
Subject: Re: WABI vs. SoftWindows?
Reply-To: rmk@rmkhome.com (Rick Kelly)
Date: Sun, 14 Aug 1994 23:08:23 GMT

Brandon S. Allbery (bsa@kf8nh.wariat.org) wrote:
: Let me tell you folks a little story.

: I am currently working with a client who has an SCO system with a database
: application on it.  *The* database application:  order processing, production,
: invoicing, A/R, A/P, G/L.  Downtime for this application means the company is
: effectively stopped.

Whose RDBMS are you using?  

: And SCO just stuck their tails in a crack twice in a row.  One was solved by a
: patch from the database vendor to get around an acknowledged OS bug.  (I
: brought the program home and tried it under the Linux iBCS2 emulator and it
: worked.  Under SCO it dropped core.)  The other was worked around by taking a
: hit on system capacity.

It's an SCO bug, but QA testing by the RDBMS vendor ought to be finding
showstoppers before the project is shipped.

: I briefly considered --- especially after the abovementioned test --- solving
: the problems once and for all by removing SCO and installing Linux.  But in
: fact it is *not* ready, as I have already acknowledged.

Yup.  You'd better be sure that semaphores and shared memory are hard as
a rock robust.

: But the writing is on the wall.  We slammed headlong into two OS bugs in a
: row; the client is shaken but unhurt as yet, but they're not shaking half as
: much as I do when I think about the next time.

: Other options:

: UnixWare?  This is a standalone system.  Seems a bad fit.  I also don't feel
: any better when I hear about bug reports.

Novell seems to be no better than SCO at fixing bugs.

: Solaris 2?  Likewise, and since they just bought a bigger disk drive they're
: not going to be pleased with having to buy *another* to hold the OS.  And,
: like many other folks, I'm not looking forward to being a paying beta tester
: for Sun.  (Despite working for a Sun VAR, and preferring Solaris 2 to SunOS
: 4 due to its familiarity.  I'm not *completely* crazy.)

Solaris 2.x for x86 runs like a slug on 486DX2/66.

: ISC?  I help maintain wariat.org, which has been more unstable of late than I
: like to see; it's an Interactive box.  And SunSoft has been less than helpful
: despite many calls (I think they'd prefer we switched to Solaris...).

I tried to certify the SCO port of Progress V7 on the latest version of
ISC.  Problems with sigaction() caused Progress to fail.  It is a known
ISC bug (acknowledged by them), but they have as yet to ship me a patch.

: I've got the SCO system stabilized for now, but I'm continuing with Linux
: development in my off hours.  The next time an SCO bug traps us I may have a
: *viable* escape route.

I take it that the app is not using X11 on SCO.  While SCO ODT does come
with X11R5 and Motif, the integrated IXI desktop probably causes some
incompatabilities in the binaries.

: The solution others have suggested here would have me discarding Linux
: completely because it won't do the job right now.  If I followed that course,
: six months or a year from now I could find myself with my tail in a vise and
: no recourse except to get the client to struggle along on a buggy (at worst,
: crashing hard and requiring full restores like the past month) while switching
: them to a SPARC box (you don't know traumatic until you do something like
: that; this client has been through it before and isn't likely to be very happy
: at all if it happens again).  That may *still* end up being the only viable
: course; but I'm thinking ahead and working ahead to keep the chance open that
: they won't have to start over essentially from scratch just to get a working
: system.

If you see binary compatability improving on Linux, then you ought to stick
with it.  Eventually it will stabilize.

: That's where I'm coming from in this discussion.  I'm being paid (through the
: company I work for) by this client, in effect, to watch out for their
: interests; if I can at all help it, avoiding another complete
: hardware/software replacement for them is a better solution for them.  It may
: end up not being necessary, but three times in three months with two SCO bugs
: bringing down their system isn't a hopeful sign for the future --- and SCO has
: been no help at all, even less help than SunSoft has been with wariat's
: problems under ISC.

: (And no, this is not my only reason for being involved with Linux; I started
: with it before any SCO problems came to light for this client.  But it
: certainly adds to my willingness to stabilize the iBCS2 emulator and other
: aspects of Linux --- including cleaning it up for a potential business
: installation.)

There is a gray area between iBCS2 and SCO.


-- 

Rick Kelly  rmk@rmkhome.com  rmk@bedford.progress.com

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Multi-threaded linux-kernel
Date: Mon, 15 Aug 1994 00:42:30 GMT

In article <730.2E4E9E79@purplet.demon.co.uk>, jaggy@purplet.demon.co.uk (Mike Jagdis) says:
+---------------
| I think that at the moment only the user level is preemptable. Once you've 
| entered the kernel you are safe until you either return or voluntarily wait 
| on something. So the kernel level is safe unless you go to either a real 
| time preemptable kernel or SMP - in which case processes have the same 
| conflict problems as threads would anyway.
+------------->8

Again, a pre-emptable kernel with kernel-level threads is what I thought he
was talking about.  Kernel support for user-level threads doesn't seem like it
would need the rewrite he's claiming for Viper, after all.

++Brandon
-- 
Brandon S. Allbery KF8NH         [44.70.4.88]             bsa@kf8nh.wariat.org
Linux development:  iBCS2, JNOS, MH

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

From: leecheng@liapunov.eecs.umich.edu (Cheng-Tang Lee)
Subject: color_xterm bug
Date: 15 Aug 1994 02:07:17 GMT


I found a bug in color_xterm.  I got kicked out of color_xterm everytime
when I tried to switch to TEK mode.  I don't have this problem with xterm.
My slackware version is 1.2.0.

James

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

From: bjb@shore.net (Beverly J. Brown)
Subject: Re: starting X automatically on installing linux distribution
Date: 14 Aug 1994 22:39:41 -0400
Reply-To: bjb@shore.net

In article <32gf7j$2r4@solaria.cc.gatech.edu>,
byron@gemini.cc.gatech.edu (Byron A Jeff) wrote:
> The posts for this thread are getting longer and longer. I'll summarize and
> Sujat can add whatever he likes to what I list as his points list.
> 
> Sujat Points (my perception)
> 1) Linux needs a GUI to compete with other PC based OS's.
> 2) X should be presented as a default for Linux at installation time.
> 3) Any type of GUI environment (even 640x480x16) is better than text.
> 
> My Points
> 1) Many PCs have insufficient resources to run X effectively.
> 2) The baseline (640x480x16) is almost unusable.
> 3) Novices would be put off if X didn't function as well as OS/2 or Windows.
> 4) Hiding what's going on from the user by adding an abstraction layer is a
>    disservice to the user if the user doesn't understand the underlaying 
>    layers. The solution here is to add transitional layers showing the user
>    how to utilize the system at all layers so that they can pick an appropriate
>    tool at an appropriate layer to do the job.
> 
> and most importantly
> 
> 5) Linux doesn't have a need to compete with other PC based OS's. My personal
>    vested interest in getting other folks to use Linux is so that I don't have
>    to support DOS/Windows installations and to maximize the utility of each
>    PC available. 
> 

I believe Sujat did an adequate job of addressing the issues you have with 
his suggestions. He's not planning to froce people to use X, just present 
the option on installation IF enough resources are availble. This suggestion 
may help to satisfy your "personal vested interest" in moving people from 
DOS/Windows to Linux.

However, once people who are used to Windows and/or OS/2 get into X and 
decide they want to configure their X Desktop, they get stuck. There are 
virtually NO tools (that I'm aware of anyway) to let you easily change your 
X configuration. Simple tasks like changing colors or placing apps at 
certain positions on your screen at startup rewuires the user to understand 
X resources and their window manager. Not very user friendly to experienced 
Windows and OS/2 users.

X is much more pwerful than Windows or OS/2. But try convincing a Linux/X 
novice who is dismayed that he can't put xclock in the upper right corner of 
the screen and expects it to be there the next time he starts X.

Just my $0.02...

Beverly J. Brown
bjb@shore.net
beverly@datacube.com

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

Date: Sun, 14 Aug 1994 22:34:55 EDT
From: Senthil R. Kumar <SRK106@psuvm.psu.edu>
Subject: Re: Linux & parallel tape bkup?

Recently someone posted that the Colorado parallel tape
backup was nothing but the internal version, with an added
Parallel-port extension, which can be safely removed, thus
converting it into an internal backup drive , which can be
used with the existing drivers.

It seemed to be easy.  I have never tried this, because I do
not have the Trakker.

Senthil

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

From: sols7520@mach1.wlu.ca (Serge Solski u)
Subject: Menu-oriented shell for dial-in users?
Date: Mon, 15 Aug 1994 03:40:47 GMT


        Is there a shell or program that will let me make menu's so that
my dial-in users won't have to deal with the OS? I've checked out the
various BBS software, but they're too... well.. BBSish. All I want is to
create some menus to help my users configure their setup (ie: which editor
to use) and select programs (pine, trn, tin, gopher, etc.) 

        I've seen them available on other systems, and they seem rather
gopherish -- which is fine. Can Gopher be used for this?

        A while ago, I was talking to someone who had some sort of BBS
thing with PERL scripts. Where can I get this? I think he was from
Australia. 

        Please help if you have some information. I noticed a few other
people asking almost the same question, and we'll be very grateful...


        -Mark
-- 
"Key chuckles. 'If Skinny Puppy, in terms of the movie _Alien_, is a
chest-burster, then Doubting Thomas is more of a face-hugger,' he informs,
as if that were an explanation."
                                                        -Keyboard, Jan '92

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

From: a0017097@wsuaix.csc.wsu.edu (Christopher Wiles)
Subject: Re: Term Errors
Date: Mon, 15 Aug 1994 03:21:46 GMT

jeffs@stein1.u.washington.edu (Jeff Skone) writes:

: I've been getting the following error a lot when trying to link my PC 
: to the remote unix host. Any ideas of how to fix it:
: 
:    Term: Failed to connect to term socket '/root/.term/socket

<snip>

You wouldn't happen to be using programs you ported using the 2.0.x 
rules, would you?

I'm still working on this problem.  Right now it looks like the 
standard-inet-to-TERM translation routines are failing ... TERM_CONNECT() 
in particular.  The guy(s) that wrote TERM seem to be a little busy right 
now, so a bug fix is apparently not soon forthcoming.

_If_ I find the problem, I'll post a bugfix here.  For right now, if you 
want to port programs, use the old rules (available upon request).

-- Chris

a0017097@wsuaix.csc.wsu.edu   wileyc@halcyon.com   wileyc@quark.chs.wa.com
       "... but I want to use all eight comm ports SIMULTANEOUSLY!"
   PGP 2.6 public key available by finger for the clinically paranoid.

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: WABI vs. SoftWindows?
Date: Mon, 15 Aug 1994 02:19:07 GMT

In article <9408141808.23@rmkhome.com>, rmk@rmkhome.com (Rick Kelly) says:
+---------------
| Whose RDBMS are you using?  
+------------->8

Unify 2000.  Unofficial contacts at Unify have suggested that they've
despaired of SCO ever getting *their* shared memory working right; I *know*
that SCO shared memory changed incompatibly between 3.2.2 and 3.2.4, and it
seems quite likely to me that shared memory is the problem again.  I also
would suspect that the code that didn't work on SCO worked on other platforms.

| It's an SCO bug, but QA testing by the RDBMS vendor ought to be finding
| showstoppers before the project is shipped.
+------------->8

I gather from abovementioned contacts that SCO is not their favorite platform.
Certainly it's not their largest volume platform.

| Yup.  You'd better be sure that semaphores and shared memory are hard as
| a rock robust.
+------------->8

It doesn't use semaphores; it uses an atomic test-and-set on flags ("latches")
in shared memory.  This has the advantage of lower overhead.

| I tried to certify the SCO port of Progress V7 on the latest version of
| ISC.  Problems with sigaction() caused Progress to fail.  It is a known
| ISC bug (acknowledged by them), but they have as yet to ship me a patch.
+------------->8

I had heard that a patch for the ISC sigaction() bug was in fact available.
Whether you can get them to admit to it may well be another story, though.

| I take it that the app is not using X11 on SCO.  While SCO ODT does come
| with X11R5 and Motif, the integrated IXI desktop probably causes some
| incompatabilities in the binaries.
+------------->8

They're running the basic SCO system:  no TCP/IP, no X11 (until I briefly put
XFree86 on to do a demo, then removed it because I had to replace their
monochrome console and video card with stuff scavenged from my spare machine
at time to run X).

| There is a gray area between iBCS2 and SCO.
+------------->8

Tell me about it.  I've been dealing with it from the SCO end for far too
long.

++Brandon
-- 
Brandon S. Allbery KF8NH         [44.70.4.88]             bsa@kf8nh.wariat.org
Linux development:  iBCS2, JNOS, MH

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


** 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: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU

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