Subject: Linux-Development Digest #740
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:     Sat, 21 May 94 00:13:05 EDT

Linux-Development Digest #740, Volume #1         Sat, 21 May 94 00:13:05 EDT

Contents:
  Re: COMMODORE CALLS IT QUITS (Andrew Bulhak)
  Re: Strange story of a T4600C notebook (Bram Smits)
  Linux Intrntl & Auto Cfg project (CHRISTOPHER M MAY)
  Re: SIGHUP - Deep Kernal Guts question! (Theodore Ts'o)
  Re: Anybody working on BSD dump porting? ("Joe C. Hager")
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Laurent Chavey)
  Re: 32-bit Novell desktop OS combines Unix, (Laurent Chavey)
  Re: setlocale() for iso_8859_1 -- configuration? (Peter Dalgaard SFE)
  Re: rarp, how to use it? (David Simmons)
  Re: SIGHUP: We tried it! (Charles E Meier)
  Source to color ls Command (C. McNiel)
  Third year Projects and Linux (Ben Frank)
  net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read (Bradley E. Smith)
  Re: Two suggestions that might speed up Linux. (Scott C. Gray)

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

From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
Crossposted-To: comp.os.linux.misc
Subject: Re: COMMODORE CALLS IT QUITS
Date: 18 May 1994 04:07:14 GMT

Brandon S. Allbery (bsa@kf8nh.wariat.org) wrote:
: In article <1994May11.194011.20646@rosevax.rosemount.com>, grante@reddwarf.rosemount.com (Grant Edwards) says:
: +---------------
: | Nope, there was a dual-mode 8/32 bit wide 6502 compatible cpu (I don't
: | remember the number, but 68C832 doesn't sound quite right).  
: +------------->8

: 65C816, but that was an 8/16 bit microprocessor.  (The Apple IIGS used it; I
: don't think any other "major manufacturer" machines did.)  I don't think there
: was a 32-bit version.

The Super Nintendo uses it.

--
Andrew Bulhak            acb@yoyo.cc.monash.edu.au
The only person more evil than Kibo!

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

From: bram@fangorn.hacktic.nl (Bram Smits)
Subject: Re: Strange story of a T4600C notebook
Date: Sun, 15 May 1994 22:57:00 GMT

fox@graphics.cs.nyu.edu (David Fox) writes:

>I just got a call from the repair shop about my Toshiba T4600C

Still under warranty ?

>notebook computer.  I brought it in because the floppy drive
>was giving me troubles - it was unable to mount HD disks under
>linux, formatting under DOS would fail when it tried to write
>to the boot sector I think; whatever it does after it asks 
>you for a label, it would get an INT 24 failure.  It usually
>couldn't read HD disks in DOS, though some disks were ok.
>They replaced the floppy drive and the motherboard with no
>improvement.  They re-partitioned and re-formatted the hard
>disk, still no improvement.  They just called up and asked
>if I had any non-DOS partitions on the disk - of course, I
>said yes.  They say that is the problem, and they're going
>to replace the hard disk.  Any theories about what is going
>on here, and how I can prevent it happening again?

Did it provide a cure ?

If not, in no particular order:
1- non-dos partitions don't cause problems (unless the system is faulty, 
    and then replacing the drive won't help)
2- harddrives usually don't cause floppydrive problems
3- even if they do, it's -a) not dependent on what's on them
    -b) usually not discovered by reformatting, but by testing the machine 
        without the harddrive or replacing it regardless of content (our 
        standard practice: If you suspect a part, temporarily swap it to 
        see if that provides a cure. Plenty of parts in stock).

I know these problems can be _very_ hard to find. Just saying 'Oh, non-dos 
partitions, replace harddrive' is a sleezy way out, and may not provide a cure.
Should you decide to let them replace the drive, don't pay until they've
demonstrated that it works (with linux :-) ), and even then get some guarantee
that you'll get your money back if it doesn't work/last after all.

Please note, I don't say that it can't be the harddrive, I just say that it's
independent of what you put on it. It would also be bad with just a dos
partition on it.

How to prevent it: you probably can't. Sometimes parts go bad without a 
clear reason. Could be a glitch on the power line, a faulty power 
regulator (have they checked these ?), a part somewhere in the power 
circuit going critical, (an obvious one:) the floppydrive cable/connector 
being unreliable, etc etc... 

Well, let me know how it turns out. Very interrested.

    v__   
  <"___\____     Bram 'mouser' Smits.

