Subject: Linux-Development Digest #315
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 16 Oct 94 01:13:12 EDT

Linux-Development Digest #315, Volume #2         Sun, 16 Oct 94 01:13:12 EDT

Contents:
  Re: Extreme delays telnetting into linux box (Klaus Lichtenwalder)
  Re: 8-bit colour ANSI and ncurses (Zeyd M. Ben-Halim)
  Re: Shared Libs: working toward a permanent solution? (Brandon S. Allbery)
  archie fails under 1.1.53 (Marc Fraioli)
  Re: Floppies still don't work under 1.1.54 (A.E. Brouwer)
  Re^2: Beautifying Linux/Xfree (Karsten Mauler)
  Optimizing the NFS server (Thomas Koenig)
  Re: Linux v1.0 SMAIL problem (Scott Jennings)
  Re: We a FAQ: Linux vs. *BSD!!! (R Vincent)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Shaune Beattie)
  Where to find latest changes.xx files? (Timothy Demarest)
  Re: GNUStep...Is It Real or Just a Hoax?!? (Derrik Walker II)
  Re: Kernel 1.1.53 - no BOOM (Rob Janssen)
  Re: 3c505 driver ? (Rob Janssen)
  Re: PGP for Linux?? (Frank Lofaro)
  Re: Improving SLIP latency under Linux (Rob Janssen)
  Re: Improving SLIP latency under Linux (Rob Janssen)

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

Crossposted-To: comp.os.linux.admin
From: [email-masked] (Klaus Lichtenwalder)
Subject: Re: Extreme delays telnetting into linux box
Date: Sat, 15 Oct 1994 11:02:39 GMT

[email-masked] (David - Morris) writes:

>I'll say it again.  When I telnet from a LAN workstation whose
>IP address can't be resolved into a name I experience a VERY long
>delay.  When I add the host to the /etc/hosts, the connection is
>almost instant....

I'd say it's a problem with the nameserver. What does nslookup say?
Where does your /etc/resolv.conf point?

Klaus
-- 
__________________________________________________________________________
Klaus Lichtenwalder, Dipl. Inf., Buschingstr. 65
D-81677 Muenchen, F.R. Germany,  Fax +49-89-98292755
email: [email-masked], [email-masked]

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

From: [email-masked] (Zeyd M. Ben-Halim)
Subject: Re: 8-bit colour ANSI and ncurses
Date: Fri, 14 Oct 1994 05:42:24 GMT

In article <[email-masked]>,
 <[email-masked]> wrote:
>I think that if the console driver is modified to accept new escaape
>sequences, a new termcap/terminfo file should be included as well.  My
>etc/termcap does not give any of the alternate character set entries
>(as,ae,ac) for the console terminal.

I'll happily modify terminfo if anybody bothers to document the changes/new
features. I have no idea who's in charge of /etc/termcap.

Zeyd

-- 
---
Zeyd M. Ben-Halim       [email-masked]
NCURSES is available from ftp.netcom.com:pub/zmbenhal/ncurses
Current version is 1.8.5

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

From: [email-masked] (Brandon S. Allbery)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: Sat, 15 Oct 1994 16:08:23 GMT

In article <[email-masked]>, [email-masked] (H. Peter Anvin) says:
+---------------
| > I think you misunderstand his intent:  he's talking about using a segment
| > register as if it were a general register containing an address.  Basically,
| No, no, no... that wouldn't work at all, especially since we're
| talking 32-bit offsets here.  What I am talking about is using segment
| aliasing; a segment can overlap another, but possibly with another
+------------->8

If you had read the rest of my message, you would know that (a) I already said
that, although not in so many words, and (b) segment aliasing won't work
either unless %gs == %ds, which is useless.

++Brandon
-- 
Brandon S. Allbery KF8NH         [44.70.4.88]           [email-masked]
Linux development:  iBCS2, JNOS, MH                                      ~\U
Waiting For Godot^H^H^H^H^HRothenberg

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

From: [email-masked] (Marc Fraioli)
Subject: archie fails under 1.1.53
Date: 15 Oct 1994 17:29:47 GMT
Reply-To: [email-masked]

  I recently upgraded my system to 1.1.53 from 1.1.50.  When I did, archie
and xarchie stopped working.  They now just sit there for a long time and
eventually die with a "timed out" error.  This used to happen under 1.1.45
or so, but was fixed when I went to 1.1.50.  Now it's back in 1.1.53.  I
haven't tried 1.1.54 yet, perhaps it's already fixed.  Anyone know what
causes this?

  I tried re-compiling them with the new include files, but this made no
