I doubt it. I suspect that there's a court case on Monday unless Judge Kimball says that there isn't, and I suspect that he is quite unlikely to do so.
Remember, about all that's left of the case is how much of Novell's money is SCO holding and refusing to give to Novell. SCO going bankrupt doesn't alter the case, it merely adds more urgency to it.
I seem to recall[*] that SCO told the court that there was no need for a constructive trust to protect Novell's money, since they (SCO) were in no danger of bankruptcy.
Now SCO is facing the exact same judge on Monday morning over the issue of how much money they owe Novell. I predict an interesting day in court;-)
* OK, I was reminded of it by something someone (anonymous, so I can't give credit) said on Groklaw.
Did they just argue that they haven't admitted that they were doing it, but they can't talk about doing it because it would threaten national security?
Um, hello?
First, it's true that you're not supposed to be able to sue on a hypothetical situation. SCO aside, there's supposed to be a real issue before you can sue. But the government seems to be saying that they have to admit to the wiretapping before they can be sued for it. IANAL, but I don't believe that's how it works, not even for the federal government.
Second, maybe "we can't talk about it" is precisely why they haven't admitted it? So, maybe, not admitting it doesn't mean a thing?
I hope and expect that the judge can see right through this rubbish...
... or did MS and Google just say that I have the right to do what the law says I have the right to do?
Um... thanks, guys, and it's nice of you to say so publicly and all that, but I already had those rights, because the law said I had them. I don't need your say-so, or any corporation's. Just the law. Hard as it is to believe, the law is actually what gives us the right to do stuff, not your permission.
Note well: A well-run country is a benefit. Not being taxed to death to pay for a bunch of pork is a benefit. Honesty and integrity in government is a benefit.
But from the article, they had to hit IIS with a specially-crafted URL to exploit this. So, let's see, what can we do with a specially-crafted URL? We can do shell code into a buffer. If we know where the dangling pointer points, and where incoming URLs are placed, we might even be able to get our shell code where the dangling pointer points to. Then all we have to do is get the pointer called (assuming it's a function pointer... maybe a bad assumption). This could be done with another, immediately-following request, or it might happen automatically (if we can also make the circumstances that cause the pointer to be called occur with the same URL without messing up the shell code).
If it's a data pointer, I think it still depends on getting part of the URL into where the data pointer points. Say it points to a structure, and in that structure is a text buffer, and also in it is a function pointer. Now we can call an arbitrary function anywhere in ISS's memory image, with arbitrary data. That's got to be pretty easy to exploit. Once again, though, we also have to get the pointer used.
So as far as I can see, there are two things that are needed - being able to get the data from the URL into the memory where the dangling pointer points, and getting the pointer to be used. How you have to do those things will be highly application-specific, I would imagine...
But the judge didn't rule it unenforceable because there was no law stating that clickwrap agreements were valid. He ruled that the terms were so one-sided that it was "unconscionable" (horribly one-sided), and therefore invalid. If the same terms were in a shrinkwrap license, or even a signed contract, the same terms would have had the same problem.
The statement that it doesn't apply everywhere until upheld by the Supreme Court is, however, quite correct.
Yeah, I think that too. And I was looking at the direction of the cash flow in this deal (which is in the direction that violates common sense) as proof.
Bruce, are you sure that Microsoft is paying Xandros?
When Microsoft did the deal with Novell, the money (mostly) went from Microsoft to Novell. They could spin this as "Novell's patents are worth more" or "Microsoft ships far more units". But Xandros can't have much of a patent portfolio, if any. So if Microsoft is paying them, it's real hard to spin. "Microsoft is paying Xandros so that Microsoft won't sue Xandros's customers." Uh, yeah. Why doesn't Microsoft just not sue, and keep their money?
If Microsoft paid, this would show that Microsoft is having to buy off distros for the distros to put themselves in an untenable position. Essentially, Microsoft is paying them to die.
Let's say you're going to do solar on a large scale. Say, an acre.
Making an acre of solar cells is hard. It takes a lot of exotic materials and a very expensive factory.
Making an acre of pond isn't hard. It takes a backhoe, or a number of low-skill workers. And then it takes water. It can even be contaminated water, as long as the contamination is compatible with algae. This is much easier, and much more available to the third world.
If you do it, and the company you "interview" with drops the headhunters as a result, the headhunters may sue you and/or your employer for tortuous interference with their business.
I'm not saying they would win, just that they are reasonably likely to try.
It's not just that we dislike software patents in general (though we do). We also dislike FUD, and we dislike lies.
Microsoft says that Linux infringes on a bunch of Microsoft's patents, but they won't tell us which ones. There's no attempt to present an issue and get it cleared up. There's only an attempt to tar Linux as publicly as possible with the "patent infringer" brush while providing nothing concrete that can be refuted. That's FUD.
Microsoft says that it can't tell us what the patents are that Linux infringes because it would be too much work. But they can count them and tell us what the number is. That excuse sure looks like a lie to me.
Being hostile to FUD and lies is not the same thing as being in favor of infringing Microsoft's patents, and that's why the original post was a strawman. If Microsoft tells us what the patents are, we'll either break the patents or fix the code. Until then, there's really nothing to talk about, except to tell Microsoft to put up or shut up.
One of the CPUs is running Linux. This code we compile with gcc on a Linux box.
Another CPU is running ThreadX. We cross-compile this on Windows using the Green Hills compiler.
A couple other CPUs run Nucleus OS. These are also cross-compiled on Windows using the Green Hills compiler.
We have gotten evaluations of KlokWorks and Coverity (and I've probably said enough here for them to figure out who we are). And they do good stuff, too. But I'm trying to look around to see what else is out there, since Coverity especially is pretty pricey, and KlokWorks didn't give us a long enough demo for us to really evaluate how well their tool found the kind of issues we are looking for.
As someone (CTO of KlokWorks?) said earlier, try before you buy...
Fair enough - as long as there are enough suppliers in the market to keep each other honest. If I've got two possible suppliers, and one will sell the product to me with no strings attached, and the other will try to control the price that I can sell the product at, all other things being equal, I'm going to choose to not have my hands tied. Enough other people are going to do likewise to make it painfully obvious to the first supplier that this is not what the market wants, and either he learns or he becomes a marginal player.
But if there aren't enough suppliers to check one another, then we get into either a monopoly situation or a price-fixing situation, and the free market breaks down. At that point, we need the law that makes this kind of thing illegal, for the exact same reason that we need the antitrust laws.
If you're happy with a world where brick and mortar retailers just can't exist, then by all means keep the current system and they will die, and not because of free market forces, but because manufacturers can't control their street prices.
Um, forgive me, but "because manufacturers can't control their street prices" sounds to me exactly like "free market forces". "Price control" is the antithesis of a free market.
Yeah, I would have preferred MI myself, though I must say that I've never actually needed it. So I think I have to disagree with your "most of the time".
One way around this is to figure out which is the "main" heirarchy and which is the "mixin" (one class dominates in terms of size, importance, number of methods, or some such). Then you have the mixin as a member of the main object, and pass the mixin object to the main object's constructor. Then you have to implement the methods that you would like to be members of the main class in the form of accessors to the same functions in the mixin class. Result: A lot of scaffolding and fooling around, but no "real" code duplicated.
But if you were to tell me that my approach is a total kludge to try to band-aid a language limitation, I really couldn't argue...
The technique you describe is useful, even powerful. Being able to think in that way is a great asset.
But if I understand you correctly, you think Java should have required us to program in that way. Quite simply, that's a very bad idea. It's just another set of chains and obstructions that a language imposes on you for no good reason.
The main thing it does is make it so that you can't have a totally abstract class, a partially abstract derived class, and a fully concrete class derived from that. For example, if I had a Vehicle class, and then Car, Truck, and Airplane classes that derived from Vehicle, and then Mustang, Aerostar, Boeing747, and F16 classes that derived from those, the problem would be that Car, Truck, and Airplane could only define new abstract methods. They couldn't implement any methods that were defined in Vehicle, but which would make sense to have all Car classes have the same implementation. Then each Car class would have to duplicate the common code. Bad idea.
Slashdot Mirror
I doubt it. I suspect that there's a court case on Monday unless Judge Kimball says that there isn't, and I suspect that he is quite unlikely to do so. Remember, about all that's left of the case is how much of Novell's money is SCO holding and refusing to give to Novell. SCO going bankrupt doesn't alter the case, it merely adds more urgency to it.
I seem to recall[*] that SCO told the court that there was no need for a constructive trust to protect Novell's money, since they (SCO) were in no danger of bankruptcy.
;-)
Now SCO is facing the exact same judge on Monday morning over the issue of how much money they owe Novell. I predict an interesting day in court
* OK, I was reminded of it by something someone (anonymous, so I can't give credit) said on Groklaw.
Did they just argue that they haven't admitted that they were doing it, but they can't talk about doing it because it would threaten national security? Um, hello? First, it's true that you're not supposed to be able to sue on a hypothetical situation. SCO aside, there's supposed to be a real issue before you can sue. But the government seems to be saying that they have to admit to the wiretapping before they can be sued for it. IANAL, but I don't believe that's how it works, not even for the federal government. Second, maybe "we can't talk about it" is precisely why they haven't admitted it? So, maybe, not admitting it doesn't mean a thing? I hope and expect that the judge can see right through this rubbish...
Um... thanks, guys, and it's nice of you to say so publicly and all that, but I already had those rights, because the law said I had them. I don't need your say-so, or any corporation's. Just the law. Hard as it is to believe, the law is actually what gives us the right to do stuff, not your permission.
Note well: A well-run country is a benefit. Not being taxed to death to pay for a bunch of pork is a benefit. Honesty and integrity in government is a benefit.
... just before the next big thing comes along.
What's the next big thing? I have no idea. I'm just like everybody else, noticing that not much has changed lately...
I am completely guessing.
But from the article, they had to hit IIS with a specially-crafted URL to exploit this. So, let's see, what can we do with a specially-crafted URL? We can do shell code into a buffer. If we know where the dangling pointer points, and where incoming URLs are placed, we might even be able to get our shell code where the dangling pointer points to. Then all we have to do is get the pointer called (assuming it's a function pointer... maybe a bad assumption). This could be done with another, immediately-following request, or it might happen automatically (if we can also make the circumstances that cause the pointer to be called occur with the same URL without messing up the shell code).
If it's a data pointer, I think it still depends on getting part of the URL into where the data pointer points. Say it points to a structure, and in that structure is a text buffer, and also in it is a function pointer. Now we can call an arbitrary function anywhere in ISS's memory image, with arbitrary data. That's got to be pretty easy to exploit. Once again, though, we also have to get the pointer used.
So as far as I can see, there are two things that are needed - being able to get the data from the URL into the memory where the dangling pointer points, and getting the pointer to be used. How you have to do those things will be highly application-specific, I would imagine...
Oh... that army...
... then I can bother to care about whether Linux (or anything else) infringes.
Until then, they can get lost.
I believe that the prior art has to predate the filing by more than one year, so we need something before January 1995.
IANAL.
But the judge didn't rule it unenforceable because there was no law stating that clickwrap agreements were valid. He ruled that the terms were so one-sided that it was "unconscionable" (horribly one-sided), and therefore invalid. If the same terms were in a shrinkwrap license, or even a signed contract, the same terms would have had the same problem.
The statement that it doesn't apply everywhere until upheld by the Supreme Court is, however, quite correct.
Yeah, I think that too. And I was looking at the direction of the cash flow in this deal (which is in the direction that violates common sense) as proof.
Bruce, are you sure that Microsoft is paying Xandros?
When Microsoft did the deal with Novell, the money (mostly) went from Microsoft to Novell. They could spin this as "Novell's patents are worth more" or "Microsoft ships far more units". But Xandros can't have much of a patent portfolio, if any. So if Microsoft is paying them, it's real hard to spin. "Microsoft is paying Xandros so that Microsoft won't sue Xandros's customers." Uh, yeah. Why doesn't Microsoft just not sue, and keep their money?
If Microsoft paid, this would show that Microsoft is having to buy off distros for the distros to put themselves in an untenable position. Essentially, Microsoft is paying them to die.
Let's say you're going to do solar on a large scale. Say, an acre.
Making an acre of solar cells is hard. It takes a lot of exotic materials and a very expensive factory.
Making an acre of pond isn't hard. It takes a backhoe, or a number of low-skill workers. And then it takes water. It can even be contaminated water, as long as the contamination is compatible with algae. This is much easier, and much more available to the third world.
If you do it, and the company you "interview" with drops the headhunters as a result, the headhunters may sue you and/or your employer for tortuous interference with their business.
I'm not saying they would win, just that they are reasonably likely to try.
It's not just that we dislike software patents in general (though we do). We also dislike FUD, and we dislike lies.
Microsoft says that Linux infringes on a bunch of Microsoft's patents, but they won't tell us which ones. There's no attempt to present an issue and get it cleared up. There's only an attempt to tar Linux as publicly as possible with the "patent infringer" brush while providing nothing concrete that can be refuted. That's FUD.
Microsoft says that it can't tell us what the patents are that Linux infringes because it would be too much work. But they can count them and tell us what the number is. That excuse sure looks like a lie to me.
Being hostile to FUD and lies is not the same thing as being in favor of infringing Microsoft's patents, and that's why the original post was a strawman. If Microsoft tells us what the patents are, we'll either break the patents or fix the code. Until then, there's really nothing to talk about, except to tell Microsoft to put up or shut up.
When they are used in the 2008 election, will the code they are running match the audited source code?
They would be prosecuted by the American military's satellite-killer missiles.
Sadly, I'm not entirely sure that I'm joking...
Are police helicopters "similar"? I'd say so.
They started using them about 30 years ago...
We're on an embedded system with several CPUs.
One of the CPUs is running Linux. This code we compile with gcc on a Linux box.
Another CPU is running ThreadX. We cross-compile this on Windows using the Green Hills compiler.
A couple other CPUs run Nucleus OS. These are also cross-compiled on Windows using the Green Hills compiler.
We have gotten evaluations of KlokWorks and Coverity (and I've probably said enough here for them to figure out who we are). And they do good stuff, too. But I'm trying to look around to see what else is out there, since Coverity especially is pretty pricey, and KlokWorks didn't give us a long enough demo for us to really evaluate how well their tool found the kind of issues we are looking for.
As someone (CTO of KlokWorks?) said earlier, try before you buy...
Bugs in general.
Fair enough - as long as there are enough suppliers in the market to keep each other honest. If I've got two possible suppliers, and one will sell the product to me with no strings attached, and the other will try to control the price that I can sell the product at, all other things being equal, I'm going to choose to not have my hands tied. Enough other people are going to do likewise to make it painfully obvious to the first supplier that this is not what the market wants, and either he learns or he becomes a marginal player.
But if there aren't enough suppliers to check one another, then we get into either a monopoly situation or a price-fixing situation, and the free market breaks down. At that point, we need the law that makes this kind of thing illegal, for the exact same reason that we need the antitrust laws.
Um, forgive me, but "because manufacturers can't control their street prices" sounds to me exactly like "free market forces". "Price control" is the antithesis of a free market.
Yeah, I would have preferred MI myself, though I must say that I've never actually needed it. So I think I have to disagree with your "most of the time".
One way around this is to figure out which is the "main" heirarchy and which is the "mixin" (one class dominates in terms of size, importance, number of methods, or some such). Then you have the mixin as a member of the main object, and pass the mixin object to the main object's constructor. Then you have to implement the methods that you would like to be members of the main class in the form of accessors to the same functions in the mixin class. Result: A lot of scaffolding and fooling around, but no "real" code duplicated.
But if you were to tell me that my approach is a total kludge to try to band-aid a language limitation, I really couldn't argue...
But if I understand you correctly, you think Java should have required us to program in that way. Quite simply, that's a very bad idea. It's just another set of chains and obstructions that a language imposes on you for no good reason.
The main thing it does is make it so that you can't have a totally abstract class, a partially abstract derived class, and a fully concrete class derived from that. For example, if I had a Vehicle class, and then Car, Truck, and Airplane classes that derived from Vehicle, and then Mustang, Aerostar, Boeing747, and F16 classes that derived from those, the problem would be that Car, Truck, and Airplane could only define new abstract methods. They couldn't implement any methods that were defined in Vehicle, but which would make sense to have all Car classes have the same implementation. Then each Car class would have to duplicate the common code. Bad idea.