I've found that data returned by Kraken's OHLC API function is highly inconsistent. It is clear that the data returned by the API for "committed" (historical data) frames changes over time. Often by very large amounts!

To demonstrate this, I ran two identical API calls (simply using my web browser) approximately one minute apart. See the screenshots below. I would have expected committed/historical OHLC frames to remain static over time, but this is not the case. Am I doing something wrong or misunderstanding how this is supposed to work?

I had a thought that it might be nice to automate backups of the wallet file.
Certainly this is not beyond the realm of moderately advanced users already, through scheduled system tasks/cron/whatnot, but those are not the ones who are likely to find themselves with a corrupted or deleted wallet, or a too-old wallet backup. I've found that even moderately technical people still fail to understand that wallet backups decay over time.

How would the community feel about the addition of an automated wallet backup option - through the standard backup interface, give the option to automatically take a new backup whenever new private keys are added to the wallet. Bonus points if the backup screen can detect the presence of cloud storage folders (eg. dropbox) to suggest these locations. Perhaps it would be prudent in such scenarios to require the wallet be encrypted in order to enroll in automated backup.

Has anyone had a fan go bad yet? What's your story?

The number of Bitcoins generated per block starts at 50 and is halved every 210,000 blocks.

That will be an interesting day.

[alleviated]

My mining rig is also my database server, so I can't have the mining processes consuming 100% of the CPU. Unfortunately, this driver issue is as yet unresolved by AMD.

However, the problem can be alleviated, though not completely eliminated, if your processor has more than one core. In the screenshot below, you can see my mining processes are very low now. They still fully consume the resources of one core, however.

Furthermore, this action may increase the hashing rate on some systems. In my case, I went from 1.3Ghash/s to 1.5Ghash/s (dual 6990) with this change, because the database server was competing with poclbm.exe for CPU resources.

Here's how: