Subject: Linux-Development Digest #749
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sun, 22 May 94 21:13:07 EDT

Linux-Development Digest #749, Volume #1         Sun, 22 May 94 21:13:07 EDT

Contents:
  Re: SIGHUP: We tried it! (Sean Puckett)
  Re: Distributions considered harmful (Rob Janssen)
  Re: SIGHUP - Deep Kernal Guts question! (lilo (SpRiNg 94 GpA 3.64))
  Re: Binary compatibility (lilo (SpRiNg 94 GpA 3.64))
  Re: net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read (Tom Briggs)
  Linux and Bernoulli? (Edsel Adap)
  Re: Anybody working on BSD dump porting? (/bin/bash)
  Fax Software for Linux (Edsel Adap)
  Re: Anybody working on BSD dump porting? (David Barr)
  Re: Anybody working on BSD dump porting? (David Barr)
  Re: COMMODORE CALLS IT QUITS (Kevin Burtch X8534 Ppppp)
  Distributions considered not-so-awful (Russell Nelson)
  Re: p-thread (pre-emptive) package: volunteers gladly accepted :) (Kaelin Colclasure)
  Re: SIGHUP - Deep Kernal Guts question! (John Paul Morrison)
  Re: SIGHUP - Deep Kernal Guts question! (John Paul Morrison)

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

From: nate@loreli.ftl.fl.us (Sean Puckett)
Subject: Re: SIGHUP: We tried it!
Date: Sat, 21 May 1994 01:54:03 GMT

In the scrolls of comp.os.linux.development, Charles E Meier (CEM) enscribed,
CEM>
CEM> Why not a program that is put in inittab in place of getty which cruises the
CEM> /proc filesystem and kills anything that is being run by a user who isn't
CEM> logged in?  When it has cleaned things out, have it call getty.  Put a
CEM> config file together that lists legitimate stuff - you don't want to kill
CEM> update or lpd.  Might be easier than hacking the kernel.

We'd gotten as far as a seperate reaping program, but your idea of using
it in inittab as a getty wedge is excellent.  That's the perfect time to
check for stubborn programs -- as the line is then, by definition, open.

CEM> BTW - how were your kernel mods going to handle programs started by users
CEM> with a "nohup" option?  This is at least 1 reason why the kernel doesn't
CEM> automatically SIGHUP all of a user's processes just because they hung
CEM> up the phone line.

We tried nohup, and it worked properly under the modified kernel.


--
                       ..:: nate@loreli.ftl.fl.us ::..
             ..:: Sean Puckett - Albino Frog Software, Inc. ::..
          ..:: The Right Reverend Aural Hardly, MSK, BoC, FCoC ::..

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Distributions considered harmful
Reply-To: pe1chl@rabo.nl
Date: Sun, 22 May 1994 11:49:00 GMT

In <2rk3en$16f@eve.adam.com.au> steve@adam.com.au (Stephen White) writes:

>As for the people who say that Debian is useless... I feel this is a little
>unfair, since Debian hasn't been released yet.

Could *that* just be the reason it is being called useless?

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: lilo@slip-13-3 (lilo (SpRiNg 94 GpA 3.64))
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 21 May 1994 04:49:53 GMT

On Fri, 20 May 1994 12:31:48 GMT, Sean Puckett (nate@loreli.ftl.fl.us) wrote:

> But this gentleman has a different view:

> From: iiitac@uk.ac.swan.pyr (Alan Cox) at Swansea University College
> AC> NOPE: It's in the specs for good reasons... kernels should not set policy.
> AC> If you want people to get the boot then the shells you choose to issue them
> AC> with should follow the policy. In addition shells can do cleverer things
> AC> such as killing other process groups they have created. Fix your shell.

Um, this is the gentleman who maintains the networking code in the mainline
kernel.  In my experience, he knows what he's talking about.  ;)

> If it IS a shell thing, then all of the shells I've used under Linux
> are defective.  And I used sh, bash, and ksh all of which came with the SLS
> distribution.  In David's case, less is also broken, because it ignores the
> EIO value on its tty input, which is returned when there is no longer a
> terminal attached and you attempt to read a key.

You're using SLS?  I'd be surprised if it was the latest SLS (1.05), because
it's not completely stable, but the shells should be pretty current.  On the
other hand, if you're using an earlier (i.e., ancient) release of SLS, you
should upgrade.  If you plan on successfully developing software using
Linux.