* All views expressed herein are my own, etc, etc. | Fangorn Systems          *
* All disclaimers apply.                           | Heerlen, The Netherlands *
*  Truly songs and tales fall utterly short of reality,                       *
*  O Smaug the Greatest and Chiefest of Calamities  - JRR Tolkien, The Hobbit *

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

From: cmay@titan.ucs.umass.edu (CHRISTOPHER M MAY)
Subject: Linux Intrntl & Auto Cfg project
Date: 20 May 1994 19:50:30 GMT

Hi, I just saw a solicitation for "volunteer hardware experts"
to write for the AutoConfiguration Project for Linux International.

What is the general consensus on this project?
As I have yet to volunteer any services (I need to get through
school, and I have a job), I would like to know what people
think.  My first impression is that this project is somewhat unnessesary.

IMHO:
Linux isn't for the feint of heart when it comes to computer knowledge.
It's really for those who want to push the envelope of what their PC
can do, under a multitasking Unix-like OS.

Do we really want people who can't tell a jumper from a gender-mender
using this OS?  Can they possibly contribute to it's progress?

It sounds to me like a big effort to sell some people (i.e. newbies)
something they don't really want, by hiding some of the complexity of 
the system from them.

I forget, is LI a "non-profit" organization which is truly working 
for the betterment of Linux?  Why did they post outside the Linux
groups _FIRST_?  I keep up with these groups alot, and if it had been
handled correctly, I might have joined.  From what I remember, though,
it seems that the general linux community was against their autoconfig
project.  Please inform me, I don't know it all when it comes to linux
politics.  I don't want to rub anybody the wrong way, but seems like
a furthering of the fragmentation that we're seeing so much of lately.

Can't people just work on drivers and real hardware support, and leave
the distributions as they are?
--

-Chris May, Computer Science, University of MA, Amherst
-       Technical Assistant, P.C. Maintenance Lab


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

From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 20 May 1994 17:24:14 -0400
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)

   From: nate@loreli.ftl.fl.us (Sean Puckett)
   Date: Thu, 19 May 1994 01:42:01 GMT

   All this stuff about the POSIX standard and manuals is very enlightening,
   thank you gentlemen very much.  However, it simply raises more questions.
   Now that we know why the kernal doesn't send a HUP to running apps, the
   answer being 'because the specs say it', we now must ask why the specs
   don't say to send a HUP to running apps.

   Why is it in the specs?

Because sometimes users ***want*** to leave a process running in the
background when they logout.  Traditionally it is the shell's
responsibility to decide how to deal with this situation.

   We are programmers here, and we have a problem that needs
   to be resolved.  If there are no hard, fast reasons why it should NOT
   send a HUP signal (which is easily ignored, mind you) to all processes
   owned by a terminal on loss of carrier, then I will simply change the kernal
   to do so.

The main reason is that you will be incompatible with other systems;
this kernel patch won't be accepted into the mainline distribution, so
you'll have to manually add it in for every release --- and you'll never
be able to port your system to other operating systems which are POSIX
complaint.  Good enough?

If you have a problem to fix, fix it the right way.  Make the session
leader catch the SIGHUP signal, and have it propagate that signal down
to its children.  It's the shell's responsibility to decide whether or
not to propgate the signal or now; this is much more flexible.

Or, if you don't want to do that, set up a system daemon that runs as a
"gunner" to kill processes which have been running for too long.  There
are a lots of solutions that don't involve making incompatible changes
to the kernel.

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.

                                                - Ted

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

Crossposted-To: comp.os.linux.help
From: jchager@hobbes.demon.co.uk ("Joe C. Hager")
Subject: Re: Anybody working on BSD dump porting?
Reply-To: jchager@hobbes.demon.co.uk
Date: Fri, 20 May 1994 14:31:39 +0000

In article <1994May20.112448.3210@kf8nh.wariat.org>
           bsa@kf8nh.wariat.org "Brandon S. Allbery" writes:

> 
> Henry Spencer's tarx works fine for recovering damaged GNUtar archives...
> 

Where can I retrieve Henry Spencer's tarx?
-- 
======================================================================
Joe Hager
jchager@hobbes.demon.co.uk
======================================================================

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

From: chavey@sabre-tooth.cis.udel.edu (Laurent Chavey)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Date: 19 May 1994 17:44:48 GMT

>I find it highly unlikely that Novell's support for running MS-Windows
>apps were integrated into the Linux kernel. Therefore, it's quite possible
>that many of these "fantastic" features that we're hearing about won't
>be freely distributable at all. Novell is only required to distribute 
>code for free that is based on GPL code, e.g., any modifications to the
>Linux kernel itself. This does not entail that the entire system will be
>placed under the GPL.
>

