> David Schwartz wrote:
> >> The misunderstanding is from the docs.
> >> The select() does not report device errors.
> >> Select will just "more precisely, to see if a read will not block".
> > This is a much slighter misunderstanding. The result
> The misunderstanding is from the docs.
> The select() does not report device errors.
> Select will just "more precisely, to see if a read will not block".
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'read' will or will
> David Schwartz wrote:
> > Nope. An errored connection is always ready for read/write -- there is
> > nothing to wait for as far as the kernel is concerned. Your code keeps
> > asking the kernel if something interesting has happened, the
> > kernel keeps
> > tel
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the
kernel keeps
telling it yes, and it refuses to do anything
The misunderstanding is from the docs.
The select() does not report device errors.
Select will just more precisely, to see if a read will not block.
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'read' will or will not
David Schwartz wrote:
The misunderstanding is from the docs.
The select() does not report device errors.
Select will just more precisely, to see if a read will not block.
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits for something to happen, and I get one
i am using the GARMIN_GPS/usb driver to read a gps receiver.
In testing the ability of my software to recover from various errors, I
try this: unplug the gps/USB cable from the usb hub.
Interestingly enough the thread spins.
the SELECT() waits for something to happen, and I get one channel
> In my experience, it's not much the context switch by itself which causes
> performance degradation, but the fact that with threads, you have to put
> mutexes everywhere. And frankly, walking a list with locks everywhere
> is quite slower than doing it in one run at a rate of 3 or 4 cycles per
I mostly agree with your comments, so I'm only responding to the points I
disagree with.
> So in fact, converting a threaded program to a pure async model should
> not improve it much because of the initial architectural design. But a
> program written from scratch to be purely async should
I mostly agree with your comments, so I'm only responding to the points I
disagree with.
So in fact, converting a threaded program to a pure async model should
not improve it much because of the initial architectural design. But a
program written from scratch to be purely async should perform
In my experience, it's not much the context switch by itself which causes
performance degradation, but the fact that with threads, you have to put
mutexes everywhere. And frankly, walking a list with locks everywhere
is quite slower than doing it in one run at a rate of 3 or 4 cycles per
> Hello all,
>
> I want to know in detail about , what the events (epoll or /dev/poll or
> select ) achieve in contrast to thread per client.
>
> i can have a thread per client and use send and recv system call directly
> right? Why do i go for these event mechanisms?
>
> Please help me to
Hello all,
I want to know in detail about , what the events (epoll or /dev/poll or
select ) achieve in contrast to thread per client.
i can have a thread per client and use send and recv system call directly
right? Why do i go for these event mechanisms?
Please help me to understand
> Hmm...
> I find in section 6.1:
> > In addition to PCI INTx compatible interrupt emulation, PCI Express
> > requires support of MSI or MSI-X or both.
> Which suggests that INTx support is required.
Unfortunately, this can be equally well read to suggest that MSI/MSI-X is
not required, but
Hmm...
I find in section 6.1:
In addition to PCI INTx compatible interrupt emulation, PCI Express
requires support of MSI or MSI-X or both.
Which suggests that INTx support is required.
Unfortunately, this can be equally well read to suggest that MSI/MSI-X is
not required, but that
> > >> bunzip2 -c $file.bz2 |gzip -9 >$file.gz
So here are some actual results from a dual P3-1Ghz machine (2.6.21.1,
CFSv9). First lets time each operation individually:
$ time bunzip2 -k linux-2.6.21.tar.bz2
real1m5.626s
user1m2.240s
sys 0m3.144s
$ time gzip -9 linux-2.6.21.tar
> On Thu, 3 May 2007, David Schwartz wrote:
>
> >> I needed to recompress some files from .bz2 to .gz so I setup
> a script to
> >> do
> >>
> >> bunzip2 -c $file.bz2 |gzip -9 >$file.gz
> >>
> >> I expected that the two CPU heavy
On Thu, 3 May 2007, David Schwartz wrote:
I needed to recompress some files from .bz2 to .gz so I setup
a script to
do
bunzip2 -c $file.bz2 |gzip -9 $file.gz
I expected that the two CPU heavy processes would end up on different
cpu's and spend a little time shuffling data between
bunzip2 -c $file.bz2 |gzip -9 $file.gz
So here are some actual results from a dual P3-1Ghz machine (2.6.21.1,
CFSv9). First lets time each operation individually:
$ time bunzip2 -k linux-2.6.21.tar.bz2
real1m5.626s
user1m2.240s
sys 0m3.144s
$ time gzip -9 linux-2.6.21.tar
> No, the term context here has a specific meaning. It refers to those
> things which flow from the current pointer, including the virtual memory
> space, file descriptor table, current uid, and so forth.
And none of these things are used by an ISR.
> Because the
> current pointer is not
No, the term context here has a specific meaning. It refers to those
things which flow from the current pointer, including the virtual memory
space, file descriptor table, current uid, and so forth.
And none of these things are used by an ISR.
Because the
current pointer is not changed on
> Either you have a strange definition of fairness or you chose an
> extremely
> poor example, Ingo. In a fair scheduler I'd expect all tasks to
> get the exact
> same amount of time on the processor.
Yes, as a long-term average. However, that is impossible to do in the
short-term. Some taks has
> On Mon, 14 May 2007, Bob Johnston wrote:
> > Alan Cox lxorguk.ukuu.org.uk> writes:
> >
> > > > Why not just use the terms:
> > > > * outdated - as a replacement for "deprecated".
> > >
> > > Because they don't actually mean the same thing ?
> >
> > "superseded" would probably be a better
On Mon, 14 May 2007, Bob Johnston wrote:
Alan Cox alan at lxorguk.ukuu.org.uk writes:
Why not just use the terms:
* outdated - as a replacement for deprecated.
Because they don't actually mean the same thing ?
superseded would probably be a better word, perhaps lacking the
Either you have a strange definition of fairness or you chose an
extremely
poor example, Ingo. In a fair scheduler I'd expect all tasks to
get the exact
same amount of time on the processor.
Yes, as a long-term average. However, that is impossible to do in the
short-term. Some taks has to
> Ex: consider two equally important tasks T1 and T2 running on
> same CPU and
> whose execution nature is:
>
> T1 = 100% cpu hog
> T2 = 60% cpu hog (run for 600ms, sleep for 400ms)
>
> Over a arbitrary observation period of 10 sec,
>
> T1 was ready to run for all 10sec
>
Ex: consider two equally important tasks T1 and T2 running on
same CPU and
whose execution nature is:
T1 = 100% cpu hog
T2 = 60% cpu hog (run for 600ms, sleep for 400ms)
Over a arbitrary observation period of 10 sec,
T1 was ready to run for all 10sec
T2 was
> I needed to recompress some files from .bz2 to .gz so I setup a script to
> do
>
> bunzip2 -c $file.bz2 |gzip -9 >$file.gz
>
> I expected that the two CPU heavy processes would end up on different
> cpu's and spend a little time shuffling data between the two cpu's on a
> system (dual core
I needed to recompress some files from .bz2 to .gz so I setup a script to
do
bunzip2 -c $file.bz2 |gzip -9 $file.gz
I expected that the two CPU heavy processes would end up on different
cpu's and spend a little time shuffling data between the two cpu's on a
system (dual core opteron)
> FWIW I think doing this first will be better, exposing _all_ to non GNU
> modules will weaken whatever case we might have to take it away later.
> So, NACK from me too.
> I don't want to hear the whining; but it was allowed in .22, so why
> should we not be able to do this in .23 or
FWIW I think doing this first will be better, exposing _all_ to non GNU
modules will weaken whatever case we might have to take it away later.
So, NACK from me too.
I don't want to hear the whining; but it was allowed in .22, so why
should we not be able to do this in .23 or whatever.
> Hello,
>
> In an effort to increase over all throughput of my Linux NFS file
> server, I thought about trying to force an IRQ, for the NIC, to be
> serviced by a particular CPU. Is this possible?
>
> TIA,
> Phy
/proc/irq/*/smp_affinity
I would recommend automatic balancing and leave it at
Hello,
In an effort to increase over all throughput of my Linux NFS file
server, I thought about trying to force an IRQ, for the NIC, to be
serviced by a particular CPU. Is this possible?
TIA,
Phy
/proc/irq/*/smp_affinity
I would recommend automatic balancing and leave it at that.
> DS> Threads plus epoll is another.
> 20k threads and maybe more is too much :). Look at http://nginx.net/
> senction "Architecture and scalability" for example.
> DS> It really depends upon how much performance you need
> all, that hardware can take and hold :)
Why would you want 20k threads?
> David Schwartz пишет:
> > You have a misunderstanding about the semantics of 'sendfile'.
> The 'sendfile' function is just a more efficient version of a
> read followed by a write. If you did a read followed by a write,
> it would block as well (in the read).
> >
>
David Schwartz пишет:
You have a misunderstanding about the semantics of 'sendfile'.
The 'sendfile' function is just a more efficient version of a
read followed by a write. If you did a read followed by a write,
it would block as well (in the read).
DS
sendfile function is not just
DS Threads plus epoll is another.
20k threads and maybe more is too much :). Look at http://nginx.net/
senction Architecture and scalability for example.
DS It really depends upon how much performance you need
all, that hardware can take and hold :)
Why would you want 20k threads? You
> As I see, nonblocking mode is enabled - sendfile sends less than asked.
> But 2G via single 30 seconds sendfile call - this is blocking call. How
> can I avoid that? I prefer sendfile as fastest way to send file
> content to network socket. The problem with sendfile block on
>
As I see, nonblocking mode is enabled - sendfile sends less than asked.
But 2G via single 30 seconds sendfile call - this is blocking call. How
can I avoid that? I prefer sendfile as fastest way to send file
content to network socket. The problem with sendfile block on
nonblocking
> My test machine is a Dell Precision 490 with dual 5140 processors and
> 3GB of RAM. If I reduced kMaxSize to (2048 * 2048 * 236) is works.
> However, I need to allocate an array of char that is (2048 * 2048 * 256)
> and maybe even as large at (2048 * 2048 * 512).
>
> Obviously I have enough
My test machine is a Dell Precision 490 with dual 5140 processors and
3GB of RAM. If I reduced kMaxSize to (2048 * 2048 * 236) is works.
However, I need to allocate an array of char that is (2048 * 2048 * 256)
and maybe even as large at (2048 * 2048 * 512).
Obviously I have enough physical
> 1) When physical memory runs low, the memory manager will try to use
> memory currently allocated to the pagecache. Is this true?
Yes.
> 2) When vm.overcommit_memory = 2 (overcommit disabled), and memory runs
> low, it appears that the memory manager does not try to use memory
> currently
1) When physical memory runs low, the memory manager will try to use
memory currently allocated to the pagecache. Is this true?
Yes.
2) When vm.overcommit_memory = 2 (overcommit disabled), and memory runs
low, it appears that the memory manager does not try to use memory
currently
> I'm working on a project with teams spread across the world and we all
> work on the same repository patching the kernel and then integrating
> into a common main branch. Even though we label the source code, we
> would like to make sure that we are all building the same kernel by
> running
I'm working on a project with teams spread across the world and we all
work on the same repository patching the kernel and then integrating
into a common main branch. Even though we label the source code, we
would like to make sure that we are all building the same kernel by
running md5sum
> But when writing, what is the difference between queuing multiple tagged
> writes, and sending down multiple untagged cached writes that complete
> immediately and actually hit the disk later? Either way the host keeps
> sending writes to the disk until it's buffers are full, and the disk
Bill Davidsen wrote:
> I agree for giving a process more than a fair share, but I don't think
> "latency" is the best term for what you describe later. If you think of
> latency as the time between a process unblocking and the time when it
> gets CPU, that is a more traditional interpretation.
Bill Davidsen wrote:
I agree for giving a process more than a fair share, but I don't think
latency is the best term for what you describe later. If you think of
latency as the time between a process unblocking and the time when it
gets CPU, that is a more traditional interpretation. I'm not
But when writing, what is the difference between queuing multiple tagged
writes, and sending down multiple untagged cached writes that complete
immediately and actually hit the disk later? Either way the host keeps
sending writes to the disk until it's buffers are full, and the disk is
> So what gcc does may be technically legal, but it's still a horribly
> bad thing to do. Sadly, some gcc people seem to care more
> about "letter
> of the law" than "sanity and quality of implementation".
You know, it would be one thing if they were consistent. A policy that, by
default, you
So what gcc does may be technically legal, but it's still a horribly
bad thing to do. Sadly, some gcc people seem to care more
about letter
of the law than sanity and quality of implementation.
You know, it would be one thing if they were consistent. A policy that, by
default, you get all
> If you can't read protect your kernel, you can't write protect it
> either.
This is so misleading as to basically be false.
It is true that any security scheme that can prevent people from taking
money out of my account can also prevent people from putting money in.
However, the set of people
> So, obviously, /dev is on /, but the stat(2) says no.
> Who is right, and where is the bug ?
>
> Kernel 2.4 had it right : /dev was on /, no doubt.
Have a look at the contents of /proc/mounts and all will be clear.
DS
-
To unsubscribe from this list: send the line "unsubscribe
> there were multiple attempts with renicing X under the vanilla
> scheduler, and they were utter failures most of the time. _More_ people
> complained about interactivity issues _after_ X has been reniced to -5
> (or -10) than people complained about "nice 0" interactivity issues to
> begin
there were multiple attempts with renicing X under the vanilla
scheduler, and they were utter failures most of the time. _More_ people
complained about interactivity issues _after_ X has been reniced to -5
(or -10) than people complained about nice 0 interactivity issues to
begin with.
So, obviously, /dev is on /, but the stat(2) says no.
Who is right, and where is the bug ?
Kernel 2.4 had it right : /dev was on /, no doubt.
Have a look at the contents of /proc/mounts and all will be clear.
DS
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
If you can't read protect your kernel, you can't write protect it
either.
This is so misleading as to basically be false.
It is true that any security scheme that can prevent people from taking
money out of my account can also prevent people from putting money in.
However, the set of people I
> can anyone suggest me a proper way how to schedule UDP packets to
> transmit at
> some given rate?
>
> E.g., I have two boxes both having 10 GE interfaces. One box is able to
> transmit at 9.9Gbps, the other one is able to receive only at
> about 5.5Gbps.
> Flow control must be turned off for
can anyone suggest me a proper way how to schedule UDP packets to
transmit at
some given rate?
E.g., I have two boxes both having 10 GE interfaces. One box is able to
transmit at 9.9Gbps, the other one is able to receive only at
about 5.5Gbps.
Flow control must be turned off for some
> P.S. "utter failure" was too harsh. What sticks in my craw is that the
> world has to adjust to fit this new scheduler.
>
> -Mike
Even when it's totally clear that this scheduler is doing what you asked it
do while the old one wasn't? It still bothers you that now you have to ask
for
> I didn't suggest adding any unfairness! I suggested being fair by
> user/job/process instead of being fair by thread (which is actually
> unfair as it favors multi threaded processes over single threaded
> processes).
Wouldn't that be unfair because it favors multi-user approaches over
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be unfair because it favors multi-user approaches over
P.S. utter failure was too harsh. What sticks in my craw is that the
world has to adjust to fit this new scheduler.
-Mike
Even when it's totally clear that this scheduler is doing what you asked it
do while the old one wasn't? It still bothers you that now you have to ask
for what
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of jos poortvliet
> Sent: Saturday, March 17, 2007 5:24 AM
> To: [EMAIL PROTECTED]
> Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith;
> linux-kernel@vger.kernel.org; Nicholas Miell; Linus Torvalds;
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of jos poortvliet
Sent: Saturday, March 17, 2007 5:24 AM
To: [EMAIL PROTECTED]
Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith;
linux-kernel@vger.kernel.org; Nicholas Miell; Linus Torvalds; Andrew
> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression
* Mike Galbraith [EMAIL PROTECTED] wrote:
[...] The situation as we speak is that you can run cpu intensive
tasks while watching eye-candy. With RSDL, you can't, you feel the
non-interactive load instantly. [...]
i have to agree with Mike that this is a material regression that cannot
There's a distinction between giving it more cpu and giving it higher
priority: the important part about having high priority is getting low
latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other
> > There's a substantial performance hit for not yield, so we probably
> > want to investigate alternate semantics for it. It seems reasonable
> > for apps to say "let me not hog the CPU" without completely expiring
> > them. Imagine you're in the front of the line (aka queue) and you
> > spend
There's a substantial performance hit for not yield, so we probably
want to investigate alternate semantics for it. It seems reasonable
for apps to say let me not hog the CPU without completely expiring
them. Imagine you're in the front of the line (aka queue) and you
spend a moment
> I have a GPL driver (written by me) with workarounds, since I hadn't
> know-how,
> when I wrote it. Now I've got 2.4 proprietary driver from the vendor.
> Is use of
> the 2.4 driver know-how OK? (And could be such driver merged?)
Unless you made some kind of agreement with the copyright
I have a GPL driver (written by me) with workarounds, since I hadn't
know-how,
when I wrote it. Now I've got 2.4 proprietary driver from the vendor.
Is use of
the 2.4 driver know-how OK? (And could be such driver merged?)
Unless you made some kind of agreement with the copyright holder or
> > Right, but *why* is he doing that? The answer: It is the most
> > practical way
> > to write his driver.
> Most practical way to get something Windows compatible is to pirate
> Windows; I do not think that gives me permission to do so.
This is comparing apples to oranges because Windows has
> But... how does situation change when Evil Linker does #include
> from his
> binary-only part?
Right, but *why* is he doing that? The answer: It is the most practical way
to write his driver.
> I believe situation in this case changes a lot... And that's what
> embedded people are doing; I
But... how does situation change when Evil Linker does #include
pop3/gpl_header_file_with_some_inline_functions.h from his
binary-only part?
Right, but *why* is he doing that? The answer: It is the most practical way
to write his driver.
I believe situation in this case changes a lot... And
Right, but *why* is he doing that? The answer: It is the most
practical way
to write his driver.
Most practical way to get something Windows compatible is to pirate
Windows; I do not think that gives me permission to do so.
This is comparing apples to oranges because Windows has an
Combined responses
> On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > There is no legal meaning to "combining" two works of authorship under
> > the Berne Convention or any national implementation thereof. If you
> > "compile" or "collect" them, you're in one area of law, and if you
> On 2/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:
> > There is no such thing as the "combined work". If I put a DVD
> > of The Phantom
> > Menace in the same box as a DVD of The Big Lebowski, the box is not a
> > "combined work".
> On Saturday 17 February 2007 15:19, David Schwartz wrote:
> > Static Controls argued that taking the TLP was the only practical way to
> > make a cartridge that would work with that printer.
> Which shows how that case is different from writing Linux drivers. For
> Sigh. VJ is distributing the linux kernel with proprietary
> extensions. If you want to argue that the proprietary extensions in
> isolation are not derivative works of the kernel, fine, you might have
> a case, but the combined work, which VJ is distributing is *clearly* a
> derivative work
Sigh. VJ is distributing the linux kernel with proprietary
extensions. If you want to argue that the proprietary extensions in
isolation are not derivative works of the kernel, fine, you might have
a case, but the combined work, which VJ is distributing is *clearly* a
derivative work and
On Saturday 17 February 2007 15:19, David Schwartz wrote:
Static Controls argued that taking the TLP was the only practical way to
make a cartridge that would work with that printer.
Which shows how that case is different from writing Linux drivers. For
example, looking at the example
On 2/20/07, David Schwartz [EMAIL PROTECTED] wrote:
There is no such thing as the combined work. If I put a DVD
of The Phantom
Menace in the same box as a DVD of The Big Lebowski, the box is not a
combined work.
If you can't even agree on that the legal concept of a combined work
Combined responses
On 2/20/07, Michael K. Edwards [EMAIL PROTECTED] wrote:
There is no legal meaning to combining two works of authorship under
the Berne Convention or any national implementation thereof. If you
compile or collect them, you're in one area of law, and if you
create a
> You're saying that there's no other way to interface device drivers to
> an operating system than the current Linux driver model?
Interfacing an X1900 graphics card to FreeBSD and interfacing an X1900
graphics card to Linux are two different ideas. They are *not* two
expressions of the same
> On 2/17/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > Per this principle, it would seem that only source code and
> > hand-crafted object code would be governed by copyright, since
> > compilation is also an automated process.
> Well, compilation is probably equivalent to "translation",
> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>
> > Again, see Lexmark v. Static Controls. If "make a toner cartridge that
> > works
> > with a particular Lexmark printer" is a functional idea, why is "make a
> > graphics driver that wo
(combined responses)
> On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> >> Linking with kernel exported symbols in a kernel module is by many
> >> people considered creating a work derived from the kernel.
> > That's simply
(combined responses)
On Feb 17, 2007, David Schwartz [EMAIL PROTECTED] wrote:
Linking with kernel exported symbols in a kernel module is by many
people considered creating a work derived from the kernel.
That's simply unreasonable. It is the most clear settled law that only a
creative
On Saturday 17 February 2007 03:42, David Schwartz wrote:
Again, see Lexmark v. Static Controls. If make a toner cartridge that
works
with a particular Lexmark printer is a functional idea, why is make a
graphics driver that works with a particular Linux kernel not? What
On 2/17/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
Per this principle, it would seem that only source code and
hand-crafted object code would be governed by copyright, since
compilation is also an automated process.
Well, compilation is probably equivalent to translation, which is
You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model?
Interfacing an X1900 graphics card to FreeBSD and interfacing an X1900
graphics card to Linux are two different ideas. They are *not* two
expressions of the same
> Linking with kernel exported symbols in a kernel module is by many
> people considered creating a work derived from the kernel.
That's simply unreasonable. It is the most clear settled law that only a
creative process can create a work for copyright purposes. Linking is an
automated process,
> On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:
> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own
> > something if there
> > are multiple equally good ways to do it and you claim *one* of them
> > That's exactly what they're doing. Knowing only the *function* of his
> > program, they are claiming it must obey their licensing terms.
> > They have no
> > idea exactly how he chose to implement that function, but claim
> > they must
> > own it anyway.
> They are not claiming ownership of
> On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:
> > Just to be perfectly clear, it is an outrageous claim that *every*
> > *possible* kernel module must be a derivative work of the
> > kernel. Copyright
> > *cannot* protect every possible way
> What are you talking about? This is not about software patents AT ALL.
Yes, it is. The difference between a copyright and a patent is this
simple -- a copyright protects the one particular way you chose to do
something and a patent protects every possible way of doing the same thing
(or
> I'll say that again, for everyone else who is reading this: the GPL
> makes it really clear that extensions to a GPL work are required to be
> distributed under the terms of the GPL. All this junk about
> "derivative works" is just the legal jargon used to implement the
> intent of the GPL.
301 - 400 of 676 matches
Mail list logo