I am running Slackware 1.2.0.1 or so (pretty current) and have never seen
these problems.  The current Slackware releases are among the most stable
available for Linux, and among the most popular.

What release of SLS are you running?

> Based on the answers I've seen to this issue so far, It seems that there
> in reality is NO good reason why the kernel can't send a SIGHUP to processes
> that will lose their tty input on a hangup.  I'm going to patch the kernel
> and see what breaks.

I hope you don't intend to restrict your software distribution to people who
are willing to apply that kernel patch and lose POSIX compliance.



lilo

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

From: lilo@slip-13-3 (lilo (SpRiNg 94 GpA 3.64))
Subject: Re: Binary compatibility
Date: 21 May 1994 04:54:55 GMT

On Wed, 18 May 1994 21:04:45 -0400, Conrad C. Nobili (Conrad_Nobili@Harvard.EDU) wrote:

> Of course, total lack of concern for compatibility would be bad too.  In
> this regard, Linus with the kernel, H.J. Lu with GCC/libc, and Alan Cox
> with the NET-2D stuff have done wonders to maintain a *reasonable* level of
> compatibility and stability.

I agree wholeheartedly!  :)

> Personally I don't *care* if Linux ever "takes off" or becomes
> "commercially viable" or "commercial developer friendly" or whether I can
> ever buy WordPerfect for it at Egghead.  Of course I understand that others
> *do* care about these things.  Maybe their needs can be served with
> Novell's Corsair/Expose Linux system (see PCWeek May 16, V11, N19, cover
> bottom)...?

Here I disagree.  Commercial viability is a wonderful thing.  But it is
worth noting that SCO binary execution, once it is stable, will probably not
hit a lot of bumps as we continue to make small incremental improvements in
other design areas.... ;)


lilo

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

From: tbriggs@cutter.ship.edu (Tom Briggs)
Subject: Re: net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read
Date: 21 May 1994 05:22:50 GMT

Bradley E. Smith (brad@bradley.bradley.edu) wrote:
: It appears that linux sends a window size of 8192, the cisco terminal
: server uses about 1120.  When sending data to cisco if the window
: size is larger than what the server wants (and linux seems to not
: change this) the link gets jammed.  The SUN computer states it window
: is 4096 but doesn't seem to have a problem.

I believe that number is the Maximum that it will send.  This is not the 
maximum it will receive (if that makes any sense).  I think what your 
problem is, is related to a problem that I am having right now also.

When Linux recieves a short packet, it performs what is called a "keep
alive" check, it basically sends a ping (I_COMP) packet with an out of
sync Window number and waits for a response.  If the machine doesn't respond,
Linux assumes that the thing died during packet transmission, and it 
throws away the day and drops the connection. 

Software that I know has big problems with tis:
   NCSA Ftp (telnet works fine)
   Winsock driven programs
   PC/TCP from FTP software (all programs in the bundle fail).  

The other UNIX based machines (such as the Sun) have no problem with it.
The System Administrator on campus tried to telnet to this Linux box with
FTP's software, and it would just lock up.  But he can spend all day long 
on from the Sun.

Tom Briggs


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

From: adap@andrews.edu (Edsel Adap)
Crossposted-To: comp.os.linux,comp.os.linux.misc,comp.os.linux.help
Subject: Linux and Bernoulli?
Date: 22 May 1994 22:44:44 GMT


Hi!
Is there any way I can get linux to recognize my bernoulli 90?  Is
anyone working on a device driver for it?

thanks.
-- 
 Edsel Adap                         Computer Science / Mathematics Major
 adap@andrews.edu                   Andrews University, Berrien Springs, MI

The Briggs/Chase Law of Program Development:

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

Crossposted-To: comp.os.linux.help
From: dbl@levad.oau.org (/bin/bash)
Subject: Re: Anybody working on BSD dump porting?
Date: Sat, 21 May 1994 03:23:49 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <2rad8i$bqu@serra.unipi.it> gio@di.unipi.it (Gioacchino La_vecchia) writes:


: >I'm trying to port bsd dump to linux.
: >Many header files have not corrispondence on linux systems.

: >Nobody working on it?

: Because of the many filesystems that Linux supports, trying to port
: something like "dump" is not simple, and IMHO not a good idea.

: You are better off making backups with "tar" or "cpio".

That is a shame as far as I am concerned! dump/restore is a very powerful
backup tool and will be missed. I have used dump/restore for several 
years now and miss it a great deal on linux. cpio and tar do not even come 
close to filling the void, IMO. 

: Rob
: -- 
: -------------------------------------------------------------------------
: | Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
: | e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
: -------------------------------------------------------------------------
-- 
/=============================================================================\
| Dave Lounsberry            | "MSDOS didn't get as bad as it is overnight -- |
| dbl@levad.oau.org          |  it took over ten years of carful development."|
| uunet!gator!edus!levad!dbl |   ---dmeggins@aix1.uottawa.ca                  |
\=============================================================================/


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

From: adap@andrews.edu (Edsel Adap)
Crossposted-To: comp.os.linux.misc,comp.os.linux.help
Subject: Fax Software for Linux
Date: 22 May 1994 23:25:26 GMT

Hi!

Is there a public domain fax software for linux?  Preferrably one that
can send .dvi, .ps or xwd files.

If anyone knows of one, please let me know.

Thanks!
-- 
 Edsel Adap                         Computer Science / Mathematics Major
 adap@andrews.edu                   Andrews University, Berrien Springs, MI

The Briggs/Chase Law of Program Development:

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

From: barr@pop.psu.edu (David Barr)
Crossposted-To: comp.os.linux.help
Subject: Re: Anybody working on BSD dump porting?
Date: 22 May 1994 19:43:53 -0400

In article <2rgsdb$1c7@panix.com>, Gary Merinstein <gmerin@panix.com> wrote:
>rdump deals with raw data / raw disks; sort of a bit-by-bit image (you 
>can boot & mount a dump tape as tho it were a disk)

Um, no you can't.  You're thinking of a raw partition copied to tape via
dd.  dump includes a header and separate directory information which is
different.  Also, the mounting of the tape as a filesystem isn't possible
on many systems, due to limitations in the tape device driver.

--Dave
-- 
"Gopher is the Model T of the Information Superhighway.  It's small,
trusty, underpowered, modified to do things it was never designed to
do, and available in every color of OS, as long as you like text" - me

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

From: barr@pop.psu.edu (David Barr)
Crossposted-To: comp.os.linux.help
Subject: Re: Anybody working on BSD dump porting?
Date: 22 May 1994 19:47:50 -0400

In article <2rl9q0$epi@crl2.crl.com>, Mark A. Horton <mahmha@crl.com> wrote:
>Bleeechh!  I don't even use dump on my SPARCS anymore! (got bitten 
>too many times!)

Perhaps you don't know what you were doing.  I use dump fine on this
network of 48 SPARC's.  (around 20GB or so)

>I now use regular, normal, cpio -- I like to know
>what I'm really putting on tape!  It's no big deal to write a few
>scripts to control incremental dumps, etc.  And now I backup the
>SPARCS through the Linux box via NFS to an external EXB-8200, so it's
>even easier.

And slower.

--Dave
-- 
"Gopher is the Model T of the Information Superhighway.  It's small,
trusty, underpowered, modified to do things it was never designed to
do, and available in every color of OS, as long as you like text" - me

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

From: kburtch@pts.mot.com (Kevin Burtch X8534 Ppppp)
Subject: Re: COMMODORE CALLS IT QUITS
Reply-To: kburtch@pts.mot.com
Date: Fri, 20 May 1994 15:16:44 GMT


I tried to send this directly to Andrew, but it bounced.

> Date: 20 May 94 17:01:27 +1000 (Fri)
> From: andrew@teslab.lab.oz (Andrew Phillips)
> 
> In article <Cpr2Jp.Eyp@pts.mot.com> you wrote:
> : In article r5d@wea.eel.ufl.edu, acg@kzin.cen.ufl.edu (Alexandra Griffin) writes:
> : > The 64 & vic were 6502-based-- no danger of that architecture
> 
> : Close, the Apple II, II+, and IIe were 6502, the //e (enhanced) and //c were 65C02,
    ^^^^^

> : and the Commodore's were 6510. (they did have a 6502 in their disk drives though...)
> 
> The 6510 is a 6502 with a few ports built-in.  Its as close as a 6502
> as you can get without being one.  The VIC-20 used a 6502.

