538 lines
20 KiB
Plaintext
538 lines
20 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: Sun, 9 Oct 94 20:13:06 EDT
|
||
Subject: Linux-Development Digest #284
|
||
|
||
Linux-Development Digest #284, Volume #2 Sun, 9 Oct 94 20:13:06 EDT
|
||
|
||
Contents:
|
||
Re: Hardware PROBLEM HELP! (Steven M. Doyle)
|
||
Re: ext2fs vs. Berkeley FFS (Albert D. Cahalan)
|
||
[fixed] lmail problem with sendmail (Tim Bass (Network Systems Engineer))
|
||
Re: Improving SLIP latency under Linux (Al Longyear)
|
||
Re: umount problem! (Steven Pritchard)
|
||
Re: [fixed] lmail problem with sendmail (Arnt Gulbrandsen)
|
||
Serious Bug In The Networking Code (Ketil Z Malde)
|
||
Re: linux-activists@Niksula.hut.fi (Mark Hahn)
|
||
Re: NCR53c810 card and Technoland (Michael J. Ashmore)
|
||
Re: What GUI to write for? (Terry Lambert)
|
||
Re: Adaptec 2940 Support? (Robert R. Richter)
|
||
Re: Telnet & ftp freeze! (System Administrator)
|
||
Re: Text modes? (Stormy Henderson)
|
||
|
||
----------------------------------------------------------------------------
|
||
|
||
From: wcreator@kaiwan.com (Steven M. Doyle)
|
||
Subject: Re: Hardware PROBLEM HELP!
|
||
Date: 8 Oct 1994 02:55:17 -0700
|
||
|
||
In <3756gt$fn3@senior.nectec.or.th> wintera@morakot.nectec.or.th (Axel Winter) writes:
|
||
|
||
|
||
>I really have a problem with my hardware ... If I touch
|
||
>any place of the system or a conected part (priter, termial)
|
||
>at a place where is steel, i get a eletric shock. Next to that
|
||
|
||
You might want to make sure that your power outlets are all earth-groudned.
|
||
This is commonly not the case in many homes in the US, at least, (mostly
|
||
older homes), and could conceivably cause that condition.
|
||
|
||
--
|
||
| Steven Doyle, AKA World Creator | #include <std_disclaimer> |
|
||
| Sysop, NETDimension (818)592-6279 | For information on Artificial Worlds |
|
||
| wcreator@kaiwan.com | send email to wcreator@kaiwan.com for |
|
||
| wcreator@axposf.pa.dec.com | an information package. |
|
||
|
||
------------------------------
|
||
|
||
From: adc@bach.coe.neu.edu (Albert D. Cahalan)
|
||
Subject: Re: ext2fs vs. Berkeley FFS
|
||
Date: 09 Oct 1994 18:41:48 GMT
|
||
|
||
In article <CHRISB.94Oct9163052@hawk.cssc-syd.tansu.com.au> chrisb@hawk.cssc-syd.tansu.com.au (Chris Bitmead) writes:
|
||
>I think it's important to keep in perspective that performance
|
||
>is only one aspect of the equation. It may be reasonable to
|
||
>compare ext2fs to FFS on this basis, but FFS dates from about
|
||
>(I think) 4.1 or 4.2 BSD. I think the issue today is flexibility
|
||
>as much as it is performance.
|
||
>
|
||
>Ext2fs supports a limited set of extended attributes (append, immutable,
|
||
>secure delete, uneraseable, synchronous) and the sources indicate
|
||
>that ACLs will be available in the future. But these are all
|
||
>kernel space extensions. You can't associate some arbitrary piece
|
||
>of data (that stays with the file when copied) with the file without
|
||
>writing it in the data stream somewhere. By contrast, HPFS allows
|
||
>up to 64K of extended attributes per file. NTFS goes the full
|
||
>distance by allowing multiple arbitrary streams per file, although
|
||
>there doesn't seem to be any documentation on how to exploit this
|
||
>in the Win32 API manual.
|
||
>
|
||
>I know this doesn't sound very UNIXy, but how difficult would
|
||
>it be to implement a filesystem with some sort of arbitrary
|
||
>extended attributes like those in NTFS or the more limited ones
|
||
>in HPFS?
|
||
|
||
Not very hard to do, but why clutter up the operating system with more
|
||
features, when directories will do exactly what you want?
|
||
|
||
You would not be able to distinguish the special directories from other ones.
|
||
|
||
I think 3 or 4 bits could be spared for extended attributes like this:
|
||
|
||
0 flat file (default)
|
||
1 NEW record file
|
||
2 Mac file
|
||
3 NT file
|
||
4 OS/2 file
|
||
5 DOS executable
|
||
6 Windows executable
|
||
7 etc.
|
||
|
||
Decide how (and if) the standard calls will open the new file types, then add the
|
||
required new calls.
|
||
|
||
Want to reduce OS clutter? Take executable formats and library support out of
|
||
the kernel.
|
||
--
|
||
|
||
Albert Cahalan
|
||
adc@meceng.coe.neu.edu
|
||
|
||
------------------------------
|
||
|
||
From: bass@cais.cais.com (Tim Bass (Network Systems Engineer))
|
||
Subject: [fixed] lmail problem with sendmail
|
||
Date: 9 Oct 1994 17:01:02 GMT
|
||
|
||
[ Article crossposted from comp.os.linux.admin ]
|
||
[ Author was Tim Bass (Network Systems Engineer) ]
|
||
[ Posted on 9 Oct 1994 16:59:55 GMT ]
|
||
|
||
|
||
This really surprises me.....
|
||
|
||
I pulled down the sendmail + IDA package from tsx-11.mit.edu (forget the
|
||
exact name of the file, sorry - can get it if anyone cares) and found
|
||
that the lmail binary had trouble writing to the /tmp file.
|
||
|
||
Looking at the src for lmail.c the code contains the line(s):
|
||
|
||
if (fputs (line,fp) != strlen (line)) { ... }
|
||
|
||
in the source.
|
||
|
||
Doing some detective work yielded that fact that fputs() was always 1 and
|
||
never equaled strlen() even though the write was okay.
|
||
|
||
I changed the line to read:
|
||
|
||
if (fputs (line,fp) < 0) { ... }
|
||
|
||
|
||
and all was okay. Is fputs() okay?
|
||
|
||
Anyway, knowing the problem is 99 percent of the solution and sendmail
|
||
is working on linux, delivering to the local users just fine.
|
||
|
||
------------------------------
|
||
|
||
From: longyear@netcom.com (Al Longyear)
|
||
Subject: Re: Improving SLIP latency under Linux
|
||
Date: Sun, 9 Oct 1994 18:15:36 GMT
|
||
|
||
rob@pe1chl.ampr.org (Rob Janssen) writes:
|
||
|
||
>>The best solution is to simply choose the priority when you do the
|
||
>>transmission and then send it in that order.
|
||
|
||
>That only helps when there are as little buffers as possible between the
|
||
>point where this decision is made and the line.
|
||
>Although the buffers in the modems are a problem, I don't think they are
|
||
>the full explanation of 6 second roundtriptimes when an FTP is running.
|
||
>Probably some frames get queued up in the kernel "waiting to be sent on
|
||
>the serial line". That is not good...
|
||
|
||
Rob,
|
||
|
||
New frames are merged into the list of frames bound for the SLIP/PPP/
|
||
PLIP link in order based upon their priority. Each new frame is
|
||
inserted into the list in sequence. They are not simply tacked on to
|
||
the end of the list.
|
||
|
||
So, yes, it is a very good solution to implement and use the
|
||
IP_TOS. All higher priority frames will be sent before lower priority
|
||
frames are sent.
|
||
|
||
For this to work the best, you need to implement IP_TOS on both sides
|
||
of the link. If you are doing an ftp transfer to read a large file,
|
||
then it the remote side (the one running ftpd) which is doing the
|
||
majority of the transmission. Their frames need to have a background
|
||
(7) priority. The wu-ftpd process has had this implemented for some
|
||
time. Unfortunately, not all implementations of TCP/IP support this
|
||
logic. The BSD 4.3 code did not. I believe that it is in place for
|
||
the BSD 4.4 code.
|
||
|
||
There have been kludges to support the queueing in the PPP or SLIP
|
||
drivers. They look at the port numbers being used and determine a
|
||
"priority" based upon the list of known interactive ports. THIS IS A
|
||
KLUDGE. It is only because the TCP/IP software did not allow the
|
||
application to specify the proper value.
|
||
|
||
(Morningstar PPP/SLIP and the BSD pppd package are two that I am
|
||
familiar with doing this kludge.)
|
||
|
||
>Peeking in the TCP headers inside the IP routing code (checking for port
|
||
>numbers, so that 20 and 25 can get a lower priority than 23 even when the
|
||
>TOS is the same) seems to be the best solution... (although dirty)
|
||
|
||
Why bother? It is done in all of the daemons and client code now in
|
||
place for Linux.
|
||
|
||
The default priority is TOS_THROUGHPUT (0x08). Most of the sockets
|
||
will generate IP frames of this priority. I suppose that you could do
|
||
it for those frames. It would imply that the priority was not
|
||
specified. However, if the value was specified then I think that you
|
||
should leave it alone.
|
||
|
||
However, as the saying goes, "the proof is in the pudding". Please
|
||
feel free to make the changes that you see fit to your copy of the
|
||
kernel and try it out. I would be interested in hearing about your
|
||
results.
|
||
|
||
I do ask one favor (or condition if you wish). That is that you use
|
||
the current kernel 1.1.52+ and the latest versions of all of the
|
||
networking software. (If you use my favorite ftp client, ncftp, then
|
||
you need a fairly new one which supports the IP_TOS socket option.)
|
||
|
||
>In fact I think the "always use a big window because that performs so
|
||
>nicely on fast links" may be not optimal. One could argue that the optimum
|
||
>window size for a TCP is such that it can just keep sending (i.e. an
|
||
>ACK comes back just when the sending TCP runs out of send window), and
|
||
>not much larger than that. The sending TCP could adapt its send window
|
||
>accordingly (staying below the negotiated window size).
|
||
|
||
That is the slow start algorithm presently in place.
|
||
|
||
--
|
||
Al Longyear longyear@netcom.com
|
||
|
||
------------------------------
|
||
|
||
From: spritcha@nyx10.cs.du.edu (Steven Pritchard)
|
||
Subject: Re: umount problem!
|
||
Date: 4 Oct 1994 00:56:31 -0600
|
||
|
||
Similar story: I was trying to umount a DOS floppy after doing a couple
|
||
of writes to it and got this (kernel 1.1.51):
|
||
|
||
Oct 3 14:49:18 Osiris kernel: Oops: 0000
|
||
Oct 3 14:49:18 Osiris kernel: EIP: 0010:00166130
|
||
Oct 3 14:49:18 Osiris kernel: EFLAGS: 00010246
|
||
Oct 3 14:49:18 Osiris kernel: eax: 00160000 ebx: 00000000
|
||
ecx: 00000000 edx: 00160000
|
||
Oct 3 14:49:18 Osiris kernel: esi: 0030ded4 edi: 0030ded4
|
||
ebp: 00000000 esp: 0030dea8
|
||
Oct 3 14:49:18 Osiris kernel: ds: 0018 es: 0018 fs: 002b
|
||
gs: 002b ss: 0018
|
||
Oct 3 14:49:18 Osiris kernel: Process umount (pid: 1862, process
|
||
nr: 20, stackpage=0030d000)
|
||
Oct 3 14:49:18 Osiris kernel: Stack: 001b0200 001b0002 00126193
|
||
0030ded4 00000000
|
||
Oct 3 14:49:18 Osiris kernel: Code: f6 01 02 74 0d 0f b7 46 10 50
|
||
e8 bd be fb ff 83 c4 04 be d8
|
||
|
||
Which appears to come from _floppy_release (if I understand this
|
||
properly). Here's the ouput from 'nm /usr/src/linux/tools/zSystem|egrep
|
||
"1661"':
|
||
|
||
001661dc t _floppy_open
|
||
0016610c t _floppy_release
|
||
|
||
Everything seemed to get written to the floppy properly, so I guess it is
|
||
no big deal. Curious to know if this can be prevented in the future though.
|
||
|
||
For future information: just where should this sort of thing be reported?
|
||
|
||
Steve
|
||
--
|
||
spritcha@nyx10.cs.du.edu | Southern Illinois Linux Users Group
|
||
(618)549-8579 | Meetings the 1st and 3rd Mondays of every month.
|
||
Steven Pritchard | http://nyx10.cs.du.edu:8001/~spritcha/home.html
|
||
|
||
|
||
------------------------------
|
||
|
||
From: agulbra@nvg.unit.no (Arnt Gulbrandsen)
|
||
Subject: Re: [fixed] lmail problem with sendmail
|
||
Date: 9 Oct 1994 17:52:35 GMT
|
||
|
||
In article <3797ke$ktn@news.cais.com>,
|
||
Tim Bass (Network Systems Engineer) <bass@cais.cais.com> wrote:
|
||
>Looking at the src for lmail.c the code contains the line(s):
|
||
>
|
||
>if (fputs (line,fp) != strlen (line)) { ... }
|
||
>
|
||
>in the source.
|
||
>
|
||
>Doing some detective work yielded that fact that fputs() was always 1 and
|
||
>never equaled strlen() even though the write was okay.
|
||
|
||
This bug was reported a long time ago, a year perhaps. Perhaps you
|
||
could upload a fixed version?
|
||
|
||
The problem is really that the successful return value of fputs() and
|
||
puts() isn't specified. The man pages I have say it should return
|
||
EOF and -1 (EOF is, I hope, -1) on error, but don't say anything
|
||
about success.
|
||
|
||
--Arnt
|
||
|
||
|
||
------------------------------
|
||
|
||
From: ketil@ii.uib.no (Ketil Z Malde)
|
||
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
|
||
Subject: Serious Bug In The Networking Code
|
||
Date: 9 Oct 1994 18:33:07 GMT
|
||
Reply-To: ketil@ii.uib.no
|
||
|
||
|
||
There appears to be a serious bug in some of the networking code
|
||
supplied with linux/slackware, that causes the computer to get
|
||
'network unreachable' after approximately 3 minutes of perfect
|
||
functioning. I have no idea what the problem might be, and if
|
||
somebody tell me where to look, I can try to figure out what versions
|
||
my drivers etc. are. Here are the configurations I ve gotten this
|
||
problem with:
|
||
|
||
AMD DX2/66, 8Mb, VLB CL5428 1Mb with either
|
||
* Etherlink II, kernel 1.1.50 and 1.1.49
|
||
* SMC Ultra Combo, kernel 1.1.33, 1.1.49, 1.1.50
|
||
-tried both coax and TP
|
||
* SMC Ultra something else, also with various kernels
|
||
|
||
AMD 386/40, 12Mb,
|
||
* SMC Ultra Combo, kernel 1.1.33
|
||
|
||
The 386 works perfectly well with the network with both cards when
|
||
using older software (Some old SLS distrib. I believe)
|
||
|
||
I would very much like to know what is wrong, and how to fix it.
|
||
|
||
There is also a 'bug' in df, causing a float exception when it cannot
|
||
access a non-existent NFS-mount.
|
||
|
||
Thanks for any help,
|
||
--
|
||
|
||
<20> Ketil Malde In real life: ketil@ii.uib.no <20>
|
||
<20> Nuke The Whales! Pave The Earth! And Honk If You Love Unicorns! <20>
|
||
|
||
------------------------------
|
||
|
||
From: hahn@neurocog.lrdc.pitt.edu (Mark Hahn)
|
||
Subject: Re: linux-activists@Niksula.hut.fi
|
||
Date: 4 Oct 1994 07:06:25 GMT
|
||
|
||
> But unfortunately you can't specify the address yourself. It blindly
|
||
> takes the address it finds in the From: line. This loses badly when your
|
||
> address has changed, or the translation of the From: address which happens
|
||
> in the mail routers has changed.
|
||
|
||
> I have experienced already two times that the only way to unsubscribe was
|
||
> to write a message to the operator :-(
|
||
|
||
some sendmails have a -f switch for forging From: lines,
|
||
and you can always do it by hand by telnetting to their smtp port.
|
||
|
||
regards, mark hahn.
|
||
--
|
||
operator may differ from spokesperson. hahn@neurocog.lrdc.pitt.edu
|
||
|
||
------------------------------
|
||
|
||
From: mja9@po.CWRU.Edu (Michael J. Ashmore)
|
||
Subject: Re: NCR53c810 card and Technoland
|
||
Date: 9 Oct 1994 18:25:19 GMT
|
||
Reply-To: mja9@po.CWRU.Edu (Michael J. Ashmore)
|
||
|
||
|
||
In a previous article, haid0002@gold.tc.umn.edu (Stavros J Haidos) says:
|
||
|
||
> In the scsi-howto it states that you can get a NCR56c810 card that will work
|
||
>on the pci bus. When I called up the number given for Technoland they told me
|
||
>that the card will only work on one type of pci mother board and that it will
|
||
>not work on a 90 mhz 586 mother board. Is this true? Is there any way I can
|
||
>get a board like this to work on a P90 and under linux? Please help. Thanks!
|
||
>
|
||
>--
|
||
> -Steve
|
||
>
|
||
Well, I'm running a Zenon P90, and I have a NCR53c810-based PCI card
|
||
working just fine ... it seems to be a generic card; the only dox Zenon
|
||
gave me was a techsheet (1 page, front only) identifying the chip and
|
||
giving some basic info on termination :(
|
||
Though the sheet is called "Quick Reference guide for PCI-SC200" -- there
|
||
doesn't seem to be a brand attached.
|
||
|
||
Incidentally, I'm trying to set up Linux here, using the Slackware release,
|
||
but can't seem to get any of the updated kernels to compile completely --
|
||
using 1.1.50, config, dep, and clean all compile nicely, but zlilo just
|
||
hangs -- or at least I'm *assuming* it's hung; it stayed on "main.c" for
|
||
over 15 minutes... not normal on a Pentium :/
|
||
Without an updated lilo, I can't boot from my SCSI drive -- major
|
||
annoyance.
|
||
|
||
-Mashmore
|
||
|
||
------------------------------
|
||
|
||
From: terry@cs.weber.edu (Terry Lambert)
|
||
Crossposted-To: comp.windows.x.intrinsics,gnu.misc.discuss
|
||
Subject: Re: What GUI to write for?
|
||
Date: 9 Oct 1994 22:35:11 GMT
|
||
|
||
In article <373lan$1ij@due.uninett.no> torgeir@eik.ii.uib.no (Torgeir Veimo) writes:
|
||
] |> 5) There's the window manager. Nobody but OSF has one of these.
|
||
]
|
||
] I can't quite agree on this, since I use fvwm every day. It has motif style
|
||
] decorations, and to my knowledge does it also understand the motif api
|
||
] decoration and menu function hints. And if there is something wrong, you
|
||
] could allways hack the code....
|
||
|
||
Can you set the config information in the correct Motif compliant config
|
||
files and have it behave like mwm would? Nope.
|
||
|
||
Also, there's a problem with it killing clients when you click the heck out
|
||
of the mouse (nettrek, etc.).
|
||
|
||
All in all, I use it because I have a thing against licensing Motif, but
|
||
I knew mwm, and fvwm's no mwm. 8-).
|
||
|
||
|
||
Terry Lambert
|
||
terry@cs.weber.edu
|
||
---
|
||
Any opinions in this posting are my own and not those of my present
|
||
or previous employers.
|
||
|
||
------------------------------
|
||
|
||
From: draxx@draxx.co.netz.sub.de (Robert R. Richter)
|
||
Subject: Re: Adaptec 2940 Support?
|
||
Date: Sun, 9 Oct 1994 11:43:35 GMT
|
||
|
||
Michael_Nelson (nelson@seahunt.imat.com) wrote:
|
||
: I've got my roommate convinced to switch over to Linux from Unixware. He's
|
||
: running a Mylex P5/66 EISA/PCI motherboard and is using an Adaptec AHA-2940
|
||
: PCI/SCSI card. I can't find any evidence that the 2940 is yet supported by
|
||
: Linux, though. Is anyone working on a driver or kernel patch to support
|
||
: this host adapter?
|
||
|
||
Hi Michael !!
|
||
|
||
I have a 2940, too !! :-)
|
||
|
||
And no device-driver :-( !!
|
||
|
||
If you get any response, please mail to me !!
|
||
|
||
THANX,
|
||
Robert.
|
||
|
||
|
||
--
|
||
DRAXX-Online-Systems | DRAXX (Robert R. Richter)
|
||
------------------------------ | E-Mail 1 : draxx@draxx.co.netz.sub.de
|
||
+49 9562 7986 (RING-DOWN) | E-Mail 2 : robi@aralon.co.netz.sub.de
|
||
============================== | CompuServe : 100341.3572@compuserve.com
|
||
|
||
------------------------------
|
||
|
||
From: root@jaguar.tigerden.com (System Administrator)
|
||
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
|
||
Subject: Re: Telnet & ftp freeze!
|
||
Date: 7 Oct 1994 21:14:06 GMT
|
||
|
||
Peter H. Lemieux (phl@cyways.com) wrote:
|
||
: In article <3728nr$eb0@news.halcyon.com>, ralphs@halcyon.halcyon.com (Ralph Sims) says:
|
||
: >
|
||
: >Other things that run are Sendmail+IDA as a daemon, xntpd, and
|
||
: >CERN's web server. The ftp session definitely takes over the system.
|
||
: >
|
||
|
||
: Remember that FTP is running two simultaneous sessions with the other host,
|
||
: a data channel and a control channel. With only a standard two-wire modem,
|
||
: the line must be repeatedly turned around from TX to RX and back again.
|
||
: (Four wire, dedicated-line modems are pricey.) Services like news and
|
||
: the web have little upstream traffic, mostly downstream, since they
|
||
: have no control channel.
|
||
|
||
Pardon, but I don't think this is correct. Most 2 wire modems multiplex
|
||
the bandwidth and *do* allow simultaneous bi-directional data flow. You
|
||
may be thinking of some data protocols that require packets to be
|
||
acknowledged by the receiving end before sending additonal ones, but this
|
||
has nothing really to do with what is flowing on the line itself. I
|
||
haven't seen real 'line-turn around' modems since dealing with some
|
||
ancient Burroughs stuff nearly 20 years ago. And even then the more
|
||
common 300 bps 2 wire modems *most* people were using were bi-directional,
|
||
using 4 tones, 1 pair to code 1's and 0's going one way, and the other
|
||
pair for data going the other.
|
||
|
||
George Nemeyer (root@tigerden.com)
|
||
System Administrator
|
||
Tigerden.com
|
||
|
||
------------------------------
|
||
|
||
From: Stormy@Purple.Madness (Stormy Henderson)
|
||
Subject: Re: Text modes?
|
||
Date: 9 Oct 1994 21:39:22 GMT
|
||
Reply-To: Stormy@Grand.Mother.Com
|
||
|
||
Matt Hudson wrote:
|
||
|
||
I don't know if anybody is willing to do work on this or not... or if
|
||
enough people are even interested.
|
||
|
||
I found a kernel patch that adds four new text modes to any vga card, I've
|
||
installed it and it works perfectly for me. With my new font size, I can
|
||
delete X cause I don't need it anymore. (c:
|
||
|
||
The added sizes are 80x30, 80x36 (the one I'm using), 80x40, 80x44
|
||
|
||
I'm going to ftp the patch to sunsite incoming as textmodes.gz if anyone is
|
||
interested in trying it.
|
||
|
||
Be happy...
|
||
|
||
|
||
- Stormy the happinator "The Moving Finger writes; and, having writ
|
||
Moves on: nor all your Piety nor Wit
|
||
Reply to: Shall lure it back to cancel half a line,
|
||
Stormy@Grand.Mother.Com Nor all your Tears wash out a Word of it."
|
||
|
||
|
||
------------------------------
|
||
|
||
|
||
** 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
|
||
******************************
|