Linux-Development-Sys Digest #623, Volume #6 Wed, 14 Apr 99 05:14:05 EDT
Contents:
Re: a problem with scanf (Francesc Oller)
Difference between vanilla and ac (Dieter Kraft)
Re: Win32 support in Linux (Mircea)
Re: SMP Linux, Any Catches? ("Clint Byrum")
Re: Difference between vanilla and ac (Robert Schiele)
Re: Win32 support in Linux ([EMAIL PROTECTED])
Re: asynchronous disk I/O (Phil Howard)
Re: Difference between vanilla and ac (Horst von Brand)
Re: Large pages (Peter Samuelson)
UPDATE: K6-3 / Celeron 400A Linux kernel compilation benchmark
([EMAIL PROTECTED])
Re: PCI DMA to user space possible? (Robert Kaiser)
Re: Win32 support in Linux (Suchandra Thapa)
Large pages (David Nilsen)
Re: Problems with ARP on 2.2.X (contd.) (Lenar Lohmus)
Re: Large pages (Alexander Viro)
Re: Win32 support in Linux ([EMAIL PROTECTED])
Re: Difference between vanilla and ac (Peter Samuelson)
Re: Difference between vanilla and ac (Stefaan A Eeckels)
Re: The Mindset Trap (Christopher Browne)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Enkidu)
----------------------------------------------------------------------------
From: Francesc Oller <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: a problem with scanf
Date: Tue, 13 Apr 1999 21:31:59 +0200
Reply-To: [EMAIL PROTECTED]
Steve Summit wrote:
>
> This may indicate a slight bug in the GNU/Linux libc, although
> the workaround is exquisitely simple in this case: just use
> getchar, which is what you probably wanted to use all along.
> (In general, scanf %c is a lousy substitute for getchar.)
>
> Steve Summit
> [EMAIL PROTECTED]
Latest news!
The two examples I posted expose bugs of libc5. In libc6 (a Debian box)
and other Unixes work well.
Regards
Francesc Oller
------------------------------
From: Dieter Kraft <[EMAIL PROTECTED]>
Subject: Difference between vanilla and ac
Date: Tue, 13 Apr 1999 23:16:50 +0200
Hi,
can the difference in vanilla and ac (Alan Cox, I suppose)
be explained in short?
Thanks
Dieter
--
_________________________________________________________________
Dieter Kraft Phone 0049 89 1265 1177
Fachhochschule M�nchen Fax 0049 89 1265 1100
Dachauerstrasse 98b Email [EMAIL PROTECTED]
D-80335 M�nchen http://www.fm.fh-muenchen.de:8080/~dkraft
------------------------------
From: Mircea <[EMAIL PROTECTED]>
Subject: Re: Win32 support in Linux
Date: Tue, 13 Apr 1999 17:13:29 -0400
vfat for "fat32"
MST
[EMAIL PROTECTED] wrote:
> So, what fs specifyer do I use for
> 'mount'? 'fat32'? I would guess so, but if anyone knows the specifics,
> let me know.
------------------------------
From: "Clint Byrum" <[EMAIL PROTECTED]>
Subject: Re: SMP Linux, Any Catches?
Date: Tue, 13 Apr 1999 15:00:56 -0700
Where can i get the 2.2.x kernel? I haven't updated the kernel outright
since I upgraded my 2.0.16 kernel to 2.0.22. As far as 14 processors go, I
don't think I'd want all the eggs in one basket like that. I'd rather use
beowulf and do clustered processing... More fault tolerant.
------------------------------
From: Robert Schiele <[EMAIL PROTECTED]>
Subject: Re: Difference between vanilla and ac
Date: Wed, 14 Apr 1999 00:01:09 +0200
Dieter Kraft wrote:
>
> Hi,
> can the difference in vanilla and ac (Alan Cox, I suppose)
> be explained in short?
> Thanks
> Dieter
>
This is just how Alan names its directories. linux.vanilla is always the
official version from Linus, linux.ac is his patched version. There is
nothing more about it.
Robert
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Win32 support in Linux
Date: Tue, 13 Apr 1999 10:58:41 GMT
On 13 Apr 1999 11:44:42 +0200, Harald Arnesen <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] writes:
>
>> My question is simple. Does Linux have win32 support? I had read in
>> the 2.2.0 docs on linux.org that it would be, but when I installed it,
>> I could not see anything indicating that it did. I don't want to
>> win32alize my hd without first knowing that I can still access it from
>> linux. Thanks.
>
>Depends on what you mean. If you just want to access a FAT-32
>partition, no problem. They can be mounted, just as partitions with
>the native ext2 filesystem.
>
>If you mean running 32-bit Windows applications, the answer is a
>qualified no - but see www.winehq.org and www.vmware.com.
>--
>Harald Arnesen, Apall�kkveien 23 A, N-0956 Oslo, Norway
Well of cource not. I am not that uneducated. I just did not see
support for it in the kernel config, that's all. Also, now I can't get
fdisk running under windows or dos mode ( went ahead and did the fat32
conversion, but it didn't work even before that...), and Win98
detected that it was not the booting partition, and changed that. Now
I can't boot from lilo, so I have to go in and find my linux rescue
disks from among all my stuff. So, what fs specifyer do I use for
'mount'? 'fat32'? I would guess so, but if anyone knows the specifics,
let me know.
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: asynchronous disk I/O
Date: Tue, 13 Apr 1999 11:17:26 GMT
On Tue, 13 Apr 1999 02:16:03 GMT [EMAIL PROTECTED] wrote:
| Can anyone confirm that Linux does not support asynchronous disk I/O? On AIX
| and Digital Unix we have system calls like lio_listio(), but I cannot find
| anything similar to that.
Linux automatically does asyncronous disk I/O to a great extent. For writes,
the data is "written" to buffer space, and later actually written to disk.
There appears to be some read-ahead taking place as well.
If you want non-blocking I/O on disk, which has uses when you open files with
the O_SYNC option to interleave the I/O with other I/O, then what you will
need to do is fork each I/O to a child process and let it do the syncronous
I/O, and the master process does non-blocking I/O via the pipes. Using a
shared buffer and writing messages over the pipe that point to where in the
buffer that the data is, would reduce the overhead. The facilities of other
systems could very well be a library that does this for you.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Horst von Brand)
Subject: Re: Difference between vanilla and ac
Date: 14 Apr 1999 00:40:14 GMT
In article <[EMAIL PROTECTED]>, Dieter Kraft wrote:
>can the difference in vanilla and ac (Alan Cox, I suppose)
>be explained in short?
It's vanilla + a set of experimental patches Alan has collated. He usually
posts a short notice on the differences between vanilla and -acX whenever he
releases it to [EMAIL PROTECTED]
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vi�a del Mar, Chile +56 32 672616
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Large pages
Date: 14 Apr 1999 00:48:50 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[David Nilsen <[EMAIL PROTECTED]>]
> I know the Pentium family of CPUs has support for 4mb pages, and did
> some Web searches to see if such a feature is in Linux, but my search
> was inconclusive.
> Does anyone know if such a feature exists? If so, can you enable it on
> a per-process basis?
At one point Intel was sagely publishing information on 4MB pages only
in the famous Appendix H, which was distributed under NDA. Some
enterprising Pentium hacker noticed, however, that the Intel i860 has
exactly the same feature implemented almost the same way (and publicly
documented), and effectively reverse-engineered that part of Appendix
H. Intel apparently changed their minds at some point, since my PPro
manuals (Jan 1996) have the info. In any case, AFAIK, Linux doesn't
use the feature at present.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.os.linux.advocacy
Subject: UPDATE: K6-3 / Celeron 400A Linux kernel compilation benchmark
Date: Wed, 14 Apr 1999 06:04:26 GMT
I've posted a major update to my "Linux kernel compilation benchmark";
adding K6-3 400 and Celeron 400A results, a chart of the results along with
more discussion of the results and a general re-organization / partial
re-write of the article. There are 52 results, covering AMD K6-2, K6-3,
Cyrix 6x86/M2, Intel P2/Celeron A and Winchip's at many different clock
speeds.
Site: http://www.cpureview.com
Article: http://www.cpureview.com/art_kernel_cover.html
The K6-3 was the fastest of the chips I tested. For more details, please see
the article.
Regards,
Bill
--
William Henning http://www.cpureview.com NEW: Forums (BBS)!
reviews: Riva 128&TNT, G200, i740, Voodoo2, Soyo 5EHM, Shuttle 591P
articles: What makes a good business PC?, StarOffice4 on RedHat 5.1
&more! Linux kernel compilation benchmarks, Overclocking
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Thu, 8 Apr 1999 05:12:15 +0100
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: PCI DMA to user space possible?
In article <[EMAIL PROTECTED]>,
Klaus Elend <[EMAIL PROTECTED]> writes:
> I want to write a linux device driver for a PCI board that
> transfers data into the PC at up to 50 MB/s using DMA. Reading
> all available linux documentation (KHG, "Linux Device Drivers"
> from Rubini), I found the usual method under Linux requires
> copying the data from a dedicated DMA buffer in kernel space to
> user space. This is different from how Windows NT works, where
> the DMA can be made directly into user space and no additional
> copying is required.
>
> Is this additional copying step really required in Linux or is
> there a possibility to eliminate it? Copying the data would use
> up too much memory bandwith for my application and would therefore
> restrict me to continue using NT :-(
I have done this :-)
The Linux kernel doesn't support it, though. The are two
solutions I am aware of, and both require a kernel patch:
One possibility is Matt Walsh's "bigphysarea" patch. (Can't give
you an URL, but I'm sure you'll find it if you search altavista for
"bigphysarea"). Basically, what it does is to reserve a portion
of memory at boot time. That memory is then inaccessible to
the system and is exclusively used as DMA buffer, which you can
access directly from user space. I think the Matrox Meteor driver
is a nice example to look at.
Advantage:
- DMA buffer is _physically_ contiguous -> no need for scatter/gather DMA
Disadvantages:
- Memory has to be dedicated for DMA, i.e. you can't use it for
anything else and you have to know in advance (at boot time) how
much you'll need.
- Requires a kernel patch
The other possibility is to use my user-space DMA patch which is
available at ftp://ftp.sysgo.de/pub/Linux. It adds a set of functions
to the kernel that allow a driver to lock/unlock a given piece of
user-space into memory (to make sure it doesn't get swapped out
while the DMA is proceeding) and another function to determine the
addresses and sizes of physical memory chunks that constitute a
given piece of user-space memory. (You've done this in NT, so I
suppose you're aware of the fact that virtually contiguous user-space
memory usually isn't physically contiguous).
Advantage:
- Can DMA to any piece of user-space memory, i.e. you can malloc()
your DMA buffer at run time and free() it if you no longer need it.
In fact, your application doesn't even need to be aware that DMA
is used.
Disadvantages:
- Contiguous user-space memory generally doesn't correspond to
contiguous physical addresses (which is what your DMA controller uses)
Therefore you must do scatter/gather DMA.
- Requires a kernel patch
My patch currently works for the 2.0.xx series of Linux kernels.
I'm porting it to 2.2.xx right now and I will make it publicly available
when I'm done (mail me if you need a pre-release version).
Have fun!
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (Suchandra Thapa)
Subject: Re: Win32 support in Linux
Date: Wed, 14 Apr 1999 06:23:53 GMT
On Wed, 14 Apr 1999 04:49:30 GMT,
Jim Roberts <[EMAIL PROTECTED]> wrote:
>
>Try the man page for "mount". First it would answer your question and
>second you would find that Linux mounts approx 22 different file systems
Actually in this case the man pages for mount don't mention mount. At
least for RH5.2 the man page for mount is from 1997 and using info doesn't
help either. I believe in this case the original question was totally
legitimate.
--
==================================================================
Suchandra S. Thapa
[EMAIL PROTECTED]
==================================================================
------------------------------
From: [EMAIL PROTECTED] (David Nilsen)
Subject: Large pages
Date: 13 Apr 1999 16:25:42 -0700
I know the Pentium family of CPUs has support for 4mb pages, and did
some Web searches to see if such a feature is in Linux, but my search
was inconclusive.
Does anyone know if such a feature exists? If so, can you enable it on
a per-process basis?
(In case you may have guessed, I have a huge application that typically
thrashes the TLB. Large pages seem to help under other OS's. Does
Linux have any other features that might help with this?)
--David Nilsen
[EMAIL PROTECTED]
------------------------------
From: Lenar Lohmus <[EMAIL PROTECTED]>
Subject: Re: Problems with ARP on 2.2.X (contd.)
Date: 14 Apr 1999 06:32:14 GMT
Having exactly the same problem but even more.
I used proxy arp on my internal network, but after installing
2.2.5 (2.2.1 at first) it seems to be boken. When I boot
with 2.0.36 everything works just fine as usual.
When I try to add new pub entryes to the table it works.
But if I look at the arp cache the 'C' (Complete) flag is
missing from my newly made entries. So it is understandable
why my proxy arp doesn't work. But I do not see a solution
to make these entries 'complete'. And of course, I can't
delete these entries, I get the error message mentioned below.
I hope somebody knows what's the problem.
---
Lenar
Sam Johnston wrote:
> Sorry about that - lets try again:
>
> Hello all,
>
> I figure this is probably the best place for such a question - I'm using
>
> Debian 2.1 (slink) and have compiled the 2.2.5 kernel. When I try to
> delete an address from the arp table I get:
>
> SIOCDARP(pub): No such file or directory
>
> and similarly with ppp (and proxyarp):
>
> Apr 9 14:50:02 svr-new pppd[328]: ioctl(SIOCDARP): No such file or
> directory(2)
>
> Reading the man(8) page for arp, I find that it wants to see
> /proc/net/arp, which exists and contains entries like:
>
> IP address HW type Flags HW address Mask
> Device
> A.B.C.D 0x1 0x2 AA:BB:CC:DD:EE:FF
> * eth0
>
> From http://www.debian.org/releases/slink/running-kernel-2.2 I see that
> slink is certified for 2.0.X but not for 2.2.X and that there are some
> known issues. However there is no mention of arp.
>
> Anyone?
>
> Thanks in advance.
>
> - samj
>
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Large pages
Date: 14 Apr 1999 02:41:07 -0400
In article <7f1a82$48k$[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[David Nilsen <[EMAIL PROTECTED]>]
>> I know the Pentium family of CPUs has support for 4mb pages, and did
>> some Web searches to see if such a feature is in Linux, but my search
>> was inconclusive.
>
>> Does anyone know if such a feature exists? If so, can you enable it on
>> a per-process basis?
Per-process? That is, put it into the process address space?
How long will page-in/page-out take on such page?
>At one point Intel was sagely publishing information on 4MB pages only
[snip]
>H. Intel apparently changed their minds at some point, since my PPro
>manuals (Jan 1996) have the info. In any case, AFAIK, Linux doesn't
>use the feature at present.
grepTFSource. arch/i386/mm/init.c. It is used for kernel memory, but not
for processes.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Win32 support in Linux
Date: Wed, 14 Apr 1999 06:45:43 GMT
On Wed, 14 Apr 1999 06:23:53 GMT, [EMAIL PROTECTED]
(Suchandra Thapa) wrote:
>On Wed, 14 Apr 1999 04:49:30 GMT,
> Jim Roberts <[EMAIL PROTECTED]> wrote:
>>
>>Try the man page for "mount". First it would answer your question and
>>second you would find that Linux mounts approx 22 different file systems
>
>Actually in this case the man pages for mount don't mention mount. At
>least for RH5.2 the man page for mount is from 1997 and using info doesn't
>help either. I believe in this case the original question was totally
>legitimate.
>
>--
>------------------------------------------------------------------
>
>Suchandra S. Thapa
>[EMAIL PROTECTED]
>
>------------------------------------------------------------------
Except I said win32, and not fat 32. Oops. Well, I got it working,
without very much work. At least not for that. Win98 decided it was
going to make it self the booting partition, and so I had to fish out
my rh rescue disk and fix that, which took me a couple of hours (one
to find the disk, another to fix the problem). My fstab I didn't even
have to change! it mounts my c: and d: drives from windows (dos with
it's gui) just like it did before. With better access time too, I
would susspect.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Difference between vanilla and ac
Date: 13 Apr 1999 21:36:59 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Dieter Kraft <[EMAIL PROTECTED]>]
> can the difference in vanilla and ac (Alan Cox, I suppose) be
> explained in short?
Alan sends changelogs to the linux-kernel and to LWN, and LWN usually
posts them. For example:
http://www.lwn.net/1999/0408/a/2.2.5ac6.html
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: Difference between vanilla and ac
Date: 13 Apr 1999 22:41:53 GMT
In article <[EMAIL PROTECTED]>,
Robert Schiele <[EMAIL PROTECTED]> writes:
> Dieter Kraft wrote:
>>
>> Hi,
>> can the difference in vanilla and ac (Alan Cox, I suppose)
>> be explained in short?
>> Thanks
>> Dieter
>>
>
> This is just how Alan names its directories. linux.vanilla is always the
> official version from Linus, linux.ac is his patched version. There is
> nothing more about it.
In English, the word "vanilla" is used to mean the plain variant
of something, in analogy with "vanilla icecream", which is the
basic version of icecream. In this sense, the opposite of
"vanilla" is "fancy".
HTH,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.x
Subject: Re: The Mindset Trap
Reply-To: [EMAIL PROTECTED]
Date: Tue, 13 Apr 1999 23:48:04 GMT
On Mon, 12 Apr 1999 19:02:40 -0700, Avery & Helen Payne
<[EMAIL PROTECTED]> wrote:
>It seems to me that as of late, the very problems that Linux is trying to
>avoid are being promoted...which makes me wonder if there is a subversive
>movement coming from the city of Redmond... Things like:
>
>1) Centralized Settings Database. This set off a discussion in the
>community when someone suggested that it be "made like the Windows
>registry". Ugh. Folks, I understand how frustrating it is to have
>different formats for different config files, but frankly, one sizes doesn't
>fit all. The config files are text for a reason - because they were meant
>to be manipulated with text processing tools that come with the system ( vi,
>grep, sed, emacs, etc.)
There are two ideas that people seem to be steadfastly bent on
mistaking for one another:
a) Creating a centralized database, where those that are involved seem
to be utterly lacking in understanding of either how databases are
implemented, how transaction management works (e.g. - if there are 40
changes that have to either go in together, or be rolled back together),
or about the notion of serialization, or the necessary protocols of
ordering reads/updates.
Duplicating the Windows Registry in all its "glory" as a fragile binary
database, repository of countless different bits of critical system
configuration information is a fool's errand that only a few utter fools
have been proposing.
Most of the ideas being discussed don't relate to this but rather
reflect...
b) Creating centralized APIs that know how to multiplex access to a
variety of data sources so that diverse configuration information may be
accessed in common ways.
Linuxconf does this; COAS does this;
<http://www.debian.org/~wakkerma/config6/> talks about this for Debian;
I think that people are insane not to be considering the use of
something that *EXISTS ALREADY* like cfengine
<http://www.iu.hioslo.no/cfengine/>; there's
<http://24.1.97.22/gmd/opStore/> opStore,
<http://www.thestuff.net/libcfg/?theme=lcars> libCFG, the
<http://imap.org/docs/acap.html> ACAP protocol, and probably others.
The point of the exercise is *NOT* to create a fragile binary database,
except to moronic trolls that have Microsoft on the brain, but rather to
provide some common ways of *GETTING AT* the configuration information.
In the long run, it might be nice to establish some common libraries
(perhaps like libPropList?) to provide common mechanisms for reading and
writing configuration information; that makes it easier to build
automated tools to both monitor *and maintain* configuration
information.
This in no way mandates the use of binary formats, or the notion of
forcing the data all into one file, or the notion that the *only* way to
update things is by use of some obscure API somewhere.
>2) Replacement of X as a user interface. Uh, it seems that the bulk of
>posters on this topic can't distinguish between a Window Manager and an
>X-server.
... And people that are effectively illiterate in this keep
misunderstanding what X is, what a Window Manager is, what a GUI library
is, what "bloatedness" they are actually encountering (versus what they
*think* is bloated about X) and, most importantly, THAT MOST OF THE
THINGS BEING WORKED ON THESE DAYS AREN'T FORCIBLY X-SPECIFIC.
Note to the uncomprehending:
- GTk and Qt and Tk and FLTK are amongst the "most-adopted" GUI
libraries these days; *none of them only run on X.*
- If you code to a decent API that already works atop multiple graphical
infrastructures (e.g. - most of these run on some combination of X,
Win32, and MacOS), then changes to X, *or even a replacement of X,* does
not require modifying the applications.
We are on an appropriate route to the eventual replacement of X by
whatever better solution comes along. That may be GGI. We'll see.
XFree86 4.0 may solve many of the problems.
Alternatively, 256MB DIMM chips should start to be cheap next year, and,
as a note to the unclued, X ISN'T GETTING ANY MORE BLOATED.
Amortizing the few megs of X server and Xlib code when you had 512k of
video memory made X look pretty expensive five years ago. Amortizing
that same code when you now likely have 4MB or more of RAM on the video
card, and have to have almost double that in double-buffering in order
to get decent performance, makes what "X bloat" there is quite
reasonable today.
Next year's "state of the art" graphics cards are liable to have 64MB of
RAM on them, which will make the less-than-10MB of X-related software
that sits in memory increasingly unimportant, and combining that with
the 256MB DIMMs makes the "bloat" of X exceedingly unimportant.
>3) Everyone and their brother's frog deciding that they will release some
>mutated version of the LGPL. Apple was the worst of the bunch - at the
>moment you can contribute back to Apple's source and have it incorporated,
>but Apple reserves the right to pull the plug at any moment, and all of your
>hard work suddenly becomes THEIR INTELLECTUAL PROPERTY. Think about that
>one.
Termination is a problem.
The ludicrous growth of the "*PL of the week" is a problem.
It is at least encouraging that we're not mutating a new X library each
month anymore as we were a couple years ago...
>4) Everyone suddenly thinks that it is critical that Linux become a desktop
>OS. What purpose does this serve?
The UNIX vendors 'gave the desktop up' to Microsoft, and shot themselves
in the foot thereby.
I'm not sure what the right answer to this one is; I just know that I
haven't seen the right answer yet.
--
Where do you *not* want to go today? "Confutatis maledictis, flammis
acribus addictis" (<http://www.hex.net/~cbbrowne/xbloat.html>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Enkidu <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: Wed, 14 Apr 1999 20:36:16 +1200
Reply-To: [EMAIL PROTECTED]
"M.C. van den Bovenkamp" wrote:
>
> Here in the Netherlands; the province of Zeeland ('Sea-land',
> literally). A Dutch fellow whose name escapes me right now
> discovered what was to become New Zealand and called it Nieuw
> Zeeland.
>
Abel Tasman.
Greeting from New Zealand,
Cliff
--
Cliff Pratt, CAP Consulting
Web build, web design. HTML, Javascript, CGI, ASP, Web Consulting
Email: [EMAIL PROTECTED] Phone: 025 246 7747
------------------------------
** 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
******************************