Close, but not the same processor. (you can't swap them and expect functionality)

> And who mentioned Apple.  Everyone knows that the Apple II line (and
> the Apple III) were 6502 based.

Obviously, the previous poster! and many others! (haven't you read any of
this thread at all???)

>...
> The 32 bit equiv of the 65C816 is the 65C832 currently used by a video games
> manufacturer.

First, I have never heard of the 65C832. (65C816 & 65C802 I have)
(I am not disputing it's existance) It was obviously not used in
any "computers". (VGs excluded)

>...
> MC68K means Motorola Corp 68000.  Why do you add this drivel about

Check my address! I know who Motorola is!!

> the company "Amiga" - it adds nothing to the discussion.

I am not the one who brought them up! Don't jump into the middle of
a coversation and accuse the first person you hear of starting it!

******READ THE SUBJECT LINE!!******

>...
> Well in ten years the development of the Amiga was pathetic.  They
> did introduce new machines bu they were not major advances over
> previous ones.  They mainly benefited from improvements in Motorola

That's because the previous ones were so advanced! :) I've seen them in
action, and believe me, IBM and Apple products _of_the_same_timeframe_
could not touch them in performance or features. (the early ones)

> processors.  Enhancements to the Amiga coprocessor were done but were
> not major (perhaps doubled), compared to advances by other companies
> (about doubled every 3 years).

True, and after a decade, Apple (Mac) finally caught up with them! :)
(no flames here, I like Apples too.)

>...
> The real problem is that they were only made by the same company,
> unlike the IBM compatibles.  Apple were better off with the MAc
> because they were a bit bigger and brought it in earlier but they are

Apple was bigger than Commodore when they introduced the Amiga??? If
you say so!  If I remember right, they came out about the same time.
(Mac and Amiga)

Mac was only made "by one company", so why did _they_ do so good??

The problem, proven here again, was Commodore's marketing dept! Apple
marketed the $#!T out of the Mac, and sold a lot more because of it,
while Commodore didn't market themselves, and people didn't know about
them, so they didn't sell! 

> going the same way as Commodore (becuase there were no MAc clones).

I doubt that. The reason there were no Mac clones, is that Apple
protected themselves! They would have gone under in a heartbeat
if they hadn't! (do you have any idea at all how many companies
Apple put out of business in court??) There is no way Apple would
have been able to compete with a company the size of IBM without
doing so! By the way, if it wasn't for Apple, IBM wouldn't have 
invented the PC! "We will _never_ make a personal computer, there
just isn't a market for them" is a very famous IBM quote. Also, the
only reason IBM used the 80x8x processors, was that Motorola couldn't
deliver enough 68000 processors at the time! (that was their primary
choice)

> Interestingly they've recognised this and reversed tack with 
> Power PC.

No, what they realized, was that the world is moving on to much more
powerful processors, and they needed to make a jump along with everyone
else, or be left behind "climbing".

***************************************************************************
Lets end this rediculousness. This started out as a discussion and you seem
to want to turn it into a flamefest.
***************************************************************************

Kevin




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

From: nelson@crynwr.crynwr.com (Russell Nelson)
Subject: Distributions considered not-so-awful
Date: 23 May 1994 00:26:39 GMT

Thanks for your comments on my earlier "Distributions considered harmful".

Different versions of the same free software occur for the same reason
that religious societies split -- an irreconcilable difference in
opinion.  I don't think that's ever a happy thing to have happen, but
I see that it *does* have to happen sometimes.

I'm running Slackware 1.0.1 with an updated kernel (which has caused
problems with some of the utilities).  My posting was prompted because
I had a support contract with SLS, and I felt like I shouldn't be
calling him on Slackware issues.  Is there anyone out there who sells
Slackware support for a reasonable price (<$300/year)?  I've asked
Patrick but haven't gotten a response yet.

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

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

From: kaelin@bridge.com (Kaelin Colclasure)
Subject: Re: p-thread (pre-emptive) package: volunteers gladly accepted :)
Date: 23 May 1994 00:23:35 GMT

In article <2rf76b$8h4@news-rocq.inria.fr> soulard@druuna.inria.fr (Herve Soulard) writes:

   > Help is gladly accepted--we *will* bother you about it :)

   Here is my "help" :

           Chris Provenzano has implemented a pthreads library that is
           based on the POSIX1003.4a Draft 8 pthread standard. It works
           on Linux as well as on *BSD and Sparc and ....

           It is available on  sipb.mit.edu in pub/pthreads.

Is anyone actually using this under Linux?  I retrieved v 1.27 and
noted that, while it compiles cleanly under Linux 1.1.8, it fails its
own test_sleep validation program.  Judging solely from the observed
behavior, I'd say that only one thread can safely call sleep().

