Google has been answering simple questions since 2005. It was the first 20% time project a friend of mine worked on when he joined the company. I remember that if you asked it "where in the world is Carmen Sandiego" it inexplicably said "Cairo, Egypt". Here's a screen cap showing exactly that from 2005: http://www.capsgetpeeled.com/blog/archives/000473.html
I remember Slashdot had an article about this back then and there's was a google blog or press release, but I can't find either. Anyone remember what this feature was called or have a link?
Thanks for the link. That press release is surprisingly technical makes it clear that this has nothing to do with a successor to the MPEG4 codec / container format. It relates to:
*2) MPEG-7 Video signature tools: This is an amendment to MPEG-7 Visual, a standard for content description interface for multimedia content that has been established as an international standard for identification technology of video content, as ISO/IEC 15938-3/Amd.4.
There currently exist handful of different techniques for creating small signatures (76 bytes in this case) of a video frame. Content companies create sequences of signatures for all their videos and distribute the sequences. Youtube can then create a sequence of signatures for an uploaded file, compare it against all known sequences, and then do whatever with that knowledge.
The MPEG group is just standardizing on one particular technique for creating the signatures, distributing them, and comparing them. In that case this is something sensable for the MPEG group to do, and isn't really good or evil.
1. There was a constant inspection regime paid for entirely by the industry. In other words, there is an armed government official with absolute power to stop drilling, and his salary paid entirely by whoever owns the well and the platform.
So similar to the Mine Safety and Health Administration? Or how about the SEC? We've seen how well those have worked out. Any time you have a small regulatory body working in a single industry you end up with conflicts of interest. Industry players come into the agency to control it, ex-agency employs go to industry to show how to game it, and lots of expensive dinners all around.
2. All caps on liability were removed and the owners of the well and platform were forced to pay all costs of a spills, without limit of any kind. 3. Any evidence of ignoring of safety requirements would lead to lengthy prison sentences for all involved, and a ban on the companies involved in the accident of no less than five years from any extraction.
Both of those amount to "bankrupt any company that has an incident". Remember that for 2) "pay all costs, without limit" actually means "pay all costs until the company goes bankrupt". While that might sound great to you in theory, in practice it's a terrible idea. Take a look at Arthur Anderson - exactly what you describe happened to them after Enron. Did 85,000 employees that had absolutely nothing to do with Enron deserve to have their lives thrown into chaos as the company imploded? Also bankrupting BP wouldn't really do anything structurally - the other big oil companies (Shell, Exxon, etc) would just pick up the pieces and everything would go on as if nothing happened.
The only thing I agree with you on is the need for criminal action against directors. Far too often companies see regulatory fines (and appeals to avoid them) as simply part of the cost of doing business, as is blatantly obvious in the case of Massey's WV mining operation. Start threatening criminal action against supervisors for repeat offenses and they'll suddenly have a real incentive to implement real protocols.
Frankly, even equally worrisome is that Matlab doesn't appear to take advantage of GPGPU yet. The concept has been around for over half a decade, and I'd have expected the MAtrix LABoratory to jump on the bandwagon quicker than most. It's a game changer in their core competency, after all.
I guess it depends on the exact question you're asking. A google search for "matlab gpgpu" shows that there are lots of ways to take advantage of GPGPU (NVidia's CUDA specifically) from within Matlab. MATLAB plug-in for CUDA AccelerEyes GPUmat
However AFAIK there's no plan for native support of GPGPU within Matlab. It's kind of ridiculous that there's not considering the 10x speedup frequently reported by using the above tools.
They seized various forms of ID: business cards, an Amex card, check stubs, etc. That way someone can't claim after the fact that they never lived at a particular location and so none of the seized stuff is theirs.
Obviously in this case he's not going to want the computers back so will say they are his, but it makes sense as part of standard operating procedure for warrants. I'm sure there have been more than one case where a defendant has tried to get evidence (drugs, computers, records, whatever) thrown out claiming they never were at the location it was seized from.
I'm amazed at how many people want to shoot anyone that's ever lost a portable device before. No matter what safeguards you have in place, no matter how perfect your employees are, portable devices *will* get lost. It's simply a fact of life.
Once you accept that devices will be lost it becomes a question of how do you handle the losses that will happen. Apple had clearly thought about this and the phone was remote-wiped overnight. I'm also sure this is not the first prototype phone to be lost. It just happens to be the first one that got sold to a blog.
When an accountant leaves a laptop full of SSN numbers lying around I don't blame him. I blame the IT guy that allowed a laptop full of SSN numbers out of the building unencrypted. Full-disk encryption's not that hard to setup and makes losing the laptop essentially a non-issue.
Do you have a reference to the fact that the battery needs to run at 350C? It seems a bit impractical to heat a house-sized building that much, especially when you have lost power.
The main advantage of a battery over a generator is that you can switch power over to it in a matter of seconds. I'm guessing a 4MW generator would take a couple of minutes, maybe 10s of minutes, to spin up to capacity.
It's amazing the game of telephone that happens when blogs steal news stories from blogs that steal news stories from blogs.
Inhabitat: "Electric Transmission Texas ponied up $25 million to build the battery, and will add $60 million to build a second transmission line by 2012."
PopSci: "Electric Transmission Texas helped put the battery project together for around $25 million. But the utility has also agreed to build a second 60-mile transmission line to Presidio for about $44 million by 2012."
NPR: "The other solution for this town would be to build a second line, and that line would cost somewhere in the range of $40 to $50 million. And so a battery project in the $25 million range looks pretty attractive."
They all agree the battery costs $25mill, 2/3 agree that the 2nd transmission line will be built in 2012, and none of them agree on the price of the 2nd line.
Woah, that's huge. According to billshrink's comparison there are only 300 apps currently for the Pre. The lack of apps was the #1 reason I haven't bought a Pre yet.
This should let them easily get 10x the number of current apps for a relatively cheap price. Also since there are so few apps to start with it should be fairly easy for any descent app to at least get the $1k prize.
Actually the fact they make crappy voting machines is fairly well known. Diebold is (trying to) sell off their voting division because it's been such a nightmare. From some random local news outlet's report:
The deal, announced before the markets opened Thursday, effectively closes the chapter on a sore spot in Diebold's storied 150-year history.
"The elections business has been a PR nightmare and a huge distraction for management," said analyst Gil Luria, vice president of research for Wedbush Morgan Securities Inc. in Los Angeles.
Yeah there hasn't been a front-page article in USA Today or anything like that. However anyone that knows about Diebold (aka not most of the general public) certainly know how much they've screwed up.
I think the most interesting part was the (lack of) answer about how the compression works.
They claim 80ms round-trip latency from button push to image display. Running a game on a server and screen-scraping in ~20ms is fairly easy. With proper datacenter placement and peering agreements ~50ms round-trip ping times are reasonable (if somewhat optimistic). The issue is how do you compress the 720p image and send it back in 10ms with reasonable bandwidth.
They're claiming 1ms compression, 8ms decompression (125hz), and 5mbit 720p streams. The compression is using a custom ASIC, so that's completely believable. Decompressing at 120hz on any generic hardware (they specifically said no GPU help) means it has to be an extremely simple protocol. The biggest question is how do you reach "HD-quality" at only 5mbit when you are not doing group-of-pictures compression (keyframes and diffs from the keyframe). Mind you that a standard DVD is 10mbit, so they're claiming higher resolution with half the bitrate and no keyframing. Obviously H264 gets better quality/bit than DVDs, but it does so by using even more complex keyframing and diffs and is far too CPU intensive for their target platforms (it's hard to watch 30fps H264 trailers on many machines, let alone a 60fps stream). The only hint he gave was some mumbling about visual perception, and the statement that their compression only looks good in motion (if you paused the stream it would look terrible).
I've been using the Ion window manager for years. The principle behind it is keyboard-controlled tabbed and tiled windows. There's an entire wiki list of similar tiling window managers, which are all also tabbed window managers. Ion will also let you create non-tilled windows that are still tabbed, so exactly what KDE is now doing.
WMs that can do this have been around forever, but it's nice that they're finally going more "mainstream". I'm still never going to use KDE or Gnome (way to heavyweight), but it's nice that they might be a more reasonable option in the future.
A number of emulators already have good algorithms for scaling fixed-pixel images that preserve the sharpness while removing aliasing. Wikipedia of course has a page on Pixel art scaling algorithms. The 2 best ones out there are 2xSal and hqx.
The problem is that these only work within emulators that implement the algorithms. This clearly does not work for something like StarCraft. Graphics drivers (both ATI and NV) already have options to scale between virtual and physical resolutions. The ideal solution would be for them to offer different scaling algorithms that can be picked - standard bilinear or a modified one for classic games. Everything "just works" then and you get nice graphics.
I'm not going to hold my breath on ATI or NV ever officially implementing this in their release drivers. However I'm wondering how hard it would be to add an option like this to one of the open source linux X drivers, or maybe even to Wine/DosBox. Also for windows isn't there a way to intercept graphics calls (along the lines of what FRAPs does)? Would it be possible to create a wrapper program that intercepts all the graphics calls and adds a scaling algorithm after each frame is drawn?
It's pretty clear that whoever designed this API didn't even take an passing glance at the security or reliability implications. There are 2 ways (from the linked slides) for a merchant to report cashback activity to MS:
1) Tracking pixel: this gives instant update to the user, but is completely insecure and also fairly unreliable (image fails to load, cross site https issues, random network hickup, etc).
2) FTP upload of a plain text list: yes really, plain old FTP. This is at least reliable but is only authenticated by a plain-text user/pass. The list does not have any signature for authentication.
I'm not a web guy at all (I'm an ASIC hardware guy) and off the top of my head I can think of 2 real solutions:
The right way: SOAP. Gives instant update to the user, should be trivial in any backend web language, is reliable, is trivial to encrypt (https), is trivial to authenticate (a simple shared secret would be enough).
A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different). As an added bonus a cryptographic signature should be added to the list.
The problem with simply adding a MAC to the existing tracking pixel is that it doesn't fix the reliability issue. Also the advantage of the current tracking pixel is that it's stupidly easy to implement. If you're going to load in some libraries to do the MAC calculation on the server, you might as well load in a SOAP library and do the transaction properly.
It really boggles the mind that a bogus transaction could actually be paid out. That indicates there is absolutely no auditing or rationalization between what the e-tailer thinks should be paid out and what MS thinks should be paid out. Even something as stupid as end-of-month totals should flag that there are bogus transactions.
Also the guy who posted this is an idiot for placing a $100,000 transaction which would result in a $2,000 payment, and then bragging about it. His two $1 transactions proved the vulnerability and the $0.06 payment generated is easily ignored. The $100k transaction with $2k payment is just flat out wire fraud asking for federal PMITA prison.
Ive never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Lets see how these transactions might have accidentally got credited to my account.
First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this:
This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. Im not going to explain exactly how to generate the fake requests so that they actually post, but its not complicated. Bing doesnt seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have cleared, and Im guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.
Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I havent done enough work to say it with confidence, but a malicious user might be able to block another users legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order IDs (e.g. sequential), a malicious user can use up all the future order IDs, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.
Based on what Ive found, I wouldn't implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, Ill demonstrate some other subtle but important reasons to avoid using Bing Cashback.
It seems like people have still not learned to never trust anything from the user. This reminds me of some trivially exploitable web merchants years ago. The would store the entire shopping basket, including prices, in the user's cookies. User simply modifies their cookies so that everything costs $1 or $0.01 and they could order a dozen cpus / t-shirts / whatever for a few bucks.
I'm quite happy with the Garmin bike GPS I have. It downloads the data in a pseudo-proprietary format, but it's easy to convert into an XML format that's fully documented on their website: http://developer.garmin.com/schemas/
Also for those that use linux, here's a couple of scripts that sync down the garmin data, do the XML transformation, and uploads it to garmin connect: http://braiden.org/?p=62
I expect that in this case it's those who were shareholders in 2006 suing the company, who are likely no longer shareholders. In that case it's fairly reasonable. Say someone bought stock in 2005 and then sold it in 2006 when shit hit the fan for a substantial loss. That person can now recoup some of the their losses.
Also Take Two had some sort of crazy umbrella insurance (how do you get "our directors are incompetent" insurance?) so the insurance company is ponying up $15M of the $20M.
I wonder if I could manage to pull this off at a personal level. Get an umbrella insurance policy. Crash my car into a tree. Sue myself(defendant) for the pain and suffering caused due to the negligence of myself(plaintiff). If I(plaintiff) win, I(defendant) get the insurance company to cover 3/4ths of the settlement cost.
What on earth is the point of something with a 3 hour life that you have to recharge every day, and yet barely puts out any light? You could trivially power a massive, blinding LED array off the same power source and be 10x as visible.
First of all it's "north of San Fransisco" and by North they mean it's actually North of Santa Rosa. And it looks to be about 20 miles north of that up near Clear Lake. And if you go to their project site and look at the map at the bottom, you'll notice in the past week there's been 3.0 or larger earth quakes in that region. The 3.4 they had in Basel looks to be just another daily occurrence in those parts.
Santa Rosa's not exactly far from San Francisco. And since it's just Santa Rosa that's close you're fine with them being leveled in an earthquake?
Also you fail to note that those "daily occurrences" are only there because of other, much smaller, geothermal plants next door. If 3.0's are acceptable daily occurrences from the smaller plants, then would 4.0's or 5.0's be acceptable daily occurrences from this new, larger plant?
Slashdot Mirror
The server's crashing, but coral cache managed to get the text:
http://sol.gfxile.net.nyud.net/ddhack/
Erm, does Kazakhstan count as Bumfuckistan? Because if it does, they apparently have "a single field [that] stands ready to produce two-thirds as much oil each day as the entire gulf does". Also according to geologists Afghanistan has "nearly $1 trillion in untapped mineral deposits".
Google has been answering simple questions since 2005. It was the first 20% time project a friend of mine worked on when he joined the company. I remember that if you asked it "where in the world is Carmen Sandiego" it inexplicably said "Cairo, Egypt". Here's a screen cap showing exactly that from 2005:
http://www.capsgetpeeled.com/blog/archives/000473.html
I remember Slashdot had an article about this back then and there's was a google blog or press release, but I can't find either. Anyone remember what this feature was called or have a link?
Thanks for the link. That press release is surprisingly technical makes it clear that this has nothing to do with a successor to the MPEG4 codec / container format. It relates to:
There currently exist handful of different techniques for creating small signatures (76 bytes in this case) of a video frame. Content companies create sequences of signatures for all their videos and distribute the sequences. Youtube can then create a sequence of signatures for an uploaded file, compare it against all known sequences, and then do whatever with that knowledge.
The MPEG group is just standardizing on one particular technique for creating the signatures, distributing them, and comparing them. In that case this is something sensable for the MPEG group to do, and isn't really good or evil.
So similar to the Mine Safety and Health Administration? Or how about the SEC? We've seen how well those have worked out. Any time you have a small regulatory body working in a single industry you end up with conflicts of interest. Industry players come into the agency to control it, ex-agency employs go to industry to show how to game it, and lots of expensive dinners all around.
Both of those amount to "bankrupt any company that has an incident". Remember that for 2) "pay all costs, without limit" actually means "pay all costs until the company goes bankrupt". While that might sound great to you in theory, in practice it's a terrible idea. Take a look at Arthur Anderson - exactly what you describe happened to them after Enron. Did 85,000 employees that had absolutely nothing to do with Enron deserve to have their lives thrown into chaos as the company imploded? Also bankrupting BP wouldn't really do anything structurally - the other big oil companies (Shell, Exxon, etc) would just pick up the pieces and everything would go on as if nothing happened.
The only thing I agree with you on is the need for criminal action against directors. Far too often companies see regulatory fines (and appeals to avoid them) as simply part of the cost of doing business, as is blatantly obvious in the case of Massey's WV mining operation. Start threatening criminal action against supervisors for repeat offenses and they'll suddenly have a real incentive to implement real protocols.
I guess it depends on the exact question you're asking. A google search for "matlab gpgpu" shows that there are lots of ways to take advantage of GPGPU (NVidia's CUDA specifically) from within Matlab.
MATLAB plug-in for CUDA
AccelerEyes
GPUmat
However AFAIK there's no plan for native support of GPGPU within Matlab. It's kind of ridiculous that there's not considering the 10x speedup frequently reported by using the above tools.
They seized various forms of ID: business cards, an Amex card, check stubs, etc. That way someone can't claim after the fact that they never lived at a particular location and so none of the seized stuff is theirs.
Obviously in this case he's not going to want the computers back so will say they are his, but it makes sense as part of standard operating procedure for warrants. I'm sure there have been more than one case where a defendant has tried to get evidence (drugs, computers, records, whatever) thrown out claiming they never were at the location it was seized from.
I'm amazed at how many people want to shoot anyone that's ever lost a portable device before. No matter what safeguards you have in place, no matter how perfect your employees are, portable devices *will* get lost. It's simply a fact of life.
Once you accept that devices will be lost it becomes a question of how do you handle the losses that will happen. Apple had clearly thought about this and the phone was remote-wiped overnight. I'm also sure this is not the first prototype phone to be lost. It just happens to be the first one that got sold to a blog.
When an accountant leaves a laptop full of SSN numbers lying around I don't blame him. I blame the IT guy that allowed a laptop full of SSN numbers out of the building unencrypted. Full-disk encryption's not that hard to setup and makes losing the laptop essentially a non-issue.
Do you have a reference to the fact that the battery needs to run at 350C? It seems a bit impractical to heat a house-sized building that much, especially when you have lost power.
The main advantage of a battery over a generator is that you can switch power over to it in a matter of seconds. I'm guessing a 4MW generator would take a couple of minutes, maybe 10s of minutes, to spin up to capacity.
It's amazing the game of telephone that happens when blogs steal news stories from blogs that steal news stories from blogs.
Inhabitat: "Electric Transmission Texas ponied up $25 million to build the battery, and will add $60 million to build a second transmission line by 2012."
PopSci: "Electric Transmission Texas helped put the battery project together for around $25 million. But the utility has also agreed to build a second 60-mile transmission line to Presidio for about $44 million by 2012."
NPR: "The other solution for this town would be to build a second line, and that line would cost somewhere in the range of $40 to $50 million. And so a battery project in the $25 million range looks pretty attractive."
They all agree the battery costs $25mill, 2/3 agree that the 2nd transmission line will be built in 2012, and none of them agree on the price of the 2nd line.
Woah, that's huge. According to billshrink's comparison there are only 300 apps currently for the Pre. The lack of apps was the #1 reason I haven't bought a Pre yet.
This should let them easily get 10x the number of current apps for a relatively cheap price. Also since there are so few apps to start with it should be fairly easy for any descent app to at least get the $1k prize.
The demo page of the voicemail app is extremely shiny. Google voice transcription of the voicemail shown in real-time with playing the voicemail.
Then again I can't remember the last time I got a voice mail, so who actually cares.
Actually the fact they make crappy voting machines is fairly well known. Diebold is (trying to) sell off their voting division because it's been such a nightmare. From some random local news outlet's report:
Yeah there hasn't been a front-page article in USA Today or anything like that. However anyone that knows about Diebold (aka not most of the general public) certainly know how much they've screwed up.
I think the most interesting part was the (lack of) answer about how the compression works.
They claim 80ms round-trip latency from button push to image display. Running a game on a server and screen-scraping in ~20ms is fairly easy. With proper datacenter placement and peering agreements ~50ms round-trip ping times are reasonable (if somewhat optimistic). The issue is how do you compress the 720p image and send it back in 10ms with reasonable bandwidth.
They're claiming 1ms compression, 8ms decompression (125hz), and 5mbit 720p streams. The compression is using a custom ASIC, so that's completely believable. Decompressing at 120hz on any generic hardware (they specifically said no GPU help) means it has to be an extremely simple protocol. The biggest question is how do you reach "HD-quality" at only 5mbit when you are not doing group-of-pictures compression (keyframes and diffs from the keyframe). Mind you that a standard DVD is 10mbit, so they're claiming higher resolution with half the bitrate and no keyframing. Obviously H264 gets better quality/bit than DVDs, but it does so by using even more complex keyframing and diffs and is far too CPU intensive for their target platforms (it's hard to watch 30fps H264 trailers on many machines, let alone a 60fps stream). The only hint he gave was some mumbling about visual perception, and the statement that their compression only looks good in motion (if you paused the stream it would look terrible).
Any ideas as to how the compression works?
Thankfully a project by the same company just north of San Francisco has been shut down. The last thing CA needs is more earthquakes.
http://www.nytimes.com/2009/12/12/science/earth/12quake.html
I've been using the Ion window manager for years. The principle behind it is keyboard-controlled tabbed and tiled windows. There's an entire wiki list of similar tiling window managers, which are all also tabbed window managers. Ion will also let you create non-tilled windows that are still tabbed, so exactly what KDE is now doing.
WMs that can do this have been around forever, but it's nice that they're finally going more "mainstream". I'm still never going to use KDE or Gnome (way to heavyweight), but it's nice that they might be a more reasonable option in the future.
And then I notice that DosBox already has this implemented: http://www.dosbox.com/wiki/Scaler
It should be fairly straightforward for Wine to implement a similar feature.
A number of emulators already have good algorithms for scaling fixed-pixel images that preserve the sharpness while removing aliasing. Wikipedia of course has a page on Pixel art scaling algorithms. The 2 best ones out there are 2xSal and hqx.
The problem is that these only work within emulators that implement the algorithms. This clearly does not work for something like StarCraft. Graphics drivers (both ATI and NV) already have options to scale between virtual and physical resolutions. The ideal solution would be for them to offer different scaling algorithms that can be picked - standard bilinear or a modified one for classic games. Everything "just works" then and you get nice graphics.
I'm not going to hold my breath on ATI or NV ever officially implementing this in their release drivers. However I'm wondering how hard it would be to add an option like this to one of the open source linux X drivers, or maybe even to Wine/DosBox. Also for windows isn't there a way to intercept graphics calls (along the lines of what FRAPs does)? Would it be possible to create a wrapper program that intercepts all the graphics calls and adds a scaling algorithm after each frame is drawn?
It's pretty clear that whoever designed this API didn't even take an passing glance at the security or reliability implications. There are 2 ways (from the linked slides) for a merchant to report cashback activity to MS:
1) Tracking pixel: this gives instant update to the user, but is completely insecure and also fairly unreliable (image fails to load, cross site https issues, random network hickup, etc).
2) FTP upload of a plain text list: yes really, plain old FTP. This is at least reliable but is only authenticated by a plain-text user/pass. The list does not have any signature for authentication.
I'm not a web guy at all (I'm an ASIC hardware guy) and off the top of my head I can think of 2 real solutions:
The right way: SOAP. Gives instant update to the user, should be trivial in any backend web language, is reliable, is trivial to encrypt (https), is trivial to authenticate (a simple shared secret would be enough).
A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different). As an added bonus a cryptographic signature should be added to the list.
The problem with simply adding a MAC to the existing tracking pixel is that it doesn't fix the reliability issue. Also the advantage of the current tracking pixel is that it's stupidly easy to implement. If you're going to load in some libraries to do the MAC calculation on the server, you might as well load in a SOAP library and do the transaction properly.
It really boggles the mind that a bogus transaction could actually be paid out. That indicates there is absolutely no auditing or rationalization between what the e-tailer thinks should be paid out and what MS thinks should be paid out. Even something as stupid as end-of-month totals should flag that there are bogus transactions.
Also the guy who posted this is an idiot for placing a $100,000 transaction which would result in a $2,000 payment, and then bragging about it. His two $1 transactions proved the vulnerability and the $0.06 payment generated is easily ignored. The $100k transaction with $2k payment is just flat out wire fraud asking for federal PMITA prison.
It seems like people have still not learned to never trust anything from the user. This reminds me of some trivially exploitable web merchants years ago. The would store the entire shopping basket, including prices, in the user's cookies. User simply modifies their cookies so that everything costs $1 or $0.01 and they could order a dozen cpus / t-shirts / whatever for a few bucks.
I'm quite happy with the Garmin bike GPS I have. It downloads the data in a pseudo-proprietary format, but it's easy to convert into an XML format that's fully documented on their website: http://developer.garmin.com/schemas/
Also for those that use linux, here's a couple of scripts that sync down the garmin data, do the XML transformation, and uploads it to garmin connect: http://braiden.org/?p=62
I expect that in this case it's those who were shareholders in 2006 suing the company, who are likely no longer shareholders. In that case it's fairly reasonable. Say someone bought stock in 2005 and then sold it in 2006 when shit hit the fan for a substantial loss. That person can now recoup some of the their losses.
Also Take Two had some sort of crazy umbrella insurance (how do you get "our directors are incompetent" insurance?) so the insurance company is ponying up $15M of the $20M.
I wonder if I could manage to pull this off at a personal level. Get an umbrella insurance policy. Crash my car into a tree. Sue myself(defendant) for the pain and suffering caused due to the negligence of myself(plaintiff). If I(plaintiff) win, I(defendant) get the insurance company to cover 3/4ths of the settlement cost.
What on earth is the point of something with a 3 hour life that you have to recharge every day, and yet barely puts out any light? You could trivially power a massive, blinding LED array off the same power source and be 10x as visible.
Santa Rosa's not exactly far from San Francisco. And since it's just Santa Rosa that's close you're fine with them being leveled in an earthquake?
Also you fail to note that those "daily occurrences" are only there because of other, much smaller, geothermal plants next door. If 3.0's are acceptable daily occurrences from the smaller plants, then would 4.0's or 5.0's be acceptable daily occurrences from this new, larger plant?