difference.  I am using gcc 2.5.8, libc 4.5.26, and XFree86 2.0 (for xarchie).
My system was once Slackware 1.1.1 (but that was long ago...;-) ).

  Oh yeah, my network connection is via SLIP.  I have no ethernet card, and
none configured in my kernel either.

---
Marc Fraioli          | "They couldn't hit an elephant at this dist- " 
[email-masked]         |    - Last words of Union General John Sedgwick,
                      |    Battle of Spotsylvania Court House, U.S. Civil War

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

From: [email-masked] (A.E. Brouwer)
Subject: Re: Floppies still don't work under 1.1.54
Date: 16 Oct 1994 00:43:17 +0100

[email-masked] (Shaune Beattie) writes:

>I couldn't access my floppy under 1.1.53 same happens with 1.1.54, 51 and 52 
>were fine though (apart from the umount problem in 51).

>beattie:~# mount /dev/fd0 /floppy/
>mount: /dev/fd0 is not a valid block device
>beattie:~# fdformat /dev/fd0
>ioctl(FDGETPRM): No such device

Yes, it will set the changed_floppies bit,
and then the fragment
        if (filp->f_mode & 3) {
                UDRS->last_checked = 0;
                check_disk_change(inode->i_rdev);
                if (test_bit(drive,&changed_floppies))
                    RETERR(ENXIO);
        }
of floppy_open() returns ENXIO.

Another bug I stumbled onto:
If you insert a 5.25" floppy the wrong way, then a timeout
will occur, and the flag PROVEN_ABSENT is set.
After that /dev/fd1 is unusuable, since that flag is never
cleared again. (But you can always reboot.)

For the time being is is perhaps easier to use old kernels
when floppy access is required.

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

Crossposted-To: comp.os.linux.misc
From: [email-masked] (Karsten Mauler)
Subject: Re^2: Beautifying Linux/Xfree
Date: Thu, 13 Oct 1994 17:54:00 +0100

Hi DAVID                                                   13.10.94 / 18:53

d> This is arleady avialable.  Try GREAT.  Really.  It takes a while to
d> configure, and you should have Motif to get the best performance, but it
   Is it right, that motif is a comercial prog ? Or is there a free
   port ?

"Ansehen ist der gut Ruf, den man geniesst, weil viele schweigen."
 (Zitat: Earl of Chesterfield 1694-1773)

Cu

        /                             Fido       :Karsten Mauler@2:241/565.27
   **   \ mokie  **                   Z-Netz     :[email-masked]
        /                             Inernet    :[email-masked]

## CrossPoint v3.02 R ##

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

From: [email-masked] (Thomas Koenig)
Subject: Optimizing the NFS server
Date: 16 Oct 1994 00:11:37 GMT
Reply-To: [email-masked]

Well, the NFS client code finally got some attention; performance
isn't bad, it seems.

What about he NFS server?  It's also far from fast, at the moment;
I see several bottlenecks:

- The RPC code has too much overhead.  It would be better to rewrite
  the protocol parsing stuff from scratch, using 'raw' C.

- Other Unices have the advantage of being able to server multiple
  requests by having multiple in-kernel NFS servers, which can serve
  multiple requests concurrently.  For example, this means that one
  process can do the CPU work to check a request while another one
  is waiting for data to come from the disk.  Linux nfsd, which is
  a user-level daemon, can't do this (being single - threaded).
 
A couple of random thoughts...

The clone() system call would be ideal for that, but it seems to be
on the back burner until at least 1.3.  Has anybody given it thoughts?

Another possibility would be to implement a non - blocking read from
disk.  The NFS server would then be able to handle requests coming
in from the network while the disk was busy.

Thoughts, anybody?
--
Thomas Koenig, [email-masked], [email-masked].
The joy of engineering is to find a straight line on a double
logarithmic diagram.

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

From: [email-masked] (Scott Jennings)
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.prog,dc.org.linux-users
Subject: Re: Linux v1.0 SMAIL problem
Date: 16 Oct 1994 00:28:25 GMT

Caesar M Samsi ([email-masked]) wrote:
: I got smtp working with smart-host, but direct smtp with MX records still 
: eludes me.

the smail that came with slackware 2.0 had to be recompiled here to get it
to look up MX records.  Works great now.

 -smj

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

From: [email-masked] (R Vincent)
Crossposted-To: comp.os.386bsd.development
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: 15 Oct 1994 19:23:53 +0200

Ken Hughes ([email-masked]) wrote:

: Normally I would agree, but in this case I doubt that ignoring the
: questions will stop them from being asked.  New people come into these
: groups all the time and so these questions are bound to keep coming up.
: The problem is, as you point out, not the questions but the answers.  It's