I plan to check this out under SunOS when I get back to work Monday.
Of course, I haven't actually looked at the source or tried to fix it
or anything... ;-)

FYI, the other test_xxx programs _seemed_ to work fine (ie. ran to
completion and generated reasonable-looking results).
--
// Kaelin Colclasure ---------------------------------------------------------
// EMail: kaelin@bridge.com            Mail: Bridge Information Systems, Inc.
// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141

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

From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: Sun, 22 May 1994 06:09:40 GMT

In article <davem.769276922@extro>,
David Monro <davem@extro.ucc.su.OZ.AU> wrote:
>[lots deleted..]
>>do_exit sends SIGHUP to the group if (and only if)
>>there are stopped processes in the group,
>
>>it is only running tasks that i find detached from the terminal after
>>the leader exits. but thats even if there are stopped jobs.
>>(i dont know if the bit about stopped jobs in do_exit has anything
>>much to do with this problem
>
>Does this explain why if I kill an xterm/rxvt running less, the less
>process goes beserk and eats all my CPU? If so, this is bad, and could
>cause real havoc on a multiuser machine (user logs out, process goes
>beserk, nobody can kill it till root comes along...)

Partially. It looks to me like less has a bug with its signal
handling, even if hupcl is set. (Maybe it's not a bug but wrong
defines during compilation).

observe:

$ telnet localhost
login: foobar
Password:

$ stty hupcl
$ less /usr/adm/messages
^]
telnet> q
Connection closed.
$ ps aux

....
foobar  7220 52.2  1.7   96  204  ?  R    22:45   0:47 less /usr/adm/message
             ^^%CPU

notice that less is sitting there chewing up CPU time!  and you can't
kill it with SIGHUP either: kill -1 7220 doesn't do anything.  you
have to kill it with -15 or -9. You can kill less with SIGHUP under
normal circumstances though.

now try with more:

$ telnet localhost
login: foobar
Password:

$ stty -hupcl
$ more /usr/adm/messages
^]
telnet> q
Connection closed.
$ ps aux
...
nope, no more running

so 'more' got HUP'ed even though -hupcl was set (maybe that's because
I'm trying with a pty. anyway, that's not the point. SIGHUP does get
sent when the tty is closed (by the shell, so I'm told) and the
process in this case is getting killed like it's supposed to).

So on hangup, the process may be hanging around because the shell
didn't send SIGHUP, or because the process is ignoring SIGHUP
(deliberately or because of a bug). With less, it's ignoring SIGHUP
and also getting stuck in an infinite loop (doing 'read(3, "", 1) = 0'
according to strace). 

Now maybe it's a bug in 'less' but it wouldn't surprise me if it's a
bug in the C library or curses/termcap. You shouldn't need to do major
surgery on programs to get them to compile properly on linux.


>
>       David


-- 
===========================================================================
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --      
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@rflab.ee.ubc.ca
===========================================================================

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

From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: Sun, 22 May 1994 06:41:17 GMT

In article <2rj9pu$ec6@senator-bedfellow.mit.edu>,
Theodore Ts'o <tytso@ATHENA.MIT.EDU> wrote:
>
>As for programs going beserk and eating up lots of CPU --- they're
>broken.  And, I suspect, there are relatively few of them.  Perhaps your
>favorite version of "less" is broken that way, so you see a skewed
>version of the world.  But Unix programs all over the world have to work
>under the same rules, and so they tend to get fixed over time.
>

It's a bit annoying that applications which work on dozens of other
systems are "broken" in sometimes subtle (or not so subtle) and
annoying ways under Linux. Like the bug in talk when you press ^Z
(hopefully fixed by now), which also affects(affected) gopher and
some other programs relying on curses.  Problems especially with signal
handling pop up all over the place, and there are no compatibility
options or libraries that really work to bridge the gap.  What would
be a simple compile on one system can often become an hour or two
debugging session under Linux. Well, hopefully it will get better as
more people support Linux, or POSIX systems.

Other compatibility fun: compiling a Linux 'port' of gated
demonstrated just how bad the header file compatibility is between
various Linux distributions (Slackware is missing most BSD net include
files, SLS had some) and BSD. I haven't had a chance to even run it,
now that will be interesting...



>                                               - Ted


-- 
===========================================================================
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --      
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@rflab.ee.ubc.ca
===========================================================================

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


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

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

    Internet: Linux-Development@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-Development Digest
******************************
