Maybe you're not very experiences in reading patents, but this one seems surprisingly clear. What they're claiming is this:
1) You pick something up and drag it.
2) You drop it in something else.
3) Some new user-interface element pops up, presumably to offer you some options about how the accepting application should handle the thing you just dropped on it.
First, intellectual property issues always have slippery slopes. The results are due to balancing tests of the rights of the IP owner against the rights of the public. You can always find cases close to the line where a little push either way gives a different result.
So what?
Second, the issue is one of Trademark, not ownership of the images. Ford never claimed to own the images.
The primary question is: could a reasonable consumer believe that the calendar is a Ford product or endorsed by Ford? What is the chance for confusion?
Everyone knows what the terms of the GPL actually are. It's an incredibly simple document, which you can read and understand in five minutes. Either they publish their source, or else they don't use GPL code. And if that means - which I do not believe - that that means they can't write a Linux kernel module, well, tough, they can't.
But that's just the thing. You don't believe they can't write a Linux kernel module, and I don't believe that either. They also don't believe that. But despite how "incredibly simple" the GPL is, it's not clear that a court will agree with the three of us.
In fact, many of the contributors to the Linux kernel, who hold copyright to the various bits and pieces, don't share that view. They could potentially sue McAfee, and this has not been well-tested in court. McAfee can't predict, with reasonable certainty, the outcome of such a suit.
No, they are not 'supporting Linux'. Nothing in the McAfee statement says anything about Linux - the whole Linux angle is a fantasy dreamed up by trolls here on Slashdot.
I'm guessing you haven't followed any of the recent discussion between the folks at McAfee and the Linux kernel developers. While this particular statement may or may not be about Linux, McAfee has definitely expressed concerned about their Linux kernel modules and the GPL. These efforts could have many purposes, but IMO, the most obvious one is to prepare a defense to possible GPL violation accusations -- engineering necessity.
But even if all this were not so, even if McAfee's Linux products were actually useful for something, McAfee is a member of the Business Software Alliance, and have strong views on software piracy. They say, 'Software piracy is the illegal distribution and/or reproduction of software'. It is illegal to distribute GPL'd software without the full source code of what it is linked to. McAfee can't pick and choose which software the law applies to - either it applies to no software at all, or it applies to all software. If they are using GPL software without abiding by the terms of the license, then they are 'software pirates' (and on an epic scale). They cannot have it both ways.
McAfee is trying to abide by the terms of the GPL. The problem is simply that nobody knows what the terms of the GPL actually are. McAfee is simply acknowledging the risk that they got it wrong.
1) #include is just a way to include one file in another during compilation. Whether the result is a derived work of the header file is a complex question. There are certain cases that are quite clear and certain cases that are not so clear. One tricky case is Linux kernel modules.
I don't know what you mean by "create your own header file using part of it". When you #include a header file in a code file, the compiled code uses parts of the header file. The question is whether the compiled code is a derivative work.
2) You seem confused about how the GPL applies. The GPL applies when you distribute a derivative work of a work that is licensed under the GPL. I can't understand what you mean by "include GPL source code to create your code".
McAfee's kernel modules #include kernel header files. If they are derivative works of the Linux kernel, then they become subject to the GPL. Nobody can answer this question with certainty because there is no good case law and the laws themselves are not crystal clear.
The issue is about their Linux kernel modules. McAfee has been trying to get a stable kernel interface so that they don't need to include kernel header files, but for various reasons, this has not happened.
IMO, McAfee can make a strong showing that they took only what they had to take out of engineering necessity. This would mean that there work is not a derivative work. (See, for example, Lexmark v. Static Controls.)
Well, that's not quite true. Understanding the Linux process structure or any other aspect of the linux kernel does not, in any way, require you to use GPL'd code. It may require you to look at it and understand it, but you don't have to use GPL'd code to protect it. Maybe there is GPL software available to do just that, but you don't have to use it.
You have to use the kernel header files to create a kernel module.
Interacting with a Kernel API does not require you to release your software under the GPL. Using GPL code to do it, does bind you to the GPL.
This is assuming that the API itself is not or cannot be covered by the GPL. It is not clear that extracting the API from the code leaves an API that is not itself a derivative work. This may be true, but you can't just assume it.
McAfee has used GPL code so they need to abide by it's rules. It didn't have to - it could have written its own code, but it chose to use GPL code.
Nobody has to do anything. Engineering reality often means that you do have to do things, if you want to produce a product that has a particular set of features. McAfee could not, realistically, have provided the features they did without using the kernel header files. This includes the typical "on-demand" virus scan functionality that their products provide.
They don't believe they're subject to the GPL because of that, and I agree with them. But it's very dangerous not to disclose something that could be a risk. They can't predict how a court might rule.
There are lot of issues that are not well-tested in court. You put something in the SEC risks section so that should something happen, you are covered against accusations that you tried to hide it.
The biggest question is whether making a kernel module taking just what you need out of reasonable engineering necessity makes the module a derivative work. The answer seems to clearly be "no", but the FSF and many Linux developers seem to so strongly believe the opposite that there's a risk a court might somehow agree with them.
"Could you not argue that by using a computer program you are copying it?"
Yes, but so what? Anything *necessary* to use something is use. The terms "use" and "anything necessary for normal use" are synonymous.
If you have to copy something to use it in the ordinary way, then that copying is using the work in its ordinary way.
A great example is coloring books. When you color them in, you are surely creating a derivative work. Why don't you need a special license to do that? Simple -- coloring in a coloring book is the ordinary, expected use.
Everything you do when you use a work is also something else.
You are wrong. Linking does not create a derivative work because it doesn't create a work. Under copyright law, only creative effort can create a work. A linker is not creative.
There is no need to change copyright law.
If linking created a new derivative work, the linker would be entitled to own copyright on that new work since it created it.
"And no, I don't believe they are using GPL code. That's not what this is about. They are afraid of their (important) customers demanding McAfee support GPL products."
"They have a very simple solution, then, don't they? Do their own graft, write their own damn software, and stop freeloading off the community."
Your understanding of the issues involved seems pretty close to zero. They are not "freeloading off the community", they are supporting Linux.
The problem is simply that in order to write software that interacts with Linux at the low level they need to interact, they need to use code that defines how Linux processes some things internally. There is no choice -- to support Linux, they need to use that code.
They are voicing the risk that using that code may require them to comply with the terms of the GPL. I personally think it's pretty clear that's not the case, but even if I were in their shoes, I'd have to voice the concern.
They are not taking any more code than engineering necessity requires them to take if they are to support Linux.
"It's the same thing as stealing someones chips in a casino and cashing them in."
Exactly, except instead of stealing them, you win them at a table game. You see, the "scammers" were actually *following* the rules of the game. This is like "stealing bases" in baseball. We can metaphorically describe it as stealing or scamming, but the objective of the game is to get RL currency by following the rules of the game.
Why can't there be games where "scamming" is legal? If not, why doesn't WoW have to charge people with murder when they kill other people's characters without just provocation?
"I don't see how forcing everyone to publish their additions to your code means "locking down", just like I don't understand some hicks on my university's forum who demand their right to spam and flood, as moderating it is fascism and restricting their right to free speech."
Certainly one could argue that prohibiting people from spamming and flooding is a form of "locking down". It's not that "locking down" is automatically bad. Machine guns are not automatically bad, but clearly they should be locked down and not used indiscriminately.
Yes, forcing everyone to publish their additions to your code is a form of locking down. It prohibits some uses of your code and prohibits others. The question is whether this it the good kind of locking down, like prohibiting spam, or the bad kind of locking down, like prohibiting dissenting views.
""The GPL allows you everything, and for free -- the only thing you have to do in exchange is to provide like for like. If you got a program with a source code, the least you can do is publish any improvements you made to it.""
The thing is, like for like transactions are seldom optimum. A restaurant that required me to pay in food would be extremely inconvenient. The GPL, because it insists on like for like, prevents your code from being used for a lot of things it otherwise might be used for.
If you want your code to benefit everyone as much as possible, the GPL might not be the license for you. For example, a lot of standards have to be re-implemented because existing implementations are GPL and the protocol needs to be used in a project that is not GPL-compatible. This may mean incompatibilities, and it definitely means more work and poorer quality for everyone.
That may be worth it to you, it may be not.
""That's the thing I like about the GPL: it plays by the rules. We may not like the rules, but we play by them, and by playing, we show that the rules need to change.""
I don't know what that means, but I don't think it's true. For example, the FSF has been arguing that linking creates a derivative work -- that's trying to change the rules for the worse for everyone.
Suppose, to impress a friend, you intentionally shoot at someone. That someone happens to be dead. You believe they are dead, but that belief is reckless. Had they been alive, your shot would have killed them.
"You still haven't given any specific example of a real-time application that handles the fundamental real-time requirements entirely in software running on an X86 processor."
Of course not, because that's a meaningless and nonsensical request. The whole point is that x86 *hardware* provides all that's needed for this, so why are you asking me for an example that does it in software?
"I note that you are now talking about a system that implements real-time requirements rather than software that does. As I said at the start, such a system typically requires specialized hardware to meet real-time requirements and a video capture board is the specialized hardware used in this case."
Wow, a video capture applications requires a video capture card. I never would have guessed that.
However, from the software standpoint, the video capture card is the source of the real time requirement. That capture card must be serviced every so often.
Almost every real time requirement will have some real world source of the real world requirement. It's hard to imagine any real time requirements locked in a closet. If you're going to argue that whatever connects that real world requirement to the system is "specialized hardware", then every real time application requires specialized hardware.
The thing is, this is a meaningless exercise. The question is whether something about the unpredictable timing of x86 hardware makes it particularly unsuitable for real-time applications. An argument that all real time tasks need hardware to talk to the real world says nothing about this point. It was a total waste of time.
The video capture card example proves the point. It can go in an x86 system, or a MIPS system, or a PPC system. Any video capture real time system will need a video capture card, and once you have that, all these platforms are suitable.
You know this. It's obvious you know this. So the question is why you're being so dense about it. And I have no answer.
You're being an idiot. You're impervious to facts and reason. Most likely, anyone reading can already see this.
The point is, this is a system that implements real-time requirements. It is a realistic example of such a system. In fact, it is typical. It works just as well if the processing unit is a commodity x86 system or some other architecture.
Just as x86 works perfectly in this typical system that manages real-time requirements, it also works perfectly in many similar systems that meet real-time requirements.
""Wow, you are really missing the point. The capture board is more than just a minimal interface between a TV signal and the PC's processor, it's doing the heavy lifting with respect to the real-time requirements of capturing video. Thus the card is specialized hardware that makes video capture possible by performing the real-time processing. Obviously, it is "specialized" because you couldn't use that card to capture other kinds of data. Being "specialized" has nothing to do with complexity.""
The point is simply that this same hardware work work precisely the same on an x86 platform as on any other platform. It has nothing whatsoever to do with the subject of our disagreement, which is whether x86 platforms are unusually unsuitable for real-time use.
"That's fine if the timing requirements only have an upper bound, but what if there's a lower bound as well? What if the timing window is narrower than the jitter in timing behavior due to caches and prefetch etc? What is your trivial solution for that?"
Let's take the case of video acquisition. A typical requirement will be that the video hardware will trigger an interrupt when the buffer fills to some particular point. The buffer must be drained before it overflows or else data will be lost. All that matters is that you have an upper bound on the latency between when the interrupt occurs and when you get around to draining the buffer.
Suppose you have a weird situation where you must service the interrupt more than 5 milliseconds after it occurs but no more than 15. When the interrupt occurs, you simply arrange for another interrupt to be generated in 5 milliseconds. So long as you can upper bound the cost of all delays to 10 milliseconds, you will meet the interval requirement.
If the timing interval is narrower than the window and cannot be reduced by software, then the hardware is unsuitable. Generally, the fix is faster hardware. For a given performance level, x86 is probably the cheapest way to get fast enough to bring that jitter down.
You can also turn things like caches off, but I've never heard of a case where the reduction in jitter was worth the reduction in absolute performance.
I think you are imagining some extremely bizarre narrow group of real-time applications rather than the whole universe of such applications. Obviously, there is no one technology that is right for the majority of bizarre applications, that's what makes them bizarre.
But for the vast majority of real-time applications, x86 hardware is cheap and well suited.
"So your saying that the specialized hardware you believe isn't needed doesn't depend on the application? I don't see how you can claim to understand something you don't believe exists."
I'm not sure if this sudden bout of stupidity is intentional or unintentional, but I'm saying that whether or not specialized hardware is generally needed to provide real-time capability doesn't depend on the application because the question isn't about particular applications. We're talking about whether the x86 platform is suitable generally for real time applications, not the ins and outs of particular real time applications.
You are attempting for some reason to sideline this into ever and ever narrower and weirder areas. The fact is, modern x86 systems have all the hardware required for most real time applications.
Your argument about PC video capture boards makes my point. They work fine in x86 systems and don't require any specialized hardware to make them work. They would work exactly the same in power PC systems or MIPS system. The fact that the board is in an x86 system doesn't make the hardware or software any more complex or simpler.
All that is needed is specialized software in the x86 system to ensure that the board is serviced at least as often is required.
"Again, it's predictable timing behavior that is key."
The simplest way to get predictable timing behavior is simply to ensure that the worst case performance is sufficient to meet the timing requirements. Unpredictable acceleration only hurts you if the software isn't designed to account for it. Fortunately, designing the software to account for that is all but trivial.
Why reply if you're not going to answer? You are wrong, specialized hardware is not required for the vast majority of real time applications. Only specialized software is required.
I've asked you what kind of specialized hardware you think is required and the best you can come up with is "it depends". No, it doesn't depend. Specialized hardware is rarely needed to meet real time requirements.
It may once have been, back in the days of the Atari 2600. But these days, commodity hardware provides all of the things needed. All modern x86 commodity implementations includes prioritized interrupts, precision counters and timers with interrupt-generation capability, and so on.
"What happens today is that systems with real-time requirements have delegated the real-time parts to specialized hardware instead of software. In that way they can avoid the problems that inconsistent timing would otherwise present. Thus real-time systems can be implemented on a x86 system, but not entirely in software."
I think you have no idea what you're talking about. What kind of specialized hardware do you think is needed? In truth, they use specialized *software*.
"For the reasons you state, I'd say that such optimization is a fool's errand."
Nonsense. Perfect optimization is a fool's errand. Claiming that any significant code can't be further optimized is a fool's errand. But sometimes small amounts of effort, in the right place, can have a huge payoff. That's hardly a fool's errand.
"It also shows why you shouldn't try to create real-time software to run on x86 system."
Nonsense. If the worst case behavior meets the real-time requirements, then you win. You can often get x86 systems whose worst case behavior is many times faster than non-x86 systems at the same price level. This is often the case because x86 hardware is made in massive quantities. Why do you think the Hubble space telescope uses x86 processors?
"At the application level it's often not necessary to do something special to run 32-bit software."
In which case, you get basically no benefit.
"The point is that the performance improvements of the past were primarily intended to boost new processor sales rather than do something for software developers."
Of course. Intel and AMD make chips for consumers, not for developers.
"The fact that legacy software ran faster on a new processor is a great way to get people to upgrade their hardware, but really has no effect on software sales."
I think that's largely true, but I don't see what it has to do with anything.
The point I'm trying to make is that developers have always had to figure out how to get the most out of new CPUs. Optimizing for modern CPUs is very, very tricky even ignoring multi-core or multi-thread issues. For example, you can't just add up the number of clock cycles for each instruction on any modern x86 or x86-64 CPU. You can't easily anticipate cache effects, mispredicted branched, and any number of other things.
It has always taken massive work on the part of developers to get performance out of new processors. People forget this because there was a historically brief period where not quite so much as usual was required. It is amazing that Intel has kept the x86 instruction set basically the same for as long as it has.
Slashdot Mirror
It is only natural to expect that an agreement forced by a third party will be inferior to an agreement mutually acceptable to both parties.
Maybe you're not very experiences in reading patents, but this one seems surprisingly clear. What they're claiming is this:
1) You pick something up and drag it.
2) You drop it in something else.
3) Some new user-interface element pops up, presumably to offer you some options about how the accepting application should handle the thing you just dropped on it.
DS
First, intellectual property issues always have slippery slopes. The results are due to balancing tests of the rights of the IP owner against the rights of the public. You can always find cases close to the line where a little push either way gives a different result.
So what?
Second, the issue is one of Trademark, not ownership of the images. Ford never claimed to own the images.
The primary question is: could a reasonable consumer believe that the calendar is a Ford product or endorsed by Ford? What is the chance for confusion?
But that's just the thing. You don't believe they can't write a Linux kernel module, and I don't believe that either. They also don't believe that. But despite how "incredibly simple" the GPL is, it's not clear that a court will agree with the three of us.
In fact, many of the contributors to the Linux kernel, who hold copyright to the various bits and pieces, don't share that view. They could potentially sue McAfee, and this has not been well-tested in court. McAfee can't predict, with reasonable certainty, the outcome of such a suit.
I'm guessing you haven't followed any of the recent discussion between the folks at McAfee and the Linux kernel developers. While this particular statement may or may not be about Linux, McAfee has definitely expressed concerned about their Linux kernel modules and the GPL. These efforts could have many purposes, but IMO, the most obvious one is to prepare a defense to possible GPL violation accusations -- engineering necessity.
McAfee is trying to abide by the terms of the GPL. The problem is simply that nobody knows what the terms of the GPL actually are. McAfee is simply acknowledging the risk that they got it wrong.
1) #include is just a way to include one file in another during compilation. Whether the result is a derived work of the header file is a complex question. There are certain cases that are quite clear and certain cases that are not so clear. One tricky case is Linux kernel modules.
I don't know what you mean by "create your own header file using part of it". When you #include a header file in a code file, the compiled code uses parts of the header file. The question is whether the compiled code is a derivative work.
2) You seem confused about how the GPL applies. The GPL applies when you distribute a derivative work of a work that is licensed under the GPL. I can't understand what you mean by "include GPL source code to create your code".
McAfee's kernel modules #include kernel header files. If they are derivative works of the Linux kernel, then they become subject to the GPL. Nobody can answer this question with certainty because there is no good case law and the laws themselves are not crystal clear.
3) McAfee most certainly does produce or sell products for Linux, otherwise there would be no issue. The issue is about the code they use to scan files as they are used on Linux boxes.
http://www.mcafee.com/us/enterprise/products/anti_virus/file_servers_desktops/linuxshield.html
The issue is about their Linux kernel modules. McAfee has been trying to get a stable kernel interface so that they don't need to include kernel header files, but for various reasons, this has not happened.
IMO, McAfee can make a strong showing that they took only what they had to take out of engineering necessity. This would mean that there work is not a derivative work. (See, for example, Lexmark v. Static Controls.)
You have to use the kernel header files to create a kernel module.
This is assuming that the API itself is not or cannot be covered by the GPL. It is not clear that extracting the API from the code leaves an API that is not itself a derivative work. This may be true, but you can't just assume it.
Nobody has to do anything. Engineering reality often means that you do have to do things, if you want to produce a product that has a particular set of features. McAfee could not, realistically, have provided the features they did without using the kernel header files. This includes the typical "on-demand" virus scan functionality that their products provide.
They don't believe they're subject to the GPL because of that, and I agree with them. But it's very dangerous not to disclose something that could be a risk. They can't predict how a court might rule.
There are lot of issues that are not well-tested in court. You put something in the SEC risks section so that should something happen, you are covered against accusations that you tried to hide it.
The biggest question is whether making a kernel module taking just what you need out of reasonable engineering necessity makes the module a derivative work. The answer seems to clearly be "no", but the FSF and many Linux developers seem to so strongly believe the opposite that there's a risk a court might somehow agree with them.
"Could you not argue that by using a computer program you are copying it?"
Yes, but so what? Anything *necessary* to use something is use. The terms "use" and "anything necessary for normal use" are synonymous.
If you have to copy something to use it in the ordinary way, then that copying is using the work in its ordinary way.
A great example is coloring books. When you color them in, you are surely creating a derivative work. Why don't you need a special license to do that? Simple -- coloring in a coloring book is the ordinary, expected use.
Everything you do when you use a work is also something else.
You are wrong. Linking does not create a derivative work because it doesn't create a work. Under copyright law, only creative effort can create a work. A linker is not creative.
There is no need to change copyright law.
If linking created a new derivative work, the linker would be entitled to own copyright on that new work since it created it.
"And no, I don't believe they are using GPL code. That's not what this is about. They are afraid of their (important) customers demanding McAfee support GPL products."
So they've been faking all their posts to the Linux kernel group? And, of course, this page must be a hoax:
http://www.mcafee.com/us/enterprise/products/anti_virus/file_servers_desktops/linuxshield.html
Damn, they're good.
"They have a very simple solution, then, don't they? Do their own graft, write their own damn software, and stop freeloading off the community."
Your understanding of the issues involved seems pretty close to zero. They are not "freeloading off the community", they are supporting Linux.
The problem is simply that in order to write software that interacts with Linux at the low level they need to interact, they need to use code that defines how Linux processes some things internally. There is no choice -- to support Linux, they need to use that code.
They are voicing the risk that using that code may require them to comply with the terms of the GPL. I personally think it's pretty clear that's not the case, but even if I were in their shoes, I'd have to voice the concern.
They are not taking any more code than engineering necessity requires them to take if they are to support Linux.
"It's the same thing as stealing someones chips in a casino and cashing them in."
Exactly, except instead of stealing them, you win them at a table game. You see, the "scammers" were actually *following* the rules of the game. This is like "stealing bases" in baseball. We can metaphorically describe it as stealing or scamming, but the objective of the game is to get RL currency by following the rules of the game.
Why can't there be games where "scamming" is legal? If not, why doesn't WoW have to charge people with murder when they kill other people's characters without just provocation?
"I don't see how forcing everyone to publish their additions to your code means "locking down", just like I don't understand some hicks on my university's forum who demand their right to spam and flood, as moderating it is fascism and restricting their right to free speech."
Certainly one could argue that prohibiting people from spamming and flooding is a form of "locking down". It's not that "locking down" is automatically bad. Machine guns are not automatically bad, but clearly they should be locked down and not used indiscriminately.
Yes, forcing everyone to publish their additions to your code is a form of locking down. It prohibits some uses of your code and prohibits others. The question is whether this it the good kind of locking down, like prohibiting spam, or the bad kind of locking down, like prohibiting dissenting views.
""The GPL allows you everything, and for free -- the only thing you have to do in exchange is to provide like for like. If you got a program with a source code, the least you can do is publish any improvements you made to it.""
The thing is, like for like transactions are seldom optimum. A restaurant that required me to pay in food would be extremely inconvenient. The GPL, because it insists on like for like, prevents your code from being used for a lot of things it otherwise might be used for.
If you want your code to benefit everyone as much as possible, the GPL might not be the license for you. For example, a lot of standards have to be re-implemented because existing implementations are GPL and the protocol needs to be used in a project that is not GPL-compatible. This may mean incompatibilities, and it definitely means more work and poorer quality for everyone.
That may be worth it to you, it may be not.
""That's the thing I like about the GPL: it plays by the rules. We may not like the rules, but we play by them, and by playing, we show that the rules need to change.""
I don't know what that means, but I don't think it's true. For example, the FSF has been arguing that linking creates a derivative work -- that's trying to change the rules for the worse for everyone.
That was the most insane rant I've every read on /. -- and that's saying something!
This is a rotary wing craft, not a fixed wing. He can fly as low as is safe.
Suppose, to impress a friend, you intentionally shoot at someone. That someone happens to be dead. You believe they are dead, but that belief is reckless. Had they been alive, your shot would have killed them.
"You still haven't given any specific example of a real-time application that handles the fundamental real-time requirements entirely in software running on an X86 processor."
Of course not, because that's a meaningless and nonsensical request. The whole point is that x86 *hardware* provides all that's needed for this, so why are you asking me for an example that does it in software?
"I note that you are now talking about a system that implements real-time requirements rather than software that does. As I said at the start, such a system typically requires specialized hardware to meet real-time requirements and a video capture board is the specialized hardware used in this case."
Wow, a video capture applications requires a video capture card. I never would have guessed that.
However, from the software standpoint, the video capture card is the source of the real time requirement. That capture card must be serviced every so often.
Almost every real time requirement will have some real world source of the real world requirement. It's hard to imagine any real time requirements locked in a closet. If you're going to argue that whatever connects that real world requirement to the system is "specialized hardware", then every real time application requires specialized hardware.
The thing is, this is a meaningless exercise. The question is whether something about the unpredictable timing of x86 hardware makes it particularly unsuitable for real-time applications. An argument that all real time tasks need hardware to talk to the real world says nothing about this point. It was a total waste of time.
The video capture card example proves the point. It can go in an x86 system, or a MIPS system, or a PPC system. Any video capture real time system will need a video capture card, and once you have that, all these platforms are suitable.
You know this. It's obvious you know this. So the question is why you're being so dense about it. And I have no answer.
You're being an idiot. You're impervious to facts and reason. Most likely, anyone reading can already see this.
The point is, this is a system that implements real-time requirements. It is a realistic example of such a system. In fact, it is typical. It works just as well if the processing unit is a commodity x86 system or some other architecture.
Just as x86 works perfectly in this typical system that manages real-time requirements, it also works perfectly in many similar systems that meet real-time requirements.
""Wow, you are really missing the point. The capture board is more than just a minimal interface between a TV signal and the PC's processor, it's doing the heavy lifting with respect to the real-time requirements of capturing video. Thus the card is specialized hardware that makes video capture possible by performing the real-time processing. Obviously, it is "specialized" because you couldn't use that card to capture other kinds of data. Being "specialized" has nothing to do with complexity.""
The point is simply that this same hardware work work precisely the same on an x86 platform as on any other platform. It has nothing whatsoever to do with the subject of our disagreement, which is whether x86 platforms are unusually unsuitable for real-time use.
"That's fine if the timing requirements only have an upper bound, but what if there's a lower bound as well? What if the timing window is narrower than the jitter in timing behavior due to caches and prefetch etc? What is your trivial solution for that?"
Let's take the case of video acquisition. A typical requirement will be that the video hardware will trigger an interrupt when the buffer fills to some particular point. The buffer must be drained before it overflows or else data will be lost. All that matters is that you have an upper bound on the latency between when the interrupt occurs and when you get around to draining the buffer.
Suppose you have a weird situation where you must service the interrupt more than 5 milliseconds after it occurs but no more than 15. When the interrupt occurs, you simply arrange for another interrupt to be generated in 5 milliseconds. So long as you can upper bound the cost of all delays to 10 milliseconds, you will meet the interval requirement.
If the timing interval is narrower than the window and cannot be reduced by software, then the hardware is unsuitable. Generally, the fix is faster hardware. For a given performance level, x86 is probably the cheapest way to get fast enough to bring that jitter down.
You can also turn things like caches off, but I've never heard of a case where the reduction in jitter was worth the reduction in absolute performance.
I think you are imagining some extremely bizarre narrow group of real-time applications rather than the whole universe of such applications. Obviously, there is no one technology that is right for the majority of bizarre applications, that's what makes them bizarre.
But for the vast majority of real-time applications, x86 hardware is cheap and well suited.
"So your saying that the specialized hardware you believe isn't needed doesn't depend on the application? I don't see how you can claim to understand something you don't believe exists."
I'm not sure if this sudden bout of stupidity is intentional or unintentional, but I'm saying that whether or not specialized hardware is generally needed to provide real-time capability doesn't depend on the application because the question isn't about particular applications. We're talking about whether the x86 platform is suitable generally for real time applications, not the ins and outs of particular real time applications.
You are attempting for some reason to sideline this into ever and ever narrower and weirder areas. The fact is, modern x86 systems have all the hardware required for most real time applications.
Your argument about PC video capture boards makes my point. They work fine in x86 systems and don't require any specialized hardware to make them work. They would work exactly the same in power PC systems or MIPS system. The fact that the board is in an x86 system doesn't make the hardware or software any more complex or simpler.
All that is needed is specialized software in the x86 system to ensure that the board is serviced at least as often is required.
"Again, it's predictable timing behavior that is key."
The simplest way to get predictable timing behavior is simply to ensure that the worst case performance is sufficient to meet the timing requirements. Unpredictable acceleration only hurts you if the software isn't designed to account for it. Fortunately, designing the software to account for that is all but trivial.
Why reply if you're not going to answer? You are wrong, specialized hardware is not required for the vast majority of real time applications. Only specialized software is required.
I've asked you what kind of specialized hardware you think is required and the best you can come up with is "it depends". No, it doesn't depend. Specialized hardware is rarely needed to meet real time requirements.
It may once have been, back in the days of the Atari 2600. But these days, commodity hardware provides all of the things needed. All modern x86 commodity implementations includes prioritized interrupts, precision counters and timers with interrupt-generation capability, and so on.
"What happens today is that systems with real-time requirements have delegated the real-time parts to specialized hardware instead of software. In that way they can avoid the problems that inconsistent timing would otherwise present. Thus real-time systems can be implemented on a x86 system, but not entirely in software."
I think you have no idea what you're talking about. What kind of specialized hardware do you think is needed? In truth, they use specialized *software*.
"For the reasons you state, I'd say that such optimization is a fool's errand."
Nonsense. Perfect optimization is a fool's errand. Claiming that any significant code can't be further optimized is a fool's errand. But sometimes small amounts of effort, in the right place, can have a huge payoff. That's hardly a fool's errand.
"It also shows why you shouldn't try to create real-time software to run on x86 system."
Nonsense. If the worst case behavior meets the real-time requirements, then you win. You can often get x86 systems whose worst case behavior is many times faster than non-x86 systems at the same price level. This is often the case because x86 hardware is made in massive quantities. Why do you think the Hubble space telescope uses x86 processors?
"At the application level it's often not necessary to do something special to run 32-bit software."
In which case, you get basically no benefit.
"The point is that the performance improvements of the past were primarily intended to boost new processor sales rather than do something for software developers."
Of course. Intel and AMD make chips for consumers, not for developers.
"The fact that legacy software ran faster on a new processor is a great way to get people to upgrade their hardware, but really has no effect on software sales."
I think that's largely true, but I don't see what it has to do with anything.
The point I'm trying to make is that developers have always had to figure out how to get the most out of new CPUs. Optimizing for modern CPUs is very, very tricky even ignoring multi-core or multi-thread issues. For example, you can't just add up the number of clock cycles for each instruction on any modern x86 or x86-64 CPU. You can't easily anticipate cache effects, mispredicted branched, and any number of other things.
It has always taken massive work on the part of developers to get performance out of new processors. People forget this because there was a historically brief period where not quite so much as usual was required. It is amazing that Intel has kept the x86 instruction set basically the same for as long as it has.