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/digest287
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

691 lines
26 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, 10 Oct 94 15:13:11 EDT
Subject: Linux-Development Digest #287
Linux-Development Digest #287, Volume #2 Mon, 10 Oct 94 15:13:11 EDT
Contents:
Hardware PROBLEM HELP! (Axel Winter)
Re: 3c503 problem (Greg Bruell)
Re: Beautifying Linux/Xfree (Oliver Mai)
Re: Improving SLIP latency under Linux (Rob Janssen)
tty bug and fix (for 1.1.51) (Frank Lofaro)
Re: Improving SLIP latency under Linux (Rob Janssen)
Re: Question: Any DOS/4GW? (Rob Janssen)
executable size too big (Ramana Ramachandran)
tty bug and fix (for 1.1.51) (Frank Lofaro)
Re: ext2fs vs. Berkeley FFS (Hugh Strong)
Re: BSD/386 vs. Linux Performance (Alan Cox)
----------------------------------------------------------------------------
From: wintera@morakot.nectec.or.th (Axel Winter)
Subject: Hardware PROBLEM HELP!
Date: 8 Oct 1994 04:17:33 GMT
Hallo,
I really have a problem with my hardware ... If I touch
any place of the system or a conected part (priter, termial)
at a place where is steel, i get a eletric shock. Next to that
sometimes the keyboard stopps working at all ... The system
isn't halted or jump off ... it's only the keyboard which is off
line (mouse, terminals etc. works fine) ... May be this is an
effect from electric ... The system is operated by 220V here in Thailand.
Hope some can help.
Axel
------------------------------
From: gbruell@wellfleet.com (Greg Bruell)
Crossposted-To: comp.os.linux.help
Subject: Re: 3c503 problem
Date: 10 Oct 1994 15:41:05 GMT
OK. I've done some more homework. Based on looking at net/inet/dev.c
to find where /proc/net/dev is created I found the stat rx_errors.
I grepped for that and found it in several places but the only place
in the 3c503 driver was actually in the file 8390.c. Here's the code:
/* Check for bogosity warned by 3c503 book: the status byte is n
ever
written. This happened a lot during testing! This code shoul
d be
cleaned up someday. */
if (rx_frame.next != next_frame
&& rx_frame.next != next_frame + 1
&& rx_frame.next != next_frame - num_rx_pages
&& rx_frame.next != next_frame + 1 - num_rx_pages) {
ei_local->current_page = rxing_page;
outb(ei_local->current_page-1, e8390_base+EN0_BOUNDARY);
ei_local->stat.rx_errors++;
continue;
}
The stat is written only in drivers. It is read in only one place in the kernel.
Based on a suggestion someone sent me I tried programmed IO mode.
This worked better but not reliably. I'm not shadowing memory
according to my BIOS setup but the idea that this is related to
memory/IO conflicts seems plausible.
One last thing is that ARP works even though nothing else does.
Gregory Bruell
Wellfleet Communication, Inc.
Donald Becker (becker@cesdis.gsfc.nasa.gov) wrote:
: In article <376oda$55p@paperboy.wellfleet.com>,
: Greg Bruell <gbruell@wellfleet.com> wrote:
: >I'm seeing the same problem with:
: > 1.1.51, P60
: >
: >I've checked /var/adm/notice and /proc/net/dev and there is no
: >further information. I gave a quick glance at the driver and it
: >doesn't look like it logs much. I'm using the internal transciever.
: >The card and drop have been independently verified as functional.
: >Is anyone else seeing this with 1.1.?? ?
: What does /proc/net/dev report? The 'rx-errors' reported by ifconfig is a
: catch-all category. Most errors also cause one of the other error counters
: to increment.
: --
: 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
------------------------------
From: mai@x4u2.desy.de (Oliver Mai)
Crossposted-To: comp.os.linux.misc
Subject: Re: Beautifying Linux/Xfree
Date: 10 Oct 1994 10:47:08 GMT
...
Eric Jeschke wrote:
> If there was a default "standard" GUI available on most distributions
> it would be possible to write a introduction to Linux (a la Welch)
> from a GUI perspective. Whether this is a good idea or not depends on
> your ideas about how to teach Unix. IMHO, I think you can wean newbies
> off of the mainstream PC OSes more easily with a good GUI and then let
> them gradually cut their teeth with more and more command-line.
Agreed!
> It might be a good idea to make a
> GUI "mini-distribution" (package) that just contains a standardized
> GUI setup (GREAT + fvwm + customized *rc files + selected GUI apps).
I used to run GREAT for some time. But firstly one needs Motif
to run GREAT with acceptable performance, and secondly I think fvwm and
xfm together give at least the functionality of GREAT without requiring
as much resources. For example the GREAT filemanager might look better
than xfm, but xfm is more powerful. The xfm file and application managers
support drag and drop much better than GREAT. E.g. one can drag files
or directories directly into the application manager, then drop files onto
the icons of e.g. executables or directories in either the application
or file manager, and so on. Once one has a well preconfigured xfm and
fvwm one has a very powerful desktop, which IMO is superior to MS Windows',
because the xfm application manager is much more flexible than Windows'
program manager. Drawbacks are: 1) fvwm does not support drag and drop on
desktop icons (in contrast to Windows, but, IMO drag and drop in the
application manager is better in practice). 2) There can be only one
instance of the xfm application manager. 3) xfm is too slow (esp. changing
to directories with many files), but not compared to GREAT's filemanager
4) xfm can only do one operation a time, so if you copy a file in one
xfm filemanager window, the other xfm windows are blocked.
I would advocate a GUI package with well preconfigured xfm and fvwm.
Oliver Mai
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Improving SLIP latency under Linux
Reply-To: pe1chl@rabo.nl
Date: Mon, 10 Oct 1994 08:52:41 GMT
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.
Also, I don't really understand the "background (7) priority". I think
there are 8 priorities encoded in the TOS and 7 is the HIGHEST of them.
Besides, there are the bits that define optimization of one specific
aspect of the service. They can be used in the equation as well.
Unfortunately, existing systems send a TOS of 00, which is the lowest
priority and no specific optimization. It will be difficult to assign
relative priorities to some traffic which are lower than this default
TOS. (unless you assign it some special meaning)
> There have been kludges to support the queueing in the PPP or SLIP
> drivers. They look at the port numbers being used and determine a
> "priority" based upon the list of known interactive ports. THIS IS A
> KLUDGE. It is only because the TCP/IP software did not allow the
> application to specify the proper value.
>
> (Morningstar PPP/SLIP and the BSD pppd package are two that I am
> familiar with doing this kludge.)
I already mentioned it in my post. KA9Q is another package which uses
it. It is a kludge, but it works well.
> >Peeking in the TCP headers inside the IP routing code (checking for port
> >numbers, so that 20 and 25 can get a lower priority than 23 even when the
> >TOS is the same) seems to be the best solution... (although dirty)
>
> Why bother? It is done in all of the daemons and client code now in
> place for Linux.
That only helps when the client and server are on Linux machines.
This isn't the case in my environment. Some of them are on SYSV.4
and some on Novell machines, which are unchangable.
(no source, no knowledgable manufacturer)
> However, as the saying goes, "the proof is in the pudding". Please
> feel free to make the changes that you see fit to your copy of the
> kernel and try it out. I would be interested in hearing about your
> results.
>
> I do ask one favor (or condition if you wish). That is that you use
> the current kernel 1.1.52+ and the latest versions of all of the
> networking software. (If you use my favorite ftp client, ncftp, then
> you need a fairly new one which supports the IP_TOS socket option.)
We are now running 1.1.50 and the utilities from slackware 2.0
I hope to upgrade soon, but I often find it difficult to locate
recent versions of the networking binaries...
(kernel is no problem)
> >In fact I think the "always use a big window because that performs so
> >nicely on fast links" may be not optimal. One could argue that the optimum
> >window size for a TCP is such that it can just keep sending (i.e. an
> >ACK comes back just when the sending TCP runs out of send window), and
> >not much larger than that. The sending TCP could adapt its send window
> >accordingly (staying below the negotiated window size).
>
> That is the slow start algorithm presently in place.
I think the slow start algorithm normally does not do this. It increases
the window as long as no negative feedback (packet loss or QUENCH) comes
back, without looking at the amount of data in the send window.
It may be that the Linux implementation does this differently, but
unfortunately the structure and commenting of the code makes it difficult
to say for sure (I know KA9Q TCP well, but I am not familiar with the
Linux TCP code).
What I propose is to clip the send window at the point where there is
just enough window to keep it from stop-and-wait behaviour. Is this
currently being done?
It would be helpful when there would be more of the TCP state visible
for the user, e.g. a detailed netstat for one session. KA9Q provides
this, and it can give a lot of insight in what the different algorithms
are really doing...
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: tty bug and fix (for 1.1.51)
Date: Wed, 5 Oct 94 04:57:21 GMT
There was a bug in the tty code involving EOF and EOF characters that
was fixed a while ago, but the fix has become ineffective, and the
bug has returned. The bug involves the fact a false EOF is returned
when the EOF character is entered with characters waiting (i.e. the
EOF character is meant as a push, not as a real EOF). The latest
kernel 1.1.51 exhibits this bug.
To see the bug in action:
type dd bs=4
then enter any multiple of 4 characters, ctrl-d, and the dd will
terminate with an end of file. A lot of other un*xes screw up on this
too, but Linux had it fixed, and it was not too hard, and this patch
is not too difficult, and fixes the problem (and does not appear to
create any new bugs; I have tested it in cooked and cbreak modes,
with zero and non-zero min and time values it all seems okay).
Hopefully this (or a better, more elegant fix) will go into 1.2.0:
(I removed the old fix, since it does not do any good anymore)
diff -r -u -N linux.dist/drivers/char/n_tty.c linux/drivers/char/n_tty.c
--- linux.dist/drivers/char/n_tty.c Sun Sep 25 00:41:14 1994
+++ linux/drivers/char/n_tty.c Sun Sep 25 21:44:35 1994
@@ -453,6 +453,8 @@
goto handle_newline;
}
if (c == EOF_CHAR(tty)) {
+ if (tty->canon_head != tty->read_head)
+ set_bit(TTY_PUSH, &tty->flags);
c = __DISABLED_CHAR;
goto handle_newline;
}
@@ -718,24 +720,6 @@
*nr -= n;
}
-/*
- * Called to gobble up an immediately following EOF when there is no
- * more room in buf (this can happen if the user "pushes" some
- * characters using ^D). This prevents the next read() from falsely
- * returning EOF.
- */
-static inline void gobble_eof(struct tty_struct *tty)
-{
- cli();
- if ((tty->read_cnt) &&
- (tty->read_buf[tty->read_tail] == __DISABLED_CHAR) &&
- clear_bit(tty->read_tail, &tty->read_flags)) {
- tty->read_tail = (tty->read_tail+1) & (N_TTY_BUF_SIZE-1);
- tty->read_cnt--;
- }
- sti();
-}
-
static int read_chan(struct tty_struct *tty, struct file *file,
unsigned char *buf, unsigned int nr)
{
@@ -744,6 +728,9 @@
unsigned char *b = buf;
int minimum, time;
int retval = 0;
+ int size;
+
+do_it_again:
if (!tty->read_buf) {
printk("n_tty_read_chan: called with read_buf == NULL?!?\n");
@@ -858,7 +845,6 @@
put_fs_byte(c, b++);
if (--nr)
continue;
- gobble_eof(tty);
break;
}
if (--tty->canon_data < 0) {
@@ -896,7 +882,14 @@
current->state = TASK_RUNNING;
current->timeout = 0;
- return (b - buf) ? b - buf : retval;
+ size = b - buf;
+ if (size && nr)
+ clear_bit(TTY_PUSH, &tty->flags);
+ if (!size && clear_bit(TTY_PUSH, &tty->flags))
+ goto do_it_again;
+ if (!size && !retval)
+ clear_bit(TTY_PUSH, &tty->flags);
+ return (size ? size : retval);
}
static int write_chan(struct tty_struct * tty, struct file * file,
diff -r -u -N linux.dist/include/linux/tty.h linux/include/linux/tty.h
--- linux.dist/include/linux/tty.h Wed Aug 10 09:26:44 1994
+++ linux/include/linux/tty.h Wed Aug 10 09:26:44 1994
@@ -247,6 +247,7 @@
#define TTY_EXCLUSIVE 3
#define TTY_DEBUG 4
#define TTY_DO_WRITE_WAKEUP 5
+#define TTY_PUSH 6
#define TTY_WRITE_FLUSH(tty) tty_write_flush((tty))
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Improving SLIP latency under Linux
Reply-To: pe1chl@rabo.nl
Date: Mon, 10 Oct 1994 09:00:27 GMT
In <37981n$9bs@gate.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
>> >3- turn off error correction in the modems
>> I tried this to no avail.
>Modems should have a configuration option to also turn off (or tune) the
>RTS threshold values for the modem's send buffer. Unfortunately, in most
>modems there is no such thing. We could see more sensible modems if more
>people would complain.
Some high-end modems have the option to select between "large" and "small"
buffers, but what is meant by "small" is still a bit large for this purpose.
It would be nice when the modem itself would do the priority-queueing.
Of course one cannot expect this from a modem with a serial interface,
but what we could have is a modem with an ethernet connection which
operates at the packet level and could do simple priority decisions.
With the ever increasing speed of modems, I think an ethernet interface
would have many advantages.
(like higher datarate, cheap interface to many systems, no multiport
serial cards needed to build a modempool, easier to control and monitor
the modem state without using in-band (Hayes) signalling, etc)
Unfortunately, it seems that modem manufacturers bet on souped-up serial
port cards and/or PC-specific parallel interfaces instead. :-(
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Question: Any DOS/4GW?
Reply-To: pe1chl@rabo.nl
Date: Mon, 10 Oct 1994 09:06:11 GMT
In <37aebq$2fj@manuel.anu.edu.au> wlee@clubX.anu.edu.au (Wally) writes:
>Is there a DOS/4GW for Linux? or its emulator?
>Yes?! Where can I get it?
>No?! Anyone working on it?
No, it is not needed.
Linux can have 3GB in each user process without using such hacks.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: ramana@pen320.lexington.ibm.com (Ramana Ramachandran)
Subject: executable size too big
Date: 8 Oct 1994 21:06:53 GMT
Reply-To: ramana@vnet.ibm.com
Hi
I recently upgrded my kernel from 1.0.9 to 1.1.45 ( along with it I
upgraded gcc 2.4.5 to 2.5.8, libc from 4.0.4 to 4.5.26 ) and now when
I compile stuff the executable are about 3 times the size of the original
executables. How do I find if I am linking the dynamic libraries or not?
Any help would be greatly appreciated.
Thanks
ramana
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: tty bug and fix (for 1.1.51)
Date: Wed, 5 Oct 94 04:41:29 GMT
There was a bug in the tty code involving EOF and EOF characters that
was fixed a while ago, but the fix has become ineffective, and the
bug has returned. The bug involves the fact a false EOF is returned
when the EOF character is entered with characters waiting (i.e. the
EOF character is meant as a push, not as a real EOF). The latest
kernel 1.1.51 exhibits this bug.
To see the bug in action:
type dd bs=4
then enter any multiple of 4 characters, ctrl-d, and the dd will
terminate with an end of file. A lot of other un*xes screw up on this
too, but Linux had it fixed, and it was not too hard, and this patch
is not too difficult, and fixes the problem (and does not appear to
create any new bugs; I have tested it in cooked and cbreak modes,
with zero and non-zero min and time values it all seems okay).
Hopefully this (or a better, more elegant fix) will go into 1.2.0:
(I removed the old fix, since it does not do any good anymore)
diff -r -u -N linux.dist/drivers/char/n_tty.c linux/drivers/char/n_tty.c
--- linux.dist/drivers/char/n_tty.c Sun Sep 25 00:41:14 1994
+++ linux/drivers/char/n_tty.c Sun Sep 25 21:44:35 1994
@@ -453,6 +453,8 @@
goto handle_newline;
}
if (c == EOF_CHAR(tty)) {
+ if (tty->canon_head != tty->read_head)
+ set_bit(TTY_PUSH, &tty->flags);
c = __DISABLED_CHAR;
goto handle_newline;
}
@@ -718,24 +720,6 @@
*nr -= n;
}
-/*
- * Called to gobble up an immediately following EOF when there is no
- * more room in buf (this can happen if the user "pushes" some
- * characters using ^D). This prevents the next read() from falsely
- * returning EOF.
- */
-static inline void gobble_eof(struct tty_struct *tty)
-{
- cli();
- if ((tty->read_cnt) &&
- (tty->read_buf[tty->read_tail] == __DISABLED_CHAR) &&
- clear_bit(tty->read_tail, &tty->read_flags)) {
- tty->read_tail = (tty->read_tail+1) & (N_TTY_BUF_SIZE-1);
- tty->read_cnt--;
- }
- sti();
-}
-
static int read_chan(struct tty_struct *tty, struct file *file,
unsigned char *buf, unsigned int nr)
{
@@ -744,6 +728,9 @@
unsigned char *b = buf;
int minimum, time;
int retval = 0;
+ int size;
+
+do_it_again:
if (!tty->read_buf) {
printk("n_tty_read_chan: called with read_buf == NULL?!?\n");
@@ -858,7 +845,6 @@
put_fs_byte(c, b++);
if (--nr)
continue;
- gobble_eof(tty);
break;
}
if (--tty->canon_data < 0) {
@@ -896,7 +882,14 @@
current->state = TASK_RUNNING;
current->timeout = 0;
- return (b - buf) ? b - buf : retval;
+ size = b - buf;
+ if (size && nr)
+ clear_bit(TTY_PUSH, &tty->flags);
+ if (!size && clear_bit(TTY_PUSH, &tty->flags))
+ goto do_it_again;
+ if (!size && !retval)
+ clear_bit(TTY_PUSH, &tty->flags);
+ return (size ? size : retval);
}
static int write_chan(struct tty_struct * tty, struct file * file,
diff -r -u -N linux.dist/include/linux/tty.h linux/include/linux/tty.h
--- linux.dist/include/linux/tty.h Wed Aug 10 09:26:44 1994
+++ linux/include/linux/tty.h Wed Aug 10 09:26:44 1994
@@ -247,6 +247,7 @@
#define TTY_EXCLUSIVE 3
#define TTY_DEBUG 4
#define TTY_DO_WRITE_WAKEUP 5
+#define TTY_PUSH 6
#define TTY_WRITE_FLUSH(tty) tty_write_flush((tty))
------------------------------
From: hstrong@eng1.uconn.edu (Hugh Strong)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 10 Oct 1994 14:50:20 GMT
Michael Bischoff (mbi@math.nat.tu-bs.de) wrote:
: In article <ADC.94Oct9144148@bach.coe.neu.edu> adc@bach.coe.neu.edu (Albert D. Cahalan) writes:
: I think 3 or 4 bits could be spared for extended attributes like this:
: 0 flat file (default)
: 1 NEW record file
: 2 Mac file
: 3 NT file
: 4 OS/2 file
: 5 DOS executable
: 6 Windows executable
: 7 etc.
: Hi,
: this would be against the philosophy of UNIX: less is more!
: The success and flexibility of UNIX is due to the fact that
: all I/O is done through files: ordinary files, hard disks, printers
: are all accessable through the same open() and write() calls.
: The mess of DOS is that you need special programs if you want
: to read A: as entire image.
: Michael
: --
: EOI
: ----------------------------------------------------------------------------
: Michael Bischoff e-mail: mbi@mo.math.nat.tu-bs.de
: Abt. Mathematische Optimierung or m.bischoff@tu-bs.de
: Inst. Angewandte Mathematik or on.bischoff@zib-berlin.de
: Pockelsstrasse 14 Tel. +49-531-391-7555, Fax: +49-531-391-4577
: 38106 Braunschweig Germany
I think some people may misunderstand what I an suggesting.
Introducing a new set of namespaces like A:,C: and LPT1: would be
an intolerable barbarity. Certainly no one accustomed to UNIX would
think of using it. But what about extending the semantics of
existing calls? This has occured many times in the UNIX world. This
is precisely what happens every time someone writes a driver
with a new ioctl() call.
For instance, to open the main (data) fork of a file, one
might write
fd = open("MyDataFile",O_RDONLY);
The icon (for a window manager) for the file could be
accessed by the following call.
fd1 = open("MyDataFile:ICON",O_RDONLY);
The state of an editing session on the file could be
saved in yet another fork
fd2 = open("MyDataFile:EDITSTATE",O_RDONLY);
It is the FILESYSTEM code that grasps the semantics of what
we are doing, not other parts of the kernel. If some of
this functionality can be exported to user space, so much
the better.
I believe that NTFS handles extended attributes in a similar way.
I don't think that there's any need for a single filesystem to
understand more than one type of multifork FS. Support for
other forkful filesystems should be in the code for that
fs. A common interface is important, so that fork-aware
versions of cp, rm, etc can move data between different filesystems
without too much hassle.
-- Hugh Strong
hstrong@eng1.uconn.edu
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: BSD/386 vs. Linux Performance
Date: Mon, 10 Oct 1994 10:43:08 GMT
In article <Cx9wvK.Lu5@hermes.hrz.uni-bielefeld.de> lalbers@dozy.hrz.uni-bielefeld.de ( Leif Albers) writes:
>The main result was (if I'm right):
> If you have a small (harddisk and memory), stand-alone machine --
>use Linux.
> If you have a machine connected to a network with much network
>travel -- use BSD.
Both of these are out of date. With its shared libs and clean up BSD runs as
well as Linux on small machines and the net code in Linux is now solid.
Everyone around here uses Linux mostly because
a) Everyone else does
b) It's easier to get hold of (in the UK its made a major UK CD
magazine [which seems to have immediately sold out everywhere].
c) DOS emulation, and being able use iBCS2 binaries.
I think a) probably has the most bearing.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.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: 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