Linux-Misc Digest #336, Volume #19 Sat, 6 Mar 99 20:13:08 EST
Contents:
Re: DNS problem (Raj Rijhwani)
Re: Public license question (Bernd Gehrmann)
Re: equivalent of edit? (Gamma Rat)
Re: VQF for Linux... (Todd Ostermeier)
Re: More bad news for NT (Ed Blackman)
Re: BEST HW For Linux NoteBook Project (Robert Billing)
Re: kermit messages (Frank da Cruz)
Re: How to change date for Unix/Linux? (jik-)
Re: mounting dos partition (bklimas)
Re: Can Linux use 36-bit Xeon addressing? (Robert Krawitz)
Re: Again SMP problems (Jacques Oosthuizen)
Re: glibc2.1.x + gnu.org 'political issues'?? (jik-)
stupid tar question (tim rosen)
Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?) (Phillip Deackes)
Re: Berkeley DB (Juergen Heinzl)
A LUG in Vermont ("Marc G. Glade")
Re: A LUG in Vermont (mlw)
Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Raj Rijhwani)
Crossposted-To: uk.comp.os.linux
Subject: Re: DNS problem
Date: Sat, 06 Mar 99 01:34:45 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] "Robert Billing" writes:
> Raj Rijhwani wrote:
> > a request is made of the server for external resolution once the gateway
> > is down, it seems to lock out and won't answer external addresses even
> > when the gate comes back up. Resetting it (with "kill -HUP {pid}") gets
> > it up and running again.
> I had to comment out this line in
> /usr/local/lib/diald/standard.filter.m4 to get DNS to bring the link up.
> #ignore udp udp.dest=udp.domain,udp.source=udp.domain
I'm not using diald, but thanks for the tought.
To clarify, the gateway machine has scheduled dial-up events, whilst
it can also be manually engaged. Other machines behind it, await the
arrival of mail and periodically try to pick up news, to make full use
of the line whenever it's up. These machines (and any of the web
browsers that may be active) rely on the internal DNS, which is also
behind the gateway. As I said before, this works fine when it's
started/reset whilst the line's up, but once the line goes down, asking
for resolution of an external address (as happens when the news
collector polls every few minutes) often causes DNS to lock up, and it
has to be restarted before it will serve another request (even an
internal one). I've got around this at the moment by the very kludgy
expedient of a "killall -1 named" cron event every 15 minutes. Dirty,
but sufficiently good to work (for now). I'd prefer it didn't need to,
though.
--
Raj Rijhwani (umtsb5/16) | This is the voice of the Mysterons...
[EMAIL PROTECTED] | ... We know that you can hear us Earthmen
[EMAIL PROTECTED] | "Lieutenant Green: Launch all Angels!"
http://www.courtfld.demon.co.uk/raj/ (demon, and gods, willing...)
------------------------------
From: Bernd Gehrmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,gnu.misc.discuss
Subject: Re: Public license question
Date: Sat, 6 Mar 1999 22:03:35 +0100
On Thu, 4 Mar 1999, John Hasler wrote:
> Christopher Seawood writes:
> > Per Section 3, what constitutes "normally distributed with major
> > components of the operating system"?
>
> Libc, Motif.
>
> > Motif distributed with Solaris seems to fall under this distinction but
> > Qt distributed with Linux-Mandrake does not. What's the difference?
>
> Is Linux-Mandrake an operating system, or is it only a minor variation on
> an operating system that does not normally include Qt?
It's a variation of an operating system that does normally include
Qt, but not Motif. But for the given question (section 3 of the GPL)
this is irrelevant. This section requires that for components of the
operating system which accompany a GPL'd program, the source must
be provided. Qt always comes with source code, so this is not an
issue. For Motif, it _is_ an issue. GPL'd programs statically linked
with Motif are always in violation with the GPL. Moreover, with the
unusual definition given in the GPL (compilers are part the OS), one
cannot ship a compiler bundled with e. g. Emacs without providing
source for the compiler. AFAIR Sun did exactly this.
> Copyright law does not concern itself about processes, source files,
> sockets, linkage, etc. Copyright is about making copies. If your work as
> didtributed contains a copy of part or all of another work it is a
> derivative of that work. If not, it isn't.
This doesn't answer the question, because the GPL does not apply for
mere aggregation of works.
Bernd.
------------------------------
From: [EMAIL PROTECTED] (Gamma Rat)
Subject: Re: equivalent of edit?
Date: 6 Mar 1999 21:46:25 GMT
Reply-To: see my .sig below
On 3 Mar 1999 22:22:03 GMT, ErickShun6 <[EMAIL PROTECTED]> wrote:
>I know it's kinda a stupid question but what is the equvalent of edit in linux?
Perhaps what you are looking for is "mcedit".
--
The penguins are not what they seem ...
These are my opinions. Others will believe what they wish to believe.
It's not my job to re-educate the net. Demands for citations will be ignored.
(And isn't it ironic how people demand air-tight proofs only for views that
don't agree with theirs?)
My REAL email address is ksinner
at ticon
dot net
------------------------------
From: Todd Ostermeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: VQF for Linux...
Date: Sat, 6 Mar 1999 16:22:08 -0600
On Sat, 6 Mar 1999, Brian Woo wrote:
: Hi all,
:
: Is there a VQF player for Linux? There are several MP3 players out
: there for Linux but I can find one which also supports the VQF
: format... Thanks
That's probably because VQF is a proprietary format. I expect it to be a
while before VQF is supported.
________________________________
Todd Ostermeier
[EMAIL PROTECTED]
http://www.ews.uiuc.edu/~ostermer/index.html
ICQ UIN: 2253928
A-723
________________________________
------------------------------
From: [EMAIL PROTECTED] (Ed Blackman)
Subject: Re: More bad news for NT
Date: Sat, 06 Mar 1999 11:47:16 -0500
Reply-To: [EMAIL PROTECTED]
Harry <[EMAIL PROTECTED]> wrote:
>> luser <
>
>This is an appalling way to refer to your end-users! Why do shop
>staff and help desk people always hate dealing with the public?
Help desk people deal with a lot of people who are ignorant about
computers, simply because people who aren't as ignorant don't use the
help desk frequently. When just about every user they deal with is
ignorant, it's not surpising that they have a tendency to start
thinking that every end user is ignorant.
Ed
------------------------------
From: Robert Billing <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.portable,uk.comp.os.linux
Subject: Re: BEST HW For Linux NoteBook Project
Date: Sat, 06 Mar 1999 23:00:11 +0000
David Fox wrote:
> You could get a Pentium 233MMX thinkpad 560X from Micro Warehouse for
> $1299.
Look, chaps, if you are going to crosspost to uk.comp.os.linux, could
we have the prices in sterling as well please? Btw I have just picked up
a Libretto, that runs Linux very well, for �600 (that's about $1000).
--
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
------------------------------
From: [EMAIL PROTECTED] (Frank da Cruz)
Crossposted-To: comp.protocols.kermit.misc
Subject: Re: kermit messages
Date: 6 Mar 1999 23:31:28 GMT
In article <[EMAIL PROTECTED]>,
Allan Adler <[EMAIL PROTECTED]> wrote:
:
: I am running kermit on a 80486 under RedHat 5.1 Linux. In downloading
: files, I frequently get messages about input overruns. I gather that
: this is a correctable error since the integrity of the file seems
: uncompromised after the file is downloaded.
:
This means either:
(a) You do not have an adequate flow-control method enabled between
C-Kermit and the modem. If, however, you are using C-Kermit 6.0 or
later with a modern modem, and following the instructions for
dialing, then Kermit should be choosing RTS/CTS by default, and
also setting it in the modem. Or:
(b) Your serial port is an unbuffered kind (8250, 16450, etc) rather
than a buffered one, in which case the Linux device driver itself
loses characters when its attempt to flow control the modem are
not fast enough. Or:
(c) You have interrupt conflicts in your PC configuration.
The Kermit protocol is designed to correct errors like this, and it's
doing its job in your case.
: Today I started getting
: a new message in addition to the overrun message. It is:
:
: ll_rw_block: device 03:02: only 1024-char blocks implemented (4096)
:
: Again, it doesn't seem to have compromised the integrity of the file
: transferred. However, if these messages indicate that I should be
: doing something differently I would like to know about it. It would
: also be nice to know what they mean; I'm clueless.
:
: The file that gave the new message was a compressed tar file. When
: I left kermit and tried to uncompress the file, I got the same
: message:
:
: ll_rw_block: device 03:02: only 1024-char blocks implemented (4096)
:
: So maybe something else is going on, not specifically involving kermit.
:
Which version of C-Kermit are you using? Newer versions do bigger disk
writes. Version 7.0 might try to write anywhere from 4K to 32K at a time.
Evidently your disk device driver doesn't handle large writes "atomically"
and therefore puts up a warning message to let you know this. But from what
you said, it also appears to recover from them by breaking large writes up
into smaller ones internally.
In C-Kermit 7.0 you can control the size of the disk output buffer with:
SET FILE OUTPUT { { BUFFERED, UNBUFFERED } [ size ], BLOCKING, NONBLOCKING }
Lets you control the disk output buffer for incoming files. Buffered
blocking writes are normal. Nonblocking writes might be faster on some
systems but might also be risky, depending on the underlying file service.
Unbuffered writes might be useful in critical applications to ensure that
cached disk writes are not lost in a crash, but will probably also be
slower. The optional size parameter after BUFFERED or UNBUFFERED lets you
change the disk output buffer size; this might make a difference in
performance.
Please report results back to [EMAIL PROTECTED]
- Frank
------------------------------
From: jik- <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.admin,comp.unix.questions
Subject: Re: How to change date for Unix/Linux?
Date: Sat, 06 Mar 1999 15:30:39 -0800
Alexander Kalinin wrote:
>
> In comp.unix.questions [EMAIL PROTECTED] wrote:
>
> date is the basic command. ntpd is more advanced way.
I found the best way to fix the date and time was to do it in the BIOS.
Every time I restarted my coimputer Linux would check the bios and use
THAT time anyway,...so changing the date in Linux for me was irrelevant,
changing the BIOS clock did the trick.
Funny thing is, win95 seems to use the BIOS clock directly, so changing
the time in win95 will carry over to Linux...one of the few ways the 2
affect each other on the same system.
------------------------------
From: bklimas <[EMAIL PROTECTED]>
Subject: Re: mounting dos partition
Date: Sat, 06 Mar 1999 23:42:32 GMT
Rulecoyote wrote:
> Hi
>
> I know this must be common knowledge but I cant seem to find it any where.
> I have a cursed ltwinmodem so windows is my downloader. I need to transfer
> some linux files to my linux partitions. How is that done?
>
> [EMAIL PROTECTED]
This question was asked so many times that I created a hompage to answer it.
Try:
http://www.magma.ca/~bklimas
Best regards,
b.k.
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.hardware
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: 06 Mar 1999 18:44:39 -0500
Johan Kullstam <[EMAIL PROTECTED]> writes:
> Robert Krawitz <[EMAIL PROTECTED]> writes:
>
> > For better or for worse, the latter statement is not true, and it's
> > becoming less and less true. If your goal is to run Oracle, Informix,
> > DB/2, Sybase, or what have you, binary compatibility is essential.
>
> true. but to exploit a 36 bit address space in order to use more than
> 4 GB on a xeon, would require recompiling those applications. so your
> program falls into two buckets:
No, that's not true either! These applications in fact run many
individual processes, each of which uses less than 2 GB of address
space. However, the SUM of the total address spaces of all of these
processes can far exceed 2 GB.
These processes do not need to share their address spaces with the
other processes making up the application.
> therefore, there is no point in trying to make a far pointer memory
> model for linux on the x86. should you need big memory, just use
> a 64 bit platform.
I think we're talking past each other here. I don't want a far
pointer memory model or any of that nonsense. I want to be able to
use >2GB (>4GB, whatever) of PHYSICAL memory. When I say I want to be
able to use that much physical memory, I mean that I want the kernel
to be able to take advantage of it for my processes. All that that
means is for the kernel to be able to stash the pages of my processes
in that memory and such. My user space processes will never know the
difference; they're still using 32 bit addresses.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Jacques Oosthuizen <[EMAIL PROTECTED]>
Subject: Re: Again SMP problems
Date: Mon, 01 Mar 1999 12:00:02 +0200
Sorry version 2.2.2
Raymond Doetjes wrote:
> Wich kernel do you use???
>
> Jacques Oosthuizen wrote:
>
> > I have previously posted a message with a problem on our compaq proliant
> > 800 server with two CPU's . I have compiled a kernel for SMP , changed
> > the BIOS to say Unixware
> > but the machine runs for about five minutes and then locks up. This is a
> > serious problem because we want to use this machine for a Sybase
> > database. In single CPU mode the machine is ROCK SOLID. Common guys this
> > machine is dual boot an under NT we don't have any probs. Can anyone
> > help me PLEASE.
>
> --
> =====================================================================
> Windows is a 32 bit patch to a 16 bit GUI based on a 8 bit operating
> system, written for a 4 bit processor by a 2 bit company which can
> not stand 1 bit of competition.
> =====================================================================
------------------------------
From: jik- <[EMAIL PROTECTED]>
Subject: Re: glibc2.1.x + gnu.org 'political issues'??
Date: Fri, 05 Mar 1999 14:47:07 -0800
> glibc-2.1 contains some features that work with EGCS, but not with
> gcc2.8.1. (Mostly relating to C++ functionality, I gather.)
>
> Sounds to me like there won't be a new release of glibc until either:
> a) The FSF releases a newer version of GCC,
> b) EGCS gets "blessed" as the New GCC, or
> c) glibc gets back-ported to gcc2.8.1.
In other words, the FSF has proven to the world it can be more petty and
stupid then anyone...hmmm...glad I never switched....looks like glibc2
has no real future. Course just because gnu refuses to distribute it,
doesn't mean noone else can.
This 'community' is going down hill people, I hope you all realize
that. I hope we can do something about it before it turns into
crap,..like so many other things that might have been cool.
I gotta ask though...I thought C++ had a standard, unlike objc were you
naturaly get compiler uncompatabilities,....there shouldn't be any
reason why it would compile on one and not the other should there? And
what would a C library be doing with C++ code in it? Isn't that what
libg++ is for???
------------------------------
From: tim rosen <[EMAIL PROTECTED]>
Subject: stupid tar question
Date: Sat, 6 Mar 1999 18:44:53 -0500
This is an awfully simple question, but I just can't seem to find a simple
explanation in my various manuals. How do I extract tar files? I'm trying:
tar -x file.tar
and it is just freezing up.
Help please. Thank you.
------------------------------
From: [EMAIL PROTECTED] (Phillip Deackes)
Crossposted-To:
alt.os.linux.slackware,comp.os.linux.development.system,comp.os.linux.hardware,comp.os.linux.setup
Subject: Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?)
Date: 5 Mar 1999 21:52:29 GMT
In article <[EMAIL PROTECTED]>, Christian Ravera wrote:
>
>Sure, I can answer that one. Raise the voltage to 2.3V, and if that doesn't
>work try 2.4V... then it'll be smooth sailing. Like yours, my machine won't
>even boot when my K6-2/350 is at 400 mhz / 2.2V... but with my voltage at
>2.3V... NO PROBLEMS. The K6-2/350 does 400 just fine.
Thanks, Christian. I had been running my K6-350 for a while at 400 MHz,
but has a few problems - like compiling the kernel and getting a signal
11 error. I had given up over-clocking and set it back to 350 MHz -
until I read your post. Now I have raised the voltage to 2.3V and it
works great at 400 MHz, no signal 11 in sight!!
Thanks very much!
--
Phillip Deackes
[EMAIL PROTECTED]
Debian Linux v.2.0
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Berkeley DB
Date: Sat, 06 Mar 1999 23:42:10 GMT
In article <[EMAIL PROTECTED]>, Milos Prudek wrote:
>> >How do I find out what version of Berkeley DB is installed on my Linux?
>>
>> See the db.h include file ... DB_VERSION_MAJOR etc.
>
>There's no DB_VERSION_MAJOR or DB_VERSION in there. The file is dated
>Dec 16, 1996, and comment at the beginning of the file says "8.7
>(Berkeley) 6.16.94"
Then it is too old 8) ... you can get the latest and greatest ...
http://www.sleepycat.com/
... here. Since GNU glibc-2.x comes with version 2.x too you might consider
using a static libdb for sendmail, else you'll have to re-compile sendmail
latter (just in case).
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
\ Phone Private : +44 181-332 0750 \ /
------------------------------
Date: Sat, 06 Mar 1999 00:45:21 -0500
From: "Marc G. Glade" <[EMAIL PROTECTED]>
Crossposted-To: vt.unix,uvm.linux,uvm.unix,comp.os.linux.advocacy
Subject: A LUG in Vermont
Hi my name is Marc Glade and I have been a user of Linux for the past
five years. I am interested in starting a Linux Users Group in Vermont,
particularly in the Burlington area. I think that there could be a lot
of use out there in the snow covered countryside for a LUG in the green
mountain state. I am looking the either start a new LUG or try and
revitalize the now defunct SLUG-VT. The goals of this new LUG would be
as set forth in the User-Group-HOWTO: 1) advocacy, 2) education, 3)
support and, 4) socializing. If you would be interested in either
joining or helping to set up a Users Group in Vermont then please send
email to Marc Glade at [EMAIL PROTECTED] I look forward to
hearing from you.
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: vt.unix,uvm.linux,uvm.unix,comp.os.linux.advocacy
Subject: Re: A LUG in Vermont
Date: Sat, 06 Mar 1999 15:19:41 +0000
Marc G. Glade wrote:
>
> Hi my name is Marc Glade and I have been a user of Linux for the past
> five years. I am interested in starting a Linux Users Group in Vermont,
> particularly in the Burlington area. I think that there could be a lot
> of use out there in the snow covered countryside for a LUG in the green
> mountain state. I am looking the either start a new LUG or try and
> revitalize the now defunct SLUG-VT. The goals of this new LUG would be
> as set forth in the User-Group-HOWTO: 1) advocacy, 2) education, 3)
> support and, 4) socializing. If you would be interested in either
> joining or helping to set up a Users Group in Vermont then please send
> email to Marc Glade at [EMAIL PROTECTED] I look forward to
> hearing from you.
Are there more than two computers in Vermont? ;-)
(Just kidding, couldn't resist, I'm in Mass)
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.hardware
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:03:44 -0500
Hello all;
Robert Krawitz wrote in message ...
>[EMAIL PROTECTED] (Christopher B. Browne) writes:
>
>> >The Xeon is not a "36-bit" machine, whatever that is... It merely has a
>> >36-bit physical address bus.
>>
>> That can be interpreted as meaning it supports 36 bit address spaces, so
it
>> is a true statement.
>
>That interpretation is simply incorrect. Virtual addresses (which are
>the only kind that normal instructions ever deal with in protected
>mode) are 32 bits wide, just as in all x86 processors from the 80386
>on up. The processor (in hardware, by referring to the page tables)
>translates these virtual addresses into physical memory addresses.
>It's immaterial how wide the physical address bus is. The physical
>address bus could be 20 bits wide (not that I'd care to use such a
>machine), or 32 bits wide, or 40 bits wide. The kernel sets up the
>mapping between virtual addresses and physical memory; the processor
>actually performs the mapping in hardware, and the user code never
>knows the difference.
Maybe I misinterpeted the original posters question but as I understood it
he had a process that wanted to access around 8GB of main memory. I don't
know what the application was, but It clearly requires a machine with an
address space of more than 32 bits. The Xeon is NOT the processor for
this sort of thing. The market now supports several processor families
with clean 64 bit addressing, which would support large programs in a much
cleaner implementation. Since Linux runs on several of these it would be
foolish to try to stuff this application on to a XEON.
>
>> >The Xeon, like all x86's, is a 32-bit machine. For the large part, the
>> >code needing modification is kernel code that deals with physical
addresses.
>>
>> Nope. It will intrude on all user code as well, because user code deals
>> with logical addresses, which must be mapped to physical addresses, and
>> therefore need to have an isomorphism to do so, ergo the compiler must be
>> modified to use the 36 bit addressing mode, libraries must be modified to
>> use the 36 bit addressing mode, and applications must be modified to use
the
>> 36 bit addressing mode.
>
>Not at all. You're drawing completely unwarranted conclusions here.
>
>User code does deal with virtual (not "logical") addresses, and yes,
>they must ultimately be mapped to physical addresses. However,
>everything else in that paragraph is incorrect.
Again this depends on the application. If there is a need to address more
than 4GB of memory then the system and libraries must support that.
>
>At any given time, any given address within any given process address
>space may or may not be mapped to any given physical address. If it
>is so mapped, the processor just goes ahead and accesses the
>appropriate memory location.
>
>If it's not mapped (i. e. if the page table entry for the given
>address -- and this is still a virtual address -- is blank), however,
>the processor takes a page fault. This is essentially an internally
>generated interrupt. This page fault is trapped by the kernel, which
>saves away the processor state and looks at the (still virtual)
>address that generated the fault. There are a number of things it can
>do here:
>
>1) It can determine that the address is not in the process's address
>space (e. g. the address is 0). In this case, the kernel will raise a
>segmentation fault, which becomes a signal to the process. Unless the
>process has arranged to catch SIGSEGV (or sometimes SIGBUS -- I'm not
>clear on the distinction), it will be terminated with a core dump.
>
>2) It can determine that the virtual address in question is part of
>the process's address space, and already exists in physical memory
>(i. e. it's part of a file -- such as an executable or a shared
>library -- that wasn't already mapped). In this case, it will set up
>the mapping in the process's page table and continue the process from
>where it left off. Unless there's a really nasty kernel bug, this
>should be undetectable by the process.
>
>3) It can determine that the virtual address in question is not
>currently in physical memory. In this case, it will need to find the
>page on disk and bring it into physical memory, and set up the
>mapping, and resume the process. Again, the process should not be
>able to detect this. The process may be able to infer this by means
>of a time delay (e. g. it took 10 milliseconds to access this memory
>location -- that's probably a page fault, although the kernel might
>have decided to preempt the process for entirely different reasons).
>
>Notice that at no point in this scenario does the user process have
>any idea whether the virtual address it accessed was mapped, or how.
>Nor does it matter how wide the virtual address is, or how wide the
>physical address is. It's simply a mapping. Each virtual address
>maps to zero or one physical addresses, but there's no isomorphism
>here at all. Indeed, many different virtual addresses can map to the
>
>> It does not seem to be a reasonable idea to start tying the OS to an
>> odd-ball addressing mode that will hurt portability later, particularly
>> when:
>
>Linus's point is that mapping all of physical memory into virtual
>address space makes management of physical memory in the kernel a lot
>easier and more efficient. This is indeed a serious enough
>consideration, but there are no user-space ramifications here (other
>than possibly slower I/O or context switching).
>
>--
>Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
>
>Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
>Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
>
>"Linux doesn't dictate how I work, I dictate how Linux works."
>--Eric Crampton
------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.hardware
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:10:28 -0500
Johan Kullstam wrote in message ...
>Robert Krawitz <[EMAIL PROTECTED]> writes:
>
>> 2 GB RAM is a satisfactory virtual address space for a single process
>> for most purposes, but 1 or 2 GB RAM is not a satisfactory upper limit
>> on RAM today.
>
>but these are not `most purposes'. the big ram user will almost
>certainly need a shitload of ram for *one* process. otherwise, you'd
>just buy more machines and run one of the big (but not humongous)
>processes on each.
>
>e.g., a finite-element analysis requiring 7GB of memory for the matrix
>math. or a database application juggling a giant lump in memory.
My question is why would anyone try to run a finite-element analysis with a
7GB matrix on any Intel based machine. Again this is an address space
issue best solved by a 64 bit processor. Even NT breakes up the address
space of an i386 in such a way that user adressable memory is limited.
>
>--
> J o h a n K u l l s t a m
> [[EMAIL PROTECTED]]
> Don't Fear the Penguin!
------------------------------
** 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.misc) 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-Misc Digest
******************************
