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.

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:

https://ssl.search.live.com/cashback/pixel/index? jftid=0&jfoid=<orderid>&jfmid=<merchantid> &m[0]=<itemid>&p[0]=<price>&q[0]=<quantity>

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.

Man, this poll is missing a pile of options.

No Twist-lock? My favorite is L6-30, great for any sort of medium-powered application where you want to be damn sure no one can kick the extension cord loose. Also throw on some $5 rubber boots to make the connection waterproof.

No Nema 5-20P (the one with the neutral pin turned, so it forms a T)? It's a must for any high-powered amp or quite a few servers.

No Nema 10-30 (the dryer plug)? Sure it's kind a crappy outlet, but it's great when you need lots of power in a house. A friend of mine has a small arc welder that runs off that plug.

When you want to have some real fun, you turn to Cam-lok. Running 3-phase, 300 amp power 100 feet across a muddy field is no problem for these guys.

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?

It's not only where you are, but what part of the industry. From my experience most of the industry (Intel, AMD/ATI, Nvidia, etc) are all Verilog houses. On the other hand anything that interacts with the government (research labs, IBM, defense contractors) are VHDL houses.

But really, it doesn't matter in the long run since there are no fundamental differences between the two. The syntax will take you a month or so to get used to, but the hardware you're designing will be the same. The hard part of hardware design is not typing out the code, but creating a good micro-architectural design with good documentation and diagrams of how all the pieces connect together. Once you have a solid uarch, translating that into either Verilog or VHDL should be very straightforward.

From the C++ prototype guide, which is just the ISA made into a terribly complex C++ wrapper, they support these transcendental functions in the ISA:
EXP2_PS - Exponential Base-2 of Float32 Vector
LOG2_PS - Logarithm Base-2 of Float32 Vector
RECIP_PS - Reciprocal of a Float32 Vector
RSQRT_PS - Reciprocal of the Square Root of a Float32 Vector

They also provide library functions that implement everything else you'd want (sin, cos, etc) in software, I assume using Newton-Raphson iteration.

You just described ECC scrubbing and Chipkill. The technology's been around for a while, but it costs >$0 to implement so most people don't bother. As with most RAS features most people don't know anything about it, so would rather pay $50 less than have a strange feature that could end up saving them hours of downtime. At the same time if you actually know what these features are and you need them, you're probably going to be willing to shell out the money to pay for them.