lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest322
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

709 lines
25 KiB
Plaintext
Raw Blame History

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: Mon, 17 Oct 94 05:13:05 EDT
Subject: Linux-Development Digest #322
Linux-Development Digest #322, Volume #2 Mon, 17 Oct 94 05:13:05 EDT
Contents:
Re: Problems compiling 1.1.54 (WE Metzenthen)
mtools & to many devices (Chris Origer)
Re: Any plans for 'trace'? (Rob Janssen)
Re: Adaptec AHA-2940 PCI SCSI card support.... (PETE KORNER)
Re: NFS over TERM? (Donald Becker)
Re: Mathematical functions with c (Eberhard Moenkeberg)
Re: Improving SLIP latency under Linux ("Eric Jeschke")
File Attributes (or resource forks) was: Re: ext2fs vs. Berkeley FFS (Robert Andrew Ryan)
Re: Chaning text mode after bootup (A.E. Brouwer)
Moving technology forward --- alpha pagers (Jesus Monroy Jr)
Re: Linux killed my floppy drive! (Rob Janssen)
Re: ext2fs vs. Berkeley FFS (H. Peter Anvin)
Amateur Radio- IPIP daemon patch (Donald Jeff Dionne)
Re: Shared Libs: working toward a permanent solution? (Bruce Thompson)
Kernel: TCP HANGS again! What is happening? (Bart Kindt)
Re: Extreme delays telnetting into linux box (Bart Kindt)
Re: Beautifying Linux/Xfree (jon m)
----------------------------------------------------------------------------
From: billm@jacobi.maths.monash.edu.au (WE Metzenthen)
Crossposted-To: aus.computers.linux,latrobe.linux
Subject: Re: Problems compiling 1.1.54
Date: 17 Oct 1994 03:14:59 GMT
Huw Davies (cchd@lucifer.latrobe.edu.au) wrote:
: I've just applied the 1.1.54 patches to a (working) copy of 1.1.53, ran
: make config choosing the usual group of options (although I added ISO9660
: support which I must have accidentally turned off building 1.1.53) and
: then ran make zImage. Sadly I get compile time errors (see below). I've
: tried rebuilding the compiler with and without elf support but the errors
: remain.
: Given that noone else has complained, I assume that it's a problem with
: my setup (most likely, I need a later version of something). Any pointers
: appreciated.
: Here is the section I'm having difficulties with....
: make[2]: Entering directory `/usr/src/linux/fs'
: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f
: rame-pointer -pipe -m486 -DMODULE -c binfmt_elf.c
: binfmt_elf.c:36: warning: function declaration isn't a prototype
: binfmt_elf.c:825: redefinition of `padzero'
: binfmt_elf.c:61: `padzero' previously defined here
(Almost) Everyone applying patch54 would get the same problem. Here
is what I did:
RTFM (Read The Failure Message ;-), then look at binfmt_elf.c and
take about 1 minute to conclude that binfmt_elf.c actually contains
two complete (but slightly different) versions of the same thing.
Then look at patch54.gz to confirm that Linus didn't have a
binfmt_elf.c to patch against -- SNAFU.
Solution: A number of possibilities, but I chose to edit binfmt_elf.c
by hand to remove the old version from the file.
--
Bill Metzenthen
Mathematics Department
Monash University
Clayton, Victoria, Australia
email: billm@vaxc.cc.monash.edu.au
billm@euler.maths.monash.edu.au
------------------------------
From: ctoriger@starbase.neosoft.com (Chris Origer)
Subject: mtools & to many devices
Date: 16 Oct 1994 22:08:07 GMT
Hi, I'm trying to use four floppies with mtools and its not working.
I have three line for each device e.g.
A /dev/fd0 12 80 2 18 # fisrt floppy
A /dev/fd0 12 80 2 18 # low density
A /dev/fd0 12 0 0 0 # generic autodetect
B /dev/fd1 " "
B ...
B ...
D /dev/fd2 12 80 2 15
D " "
D " "
E /dev/fd3 12 80 2 15
E " "
E " "
#
C /dev/hdb4 16 0 0 0
If I use the above I get to many devices.
If I take out E it works fine.
Any ideas? Thanks
Chris
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Any plans for 'trace'?
Reply-To: pe1chl@rabo.nl
Date: Sun, 16 Oct 1994 12:23:02 GMT
In <CxrAD9.L4s@lehman.com> justinb@lehman.com (Justin Beech) writes:
>One command I sorely miss, especially when things are not
>going well, is 'trace', the Sunos command for spewing out
>the system calls a process does, with arguments.
>I know this is Sun special, but its a very useful special.
>Anybody else miss trace?
No, we are not missing it. Because it has been there for a long time
already.
Under Linux, it is called "strace".
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: pkorn@ix.netcom.com (PETE KORNER)
Subject: Re: Adaptec AHA-2940 PCI SCSI card support....
Date: 16 Oct 1994 21:13:33 GMT
In <37nrg3$lku@nic.umass.edu> cmay@titan.ucs.umass.edu (Christopher M. May) writes:
>
>: Big deal, they don't have email support, wow, 1-800 numbers, what a
>: shame. Come on, adaptec support is excellent.
>
>
>: Mark> So there you have it... call your vendor and
>: Mark> complain... don't complain about Linux not supporting YOU,
>: Mark> complain about your hardware vendor not supporting YOU! :)
>
>
>Anyone know of ANY linux drivers that were written by the hardware
>vendor?
>
>I thing some of the intelligent serial boards come with drivers......
>
>
>
>LInux moves too fast for any of those guys to keep up with.
>
>
Ya because it's too buggy :(
>They'd have to release updates weekly...
>
>--
>
>-Chris May, Computer Science, University of MA, Amherst
>- Technical Assistant, P.C. Maintenance Lab
>
>
------------------------------
From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Subject: Re: NFS over TERM?
Date: 16 Oct 1994 09:15:33 -0400
In article <CxrGsE.H1C@sci.kun.nl>, Patrick Reijnen <patrickr@cs.kun.nl> wrote:
>In <1994Oct15.175734.27451@excaliber.uucp> joel@wam.umd.edu (Joel M. Hoffman) writes:
>
>>I've asked this before, but I got no response. I'll try one more time:
>
>>Is there any way to remote NFS mount a directory via term?
>
>Nope, at this moment this is not possible. Problem is the NFS server is only
> supposed to accept requests if the socket requesting the connection is bound
> to a port below 1024.
Read the manual page to the Linux 'nfsd'. The '-n' option configures the
NFS server to accept "insecure" requests.
--
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
------------------------------
Date: Sat, 15 Oct 1994 22:32:41 +0100
From: Eberhard_Moenkeberg@p27.rollo.central.de (Eberhard Moenkeberg)
Subject: Re: Mathematical functions with c
Hello norbert.kuemin and all others,
on 12.10.94 norbert.kuemin wrote to All in USENET.COMP.OS.LINUX.DEVELOPMENT:
n> Does anyone now which library i must link to use the definitions from
n> /usr/include/math.h ???
Yes. Ask the readers of C.O.L.help.
Greetings ... Eberhard
------------------------------
From: "Eric Jeschke" <jeschke@cs.indiana.edu>
Subject: Re: Improving SLIP latency under Linux
Date: Tue, 11 Oct 1994 13:56:43 -0500
longyear@netcom.com (Al Longyear) writes:
[clip]
:networking software. (If you use my favorite ftp client, ncftp, then
:you need a fairly new one which supports the IP_TOS socket option.)
What version of ncftp?
--
Eric Jeschke | Indiana University
jeschke@cs.indiana.edu | Computer Science Department
------------------------------
From: Robert Andrew Ryan <rr2b+@andrew.cmu.edu>
Subject: File Attributes (or resource forks) was: Re: ext2fs vs. Berkeley FFS
Date: Tue, 11 Oct 1994 14:45:22 -0400
(discussion about pros&cons of ext2fs and ffs, and about where file
attributs belong deleted.)
The standard unix filesystem certainly provides enough generality that
file attributes (ala mac resource forks) could be implemented in the
user level software. There is a potential problem with this approach.
The unlink system call couldn't be made atomic in user level code. The
process performing the unlinking of the resource files might be killed
before it completes the task. This could leave the file resources in an
inconsistent state. Presumably an atomic operation would at least be
used to mark the file as deleted, but a scavenger would have to be used
to complete partial deletions.
There are logical issues as well, such as whether editing such a file
and then save it in a non-resource aware editor will the resources be
preserved? A common idiom in the code for my project (AUIS) is to write
the data out to a new file, unlink the old file, and rename the new one
to the old. This process ensures that if the new data cannot be written
no data will be lost. Emacs writes over the existing file, I assume it
provides safety by first copying the existing file before writing in the
new data. Thus among non-resource aware applications differences in
implementation can produce undesired differences in how resources are
treated.
Lastly, COSE is working on a standard for a Unix desktop (CDE). As more
unix platforms gain use desktops and interoperability between them will
become more of an issue.
Ideally I would like to see a CDE implementation for Linux, but this
would some funding in order to get the specs at least.
-Rob
------------------------------
From: aeb@wsdw01.win.tue.nl (A.E. Brouwer)
Subject: Re: Chaning text mode after bootup
Date: 16 Oct 1994 14:01:55 +0100
rasumner@calum.csclub.uwaterloo.ca (Reuben Sumner) writes:
: After seeing the nifty new patch to 1.1.54 I worked on being able to set
: my text mode at run time and have enjoyed limited success (scripts and
: C program follow). I can now switch between 80x25, 80x28 and 80x50
: freely. However when it comes to 132x25 it just doesn't go.
: ...
Probably you had not seen kbd-0.88, that already contains
a somewhat more elaborate version of the program you gave.
[By the way, the kernel patch in there is no longer required
since it was part of the patch that created 1.1.54.]
What goes wrong with 132x25? Does the svgalib restoretextmode not work?
------------------------------
Crossposted-To: comp.os.386bsd.development
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Moving technology forward --- alpha pagers
Date: Mon, 17 Oct 1994 04:04:47 GMT
Hello and thank you for reading this note.
Today, 10-16-94 at 8:47 pm (Pacific Daylight Time) I am
making a call to test the new internet connected pager from
Notable technologies in Oakland. The test is being conducted
by WCO (West Coast Online) magazine. Our hope is to show that
the growth of the Internet is not quirk of government
"wish listing", followed by media hype.
What I need from you my friends is an e-mail message.
This message will hit the gateway machine and page me
24 hours a day. Please send me this information:
your name
your location in the world!
your local time
your message
MY EMAIL address is: jmonroy@airnote.net
Messages longer than 99 characters will be truncated.
Also as a service to the sender, the gateway machine will
send you a copy of your message sent to me, complete with
time stamp.
Thank you for your help.
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________
------------------------------
Crossposted-To: comp.os.linux.help
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux killed my floppy drive!
Reply-To: pe1chl@rabo.nl
Date: Fri, 14 Oct 1994 18:20:52 GMT
In <CxMnFE.4Do@oea.xs4all.nl> ahmed@oea.xs4all.nl (Ahmed Naas) writes:
>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>: The answer probably is: Yes, Linux killed your floppy drive.
>: When you would have used another (much more popular) operating system
>: for the PC, the system would have been rebooted several times a day, the
>: floppy would have seeked each time it went to the BIOS selftest, and dirt
>: would not have accumulated on the mechanism.
>: Don't run stable operating systems! They may kill your drive!
>Rob,
>I hate to disappoint you but I also run DOS/WIN and NT on the same
>machine. Flame away :-)
Ahh but you did not tell that before...
How can you be sure it wasn't killed by one of those systems??
Rob
7:20pm up 24 days, 19:32, 8 users, load average: 0.11, 0.06, 0.02
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: ext2fs vs. Berkeley FFS
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Tue, 11 Oct 1994 21:21:57 GMT
Followup to: <ADC.94Oct11131031@zeta.coe.neu.edu>
By author: adc@zeta.coe.neu.edu (Albert D. Cahalan)
In newsgroup: comp.os.linux.development
>
> No, it's not at all.
>
> 1: File operations do not work the same. Try gzipping a directory
> without tar.
> 2: There is no way to recognize these directories as complete units.
> 3: File managers will open them as directory trees, because that is
> what they are, NOT record type files.
>
1. The gzip format doesn't support multiple forks anyway.
2. This a modification to user mode utilities, not to the kernel.
3. That is also what a multistream file really is.
The point is that, sure, you can have "multistream files", but there
is no need for any kernel modifications: all that would be needed is a
standard way of identifying these as "opaque" directories, and a
sh*tload of modifications to user level utilities (which would have to
be done anyway!!).
/hpa
--
INTERNET: hpa@nwu.edu --- 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
... but his bosses didn't like him so they shot him into space ...
------------------------------
From: jeff@storm.ee.ryerson.ca (Donald Jeff Dionne)
Subject: Amateur Radio- IPIP daemon patch
Date: 13 Oct 1994 18:09:15 GMT
Here is a quick hack patch to get BDale Garbie's ipip daemon to build on Linux.
I've only tested it so far as to see that packets go in - they come out,
other than that, I don't know yet. For those that don't know, IPIP is used
for Internet <-> AMPRnet (HAM Radio) gateways. I will be testing this out
in more detail over the next little while, and if it works ok, we will
switch the toronto gateway to Linux!!
To use this, you need BDale's ipip.tgz from hpcsos.col.hp.com:/hamradio/ipip.
73! de Jeff / VE3DJF
Jeff@EE.Ryerson.Ca
========= patch starts here ========
diff --unified --new-file ipip.bdale/Makefile ipip/Makefile
--- ipip.bdale/Makefile Tue Feb 8 23:59:28 1994
+++ ipip/Makefile Wed Oct 12 11:39:19 1994
@@ -1,8 +1,21 @@
-PROG= ipip
-BINDIR= /usr/local/etc
-SRCS= config.c ip.c main.c route.c run.c slip.c tun.c
-CFLAGS+= -DBDALE -DAMPRONLY -g
-LDFLAGS+= -g
-NOMAN=1
+all: ipip
-.include <bsd.prog.mk>
+CFLAGS = -O2 -g
+# -DBDALE
+CC = gcc
+LD = ld
+AR = ar -r
+RM = rm -f
+
+IPIPOBJS = config.o ip.o main.o route.o run.o slip.o tun.o
+
+ipip: ipipobjs
+
+ipipobjs: $(IPIPOBJS)
+
+ $(CC) $(CFLAGS) $(IPIPOBJS) -o ipip
+
+clean:
+
+ $(RM) ipip
+ $(RM) `find . -name '*.[oa]' -print`
diff --unified --new-file ipip.bdale/README.Linux ipip/README.Linux
--- ipip.bdale/README.Linux Wed Dec 31 18:00:00 1969
+++ ipip/README.Linux Wed Oct 12 12:26:55 1994
@@ -0,0 +1,8 @@
+This is my port of BDale's IPIP daemon to Linux. I've built it on
+Linux1.1.23 without a problem, and if it actually works ok I'll
+release it public. All that needed changing was an #ifdef __BSDI__
+to #if 1 and a couple of references to the ip headers. All this stuff
+should be in #ifdefs, and I'll get around to that before a public release,
+for now it just builds. That's ok for a Real Quick Hack.
+
+Jeff@EE.Ryerson.Ca
diff --unified --new-file ipip.bdale/ip.c ipip/ip.c
--- ipip.bdale/ip.c Mon Oct 18 23:43:54 1993
+++ ipip/ip.c Wed Oct 12 11:52:15 1994
@@ -88,7 +88,7 @@
{
unsigned char buf[MAX_SIZE], *p;
int n, hdr_len, fromlen;
- struct ip *ipptr;
+ struct iphdr *ipptr;
struct sockaddr_in ip_from;
CK_IFNULL(ifp);
@@ -114,8 +114,8 @@
if(ifp->type == IF_TYPE_IPUDP){
p = buf;
} else {
- ipptr = (struct ip *)buf;
- hdr_len = 4 * ipptr->ip_hl;
+ ipptr = (struct iphdr *)buf;
+ hdr_len = 4 * ipptr->ihl;
p = buf + hdr_len;
n = n - hdr_len;
}
diff --unified --new-file ipip.bdale/ipip.h ipip/ipip.h
--- ipip.bdale/ipip.h Tue Jan 18 11:24:35 1994
+++ ipip/ipip.h Wed Oct 12 11:41:55 1994
@@ -100,7 +100,7 @@
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
-struct route {
+struct encaproute {
unsigned long ipaddr; /* the ip address (network order) */
unsigned long mask; /* the bit-mask to apply */
struct interface *destif; /* the destination interface */
@@ -111,7 +111,7 @@
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
-struct route rts[MAX_ROUTES];
+struct encaproute rts[MAX_ROUTES];
int rts_top;
struct interface ifs[MAX_IFACES];
Common subdirectories: ipip.bdale/samples and ipip/samples
diff --unified --new-file ipip.bdale/slip.c ipip/slip.c
--- ipip.bdale/slip.c Tue Jan 18 11:24:45 1994
+++ ipip/slip.c Wed Oct 12 11:56:32 1994
@@ -26,7 +26,7 @@
#include <errno.h>
#include <syslog.h>
-#ifdef __bsdi__
+#if 1
#define USE_TERMIOS
#endif
Common subdirectories: ipip.bdale/test and ipip/test
------------------------------
From: bruce@mdavcr.mda.ca (Bruce Thompson)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 17 Oct 94 06:20:37 GMT
Shannon Hendrix (shendrix@escape.widomaker.com) wrote:
: Actually, I'd love to see Multics (or something close) that I could
: play with. I always wanted to get a chance to learn/use Multics but
: now I guess that won't ever happen.
Ok, this has nothing to do with Linux and for that I apologize in
advance, but I couldn't resist.
If you _really_ want to work on Multics, get a job with ACTC
Technologies in Calgary, Alberta. They're the only (I think) software
support site left for Multics. I _still_ think that Multics is (in
some ways) far ahead of everybody else. If only it was on more modern
(faster) hardware.
Cheers,
Bruce.
--
Bruce Thompson, B.Sc. | "A great many people think they are
Software Engineer | thinking when they are merely
MacDonald Dettwiler, | rearranging their prejudices."
13800 Commerce Parkway, | -- William James
Richmond, BC |
(604) 278-3411 | Usual disclaimers apply
NAPRA #473 |
------------------------------
From: bart@dunedin.es.co.nz (Bart Kindt)
Subject: Kernel: TCP HANGS again! What is happening?
Date: Sat, 15 Oct 1994 18:52:20 GMT
Just now it happened again: All TCP traffic suddenly hangs for many minutes!
Okay, here goes: Slackware 1.2 distribution. Kernel 1.1.52. Running: named,
gated, Smail as DAEMON, httpd as daemon.
I run a multi-line Internet SLIP Dial-In service. At the time of the problem,
nobody was online. I tried to send a E-Mail prepared on Windows Eudora, via
SMTP over the Ethernet link between the Linux server and my Windows computer.
The SMTP transfer was suddenly hanging.
I type Netstat on the Linux box: 3 connections: One international SMTP
Establised but not moving; One SYN Received, and my own SMTP Establised and
hanging. I type PS. I see 2 smtpd's in the list: the base daemon, and one
forked. This is one short. The should have been a third one. I enable
tracing on the Windows WinSock program: Except for the 30 seconds routing info
from gated, no traffic. Everything simply hangs.
All other Linux stuff works normally. I start TOP and have a look. Lots of
memory free, swap not in use.
After about 5 minutes, suddenly everything starts working again; My SMTP goes
through; the SYN Received is suddenly gone (!!) and the other international
smtp goes through in the next minute.
I know from experience, that all other TCP traffic like Telnet, Ftp etc. also
hangs.
This is a serious problem, which many people have in various forms, sometimes
on PPP and SLIP links, often when they try to start a Telnet connection: The
connection is established, but no login prompt appears. It looks like the
Kernel makes the connection, but fails to start the appropriate program.
Strange enough, I now run smtpd as a daemon, instead via the inetd program,
and this makes *no difference!* So, it is *not* just related to inetd as some
people have thought. These must be some kind of bug in the TCP code. I wish I
knew how to fix it myself...
Can some Kernel wizz please have a look at it? I am happy to help with it if
I can!
Thanks, Bart.
====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================
------------------------------
Crossposted-To: comp.os.linux.admin
From: bart@dunedin.es.co.nz (Bart Kindt)
Subject: Re: Extreme delays telnetting into linux box
Date: Sat, 15 Oct 1994 19:22:36 GMT
In article <37jjbp$fhf@library.erc.clarkson.edu> komarimf@craft.camp.clarkson.edu (Mark 'Enry' Komarinski) writes:
>Klaus Lichtenwalder (klaus@gaston.m.isar.de) wrote:
>: barkerc@GRAPHICS.CS.NYU.EDU (Chris Barker) writes:
>: >[...]
>: >delays when telnetting into my box from my PC over ethernet. Upto a minute of
>: >delay before I see the issue.net message and a login prompt. This did not occur
>: >using the 1.1.0 kernel. It also takes a long time to ping the box, although
>: >pinging my PC from the linux box is ok and telnetting out over my slip is fine.
>: >I am using gated 3.5 alpha, but this was happening even running routed. Every
>: >thing is fine once I get in, but it is so slooooow to login! Any ideas?
>: Yeah, have a look at /etc/resolv.conf. There might be a reference to an
>: unknown name server. Looking up this name server gives a timeout, that's
>: (perhaps) your delay. Also have a look at /etc/host.conf whether bind
>: or nis is referenced. If there's no name server (and no nis for that
>: matter) you might as well delete these key words, leaving only hosts
>: (for looking in /etc/hosts).
>We have a similar login problem, especially when connecting to a MUSH
>port. The connection from a remote host can (sometimes) sit there forever.
>If, however, from the machine I connect to that port (telnet localhost 7567)
>the connection from remote becomes instantly connected. We were at first
>thinking this is a problem with our code, as regular telnet appears to
>work okay(who knows where that lag comes from? :). But these
>problems may be related. Running 1.1.49 on a Slackware setup.
There is a serious problem with the TCP in the new kernels. I (and many
others) have been posting about it for months, but sofar I have never seen any
reply from a Kernel developer. Have a look at all postings about Telnet, Ftp
delays/hangups etc.
Please, is there any developer who can look into this TCP problem?
====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================
------------------------------
Crossposted-To: comp.os.linux.misc
Subject: Re: Beautifying Linux/Xfree
From: icqo409@iupui.edu (jon m)
Date: 11 Oct 94 01:09:21 -0500
In article <372tg0$1ai@huron.eel.ufl.edu>,
Alexandra Griffin <acg@kzin.cen.ufl.edu> wrote:
> Well, you mentioned NextStep-- on second thought, something
>similar to the wonderful NeXT Workspace Manager application would be
>delightful to have. For those who have never seen it, this program
well, don't wait, gfm (with the GREAT distribution) is VERY nice
for the time being. shucks, i'd get all of GREAT if i had
the space!
>-- alex
jon
--
jon madison
oit consultant in training
"A year spent in artificial intelligence is enough to make one believe
in God." -anonymous, from a fortune program on one of my accounts. :)
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink