If they're hard coded, I bet they have production branches with the prod keys and dev branches with the dev keys.

What are the chances there are undocumented APIs now vulnerable to attack (Hint: much, much greater than 0%) There are bound to be APIs made for special events or superstar streamers that are going to be instant targets now. This is going to be fun to watch.

People are saying it's untraceable because you can generate new public keys whenever you want. In this way, you can use a different key for each person/vendor you interact with, or you can use a new key for each transaction if so desired. Whether going to these extremes makes it completely untraceable or not, I cannot say, but it does make it a heck of a lot harder if you do go to such extremes.

Neither is it silicon. The point of the article is we have a potential silicon replacement for use in specialized cases. This kind of thing paves the way for interactive packaging or other embedded uses that silicon is just too big for.

Great, now you want the [bury] button for elections. I guess well see candidates named Topt Enreasonstovoteforme come out of the woodwork for that one.

So they created a magnetic spring that will pull as well as push. I can see how that would be an improvement over metal springs that will break over time, but I can see a whole slew of other problems arising from the need to properly shield the darn things to keep particulates from sticking and creating friction.

Wow, I forgot about this one. Sadly, it mirrors exactly what I did. It wasn't very strong though.

Or, to save time, you could just try querying the Twitter API for any tweets with the #earthquake tag, check the location of said tweets, and plug those into Google maps. Or, for an even faster (but more constrained) result, you could just check the USGS Did You Feel It? map. http://earthquake.usgs.gov/earthquakes/dyfi/events/us/2010xwa7/us/index.html

It exists! https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom Now we wait for no-script.

http://forums.macrumors.com/showpost.php?p=9840543&postcount=11 All the pages loaded from a local source (as seen in the image linked), so this is a render demo only. I will admit that the render speeds are lightning fast and I've come to prefer Chrome over FF for my casual browsing. However, If I'm doing research of any kind, I know I'm going to have some 50+ tabs and until Chrome has a tree style tab plugin, FF has the job.

Yeah, that's what happens to all my coinage too.

I personally find this interesting as it essentially states that Apple doesn't trust the end user. Now read my logic before you mod me troll.

A company rarely researches something without a reason, so Apple has obviously seen enough loss from warranty replacement to try to find some way to shift the blame from themselves to the consumer for a product's failure. They have also apparently justified this by seeing a large percentage of these replacements being approved by inaccurate failure descriptions from users. If this is true, the new sensors would be a (somewhat) legitimate countermeasure.

Or Apple could just be looking for a way to shift the blame to the users by just stating, "You broke it, we have sensors that prove it," regardless of what really happened.

Either way, it amounts to declaring war on the end users on the warranty front.

That's right. Seek it from the man pages. For example, man ifconfig is all about teaching yourself how to communicate.

Fixed that for you.

Emacs is a good OS, but if there's one thing it needs, it's a good word processor.