And while your're at it, I suggest taking the Bayesian approach for the criterion of a scientific method, where falsification is a particular (and simplified) case of Bayesian reasoning.
A great introduction may be found at [0], if one is already well versed in Bayes theorom, then an excerpt [1] should be enough.
I might be nitpicking, but I disagree with Raymond Chen here.
Regarding his example, IMO, the process of saving a file has a platonic security abstraction, it is a very limited computation engine. When one is able to escape this abstraction, it is a security concern.
The distinction between a security bug and non security bug is very subtle.
An example how this violation may happen in real life. Assume a filesystem that may contain long filenames, an attacker may control it and cause remote execution. Another scenario may be a site that tells you to see an easter egg in notepad by fire up notepad and save a file named <payload>, which will do some trick and will also run arbitrary code on your machine.
Right. What Raymond is trying to say is that if the attacker is someone else (in your case, the attacker is the person getting the victim to use a specific long filename), then it's escalation and hence an issue. Otherwise his post would mean that even opening a bad Word doc isn't a security hole.
Thus, if you are trying to show Windows is broken, and YOU are the attacker making up this long filename to inject code into your own process, then a buffer overflow isn't a vuln.
Still as I mentioned on Raymond's original post, this doesn't quite work as Windows has things like Software Restriction Policy (and AppLocker). With that in mind, it is a vuln in the app if an app lets you inject code since you couldn't do so otherwise.
Talking about tabs, I am really curious why links which get opened in new tabs don't feature a working back button. It really bothers me when reading an article that contains a lot of references, I open them, each one on a new tab, read through each one of them and then can't get back to the old one (I usually resort for Ctrl+Shift+T too many times).
I believe that a similar approach can also be used in C++ with the help of ADL [1] and some template magic. Though it may only work on expressions whose concrete type may be known at compile-time (which makes it pretty useless).
This repository previously included a toolchain to build a collection of eBooks, in ePub and MOBI formats, from Caltech's online edition of the Feynman Lectures. Those scripts have since been removed, in response to the suggestion that their continued availability might lead to a permanent discontinuation of HTML access.
If anybody was wondering and looking at the forks, these scripts don't work anymore. They have converted the links to simple Javascript functions to link to chapters which stop these scripts from running now.
Not only it is not very intuitive, I also find it to hurt the linearity of code. The code which will be executed after the loop ends depends on how the loop ended. break statement is usually a glorified but mostly harmless go to, but I think Python's go to statement isn't so harmless as it adds complexity but doesn't have big benefits.
But, I do think that the else clause on try\except blocks is less harmful. It is less harmful because the control flow complexity of exceptions handling is already there on the catch clause, so while exceptions does add big control flow changes, the addition of the else clause causes a relative minor change on the linearity of code (as it is already broken by catch: clause.)
It's built into Coursera's video player - there's a menu/button to change it somewhere on the toolbar under the video.
I like to watch at 1.5x (or 2x if it's something I'm really sure I completely know from previous courses or experience) most of the time, and then if something starts to be especially confusing I'll slow down to 1x.
A great introduction may be found at [0], if one is already well versed in Bayes theorom, then an excerpt [1] should be enough.
[0]: http://www.yudkowsky.net/rational/bayes
[1]: http://www.soest.hawaii.edu/oceanography/researchers/francoi...