I am not a fan of the Mac, even though I am on my third one. But it is a far cry better than a Windows machine. And for programming it is excellent, because it is Unix. I use my Mac for all of my "devops" programming. And if she needs to do some heavy duty computation, she will want to run that in AWS or somewhere anyway. The problem with Linux as a general purpose laptop is that you are limited in all of the mainstream things. I assume that she does not do physics all day and all night: so if she wants to, say, watch Netflix, she will have a much easier time with a Mac. Most things can be done with Linux, but it requires research and effort. If she were studying computer science I would say she should go with Linux, but she is studying physics, so she will not want to waste her time on getting Linux to serve up a movie or exasperating over the fact that her Open Office document looks different when someone loads it on a PC, since the Mac supports MS Office. Her time is better spent thinking about gravitational waves. Get her a Mac, and she can do anything she needs to do with minimum hassle. Problem solved. Also, Macs are pretty durable due to the metal case.

Isn't it ironic that a great percentage of the programming that occurs today is for using the Internet to enable online commerce, collaboration, and business? And yet the Agile community (of which I am a member, and believe in Agile - although not ever single idea or practice) shuns distributed teams - the very technology that we build.

http://valuedrivenit.blogspot.com/2013/11/are-agilists-turning-their-backs-on.html

Well said. I actually agree with all of this. When I use the term "design pattern", I am speaking generally - not in terms of the "design pattern" movement. I simply mean defining the design in some way - not just rushing to the keyboard and coding. As you put it, you need all three: good architecture, good design, and good implementation. Many programmers today skip the first two.

Yes, I agree with what you say. You misunderstood the intent of what I said. I was not arguing for formal proofs. By "assurance argument" I merely meant that the programmer uses some explicit design patterns, that can be analyzed: the "assurance argument" is merely the logical analysis that convinces the programmer that the pattern is a secure pattern. Thus, I claim that secure code does not start as code, but starts as diagrams (design patterns) and algorithms that are then turned into code. The assurance argument is merely the thought process of verifying those patterns and algorithms on paper before writing the code. And this can be done in an "agile" way by progressively refining and adding to the design: the focus is on the design, however - not the code.

Yes, you are right. But I was not speaking from a "policy" perspective. I was saying essentially what you are trying to say: security is holistic. What I was trying to say, apparently not very well, is that secure code must be based on a secure design. If you hack something together, without explicitly analyzing your design patterns, you have no way to convince yourself that is secure. This is not about policy: it is about sound design. As Peter Neumann once said, "Good system and network architecture is perhaps the most fundamental aspect of any efforts to develop trustworthy systems, irrespective of the particular set of requirements whose satisfaction is necessary." Neumann is Principal Scientist at the Computer Science Laboratory of SRI International, Fellow of the AAAS, ACM, and IEEE, recipient of the ACM Outstanding Contribution Award in 1992, the Electronic Frontier Foundation Pioneer Award in 1996, and the ACM SIGSOFT Outstanding Contribution Award in 1997, an ACM National Lecturer for 16 months during 1969 and 1970, 1997 recipient of the Norbert Wiener Award for excellence in promoting socially responsible use of computing technology, SRI Fellow, and Honorary CISSP (Certified Information Systems Security Professional), awarded by the International Information Systems Security Certification Consortium -- (ISC)^2. I was therefore honored when he wrote the foreword for my book High-Assurance Design.

I am not saying that having an assurance argument makes code secure. I am saying that without one, it is very hard to reverse engineer the security model and thereby convince oneself that the code is secure.

Code cannot be claimed to be secure unless it has been designed with secure design patterns - patterns for which there is an "assurance argument". If the code was "coded" instead of designed, then there is no hope of creating assurance arguments after the fact. In that case, the audit will be very difficult and untrustworthy.

The question is confused. The AI processes that are thought to be most promising with respect to eventually leading to intelligent machines are not algorithmic. That is, they are based on neural networks. And while it is possible to simulate those using algorithms (e.g., the RBM cascade pattern, with each node simulated as an RBM node), these "algorithms" are non-deterministic - they are simulations - we cannot know the outcomes, just as one cannot know the outcome of a human's thought process. But with regard to religion, that seems to be a human predisposition with a genetic basis, and since religion is based on absolute unquestioning faith in things that are seemingly preposterous - a cognitive dissonance if there ever was one - I don't think that we can expect intelligent machines - which are free of our cognitive impairments - to be susceptible to conversion to religion. Still, I suspect that artificial intelligences will have the same wonder and confusion about existence as we do - they just will not look to iron age shaman texts for their answers.

Above all, take a profession that is what you love to do - no matter what income it produces (as long as you can get by). And stay focused - don't let time fritter away. Make a plan for your dream - a practical plan, for which you know all the steps, because all steps are simple and very doable - and stick to that plan no matter what.

The assumption that "we will probably find new things to do to satisfy limitless human demand" has no substantiation. In fact, the rate of job replacement is now higher than the rate of job creation. Unemployment will be rising inexorably and at an increasing rate.

Perhaps it could be like the real thing, if done right - but the real thing throws you around, and you can fall off and roll onto the ground. To duplicate that would be quite a simulation! But as you say, if it is raining out, it sounds like the next best thing.

What is driving the rush into these things is that the companies behind them want to mine the data that they generate. Imagine: all those devices phoning home, and companies able to collect data on when people are using things, where people are etc. - all that data can be input to data analysis and find patterns. Those patterns are worth a-lot of money.

It is nothing like real. Measure the calories expended - it will not be comparable at all. This reminds me of one time when Konan Obrien challenged Serena Williams to virtual tennis on the Wi, and Konan won. Yeah that's real tennis - not. :-)

LOL. Well you have discovered that most developers know very little about application security. And here we are, wondering why things are so insecure - and heading head-long into the "Internet Of Things". What a train wreck that will be unless things change. Read my article about this: http://www.transition2agile.co...

You are right that we need machine learning. It is possible that the class of learning algorithms invented in 2006, known as "deep learning", can do the job. See this TED talk: http://www.ted.com/talks/jerem...