Would corsaire be a replacement for linux.
If so, would all the apps under linux run under corsaire.


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

From: chavey@bambam.cis.udel.edu (Laurent Chavey)
Subject: Re: 32-bit Novell desktop OS combines Unix,
Date: 20 May 1994 20:20:12 GMT

>>I would also add, that some of the people working at novell are
>>not born from the last rain. Some may in fact know very well what they
>>are doing, and how one can port the kernel.
>>Now, the fact that they used Linux as a base, show that they were not
>>interested in the base (usual os stuff), but were more interested in
>>adding all the functionality that will make Linux a good competitor
>>against NT. Do not forget novell is on our side, TO NOT LET 
>>MICROSOFT NAD BILL GATE OWN THE COMPUTER WORLD. Lets all fight to
>>not have another giant dictate the computer future.
>
>
>Oh no! You're fighting fire with fire. Don't forget, Novell is allready
>the number two in business. And they are very aggressive in the marketing
>strategy. MIC*SOFT is of course a target. But we're NOT on the same side 
>with Novell. Novell is not a bit better. 
>

yop, let the two giant fight among themselves, but by taking linux
as its base, novell acknowldges all of us. I see the mistake that I made
on the previous paragraph saying that Novell is on our side,
I should say that they are inadvertendly playing a good game for Us,
free users. I belive that what ever they are producing will be available
in Japan or china, or other contries without copyright laws very soon, so
reverse engineering will be done. So Novelll hard work will trickle down
to all of us. 
Using linux is a two edge sword, and they may be able to sell it, but
I can not see how they will be able to protect themselves from pirates.



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

From: pd@kubism.ku.dk (Peter Dalgaard SFE)
Subject: Re: setlocale() for iso_8859_1 -- configuration?
Date: 20 May 1994 15:00:38 GMT

In <2rdl63$7c@melchior.frmug.fr.net> thomas@melchior.frmug.fr.net (Thomas Quinot) writes:

>H. Peter Anvin N9ITP (hpa@ahab.eecs.nwu.edu) wrote:
>: > Situation: Elm won't print Danish characters. Nuisance!
>: > This should work after setting LC_CTYPE to iso_8859_1 in
>: > the environment. Does not.

>: Not.  Elm uses its own character set.  You need to set
>: "displaycharset" to ISO-8859-1 in order to print Latin-1.
>No, I had elm display French characters correctly by just setting LC_CTYPE,
>but the correct value is "ISO-8859-1" (case-sensitive), and you have to
>ensure that your libs were compiled with "__linux__" defined (I had to add
>it to /usr/lib/gcc-lib/i486-linux/2.5.8/specs -- is this normal ?)

Yes, the spelling is the problem. "iso_8859_1" is what works on
Suns. I think they used ISO_8859_1 sometime in the past.
Discussed this in private email with hpa and he said the proper
value for LC_CTYPE is the lowercase-underscore one. The
upcase-hyphen version is hardcoded in Linux's libc. On the 4th
hand HP-UX9.0 seems to have values like "danish.iso88591". What
a mess!

If there is a standard, it would certainly be nice to have Linux
conforming to it. Does anybody have hard info on the matter?
--
   O_   ---- Peter Dalgaard
  c/ /'  --- Dept. of Biostatistics 
 ( ) \( ) -- University of Copenhagen
~~~~~~~~~~ - (pd@kubism.ku.dk)

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

From: simmons@EE.MsState.Edu (David Simmons)
Subject: Re: rarp, how to use it?
Date: 19 May 1994 00:57:14 GMT
Reply-To: simmons@EE.MsState.Edu

In article <Cpsu4F.Aw2@cunews.carleton.ca>,
Kethireddy Vanier <vanier@aurora.carleton.ca> wrote:
>Hello,
>
>       In version 1.1.12, rarp has been implemented, so I would like to
>know how I can get IP address, from the system, alternatively what system
>call should I make to get the Ip address. 
>       Please note that I just started to learn how to write network 
>programs.
>       I would appreciate if email to me.
> 
>Thanks to all
>Vanier Kethireddy
> 

Better yet, post a reply here.  I'd like to know this as well.
David

-- 
David Simmons, System Administrator                 simmons@ee.msstate.edu
Mississippi State University Electrical and Computer Engineering
Visit my home page!  http://www.msstate.edu/~dls3/

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: SIGHUP: We tried it!
Date: 20 May 1994 20:48:34 GMT

