If you had read the article, you would have noticed that there is already an open-source implementation, and this patent covenant applies precisely to that implementation (as well as modified versions thereof). The only thing it doesn't apply to are video codecs, for which Microsoft probably doesn't own the patents, and therefore doesn't have the rights to create such a covenant on.
I don't know if they _need_ the income, but I'm sure they have plenty of excess capacity from reserved instances that aren't running for starters, not to mention the pool for on-demand instances. It's just a smart business move to try to exploit this.
There's no custom quote for increasing the instance limit - it's just a safety to prevent someone with a stolen credit card from spawning enough instances to use up all available capacity. You just put in a request and have it lifted; pricing stays the same.
Look at it from their point of view - all they want to do is win their games, too. The only difference is, instead of bet/no bet, their choice is bar/don't bar from the premises.
When you sue, you ask for as much as you could ever possibly imagine to get. It doesn't mean you'll get that much; but you certainly won't get more than you ask for, so in the starting phases you just ask for the world. If she actually got $10 million, that'd be another matter.
If the defense's lawyer was worth his salt, this was something the jury decided, as it's a question of fact. So before you start complaining about such things, get the actual court documents, see if the defense even bothered to raise this point (if you don't argue a point, you concede it, after all), and if so, how it played out.
Speculating on how an entire trial went on from a few pages worth of an article in the BBC is pointless; neither of us have seen enough to even begin to estimate whether the prosecution was placing things out of context and distorting their meaning as you suggest.
If you had read the article, you'd have seen that they were matching up the email contents with what they were seeing with good old fashioned surveillance.
Unfortunately, it's not so easy to do this. When embedding a watermark, there are three fundamental approaches:
Add some metadata to a nice, seperately partitioned out part of the file. While this is easy, persistent, and doesn't inconvenience the user, it's also very easy to remove.
Change the content in a way that's not perceptible to the user. The problem here is that these tend to be removed by lossy compression - the lossy compressor uses a model of human perception to remove information that's not perceptible, and your watermark's no exception.
Change the content in a way that is perceptible to the user. While this works, it's also very annoying.
So it's not an easy problem, and as compression improves, option #2 there will get even harder over time.
Unfortunately I don't have access to the journal in question - my university proxy doesn't even work:/
I wonder if this means doping ice with extra protons for conductance or similar? It seems like it'd take a lot of energy to rip a proton off a H2O molecule stuck in the crystal matrix.
Sure, but you'd have to produce the actual machine for examination. If it actually worked, then you would have an instant ticket to fame and fortune, and probably end up as renowned as Einstein and Newton.
If it didn't work, on the other hand, you'd be ridiculed and forgotten, of course.
Why not set a rate limit on entropy consumption then?
Re:This may seem obvious to some, but...
on
Google Wave Reviewed
·
· Score: 1, Funny
Given how chaotic and unstable Wave is at the moment (based on my experiences with it anyway), I think "on crack" is a very good metaphor for the situation right now.
This could be helped by making deals with the ISPs, where the gaming datacenter is peered directly with the ISP's core network, and in exchange the ISP doesn't meter (or gives a higher limit for) the data going across this peering.
And what's the problem with that? Any server worth its salt will have a small battery backup for its drive array to keep it running until array/disk write caches can be flushed anyway.
The problem isn't scanning metadata - the problem is relocating data prior to an erase. Flash memory is built into erase blocks that are quite large - 64k to 128k is typical. You can write to smaller regions, but to reset them for another write you have to pave over the neighborhood. However the OS is sending writes at the 512-byte sector granularity. So the drive has to essentially mark the old location for the data as obsolete, and place it somewhere else.
When the drive has been used enough, however, it may have trouble finding an empty, erased sector to write to. So it has to erase some erase block. But if all erase blocks still have good data (eg, each has half used, important data and half obsolete, overwritten data), you need to relocate some of that data elsewhere.
What the trim command does is tell the drive that it need not preserve the data of a given sector - otherwise, if you were to delete a file, the drive would still have to preserve its data each time one of these relocation operations occur, since it doesn't know anything about the filesystem's allocation maps. By using TRIM, the drive is aware of what data is deleted, and can thus be discarded when it's time to erase blocks. It also increases the percentage of truly unused flash sectors, increasing the probability that a write can go through without having to wait for a relocation.
Note that this is completely independent from filesystem fragmentation - indeed, a defrag can even make things worse, by making the flash drive think both old and new locations for some data need preserving.
Slashdot Mirror
If you had read the article, you would have noticed that there is already an open-source implementation, and this patent covenant applies precisely to that implementation (as well as modified versions thereof). The only thing it doesn't apply to are video codecs, for which Microsoft probably doesn't own the patents, and therefore doesn't have the rights to create such a covenant on.
I don't know if they _need_ the income, but I'm sure they have plenty of excess capacity from reserved instances that aren't running for starters, not to mention the pool for on-demand instances. It's just a smart business move to try to exploit this.
There's no custom quote for increasing the instance limit - it's just a safety to prevent someone with a stolen credit card from spawning enough instances to use up all available capacity. You just put in a request and have it lifted; pricing stays the same.
Losing energy always results in a loss of rest mass, so there's nothing unexpected about that.
And here are the real webcams.
When hadrons collide, leptons certainly do come out as debris; I'm sure the LHC will be dealing with plenty of them soon enough.
They added Disallow: /voice/fm/ to robots.txt for google.com, that's all.
Look at it from their point of view - all they want to do is win their games, too. The only difference is, instead of bet/no bet, their choice is bar/don't bar from the premises.
When you sue, you ask for as much as you could ever possibly imagine to get. It doesn't mean you'll get that much; but you certainly won't get more than you ask for, so in the starting phases you just ask for the world. If she actually got $10 million, that'd be another matter.
Moreover, even if one wanted to install pirated software, such software would likely come signed anyway - meaning you wouldn't even _need_ those keys.
If the defense's lawyer was worth his salt, this was something the jury decided, as it's a question of fact. So before you start complaining about such things, get the actual court documents, see if the defense even bothered to raise this point (if you don't argue a point, you concede it, after all), and if so, how it played out.
Speculating on how an entire trial went on from a few pages worth of an article in the BBC is pointless; neither of us have seen enough to even begin to estimate whether the prosecution was placing things out of context and distorting their meaning as you suggest.
If you had read the article, you'd have seen that they were matching up the email contents with what they were seeing with good old fashioned surveillance.
Here's how I'd break this:
Buy a copy of the ebook.
Now have a friend buy another copy.
Compare the two copies, zero out (or otherwise remove) any differences. Done.
So it's not an easy problem, and as compression improves, option #2 there will get even harder over time.
Hmm, it seems that this article might be somewhat relevant: Proton semiconductors and energy transduction in biological systems
:/
Unfortunately I don't have access to the journal in question - my university proxy doesn't even work
I wonder if this means doping ice with extra protons for conductance or similar? It seems like it'd take a lot of energy to rip a proton off a H2O molecule stuck in the crystal matrix.
Protons moving? Do you have a citation for this? I don't see any reason for protons to move more freely in ice than anything else.
Sure, but you'd have to produce the actual machine for examination. If it actually worked, then you would have an instant ticket to fame and fortune, and probably end up as renowned as Einstein and Newton.
If it didn't work, on the other hand, you'd be ridiculed and forgotten, of course.
Why not set a rate limit on entropy consumption then?
Given how chaotic and unstable Wave is at the moment (based on my experiences with it anyway), I think "on crack" is a very good metaphor for the situation right now.
If the work isn't a copyright work, then wouldn't this not apply?
This could be helped by making deals with the ISPs, where the gaming datacenter is peered directly with the ISP's core network, and in exchange the ISP doesn't meter (or gives a higher limit for) the data going across this peering.
Surely it's far more embarrassing for the person on the receiving end of the attack.
And what's the problem with that? Any server worth its salt will have a small battery backup for its drive array to keep it running until array/disk write caches can be flushed anyway.
The problem isn't scanning metadata - the problem is relocating data prior to an erase. Flash memory is built into erase blocks that are quite large - 64k to 128k is typical. You can write to smaller regions, but to reset them for another write you have to pave over the neighborhood. However the OS is sending writes at the 512-byte sector granularity. So the drive has to essentially mark the old location for the data as obsolete, and place it somewhere else.
When the drive has been used enough, however, it may have trouble finding an empty, erased sector to write to. So it has to erase some erase block. But if all erase blocks still have good data (eg, each has half used, important data and half obsolete, overwritten data), you need to relocate some of that data elsewhere.
What the trim command does is tell the drive that it need not preserve the data of a given sector - otherwise, if you were to delete a file, the drive would still have to preserve its data each time one of these relocation operations occur, since it doesn't know anything about the filesystem's allocation maps. By using TRIM, the drive is aware of what data is deleted, and can thus be discarded when it's time to erase blocks. It also increases the percentage of truly unused flash sectors, increasing the probability that a write can go through without having to wait for a relocation.
Note that this is completely independent from filesystem fragmentation - indeed, a defrag can even make things worse, by making the flash drive think both old and new locations for some data need preserving.
Could it just be that since cola typically contains some sodium, the hyponatremia doesn't occur, and all that's left is hypokalemia?