Quite possible culprit is thermal transfer to the heatsink too. I've seen occurrences of thermal patches badly (or not at all) applied on the die. Five of the 8 PC laptops I owned suffered from that, and a cleanup + proper thermal paste cured it on three. The two others simply had bad design and just could not get the heat out for some reason.
Hey guys, this is a project I put together last night. I thought it would be great to gather photos and stories about the impact of K&R on your life as a programmer. So if you have a second, snap a photo with your copy of K&R. Upload via http://kandrandyou.org/submit. If you don't have tumblr (which I'm assuming most of you don't) you can post your image in this thread or send me an email at kyle.j.conroy+kandr@gmail.com
Overall they have great service. Only their Fremont location has been a bit touchy this year. I've been with them since the days they used UML before Xen and if it's any consolation, I have experienced at least one downtime in each DC(but this was over the course of many years now). Unless you plan for distributed systems, expect some failures from time to time no matter who is the provider.
From what I've encountered, and what I've read, Fremont has been the most patchy Linode DC - they've had two outages there recently. One just a day or two ago, and another in early May. Apparently there was a significant outage late last year too.
p.s. The last two weren't network outages - they were total power failures. Your 'node would have been hard-booted as a result.
Just a fluke. I've been a Linode customer since 2008 and have managed multiple Linodes (on the East coast) and as far as I can tell, Linode has given me more than four nines.
I like the concept of these wallets, but the idea of having to plug my wallet in every night to charge a battery is less than appealing. I think the simplicity of the wallet, especially in today's world of smart phones, is one of its most attractive features.
Wireless charging stations will probably prevail eventually. If they went that way, all you'd have to do is stick it next to your phone on a charging pad - you probably already have them near each other frequently.
Instead of writing your own blogging engine, I would suggest using one of the many extensible blogging platforms as a base and building from there.
I personally have become a huge fan of statically-generated blogs (using Jekyll[1] for Ruby or Hyde[2] for Python) as they integrate great with version control and require little maintenance. Another benefit is speed, as nginx serves static content with ease.
After reading the article, I looked into similar services available online. While I couldn't find any blogging sites, both WriteAPrisoner[1] and PrisonPenPals[2], while dated, offer to connect visitors with incarcerated pen pals.
Even more interesting, however, is that the State of Arizona banned these types of interactions in 2000[3], only to have to the law struck down as unconstitutional four years later. Specifically, the law banned any "attempts to correspond with a communication service provider or remote computing service" such as the sites listed above.
Arizona is notorious for all kinds of crap like this. For instance, they regularly use exposure - putting people out in the sun - as punishment. One women died as a result of this treatment, and no one was prosecuted: http://blogs.phoenixnewtimes.com/bastard/2010/09/marcia_powe...
I think the fact that this uses blogs to make the communication one-to-many, rather than connect individuals outside to individuals inside (one-to-one), is a crucial distinction.
When internet access becomes a human right, will prisoners ever be able to get it? This has become an issue since media companies wanted to cut individuals off for breaching copyright, with extensive collateral damage, but I think it has big implications for prisoners rights as well.
Meta HN: Why can't HN allow us to create text anchors, like the rest of the web, reddit, etc. These in-line URLs are getting old, at least to my eyes. HN readers know how to create anchors; this isn't Facebook.
Facebook can't claim that "every person owns and controls his/her information" when the Graph API allows access (via friends permissions) to your friends' status, likes, notes, location, photos, relationships, checkins, website, groups, events, activities and birthdays[1].
In fact, the only information about your friends not available via friends permissions are email addresses and full streams.
Your photos are easily accessible using the Graph API[1]. I wrote a python script which downloads all your photos and saves them to your computer[2]. However, I agree that Facebook doesn't make it easy for other web services to access stored data.
genuine question (this sounds a little smarmy but I know nothing about Graph API or web dev at all really): How is it not easy for other web services to access this stored data when a random guy can easily throw a script on GitHub to do it?
Not sure if this is the right answer, but a guess: it's easy for other web services to access this stored data if the user provides them with their Facebook login and password, which no self-respecting service would ever ask for. Even if Google did at one point get users to give up their facebook credentials, the API's they access will probably block IP's that try to access multiple users' data in a short amount of time.
The best solution, IMO, is to use the browser as a platform: a Chrome extension can allow users to seamlessly sync data between services, because Chrome already has access both to your Facebook account and your Picasa account.
With the Facebook API, the user doesn't have to provide any third party his credentials to allow the third party to access his data. Facebook uses OAuth to securely pass an access token to the third party while protecting the user's credentials. See http://developers.facebook.com/docs/authentication/ for more info.
Ah, but if I remember correctly, the terms of that OAuth usage explicitly state that while data may be accessed and used, it can't be stored indefinitely (with good reason, sometimes I don't want some app toy to indefinitely store all the information I trust Facebook with). So if a third party uses that API as an export mechanism, their API access should be (rightfully) shut down.
BUT - what if I actually want to export all of my photos into SomeApp.com, and I want to give SomeApp the right to store my photos indefinitely? Is there an API they can use to pull it from Facebook directly?
It used to be the case that apps could only store your data for 24 hours, but we removed this restriction in the last f8 conference.
You can definitely export all your photos into SomeApp.com using the graph API and they can store your photos indefinitely. These APIs are documented at http://developers.facebook.com/docs/api.
It is perfectly easy for other web services to access the data of a logged-in Facebook user, provided that the user has granted permission via Facebook Connect. This is how Facebook's "Download your Data" product[1] works; it is entirely implemented through publicly available graph APIs.
What Google is insisting on is "download my friends' data." This is where Facebook currently draws the line; we make it easy to retrieve your own data programmatically, while retrieving your friends' data programmatically is harder.
And, whatever Google says, Facebook is right to draw the line somewhere, and probably at friends' contact info. Consider an immediate consequence of doing what Google is insisting on: Zynga (e.g.) will spam all of their users' friends' emails. Because now they can retrieve them in bulk via a Facebook API. If you use Facebook, and tomorrow you started getting reams of email from applications you do not use, would you think, "How wonderful that Facebook has finally liberated my data!"? Or would you, maybe, be annoyed, and wonder why Facebook would ever consider making such a boneheaded decision?
Ridiculous. Facebook could whitelist only the user, not any proxy, to download whatever data friends already make available to users inside the boundaries of privacy controls. This is only sensible since it's already exposed to the user. If the user dedicated human time to archiving a bunch of web pages, they could reconstruct their contacts. But it's much simpler for the computer to do it.
The user could sell out their friends to a third party if they chose to (opt in). But Zynga would only get access if the user said so.
The reason Facebook won't do it is that it would commoditize the social graph and allow straight head to head competition on features. I think no one, even Facebook, knows how that would turn out...
Except for Google, who clearly decided to make it happen.
The Facebook API allows 3rd party applications to access most of the user's data, including the user's email, if the user grants the application the required permissions. More details are at http://developers.facebook.com/docs/authentication/permissio....
1. you are doing some computationally heavy task or 2. your fan may be faulty
Simple as that.