How about we just randomly assign a person to an operating system?

Person 1: "Which is better - FreeBSD, NetBSD or Linux?"
Answer 1: "FreeBSD"

Person 2: "Which is better - FreeBSD, NetBSD or Linux?"
Answer 2: "NetBSD"

Person 3: "Which is better - FreeBSD, NetBSD or Linux?"
Answer 3: "Linux"

The answer will always be correct if it comes from the right person.
Of course, only *one* person must answer each question.

That way the person stops nagging and the work continues.  :->

*slinks back into his hole*

 -Russell

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

From: [email-masked] (Shaune Beattie)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 15 Oct 1994 12:45:28 GMT

Dominik Kubla ([email-masked]) wrote:

:    Which version of the libraries/compiler/ld.so/shell are you using?
:                                                  ^^^^^

libraries and ld.so i'll have to go check (not at my computer at the moment.
compiler.. the pentium patched gcc 2.5.8 using -mpentium -O4, but I also 
tried it with -m486 / -O2 and it didn't make a lot of difference.

: That is the point. Usually under linux /bin/sh is linked to /bin/bash.
: But imagine if it was either pdksh,ash or a stripped down bash (that is
: using config.h.mini resulting in a bash w/o history and readline) or
: even a zsh. That will make a lot of difference.

using the stock bash shell. (again not quite sure what version.. whatever 
came with slakware 2.0 as haven't upgraded that).

: I think that the library or the compiler are only do little to the
: performance (but i might be wrong). I am not so sure about ld.so ...

I'll check up the version numbers as soon as I get back to my computer.

:    Thanks to all the folks who are running the benchmark as well.  This is a
:    time consuming process and you all deserve a share of the credit!

I certainly don't envy doing that list of benchmarks you've done... must 
have taken ages.

: What about using the SPEC benchmark ? v1.2 is available on FTP. I will try to
: run the suite over the weekend.

If anyone is interested in the results on my machine I'll certainly post 
them, although as was originally said to be of any real use they need to 
be run on the same (or similiar machines) to really mean anything.

 -----------------------------------------------------------------------------
|Snail:                  |Email: (choose one of)     |Tel: +44(0)223 501878   |
|Shaune Beattie          [email-masked]        |                        |
|St. Catharine's College [email-masked] |Thought for the day...  |
|Cambridge CB2 1RL       |                           |I need a better sig :)  |
 -----------------------------------------------------------------------------

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

From: [email-masked] (Timothy Demarest)
Subject: Where to find latest changes.xx files?
Date: 13 Oct 1994 11:35:58 GMT

sunsite and other mirrors dont seem to have the latest changes files
for the newer kernels.  Where can I find some info on what changes are
taking place?

--
Timothy Demarest   | Radiation Effects Research Foundation| WWW: http://
[email-masked]| Research Information Center          | aqua.rerf.or.jp/
CIS: 100212,562    | 5-2 Hijiyama Park, Minami-ku         | .Inside/demarest/
                   | Hiroshima 732 Japan                  | NewChiba.html

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

From: Derrik Walker II <[email-masked]>
Subject: Re: GNUStep...Is It Real or Just a Hoax?!?
Date: Sat, 15 Oct 1994 17:18:32 GMT

On Fri, 14 Oct 1994, Bill Broadley wrote:

> 
> How much are RS/6000's going for?
> 

