Defendant gets caught. Labels offer to settle for a relatively low amount. Defendant declines, thinking she actually has a viable defense.
Defendant's case is so weak, she losses on summary judgement. She gets lucky, though, and the court finds she qualifies for the innocent infringement damage reduction. Even with that reduction, the minimum damages the court can award are considerably larger than she could have settled for. The record companies will accept this and let the matter end, but reserve the right to appeal the damages if she appeals the infringement.
Instead of showing some inkling of intelligence and cutting her losses, she appeals, and so the record labels cross-appeal.
Her appear fails, of course (that's what happens when you have no even remotely viable grounds for appeal). The labels' appear succeeds, and the minimum damages go up by a factor of 3.
The defendants really should start hiring competent counsel.
That method does work as long as you guarantee the uniqueness of the random numbers--in other words, a tie shouldn't mean leaving elements in place, but rather repeating the algorithm on each subset of the list where the random numbers came up equal
You responded
No - look at the example of the two-element list in the link I provided. I'll copy it here for convenience:
Puzuma is right. The example you provide does not guarantee uniqueness. In the four cases is analyzes, two of them involve assigning the same random number to both elements.
In practice, this is not a problem when shuffling a small array, because most people use a random number generator with more possible outputs than the 1/0 used in that example. If your random number generator has a range of [0, 2^32-1], for instance, then you'll end up with non-unique sort values about once every 400 million shuffle attempts. That's good enough for most applications.
As Puzma notes, you can fix this by noting elements that are assigned the same random number and repeating the process on them. Here's a Perl implementation that does that:
sub randomize_array(@)
{
my @out;
my %h;
map {push @{$h{rand()}}, $_} @_;
map {push @out, @{$h{$_}} == 1 ? $h{$_}[0] : randomize_array(@{$h{$_}})} keys %h;
return @out;
}
Even if you were to restrict the random number generator to just returning 0 or 1 (by changing rand() to int(rand(2))), the above will produce properly shuffled arrays.
As I stated in a previous post it likely won't catch on among more technical audiences, but it has a fair chance (especially considering Apple puts thought into the UI unlike every netbook vendor) among the "I just want it to work" audience, which is far, far larger
A lot of us geeks like things that just work, too.
The work is in fact a copyrighted work by Microsoft. Cryptome was in fact in violation Microsoft's copyright.
Having read the document, I don't see anything in there that is important. Basically, Microsoft will turn over various kinds of data to law enforcement when legally compelled to, and they only turn over what they are required to. In other words, nothing we didn't already know or suspect. It's not like there is some kind of secret whistleblower information in there.
I suspect that the main reason Microsoft cares about its release is that it includes contact information for law enforcement to contact Microsoft, including telephone numbers, which invites harassment. Cryptome should have redacted that before publishing.
Since msft got away with doing the same thing to TomTom, I suppose these deals are effectively legal
TomTom was threatening Microsoft over TomTom patents. We have no information as to who threatened whom first in the TomTom case. All we know is that they negotiated over each other's patents for over a year, before negotiations broke down and both sides filed lawsuits. We also know that TomTom has a history of suing over its patents, having sued Garmin and several of Garmin's customers.
Microsoft struck a patent deal with struggling Novel, and it feels very similar to what we see here. The implication: Novel agrees its use of Linux somehow infringed on Microsoft's patents, and that it (and by extension everyone else) must pay Microsoft to use Linux.
Is there any serious disagreement about Linux distributions infringing patents? In a speech against software patents, Stallman cited a whole bunch of patents the Linux likely infringes, as part of his argument that software patents are harmful.
Anyway, the Novell deal is not Novell agreeing that Linux infringes patent. It is Novell agreeing that business customers worry that Linux might infringe patents. That's one of the reasons these kind of deals are often broad cross licensing agreements.
Vista was mostly looked badly because they introduced new security features.
I think a much bigger factor was that it was so long between XP and Vista, people had forgotten what XP was like at the start. When XP launched, it received many of the same complaints Vista received. It wasn't until a couple of service packs that people started to like XP. After a couple of service packs, Vista too was fine.
No way a site called microsofttaxdodge.com would be biased, right?
It's quite common for companies to structure transactions so that they are taxed in a jurisdiction with a low tax rate. Just as Microsoft is doing with Nevada, Google does with Ireland to save on UK taxes. Microsoft also uses Ireland for European stuff, as does, I believe Apple. These are just the tip of the iceberg.
There's nothing shady about it. All of those companies are international companies with a presence in many different jurisdictions.
It's weird. When I've tried Bing for regular search, its been better than Google. Mainly, I think that is because people selling things have really honed in on optimizing their sites for Google, so when I search for some technical information, half the results are useless companies trying to sell me something slightly related. They haven't concentrated on doing that to Bing yet, so right now its more useful.
Bing maps has a much nicer interface than Google. Same for their video search.
Yet most of my searching remains with Google. As near as I can tell, I'm simply too lazy to change. Google has become such a habit it doesn't matter that Bing might actually be better.
Wow, you're the first person I've heard that's said anything more than "meh" about the ipad
Then you haven't listened very hard. The people who have actually used it are usually pretty enthusiastic about it, as they get what its for, and it looks like it's going to be fantastic at that.
and they've made a very specific point of missing that boat for at least the last decade. They're marketing to fanboys who want it to be trendy and 'just work', not to nerds
They don't have to market to nerds. Nerds buy Macs without needing to be marketed to. That's why Macs are significantly overrepresented among top geeks.
Even better, you had the first Fry's, Weird Stuff across one street from that, and across the other street you had a branch of Computer Literacy books, and a Togo's. Hit Fry's and Weird Stuff, then go pick up a magazine or book at Computer Literacy, and grab a large hot #7 at Togo's and eat it while reading the book or magazine.
Proof that there is no God: Togo's only has one location in Washington (where I live now), so my sandwich needs have to be met by Subway and Quizno's, neither of which comes within an order of magnitude of the goodness that is Togo's.
FUD. Microsoft Office 2007 for Windows and 2008 for Mac support OOXML just fine.
Yes, there are minor validation errors if you validate documents against the transitional schema (mostly because some attribute values were changed late during standardization, such as true/false changing from 1/0 to "true"/"false"). However, OpenOffice documents have at least as many similar errors when you validate them against ODF, so unless you also claim that OpenOffice doesn't support ODF, your claim is just FUD.
There are legitimate technical criticisms of OOXML, so why do so many of its opponents have to resort to lying about it?
For home machines or desktop machines, the occasional reboot for patches is not problem.
For servers, you want to reboot after any significant change to the code running on your system, to verify the change didn't break booting. It is very annoying when a server fails to start properly after a power failure or the replacement of broken hardware, and it turns out to be due to a change someone made weeks or months ago.
It's been my experience that the software that reports a problem will get blamed for causing the problem
I've seen that quite a bit. I work at a small anti-virus/anti-spyware company.
If our software finds a problem that McAfee or Symantec misses, out come the accusations that we have a deliberate false positive to scare the user into buying the product, or even worse, the accusations that we actually put the virus on the system.
On the other hand, if we fail to find a problem that McAfee or Symantec reports (even if it is a false positive), out come the accusations that our product does a poor job of detecting problems!
Others have argued that, while the specification is less specific than one might like, the intent is fairly clear (especially since formulas tend to follow decades-long traditions), and also because the vast majority of spreadsheets only use a small set of functions (such as SUM) which are universally supported by all spreadsheet implementations anyway. In practice, many developers look to OpenOffice.org as a "canonical implementation"; since its code is public for anyone to review, and its XML output can be inspected, this can resolve many questions
Lots of FUD there. Let's take one, truncateFontHeightsLikeWP6, and compare to how it is done in ODF.
Let's say you have a bunch of WP6 documents. You have reverse engineered the WP6 format. You have tools that take documents in that format and do interesting things with them, like typeset them for the magazine you publish.
You want to switch to using ODF in your workflow, and are writing a converter to convert WP6 documents to ODF. However, when you run across things in WP6 that just aren't representable in ODF, you want to somehow preserve them, so that (1) your converter can convert back to WP6 without losing anything, and (2) your internal tools recognize and format things correctly when using the ODF form of your converted docs.
So what you are going to do is use one of the mechanisms ODF provides to embed information beyond the standard, and use this to embed the extra information. That way, your converted WP6 documents work fine for you, and if they are ever sent to someone else, the extra information will be ignored.
Suppose that I have done a similar thing--my workflow also revolved around WP6 format, and I'm converting to ODF, with extra info for the WP6 that doesn't fit.
Wouldn't it be nice if my ODF+WP6 documents could work with your workflow, and your ODF+WP6 documents would work with my workflow? But alas, we probably picked different ways to add the WP6 info--and even if we picked similar ways, we probably named things differently. Sucks, doesn't it?
All truncateFontHeightsLikeWP6 and similar in OOXML were doing is trying to address that last part. Basically, what truncateFontHeightsLikeWP6 in OOXML is saying is "hey! anyone out there who has figured out WP6 font height stuff and is going to embed information about that in their OOXML document, use this name for it, so that you'll all be on the same page. Everyone else, ignore it".
A large part of that is because it gives many examples and gives detailed specifications for spreadsheets functions (several pages per function for some of the more complicated functions).
ODF is quite a bit more concise, by completely leaving such things out.
I mean, there's a clear relationship here that I find very amusing. Microsoft's OOXML, while sure to be empirically more interoperable with most users due to the pervasity of Microsoft Office, is not logically more interoperable due to the nature of what MS has done to the "open" standard.
Read both specs. Given two independent developers who have to implement entirely from the spec, they are for more likely to produce interoperable implementations if they use OOXML than if they use ODF.
Only the kind of stupid Americans that though that restricting the export of encryption technology would actually work[...]
I'm curious. How do the stupid Americans who think that differ from the stupid Europeans who think that? Or were you not aware that European countries and the EU also have similar export restrictions?
Slashdot Mirror
The defendants really should start hiring competent counsel.
Ambiguous Puzuma wrote:
That method does work as long as you guarantee the uniqueness of the random numbers--in other words, a tie shouldn't mean leaving elements in place, but rather repeating the algorithm on each subset of the list where the random numbers came up equal
You responded
No - look at the example of the two-element list in the link I provided. I'll copy it here for convenience:
Puzuma is right. The example you provide does not guarantee uniqueness. In the four cases is analyzes, two of them involve assigning the same random number to both elements.
In practice, this is not a problem when shuffling a small array, because most people use a random number generator with more possible outputs than the 1/0 used in that example. If your random number generator has a range of [0, 2^32-1], for instance, then you'll end up with non-unique sort values about once every 400 million shuffle attempts. That's good enough for most applications.
As Puzma notes, you can fix this by noting elements that are assigned the same random number and repeating the process on them. Here's a Perl implementation that does that:
sub randomize_array(@)
{
my @out;
my %h;
map {push @{$h{rand()}}, $_} @_;
map {push @out, @{$h{$_}} == 1 ? $h{$_}[0] : randomize_array(@{$h{$_}})} keys %h;
return @out;
}
Even if you were to restrict the random number generator to just returning 0 or 1 (by changing rand() to int(rand(2))), the above will produce properly shuffled arrays.
As I stated in a previous post it likely won't catch on among more technical audiences, but it has a fair chance (especially considering Apple puts thought into the UI unlike every netbook vendor) among the "I just want it to work" audience, which is far, far larger
A lot of us geeks like things that just work, too.
The work is in fact a copyrighted work by Microsoft. Cryptome was in fact in violation Microsoft's copyright.
Having read the document, I don't see anything in there that is important. Basically, Microsoft will turn over various kinds of data to law enforcement when legally compelled to, and they only turn over what they are required to. In other words, nothing we didn't already know or suspect. It's not like there is some kind of secret whistleblower information in there.
I suspect that the main reason Microsoft cares about its release is that it includes contact information for law enforcement to contact Microsoft, including telephone numbers, which invites harassment. Cryptome should have redacted that before publishing.
Since msft got away with doing the same thing to TomTom, I suppose these deals are effectively legal
TomTom was threatening Microsoft over TomTom patents. We have no information as to who threatened whom first in the TomTom case. All we know is that they negotiated over each other's patents for over a year, before negotiations broke down and both sides filed lawsuits. We also know that TomTom has a history of suing over its patents, having sued Garmin and several of Garmin's customers.
Microsoft struck a patent deal with struggling Novel, and it feels very similar to what we see here. The implication: Novel agrees its use of Linux somehow infringed on Microsoft's patents, and that it (and by extension everyone else) must pay Microsoft to use Linux.
Is there any serious disagreement about Linux distributions infringing patents? In a speech against software patents, Stallman cited a whole bunch of patents the Linux likely infringes, as part of his argument that software patents are harmful.
Anyway, the Novell deal is not Novell agreeing that Linux infringes patent. It is Novell agreeing that business customers worry that Linux might infringe patents. That's one of the reasons these kind of deals are often broad cross licensing agreements.
Unless you are Robert R. Coveyou, you should have attributed that.
Vista was mostly looked badly because they introduced new security features.
I think a much bigger factor was that it was so long between XP and Vista, people had forgotten what XP was like at the start. When XP launched, it received many of the same complaints Vista received. It wasn't until a couple of service packs that people started to like XP. After a couple of service packs, Vista too was fine.
Any technological endeavor human beings work towards will always be subject to "more eyeballs means improvement".
So that's why the more people there are on the committee that designed a language or protocol, the better the result. I'd always wondered about that.
No way a site called microsofttaxdodge.com would be biased, right?
It's quite common for companies to structure transactions so that they are taxed in a jurisdiction with a low tax rate. Just as Microsoft is doing with Nevada, Google does with Ireland to save on UK taxes. Microsoft also uses Ireland for European stuff, as does, I believe Apple. These are just the tip of the iceberg.
There's nothing shady about it. All of those companies are international companies with a presence in many different jurisdictions.
Clue: e-ink does not melt your eyes like a TFT with a backlight...
Anyone got a cite to actual research that backs this?
The Kindle handles non-DRM content fine.
It's weird. When I've tried Bing for regular search, its been better than Google. Mainly, I think that is because people selling things have really honed in on optimizing their sites for Google, so when I search for some technical information, half the results are useless companies trying to sell me something slightly related. They haven't concentrated on doing that to Bing yet, so right now its more useful.
Bing maps has a much nicer interface than Google. Same for their video search.
Yet most of my searching remains with Google. As near as I can tell, I'm simply too lazy to change. Google has become such a habit it doesn't matter that Bing might actually be better.
Wow, you're the first person I've heard that's said anything more than "meh" about the ipad
Then you haven't listened very hard. The people who have actually used it are usually pretty enthusiastic about it, as they get what its for, and it looks like it's going to be fantastic at that.
and they've made a very specific point of missing that boat for at least the last decade. They're marketing to fanboys who want it to be trendy and 'just work', not to nerds
They don't have to market to nerds. Nerds buy Macs without needing to be marketed to. That's why Macs are significantly overrepresented among top geeks.
Even better, you had the first Fry's, Weird Stuff across one street from that, and across the other street you had a branch of Computer Literacy books, and a Togo's. Hit Fry's and Weird Stuff, then go pick up a magazine or book at Computer Literacy, and grab a large hot #7 at Togo's and eat it while reading the book or magazine.
Proof that there is no God: Togo's only has one location in Washington (where I live now), so my sandwich needs have to be met by Subway and Quizno's, neither of which comes within an order of magnitude of the goodness that is Togo's.
FUD. Microsoft Office 2007 for Windows and 2008 for Mac support OOXML just fine.
Yes, there are minor validation errors if you validate documents against the transitional schema (mostly because some attribute values were changed late during standardization, such as true/false changing from 1/0 to "true"/"false"). However, OpenOffice documents have at least as many similar errors when you validate them against ODF, so unless you also claim that OpenOffice doesn't support ODF, your claim is just FUD.
There are legitimate technical criticisms of OOXML, so why do so many of its opponents have to resort to lying about it?
For home machines or desktop machines, the occasional reboot for patches is not problem.
For servers, you want to reboot after any significant change to the code running on your system, to verify the change didn't break booting. It is very annoying when a server fails to start properly after a power failure or the replacement of broken hardware, and it turns out to be due to a change someone made weeks or months ago.
It's been my experience that the software that reports a problem will get blamed for causing the problem
I've seen that quite a bit. I work at a small anti-virus/anti-spyware company.
If our software finds a problem that McAfee or Symantec misses, out come the accusations that we have a deliberate false positive to scare the user into buying the product, or even worse, the accusations that we actually put the virus on the system.
On the other hand, if we fail to find a problem that McAfee or Symantec reports (even if it is a false positive), out come the accusations that our product does a poor job of detecting problems!
This is what you consider the right way?
Others have argued that, while the specification is less specific than one might like, the intent is fairly clear (especially since formulas tend to follow decades-long traditions), and also because the vast majority of spreadsheets only use a small set of functions (such as SUM) which are universally supported by all spreadsheet implementations anyway. In practice, many developers look to OpenOffice.org as a "canonical implementation"; since its code is public for anyone to review, and its XML output can be inspected, this can resolve many questions
Lots of FUD there. Let's take one, truncateFontHeightsLikeWP6, and compare to how it is done in ODF.
Let's say you have a bunch of WP6 documents. You have reverse engineered the WP6 format. You have tools that take documents in that format and do interesting things with them, like typeset them for the magazine you publish.
You want to switch to using ODF in your workflow, and are writing a converter to convert WP6 documents to ODF. However, when you run across things in WP6 that just aren't representable in ODF, you want to somehow preserve them, so that (1) your converter can convert back to WP6 without losing anything, and (2) your internal tools recognize and format things correctly when using the ODF form of your converted docs.
So what you are going to do is use one of the mechanisms ODF provides to embed information beyond the standard, and use this to embed the extra information. That way, your converted WP6 documents work fine for you, and if they are ever sent to someone else, the extra information will be ignored.
Suppose that I have done a similar thing--my workflow also revolved around WP6 format, and I'm converting to ODF, with extra info for the WP6 that doesn't fit.
Wouldn't it be nice if my ODF+WP6 documents could work with your workflow, and your ODF+WP6 documents would work with my workflow? But alas, we probably picked different ways to add the WP6 info--and even if we picked similar ways, we probably named things differently. Sucks, doesn't it?
All truncateFontHeightsLikeWP6 and similar in OOXML were doing is trying to address that last part. Basically, what truncateFontHeightsLikeWP6 in OOXML is saying is "hey! anyone out there who has figured out WP6 font height stuff and is going to embed information about that in their OOXML document, use this name for it, so that you'll all be on the same page. Everyone else, ignore it".
A large part of that is because it gives many examples and gives detailed specifications for spreadsheets functions (several pages per function for some of the more complicated functions).
ODF is quite a bit more concise, by completely leaving such things out.
Such as?
I mean, there's a clear relationship here that I find very amusing. Microsoft's OOXML, while sure to be empirically more interoperable with most users due to the pervasity of Microsoft Office, is not logically more interoperable due to the nature of what MS has done to the "open" standard.
Read both specs. Given two independent developers who have to implement entirely from the spec, they are for more likely to produce interoperable implementations if they use OOXML than if they use ODF.
Only the kind of stupid Americans that though that restricting the export of encryption technology would actually work[...]
I'm curious. How do the stupid Americans who think that differ from the stupid Europeans who think that? Or were you not aware that European countries and the EU also have similar export restrictions?