In article <1994May20.151724.368@loreli.ftl.fl.us>,
Sean Puckett <nate@loreli.ftl.fl.us> wrote:
>
>Okay.  I hacked the kernel, just like this:
>
>In kernel/exit.c
>  copy routine kill_sl making a new routine called kill_sess.
>  remove the second test from the if statement in kill_sess that selects
>     only leader processes.
>
>In include/linux/kernel.h
>  add a prototype for kill_sess that matches kill_sl
>
>In drivers/char/tty_io.c
>  change two calls to kill_sl to kill_sess
>
>
>This solved many of our test cases, but also screwed up another program which
>hadn't detached itself from the terminal and was simply ignoring stdin as
>its way of staying alive through loss of tty.
>
>So, sadly, we changed it back.  I figure, if we're going to have to hack
>out a way to solve the problem, we should hack from the point of an unblemished
>kernel, rather than a blemished one.  Then our work will be useful to others
>in similar circumstances.
>
>Perhaps this is an 'i told you so' from the ivory tower tribe.  Like I said,
>being right isn't what matters to me.  Finding a solution to my problems is.
>
>Still taking suggestions!
>
>
>--
>                       ..:: nate@loreli.ftl.fl.us ::..
>             ..:: Sean Puckett - Albino Frog Software, Inc. ::..
>          ..:: The Right Reverend Aural Hardly, MSK, BoC, FCoC ::..


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

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

cem

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

From: cmcniel@blue.weeg.uiowa.edu (C. McNiel)
Subject: Source to color ls Command
Date: 20 May 1994 10:08:01 -0500

Can anyone tell me where I can get the source to the color
"ls" command?  A friend of mine would like to try and compile it
for AIX to run in a color X-term?  

Thanks in advance.

Craig McNiel
University of Iowa
User Consultant
cmcniel@blue.weeg.uiowa.edu

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

From: u9219765@cpcw2.uea.ac.uk (Ben Frank)
Subject: Third year Projects and Linux
Reply-To: u9219765@sys.uea.ac.uk
Date: Fri, 20 May 1994 15:25:02 GMT


Hi,
    I like many other computer science students have to choose there third year projects soon. I was
wondering if anything needed doing in Linux that would be suitable for such a project, There are loads of
second years out there who use Linux and would like to put something back (like me :)
   If you can think of something can you mail me, I'll post a summary, here and on comp.misc
Cheers.
        Ben Frank.

--
If I hadn't seen such riches I could live with  | Ben Frank
being poor ! :)                                 | u9219765@sys.uea.ac.uk


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

From: brad@bradley.bradley.edu (Bradley E. Smith)
Subject: net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read
Date: 20 May 1994 10:37:07 -0500

i have found my problem with the cisco terminal servers.  I am not
sure how to fix it correctly, but I can hack it to stay working.

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.

Anyways If I set TCP_MAX_WINDOW to 1024 and MIN_WINDOW to 512,
everything works okay.  It appears to me that the linux box should
set it's window size to the smaller of the 2 and use that number
when talking back and queueing up data to the remote end.

So what is next?  I feel my hack will slow down computers that can
take more data.
-- 
Bradley Smith                    brad@bradley.edu ---  309-677-2337
Network & Technical Services @ Bradley University, Peoria, IL

"It's amazing how much scrap metal you get from 4 cans of beer"

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

From: gray@pong.nas.nasa.gov (Scott C. Gray)
Subject: Re: Two suggestions that might speed up Linux.
Date: Fri, 20 May 1994 21:15:24 GMT

In article <2rdkae$7u@acme.gatech.edu>,
Robert Sanders <gt8134b@prism.gatech.edu> wrote:
>stevek@panix.com (Steve Kann) writes:
>
>>William O Smith (wos@dcs.warwick.ac.uk) wrote:
>>: Suggestion 1:  Compressed buffers.  On fast machines, if there is idle
>>:        time, and spare buffer space, how about compressing the
>>:        disk buffers, storing both versions (compressed and un-
>>:        compressed) until memory gets tight, then just keeping
>>:        the compressed version (if it saves much space).  Presumably
>>:        if the machine becomes fast enough, decompressing memory
>>:        should be faster than loading off disk.
>
>>I think this is a really interesting idea...  And the basics of the
>
>And a really bad one.  It's kinda amusing how people will want
>to compress everything.  I imagine quite a few of them have tried
>to gzexe gzip...
>

[correct observations deleted]

..besides (and correct if me I am wrong), if you are running multi-user
this would slow down *everyone*, not just the processes waiting on disk I/O.
Presumably, when a process requires a page which is on disk it begins the
disk request and sleeps until the I/O has completed, freeing up cycles for
other processes.

-scott

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


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