Someone may wish to change the description of the Compaq Array
Controllers under Block Devices to "HP" based controllers
for the HP appliances. It's rather confusing and inaccurate since
Compaq has not existed for several years now. The controllers
come up and identify themselves as "HP
Someone may wish to change the description of the Compaq Array
Controllers under Block Devices to HP based controllers
for the HP appliances. It's rather confusing and inaccurate since
Compaq has not existed for several years now. The controllers
come up and identify themselves as HP
BUG: using smp_processor_id() in preemptible [0001] code:
kondemand/0/2473
caller is centrino_target+0xfb/0x600
[<401e3646>] debug_smp_processor_id+0x9e/0xb0
[<40112afb>] centrino_target+0xfb/0x600
[<40112a00>] centrino_target+0x0/0x600
[<40305bd9>] __cpufreq_driver_target+0x5c/0x6b
[]
BUG: using smp_processor_id() in preemptible [0001] code:
kondemand/0/2473
caller is centrino_target+0xfb/0x600
[401e3646] debug_smp_processor_id+0x9e/0xb0
[40112afb] centrino_target+0xfb/0x600
[40112a00] centrino_target+0x0/0x600
[40305bd9] __cpufreq_driver_target+0x5c/0x6b
[f897a537]
Kok, Auke wrote:
Jeff V. Merkey wrote:
Kok, Auke wrote:
Jeff V. Merkey wrote:
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro
Kok, Auke wrote:
Jeff V. Merkey wrote:
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro "INIT_WORK"
passed 3 arguments,
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro "INIT_WORK" passed
3 arguments, but takes just 2
ared (first use in this function)
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro INIT_WORK passed
3 arguments, but takes just 2
ared (first use in this function)
Kok, Auke wrote:
Jeff V. Merkey wrote:
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro INIT_WORK
passed 3 arguments, but takes
Kok, Auke wrote:
Jeff V. Merkey wrote:
Kok, Auke wrote:
Jeff V. Merkey wrote:
CC [M] drivers/net/chelsio/mv88x201x.o
CC [M] drivers/net/chelsio/my3126.o
LD [M] drivers/net/chelsio/cxgb.o
CC drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro
Eric,
Please find attached the APIC code I used in Gadugi. It's code for plain
vanilla APICs, but does just this. This code not only allows
interrupts to be migrated, but processors to be stopped and restarted on
the fly without system interruption. You may find some useful
ideas in it.
Here's the include file that goes with it.
Jeff
#include "types.h"
#include "emit.h"
#define _82489APIC_MASK 0x00F0
#define APIC_IO_REG 0x
#define APIC_IO_DATA 0x0004
// APIC registers are 128 bit aligned. accesses are offset * 4
#define APIC_TASKPRI (4 * 0x0008)
Eric W. Biederman wrote:
** Conclusions.
*IRQs must be reprogramed in interrupt context.
The result of this is investigation is that I am convinced we need
to perform the irq migration activities in interrupt context although
I am not convinced it is completely safe. I suspect multiple
Eric W. Biederman wrote:
** Conclusions.
*IRQs must be reprogramed in interrupt context.
The result of this is investigation is that I am convinced we need
to perform the irq migration activities in interrupt context although
I am not convinced it is completely safe. I suspect multiple
Here's the include file that goes with it.
Jeff
#include types.h
#include emit.h
#define _82489APIC_MASK 0x00F0
#define APIC_IO_REG 0x
#define APIC_IO_DATA 0x0004
// APIC registers are 128 bit aligned. accesses are offset * 4
#define APIC_TASKPRI (4 * 0x0008)
#define
Eric,
Please find attached the APIC code I used in Gadugi. It's code for plain
vanilla APICs, but does just this. This code not only allows
interrupts to be migrated, but processors to be stopped and restarted on
the fly without system interruption. You may find some useful
ideas in it.
Jeff Garzik wrote:
Great offer to folks for drivers, but it sends a mixed message. OSDL
should offer to host a page somewhere to coordinate all of this.
:-)
Jeff
Roland Dreier wrote:
Just look at the in-tree drivers: there are tons of them that don't
work on big-endian platforms, or
Jeff Garzik wrote:
Great offer to folks for drivers, but it sends a mixed message. OSDL
should offer to host a page somewhere to coordinate all of this.
:-)
Jeff
Roland Dreier wrote:
Just look at the in-tree drivers: there are tons of them that don't
work on big-endian platforms, or
Lennart Sorensen wrote:
On Wed, Jan 10, 2007 at 06:29:28PM +0100, Prakash Punnoor wrote:
You can install the Intel Matrix driver after "adjusting" the inf file...
Hmm, I guess a good question is: Why should I have to edit the inf file?
Is it an issue of them making it only install if
Lennart Sorensen wrote:
On Wed, Jan 10, 2007 at 06:29:28PM +0100, Prakash Punnoor wrote:
You can install the Intel Matrix driver after adjusting the inf file...
Hmm, I guess a good question is: Why should I have to edit the inf file?
Is it an issue of them making it only install if
Jeff Garzik wrote:
Jeff V. Merkey wrote:
Jeff Garzik wrote:
Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a
Shuttle motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Lennart Sorensen wrote:
On Tue, Jan 09, 2007 at 01:46:42PM -0700, Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Jeff Garzik wrote:
Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked for about 30 seconds before liquifying
Auke Kok wrote:
Jeff V. Merkey wrote:
Jeff V. Merkey wrote:
root=/dev/hda2 is what was passed to the kernel from grub.
Jeff
I just finished pulling out a melted IDE flash drive out of a
Shuttle motherboard with the intel 945 chipset which claims to support
SATA and IDE drives
Jeff V. Merkey wrote:
root=/dev/hda2 is what was passed to the kernel from grub.
Jeff
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Sergey Vlasov wrote:
Yep.
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked for about 30 seconds before liquifying in the chassis.
I note that the 945 chipset in the
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked for about 30 seconds before liquifying in the chassis.
I note that the 945 chipset in the
Sergey Vlasov wrote:
Yep.
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0
Jeff V. Merkey wrote:
root=/dev/hda2 is what was passed to the kernel from grub.
Jeff
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Auke Kok wrote:
Jeff V. Merkey wrote:
Jeff V. Merkey wrote:
root=/dev/hda2 is what was passed to the kernel from grub.
Jeff
I just finished pulling out a melted IDE flash drive out of a
Shuttle motherboard with the intel 945 chipset which claims to support
SATA and IDE drives
Jeff Garzik wrote:
Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked for about 30 seconds before liquifying
Lennart Sorensen wrote:
On Tue, Jan 09, 2007 at 01:46:42PM -0700, Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a Shuttle
motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Jeff Garzik wrote:
Jeff V. Merkey wrote:
Jeff Garzik wrote:
Jeff V. Merkey wrote:
I just finished pulling out a melted IDE flash drive out of a
Shuttle motherboard with the intel 945 chipset which claims to support
SATA and IDE drives concurrently under Linux 2.6.18.
The chip worked
Linus Torvalds wrote:
On Mon, 18 Dec 2006, Alexandre Oliva wrote:
In other words, in the GPL, "Program" does NOT mean "binary". Never has.
Agreed. So what? How does this relate with the point above?
The binary is a Program, as much as the sources are a Program. Both
forms are
Eric W. Biederman wrote:
Things we can say without being hypocrites and without getting into
legal theory:
Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.
??
Please don't be rude.
???
J
Eric
-
To unsubscribe from
Eric W. Biederman wrote:
Things we can say without being hypocrites and without getting into
legal theory:
Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.
??
Please don't be rude.
???
J
Eric
-
To unsubscribe from
Linus Torvalds wrote:
On Mon, 18 Dec 2006, Alexandre Oliva wrote:
In other words, in the GPL, Program does NOT mean binary. Never has.
Agreed. So what? How does this relate with the point above?
The binary is a Program, as much as the sources are a Program. Both
forms are
Jeff V. Merkey wrote:
Corrected URL.
http://sourceforge.net/projects/data-echo
Jeff
We have open sourced this project for our Linux based appliances and
file systems. Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.
The program supports
all native
We have open sourced this project for our Linux based appliances and
file systems. Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.
The program supports
all native Linux forensics applications and formats. The program
reconsutructs web session and
email,
We have open sourced this project for our Linux based appliances and
file systems. Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.
The program supports
all native Linux forensics applications and formats. The program
reconsutructs web session and
email,
Jeff V. Merkey wrote:
Corrected URL.
http://sourceforge.net/projects/data-echo
Jeff
We have open sourced this project for our Linux based appliances and
file systems. Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.
The program supports
all native
/etc/init.d/rcS script execution fails with busybox on 2.6.18. Seems
ldlinux.so related.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
This whole effort is pointless. This is the same kind of crap MICROSOFT
DOES to create incompatibilities
DELIBERATELY. The code is either FREE or its NOT FREE.If the code
is FREE then let it be. You can put whatever
you want in the code -- I will remove any such constructs, just like I
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
No. That's really a purely technical thing.
I'm not certain I understand what you mean here. Nasty messages using
the word "taint" is purely
Martin J. Bligh wrote:
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate
exactly as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver")
and our proprietary
non derived
Alan wrote:
As per Alan's suggestion I decompressed the kernel source tree with the
processes pegged to one CPU then the other, and as he predicted it took
vastly longer on one CPU than the other, but I don't know what that
implies, or how to fix it.
From the timing it sounds like one
Alan wrote:
As per Alan's suggestion I decompressed the kernel source tree with the
processes pegged to one CPU then the other, and as he predicted it took
vastly longer on one CPU than the other, but I don't know what that
implies, or how to fix it.
From the timing it sounds like one
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a skeleton driver)
and our proprietary
non derived code
Martin J. Bligh wrote:
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate
exactly as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
No. That's really a purely technical thing.
I'm not certain I understand what you mean here. Nasty messages using
the word taint is purely subjective
This whole effort is pointless. This is the same kind of crap MICROSOFT
DOES to create incompatibilities
DELIBERATELY. The code is either FREE or its NOT FREE.If the code
is FREE then let it be. You can put whatever
you want in the code -- I will remove any such constructs, just like I
/etc/init.d/rcS script execution fails with busybox on 2.6.18. Seems
ldlinux.so related.
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Phillip Susi wrote:
If your comment here was in reply to my general comment about resierfs
stability and not the specific hibernation issue the OP was having,
please edit the quote down to just that portion instead of quoting the
entire message, including the quotes it was replying to.
I
Phillip Susi wrote:
Andrew Robinson wrote:
Now I am confused on what may be the cause of the corruption. Could it
have been just a ReiserFS problem (I will be using Ext3 or JSF on my
next rebuild I think after reading some reviews on the ReiserFS and
this recent experience).
I have been
Phillip Susi wrote:
Andrew Robinson wrote:
Now I am confused on what may be the cause of the corruption. Could it
have been just a ReiserFS problem (I will be using Ext3 or JSF on my
next rebuild I think after reading some reviews on the ReiserFS and
this recent experience).
I have been
Phillip Susi wrote:
If your comment here was in reply to my general comment about resierfs
stability and not the specific hibernation issue the OP was having,
please edit the quote down to just that portion instead of quoting the
entire message, including the quotes it was replying to.
I
with the GPL license
regarding modifications to the linux kernel
core code sections. This patch DOES NOT contain the DSFS file system
code, but only contains those portions of
the Linux kernel which have been modified and are required to be
released under the GPL.
Jeff V. Merkey
Chief Scientist
with the GPL license
regarding modifications to the linux kernel
core code sections. This patch DOES NOT contain the DSFS file system
code, but only contains those portions of
the Linux kernel which have been modified and are required to be
released under the GPL.
Jeff V. Merkey
Chief Scientist
Vladislav Bolkhovitin wrote:
The code is not at sourceforge on your project site with these updates
for 2.6.18. Where is the 2.6.18 version currently hosted?
It is there on http://sourceforge.net/projects/scst
(http://scst.sourceforge.net/). See 0.9.5 release version as well as
Vladislav Bolkhovitin wrote:
Jeff V. Merkey wrote:
I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
and above. Is scst and target support for FC-AL going to
remain supported and/or merged at some point? If so, what is planned
for scst support for later kernels
Vladislav Bolkhovitin wrote:
Jeff V. Merkey wrote:
I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
and above. Is scst and target support for FC-AL going to
remain supported and/or merged at some point? If so, what is planned
for scst support for later kernels
Vladislav Bolkhovitin wrote:
The code is not at sourceforge on your project site with these updates
for 2.6.18. Where is the 2.6.18 version currently hosted?
It is there on http://sourceforge.net/projects/scst
(http://scst.sourceforge.net/). See 0.9.5 release version as well as
I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
and above. Is scst and target support for FC-AL going to
remain supported and/or merged at some point? If so, what is planned
for scst support for later kernels?
Jeff
-
To unsubscribe from this list: send the line
I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
and above. Is scst and target support for FC-AL going to
remain supported and/or merged at some point? If so, what is planned
for scst support for later kernels?
Jeff
-
To unsubscribe from this list: send the line
If the X server is started manually on 2.6.14 and above with "startx &"
and if you hit the enter key in the detached session,
the desktop will stop responding to keyboard and mouse events.
It's easy to reproduce. Set to run level 3 on an ES4, then start the X
server manually
and hit enter
If the X server is started manually on 2.6.14 and above with startx
and if you hit the enter key in the detached session,
the desktop will stop responding to keyboard and mouse events.
It's easy to reproduce. Set to run level 3 on an ES4, then start the X
server manually
and hit enter in
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the
[EMAIL PROTECTED] wrote:
On Wed, 31 Aug 2005 12:00:45 MDT, "Jeff V. Merkey" said:
There's also a more fundamental problem with the GPL language. The GPL stated
it
confers "RIGHT TO COPY". This is not the same as "RIGHT TO GRANT
LICENSES TO DISTRIBUTE."
Arjan van de Ven wrote:
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does
Rik van Riel wrote:
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
I am very open to discussions
of high performance
network forensic open source applications on the Linux
Operating System.
DSFS is fully SMP enabled and supports Hyperthreaded architectures as
well as native SMP.
Jeff V. Merkey
Solera Networks
www.soleranetworks.com
-
To unsubscribe from this list: send the line
of high performance
network forensic open source applications on the Linux
Operating System.
DSFS is fully SMP enabled and supports Hyperthreaded architectures as
well as native SMP.
Jeff V. Merkey
Solera Networks
www.soleranetworks.com
-
To unsubscribe from this list: send the line
Rik van Riel wrote:
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
I am very open to discussions
Arjan van de Ven wrote:
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does
[EMAIL PROTECTED] wrote:
On Wed, 31 Aug 2005 12:00:45 MDT, Jeff V. Merkey said:
There's also a more fundamental problem with the GPL language. The GPL stated
it
confers RIGHT TO COPY. This is not the same as RIGHT TO GRANT
LICENSES TO DISTRIBUTE. Under US copyright law, if you confer
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of derived work.
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the
Trever L. Adams wrote:
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
Patent law in the US is based on section 113 of the United States
Constitution, and patents
are not going away.
Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles
Bernd Petrovitsch wrote:
On Wed, 2005-03-02 at 21:28 -0700, Jeff V. Merkey wrote:
Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
Another Linux patent.
... and another - AFAICS obvious - trivial ("prior art") patent (but I'm
Why the hell would I want
to look at the link in kwrite?
Talk to the USPTO, they created these links from their website. BTW,
if you check
the verson of web server run on the uspto.gov server, you will
discover it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware
outputs
Why the hell would I want
to look at the link in kwrite?
Talk to the USPTO, they created these links from their website. BTW,
if you check
the verson of web server run on the uspto.gov server, you will
discover it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware
outputs
Bernd Petrovitsch wrote:
On Wed, 2005-03-02 at 21:28 -0700, Jeff V. Merkey wrote:
Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
Another Linux patent.
... and another - AFAICS obvious - trivial (prior art) patent (but I'm
not fluent
Trever L. Adams wrote:
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
Patent law in the US is based on section 113 of the United States
Constitution, and patents
are not going away.
Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles
Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
Another Linux patent.
And that pretty much says it. Assigned to the Canopy Group. So SCO
will have yet another lawsuit to threaten us with. If they survive
the thrashing I've Been Moved will give them
Another Linux patent.
--- Begin Message ---
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2=HITOFF=1=/netahtml/search-bool.html=1=G=50=AND=ptxt=merkey.INZZ.=IN/merkey=IN/merkey
Zwane Mwaikambo wrote:
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from a stability viewpoint. I have to maintain a huge tree of
patches in order to ship appliance builds due to the lack of stability
for 2.6. I
Randy.Dunlap wrote:
Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been
a disaster from
a stability viewpoint. I have to maintain a huge tree of patches in
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even
number
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from
a stability viewpoint. I have to maintain a huge tree of patches in
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even
number releases will take longer
but it's worth
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from
a stability viewpoint. I have to maintain a huge tree of patches in
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even
number releases will take longer
but it's worth
Randy.Dunlap wrote:
Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been
a disaster from
a stability viewpoint. I have to maintain a huge tree of patches in
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even
number
Zwane Mwaikambo wrote:
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from a stability viewpoint. I have to maintain a huge tree of
patches in order to ship appliance builds due to the lack of stability
for 2.6. I
Another Linux patent.
---BeginMessage---
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/search-bool.htmlr=1f=Gl=50co1=ANDd=ptxts1=merkey.INZZ.OS=IN/merkeyRS=IN/merkey
Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
Another Linux patent.
And that pretty much says it. Assigned to the Canopy Group. So SCO
will have yet another lawsuit to threaten us with. If they survive
the thrashing I've Been Moved will give them
On Sun, Jul 01, 2001 at 04:50:44PM -0700, Ben Ford wrote:
Microsoft is like a mountain with their installed base. Like it
or not, no matter how loud the wind howls, the mountain cannot bow
to it.
:-)
Jeff
> Paul Mundt wrote:
>
> >On Sun, Jul 01, 2001 at 01:35:24PM -0400, Adam
On Sun, Jul 01, 2001 at 12:23:17PM -0700, Justin Guyett wrote:
> On Mon, 2 Jul 2001, Chris Wedgwood wrote:
>
> > On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
> >
> > > I'm not a file sustem hacker, nor since I work for one vendor the
> > > appropriate owner for larg chunks of code
On Sun, Jul 01, 2001 at 12:16:34AM -0400, Trever L. Adams wrote:
> > I am doing very well with my consulting projects, but to be honest,
> > my family has sufferred horribly in the past four years fighting with
> > Novell every other week, and there's a very strong chance I will be
> > moving
On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
> > There are several areas that need restructuring and work, and I am
> > available to answer questions, and assist with technical consulting,
>
> I'm not a file sustem hacker, nor since I work for one vendor the
> appropriate owner
On Sat, Jun 30, 2001 at 10:59:59PM -0500, Paul Fulghum wrote:
>
> From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
> > Novell has recently threatened to try to take my house and
> > assets if I post any more NWFS releases or MANOS.
> [snip]
> > T
On Mon, Jul 02, 2001 at 02:54:18AM +1200, Chris Wedgwood wrote:
> On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
>
> > I'm not a file sustem hacker, nor since I work for one vendor the
> > appropriate owner for larg chunks of code in some people's eyes. I
> > suspect the FSF is a much
1 - 100 of 1191 matches
Mail list logo
