Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest276
2024-02-19 00:24:15 -05:00

666 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: Fri, 7 Oct 94 17:13:29 EDT
Subject: Linux-Development Digest #276
Linux-Development Digest #276, Volume #2 Fri, 7 Oct 94 17:13:29 EDT
Contents:
Re: VESA and SVGAlib? (Christopher Wiles)
Is anyone running websterd on linux? (Thaddeus H. Wood)
Re: AHA-1742 driver near optimal? Ult 24F? (Mary Shenk)
Re: Linux Mud (Joseph Angelis)
Help With LCD, Cirrus and XFree86 (Lucas James Sheneman)
Re: VESA and SVGAlib? (Phil Howard)
Re: Compiling progs using port I/O (Frank Lofaro)
Re: Adaptec AHA-2940 PCI SCSI card support.... (Hans de Hartog)
Re: ext2fs vs. Berkeley FFS (H. Peter Anvin)
Re: Telnet & ftp freeze! (Peter H. Lemieux)
Re: Beautifying Linux/Xfree (DAVID L. JOHNSON)
Re: Shared Libs: working toward a permanent solution? (Eric Youngdale)
Xfree 3.1 and SPEA MirageP64 (Linux) (Christoph Martin)
Re: Telnet & ftp freeze! (Ralph Sims)
LINUX Logical volumes (Richelo Killian)
Freeware Motif/Xview/tty interface library ? (Patrick Spinler)
----------------------------------------------------------------------------
From: a0017097@wsuaix.csc.wsu.edu (Christopher Wiles)
Subject: Re: VESA and SVGAlib?
Date: Fri, 7 Oct 1994 01:24:17 GMT
hhenson@inyanga.cs.wits.ac.za (Howard P. Henson) writes:
: Andy Bailey (bailey9@muvms6.wvnet.edu) wrote:
: : I have what might be a dumb question, about SVGAlib and video modes. I don't
: : know diddly about programming graphics drivers, but here goes.
: : With most DOS applications, namely graphics viewers, instead of specifying
: : the drive specific to my card, I simply use the VESA driver, and voila, all my
: : cardsmodes are recognized. Would this be possible for SVGAlib? I have overheard
: : bits of conversation among Linux developers about avoiding making BIOS calls (
: : I guess to ensure portability to other processors). Is the case the same here?
:
: The problem is not so much portability as the fact that VESA
: drivers (and I asume you have a bios version) is 16 bit code and to run
: it would require on to change CPU modes, and start thunking (16 -> 32 bit
: conversions) etc. producing i) Slow access ii) Possible unstabilities on
: the system which may land up with system crashes etc.
.. things run ever so much faster when one accesses the SVGA chip in
question directly ... no overhead added by going through the 8/16 bit
250ns VGA BIOS (which may contain bugs to begin with) accessed worst-case
through an ISA slot at 8Mhz (I _did_ say worst-case). I don't think that
the CPU has to switch modes to deal with the bus ... if that were the
case, you'd switch modes every time you accessed the hard drive.
-- Chris
a0017097@wsuaix.csc.wsu.edu wileyc@halcyon.com wileyc@quark.chs.wa.com
"... but I want to use all eight comm ports SIMULTANEOUSLY!"
PGP 2.6 public key available by finger for the clinically paranoid.
------------------------------
From: thw@sentient.sentient.com (Thaddeus H. Wood)
Crossposted-To: comp.os.linux.admin
Subject: Is anyone running websterd on linux?
Date: 7 Oct 1994 01:43:57 GMT
Greets all.
I'm attempting to run the websterd server on linux.
I've gotten the client & server sources that David Curry
wrote at Purdue.
I've managed to get it compiled, but there seems to be
some sort of problem using libdbm.a.
It compiles and links fine, but for some reason, calls to
dbm_open or dbm_fetch seem to fail.
Does anyone have any sort of inkling of what I speak?
Is dbm the problem here?
Do I need some sort of external dbm software?
I'm running a full Slackware 2.0.1 installation.
Thanks.
--
Thaddeus H. Wood thw@sentient.com
-- --
If you're not part of the solution, you're part of the precipitate.
--
------------------------------
From: mkshenk@u.washington.edu (Mary Shenk)
Subject: Re: AHA-1742 driver near optimal? Ult 24F?
Date: 7 Oct 1994 01:45:38 GMT
It seems that while I am hitting the disk hard on my dx2/66 w/an AHA-1742
host adapter, I miss term packets. I have a 16550 UART. Should this be
happening? It seems my system slows more than I think it "should" while
hitting the disk. How much work has gone into the 1742 drivers under Linux?
Are they close to optimal? What about the UltraStor 24F? Will this be a
superior card under Linux, due to technical superiority and/or a better driver?
Drivers aside, can anyone comment on the rel. technical merits of these 2
cards?
Thanks.
(term is configured properly. I promise. Works wonderfully except when I
hit the disk hard. These event are definitely linked, have done may trials.)
------------------------------
From: angelis@ux1.cso.uiuc.edu (Joseph Angelis)
Subject: Re: Linux Mud
Date: 5 Oct 1994 23:54:21 GMT
francis@VIOLET.uthscsa.edu (Scott Francis) writes:
>Is there a mud developed for Linux and if so is it possible for me to get
>the source or compiler version of it?
Most of the Diku variants seem to work on my machine.. I'm using 1.1.0
of the kernel and the latest gcc. Haven't had any problems yet..
>Please respond to francis@violet.uthscsa.edu
>Thanks is advance
>Scott
>//////////////////////////////////////////////////////
>// //
>// Scott Francis - UT Health Science Center //
>// San Antonio, Texas //
>// //
>// e-mail: francis@violet.uthscsa.edu //
>// sfrancis@janus1.cs.trinity.edu //
>// //
>// voice: (210)829-5501 //
>// //
>//////////////////////////////////////////////////////
------------------------------
From: sheneman@cs.uidaho.edu (Lucas James Sheneman)
Crossposted-To: comp.os.linux.misc,comp.os.linux.help
Subject: Help With LCD, Cirrus and XFree86
Date: 7 Oct 1994 02:03:36 GMT
I just got XFree86-3.1 and installed it on my machine. I have a Cirrus-6440
chipset. I am trying to run the XF86-SVGA server. I managed to make the
server happy by telling it I had a Cirrus-6420 chipset (like the docs say to
do). When the server comes up, I get a nice, crisp, clear display on my
LCD notebook, except for the fact that the top 50 pixels or so and the
bottom 50 pixels of the screen are screwed up. The bottom 50 pixels of the
display are identical to the top 50 pixels on the display...only shifted by
about 100 pixels.
My question is this: I have a dual-scan color LCD display and a cirrus 6440
chipset. Does it make sense for me to determine the video modes for my
display as discussed in the text file VideoModes.txt? How do I treat an LCD
display when trying to determine video modes and sync frequencies? Does my
problem sound like a video timings problem or does it sound like a problem in
which my server is mis-using VRAM?
Specifically, here is my system:
1. Sager NP7500 Notebook/dual scan color LCD (640x480x256)
2. 1MB VRAM.
3. XFree86-3.1
Please e-mail me if you have any suggestions. Thanks.
-Luke.
--
+--------------------------------------------------------------------------+
| Luke Sheneman sheneman@cs.uidaho.edu |
+--------------------------------------------------------------------------+
| Laboratory for Applied Logic, University of Idaho |
| http://www.cs.uidaho.edu/lal/students/sheneman.dir/sheneman.html |
+--------------------------------------------------------------------------+
------------------------------
From: phil@zeus.fasttax.com (Phil Howard)
Subject: Re: VESA and SVGAlib?
Date: 6 Oct 1994 22:45:47 -0500
hhenson@inyanga.cs.wits.ac.za (Howard P. Henson) writes:
>Andy Bailey (bailey9@muvms6.wvnet.edu) wrote:
>: I have what might be a dumb question, about SVGAlib and video modes. I don't
>: know diddly about programming graphics drivers, but here goes.
>: With most DOS applications, namely graphics viewers, instead of specifying
>: the drive specific to my card, I simply use the VESA driver, and voila, all my
>: cardsmodes are recognized. Would this be possible for SVGAlib? I have overheard
>: bits of conversation among Linux developers about avoiding making BIOS calls (
>: I guess to ensure portability to other processors). Is the case the same here?
> The problem is not so much portability as the fact that VESA
>drivers (and I asume you have a bios version) is 16 bit code and to run
>it would require on to change CPU modes, and start thunking (16 -> 32 bit
>conversions) etc. producing i) Slow access ii) Possible unstabilities on
>the system which may land up with system crashes etc.
VESA is 2 things:
1. A common BIOS programming interface.
2. A driver that understand your hardware.
Linux has:
1. A non-BIOS programming interface.
2. Good drivers for documented hardware and some drivers for others, too.
If your hardware is not supported by Linux:
1. Maybe someone is working on it now.
2. Call your vendor and ask for a "Linux driver".
3. Call your vendor and ask for full hardware documentation for driver
development.
4. Sell your hardware to some DOS loser and get something better.
--
/***** Phil Howard KA9WGN *********** How about universal JOBS? **************\
* Unix/Internet/Sys Admin Let's de-Foley-ate congress in 94 *
* CLR/Fast-Tax Don't let Annie get your gun! *
\***** phil@fasttax.com ************* Just say NO to CIX extortion ***********/
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Compiling progs using port I/O
Date: Fri, 7 Oct 94 03:07:40 GMT
In article <36hm55Ebnr@uni-erlangen.de> bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes) writes:
>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>> In <36bmo0$fmg@clarknet.clark.net> nardone@clark.net (Joe Nardone) writes:
>
>
>> >Hey net-folks--
>
>> >I'm trying to compile a program that uses the inb and outb
>> >functions (macros, actually) but when it comes to link time
>> >all my inb/outb calls are represented as unresolved references
>> >to ___outb (or ___outcb) and ___inb...
>
>> >Am I missing a library, or a path to one? gcc -v looks like it's
>> >looking in all the right places for library files...
>
>> >I'm running GCC 2.5.8 on Linux Kernel 1.1.50 w/ a 486dx2/66.
>
>> >Any help would be much appreciated-
>
>> You have to compile with optimization (-O2)
>
>Is there some explanation for that behaviour?
>--
>Uwe Bonnes bon@lte.e-technik.uni-erlangen.de
Yes, there is.
extern inline is used instead of static inline in the function definitions.
This is a Bad Thing. Without optimization, inline is ignored, thus
extern inline becomes extern, which means it is not defined. Using static
inline would mutate to static when not optimizing, which would still work
(it would not be inline of course, but it wouldn't fail to compile, either).
P.S. Using extern does not require -O2, just -O will work, Still, it would
be nice to be able to use those functions even when you do not want to
use optimization.
------------------------------
From: dehartog@kwetal.comcons.nl (Hans de Hartog)
Subject: Re: Adaptec AHA-2940 PCI SCSI card support....
Date: 7 Oct 1994 13:10:23 -0000
Edward S Peschko (pesc0002@gold.tc.umn.edu) wrote:
: hey all --
: Any plans (*please*) for developing support for the AHA-2940 PCI SCSI
: board??
Yes, I've read somewhere that people are working on the PCI SCSI drivers
Stay tuned to c.o.l.announce
: Ed
: (ie: This really sucks. I have a $5K system, with a 4MB VRAM card (and yes,
: its diamond unfortunately) 4xPlextor, etc. etc... and its TOO NEW for linux!
: If something doesn't come out soon, I guess it is just going to have to be
: SCO...)
Yup, that's life. There is a HOWTO-hardware (a.k.a. hardware compatibility
list) for Linux. Better check that list before spending...
--
_____________________________________________________________________________
Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands
Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: ext2fs vs. Berkeley FFS
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Fri, 7 Oct 1994 04:11:17 GMT
Followup to: <36nng2$4a1@babyblue.cs.yale.edu>
By author: hstrong@eng1.uconn.edu (Hugh Strong)
In newsgroup: comp.os.linux.development
>
> I know this doesn't sound very UNIXy, but how difficult would
> it be to implement a filesystem with some sort of arbitrary
> extended attributes like those in NTFS or the more limited ones
> in HPFS?
>
Probably quite trivial (all you need is an attribute on a directory
that marks it as "look like a file"). A file with multiple data
streams (forks, to use Mac terminology) is nothing but a directory.
However, you would have to teach ls, cp etc about this convention,
which would be a pain.
/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
"All sysadmins love logs." -- Me after deleting 87 Mb worth of log files
------------------------------
From: phl@cyways.com (Peter H. Lemieux)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 7 Oct 1994 04:26:30 GMT
In article <3728nr$eb0@news.halcyon.com>, ralphs@halcyon.halcyon.com (Ralph Sims) says:
>
>Other things that run are Sendmail+IDA as a daemon, xntpd, and
>CERN's web server. The ftp session definitely takes over the system.
>
Remember that FTP is running two simultaneous sessions with the other host,
a data channel and a control channel. With only a standard two-wire modem,
the line must be repeatedly turned around from TX to RX and back again.
(Four wire, dedicated-line modems are pricey.) Services like news and
the web have little upstream traffic, mostly downstream, since they
have no control channel.
Peter
Dr. Peter H. Lemieux
cyways, inc Voice: +1 (617) 924-7991
203 Arlington Street Fax: +1 (617) 926-8440
Watertown, MA 02172-2036 USA Internet: phl@cyways.com
------------------------------
From: dlj0@Lehigh.EDU (DAVID L. JOHNSON)
Crossposted-To: comp.os.linux.misc
Subject: Re: Beautifying Linux/Xfree
Date: 7 Oct 1994 16:09:25 GMT
In article <372tg0$1ai@huron.eel.ufl.edu>, acg@kzin.cen.ufl.edu (Alexandra Griffin) writes:
>In article <1994Oct5.141142.773@muvms6>,
>Andy Bailey <bailey9@muvms6.wvnet.edu> wrote [in c.o.l.misc]:
>>[...]
>>
>You may get some negative feedback from the die-hard functionality
>over form crowd, but I'd say there's a lot of truth to what you're
>saying-- cleaning up minor things like GUI look & feel *will* make the
>X environment more appealing to a lot of people (maybe this is
>unfortunate, but with all the "fluff" on a typical Mac/Windoze desktop
>nowadays a lot of people expect this kind of thing...)
We got LOTS of fluff, but no *one* set of it. That is sort of the main
difference. You want standardized interfaces? Not likely. A vendor could
provide one -- most of them do. But linux is a creature of the net, and there
will not be only one GUI interface.
>
>Some ideas along this line that I've thought about:
>
>1) A mouse-driven tool for setting common X resource preferences would
>be *very* helpful, even for experienced users (kind of a big project,
>I know).
I don't think this is too hard, and it is a good idea.
>2) A better X file manager than what's currently out there (xfm &
>xfilemanager are nice but not as easy to configure, easy to use, or
>generally polished as one might like). Maybe something that provided
>essentially the same functionality as Mouseless Commander (the
>text-based Norton Commander clone), but with a mouse-driven GUI? (&
>provisions for icons if desired, scrollbars on the dual file selection
>lists, real pulldown menus-- leave in the command line at the bottom,
>though!).
This is arleady avialable. Try GREAT. Really. It takes a while to
configure, and you should have Motif to get the best performance, but it has
lots of options.
> 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
>(in its Browser mode) presents a group of side-by-side vertical
>directory listings, with each column representing a level of the
>directory hiearchy...
Y'know, the browser from Ghostview is similar to this -- not as advanced,
though. GREAT's file manager is similar, as well -- though not the
tree-structure. To each his own
>3) Another idea from HP-VUE... this environment features a "console
>bar" area at the bottom of the screen, containing buttons to switch
>virtual desktops, invocation icons for commonly-used apps, small icons
>for system functions (logging out...), and space for a clock,
>calendar, Xload bargraph, & other stuff.
Again, GREAT -- along with what you can do with .xinitrc, can do this. There
is also another program out there that does things like this. Can't
remember the name, but check them out as they show up.
Much of your suggestions are really already available, and I don't see any
interest in somehow standardizing them. Making such bells&whistles available
is one thing, making them ubiquitous is another. Don't just assume that,
if it isn't in slackware, it's not available.
--
David L. Johnson dlj0@lehigh.edu or
Department of Mathematics dlj0@chern.math.lehigh.edu
Lehigh University
14 E. Packer Avenue (610) 758-3759
Bethlehem, PA 18015-3174 (610) 828-3708
------------------------------
From: eric@aib.com (Eric Youngdale)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: Fri, 7 Oct 1994 04:38:26 GMT
In article <RICHK.94Oct4145524@netcom17.netcom.com>,
Richard Krehbiel <richk@netcom17.netcom.com> wrote:
>In article <36pe51$s0v@strauss.udel.edu> mike@strauss.udel.edu (Michael James Porter) writes:
>
>> In article <DHOLLAND.94Sep29150545@husc7.harvard.edu>,
>> David Holland <dholland@husc7.harvard.edu> wrote:
>> =>How about dynamically relocating the library when it's loaded - once.
>> =>Then the address it appears at can be determined at run time; that way
>> =>it cannot possibly conflict with any other libraries; the library
>> =>loading mechanism would pick addresses so that doesn't happen. Then
>> =>when other processes add it, it would appear at the same address in
>> =>every process.
>>
>>
>> This is a good idea
>
>I also like this idea; it does not require that library code be
>position independent. There was a long thread about the actual
>performance penalty of PIC; from that I gather that it's at least 3%
>and possibly more.
The performance penalty is not due to the library being relocated. It
is because we lose one of the machine registers so that it can be used
to point to the GOT table. The Intel architecture is painfully short of
registers, so losing one gives a noticable performance impact.
>> , but it limits the loading of a shareable library
>> to program load time. I would like to see dlls be loadable at any
>> time in the life of a process.
>
>I don't see why this is a problem; if it can be done at program load
>time, it can certainly be done at run time. It only requires that the
>load-and-relocate function (and perhaps the locate-symbolic-entry-
>point functions) be available to executing processes.
The only way to avoid the performance penalty is to modify the compiler
to do something like half-pic. THis way the same pic operands are used so but
are not referenced to the %ebx register - then you can free up the %ebx
register. Next you need to make sure that the assembler generates sensible
relocations for all of these operands, and then you can generate a shared
library. Finally you can use some kind of utility to "fast-load" the shared
library at some fixed address and perform the majority of the relocations and
then write the file back out again. You will also need to modify the dynamic
loader to recognize that the library has already been relocated and properly
load it at the correct address - in this case the addresses would be chosen
locally. The disadvantage is that with a system such as this the libraries
would be painfully slow before they are "fast-loaded".
If I were trying to improve performance of ELF libraries, I would
probably try and do something along the lines of what I just outlined. The
key is to avoid cumbersome build procedures and it simply must be as
idiot-proof as possible. I want to reiterate that for now the concern
is simply to get everything stable and debugged so that it works.
At the moment there are some C++ issues that should be resolved, and then
we will sit back and pound on it for a while to make sure that it all hangs
together before we release it to the general public.
Finally, I noticed earlier in this thread that someone said that it was
the performance of linux that was so attractive, and that if we started doing
this sort of thing (i.e. ELF), that they would switch to something like
Solaris. I found this comment *extremely* amusing, as would anyone else who
had ever used Solaris. In my new job I have occasion to work on a Solaris
machine, and believe you me, Solaris is the butt of many rather rude jokes, all
of them concerning poor performance. BTW - Solaris uses ELF, but the
performance problems are apparenetly more to do with the kernel/filesystem
rather than anything else - Unixware also uses ELF, and it is much faster.
-Eric
------------------------------
From: martin@goofy.zdv.Uni-Mainz.DE (Christoph Martin)
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.admin
Subject: Xfree 3.1 and SPEA MirageP64 (Linux)
Date: 06 Oct 1994 16:11:53 GMT
README.S3 (in XF86-3.1-doc.tar.gz) says:
>1 - Supported hardware
>----------------------
>
> ...
>
>S3 864, 20C498 RAMDAC, ICS2595 Clockchip
> SPEA MirageP64 2MB DRAM
>
> 8 and 15/16 bpp
>
> ClockChip "ICS2595"
I tried this in my XF86Config file. The card is probed correctly as
S3 864 with 20C486 RAMDAC. But the server can't set the clockchip.
What is the problem? Is it the right ClockChip statement? Has anyone
this card running with XFree 3.1?
Christoph
--
============================================================================
Christoph Martin, Zentrum f<>r Datenverarbeitung, Uni-Mainz, Germany
Internet-Mail: Christoph.Martin@Uni-Mainz.DE
Paper-Mail: C. Martin, Zentrum f<>r Datenverarbeitung,
Johannes-Gutenberg-Universit<69>t, 55099 Mainz, Germany
Telefon: +49 6131 396316
--
============================================================================
Christoph Martin, Zentrum f<>r Datenverarbeitung, Uni-Mainz, Germany
Internet-Mail: Christoph.Martin@Uni-Mainz.DE
Paper-Mail: C. Martin, Zentrum f<>r Datenverarbeitung,
Johannes-Gutenberg-Universit<69>t, 55099 Mainz, Germany
Telefon: +49 6131 396316
------------------------------
From: ralphs@halcyon.halcyon.com (Ralph Sims)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 7 Oct 1994 14:06:44 GMT
phl@cyways.com (Peter H. Lemieux) writes:
>>CERN's web server. The ftp session definitely takes over the system.
>Remember that FTP is running two simultaneous sessions with the other host,
>a data channel and a control channel. With only a standard two-wire modem,
Right, but introducing a 3000ms latency in the PPP session is not
really acceptable.
------------------------------
From: killianr@beldin.sun.ac.za (Richelo Killian)
Subject: LINUX Logical volumes
Date: 7 Oct 1994 14:13:31 GMT
I have a interesting question for all you LINUX gurus out there...
Is it posible to create logigal volumes across drives and/or partitions and then mount a single filesystem on that volume? I know it can be done on HP-UX, but I want to do it on my LINUX box?
Cheers
Richelo Killian
KILLIANR@TELKOM09.telkom.co.za
------------------------------
From: pats@mack.RT66.com (Patrick Spinler)
Crossposted-To: comp.windows.x,comp.windows.x.motif,comp.windows.x.open-look,comp.windows.misc,comp.programming,comp.unix.bsd
Subject: Freeware Motif/Xview/tty interface library ?
Date: 07 Oct 1994 03:06:13 GMT
Hi folks,
I'm part of a group writing a set of administration tools for freeware
unixes, and I'm looking for a freeware GUI interface library or class
library that transparently supports or can be made to support several
different interfaces, including Motif, Openlook, Xview, and tty
(curses). MS-Win, Mac, et al are nifty extras but not necessary.
Sorry for all the cross posting. Please email responses. If enough
people are interested, I'll post a summary to comp.windows.x or
comp.windows.misc.
Thanks !
-- Pat
----
Patrick Spinler pats@rt66.com
Re: flames - "May your cats grow hands"
--
Patrick Spinler pats@rt66.com
Re: flames - "May your cats grow hands"
------------------------------
** 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
******************************