Linux-Development-Sys Digest #234, Volume #8 Wed, 25 Oct 00 01:13:06 EDT
Contents:
back-up for linux workstation... ("Rajendra Jadhav")
back-up for linux workstation... ("Rajendra Jadhav")
Re: back-up for linux workstation... (Lew Pitcher)
ModSSL/Linux 6.1/Apache (Fabien Voland)
Re: Accessing PCI I/O space
Re: Device or resource busy
Re: i820 Camino AGPset: Will it be supported? ("John Hall")
Re: i820 Camino AGPset: Will it be supported? (Nick Maclaren)
unexpected sorting order? (Ronald Cole)
Re: Microsoft Linux API? (Christopher Browne)
mount gets a spam of strange kernel messages ([EMAIL PROTECTED])
Re: using /linuxrc ([EMAIL PROTECTED])
Re: using /linuxrc ([EMAIL PROTECTED])
Semaphore problem (James Moe)
----------------------------------------------------------------------------
From: "Rajendra Jadhav" <[EMAIL PROTECTED]>
Subject: back-up for linux workstation...
Date: Tue, 24 Oct 2000 14:31:14 -0500
Hi,
I wanted to know what type of backing-up system can I use for my Linux
workstation..like can I use a cd writer..or a jazz drive..or something like
that.
Thanks,
--
Rajendra Jadhav
------------------------------
From: "Rajendra Jadhav" <[EMAIL PROTECTED]>
Subject: back-up for linux workstation...
Date: Tue, 24 Oct 2000 14:36:06 -0500
Hi,
I wanted to know what type of backing-up system can I use for my Linux
workstation..like can I use a cd writer..or a jazz drive..or something like
that.
Thanks,
--
Rajendra Jadhav
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: back-up for linux workstation...
Reply-To: [EMAIL PROTECTED]
Date: Tue, 24 Oct 2000 19:58:52 GMT
On Tue, 24 Oct 2000 14:36:06 -0500, "Rajendra Jadhav"
<[EMAIL PROTECTED]> wrote:
>
>Hi,
>
>I wanted to know what type of backing-up system can I use for my Linux
>workstation..like can I use a cd writer..or a jazz drive..or something like
>that.
Any of the above, and more including QIC tape and various flavours of
network backup.
For instance:
I backup one of my machines to CD-RW, the other to a removable HD.
The 'tar' utility was originally designed as a 'tape archive' to back
up to serial media (magnetic tape); it can be used to write archives
to QIC tape.
There are a number of network backup tools around, including IBM's
ADSM, Knox Software's Arkeia, and of course SAMBA and NFS.
Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: [EMAIL PROTECTED] (Fabien Voland)
Subject: ModSSL/Linux 6.1/Apache
Date: Tue, 24 Oct 2000 20:36:59 GMT
Hi!
I have installed the ModSSL package RPM.
Now, when I start Apache httpd, I have a error message : undefined
symbol:ap_global_ctx.
In FAQ of ModSSL, it writes : I must installed a patch for Apache
EAPI. In the site ModSSL, I find a patch but not for Apache/Linux but
only for Apache.
Can you help me for find the patch EAPI for Apache ?
Thanks.
Fabien
====================================================
>From Anywhere
====================================================
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Accessing PCI I/O space
Date: Tue, 24 Oct 2000 22:35:12 -0000
In article <8t0glb$rbh$[EMAIL PROTECTED]>,
Peter Huang <[EMAIL PROTECTED]> wrote:
>with pci memory space. I can call pci_find_device and then ioremap to access
>a pci memory space.
>How do I access PCI I/O space?
Nothing special is needed; just use the regular inb/outb etc.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Device or resource busy
Date: Tue, 24 Oct 2000 22:36:27 -0000
In article <[EMAIL PROTECTED]>,
Ed Hudson <[EMAIL PROTECTED]> wrote:
>I have successfully compiled a driver written for the 2.2 kernel
>series under 2.0.34. When I try to insmod it, I get a message
>init_module() Device or resource busy. The obvious things appear to
>be ok. The card is plugged in, other simple "Hello world" modules
>work fine. Any suggestions?
What does your init_module do? Does it have anything that detects
an error and returns it?
--
http://www.spinics.net/linux
------------------------------
From: "John Hall" <[EMAIL PROTECTED]>
Subject: Re: i820 Camino AGPset: Will it be supported?
Date: Tue, 24 Oct 2000 22:59:05 GMT
Do you mean Framebuffer kernel support, or XFree86 Direct Rendering? Because
"agp" support can be compiled into the kernel generically, it's in the
Character devices section "/dev/agpgart"
.. it's all I needed for my i810 motherboard + video to get Xfree86 4.x
running. But then again I don't do anything "fancy".
"Alessandro Frigeri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On the Character Devices section I noted there's support for all the AGP
> chipsets but not for the i820.
>
> Is that a particular reason for that? If there's a patch for that,
> where could I find it?
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: i820 Camino AGPset: Will it be supported?
Date: 24 Oct 2000 23:27:04 GMT
In article <ZuoJ5.14857$[EMAIL PROTECTED]>,
John Hall <[EMAIL PROTECTED]> wrote:
>Do you mean Framebuffer kernel support, or XFree86 Direct Rendering? Because
>"agp" support can be compiled into the kernel generically, it's in the
>Character devices section "/dev/agpgart"
>
>.. it's all I needed for my i810 motherboard + video to get Xfree86 4.x
>running. But then again I don't do anything "fancy".
>
>"Alessandro Frigeri" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> On the Character Devices section I noted there's support for all the AGP
>> chipsets but not for the i820.
>>
>> Is that a particular reason for that? If there's a patch for that,
>> where could I find it?
Given that recent rumours are that Intel are discontinuing it at the
end of this calendar year (yes, in 10 weeks's time), I doubt that
there will be immense interest in the 820 ....
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Subject: unexpected sorting order?
Date: 24 Oct 2000 16:28:49 -0700
I've always done "sort | uniq", so I never had cause to examine the output
of sort for quite some time.
Now imagine my surprise when I discover that, on my new RedHat 7.0
installation, sorting seems to be folding lowercase to uppercase to
determine sort order!
$ echo "Z
> a" | sort
a
Z
And it's not just sort... even bash is doing it, too!!
$ touch Z a
$ echo *
a Z
However, ls seems to "do the right thing" (i.e., what I expected):
$ ls -1
Z
a
so I'm confused...
LANG is set to "en_US" and there are no LC_* environment variables set
(so no LC_COLLATE). What gives? Am I locale challenged, or what?
Please clue me.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Microsoft Linux API?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 25 Oct 2000 00:47:13 GMT
In our last episode (Tue, 24 Oct 2000 19:21:06 +0200),
the artist formerly known as J.H.Delaney said:
>> Pretty soon, Microsoft can use this dependency to
>> leverage control over the Linux marketplace.
>Will never happen. Sure, Microsoft 'ports' some apps to linux,
>but... Its **BINARYS** they deliver, not source code. People that
>love linux, love it because they can modify anything they want. Cant
>do that with binarys.
True to a significant extent.
>> multiple operating systems, not just Linux. If apps start
>> coming to Linux so that it is of very high value and runs
>> specifially for Linux, THAT is the day when Windows will see
>> serious competition. However, if Microsoft was to become the
>
>There already are application on linux that are of very high
>value. And most of the people that use linux dont really care about
>windows, so they will not 'switch' to linux just cause windows has a
>cool new feauture.
The critical factor is that there is a Whole Lot Of Stuff that runs on
Linux that conforms with the expectations of _Unix_ environments;
Microsoft has little to offer in that regard. They wound up buying up
folks that were building tools to "do Unix stuff on Windows NT."
>> Linux must play to the human psychie.
>They already do. People who use linux, use linux because they like
>*nix in general, and because they like open source. THAT is the power
>of linux. These people will never leave linux for another OS, they
>will ADD any cool feature seen in another OS to linux themselves.
"Unix *is* user friendly. It's just selective about who its friends
are..."
Part of the power of Linux and Unix comes in that they allow the
expert user to actually have something to be expert about; while with
Windows, there may be _nobody_ that understands what's going on
underneath, there is a significant population that _do_ understand how
Unix works.
The value of that can be overstated, but it should not merely be
minimized if it were irrelevant. The fact that some people can and do
understand Unix means that they can get a lot done with it.
Linux "plays" to the psyche of those that have a desire to understand
how things work, and rewards such understanding.
Neal Stephenson characterizes this eminently well in his excellent
essay/book "In The Beginning Was The Command Line."
<http://www-classic.be.com/users/cryptonomicon/beginning_print.html>
"The average computer user is a technological antiquarian who doesn't
really like things to change. He or she is like an urban professional
who has just bought a charming fixer-upper and is now moving the
furniture and knicknacks around, and reorganizing the kitchen
cupboards, so that everything's just right. If it is necessary for a
bunch of engineers to scurry around in the basement shoring up the
foundation so that it can support the new cast-iron claw-foot bathtub,
and snaking new wires and pipes through the walls to supply modern
appliances, why, so be it--engineers are cheap, at least when millions
of OS users split the cost of their services."
There _is_ room in the universe both for "technological antiquarians"
who can cope only with "reorganizing the cupboards so they look right"
as well as for engineers that are capable of snaking new wires through
the walls.
--
(concatenate 'string "cbbrowne" "@" "ntlug.org")
<http://www.ntlug.org/~cbbrowne/unix.html>
UNIX *is* user friendly. It's just selective about who its friends
are...
------------------------------
From: [EMAIL PROTECTED]
Subject: mount gets a spam of strange kernel messages
Date: Wed, 25 Oct 2000 04:03:18 -0000
My console gets spammed with a bunch of these kernel messages when I do
a mount on a certain partition, but only on that one, or the like one
of the same size and position on hdb. This does not happen on others.
Can someone tell me what these kernel messages MEAN? What are they
trying to tell me (or is it me they are trying to tell, or a developer?).
The partition is hda1.
Here's what my hda partition layout looks like (hdb is identical):
Disk /dev/hda: 255 heads, 63 sectors, 5606 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 8 64228 83 Linux native
/dev/hda2 9 16 64260 83 Linux native
/dev/hda3 17 312 2377620 5 Extended
/dev/hda4 313 5606 42524055 83 Linux native
/dev/hda5 17 40 192748 83 Linux native
/dev/hda6 41 56 128488 83 Linux native
/dev/hda7 57 88 257008 83 Linux native
/dev/hda8 89 120 257008 83 Linux native
/dev/hda9 121 264 1156648 83 Linux native
/dev/hda10 265 288 192748 83 Linux native
/dev/hda11 289 312 192748 82 Linux swap
Device Boot Start End Blocks Id System
/dev/hda1 64 128519 64228 83 Linux native
/dev/hda2 128520 257039 64260 83 Linux native
/dev/hda3 257040 5012279 2377620 5 Extended
/dev/hda4 5012280 90060389 42524055 83 Linux native
/dev/hda5 257104 642599 192748 83 Linux native
/dev/hda6 642664 899639 128488 83 Linux native
/dev/hda7 899704 1413719 257008 83 Linux native
/dev/hda8 1413784 1927799 257008 83 Linux native
/dev/hda9 1927864 4241159 1156648 83 Linux native
/dev/hda10 4241224 4626719 192748 83 Linux native
/dev/hda11 4626784 5012279 192748 82 Linux swap
I did mke2fs on the partition like so:
mke2fs -b 4096 -i 4096 -m /dev/hda1
These are the kernel messages I get from just one time mounting:
set_blocksize: b_count 1, dev ide0(3,1), block 16000, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16001, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16002, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16003, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16004, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16005, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16006, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16007, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16008, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16009, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16010, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16011, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16012, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16013, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16014, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16015, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16016, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16017, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16018, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16019, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16020, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16021, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16022, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16023, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16024, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16025, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16026, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16027, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16028, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16029, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16030, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16031, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16032, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16033, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16034, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16035, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16036, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16037, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16038, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16039, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16040, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16041, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16042, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16043, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16044, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16045, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16046, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16047, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16048, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16049, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16050, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16051, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16052, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16053, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16054, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16055, from c0143b9b
set_blocksize: b_count 1, dev ide0(3,1), block 16056, from c0143b9b
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: using /linuxrc
Date: Wed, 25 Oct 2000 04:12:31 -0000
On Mon, 23 Oct 2000 08:23:01 +0200 Josef Moellers <[EMAIL PROTECTED]>
wrote:
| [EMAIL PROTECTED] wrote:
|>
|> I'm about to make use of the /linuxrc feature. I'm interested in any
|> experiences people who have tried this for various purposes may have.
|> I don't need any help (yet) on making this happen; I'm just wanting
|> to be wary of any quirks I may encounter.
|
| AFAIK, despite the fact that the first line looks like a shebang calling
| /bin/bash, linuxrc is NOT a shell script and you won't be able to use
| (full) shell functionality there. You can put a few insmods in there,
| but that's about it.
|
| I'd be very happy if my view is incorrect, because I too need to call
| some external programs and do some flow control in there.
The first line? What first line? Maybe you're referring to some actual
script that runs as /linux (which I am not aware of).
My intention is to have a C program compiled without any libraries be
run as the /linuxrc program to do the things mentioned in my prior post.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: using /linuxrc
Date: Wed, 25 Oct 2000 04:20:45 -0000
On 24 Oct 2000 07:15:27 +0200 Peter Pointner <[EMAIL PROTECTED]> wrote:
| Josef Moellers <[EMAIL PROTECTED]> wrote:
|> [EMAIL PROTECTED] wrote:
|>>
|>> I'm about to make use of the /linuxrc feature. I'm interested in any
|>> experiences people who have tried this for various purposes may have.
|>> I don't need any help (yet) on making this happen; I'm just wanting
|>> to be wary of any quirks I may encounter.
|
|> AFAIK, despite the fact that the first line looks like a shebang calling
|> /bin/bash, linuxrc is NOT a shell script and you won't be able to use
|> (full) shell functionality there. You can put a few insmods in there,
|> but that's about it.
|
| Fortunately, it _is_ a shell script. From the kernel sources (2.2.13):
|
| static int do_linuxrc(void * shell)
| {
| static char *argv[] = { "linuxrc", NULL, };
|
| close(0);close(1);close(2);
| setsid();
| (void) open("/dev/console",O_RDWR,0);
| (void) dup(0);
| (void) dup(0);
| return execve(shell, argv, envp_init);
| }
Just because the function argument variable name is "shell" does not mean
it has to be a shell script. In fact what is passed comes from:
#ifdef CONFIG_BLK_DEV_INITRD
root_mountflags = real_root_mountflags;
if (mount_initrd && ROOT_DEV != real_root_dev
&& MAJOR(ROOT_DEV) == RAMDISK_MAJOR && MINOR(ROOT_DEV) == 0) {
int error;
int i, pid;
pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
if (pid>0)
while (pid != wait(&i));
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "
"error %d\n",error);
}
}
#endif
... so all it is doing is executing /linuxrc just the same way as it
does any other executeable. It does so in a new kernel thread, so the
one for PID 1 can be used to really run init when the time comes.
| I use linuxrc on an embedded system to start inetd and some other
| processes. Works fine.
Why do you need to have inetd start before init starts? Just curious.
IWSTM that you can just start everything from init if you are already
mounted on the final / filesystem. I'll be using /linuxrc to build
that / filesystem.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: James Moe <[EMAIL PROTECTED]>
Subject: Semaphore problem
Date: Wed, 25 Oct 2000 04:55:52 GMT
Hello,
[ This is a re-post. Somehow I managed to post it in a group that
no one visits. Urk.]
I am using Rehat 6.1 (kernel v2.2.12) and v6.2 (v2.2.14). The
problem
described below occurs in both versions.
In brief: When running as the superuser (no problem if
non-superuser), it is possible to completely freeze the system by
making a blocking call to semop() to acquire a semaphore (sembuf =
{id, -1, 0}) My best guess is that the kernel is blocking (!);
Interrupts are handled, interactive input is utterly ignored. The
only option I have found is a hard reset.
The programs make heavy use of pthreads, and it is in one of the
threads that the semaphore call is made. Also the call must be to a
semaphore in the set that is not the zero-th entry, ie, semnum > 0.
The way it (is supposed to) work:
The semaphores are being used as signals between two processes.
Process1 creates a thread that generates data (to simulate the target
environment), posts it in shared memory, releases a semaphore (sem1)
and waits for a response from process2.
Process2 is blocked on sem1; when it is acquired, process2
does stuff with the data, releases sem2 that signals process1
that response data awaits, and blocks on sem1 again.
Process1 has a receiver thread (where the problem occurs) that
blocks
on acquiring sem2. When process2 releases sem2, the receiver loop
decants the response data, stores it locally, signals the waiting
thread, and blocks on sem2 again.
This is odd enough, but wait! It gets better. I created a timed
acquire that does this:
1. Makes a non-blocking call to acquire the sem. If it succeeds the
function returns.
2. If not, the semop() call is made in a separate thread that signals
a mutex in the calling function when the sem is acquired.
3. At the same time a timed wait is made on the signalling mutex.
4. So either the semop() succeeds and signals the mutex, or the mutex
times out and the semop thread is cancelled.
5. The function returns true if acquired, false otherwise.
The important point here is that there is a blocking semop() call in
a thread that works just fine. Just like the one in the receiver loop
where the system freezes. More curiously, the timed acquire works
fine in the receiver whereas the simple acquire does not.
A sort of picture of the programs:
process 1 process 2
===========================================+===================
receiver loop thread:
sem2.trylock(); <-- pre-locks the sem
loop
sem2.lock(); <-- where it freezes
// sem2.lock_timed(x); <-- ok!
get data
signal thread
endloop
Each data-generating thread: sem1.trylock(); <--
pre-lock
make data loop
add to shanred memory sem1.lock(); <-- wait
sem1.unlock(); <-- signals process 2 get data
await signal from receiver send response
end of thread sem2.unlock();
endloop
--
sma at rtd dot com
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
