The scientific method need not constitute the entirety of a person's belief system for them to decide that, based on its eminently observable practical applications, it is a useful tool.

Yes. One might come to the conclusion that certain other explanations for existence are improbable or unnecessary, as well.

I thought that man was "ish" (aleph-yod-shin) and woman was "isha" (aleph-shin-shin-he).

While I will agree that 65 million years is not long in geological time, any novel life forms trying to develop on Earth have to compete for limited resources with existing organisms that are already well-adapted to their environments. It is probably much less likely for some alternative to cellular life as we know it to develop here in parallel with existing life than it is somewhere that we seed a supply of proteins and amino acids and watch to see what happens.

Curious, has Google said or implied anything about plans for separating the radio drivers form the kernel? If so, could someone point me to it?

A bit late, but Ceylon creator Brian Krig answered the following question in an interview posted today:

I am curious as to Red Hat's practical motivations for creating this language. Specifically, do they plan on integrating it in their existing business or projects in any way?

Piaget would disagree with you.

http://en.wikipedia.org/wiki/Schema_(psychology)

Not sure why parent is modded down, Ur/Web does have relatively little to do with Ceylon.

I legitimately wonder how many (if any) of the features covered by the patents in question would not have been implemented in Android if not for the work of whoever filed the patent. If the answer is few or none, then patents are subtracting rather than adding value to society in this domain. If the answer is many, then there is at least an argument to be made.

While it is true that some security issues are outside of your awareness and control, following best practices makes it less likely for a single point of failure to provide attackers with access to sensitive data.

Personally, I would never allow sensitive user data to be used in a Dev environment in the first place. You shouldn't need to, and it creates an additional potential target for attackers.

It doesn't help that a lot of sites use policies that make it harder to practice good password habits. Examples:

• Unnecessary limits on password length or allowed characters. These make passwords weaker and serve no purpose that I am aware of. They also make it harder to use consistent conventions between services.
• "Security Questions" that would be easy for others to know if answered honestly.
• "Password Hints". I don't think I even need to explain why these are a bad idea.
• Requiring users to change their passwords regularly. Such rules often result in users picking weak passwords or taping them to their monitor or keyboard, and so in my opinion, reduce rather than increase security.

I agree. I could do without "security questions", as well. Some sites allow you to reset your password using just the security questions, which is ridiculously insecure if credulously answered, given how easily available some of the information is. I used to put long strings of garbage as the answers, knowing that I would never lose my password. I can't do that anymore, because a lot of companies seem to have decided that it is a good idea to require answers to the security questions to do relatively routine things like log in from a different IP address. Now it is essentially one more password that I have to keep for each such site, which if you are choosing strong, unique passwords, is pretty much a waste of time.

While we should be able to assume that the hashes were salted, there have been other breaches in the past year in which the exposed password hashes were not salted. A quick web search turned up drupal.org and LinkedIn. Also, many other companies, like Sony, specified when they disclosed their breach that the password hashes were salted. As Ubisoft did not opt to specify and have not responded to the question anywhere as of yet, I am operating under the assumption that they did not, in fact, salt their password hashes. In 2013, any DBA should understand the importance of salting password hashes and insist on always doing so. In my opinion, any company over a certain size that not only fails to secure the contents of their account table against an attack and weren't even bothering to salt their passwords should be subject to fines and/or civil liabilities.