579 lines
21 KiB
Plaintext
579 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: Sat, 15 Oct 94 13:13:11 EDT
|
|
Subject: Linux-Development Digest #312
|
|
|
|
Linux-Development Digest #312, Volume #2 Sat, 15 Oct 94 13:13:11 EDT
|
|
|
|
Contents:
|
|
Re: Shared Libs: working toward a permanent solution? (H. Peter Anvin)
|
|
Re: GNUStep...Is It Real or Just a Hoax?!? (Martin Michlmayr)
|
|
We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
|
|
Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Thomas Koenig)
|
|
Re: Shared Libs: working toward a permanent solution? (Bryan Ford)
|
|
Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... (Michael Clarkson)
|
|
Re: A badly missed feature in gcc (Kevin Lentin)
|
|
Re: ext2fs vs. Berkeley FFS (Piers Cawley)
|
|
Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Donald Becker)
|
|
Re: A badly missed feature in gcc (Nate Williams)
|
|
1.1.52 breaks Ingres creatdb (Enrico Badella)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Reply-To: hpa@nwu.edu (H. Peter Anvin)
|
|
Date: Sat, 15 Oct 1994 04:28:07 GMT
|
|
|
|
Followup to: <1994Oct14.215138.3368@kf8nh.wariat.org>
|
|
By author: bsa@kf8nh.wariat.org (Brandon S. Allbery)
|
|
In newsgroup: comp.os.linux.development
|
|
>
|
|
> I think you misunderstand his intent: he's talking about using a segment
|
|
> register as if it were a general register containing an address. Basically,
|
|
> using e.g. %gs as one would normally use %bp. Segment overrides would not be
|
|
> used in this scheme; instead, the address would be calculated when needed by
|
|
> adding %gs to the library-base-relative address.
|
|
>
|
|
|
|
No, no, no... that wouldn't work at all, especially since we're
|
|
talking 32-bit offsets here. What I am talking about is using segment
|
|
aliasing; a segment can overlap another, but possibly with another
|
|
base (beginning offset). Segment overrides can then be used instead
|
|
of a base pointer register.
|
|
|
|
/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
|
|
Microsoft is not the answer. Microsoft is the question. NO is the answer.
|
|
|
|
------------------------------
|
|
|
|
From: tbm@tci002.uibk.ac.at (Martin Michlmayr)
|
|
Subject: Re: GNUStep...Is It Real or Just a Hoax?!?
|
|
Date: 14 Oct 1994 15:19:41 GMT
|
|
|
|
Derrik Walker II (dwalker@omega.csuohio.edu) wrote:
|
|
: I Seem to remember reading somewhere that FSF was working on a NeXTStep
|
|
: like environment (user and Development) that was Fully OOP - based and
|
|
: Display PS. This is intended to be ran on Linux for Mach 3.0 (Assuming
|
|
: the Linux on Mach is also a real profect, of course).
|
|
|
|
There is such a project.
|
|
GNUStep will run under X.It is as portable as the GNU Objective-C
|
|
compiler. This current includes SunOS 4.1, Solaris 2.3, Ultrix 4.2, HP/UX
|
|
9.x, SGI IRIX, OSF/1, FreeBSD, Linux, and perhaps others (but not AIX).
|
|
|
|
There are several parts, which together build the GNU OpenStep project.
|
|
One of those parts is the objcX library.
|
|
objcX emulates NeXTSTEP and not OpenStep. There is a lot of work to do
|
|
to convert it to OpenStep.
|
|
|
|
There is no Display PostScipt suport yet, Keith Mason <keith@netcom.com>
|
|
is coding this.
|
|
|
|
There is also a FAQ, please contact me to get it.
|
|
:
|
|
: So is this all a bunch of bull shit or is it real. I love both Linux and NS,
|
|
: and a combaniation of the two would be the greatest!
|
|
|
|
It is real, to join the mailing list, send mail to
|
|
gnustep-l-request@netcom.com.
|
|
|
|
: If there is such a project, who do I contact to get involved?
|
|
|
|
me (tbm@tci002.uibk.ac.at)
|
|
|
|
: -Derrik
|
|
: d.k.walker85@csuohio.edu dwalker@omega.csuohio.edu
|
|
: http://pclab19.law.csuohio.edu:8099/html/dwalker/home.html
|
|
|
|
|
|
|
|
|
|
Martin Michlmayr <tbm@tci002.uibk.ac.at>
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.386bsd.development,comp.sys.unix
|
|
From: jmonroy@netcom.com (Jesus Monroy Jr)
|
|
Subject: We a FAQ: Linux vs. *BSD!!!
|
|
Date: Thu, 13 Oct 1994 08:31:14 GMT
|
|
|
|
This is a weekly question.
|
|
More often than not, we get into a flame war
|
|
on this. Let's stop this silliness!!!
|
|
|
|
Can we get together and write a single FAQ on this?
|
|
|
|
The distraction is overwhelming and we need a solution.
|
|
|
|
|
|
I propose a single FAQ to answer the question:
|
|
|
|
Which is better Linux or *BSD?
|
|
|
|
It would have standard update procedures and
|
|
should be carried by the appropriate *.announce.
|
|
|
|
Do I get a Yeah on this?
|
|
|
|
|
|
--
|
|
Jesus Monroy Jr jmonroy@netcom.com
|
|
Zebra Research
|
|
/386BSD/device-drivers /fd /qic /clock /documentation
|
|
___________________________________________________________________________
|
|
|
|
------------------------------
|
|
|
|
From: ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig)
|
|
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
|
Date: 10 Oct 1994 22:41:50 GMT
|
|
Reply-To: Thomas.Koenig@ciw.uni-karlsruhe.de
|
|
|
|
Jeff Kuehn (kuehn@citadel.scd.ucar.edu) wrote in comp.os.linux.development,
|
|
article <37c8hk$ekl@ncar.ucar.edu>:
|
|
|
|
> 6. And of course, the scheduler sucks mud.
|
|
|
|
I remember Matthias Urlichs reporting excellent results with the BSD
|
|
scheduler. Would it be possible to run this test again, with this
|
|
scheduler patched in?
|
|
--
|
|
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
|
|
The joy of engineering is to find a straight line on a double
|
|
logarithmic diagram.
|
|
|
|
------------------------------
|
|
|
|
From: Bryan Ford <baford@schirf.cs.utah.edu>
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: 15 Oct 1994 11:09:18 -0400
|
|
Reply-To: baford@schirf.cs.utah.edu
|
|
|
|
In message <9410141722.AA00498@dcl.MIT.EDU> you write:
|
|
| Date: Fri, 14 Oct 94 09:12:10 MDT
|
|
| From: Bryan Ford <baford@schirf.cs.utah.edu>
|
|
|
|
|
| >The real problem with this sort of solution is that you have to educate
|
|
| >GCC about segment registers, and you have to include the segment number
|
|
| >into a pointer. Otherwise, how is GCC supposed to know whether a
|
|
| >pointer was pointing at memory from the library's data segment, or at
|
|
| >memory passed in from the caller?
|
|
|
|
|
| It doesn't need to. Any pointer that actually gets passed around in
|
|
| a program in variables and such is still a 32-bit, absolute, "small model"
|
|
| pointer as usual. The only thing that needs to be changed is the method
|
|
| of accessing or taking the address of a static variable. To take the
|
|
| address of a static variable, just convert the segment-register-relative
|
|
| offset to a global, absolute offset by adding the base address of the
|
|
| library, and use the resulting absolute pointer thereafter. This will
|
|
| work as long as a particular shared library doesn't move around in
|
|
| a particular process's address space _while_it_is_running_, which would
|
|
| be rather insane anyway. :-)
|
|
|
|
|
|Unfortuantely, life's not that simple. What if you take the address of
|
|
|a static variable, and store it into a structure? That structure member
|
|
|might contain a pointer to a static variable local to the shared
|
|
|library, or it might contain a pointer to memory in the main program's
|
|
|data segment.
|
|
|
|
|
|Or what the library routine needs to return the pointer to a static
|
|
|variable, like gethostbyname() does?
|
|
|
|
If the library takes a pointer to a static variable and stashes it in
|
|
a structure, passes it around, to the user, to twenty other libraries,
|
|
etc., it'll still work fine, because such pointers are _always_ relative
|
|
to the global data segment (DS), which permits access to the whole
|
|
virtual address space (including the libraries, at various offsets).
|
|
You only use the "special" segment register (GS or FS) to _directly_
|
|
access static variables within a library. If you take the address of
|
|
a static variable in a library, the GCC-generated code _immediately_
|
|
converts the GS-relative offset into a DS-relative offset, and that
|
|
offset becomes the value of the pointer variable. A DS-relative pointer
|
|
can be passed around arbitrarily and used anywhere.
|
|
|
|
|Without compiler support, people who code shared libraries would have
|
|
|to be very aware of the segmentation issues, since they would have to
|
|
|handle them by hand --- just as we do in the kernel. I doubt that would
|
|
|be popular with applications programers.
|
|
|
|
You're still assuming I'm, proposing a general multisegment model.
|
|
I'm not! I'm just proposing to use a segment register instead of ebx
|
|
(or whatever) to _initially_ find the address of static variables in
|
|
a library. _All_ pointer variables, in library code or client code,
|
|
are _always_ relative to the _global_ segment (DS), and can be passed
|
|
anywhere and used for anything. It's not a change in model at all;
|
|
just a minor architecture-specific hack to avoid losing a register.
|
|
|
|
Maybe an example would help. First, some C code:
|
|
|
|
/* these are in a shared library */
|
|
extern int foo;
|
|
static bar = 3;
|
|
|
|
int *blah()
|
|
{
|
|
int *x;
|
|
|
|
foo = bar;
|
|
x = &bar;
|
|
*x = 5;
|
|
return x;
|
|
}
|
|
|
|
/* this is in non-PIC client code */
|
|
void main()
|
|
{
|
|
int *x = blah();
|
|
|
|
printf("result: %d\n", *x);
|
|
}
|
|
|
|
Possible generated library code for blah():
|
|
|
|
_blah:
|
|
pushl %fs
|
|
|
|
/* Load the library's data segment selector into fs. */
|
|
jsr 0f
|
|
0: popl %eax
|
|
movl _libseg-0b,%eax
|
|
movw %ax,%fs
|
|
|
|
/* Assign from one library variable to another.
|
|
Note that the values of the labels _bar and _foo,
|
|
as the linker defines them, are library-relative.
|
|
Hence we use %fs to access them. */
|
|
movl %fs:_bar,%eax
|
|
movl %eax,%fs:_foo
|
|
|
|
/* Take a pointer (x) to a static library variable (bar).
|
|
Take the linker-defined library-relative offset
|
|
and add the address of the library
|
|
to find the global DS-relative pointer value. */
|
|
movl $_bar,%eax
|
|
addl %fs:_libofs,%eax
|
|
|
|
/* Access the data pointed to by that pointer from the library.
|
|
All pointer variables are DS-relative, not FS-relative,
|
|
even in the library, so don't specify a segment override at all. */
|
|
movl $5,(%eax)
|
|
|
|
/* Return the pointer to the client as well.
|
|
Since it's already DS-relative,
|
|
the client can access it with no problems. */
|
|
|
|
popl %fs
|
|
ret
|
|
|
|
(The code generated for main() is completely normal, non-PIC code.)
|
|
|
|
_libseg and _libofs are static variables in the library,
|
|
which are filled in when the library is loaded with the library's
|
|
data segment selector and the offset needed to convert an offset
|
|
relative to that selector into an offset relative to the global DS.
|
|
|
|
The stack pointer is always global (DS-relative) and shared by
|
|
all libraries and clients, so taking the address of an automatic
|
|
variable operates completely as usual. Taking the address of a
|
|
function would operate just like taking the address of a static
|
|
variable - add the library's base address to come up with a global
|
|
address. That way libraries can even pass function pointers to
|
|
other libraries or to clients.
|
|
|
|
Note that the code above could probably be optimized in various ways;
|
|
for one thing, it's really only necessary to load segment registers
|
|
in routines that are public entrypoints that can be called from
|
|
client code or from other libraries. Also, it might be possible to
|
|
use the CS register instead of FS or GS as the library base "pointer";
|
|
the implementation would look quite different but mostly the same
|
|
principles would apply. But these are just "possible optimizations";
|
|
the code as I presented it should work just fine.
|
|
|
|
Does this make things a little clearer?
|
|
|
|
Bryan
|
|
|
|
------------------------------
|
|
|
|
From: paco@faxil.leeds.ac.uk (Michael Clarkson)
|
|
Subject: Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive...
|
|
Date: Thu, 13 Oct 1994 09:42:55 +0100 (BST)
|
|
|
|
Rob Newman wrote:
|
|
|
|
: We have similar problems --
|
|
|
|
|
|
: our setup:
|
|
|
|
: 486-DX2 66
|
|
: IDE 720MB hard disk ( NO SCSI ! )
|
|
: 8 MB RAM
|
|
: NE2000 ethernet card
|
|
|
|
: In our setup, the hangs started when I upgraded from 1.1.10 to 1.1.45, and
|
|
: became signicantly less frequent when I went to 1.1.50. Man, if you figure
|
|
: this out, I'd much appreciate it!
|
|
|
|
: Rob
|
|
|
|
We also have experienced similar problems:
|
|
|
|
our setup:
|
|
|
|
P5-66
|
|
WD Caviar 540 Mb HD
|
|
16 MB Ram
|
|
16 Mb Swap
|
|
NE2000 Ethernet Card
|
|
PCI STB Lightspeed 2Mb Ram
|
|
|
|
|
|
Looking at the postings relating to this problem, it appears that the
|
|
connecting piece of hardware is the NE2000 Ethernet Card. In fact we seem
|
|
to have crudely fixed the problem by , by slowing down the reads/writes
|
|
performed by the Network Card.
|
|
|
|
If anyone else could suggest a better fix, please let me know.
|
|
|
|
|
|
Mike.
|
|
|
|
--
|
|
Michael Clarkson
|
|
Research Assistant
|
|
______ __ __ __ _ _
|
|
| ____|/ \ \ \ / /(_)| | FAXiL,
|
|
| |___ / /_ \ \ \/ / _ | | The Wellcome Wing,
|
|
| ___| ____ \ > < | || | The General Infirmary,
|
|
| | / / \ \/ /\ \ | || |____ Leeds LS1 3EX, UK.
|
|
|_| /_/ \_\/ \_\|_||______| Tel: 0113 2923595 Fax: 0113 2420926
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: kevinl@fangorn.cs.monash.edu.au (Kevin Lentin)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 13 Oct 1994 02:23:26 GMT
|
|
|
|
Jeff Kesselman (jeffpk@netcom.com) wrote:
|
|
|
|
> Whats REALLY scary about thsi is you have just inroduced a dependancy on
|
|
> a carraige-return into a language that previously assigned no syntactic
|
|
> signifigance to a carriage-return beyond that of any other sperator.
|
|
|
|
> (Before you cite macros, remember that these are handle dby the
|
|
> pre-processor, NOT the compiler proper.)
|
|
|
|
So are comments. The only non-C things the compiler sees are the # nn file
|
|
Directives so it knows where source comes from. So there is still no
|
|
meaning to the carriage return added to the comment syntax as far as the
|
|
compiler is concerned.
|
|
|
|
That aside, I believe C++ comments are better. They're great for single
|
|
line comments, make temporary removal of a line easy (I still use C
|
|
comments for temporary removal of small blocks of code and #if for bigger
|
|
ones). BUT I think C should remain C. You're just going to break something
|
|
somewhere eventually.
|
|
|
|
--
|
|
[==================================================================]
|
|
[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
|
|
[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
|
|
[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
|
|
[==================================================================]
|
|
|
|
------------------------------
|
|
|
|
From: pdcawley@ftech.co.uk (Piers Cawley)
|
|
Subject: Re: ext2fs vs. Berkeley FFS
|
|
Date: Fri, 14 Oct 1994 13:36:44 +0000
|
|
|
|
|
|
In article <CHRISB.94Oct11174651@stork.cssc-syd.tansu.com.au>
|
|
chrisb@stork.cssc-syd.tansu.com.au (Chris Bitmead) writes:
|
|
In another article someone writes:
|
|
> Stuff about adding 'forks' to the filesystem deleted
|
|
|
|
But the question still remains: Why do you want this???
|
|
|
|
Because it makes things simpler for many uses, especially for stuff like
|
|
associating documents with applications and the like -- file is generally not
|
|
clever enough to do this sort of thing. One could almost certainly write a far
|
|
more intuitive Desktop type frontend to X if you could be sure that all files
|
|
had associated info/data/resource forks.
|
|
|
|
You say you would like a "main fork" in a file and then various
|
|
"attribute" forks. Why this is better than a directory I don't know.
|
|
|
|
Because it makes it easier to write code. Even if it's syntactic sugar
|
|
'f0=open(foobar:INFO,RD_ONLY);' makes a good deal of sense, especially in
|
|
cases where foobar is an executable. I know you can stash a good deal of this
|
|
stuff in your .Xdefaults file and in /usr/lib/foobar or whereever, but it's
|
|
not exactly intuitive is it? Using data forks means that it becomes far easier
|
|
for a naive luser to move software about without breaking it by accident.
|
|
|
|
Why should there be one "main" fork? And why are you too lazy to use cp -r
|
|
to copy them?
|
|
|
|
Okay, you copy a fully working X application from one machine to another so
|
|
that it behaves in the same way on the new host as it did on the first one.
|
|
Now ask someone who doesn't have a great deal of experience with X to do the
|
|
same thing. Ask them to do the same thing with a Mac Application. I'll bet
|
|
good money that they do a far better job of the latter.
|
|
|
|
What if you start to want forks with sub-forks. Soon you'll start to want
|
|
the full facilities of directories, and we might as well leave it the way
|
|
it is.
|
|
|
|
Oh don't be stupid.
|
|
|
|
Don't be influenced by the over-featurism that NT offers. There's no need
|
|
for this crud.
|
|
|
|
Actually, my model for this sort of thing is the Mac filesystem. I wouldn't
|
|
call it overfeatured, but it does a lot of stuff very well, and very easily,
|
|
that is a royal PITA to accomplish with Unix.
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
|
|
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
|
|
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
|
|
Date: 15 Oct 1994 10:11:34 -0400
|
|
|
|
[[ I rarely quote whole articles, but this one seemed important. ]]
|
|
|
|
In article <37mui3$44c@mickey.iaccess.za>,
|
|
Steve Davies <steve@iaccess.za> wrote:
|
|
>We experience a problem on out Linux 1.1.19 systems where
|
|
>the inetd goes deaf and won't handle any more incoming connections.
|
|
>
|
|
>If you run inetd in debugging mode then as I recall you see that
|
|
>select() starts to return -1 [Dimly remembered]
|
|
>
|
|
>The fix is to kill inetd and start a new one.
|
|
>
|
|
>The cause? I have found that the problem is caused by people connecting
|
|
>with SLIP and using the *wrong IP address* on their end. In other words
|
|
>they have configured their IP stack with an address different from that
|
|
>in the diphosts file.
|
|
|
|
This would explain a lot!
|
|
The problem is unlikely to happen with other connection types.
|
|
Most people that could track this problem down have correctly configured
|
|
connections and never see the problem.
|
|
|
|
--
|
|
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: nate@bsd.coe.montana.edu (Nate Williams)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 12 Oct 1994 22:58:20 GMT
|
|
|
|
In article <CHRISB.94Oct11172758@stork.cssc-syd.tansu.com.au>,
|
|
Chris Bitmead <chrisb@stork.cssc-syd.tansu.com.au> wrote:
|
|
>In article <wcreator.781655152@kaiwan009> wcreator@kaiwan.com (Steven M. Doyle) writes:
|
|
[ Using #ifdef or // to comment out lines out code ]
|
|
|
|
>>>use:
|
|
>>>#if 0
|
|
>>>#endif
|
|
|
|
>> To each his own. I personally use both in debugging my programs,
|
|
>>for one reason. I see no reason to add the #if/#endif when one or three
|
|
>>lines of code is being commented out. It's much simpler just to use /**/ or
|
|
>>//.
|
|
|
|
>Using comments is foolish IMO. With ifdef you can easily grep though the
|
|
>code to remove or look at commented out code. With C comments, it just
|
|
>gets lost.
|
|
|
|
And it totally confuses code formatters like indent. With ifdef, you are
|
|
forced to make a (useless?) line which might give the reader an idea
|
|
why the code is commented out.
|
|
|
|
|
|
|
|
Nate
|
|
|
|
--
|
|
nate@bsd.coe.montana.edu | FreeBSD core member and all around tech.
|
|
nate@cs.montana.edu | weenie.
|
|
work #: (406) 994-4836 |
|
|
home #: (406) 586-0579 | Available for contract/otherwise work.
|
|
|
|
------------------------------
|
|
|
|
From: eb@iunet.it (Enrico Badella)
|
|
Subject: 1.1.52 breaks Ingres creatdb
|
|
Date: 14 Oct 1994 08:21:48 GMT
|
|
|
|
Has anyone used University Ingres with kernel 1.1.52? My impression is
|
|
that there is some problem handling environment variables of non root
|
|
users and/or setuid apps.
|
|
|
|
Quite a while ago I compiled University Ingres 8.9 with linux 0.99 and created
|
|
a installation diskette. I have used it on 1.0.8, 1.1.0, 1.1.20 and 1.1.45
|
|
linux kernels without problems. Now that I have upgraded to 1.1.52 the creatdb
|
|
utility refuses to work but everything else works fine. If I'm root creatdb
|
|
will effetively create a database in $INGRES/data/base but all file will be
|
|
owned by root, so they are not accessible but standard ingres commands. If
|
|
I try to create a database as an unpriviledged user the file will be written
|
|
in the current directory instead of $INGRES/data/base. If I created the
|
|
database with a kernel < 1.1.52 then swith to 1.1.52 everything works fine.
|
|
|
|
Any ideas before I plunge into debugging creatdb.c?
|
|
|
|
Thanks
|
|
eb
|
|
|
|
|
|
================================================================================
|
|
Enrico Badella email softstar@pol88a.polito.it
|
|
Soft*Star s.r.l. eb@vax.cnuce.cnr.it
|
|
Via Camburzano 9 phone +39-11-746092
|
|
10143 Torino, Italy fax +39-11-746487
|
|
|
|
People are strange
|
|
When you're a stranger (J. Morrison)
|
|
================================================================================
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|