Since world wide harddrive storage being created is about 40 exabytes per year and the Internet has about 50 exabytes of traffic per month, I would still say you're crazy to think that all traffic is recorded. They have to be filtering out a decent amount of it. According to the NSA, how ever much you can trust this, they only inspect about 1.5% of all traffic, of which storage is only a subset. So they're not recording anywhere near "all" traffic.

Maybe we need to start padding stuff like SSH sessions to increase bandwidth usage to consume "idle" bandwidth. I'm not sure how one would implement this, but it would dramatically increase how much data needs to be stored.

Being "social" is all about interacting. If you don't interact, you're not social and may as well not be a human. Until humans figure out a way to reproduce asexually, we'll need to interact. Even asexual organisms are still social because there is safety in numbers. I guess what I'm saying is that what others are doing is logical, you're the illogical one. Don't be so eager to pass judgement.

Nope, you're at more risk because of the common password changes. I think it's 3-6 months. Should be using 2 factor.

So they can "break" IPSEC by compromising the end nodes? Isn't that like saying "We can break into your house if we can get inside of it"?

With current understanding of handshakes, having access to controlling the hand shake gains you nothing. Both ends can still detect something is wrong. The only real way to MITM is to have access to the certs, magical computers, or knowledge of a flaw/bug in the protocol or implementation.

Extradition almost exclusively applies to to laws in other countries that would be also be considered criminal in the USA. Kill someone in Thailand, well murder is criminal in the USA, so they'll extradite you. Slander someone, well, that's not criminal in the USA, so you're safe. The USA also will not extradite if they think the punishment may be considered "extreme".

I wonder what they mean by "GPA". There is a strong correlation between smart people and doing poorly in studies outside of what they're good at or becoming bored due to too easy of classes.

IPv6+IPSEC will prevent seeing which ports you're using.

They won't be taking your job, they'll be taking a job that you couldn't do.

An architect that does not know how to implement is a bad architect and a programmer that does not understand the architect is a bad programmer. Implementation trivia is extremely important to the proper implementation of a system.

The implementation drives the architecture and the architecture drives the implementation. The best system meets in the middle.

quote:
Sometimes what the hackers do is called "software engineering," but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it's there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.

What and how should not be kept too separate. You're asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it's creating the spec-- though it turns out the best way to do that is to implement it.

That would be above average in my book. To me, an "excellent" programmer would not only do that, but also not be wasteful with resources, and would analyze the problem themselves and architect the program their-self.

Quite a few of the programmers I work with are in their 40s and 50s. A few of the senior software engineers are in their 60s. I sometimes find myself explaining things to them, but overall, they're quite smart people relative to many people I have met in the past. At least they don't make obvious mistakes and are good at following industry standards.

Getting the "correct" answer is not good enough, the answer needs to be correct for the right reasons. A lot of my job is cleaning up "correct" implementations. Quite a bit of my job is handling high profile cases that need quality, performance, reliability, debugability, and needs to be able to handle massive feature creep. You know how to handle feature creep in a way that doesn't involve lots of technical debt? You anticipate the features ahead of time, or at least the general direction.

Most work being done is "good enough" and "works", but I am back-logged with projects trying fix the inadequacies in other systems that I did not make. I have a back-log of projects to improve my daily work, but instead I constantly get drafted to fix other people's poor designs. They work great for the first year or two, but then go to crap once they need to start extending.

Before I got into my current position, we've had relay feature requests from high paying customers to engineering, only to get quotes like this poster-child of 1,000 man hours and 6 months. Then I wrote it myself in less than a week, deployed it to production, never had a bug, has been running for 3 years on hundreds of systems.

This is good for job security, but can be quite annoying, because it's a waste of my time cleaning up other people's messes. I have plenty of job security with my official job description duties.

First you have to find the top 20 Indian programmers. The same issue exists for finding good programmers anywhere, lots of noise from the not so good ones. You also have the issue of communications. They may speak English, but there are some large cultural differences when it comes to actually communicating ideas.

The level of interest someone has in a subject is generally a good indicator. When it comes to programming, it's not the answers that count so much as how one arrives at an answer. What we need is interactive dynamic analysis of logic. Generally it works best just to have another "great" programmer strike up a conversation with another.

Programming is a bit different than other fields, there are many technically correct answers, but few good answers. In hindsight, identifying a good programmer is much easier, because their creations are easy to debug and work well, even when beyond their design.

A great programmer understands enough stuff that they can debug their creations on a whiteboard without looking at the source code or using a debugger.

I know for myself, I have no background in the Go language. My co-worker came to me telling me he had an issue with an example program where it became slower and slower, very quickly, when it came to lots of channels and go-routines, and he couldn't figure out why. First I started asking basic questions about how the Go language is meant to work, then I asked him how he had his stuff setup, then asked him what he expected. I couldn't find any fault with his setup with my limited understanding of the Go language, but I do understand multi-threading and generally work with complex interacting systems. So my next question was what compiler he was using. Turned out he was using GNU. Then I asked him how they implemented it. After a bit of digging, turned out they used threads for go-routines because threads are much easier to implement quickly for a proof-of-concept compiler. Then I found out they limited how many threads could run at once. This meant that his go-routines, which were blocking each-other, normally would not have an issue in a correctly implemented compiler, but because the number of go-routines which could be processed at a given time was a fixed small number, it effectively created a pseudo-dead-lock, which fixed itself after some timeout that scaled poorly with the number of go-routines. A quick minor change to how the channels were configured, and it ran quickly.

Obviously, in my example, my co-worker is quite smart also, he was able to answer all of my questions or look them up quickly. He came to the same conclusion as I did at the same time. We work well together, which is why my boss paired us. We're great at asking questions. Good answers are hard to come by, good questions are rarer yet.

Having no background in a specific language, I was able to quickly, I think about 15 minutes, figure out a kind-of-deadlock issue in what technically should have worked, by understanding how the compiler implemented "go-routines". My only real-world experience in programming is C#, I don't do any at-home hobby programming, but I do a lot of reading.