499 lines
21 KiB
Plaintext
499 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: Fri, 2 Sep 94 20:13:08 EDT
|
|
Subject: Linux-Development Digest #107
|
|
|
|
Linux-Development Digest #107, Volume #2 Fri, 2 Sep 94 20:13:08 EDT
|
|
|
|
Contents:
|
|
Re: svgalib can't open /dev/mem w/1.1.47 (Christopher Wiles)
|
|
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Mitchum DSouza)
|
|
Re: IDE Hard Drives w/ over 1024 cylinders (Lawrence A. Palmer)
|
|
Re: tcl/tk XF application? (Stewart Allen)
|
|
Mosaic and other TCP/IP problems (Stewart Allen)
|
|
Re: ext2fs floppy/82077 corruption with 1.1.49 (login_menu)
|
|
Re: DEC EtherWorks 3 (Kurt M. Hockenbury)
|
|
Re: SERIAL BUG! getty_ps/Linux 1.09/Rockwell modems (Jeanette Pauline Middelink)
|
|
Mounting Sector-translated IDE drives (Dorwin Shields)
|
|
Re: SOCK_PACKET: Why not reading outgoing packets ? (Peter Howlett)
|
|
Re: PRIORITY make an undelete command (Mark A. Horton KA4YBR)
|
|
Re: Future of linux -- the sequel (Mike Kenney)
|
|
Re: MATROX PCI Graphics board supported ?? (Yasuo Ohgaki)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help
|
|
From: a0017097@wsuaix.csc.wsu.edu (Christopher Wiles)
|
|
Subject: Re: svgalib can't open /dev/mem w/1.1.47
|
|
Date: Thu, 1 Sep 1994 15:28:20 GMT
|
|
|
|
mpl@pegasus.bl-els.att.com (-Michael P. Lindner) writes:
|
|
|
|
: I was running the SLS 2.0 kernel, and built a 1.1.47 kernel from source
|
|
: (why mess around with older kernels :^). All of a sudden, things which
|
|
: svgalib (gs and sasteroids, for example) stopped working with a "can't
|
|
: open /dev/mem" message.
|
|
|
|
<snip>
|
|
|
|
This should be fixed with svgalib 1.1.4. Just fired off a message to
|
|
Harm about both the /dev/mem _and_ dlltools 2.1.6 incompatibility.
|
|
|
|
-- 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: Mitchum.DSouza@mrc-apu.cam.ac.uk (Mitchum DSouza)
|
|
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
|
|
Date: 2 Sep 1994 09:58:35 GMT
|
|
|
|
In article <3453ud$i9v@bosnia.pop.psu.edu>, barr@pop.psu.edu (David Barr) writes:
|
|
|> In article <RSANDERS.94Sep1120109@hrothgar.mindspring.com>,
|
|
|> Robert Sanders <rsanders@mindspring.com> wrote:
|
|
|> >On 1 Sep 1994 10:38:46 -0400, barr@pop.psu.edu (David Barr) said:
|
|
|> >> Sure, but the loader mechansim is significantly different than
|
|
|> >> Solaris', so it's not really the same.
|
|
|> >
|
|
|> >Could you be a bit less concise here? Solaris uses ld.so to load the
|
|
|> >shared libraries; Linux uses ld.so to load the shared libraries.
|
|
|>
|
|
|> Right. However, as I said the loader (ld.so) is significantly
|
|
|> different between Linux and Solaris. When I said loader I mean
|
|
|> loader. What else shall I say?
|
|
|>
|
|
|> Okay, I'll spell it out. In Solaris, the filename of the shared
|
|
|> libraries to load are stored at compile-time. There's also
|
|
|> run-time directory search list which is built from ld's -R flag and
|
|
|> LD_LIBRARY_PATH, if set.
|
|
|
|
I had patches to ld/ld.so to implement this for linux, but it is not really
|
|
worth the extra binary bloat by recording paths at compile-time. Having a
|
|
sensible cache in place is usually enough to satisfy the linking procedure.
|
|
The next-generation executable format for linux (ELF) will have this feature
|
|
by default (I remember seeing it in the EYC patches) as it is quite easy to
|
|
add sections to this format. You wll find it interesting that SunDOS which like
|
|
linux uses the standard a.out format does NOT have -R option to the linker and
|
|
does not support path-recording. However Slowaris which uses the ELF format for
|
|
executable does have -R.
|
|
|
|
|> In Linux, there is no distinction between run-time directory search
|
|
|> lists and compile-time directory search lists, except via LD_LIBRARY_PATH.
|
|
|> Linux uses SunOS 4.x's style library cache, plus an ldconfig which
|
|
|> does a symbolic link for you to the latest version of the shared library.
|
|
|> If you have programs compiled to use a previous version of the libarary,
|
|
|> you're stuck when you upgrade. (witness all the stuff about seyon
|
|
|> regularly breaking with each C library upgrade)
|
|
|
|
No Seyon had a bug in it. It is true to say linux is better at trapping bugs.
|
|
Our libraries are generally much more pedantic and you can not even get away
|
|
with misdemanour let alone murder (which you can with SunOS/Slowaris). The
|
|
aforementioned systems will generally let you dereference willy-nilly, close
|
|
file descriptors multiple times, free up non malloc(ated) space etc, etc...
|
|
|
|
|> If Linux did things in more of a Solaris style, then older programs
|
|
|
|
No we don't want to follow the path of evil :-)
|
|
|
|
|> would continue working (as long as the old shared libarary was kept
|
|
|> around). If you needed newer functionality or wanted to get rid
|
|
|
|
Hang on, I still have libc.so.2.2. I still keep around old binaries/libraries,
|
|
and they work just fine.
|
|
|
|
|> of the old library, simply recompile. (or you could even try your
|
|
|> luck and symlink the old library to the new if it was partially
|
|
|> incompatible)
|
|
|
|
The most significant difference with linux ld.so and Slowaris/SunDOS ld.so is
|
|
that ours does not really do dynamic linking. In linux's version we just find
|
|
the libraries, mmap `em and then perform some fixups. On the contrary the other
|
|
two systems do not have their shared libraries at fixed addresses, and thus
|
|
ld.so does "true dynamic linking" using dlopen(), dlsym() for each symbol in
|
|
the binary.
|
|
|
|
Mitch
|
|
|
|
------------------------------
|
|
|
|
From: lxp@proteon.com (Lawrence A. Palmer)
|
|
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
|
|
Date: Fri, 2 Sep 1994 18:06:10 GMT
|
|
|
|
In article <9408311222.AA04832@redbird.umsl.edu> matthew@redbird.umsl.edu
|
|
(Matthew Feldt) writes:
|
|
> I recently purchased a Western Digital 540mg hard drive on which I
|
|
installed
|
|
> Linux on to a partition of.
|
|
>
|
|
> Since I partitioned up the disk DOS doesn't care about the number of
|
|
cylinders
|
|
> but while installing Linux I kept getting the following warning:
|
|
> "The nuber of cylinders for this disk is set to 1048.
|
|
> This is larger than 1024 and may cause problems with some software."
|
|
|
|
The only problem with Linux and > 1024 sectors I've seen is that LILO
|
|
can't deal with partitions that start at a cylinder greater than 1023
|
|
(Actually a DOS restriction, I imagine). It doesn't matter how big
|
|
the partitions are, but it needs the first sector of each partition <
|
|
cyl 1023 to write the boot information. So put your small partitions
|
|
first and you should be OK.
|
|
|
|
------------------------------
|
|
|
|
From: stewart@oec.com (Stewart Allen)
|
|
Subject: Re: tcl/tk XF application?
|
|
Date: 1 Sep 1994 18:18:09 GMT
|
|
|
|
Simon Johnston (skj@oasis.icl.co.uk) wrote:
|
|
: Has anyone had any joy finding/using the XF interface builder for tcl/tk
|
|
: under Linux. If so could you let me know where it can be found and how to
|
|
: install.
|
|
|
|
harbor.ecn.purdue.edu
|
|
|
|
-- - Stewart Allen * stewart@oec.com * 617.562.5826 * FAX 617.562.0038 - --
|
|
M.I.S. Manager * Open Environment Corporation * 617.562.0900
|
|
25 Travis St * Boston, Ma * 02134
|
|
-- - -- - -- - -- "That's my story and I'm stickin' to it" -- - -- - -- - --
|
|
|
|
------------------------------
|
|
|
|
From: stewart@oec.com (Stewart Allen)
|
|
Subject: Mosaic and other TCP/IP problems
|
|
Date: 1 Sep 1994 19:32:01 GMT
|
|
|
|
|
|
I seem to be encountering difficulties with Linux's TCP/IP implementation.
|
|
In Mosaic (running on Linux 1.0.9, 1.0.0, 1.1.0, 1.1.38, etc) I have the
|
|
problem that image transfers > 5K break at 5632 Bytes always. They blitz
|
|
up to this point then begin crawling at about 1K every 3 seconds. We have
|
|
a T1 to the internet and the problem only occurs when moving from a fast
|
|
transport (10BT Ethernet @ 10Mbits) to a slower medium (T1 or SLIP). When
|
|
accessing the httpd server over straight ethernet, the problem does not
|
|
show up. My network cohorts claim that 5632 bytes = 1 machine page +
|
|
minimum TCP packet + TCP header and that there may be a problem with the
|
|
VJ conjestion control algorithms. Is this true or is the algorithm not
|
|
even implemented?
|
|
|
|
One other beef... the close() socket protocol is not implemented correctly.
|
|
Instead of negotiating the close of a socket, Linux just waits 60 secs.
|
|
and then closes the socket (/usr/src/linux/net/inet/tcp.h). For RPC servers
|
|
that spawn when called, this is ok; the residual process just hangs
|
|
around for an extra 60 seconds before going away. This can be seen on an
|
|
httpd server that is under heavy load. Every access to the httpd server
|
|
leaves a residual process for 60 secs. after completing the request. For
|
|
RPC servers that are necessarily single-threaded, however, Linux's hack is
|
|
not acceptable. The server must wait 1 minute before completing each
|
|
request and accepting the next. Is there a fix for this in the works?
|
|
|
|
|
|
-- - Stewart Allen * stewart@oec.com * 617.562.5826 * FAX 617.562.0038 - --
|
|
M.I.S. Manager * Open Environment Corporation * 617.562.0900
|
|
25 Travis St * Boston, Ma * 02134
|
|
-- - -- - -- - -- "That's my story and I'm stickin' to it" -- - -- - -- - --
|
|
|
|
------------------------------
|
|
|
|
From: niemidc@clark.net (login_menu)
|
|
Subject: Re: ext2fs floppy/82077 corruption with 1.1.49
|
|
Date: 2 Sep 1994 05:04:44 GMT
|
|
Reply-To: niemidc@clark.net
|
|
|
|
In article 2gr@huxley.anu.edu.au, gpg109@huxley.anu.edu.au (Gary Paul Gortmaker) writes:
|
|
> This may shed some more light on the floppy corruption reported
|
|
>earlier. This only seems to happen with the more advanced floppy controller
|
|
>(reported as a "post-1991 82077") and _not_ the standard 8272A based
|
|
>controllers. (The 82077 can be found on the more expensive SCSI cards
|
|
>such as the aha-154X, buslogic cards, AMI-FastDisk, etc.)
|
|
>
|
|
>This is guaranteed to demonstrate the problem on 82077 based systems.
|
|
>I have verified it on two systems with 82077 chips on cards from
|
|
>different manufacturers. I know it did so on 47 and 48, as well as 1.1.49,
|
|
>but can't vouch for how far it goes back. I sent this to the KERNEL
|
|
>channel, but I think the mail-server ate it. :-(
|
|
>
|
|
>1) mke2fs a floppy
|
|
>2) mount it and copy a big (~500k) file to it (or several files)
|
|
>3) unmount it but _don't_ eject it
|
|
>4) run "e2fsck -vrf /dev/fd0" --- it will come up clean (reading the cache)
|
|
>5) eject it and immediately stick it back in (set disk change flag)
|
|
>6) Repeat step 4 -- you will get most of the blocks in the above file(s)
|
|
> being marked as "not in use".
|
|
|
|
There is definitely something funny going on as of 1.1.49, you're right.
|
|
An even simpler test:
|
|
|
|
Stick an expendable formatted floppy in drive A:
|
|
dd if=/dev/zero count=2 of=/dev/fd0
|
|
mke2fs /dev/fd0
|
|
dd if=/dev/fd0 count=2 | od -a
|
|
|
|
You'll see that mke2fs did not actually write anything to the disk. Syncs,
|
|
etc. do not help; I think the problem is in the block caching in the kernel.
|
|
However, if you just "cp" or "dd" a file to a floppy device it works (probably
|
|
tar works too). The failure is not total; sometimes the above can be made to
|
|
work (e.g. playing around with the write protect tab). The problem seems not
|
|
to be at the very lowest levels of the floppy driver, but at some intermediate
|
|
level.
|
|
|
|
|
|
>Also, a notebook that now claims to have an 8272A (but printed the message
|
|
>"floppy: FIFO enabled" with the 1.1.3X kernels) also exhibits this
|
|
>corruption. The same notebook could not even use the floppy for
|
|
>kernels 1.1.42 --> 45 (the ones that used the faster 720k step rate)
|
|
|
|
The above FDC version numbers are quite odd. Is it possible to look
|
|
at the FDC's markings and see who's right, or ask the manufacturer?
|
|
|
|
3 msec is standard for 3.5" (and newer 5.25") floppy drives. The 4msec
|
|
is to allow a bit more latitude for slightly out of spec drives. The
|
|
older kernels (up to 1.1.40) used 6 msec, and on 82077s in double density
|
|
this actually came to 12 msec (very slow and noisy).
|
|
|
|
|
|
>I could not get the same sequence to produce the corruption with a
|
|
>standard 8272A based FDC.
|
|
>
|
|
>Perhaps we should have a way in which the 82077 can be used as a
|
|
>bog standard 8272A (like it was in kernels < 1.1.23) until all the
|
|
>enhanced FIFO features of the 82077 are sorted out.
|
|
...
|
|
Unfortunately, the 82077 cannot be made to behave *exactly* like an
|
|
8272A. Closer than it is now, yes. It might be worth having a handy
|
|
#define to cause the FIFO not to be turned on. However, it *WAS*
|
|
working earlier on quite a few systems; more debugging is needed on
|
|
both of these problems.
|
|
|
|
==============================================================
|
|
David C. Niemi niemidc@slma.com
|
|
Which is better -- the black or the white of the printed page?
|
|
==============================================================
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: kmh@linux.stevens-tech.edu (Kurt M. Hockenbury)
|
|
Subject: Re: DEC EtherWorks 3
|
|
Date: Thu, 1 Sep 1994 01:52:19 GMT
|
|
|
|
Alan Cox (iialan@iifeak.swan.ac.uk) wrote:
|
|
: In article <1994Aug22.034041.8611@dmi.stevens-tech.edu> kmh@linux.stevens-tech.edu (Kurt M. Hockenbury) writes:
|
|
: >Actually, someone from dec has a driver for freebsd for this card. (I've
|
|
: >included the post at the end of this message.) Perhaps someone in the linux
|
|
: >community could use it to develop a linux driver...
|
|
:
|
|
: Whats wrong with the current depca driver, this seems to cover the same
|
|
: cards (DEPCA, DE100, DE200 Turbo, DE201 Turbo, DE202 Turbo, DE210, DE422).
|
|
: The DE203,4,5 are apparently a different custom ASIC.
|
|
|
|
There's nothing wrong with the current depca driver (it's working fine
|
|
in several machines here). However, it doesn't support the Etherworks III
|
|
cards, of which we have a few kicking about. :-) The freebsd driver I posted
|
|
about aparently *does* support the DE203,4,5.
|
|
|
|
It's not much of an issue here, since we're moving towards 3c509s for
|
|
new machines, but I just thought someone interested in writing an
|
|
Etherworks III driver for linux might want to know about the existing
|
|
freebsd work.
|
|
-Kurt
|
|
|
|
------------------------------
|
|
|
|
From: middelin@iafnl.iaf.nl (Jeanette Pauline Middelink)
|
|
Subject: Re: SERIAL BUG! getty_ps/Linux 1.09/Rockwell modems
|
|
Date: 2 Sep 1994 08:30:08 GMT
|
|
|
|
: >Since the patch, i used getty_ps on the 2 lines of our UUCP backbone.
|
|
: >This site gets over 3400 calls a month, and is running for almost 6
|
|
: >months now... I would say 'my problem is solved :)'
|
|
: >
|
|
: Which version of the kernel are you running?
|
|
1.0.9 of the backbone (the one which get the calls) and 1.1.49 (or
|
|
whatever the highest maybe) on my own machine.
|
|
|
|
: The behavior of getty_ps when dialing-out/exiting/reinitting the modem changed
|
|
: (I believe) with the advent of the new serial drivers in 1.1.13?-18. After
|
|
: a uucico or cu exits, uugetty does not get triggered to re-init the modem
|
|
: reliably. For me, it does answer the phone and all that, but if a prior
|
|
: dial-out turned off ATS0=1, well, it's all over.
|
|
Ai, I try to avoid settings like that ATS0=1, because if the system
|
|
goes down for maintainance (backups -hihi) users who call don't get
|
|
an empty line. Also, when I callin occasionaly to check on the systems
|
|
and it answer I know at least getty is running.
|
|
|
|
: Something must be different when DTR toggles, but I can't even speculate
|
|
: what.
|
|
Your modem will reset itself, and the ATS0 setting will be defaulted.
|
|
|
|
OH! I placed the getty_ps patch in the Incoming dir of sunsite.unc.edu
|
|
i assume it will be placed in the same dir as getty_ps-2.0.7e
|
|
--> it is a patch against 2.0.7E!!!
|
|
so it will be FSSTND and so on... do not assume your setup
|
|
will work if you still have getty configs in /etc/default.
|
|
|
|
Groetjes,
|
|
Pauline
|
|
+------------------------------+---------------------------------------+
|
|
| Jeanette Pauline Middelink | email : middelin@calvin.iaf.nl |
|
|
| Roelof van Schevenstraat 37 | fidonet: Pauline Middelin (2:243/666) |
|
|
| 7521 SC, Enschede, (Holland) | voice : 053-309741 |
|
|
+------------------------------+---------------------------------------+
|
|
|
|
------------------------------
|
|
|
|
From: parprods@ecn.uoknor.edu (Dorwin Shields)
|
|
Subject: Mounting Sector-translated IDE drives
|
|
Date: 2 Sep 1994 14:55:31 GMT
|
|
|
|
I was wondering if any of the later kernels will mount sector translated
|
|
drives--I'm running Linux 1.1.44 and it will recognize the geometry-I'm
|
|
running with multiple mode on but it still gives me an error if I try to
|
|
mount the drive--When I load I run the Ontrack overlay--so it sets the
|
|
translation--then boot from a Linux floppy--I get the correct translated
|
|
drive parameters.
|
|
Is this a problem with the msdos filesystem?
|
|
Dorwin
|
|
|
|
------------------------------
|
|
|
|
From: phowlett@angus.ASG.unb.ca (Peter Howlett)
|
|
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
|
|
Subject: Re: SOCK_PACKET: Why not reading outgoing packets ?
|
|
Date: 2 Sep 1994 14:35:46 GMT
|
|
|
|
Alan Cox (iialan@iifeak.swan.ac.uk) wrote:
|
|
: In article <5VquJUE2-DB@gurke.allcon.com> morten@gurke.allcon.com (Morten Jammer) writes:
|
|
: >Why can the socket typ SOCK_PACKET only read outgoing packets
|
|
: >when the interface is in promiscious mode ?
|
|
|
|
: It can definitelyt read all incoming packets on all the cards I use
|
|
: (barring etherexpress) otherwise tcpdump wouldnt work. Outgoing packet
|
|
: viewing is very recent but now works.
|
|
|
|
: Alan
|
|
|
|
Is it possible for me to get more information on how to use this
|
|
type of socket? (Can it be used to implement user level routing
|
|
protocols or packet filters?)
|
|
|
|
====================================================================
|
|
Peter Howlett Atlantic Systems Group
|
|
E-Mail: phowlett@ASG.unb.ca Fredericton, N.B. Canada
|
|
|
|
------------------------------
|
|
|
|
From: mah@ka4ybr.com (Mark A. Horton KA4YBR)
|
|
Subject: Re: PRIORITY make an undelete command
|
|
Date: Thu, 1 Sep 1994 01:37:39 GMT
|
|
|
|
John Henders (jhenders@jonh.wimsey.com) wrote:
|
|
: In <CvBGFz.4M0@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
|
|
|
|
: >Did you never erase a file later on the day that you first created it?
|
|
: >Or foul it up during some edit session, making you wish that you could
|
|
: >get back a version like it was 3 or 4 edit-sessions ago?
|
|
|
|
: Isn't that what rcs is for?
|
|
|
|
BRAVO!
|
|
|
|
Yes, John... too bad most of the people screaming for an undelete function
|
|
have never worked in a real software development environment that used rcs or sccs
|
|
or some other package for revision control. And before the flames start about
|
|
uncessary complexity and being "too difficult to deal with," I say bull! If set
|
|
up properly, a revision control system is almost invisible to the end user (the
|
|
programmer in this case!) One should learn and explore the tools at hand before
|
|
screaming for others "just like they're used to".... One has to wonder if these same
|
|
people still use edlin under DOS or have taken the bold steps necessary to master
|
|
the newer "edit" editor!
|
|
|
|
- Mark
|
|
--
|
|
"Linux! Guerrilla UNIX Development Venimus, Vidimus, Dolavimus."
|
|
============================================================
|
|
Mark A. Horton ka4ybr mah@ka4ybr.atl.ga.us
|
|
P.O. Box 747 Decatur GA US 30031-0747 mah@ka4ybr.com
|
|
+1.404.371.0291 33 45 31 N / 084 16 59 W
|
|
|
|
------------------------------
|
|
|
|
From: mike@wavelet.apl.washington.edu (Mike Kenney)
|
|
Subject: Re: Future of linux -- the sequel
|
|
Date: 2 Sep 1994 05:36:18 GMT
|
|
|
|
In article <3456g5$1ekr@yuma.acns.colostate.edu>,
|
|
Larry Pyeatt <pyeatt@CS.ColoState.EDU> wrote:
|
|
>
|
|
>Compare the price/performance of processors and Intel comes out to
|
|
>make the worst processors in existence. PowerPC chips provide twice
|
|
|
|
I have to disagree here. The price/performance of a Pentium PC is
|
|
quite good (especially if you're running Linux :-). I've done a lot
|
|
of shopping around in the workstation market and have run quite a
|
|
few benchmarks on various systems ... the Pentium scores quite well.
|
|
IMHO it's a much better deal than any of the low-end (< $20k) workstations
|
|
out there right now. It's still a bit of a dog when it comes to fp
|
|
performance but you don't see serious MFLOPs in the workstation world
|
|
until you spend > $40k.
|
|
|
|
One of the most important benefits is vendor independence, I can buy
|
|
spare/replacement parts from anyone ... no need to purchase a
|
|
maintenance contract. This was the big selling point for us, at one
|
|
time our research group was paying $35k/year in maintenance on 4
|
|
minicomputers.
|
|
|
|
--
|
|
Mike Kenney
|
|
mikek@apl.washington.edu
|
|
|
|
------------------------------
|
|
|
|
From: yohgaki@du.edu (Yasuo Ohgaki)
|
|
Subject: Re: MATROX PCI Graphics board supported ??
|
|
Date: Fri, 2 Sep 1994 13:40:15 GMT
|
|
|
|
|
|
Take a look at Xinside's ftp.
|
|
|
|
ftp.xinside.com
|
|
|
|
They have xserver for Linux, too.
|
|
Pretty impressive spec.
|
|
|
|
BTW, it's NOT FREE
|
|
|
|
|
|
--
|
|
Yasuo Ohgaki
|
|
yohgaki@mercury.cair.du.edu
|
|
yohgaki@cassandra.cair.du.edu
|
|
Tel/FAX (303)751-4193 Data (303)751-4263
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|