Last I heard, There was a new PreP Cmpliant Rs/6000 with a 15" monitor, 
340 Meg HD (Only bad part) 16 Mags of Ram, several PCI and ISA slots, and 
a DAt Drive, as well as on board Hihg speed SCSI port, and AIX installed 
with lisence for around $4000.00.  Not much, but a little steep for a 
college studnet:(

That is the complete system - quite usable.  The Indy for $5000.00 
doesn't include as much ram, and I don't think that price includes the OS.

-Derrik
===============================================================================
 Derrik Walker II                                 Student of Computer Sciences
 Cleveland State University                  Automation Assistant, Law Library
 [email-masked]                            [email-masked]
===============================================================================
        http://pclab19.law.csuohio.edu:8099/html/dwalker/home.html

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

From: [email-masked] (Rob Janssen)
Subject: Re: Kernel 1.1.53 - no BOOM
Reply-To: [email-masked]
Date: Sat, 15 Oct 1994 09:34:20 GMT

In <[email-masked]> [email-masked] (Larry Butler) writes:

>In article <wcreator.781994946@kaiwan009>,
>Steven M. Doyle <[email-masked]> wrote:
>>In <[email-masked]> [email-masked] (Mark A. Horton KA4YBR) writes:
>>>Console: colour EGA+ 132x44, 24 virtual consoles
>>>Serial driver version 4.00 with no serial options enabled
>>>tty00 at 0x03f8 (irq = 4) is a 16550A
>>>tty01 at 0x02f8 (irq = 3) is a 16550A
>>>tty02 at 0x03e8 (irq = 4) is a 16550A
>>>tty03 at 0x02e8 (irq = 3) is a 16550A
>>
>>One interesting point is the sharing of IRQ's between tty0/2 and tty1/3.  This may
>>be causing part of your problem (only thing I can suggest not knowing exactly how
>>your link is set up)
>>

>This may be stupid, but I was wondering why the interrupt handler can't
>check for received data in both UARTs. If it is possible to poll the UARTS
>why can't this be done? Would it make the interrupt handler too time
>consuming?

No, it cannot be done because IBM was so stupid to design the interrupt
architecture in such a way that an interrupt will only come in when *BOTH*
devices on the same line request an interrupt.
This is one of the major design errors in the ISA BUS, and there is nothing
you are going to do about it in software.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: 3c505 driver ?
Reply-To: [email-masked]
Date: Sat, 15 Oct 1994 10:03:34 GMT

In <[email-masked]> [email-masked] (John Huang) writes:

>Does 3c503 driver works with 3c505 card?

No single 3com driver works with a card of another number than it is written
for.

>I tried to configure the kernel to include the 3c503 driver but it don't 
>recognize my card. I know the linux has support for all the 3com card except
>for 505. I tried my 3c501 card, and it works.

>Any help for 3c505 driver?

The distributed kernels (at least the 1.1.5x) contain a 3c505 driver which
is marked ALPHA.  So when you select ALPHA drivers you can configure it.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Frank Lofaro)
Subject: Re: PGP for Linux??
Date: Sat, 15 Oct 94 04:36:25 GMT

In article <[email-masked]> [email-masked] (Jinwoo Shin) writes:
>[email-masked] (Brian J. Swetland) writes:
>
>>PGP is available at ftp.netcom.com in /pub/mpj, I believe...
>>Their is also a site at MIT, but I'm not entirely sure on that.
>
>There is pgp.faq. I remember getting from MIT sometime ago, you have to telnet
>there, answer all the legal junks, and ftp within ten minutes to the site then
>you can grab it. I thought the new ones licensed NSA, is it true?
                                                  ^^^

What an interesting slip of the tongue!
Anyway, it's RSA, not NSA.
The NSA (National Security Agency) doesn't like PGP very much! :)

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

From: [email-masked] (Rob Janssen)
Subject: Re: Improving SLIP latency under Linux
Reply-To: [email-masked]
Date: Thu, 13 Oct 1994 22:52:18 GMT

In <[email-masked]> [email-masked] (Michael Callahan) writes:

>In article <[email-masked]>, Rob Janssen <[email-masked]> wrote:
>>According to Al Longyear:
>>> For this to work the best, you need to implement IP_TOS on both sides
>>> of the link. If you are doing an ftp transfer to read a large file,
>>> then it the remote side (the one running ftpd) which is doing the
>>> majority of the transmission. Their frames need to have a background
>>> (7) priority.
>>
>>Note in my application Linux on one side is used only as a router.
>>I cannot change the ftpd.  So, if it does not use another than the default
>>TOS, I will not have this advantage when using TOS based queueing.

>OK, if you really can't get the remote end to do TOS correctly,
>and you want to do the TCP-port-number hack, put an appropriate
>hook in the ip_forward routine in net/inet/ip.c just before it 
>examines the TOS field to decide what queue to use.

This can easily be combined with packet filtering functionality.
I think people are working on packet filtering.  Do it like this:

each packet is examined and matched with the (compiled) filtering
rules.   when a rule is found, this is not treated merely as a
discard/allow switch, but a value is associated with the rule.

this can then be interpreted as:

0 - discard the packet
1 - treat with low priority
2 - treat with medium priority
3 - treat with high priority

as the filtering rules (for any usable filtering) already should be
able to look at protocol and port number, these two functions are
conveniently combined.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Improving SLIP latency under Linux
Reply-To: [email-masked]
Date: Thu, 13 Oct 1994 22:54:09 GMT

In <[email-masked]> [email-masked] (John Richardson) writes:

>I'm not sure about this: I don't think my modem has a transmit
>buffer (hehe, try getting information from supra! Argh) and 
>I have a laggy interactive response.  I have been in contact
>with linux users who have faster modems with no internal buffers
>at all who suffer from the same problem.

All modems with error correction and compression have a transmit buffer.
The only variation between modems may be how large this buffer is.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

** 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.development) 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-Development Digest
******************************