> > Is there any reason they couldn't just be merged to mainline?
> >
> > I think it's a useful facility.
>
> ummm, now why did we made that decision... I think we decided that
> it's the sort of thing which one person can run once per few months
> and that will deliver its full value. I can
Is there any reason they couldn't just be merged to mainline?
I think it's a useful facility.
ummm, now why did we made that decision... I think we decided that
it's the sort of thing which one person can run once per few months
and that will deliver its full value. I can maintain it
I think you may be misinterpreting the word "poor" here.
Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; [EMAIL
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-kernel-
[EMAIL PROTECTED] On Behalf Of Pavel Machek
Sent: Saturday, October 27, 2007 11:29 AM
To: Ray Lee
Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
linux-kernel@vger.kernel.org; [EMAIL
I think you may be misinterpreting the word poor here.
Many people in this thread consider a security solution poor because it's
not complete or perfect: it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used,
> It's not about default (for which backward compatibility is most
> important and this patch is perfectly fine), but user explicitly asks
> for "sharecache". In this case if for any reason the cache cannot be
> shared, I am not sure if he should get an error back.
>
> I for one agree with Ian
> On Fri, 2007-08-31 at 11:47 -0700, Hua Zhong wrote:
> > This patch fixes the problem for me, thanks.
> >
> > Is this patch changing the behavior of "sharecache" to
> > "try-to-share-cache-if-possible", or adding a third behavior? If the
> >
This patch fixes the problem for me, thanks.
Is this patch changing the behavior of "sharecache" to
"try-to-share-cache-if-possible", or adding a third behavior? If the user
explicitly asks for "-o sharecache", does he get an error back if the mount
options mismatch?
> The best I can do given
This patch fixes the problem for me, thanks.
Is this patch changing the behavior of sharecache to
try-to-share-cache-if-possible, or adding a third behavior? If the user
explicitly asks for -o sharecache, does he get an error back if the mount
options mismatch?
The best I can do given the
On Fri, 2007-08-31 at 11:47 -0700, Hua Zhong wrote:
This patch fixes the problem for me, thanks.
Is this patch changing the behavior of sharecache to
try-to-share-cache-if-possible, or adding a third behavior? If the
user explicitly asks for -o sharecache, does he get an error back
It's not about default (for which backward compatibility is most
important and this patch is perfectly fine), but user explicitly asks
for sharecache. In this case if for any reason the cache cannot be
shared, I am not sure if he should get an error back.
I for one agree with Ian and Linus
Trond,
> So you are saying that it is acceptable for the kernel to decide
> unilaterally to override mount options? Why aren't we doing that for
> any other filesystem than NFS?
I think there are two reasons.
First, I have no problem with the new behavior if it didn't cause a
regression. I am
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > No. Solaris defaults to breaking cache consistency.
>
> If so, and since that's obviously what people _expect_ to happen, why
> not make that the default, with the "consistent" behaviour being the
> one that needs an explicit option.
>
>
Hi Linus,
> Hua - that said, I don't actually see why the commit you bisected to
> has anything to do with the issue being discussed. Can you double-check
> that it's literally that particular commit that breaks for you (you could
> try just reverting that commit).
I will double check that
> How is the NFS client to know that these directories are disjoint, or
> that no-one will ever create a hard link from one directory to another?
> To my knowledge, the only way to ensure this is to put them on
> different disk partitions.
>
> I don't know if all Unix systems have this issue, but
> On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> > >
> > > Which is better than having it fail silently, or giving you a mount
> > > with the wrong mount options.
> >
> > Well, it depends on how you define "better".
>
> "be
Hi Trond,
> On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > I am re-sending this after help from Ian and git-bisect. To me it's a
> > show-stopper: I cannot find an acceptable workaround that I can
> > implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22 cause
t;
:04 04 675c84bd8b2c50744018becaa0db4aeca19b8f9f
105fbd3cb3fa5e3019836b4b5268125d0181a72d M fs
:04 04 0138796e0806b4ebd1cc3850ed4e8c7ab24d2d41
2fec08debe51c20423a88b1a0d4281c683ba5daf M include
-Original Message-----
From: Hua Zhong [mailto:[EMAIL PROTECTED]
Sent: Wednesday, Augus
675c84bd8b2c50744018becaa0db4aeca19b8f9f
105fbd3cb3fa5e3019836b4b5268125d0181a72d M fs
:04 04 0138796e0806b4ebd1cc3850ed4e8c7ab24d2d41
2fec08debe51c20423a88b1a0d4281c683ba5daf M include
-Original Message-
From: Hua Zhong [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 1:59 PM
Hi Trond,
On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
I am re-sending this after help from Ian and git-bisect. To me it's a
show-stopper: I cannot find an acceptable workaround that I can
implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes
several autofs mounts
On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
Which is better than having it fail silently, or giving you a mount
with the wrong mount options.
Well, it depends on how you define better.
better as in: I now have a chance to notice, when my 'read-only
mount' is actually
How is the NFS client to know that these directories are disjoint, or
that no-one will ever create a hard link from one directory to another?
To my knowledge, the only way to ensure this is to put them on
different disk partitions.
I don't know if all Unix systems have this issue, but I
Hi Linus,
Hua - that said, I don't actually see why the commit you bisected to
has anything to do with the issue being discussed. Can you double-check
that it's literally that particular commit that breaks for you (you could
try just reverting that commit).
I will double check that tomorrow.
On Fri, 31 Aug 2007, Trond Myklebust wrote:
No. Solaris defaults to breaking cache consistency.
If so, and since that's obviously what people _expect_ to happen, why
not make that the default, with the consistent behaviour being the
one that needs an explicit option.
Just out of
Trond,
So you are saying that it is acceptable for the kernel to decide
unilaterally to override mount options? Why aren't we doing that for
any other filesystem than NFS?
I think there are two reasons.
First, I have no problem with the new behavior if it didn't cause a
regression. I am not
. It's
something else.
It will still take me about 10 reboots to bisect. If anyone has a patch for
me to try, I'll give it a shot tomorrow.
> -Original Message-
> From: Ian Kent [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 29, 2007 8:00 PM
> To: Hua Zhong
> Cc: 'Linux
Hi,
I am wondering if this is a known issue, but I just built the current git
and several autofs mounts mysteriously disappeared. Restarting autofs could
fix some, but then lose others. 2.6.22 was fine.
Is there anything I could check other than bisect? (It may take some time
for me to get to
Hi,
I am wondering if this is a known issue, but I just built the current git
and several autofs mounts mysteriously disappeared. Restarting autofs could
fix some, but then lose others. 2.6.22 was fine.
Is there anything I could check other than bisect? (It may take some time
for me to get to
. It's
something else.
It will still take me about 10 reboots to bisect. If anyone has a patch for
me to try, I'll give it a shot tomorrow.
-Original Message-
From: Ian Kent [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 8:00 PM
To: Hua Zhong
Cc: 'Linux Kernel Mailing List
> > And, from a standpoint of ONGOING, long-term innovation: what matters
> > is that brilliant, new ideas get rewarded one way or another.
>
> and in this case, the reward is that the idea got used and credit was
> given
You mean, when Ingo announced CFS he mentioned Con's name?
I really
> Did Ingo have the obligation to improve Con's work? Definitely not.
> Did Con have a right to get Ingo's improvements or
> suggestions? Definitely not.
Yes, and that's where the inequality is.
Unless the maintainer does a really bad job or pisses off Linus,
anyone who wants to merge his code
Did Ingo have the obligation to improve Con's work? Definitely not.
Did Con have a right to get Ingo's improvements or
suggestions? Definitely not.
Yes, and that's where the inequality is.
Unless the maintainer does a really bad job or pisses off Linus,
anyone who wants to merge his code into
And, from a standpoint of ONGOING, long-term innovation: what matters
is that brilliant, new ideas get rewarded one way or another.
and in this case, the reward is that the idea got used and credit was
given
You mean, when Ingo announced CFS he mentioned Con's name?
I really doubt
The idea has not died and some NAS/file server vendors have already been
doing this for some time. (I am not sure but is WAFS the same thing?)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Linus Torvalds
> Sent: Friday, April 27,
The idea has not died and some NAS/file server vendors have already been
doing this for some time. (I am not sure but is WAFS the same thing?)
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-kernel-
[EMAIL PROTECTED] On Behalf Of Linus Torvalds
Sent: Friday, April 27, 2007
> In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
> the devices are off, but the motherboard and memory is powered.
>
> > And even 3W would still be a waste of energy.
>
> .. but if the alternative is a feature that just isn't worth it, and
> likely to not only have its
In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
the devices are off, but the motherboard and memory is powered.
And even 3W would still be a waste of energy.
.. but if the alternative is a feature that just isn't worth it, and
likely to not only have its own
> This whole notion that "kernel lines of code" is somehow different is a
> stupid and idiotic _disease_ that is spread by microkernel people and
> people who have been brainwashed by them.
I think a lot of people are tired of this argument, but I am glad you speak
up (as you did last year wrt
This whole notion that kernel lines of code is somehow different is a
stupid and idiotic _disease_ that is spread by microkernel people and
people who have been brainwashed by them.
I think a lot of people are tired of this argument, but I am glad you speak
up (as you did last year wrt s2ram).
> The other problem besides the inability to handle IO errors is that
> mmap()+msync() is synchronous. You need to go async to keep
> the pipelines full.
msync(addr, len, MS_ASYNC); doesn't do what you want?
> Now if someone wants to implement an aio version of msync and
> mlock, that might
The other problem besides the inability to handle IO errors is that
mmap()+msync() is synchronous. You need to go async to keep
the pipelines full.
msync(addr, len, MS_ASYNC); doesn't do what you want?
Now if someone wants to implement an aio version of msync and
mlock, that might do the
> > Here is a simple patch that does it.
>
> Looks more likely to work than Ken's - which I didn't try,
> but I couldn't see what magic prevented it from just going BUG.
>
> But I have to say, having seen the ensuing requests for this
> to impose the same constraints as other implementations
Here is a simple patch that does it.
Looks more likely to work than Ken's - which I didn't try,
but I couldn't see what magic prevented it from just going BUG.
But I have to say, having seen the ensuing requests for this
to impose the same constraints as other implementations of
flag so we could check O_DIRECT
support at a much earlier stage. Comments on how to fix it?
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
diff --git a/fs/open.c b/fs/open.c
index c989fb4..c03285f 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -708,11 +708,13 @@ static struct file *__dentry_open(
> --- Hua Zhong <[EMAIL PROTECTED]> wrote:
>
> > > Any strong reason why not? x has some value that does not
> > > make sense and can create only problems.
> >
> > By the same logic, you should memset the buffer to zero
> before freeing it too.
--- Hua Zhong [EMAIL PROTECTED] wrote:
Any strong reason why not? x has some value that does not
make sense and can create only problems.
By the same logic, you should memset the buffer to zero
before freeing it too.
How does this help?
It doesn't. I thought that was my
flag so we could check O_DIRECT
support at a much earlier stage. Comments on how to fix it?
Signed-off-by: Hua Zhong [EMAIL PROTECTED]
diff --git a/fs/open.c b/fs/open.c
index c989fb4..c03285f 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -708,11 +708,13 @@ static struct file *__dentry_open(struct
> Any strong reason why not? x has some value that does not
> make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
> And as I explained, it can result in longer code too. So, why
> keep this value around. Why not re-initialize
Any strong reason why not? x has some value that does not
make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it
> I see that as a good argument _not_ to allow O_DIRECT on
> tmpfs, which inevitably impacts cache, even if O_DIRECT were
> requested.
>
> But I'd also expect any app requesting O_DIRECT in that way,
> as a caring citizen, to fall back to going without O_DIRECT
> when it's not supported.
I see that as a good argument _not_ to allow O_DIRECT on
tmpfs, which inevitably impacts cache, even if O_DIRECT were
requested.
But I'd also expect any app requesting O_DIRECT in that way,
as a caring citizen, to fall back to going without O_DIRECT
when it's not supported.
According
I am wondering if we should define __likely/__unlikely macros no matter whether
CONFIG_LIKELY_PROFILE is defined, like the following. This way people can always
use the raw macros in case the debugging version causes problems.
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
--- linux-2.6/i
I am wondering if we should define __likely/__unlikely macros no matter whether
CONFIG_LIKELY_PROFILE is defined, like the following. This way people can always
use the raw macros in case the debugging version causes problems.
Signed-off-by: Hua Zhong [EMAIL PROTECTED]
--- linux-2.6/include
I'd suggest putting a Documentation/GPL-Symbols to explain this.
Then in the "tainted" message, have a pointer to that documentation.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Preece
> Sent: Thursday, December 14, 2006 11:43 AM
> To:
I'd suggest putting a Documentation/GPL-Symbols to explain this.
Then in the tainted message, have a pointer to that documentation.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Preece
Sent: Thursday, December 14, 2006 11:43 AM
To: Chris
> I think allowing binary hardware drivers in userspace hurts
> our ability to leverage companies to release hardware specs.
If filesystems can be in user space, why can't drivers be in user space? On
what *technical* ground?
-
To unsubscribe from this list: send the line "unsubscribe
I think allowing binary hardware drivers in userspace hurts
our ability to leverage companies to release hardware specs.
If filesystems can be in user space, why can't drivers be in user space? On
what *technical* ground?
-
To unsubscribe from this list: send the line unsubscribe
> On Thu, Nov 30, 2006 at 10:00:35PM -0800, Hua Zhong wrote:
>
> > I am curious, what's the point?
>
> Email addresses are for contacting people.
Do you go back and change all the signed-off lines too when people change jobs?
> > These email addresses serve a "h
I am curious, what's the point?
These email addresses serve a "historical" purpose: they tell when the
contribution was made, what the author's email addresses
were at that point.
It's not MAINTAINERS. If people want to contact someone, go find the latest
address there.
> -Original
I am curious, what's the point?
These email addresses serve a historical purpose: they tell when the
contribution was made, what the author's email addresses
were at that point.
It's not MAINTAINERS. If people want to contact someone, go find the latest
address there.
-Original
On Thu, Nov 30, 2006 at 10:00:35PM -0800, Hua Zhong wrote:
I am curious, what's the point?
Email addresses are for contacting people.
Do you go back and change all the signed-off lines too when people change jobs?
These email addresses serve a historical purpose: they tell
when
>takelock domainxxx lock1
>do sutff
>droplock domainxxx lock1
>
> When someone kills the shell, the lock is leaked, becuase droplock isn't
> called.
Why not open the lock resource (or the lock space) instead of
individual locks as file? It then looks like this:
open lock
takelock domainxxx lock1
do sutff
droplock domainxxx lock1
When someone kills the shell, the lock is leaked, becuase droplock isn't
called.
Why not open the lock resource (or the lock space) instead of
individual locks as file? It then looks like this:
open lock space
I just started looking at gfs. To understand it you'd need to look at it
from the entire cluster solution point of view.
This is a good document from David. It's not about GFS in particular but
about the architecture of the cluster.
http://people.redhat.com/~teigland/sca.pdf
Hua
>
I just started looking at gfs. To understand it you'd need to look at it
from the entire cluster solution point of view.
This is a good document from David. It's not about GFS in particular but
about the architecture of the cluster.
http://people.redhat.com/~teigland/sca.pdf
Hua
> Even with a GPL'd Linux Bitkeeper I'll bet half of the existing Linux
> paying customers will continue to use a paid version.
By what? How much do you plan to put down to pay Larry in case you lose your
bet?
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Even with a GPL'd Linux Bitkeeper I'll bet half of the existing Linux
paying customers will continue to use a paid version.
By what? How much do you plan to put down to pay Larry in case you lose your
bet?
Hua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
> int bt_sock_unregister(int proto)
> {
> - if (proto >= BT_MAX_PROTO)
> + if (proto < 0 || proto >= BT_MAX_PROTO)
> return -EINVAL;
Just curious: would it be better to say
if ((unsigned int)proto >= BT_MAX_PTORO)
?
Is it faster too?
Hua
-
To unsubscribe from this
int bt_sock_unregister(int proto)
{
- if (proto = BT_MAX_PROTO)
+ if (proto 0 || proto = BT_MAX_PROTO)
return -EINVAL;
Just curious: would it be better to say
if ((unsigned int)proto = BT_MAX_PTORO)
?
Is it faster too?
Hua
-
To unsubscribe from this list: send
> -fixup or -fixes maybe. x.y is OK too. :)
How about Service Pack?
:joke:
I could never understand why we have confused users in the naming in 2.6
serials and are trying to confuse them even more..
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
-fixup or -fixes maybe. x.y is OK too. :)
How about Service Pack?
:joke:
I could never understand why we have confused users in the naming in 2.6
serials and are trying to confuse them even more..
Hua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
> You cannot have it both ways. Either the kernel needs
> testers, or it is "stable". See how these are opposites?
I think one of the fundamental problems is "either the kernel needs more
features, or it needs stablization". You cannot have it both ways. With the
current model, the kernel
> In other words, I'm really talking about something different
> from what you seem to envision.
Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases
that
> it's a no-brainer.
Alan Cox once said he would like to do it:
> On Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
> When I said "nobody", I really meant "top kernel developers". I have
not
> seen anyone step up and say "I'll volunteer to maintain a 2.6 stab
You cannot have it both ways. Either the kernel needs
testers, or it is stable. See how these are opposites?
I think one of the fundamental problems is either the kernel needs more
features, or it needs stablization. You cannot have it both ways. With the
current model, the kernel develops
.
Alan Cox once said he would like to do it:
On Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
When I said nobody, I really meant top kernel developers. I have
not
seen anyone step up and say I'll volunteer to maintain a 2.6 stable
release hence the comment.
I'll do it if Linus
In other words, I'm really talking about something different
from what you seem to envision.
Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases
> And the reason it does _not_ work is that all the people we
> want testing sure as _hell_ won't be testing -rc versions.
At least they still test "real" releases..
So instead of making sure rc is really "release-candidate", we want to trick
people to test -pre as "real release", soon people
> I actually second Matt's request; -RCs à la 2.4.
>
> Then your above becomes:
> 2.6.x-rc: bugfixes only
> 2.6.x-pre: bugfixes and features
>
> And then that doesn't confuse end users either.
I'll jump in and third this. It looks the "honest" way. I know Linus is
always talking about "open
I actually second Matt's request; -RCs à la 2.4.
Then your above becomes:
2.6.x-rc: bugfixes only
2.6.x-pre: bugfixes and features
And then that doesn't confuse end users either.
I'll jump in and third this. It looks the honest way. I know Linus is
always talking about open source keeps
And the reason it does _not_ work is that all the people we
want testing sure as _hell_ won't be testing -rc versions.
At least they still test real releases..
So instead of making sure rc is really release-candidate, we want to trick
people to test -pre as real release, soon people will
> Linus has never worked on Unix in any form, and most of the
> other kernel hackers hasn't either. Ever.
Huh? I believe they have used Unix, as in the BitKeeper case. In neither
case they get access to the source code of the software they use, to make
the comparison equal.
Whether they used a
Linus has never worked on Unix in any form, and most of the
other kernel hackers hasn't either. Ever.
Huh? I believe they have used Unix, as in the BitKeeper case. In neither
case they get access to the source code of the software they use, to make
the comparison equal.
Whether they used a
-> From Alan Cox <[EMAIL PROTECTED]> :
> > (a) It does less, namely will not kill processes with uid 0.
> > Ted, any objections?
>
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
a setuid app only changes euid, doesn't it?
-
To
-> From "H. Peter Anvin" <[EMAIL PROTECTED]> :
> When I got Pac*Smell DSL, the installer guy (who seemed to be a
> relatively clueful type) said "and [the contract] says you're not
> allowed to run a server... but who'd know?"
..and please define "server". Does it mean that you can not run any
- From H. Peter Anvin [EMAIL PROTECTED] :
When I got Pac*Smell DSL, the installer guy (who seemed to be a
relatively clueful type) said and [the contract] says you're not
allowed to run a server... but who'd know?
..and please define server. Does it mean that you can not run any programs
- From Alan Cox [EMAIL PROTECTED] :
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
a setuid app only changes euid, doesn't it?
-
To unsubscribe from
-> From Kurt Maxwell Weber <[EMAIL PROTECTED]> :
>
> You can choose to work somewhere else, or choose to enter a different field.
There are a lot of people who don't know how to use Linux/Unix. Windows is
much easier for them and has more applications. They practically have no
other choice
Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode.
> >Olaf Hering wrote:
> >> kde.o. 2.5?
> >
> >Good idea! Graphics needs to be in the kernel to be fast. Windows
> >proved that.
>
> thought SGI proved that :-)
>
> Martin
> --
>
Is this (printing out versions. etc) really a big deal so we should add stuff
like "/proc/xxx", KERN_ to make things more complicated? It sounds to me
like to make the kernel "smaller" we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't
Is this (printing out versions. etc) really a big deal so we should add stuff
like /proc/xxx, KERN_ to make things more complicated? It sounds to me
like to make the kernel smaller we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't read
Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode.
Olaf Hering wrote:
kde.o. 2.5?
Good idea! Graphics needs to be in the kernel to be fast. Windows
proved that.
thought SGI proved that :-)
Martin
--
- From Kurt Maxwell Weber [EMAIL PROTECTED] :
You can choose to work somewhere else, or choose to enter a different field.
There are a lot of people who don't know how to use Linux/Unix. Windows is
much easier for them and has more applications. They practically have no
other choice if
> Do linux even support the sticky bit (t) I can't see a reason to use it, why would I
>want the file to be stored in the swap ??
For files I think it was used in days when there was no VM, so that you could
hint the system to put frequently used executables always in memory (like vi,
sh,
Do linux even support the sticky bit (t) I can't see a reason to use it, why would I
want the file to be stored in the swap ??
For files I think it was used in days when there was no VM, so that you could
hint the system to put frequently used executables always in memory (like vi,
sh,
> So really you want an outside GUI tool that lets you reconfigure build and
> install kernels. Yeah I'd agree with that. Someone just needs to write the
> killer gnome/kde config tool. I've got C code for parsing/loading config.in
> files and deducing the dependancy constraints if anyone ever
So really you want an outside GUI tool that lets you reconfigure build and
install kernels. Yeah I'd agree with that. Someone just needs to write the
killer gnome/kde config tool. I've got C code for parsing/loading config.in
files and deducing the dependancy constraints if anyone ever wants
have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
>
Hua Zhong
Central Research Facilities Department of Computer S
]
Hua Zhong
Central Research Facilities Department of Computer Science
Columbia University New York, NY 10027
Email: [EMAIL PROTECTED] http://www.cs.columbia.edu/~huaz
1 - 100 of 104 matches
Mail list logo
