Excellent post, but one thing bothers me.

Isn't that begging the question? I'm not a physicist, but my understanding is that the question of determinism is a matter of interpretation. (Quantum mechanics can be understood to be deterministic.) Isn't that the question they are poking at here?

Typical programmers.
FTFY.

Besides, if you think that's bad, you should see what happens when they actually do do something. <grin/>

Why would they have any goal to be working toward at all? We take it for granted that an intelligent entity would necessarily value self-preservation. But it doesn't have to be so, that's a product of natural selection. Why would a machine intelligence "care" if it survived? Why would it care about anything, for that matter? If anything, it'll be selected to have goals to serve us.

If intelligent machines ever pose a threat to humans, it will be because of another group of humans giving them that goal.

Hey, you said it, not me. ;)

Absolutely. The fact that we (application developers) are dealing with passwords at all is the root of the problem here. The first time I wrote an app that did this (in 1997) I felt a little queasy about it. Yes you should use a three-tier design if at all possible. Ad-hoc queries cause many more issues than just this anyway; stored procedures should be the only allowed access from the middle tier. The password should be hashed a zillion times before being stored or compared.

But really, that's all just band-aids. We should not have to re-implement this for every application, and the user should not be subjected to the absolute train wreck of having to register and make up credentials for every fucking site. I would have thought something better would be here by now.

No amount of bitching at users or developers is going to help. This whole way of doing things needs to be tossed, and we need to figure out which one of these we want. Or something else if none of those are really sufficient. But something.

Point taken -- thanks for the clarification. There are a few comments in this thread that seem to be saying that you can't trust that something hasn't been altered, even when the hash matches, but it's hard to tell what they're saying.

Minor nit-pick: A hash is not a hash. I'm sure you are aware, but just for clarity -- Cryptographic hashes are intended to make it very hard to modify the binary stream without changing the hash. Not all hashes have that property. If you know what the cryptographic hash is supposed to be (you trust the hash) then you can be confident the stream has not been modified if the hashes match (ignoring known weaknesses, e.g. in MD5.)

Regarding your sig: your wife thinks the best way to solve 10% of problems is to start a fire? Nice.

Yep. This is really more a function of the (guest) OS than anything else. As long as the guest is OK booting under either hardware (physical and virtual) dynamically, it should work fine. It's been a long time since mainstream OSs couldn't do that. It can be a little tricky to set up the VM to use a physical partition, though. That's the part that bootcamp does for you, which is nice, but it's definitely not the only way to make this work.

I don't know why everyone is confused about this, but this isn't "unique symbols." The palm pilot input method was innovative because it solved two problems with handwriting recognition. The first problem was that there was nowhere near enough processing power to run a real handwriting recognition algorithm (which existed at the time). The second was that because you are writing each letter in the same space, there is less information to work with. Without character spacing, you have no idea whether a stroke is part of the current glyph or the beginning of a new one. They solved both problems the same way: by making each character a single continuous path, and the direction/order matters. That makes the recognition easier, and it knows when you are done with a character because you lift the stylus.

The downside is that you have to invest quite a bit to learn how to do it. It's frustrating to have to learn how to do something you already know how to do: write.

This is more sophisticated. There is quite a bit of variation in the way people write letters, and without the prescribed continuous glyph, a lot of ambiguity.

Give them some credit. This isn't just a rehash of Graffiti. It's real handwriting recognition. I think that's impressive for such a small device. Not as limited as the palm pilot for sure, but still a very limited machine. It may be an incremental improvement, but that's what innovation is, literally, distinct from invention.

Without ASLR, return to x exploits are trivial for all x. All that is needed is the address of a function (or any code -- it doesn't have to be the 'official' entry point of a function) that does something useful to the attacker, and a way to clobber the stack.

This doesn't really have anything to do with libc, except that it is a rich source of well known addresses (without ASLR). So what in the hell are you talking about?

That's a lot of languages and platforms. Know what they all have in common? I'll give you a hint; it starts with C.

You're both wrong/right. In order to supplant Objective-C, Swift would have to play well with the bazillion lines of Objective-C, and coexist with it for possibly a very long time. On the other hand, even if Apple "could not be more clear" that swift is built to supplant Objective-C, that doesn't mean it will succeed, and doesn't mean Apple won't change their mind. It's a gamble and they certainly know it. They keep that to themselves in order to encourage you to drink the cool-aid.

See also: Microsoft and .NET

If only there were some way to simulate physical systems like that. Where will they find the computing power? Plus the software probably costs a fortune.

RAM generally is, and address space always is.