That would be limited to west oakland which has always been extremely politically insular (tied up in racism and racial politics from last century). The east bay at large, especially the suburbs, is quite welcoming to tech and success.
The wife was mentioned because she was called out in the earlier article as a problem. We don't know if she was actually a problem or not. We, and specifically you, don't know enough to make the claims you're making.
Please, stop speculating. Have patience, wait for actual information.
There's nothing in the wikipedia article about the USA's ability to track planes. We did have a radar station in AK, which may be what you're thinking of? According to wikipedia it didn't produce useful information, and wasn't necessarily tracking the plane at all points anyway: http://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007#U.S...
I don't think we've ever had the ability to track all planes in the world.
These aren't myths, they're platform guarantees. It just so happens that a few of the most common unixes (Linux, BSD) implement a very good /dev/urandom and the author is suggesting that we write non-portable software that depends on implementation details of these platforms.
There can be benefits from depending on non-portable implementation details but also significant drawbacks.
"Except that we don't see CPUs being astonishingly creative in coming up with reasons why they shouldn't have to follow a clear, unambiguous program instruction."
To be fair there's some circular reasoning here. A contract itself is only valid and legal according to the law of a particular nation. Those pieces of paper had no equivalence of legal meaning in the Native American culture prior to the founding of the colonies and the forced application of English common law.
There's plenty of room for both. Many useful, worthwhile applications won't ever really push a machine to its limits, rather they primarily involve bringing structure and order to mounds of complex business logic. And that's OK. Not everything needs to be optimized.
On the other side of the same token, many useful, worthwhile applications will absolutely depend on this level of optimization. There are some problems which simply can't be solved in a practical manner without it. And that's OK too.
There are plenty of ways to kill pid 1. The major concern is simply software error, which is another reason why the current systemd design is poor. But if you'd like a concrete example, go ahead and attach gdb and use your imagination.