They seemed to have answered the rat strain criticism and the food intake one here, among other things:
http://www.sciencedirect.com/science/article/pii/S0278691512008149

I will grant them that all the data collected on 200 rats over several years is in sufficient quantity as to not fit into one journal article. That should not mean they did not use all the data for their analysis; however, I'd expect them to have the data available if requested for comparison purposes, otherwise this would start to look pretty fishy.

let's see ... google gmo liver damage ... first link is
http://worldcrunch.com/tech-science/new-study-says-monsanto-gm-corn-causes-tumors-kidney-and-liver-disease/gmo-nk602-monsanto-tumors-corn/c4s9636/
(paper link at http://www.sciencedirect.com/science/article/pii/S0278691512005637)

Feel free to abuse google further on the subject. And ofc pertinent criticism is welcome.

... and of course this uses his assumption for the chance of false positives, which is basically ... wrong. Quite embarrassing for a math student, since instead of stating it as an independent variable (as he should have) he assumes that

P(test positive | not infected) = 1 - P(test positive | infected)

where in fact the right hand side is P(test negative | infected), quite a different thing from the left hand side.

If otoh your zombie test has 0 false positives, that .9% will be irrelevant as anyone flagged positive by the test is in fact infected so you'll not be administering the cure to healthy people.

Even poorer judgment, in fact, as his probability calculation relies on an actual rate of infection of 1 in 500. For such a highly contagious disease the rate of infection will grow (well, duh!) So if 1 in 500 gives about 83% false positives, when the infection rate reaches 1 in 50 the false positive chance drops to 33% and for 1 in 5 to 4%.

So indeed 99% is quite good for a high contagion rate, not so good for low contagion and useless for something that's exceedingly rare (for a disease that affects only one person in 10000 a test that has a 99% detection rate will have 99% false positives)

P(no zombies in 100 years) = p(no zombies in year 1)* ... * p(no zombies in year 100)
= p(no zombies per year)^100 = 0.99^100 = 0.36603... or about 36.6%

similar for the second case, 0.999^1000 = 0.36769... or about 36.8%

I suppose the better illustration of probabilities would be:
99% for a zombie-free year = 36.6% for a zombie-free century
99.9% for a zombie-free year = 90.5% for a zombie-free century
99.99% for a zombie-free year = 99% for a zombie-free century

Well, it's a good thing you're not a money manager. MSFT is a company whose stock has gone sideways for the last 10 years (ignoring the dotcom bubble, as that would make it going down and sideways, but not for intrinsic reasons). 3.4% dividend on a stock that goes sideways for 10 years is a joke, even for today's artificially low rates you can get higher yield with high investment grade bonds (say, GE 10y AA, with a 5.5% coupon) for a FAR lower level of risk. OF course, you can do far worse than that, but at this stage a passive buy-and-hold of an index ETF, say SPY, you would have done far better than holding MSFT. Too bad the shareholders don't seem to want a change of leadership at Microsoft, the current Ballmer edition has a too long and too proven track for lack of vision.

And you bring this up to justify assert()ing ... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.

Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.

Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.

Sure Sparky, you can certainly have unforseen errors. You send a rover to Mars, and the whole computing system is bombarded with high energy radiation in much larger doses than here. Chances of having a bit flipped in a constant go up a bit (depending on your hardware mitigation measures). The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?

There are ways to mitigate depending on how important your whole setup is. Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort. This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen. If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.

Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*] And the reason is, if you know you might have unexpected input there are other tools to approach it in release mode: if, switch, exceptions, your own custom macros and so on. Assert is for code that has to evaluate to true, otherwise it's a programming error (for a beginner example, bounds checking for array access). If you're using it for release code it's a programmer error, and if it triggers in release code it means you have an inattentive programmer, a testing problem and a design error. And if it happens in a system library that's used by most programs in your OS ...

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

Lactose intolerant people can digest cheese just fine (for the most part). Milk lactose is largely drained with the liquid in the process of curdling, so cheese has little lactose left. That's likely why people used cheese before having developed lactose tolerance - because they discovered it was safe to digest.

This is not always true tbh. Stealing hashes can require as little as an unsanitized SQL query in a web application that allows an attacker to dump the hash table(s) using nothing more than a browser. It may or may not allow for user impersonation in order to do the stuff you listed, but the point is stealing hashes does not have to require complete hacking. In such a scenario strong passwords are still quite useful.

Automated control system and/or safety checks failure, most likely - at that speed manual braking is useless (by the time you have visual on the obstacle it's too late to brake). The automated control system should have detected that one train was no longer moving or no longer in contact and should have slowed down/halted all other trains on the same track approaching the area.

Seeing that the alternatives at the moment are not exactly in the same league, they could do with more users/testing. And waiting for the Linux Skype client to be almost unable to talk to the Skype servers due to being extremely out-of-date (aside: anyone using the official Yahoo Messenger Linux client these days?) is not a good way to help having an alternative to jump to by that time.

You might want to reconsider your understanding of critical thinking (and, by extension, scientific research) if you derive the existence of a God from the existence of what you call miracles.