Oh the Humanities!

In response to your question about the "Don't Talk to Cops" video: OK, but what did he mean?

He means, guilty or not, if you are under suspicion of a crime, the cops are NOT looking for evidence to exonerate you. They are looking for anything and everything that can be used to prove your guilt. Including twisting your words in such a way to make you sound as if you were lying or trying to hide something.

They are not really different things.

Sarah Palin was obviously not OK with a private citizen snooping on her private emails. However, do you think she IS OK with her provider giving her private emails to the NSA?

Flood the app store with thousands of shitty apps so no one can find the ones that are actually useful. I wonder how well that will work for them.

Summary of TFS: There is no spoon.

Yeah but that headline is too long and might get cut o

My wife is on her second husband so I guess she's on her way to becoming a husbandry geek.

Um... Lauren is a dude and I'm pretty sure he knows what he's talking about.

Damn. So close. Almost made it to the end without a typo!

Was there a link in the email that took them to a page to confirm their login information before Google deleted there accounts?

He should have used the SarcMark[!]

I've never been able to get a full understanding of an unfamiliar project by simply reading the code (and mapping out relationships, though I have done that from time to time). The most insight (for me at least) comes from running the code, changing it to see how it breaks, and running it again. Nothing tells you more about a piece of code than seeing how it works normally, then seeing how your changes affect it.

By deliberately breaking it. When you make a change and something else breaks you know immediately that those components are coupled. No reading/mapping required. Once that coupling is identified you can focus your code reading to understanding how tightly or loosely coupled they really are.

Rinse and repeat. It might seem simplistic or naive, however, once you've spent hours/days reading and mapping code, you're ultimately going to need to run it and modify it. In which case you are going to break it and learn something about component interactions that reading alone didn't tell you. My personal preference is to skip all that business up front and dive in. I'll still end up reading all the code. Just focused on certain areas of functionality one at a time.

You will never fully understand the code just by reading it. My approach is to ignore all of it until something needs to be changed. When you need to change something, add a feature, etc... find where in the code the functionality is and tweak it a bit. See what happens. Tweak it some more. See what breaks. You will start to get a deep understanding of a focused section of the code and not have to worry (yet) about other unrelated areas. Start with small changes first. Larger changes may require a deeper understanding of the architecture and how pieces interact. This will come in time. After a few iterations of this and you will eventually become intimately familiar with all the pieces of the code.

Of course when called out on it he said he meant that the NSA doesn't read citizens email:
http://news.yahoo.com/blogs/ticket/intel-chief-clapper-gave-least-untruthful-answer-u-164742798.html
http://news.yahoo.com/blogs/ticket/spy-chief-clapper-denies-misleading-congress-spying-americans-221024826.html

Which 1) no longer denies phone records are collected and 2) no longer answers the question that was asked in the first place!

They don't need to decipher it in transit. They just send a NSL to the ISP to give it to them once it's been received.