In article <[EMAIL PROTECTED]> you wrote:
> Just to clarify, I had about 60 days of uptime, and hence at least
> 60 days since the last FS check/mount/etc., when Linux crashed those
> few days ago, and wanted to start checking disks with "9192 days since
> last file system check".
This, however
In article [EMAIL PROTECTED] you wrote:
Just to clarify, I had about 60 days of uptime, and hence at least
60 days since the last FS check/mount/etc., when Linux crashed those
few days ago, and wanted to start checking disks with 9192 days since
last file system check.
This, however sounds
In article <[EMAIL PROTECTED]> you wrote:
> Make kernel configuration option? (e.g. disable "over commit"
> mis-feature :-)
# egrep . /proc/sys/vm/overcommit_*
/proc/sys/vm/overcommit_memory:0
/proc/sys/vm/overcommit_ratio:50
Gruss
Bernd
-
To unsubscribe from this list: send the line
In article [EMAIL PROTECTED] you wrote:
Make kernel configuration option? (e.g. disable over commit
mis-feature :-)
# egrep . /proc/sys/vm/overcommit_*
/proc/sys/vm/overcommit_memory:0
/proc/sys/vm/overcommit_ratio:50
Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe
In article <[EMAIL PROTECTED]> you wrote:
> it doesn't add value memset with a constant 0 is just as fast
> (since the compiler knows it's 0) than any wrapper around it, and the
> syntax around it is otherwise the same.
it would however allow easier changing if you need to add a page cleaning
In article <[EMAIL PROTECTED]> you wrote:
> 1. This design stretches the POSIX timers API in strange
> ways.
Maybe it is possible to reimplement the POSIX API in usermode using the
kernel's FD implementation? (and drop the posix support from kernel)
Gruss
Bernd
-
To unsubscribe from this
In article [EMAIL PROTECTED] you wrote:
1. This design stretches the POSIX timers API in strange
ways.
Maybe it is possible to reimplement the POSIX API in usermode using the
kernel's FD implementation? (and drop the posix support from kernel)
Gruss
Bernd
-
To unsubscribe from this list:
In article [EMAIL PROTECTED] you wrote:
it doesn't add value memset with a constant 0 is just as fast
(since the compiler knows it's 0) than any wrapper around it, and the
syntax around it is otherwise the same.
it would however allow easier changing if you need to add a page cleaning
In article <[EMAIL PROTECTED]> you wrote:
> What's the deal with the underscore and the parentheses surrounding the
> call to menu_get_help?
it is a macro from gettext, used to translate the string. Usually this
should only be used on string constants.
Gruss
Bernd
-
To unsubscribe from this
In article [EMAIL PROTECTED] you wrote:
What's the deal with the underscore and the parentheses surrounding the
call to menu_get_help?
it is a macro from gettext, used to translate the string. Usually this
should only be used on string constants.
Gruss
Bernd
-
To unsubscribe from this list:
In article <[EMAIL PROTECTED]> you wrote:
> So you can't draw any relationships between "Protect the end-user"
> with "Protect the device FROM the end-user", the former can be done
> very reliably to whatever level of risk-reduction you need and the
> latter can't practically be done at all.
In article [EMAIL PROTECTED] you wrote:
So you can't draw any relationships between Protect the end-user
with Protect the device FROM the end-user, the former can be done
very reliably to whatever level of risk-reduction you need and the
latter can't practically be done at all.
Unless
In article <[EMAIL PROTECTED]> you wrote:
> I found that O_NOFOLLOW is used for opened core file in Linux 2.6.10.
I think that is for security reasons, otherwise one has to (atomically)
check who is the owner of the symlink and where it points to. If you dont
have hostile users on your system
In article [EMAIL PROTECTED] you wrote:
I found that O_NOFOLLOW is used for opened core file in Linux 2.6.10.
I think that is for security reasons, otherwise one has to (atomically)
check who is the owner of the symlink and where it points to. If you dont
have hostile users on your system you
In article <[EMAIL PROTECTED]> you wrote:
> All of the posts fail to address the question here: what is the
> correct file system, or does one exist yet, for wear leveling flash
> storage. JFFS2 and logfs are nice for MTD, but for better flash
> memories that are likely to be used in the future
In article [EMAIL PROTECTED] you wrote:
All of the posts fail to address the question here: what is the
correct file system, or does one exist yet, for wear leveling flash
storage. JFFS2 and logfs are nice for MTD, but for better flash
memories that are likely to be used in the future like
In article <[EMAIL PROTECTED]> you wrote:
> In short, I'm distributing logs in realtime for about 600,000
> websites. The sources of the logs (http, ftp, realmedia, etc) are
> flexible, however the base framework was build around a large cluster
> of webservers. The output can be to several
In article <[EMAIL PROTECTED]> you wrote:
> (ps. having come from the socket side of the fence, its incredibly
> frustrating to be unable to poll() or epoll regular file FDs --
> Especially knowing that the kernel is translating them into a TCP
> socket to do NFS anyway. Please add regular files
In article [EMAIL PROTECTED] you wrote:
(ps. having come from the socket side of the fence, its incredibly
frustrating to be unable to poll() or epoll regular file FDs --
Especially knowing that the kernel is translating them into a TCP
socket to do NFS anyway. Please add regular files to
In article [EMAIL PROTECTED] you wrote:
In short, I'm distributing logs in realtime for about 600,000
websites. The sources of the logs (http, ftp, realmedia, etc) are
flexible, however the base framework was build around a large cluster
of webservers. The output can be to several hundred
On Fri, May 25, 2007 at 11:24:46AM -0500, Scott Preece wrote:
> However, it might be phrased more diplomatically in this context, like
> "because you are sacrificing time that could be spent adding features,
> to fix somebody else's mistakes".
Not all Bugs are mistakes of the coder. I still think
On Fri, May 25, 2007 at 11:24:46AM -0500, Scott Preece wrote:
However, it might be phrased more diplomatically in this context, like
because you are sacrificing time that could be spent adding features,
to fix somebody else's mistakes.
Not all Bugs are mistakes of the coder. I still think it
In article <[EMAIL PROTECTED]> you wrote:
> I tried to make it clear that I am clearly lacking expertise in this
> topic. I am currently working on a somewhat related topic and was hoping
> to get some reactions that would point me in the right directions as it
> is somewhat hard to judge the VFS
In article <[EMAIL PROTECTED]> you wrote:
> 500 8 6 1 2 5 4 9 - r w - r - - r
>3638 3231 3435 2039 722d 2d77 2d72 722d
> 520 - - 1 r o o t r o o t
>2d2d 3120 7220 6f6f 2074 6f72 746f 2020
> 540
In article <[EMAIL PROTECTED]> you wrote:
> -rw-r--r-- 1 root root 0 2007-05-06 12:41
>
> the last line is very interesting, this file has no name and the size is 0
> byte.
Well, 0 byte files are nothing special, and the name: it might be a
non-printable char?
> touch ' '
will produce a
In article <[EMAIL PROTECTED]> you wrote:
> From now I'll use Intel recomendation to run their utility to resolve all
> questions.
You mean this, right?
http://www.intel.com/support/processors/sb/cs-001632.htm
Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe
In article <[EMAIL PROTECTED]> you wrote:
> To authors of /proc/cpuinfo:
>
> Plz, fix stepping identification:
It might be a bug in the kernel code, however it is pretty unlikely: It just
reads what the CPU reports. You have an odd chip, nothing what the kernel
can do about. I see "family 15,
In article [EMAIL PROTECTED] you wrote:
To authors of /proc/cpuinfo:
Plz, fix stepping identification:
It might be a bug in the kernel code, however it is pretty unlikely: It just
reads what the CPU reports. You have an odd chip, nothing what the kernel
can do about. I see family 15, model 2,
In article [EMAIL PROTECTED] you wrote:
From now I'll use Intel recomendation to run their utility to resolve all
questions.
You mean this, right?
http://www.intel.com/support/processors/sb/cs-001632.htm
Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
In article [EMAIL PROTECTED] you wrote:
-rw-r--r-- 1 root root 0 2007-05-06 12:41
the last line is very interesting, this file has no name and the size is 0
byte.
Well, 0 byte files are nothing special, and the name: it might be a
non-printable char?
touch ' '
will produce a
In article [EMAIL PROTECTED] you wrote:
500 8 6 1 2 5 4 9 - r w - r - - r
3638 3231 3435 2039 722d 2d77 2d72 722d
520 - - 1 r o o t r o o t
2d2d 3120 7220 6f6f 2074 6f72 746f 2020
540
In article [EMAIL PROTECTED] you wrote:
I tried to make it clear that I am clearly lacking expertise in this
topic. I am currently working on a somewhat related topic and was hoping
to get some reactions that would point me in the right directions as it
is somewhat hard to judge the VFS design
In article <[EMAIL PROTECTED]> you wrote:
> I found one more interesting thing related with fork
> bombing attack. i have set following in /etc/security/limits.conf file
>
> [EMAIL PROTECTED]hard nproc 3000
> [EMAIL PROTECTED] hard nproc 500
The # is a comment
In article <[EMAIL PROTECTED]> you wrote:
> Am I right that is chipset on mainboard, who is saying - "I know", not
> CPU itself?
It is a feature bitfield read directly from the CPU.
> Is it better to switch off HT support in BIOS?
The CPU will still report that flag. Might speed up the
On Fri, May 18, 2007 at 12:07:09PM -0700, Siddha, Suresh B wrote:
> On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
> > IIRC, the HT flag is also reported for multicore CPUs.
>
> Yes. Thats correct.
And for some Single-Core Non-HT CPUs.
Gruss
Bernd
--
(OO) -- [EMAIL
In article <[EMAIL PROTECTED]> you wrote:
> I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
> everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
> that it has no HT feature, nor Windows XP identify it as HT.
the ht flag reported by the CPU and cpuinfo
In article <[EMAIL PROTECTED]> you wrote:
>> bugs is one of the best ways to get merits among other developers, because
>> not many people like wasting time fixing other people's bugs.
> ^^^
>
> you might want to find a less demeaning term for debugging than
>
In article <[EMAIL PROTECTED]> you wrote:
> + printk(KERN_INFO
> + "out of virtual memory for process %d (%s): total_vm=%lu,
> uid=%d\n",
> + current->pid, current->comm, total_vm, current->uid);
And align this one with the print_fatal layout:
In article <[EMAIL PROTECTED]> you wrote:
>printk("%s/%d: potentially unexpected fatal signal %d.\n",
>current->comm, current->pid, signr);
can we have both KERN_WARNING please?
Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
In article [EMAIL PROTECTED] you wrote:
+ printk(KERN_INFO
+ out of virtual memory for process %d (%s): total_vm=%lu,
uid=%d\n,
+ current-pid, current-comm, total_vm, current-uid);
And align this one with the print_fatal layout:
printk(KERN_WARNING
In article [EMAIL PROTECTED] you wrote:
printk(%s/%d: potentially unexpected fatal signal %d.\n,
current-comm, current-pid, signr);
can we have both KERN_WARNING please?
Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
In article [EMAIL PROTECTED] you wrote:
bugs is one of the best ways to get merits among other developers, because
not many people like wasting time fixing other people's bugs.
^^^
you might want to find a less demeaning term for debugging than
wasting time.
In article [EMAIL PROTECTED] you wrote:
I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
that it has no HT feature, nor Windows XP identify it as HT.
the ht flag reported by the CPU and cpuinfo is
On Fri, May 18, 2007 at 12:07:09PM -0700, Siddha, Suresh B wrote:
On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
IIRC, the HT flag is also reported for multicore CPUs.
Yes. Thats correct.
And for some Single-Core Non-HT CPUs.
Gruss
Bernd
--
(OO) -- [EMAIL PROTECTED]
In article [EMAIL PROTECTED] you wrote:
Am I right that is chipset on mainboard, who is saying - I know, not
CPU itself?
It is a feature bitfield read directly from the CPU.
Is it better to switch off HT support in BIOS?
The CPU will still report that flag. Might speed up the boot, not
In article [EMAIL PROTECTED] you wrote:
I found one more interesting thing related with fork
bombing attack. i have set following in /etc/security/limits.conf file
[EMAIL PROTECTED]hard nproc 3000
[EMAIL PROTECTED] hard nproc 500
The # is a comment character. So
In article <[EMAIL PROTECTED]> you wrote:
> in short, do *not* remove its "deprecated" status. rather, remove its
> "obsolete" status and *make* it deprecated.
it is deprecated and obsolete.
Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
In article [EMAIL PROTECTED] you wrote:
in short, do *not* remove its deprecated status. rather, remove its
obsolete status and *make* it deprecated.
it is deprecated and obsolete.
Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
In article <[EMAIL PROTECTED]> you wrote:
> However, there are a large number of applications which have registered
> ports in this range.
And some application who request random listening ports actually query the
/etc/services file to ensure it is a "unnamed" port.
Gruss
Bernd
-
To unsubscribe
In article <[EMAIL PROTECTED]> you wrote:
> +Consider a typical block of kernel code:
> +
> +spin_lock(_lock);
> +do_something_on(_data);
> +do_something_else_with(_data);
> +spin_unlock(_lock);
> +
> +If all the code follows the locking rules, the value of shared_data cannot
>
In article [EMAIL PROTECTED] you wrote:
+Consider a typical block of kernel code:
+
+spin_lock(the_lock);
+do_something_on(shared_data);
+do_something_else_with(shared_data);
+spin_unlock(the_lock);
+
+If all the code follows the locking rules, the value of shared_data
In article [EMAIL PROTECTED] you wrote:
However, there are a large number of applications which have registered
ports in this range.
And some application who request random listening ports actually query the
/etc/services file to ensure it is a unnamed port.
Gruss
Bernd
-
To unsubscribe from
In article <[EMAIL PROTECTED]> you wrote:
> For this particular case, Ted is probably right and the only place
> we'll ever see this insane poor man's pre-allocate pattern is from the
> Windows CIFS client, in which case fixing this in Samba makes sense -
> although I'm a bit horrified by the idea
In article [EMAIL PROTECTED] you wrote:
For this particular case, Ted is probably right and the only place
we'll ever see this insane poor man's pre-allocate pattern is from the
Windows CIFS client, in which case fixing this in Samba makes sense -
although I'm a bit horrified by the idea of
In article <[EMAIL PROTECTED]> you wrote:
> You can't have it even do a search to see if it already has something similar
> without creating an account and logging in. Since I'm out of wall space, and
> the missus is bugging me to paint over all that, I left.
Well, thats not a bugzilla
In article <[EMAIL PROTECTED]> you wrote:
> If it is considered useful it shouldn't be a problem to automatically
> forward all incoming Bugzilla bugs to linux-kernel.
Yes, most of it to linux-kernel, some components (netdev@, architecture) to
a more specific list.
Gruss
Bernd
-
To unsubscribe
In article [EMAIL PROTECTED] you wrote:
You can't have it even do a search to see if it already has something similar
without creating an account and logging in. Since I'm out of wall space, and
the missus is bugging me to paint over all that, I left.
Well, thats not a bugzilla problem.
In article [EMAIL PROTECTED] you wrote:
If it is considered useful it shouldn't be a problem to automatically
forward all incoming Bugzilla bugs to linux-kernel.
Yes, most of it to linux-kernel, some components (netdev@, architecture) to
a more specific list.
Gruss
Bernd
-
To unsubscribe from
In article <[EMAIL PROTECTED]> you wrote:
> a) it may do so for a short and bound time, typically less than the
> maximum acceptable latency for other tasks
if you have n threads in runq and each of them can have mhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at
In article [EMAIL PROTECTED] you wrote:
a) it may do so for a short and bound time, typically less than the
maximum acceptable latency for other tasks
if you have n threads in runq and each of them can have md (d=max latency
deadline) overhead, you will have to account on d/n slices. This
In article <[EMAIL PROTECTED]> you wrote:
> Could you explain for the audience the technical definition of fairness
> and what sorts of error metrics are commonly used? There seems to be
> some disagreement, and you're neutral enough of an observer that your
> statement would help.
And while we
In article [EMAIL PROTECTED] you wrote:
Could you explain for the audience the technical definition of fairness
and what sorts of error metrics are commonly used? There seems to be
some disagreement, and you're neutral enough of an observer that your
statement would help.
And while we are at
In article <[EMAIL PROTECTED]> you wrote:
> Perhaps -- until your httpd is compromised via a buffer overflow or
> simply misbehaves due to a software or configuration flaw, then the
> assumptions being made about its use of pathnames and their security
> properties are out the window.
Hu? Even
In article <[EMAIL PROTECTED]> you wrote:
> Top (VCPU maybe?)
>User
>Process
>Thread
The problem with that is, that not all Schedulers might work on the User
level. You can think of Batch/Job, Parent, Group, Session or namespace
level. That would be IMHO a generic Top,
In article [EMAIL PROTECTED] you wrote:
Top (VCPU maybe?)
User
Process
Thread
The problem with that is, that not all Schedulers might work on the User
level. You can think of Batch/Job, Parent, Group, Session or namespace
level. That would be IMHO a generic Top, with no
In article [EMAIL PROTECTED] you wrote:
Perhaps -- until your httpd is compromised via a buffer overflow or
simply misbehaves due to a software or configuration flaw, then the
assumptions being made about its use of pathnames and their security
properties are out the window.
Hu? Even a
In article <[EMAIL PROTECTED]> you wrote:
>> Unfortunatelle Latency is critical for a number of critical applications
>> like databases or file based transaction systems (mail, news) - mainly the
>> users of fsync().
>
> Whether you mix audio in userspace or kernel does not impact latency -
> you
In article <[EMAIL PROTECTED]> you wrote:
> I meant that the central requirement on the design and implementation of
> audio subsystems is an (ideally guaranteed) bounded maximum of
> latencies; and that's exactly the major point where I heard that there
> are problems with ALSA driver components
In article [EMAIL PROTECTED] you wrote:
I meant that the central requirement on the design and implementation of
audio subsystems is an (ideally guaranteed) bounded maximum of
latencies; and that's exactly the major point where I heard that there
are problems with ALSA driver components in
In article [EMAIL PROTECTED] you wrote:
Unfortunatelle Latency is critical for a number of critical applications
like databases or file based transaction systems (mail, news) - mainly the
users of fsync().
Whether you mix audio in userspace or kernel does not impact latency -
you still need
In article <[EMAIL PROTECTED]> you wrote:
> A development process like this is likely to exclude smart people from wanting
> to contribute to Linux and folks should be conscious about this issues.
Nobody is excluded, you can always have a next iteration.
Gruss
Bernd
-
To unsubscribe from this
In article [EMAIL PROTECTED] you wrote:
A development process like this is likely to exclude smart people from wanting
to contribute to Linux and folks should be conscious about this issues.
Nobody is excluded, you can always have a next iteration.
Gruss
Bernd
-
To unsubscribe from this list:
In article <[EMAIL PROTECTED]> you wrote:
> Otherwise, the client would have to cache _all_ previous READDIR results
> since the last opendir()/rewinddir() in order to be able to do its own
> loop detection and that will obviously never scale for large directories
> or for directories that change
In article [EMAIL PROTECTED] you wrote:
Otherwise, the client would have to cache _all_ previous READDIR results
since the last opendir()/rewinddir() in order to be able to do its own
loop detection and that will obviously never scale for large directories
or for directories that change
In article <[EMAIL PROTECTED]> you wrote:
> 2) Output of "yes --help" from the same terminal
Question: what do you expect?
#> yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for
In article [EMAIL PROTECTED] you wrote:
2) Output of yes --help from the same terminal
Question: what do you expect?
# yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for copying
In article <[EMAIL PROTECTED]> you wrote:
> However, when the system comes up and attempt to do an ifconfig, the
> 'ethN' numbers
> have changed to a some what intermengled seriese starting with eth6...
> eth10.
maybe a system startup script is renaming them (in order to give them well
known
In article [EMAIL PROTECTED] you wrote:
However, when the system comes up and attempt to do an ifconfig, the
'ethN' numbers
have changed to a some what intermengled seriese starting with eth6...
eth10.
maybe a system startup script is renaming them (in order to give them well
known
In article <[EMAIL PROTECTED]> you wrote:
> once your program (and many others) have such a check, then the next
> step will be pressure on the kernel code to "fake" the old situation
> when there is a processor where no longer
> holds. It's basically a road to madness :-(
I agree that for HPC
In article [EMAIL PROTECTED] you wrote:
once your program (and many others) have such a check, then the next
step will be pressure on the kernel code to fake the old situation
when there is a processor where vague criteria of the day no longer
holds. It's basically a road to madness :-(
I
In article <[EMAIL PROTECTED]> you wrote:
> I've Googled on this enough to find out that these are Linux threads,
> that "ps -m" will show them, that "ls -a /proc" will show /proc/.PPID,
> etc, but I'm still wondering what exact sequence of system calls will
> create a process like this?
clone(2)
In article <[EMAIL PROTECTED]> you wrote:
> i check the packets with an analyser and make some test. if i disable ecn
> with "echo 0x0 > /proc/sys/net/ipv4/tcp_ecn" it works, with ecn enabled, it
> don't work.
this is a problem on the remote site (old firewall software), nothing we
(linux
In article [EMAIL PROTECTED] you wrote:
i check the packets with an analyser and make some test. if i disable ecn
with echo 0x0 /proc/sys/net/ipv4/tcp_ecn it works, with ecn enabled, it
don't work.
this is a problem on the remote site (old firewall software), nothing we
(linux kernel) can
In article [EMAIL PROTECTED] you wrote:
I've Googled on this enough to find out that these are Linux threads,
that ps -m will show them, that ls -a /proc will show /proc/.PPID,
etc, but I'm still wondering what exact sequence of system calls will
create a process like this?
clone(2) can be
In article <[EMAIL PROTECTED]> you wrote:
> Was this post just not interesting enough, or is it the lack of access to
> hardware
> to test this on that prevented it from being picked up by someone?
see google, for example: http://christophe.varoqui.free.fr/multipath.html
Gruss
Bernd
-
To
In article [EMAIL PROTECTED] you wrote:
Was this post just not interesting enough, or is it the lack of access to
hardware
to test this on that prevented it from being picked up by someone?
see google, for example: http://christophe.varoqui.free.fr/multipath.html
Gruss
Bernd
-
To unsubscribe
On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
> That is the whole point why OCFS exists ;-)
The whole point of the orcacle cluster filesystem as it was described in old
papers was about pfiles, control files and software, because you can easyly
use direct block access (with
On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
> Non GPL modules are required not to be derivative works (a term of law).
> The EXPORT_SYMBOL information is merely advisory to help seperate
> symbols. In many cases its purely historical as to whether a symbol is
> marked _GPL or not.
On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
Non GPL modules are required not to be derivative works (a term of law).
The EXPORT_SYMBOL information is merely advisory to help seperate
symbols. In many cases its purely historical as to whether a symbol is
marked _GPL or not.
Yes,
On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
That is the whole point why OCFS exists ;-)
The whole point of the orcacle cluster filesystem as it was described in old
papers was about pfiles, control files and software, because you can easyly
use direct block access (with
In article <[EMAIL PROTECTED]> you wrote:
>> The Linux kernel allows binary drivers, you just have to live with a limited
>> number of exported symbols and that the kernel is tainted. Which basically
>> means nobody sane can help you with corrupted kernel data structures.
>
> You appear to be
In article <[EMAIL PROTECTED]> you wrote:
> for ocfs we have tons of production customers running many terabyte
> databases on a cfs. why ? because dealing with the raw disk froma number
> of nodes sucks. because nfs is pretty broken for a lot of stuff, there
> is no consistency across nodes when
In article [EMAIL PROTECTED] you wrote:
for ocfs we have tons of production customers running many terabyte
databases on a cfs. why ? because dealing with the raw disk froma number
of nodes sucks. because nfs is pretty broken for a lot of stuff, there
is no consistency across nodes when each
In article [EMAIL PROTECTED] you wrote:
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is tainted. Which basically
means nobody sane can help you with corrupted kernel data structures.
You appear to be confused. The
In article <[EMAIL PROTECTED]> you wrote:
> I disagree with the language and the characterization that our
> proprietary user application code is "tainted."
The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary
In article <[EMAIL PROTECTED]> you wrote:
> I mean, nvidia people also use propietary code in the kernel (probably
> violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is
In article [EMAIL PROTECTED] you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is
In article [EMAIL PROTECTED] you wrote:
I disagree with the language and the characterization that our
proprietary user application code is tainted.
The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary only
In article <[EMAIL PROTECTED]> you wrote:
> No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed
> on new machines, and cpufreq is usefull to keep your desktop cold,
> too.
And with the recent ongoing packing of CPU cores into racks, it is even more
so important for Servers.
In article [EMAIL PROTECTED] you wrote:
No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed
on new machines, and cpufreq is usefull to keep your desktop cold,
too.
And with the recent ongoing packing of CPU cores into racks, it is even more
so important for Servers.
Gruss
1 - 100 of 290 matches
Mail list logo
