553 lines
21 KiB
Plaintext
553 lines
21 KiB
Plaintext
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: Thu, 22 Sep 94 09:13:14 EDT
|
|
Subject: Linux-Development Digest #205
|
|
|
|
Linux-Development Digest #205, Volume #2 Thu, 22 Sep 94 09:13:14 EDT
|
|
|
|
Contents:
|
|
Re: [STATUS] Linus Floppy Driver Development (David Holland)
|
|
** autoconf.h? ** (Michael_Nelson)
|
|
Re: Kernel Goals? (Jeff Kesselman)
|
|
Re: HELP NEEDED : device driver (Jeff Kesselman)
|
|
Re: 1.1.51 seg fault on shutdown in _floppy_release (Steve Kneizys)
|
|
Re: Shared Libs: working toward a permanent solution? (Michael O'Reilly)
|
|
Re: Looking for a Fax daemon (Gert Doering)
|
|
FlexFax and Linux: config file anyone? (Mike Dowling)
|
|
Problems with svgalib1.11 and Trident 9200CX card (Peter Onion)
|
|
Re: Alpha Linux (Kevin Marcus)
|
|
Re: Digi Intelligent Boards? (Alan Cox)
|
|
Re: Does Quicken work under DOSEMU? (Michael E. Mendis)
|
|
Re: Sequential IO only thing lacking in Linux ... (Larry Doolittle)
|
|
Re: Shared Libs: working toward a permanent solution? (Eric Youngdale)
|
|
Re: Shared Libs: working toward a permanent solution? (Dejan Ilic)
|
|
Re: Porting applications to TERM (Robert Stockmann)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
Subject: Re: [STATUS] Linus Floppy Driver Development
|
|
From: dholland@husc7.harvard.edu (David Holland)
|
|
Date: 17 Sep 94 15:48:58
|
|
|
|
urlichs@smurf.noris.de's message of 13 Sep 1994 12:27:36 +0200 said:
|
|
|
|
> Generally, I think it's not reasonable to force the user to start some sort
|
|
> of floppy recognition program after inserting a disk and before tar-xfv'ing
|
|
> off /dev/fd0, if the format in question is known to the driver anyway.
|
|
|
|
I additionally think it's not reasonable to force the user to look up
|
|
the filesystem type and issue a mount command before reading from the
|
|
disk. Floppies should mount themselves (like on Macs and Amigas) to
|
|
the greatest extent possible given the hardware.
|
|
|
|
This is not bloat, it's an important issue for some people.
|
|
|
|
--
|
|
- David A. Holland | -- "Do you have a moment?" -- "Yes.
|
|
dholland@husc.harvard.edu | Unfortunately, it's a moment of inertia."
|
|
|
|
------------------------------
|
|
|
|
From: nelson@seahunt.imat.com (Michael_Nelson)
|
|
Subject: ** autoconf.h? **
|
|
Date: 21 Sep 1994 14:34:51 GMT
|
|
Reply-To: nelson@seahunt.imat.com
|
|
|
|
Recently, when attempting to build some applications (one was yamm), I've
|
|
encountered a problem where the application will #include
|
|
|
|
"/usr/src/linux/include/config.h"
|
|
|
|
config.h isn't a problem, because it's there, and it gets #included without
|
|
problem. But config.h has a line in it that #includes "<linux/autoconf.h>",
|
|
and there is no autoconf.h anywhere on my system.
|
|
|
|
So far I've been able to get around the problem by commenting the #include
|
|
of that file out of config.h, and the applications seem to build without
|
|
problem... but it makes me uncomfortable when I have to hack system files
|
|
like this...
|
|
|
|
Is this #include of autoconf.h an error in config.h, or should I really have
|
|
an autoconf.h?
|
|
|
|
BTW, I am currently running 1.51, which started as a complete 1.45 with the
|
|
subsequent patches applied in sequence.
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: Kernel Goals?
|
|
Date: Wed, 21 Sep 1994 19:37:55 GMT
|
|
|
|
|
|
To me, this is the single best design goal for new versions of Linux that
|
|
I've heard (i think I posted a pie-in-the-sky suggestion that someone do
|
|
this quite a whiel back.) Having said this, I have to admit that my
|
|
priorities at this time don't allow me the time to do it :(
|
|
|
|
Let me add 2 more reasons (which may be obvious) as to why modularity is
|
|
a good thing.
|
|
|
|
A) Stripping and recompiling the kernel is a pain even for knowledgaeable
|
|
programmers. It is not feasable for others. This limits both the Linux
|
|
audience and, as a result, the desirability to third party hardware
|
|
manufacturers of writing Linux drivers.
|
|
|
|
B) Stability can only be improved by breaking the system down into
|
|
smaller functional units.
|
|
|
|
Jeff Kesselman
|
|
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: HELP NEEDED : device driver
|
|
Date: Wed, 21 Sep 1994 19:41:08 GMT
|
|
|
|
In article <35jhhp$7ip@nunki.usc.edu>,
|
|
Kamal T.Mian <kmian@nunki.usc.edu> wrote:
|
|
>hi folks ,
|
|
>
|
|
>
|
|
>I am intersted in writing/porting to LINUX a device driver for an ISDN
|
|
>card that plugs into Pentium PC.
|
|
>
|
|
>
|
|
>My problem is that ... I am very new to Linux .. and donot know from
|
|
>where to start ....
|
|
>
|
|
>How should one start ?
|
|
>
|
|
>Any documents available for writing a device drivers ?
|
|
>
|
|
>Any suggestions or ideas will be highly appreciated ....
|
|
>
|
|
>It is my class project .... and I have 3-4 months to write it.
|
|
>
|
|
>
|
|
>one can also email me at mian@scf.usc.edu
|
|
>
|
|
>
|
|
>regards
|
|
>
|
|
>Mian
|
|
|
|
|
|
Get yourself a copy of the Linux Bible (published by Yygdrasil, for about
|
|
$45.00). It puts just about all the available linux docs at your finger
|
|
tips, including 'The Kernel Hacker's Guide' which has a large section on
|
|
writing device drivers (I was just reading it last night.)
|
|
|
|
Alternately, if you want to go searching aroudn the net, thats where all
|
|
the docs in this book came from. For me the time saved is woth the
|
|
$40.00 I payed for the book.
|
|
|
|
Jeff Kesselman
|
|
|
|
------------------------------
|
|
|
|
Subject: Re: 1.1.51 seg fault on shutdown in _floppy_release
|
|
From: STEVO@acad.ursinus.edu (Steve Kneizys)
|
|
Date: 19 Sep 94 21:12:20 EST
|
|
|
|
Vincent Fatica (vefatica@cockpit.syr.edu) wrote:
|
|
: According to zSystem, the error occurs in _floppy_release.
|
|
|
|
: It also occurs on dismounting /b (an ext2 floppy). Thereafter, mount says
|
|
: it's still mounted (which it's not).
|
|
|
|
: Vince Fatica
|
|
|
|
Got a similar error with a 'umount -t msdos /dev/fd0 ', but I could not
|
|
reproduce it. All I did was try and use pico on files from my 3C579
|
|
driver disk from 3Com...nothing fancy :)
|
|
|
|
Steve...
|
|
|
|
------------------------------
|
|
|
|
From: michael@iinet.com.au (Michael O'Reilly)
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: 22 Sep 1994 15:06:39 +0800
|
|
|
|
Richard Krehbiel (richk@netcom12.netcom.com) wrote:
|
|
|
|
: Why is everyone hung up on PIC for shared libraries?
|
|
|
|
: Why not this way: Take a fairly large chunk of process virtual address
|
|
: space, say 64M or so, and reserve it for shared library code and data.
|
|
: When a shared library is loaded, find an available spot in that range,
|
|
: load it, and then fix up self-relative code and data references with
|
|
: the library's relocation dictionary. This way you don't pay the
|
|
: performance penalty of PIC, and you still avoid library load address
|
|
: conflicts. You have to worry about whether all libraries loaded by
|
|
: all processes will fit into 64M, of course, and someone will have to
|
|
: write a relocating loader.
|
|
|
|
The problem is 'sharing'. When you load the library, you write all
|
|
over it, so you lose badly in terms of shared the library pages
|
|
between processes.
|
|
|
|
Michael.
|
|
--
|
|
Michael O'Reilly @ iiNet Technologies, Internet Service providers.
|
|
Voice (09) 307 1183, Fax (09) 307 8414. Email michael@iinet.com.au
|
|
GCS d? au- a- v* c++ UL++++ L+++ E po--(+) b+++ D++ h* r++ u+
|
|
e+ m+ s+++/--- !n h-- f? g+ w t-- y+
|
|
|
|
------------------------------
|
|
|
|
From: gert@greenie.muc.de (Gert Doering)
|
|
Subject: Re: Looking for a Fax daemon
|
|
Date: Thu, 22 Sep 1994 10:15:33 GMT
|
|
|
|
rjl@davinci.renaissoft.com (Robert J. LeBlanc) writes:
|
|
|
|
>seemed only to fit FlexFAX and the efax+Qfax combination due to the
|
|
>lack of spooling with mgetty+sendfax.
|
|
|
|
Well, if you phrase it *this way*, it's not correct, mgetty+sendfax *has* a
|
|
spooling system, it's just not a *network* spooler (though it can be used
|
|
over NFS).
|
|
|
|
> It should also be noted that
|
|
>mgetty+sendfax requires a Class 2 fax-modem, whereas FlexFAX and
|
|
>efax+Qfax work with both Class 1 and 2 fax-modems.
|
|
|
|
... and it should be noted that mgetty+sendfax supports class 2.0
|
|
faxmodems (e.g. the USR), which efax doesn't...
|
|
|
|
gert
|
|
--
|
|
Yield to temptation ... it may not pass your way again! -- Lazarus Long
|
|
//www.muc.de/~gert
|
|
Gert Doering - Munich, Germany gert@greenie.muc.de
|
|
fax: +49-89-3243328 gert.doering@physik.tu-muenchen.de
|
|
|
|
------------------------------
|
|
|
|
From: mike@moocow.math.nat.tu-bs.de (Mike Dowling)
|
|
Subject: FlexFax and Linux: config file anyone?
|
|
Date: 22 Sep 1994 09:44:31 GMT
|
|
Reply-To: on.dowling@zib-berlin.de
|
|
|
|
Oh, dear! I can't say that I wasn't warned! Getting FlexFax configured is
|
|
giving me a headache. If anyone has a working config file, I would be very
|
|
grateful if you could send it to me together with a very brief description of
|
|
your modem.
|
|
|
|
The Problem:
|
|
I have mgetty+sendfax up and running, so I have no hardware problems. With the
|
|
intention of implementing a fax daemon on a workstation for the department, I
|
|
first wanted to try it out under Linux. Since I don't want my Linux machine to
|
|
run 24 hours a day, mgetty+sendfax satisfies my Linux needs completely.
|
|
|
|
Currently FlexFax is capable of ringing the correct number, but it fails to
|
|
communicate with the host. My problems are compounded by having a German
|
|
description of my modem in which the page numbers of the index are wildly out,
|
|
and by having to think out all possible German translations of the technical
|
|
terms, and search for them by paging through the manual. Manual does even say
|
|
what sort of a modem it is, but FlexFax and my dealer together have worked out
|
|
that it is a Rockwell 144DP modem manufactured by Yoriko.
|
|
--
|
|
Mike Dowling
|
|
High-tech Germany presses inexorably on towards fulfilling its great dream of
|
|
establishing an electronic mini-crawlway before the end of the next century.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: onion_p_j@bt-web.bt.co.uk (Peter Onion)
|
|
Subject: Problems with svgalib1.11 and Trident 9200CX card
|
|
Date: 20 Sep 1994 08:58:52 GMT
|
|
|
|
Has anybody else tried to use svgalib1.11 with a trident 9200CX card.
|
|
|
|
I have a 9200CX card and 66DX2. Kernel 1.1.35.
|
|
|
|
The svgalib demos (fun,3d, etc seem to work ok), but vgatest (the one
|
|
which asks you to choose a mode) falls over. The mode I'm interested in
|
|
is 1024*768*256 (and I think that 800*600 failed as well). The screen
|
|
goes blank, the scan rate changes but no more video...ever.... until a
|
|
hard reset (preceeded by a shutdown -h of course!)
|
|
|
|
The XF86_SVGA X driver works fine on the same card. I looked in the
|
|
source for this and it specifically mentions the 9200CX and says that it
|
|
treats it as a 8900CL (I think).
|
|
|
|
Are there any later versions of the trident code for the svgalib, or any
|
|
patches or different values to put into tvga8900.regs?
|
|
|
|
E-mail replies to the above address are prefered (as the local news host
|
|
only keeps mail for a few days and I may be out of the office for the
|
|
rest of the week!)
|
|
|
|
Thanks in avdance Peter Onion.
|
|
|
|
------------------------------
|
|
|
|
From: datadec@corsa.ucr.edu (Kevin Marcus)
|
|
Subject: Re: Alpha Linux
|
|
Date: 20 Sep 1994 08:37:49 GMT
|
|
|
|
In article <35m1q4$qk@harbinger.cc.monash.edu.au>,
|
|
Andrew Bulhak <acbul1@penfold.cc.monash.edu.au> wrote:
|
|
>Bill Hay (wish@dumain.demon.co.uk) wrote:
|
|
>What is "natural"? An Alpha can handle 32-bit quantities just as
|
|
>"naturally" as 64-bit quantities, so it all comes down to convenience.
|
|
>And dropping one size, thus making it unavailable to programmers, is
|
|
>very inconvenient.
|
|
|
|
Actually, the Alpha suffers significant performance penalties when dealing
|
|
with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
|
|
the lower end Alpha's).
|
|
|
|
|
|
|
|
--
|
|
--> Kevin Marcus, Computer Science Dept., University of California, Riverside
|
|
Email: datadec@cs.ucr.edu.
|
|
.. "Two types of programs do CALL <next instr>; POP <index reg>. They are
|
|
viruses and a good chunk of DOS programs. Down with MicroSloth."
|
|
|
|
------------------------------
|
|
|
|
From: iialan@iifeak.swan.ac.uk (Alan Cox)
|
|
Subject: Re: Digi Intelligent Boards?
|
|
Date: Thu, 22 Sep 1994 09:41:50 GMT
|
|
|
|
In article <cPCUkapDlDyI071yn@halcyon.com> mpdillon@halcyon.com (Michael Dillon) writes:
|
|
>> I visited the Digiboard display at Interop this week, and was told by one
|
|
>> of the sales reps that Digiboard was getting pressure from SCO not to
|
|
>> promote the creation of new drivers for Linux. In particular, I was
|
|
>> asking about thier new ISDN board they had on display.
|
|
>I guess we had better all send some email to sales@digibd.com
|
|
>explaining that we would rather buy their PC/Xe board than the Cyclades
|
|
>board, but we NEED Linux device drivers. Once marketing realizes
|
|
|
|
It would also be nice if someone could substantiate the above rumour. If it
|
|
is true and peopel will admit to it then it would appear a formal complaint
|
|
can be lodged from various countries with their US embassy about restraint
|
|
of trade. In most countries leaning on people not to support a competitors
|
|
product is illegal.
|
|
|
|
Alan
|
|
--
|
|
..-----------,,----------------------------,,----------------------------,,
|
|
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
|
|
``----------'`----------------------------'`----------------------------''
|
|
|
|
------------------------------
|
|
|
|
From: mmendis@splinter.coe.neu.edu (Michael E. Mendis)
|
|
Subject: Re: Does Quicken work under DOSEMU?
|
|
Date: 22 Sep 1994 11:01:51 GMT
|
|
|
|
The title pretty much says it all: doe any of the DOS flavors of
|
|
Quicken work under DOSEMU? If not, are there any financial packages
|
|
that *do* work under it?
|
|
|
|
I haven't tried the beta version .53 but I have using .52 with quicken.
|
|
You can get .52 from sunsite.unc.edu or from the home base tsx-11.mit.edu
|
|
-mike
|
|
|
|
------------------------------
|
|
|
|
From: doolitt@recycle.cebaf.gov (Larry Doolittle)
|
|
Subject: Re: Sequential IO only thing lacking in Linux ...
|
|
Reply-To: doolittle@cebaf.gov
|
|
Date: Thu, 22 Sep 1994 02:45:04 GMT
|
|
|
|
Mark Lord (mlord@bnr.ca) wrote:
|
|
|
|
: Commercial unix systems usually include optimized support for a limited
|
|
: number of disk devices, and make use of knowledge of the physical
|
|
: characteristics in optimizing system throughput.
|
|
|
|
: For example, i/o requests can be reordered on the fly based
|
|
: on the known current rotational position of the spindle,
|
|
: rather than just waiting for it to come around again..
|
|
|
|
: Knowledge of the true physical geometry of the disk lends itself
|
|
: to further optimizations, such as organizing data by cylinder
|
|
: rather than by arbitrary sequential block numbers (close, but not
|
|
: the same results). To do a good job of this requires further knowledge
|
|
: of the sector count/location on each track of the disk.. a complex
|
|
: task when variable sectors/track are used.
|
|
|
|
: Varying the locations of sector/block 0 on each track can yield impressive
|
|
: throughput figures, by taking into account the head movement/settling times
|
|
: from one track/cylinder to the next, such that the next sequential block
|
|
: is just appearing under the heads as the seek completes..
|
|
|
|
: Lots of nice tricks, most of which require greater internal knowledge of
|
|
: a restricted subset of available drives..
|
|
|
|
: Linux, (un?)fortunately, likes to provide more generic drive support.
|
|
|
|
Fortunately, the trend is to put this level of optimization on
|
|
the hard disk itself, which *really* knows where it is :-)
|
|
All the OS is interacting with on a real-time basis is the 256K or so
|
|
sector/track/cylinder/whatever-RAID-trick-they-pull-next cache.
|
|
This arrangement _should_ prove highly satisfactory.
|
|
|
|
- Larry Doolittle doolittle@cebaf.gov
|
|
|
|
------------------------------
|
|
|
|
From: ericy@cais2.cais.com (Eric Youngdale)
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: 22 Sep 1994 11:27:19 GMT
|
|
|
|
In article <RICHK.94Sep21133315@netcom12.netcom.com>,
|
|
Richard Krehbiel <richk@netcom12.netcom.com> wrote:
|
|
>
|
|
>Why is everyone hung up on PIC for shared libraries?
|
|
>
|
|
>Why not this way: Take a fairly large chunk of process virtual address
|
|
>space, say 64M or so, and reserve it for shared library code and data.
|
|
>When a shared library is loaded, find an available spot in that range,
|
|
>load it, and then fix up self-relative code and data references with
|
|
>the library's relocation dictionary. This way you don't pay the
|
|
>performance penalty of PIC, and you still avoid library load address
|
|
>conflicts. You have to worry about whether all libraries loaded by
|
|
>all processes will fit into 64M, of course, and someone will have to
|
|
>write a relocating loader.
|
|
|
|
Technically you can do this with ELF. When you build the
|
|
library, just omit -fPIC from GCC. The code generated will ultimately be
|
|
relatively fast, but the startup time will really suck because PIC code
|
|
tends to have far fewer relocations, and they tend to be organized in such
|
|
a way that is more suitable for dynamic linking (i.e. reference
|
|
functions/data through .plt/.got).
|
|
|
|
The one thing I am not entirely clear about is where the
|
|
performance hit for PIC comes from. Is it due to the fact that we lose a
|
|
register, or is it because the addressing modes that are used to reference
|
|
data through the %ebx register are slower. (or both, for that matter).
|
|
Anyone have any guesses?
|
|
|
|
I am not entirely unsympathetic to the complaints about loss of
|
|
performance, but to start with I just want to get vanilla ELF working and
|
|
stable. Once we reach this point, then performance enhancements can be
|
|
considered (and I do have ideas). How much trouble I go to depends upon
|
|
how bad the problem really is, and this will become evident as time
|
|
goes on. Whatever enhancements I make to improve performance will have
|
|
the following properties:
|
|
|
|
1) Fixed address is a possibility, but to achieve this the
|
|
transformation will be local, not global. Thus each user might have
|
|
some utility to pre-load a PIC shared library at some fixed address
|
|
and reduce the startup overhead. The addresses chosen would be local
|
|
to each system, so there would not be a worldwide list of addresses.
|
|
|
|
2) Processing the assembly code is a possibility, but I want
|
|
to eliminate all traces of tables of symbols. The kind of processing
|
|
that I am thinking of would be to change things like foo@GOTOFF(%ebx) to
|
|
foo@GOTOFF, thereby changing the addressing mode of the instruction.
|
|
For a straight PIC library you would lose if you did this, but coupled
|
|
with (1) above, it could be a net win.
|
|
|
|
3) Hacking gcc is a possibility, I suppose. If you assumed that
|
|
people would tend to use libraries generated in step (1), then you
|
|
could eliminate the requirement that %ebx be saved and reserved. This
|
|
would most likely win back all of the performance loss, but it would be
|
|
the hardest.
|
|
|
|
Again, the above are all just ideas, and I make no promises that
|
|
I will attempt to do anything with them. What gets done depends upon
|
|
how bad the performance hit really is.
|
|
|
|
-Eric
|
|
|
|
|
|
--
|
|
"The woods are lovely, dark and deep. But I have promises to keep,
|
|
And lines to code before I sleep, And lines to code before I sleep."
|
|
|
|
------------------------------
|
|
|
|
From: Dejan Ilic <svedja@lysator.liu.se>
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: Thu, 22 Sep 1994 11:11:19 +0200 (MET DST)
|
|
|
|
On 21 Sep 1994, H.J. Lu wrote:
|
|
|
|
> Date: 21 SEP 1994 13:51:26 GMT
|
|
> From: H.J. Lu <hjl@nynexst.com>
|
|
> Newgroups: comp.os.linux.development
|
|
> Subject: Re: Shared Libs: working toward a permanent solution?
|
|
>
|
|
> I have released a complete ELF developement kit for testing. Everything
|
|
> in it is linked with one or more ELF/PIC libraries. From what I have seen
|
|
> so far, the speed of ELF/PIC shared library is pretty good. I hope someone
|
|
> will compile an entire Linux distribution with ELF to see how good/bad
|
|
> it is. With ELF, you can easily make shared libraries without worrying too
|
|
> much :-).
|
|
>
|
|
> FYI, the public release of the Linux C library will contain the ELF
|
|
> version of the shared libraries.
|
|
>
|
|
> H.J.
|
|
>
|
|
>
|
|
|
|
Very nice, but where do we grab it for testing ?
|
|
|
|
------------------------------
|
|
|
|
From: stock@dutsh7.tudelft.nl (Robert Stockmann)
|
|
Subject: Re: Porting applications to TERM
|
|
Date: Wed, 21 Sep 1994 16:44:57 GMT
|
|
|
|
: Porting shouldn't be necessary with the new termnet library. Add in
|
|
: the program Makefile following definitions:
|
|
|
|
: to CFLAGS -include /usr/local/lib/termnet.h (or whereever)
|
|
: to LIBS -ltermnet -L/usr/local/lib ( ="= )
|
|
|
|
: That should do it. Note that -include is not understood by some C
|
|
: compilers (but gcc does grok it :-)
|
|
|
|
: Ideally, programs compiled in this way run with and without term
|
|
: and/or TCP/IP, they always take what's available.
|
|
|
|
: Olaf
|
|
: --
|
|
: ___ olaf@bigred.ka.sub.org - uknf@rz.uni-karlsruhe.de
|
|
: __ o <a href="http://rzstud1.rz.uni-karlsruhe.de/~uknf/">click</a>
|
|
: __/<_ also: s_titz@ira.uka.de - uknf@dkauni2.bitnet - praetorius@irc
|
|
: _)>(_)_________ "now i find that most of the time love's not enough
|
|
in itself"
|
|
|
|
I think its amazing! does that mean that also smail/sendmail can be compiled
|
|
with term within? how can you than receive email if your term pc is
|
|
not registered with a valid hostname?
|
|
|
|
Robert Stockmann
|
|
stock@dutsh7.tudelft.nl
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|