The ones I cited above were all examples from weak random numbers (https://en.wikipedia.org/wiki/Random_number_generator_attack). Slashdot has become a terrible place, with anonymous cowards just contradicting without actually understanding. I mean, if you understand the topic, by all means, contradict, maybe kindly and constructively. Otherwise, just find a better use of your time.

You are right, but in practice, if you do your algorithm is right, then the security relies solely on the key. The one-time pad illustrates this. Looking at it the other way, if your adversary can guess the key, it does not matter what algorithm you have.

Actually, Kerckhoffs's principle states that all of the security of an algorithm must reside solely in the key. So, the key is important. Most high-profile attacks (e.g. playstation jailbreak, debian ssh hack, bitcoin wallet hack, crypto AG backdoors, and many other backdoors that I will not mention here) have relied on the weakness of the key. You can have provably secure encryption algorithms (the simplest being the one-time pad), but, quantum mechanics is the only theory that allows you to generate provably secure keys, as quantum is the only physics that has randomness as a fundamental part of it. If you go the classical way of generating keys, you can end up with issues as highlighted in this paper: https://eprint.iacr.org/2012/0... that found that a percentage of randomly generated public keys are actually the same. So, in my view, it's the opposite: QRNG adds significant security at virtually no cost (you can buy QRNG chips for cheap), and virtually no effort (use all the usual, secure, quantum safe algorithms). QKD, is more tricky, it works really well for short distances, and exponentially badly as the distances get longer.

When I first read Linus' post, I dismissed it as one of his rants. Then, I tried to optimized our code (image compression) for AVX-512. The problem is that each different "AVX-512" Intel processor implements only part of the spec, making it a nightmare from all points of view: programming, testing, and even marketing i.e., I can't even say to customers " if you have AVX-512, you will get performance X". That makes AVX2 a much better option, as it is the same across most processors (including AMD). Where performance and parallelism are really needed, a GPU is at least one order of magnitude faster. I agree that the idea of having a 512-bit (or more) simd is nice, but the implementation is just terrible.

The problem with this theory is that in a medium of refractive index n>1, light does not travel at the same speed in all directions: light travels slightly faster in the direction of the flow of the medium, and slightly slower in the opposite direction. As the earth goes round we would pass from one situation to the other, and notice this slight difference in the speed of light. This is basically the Michelson-Morley experiment, which has been repeated to huge precisions over the last century.

Wayne Kerr electronics (http://www.waynekerrtest.com/) made me lough when I saw them in a physics lab. I guess British English counts as a foreign language too ...

Hi, I see your point: Python is getting a lot better for scientific use, maybe not so much due to the changes in 3.0 but rather because the community has grown (e.g. Python(x,y), Enthought). There are a few things that make Python what I use most of the time for scientific work: - The language is better thought out i.e. the Matlab tradition of having one function per file is just annoying. - The quality of the old Fortran algorithms which scipy wraps is consistently better than that of Matlab functions e.g. Matlab fitting routines are a mess, I get much more accurate results with scipy. - Compatibility between versions: matlab code from my colleagues always needs some work to run: either because there have been some changes between matlab versions, or they use a function from a toolbox that I don't have, even though there is an equivalent one in standard matlab. Since we changed to Python all is fine. - When you cannot vectorize a small piece of code, scipy offers a few ways in which compiled code can be added transparently: cython, pyrex, f2py and even pycuda. Much easier than .mex in matlab. - Python has a large set of very useful libraries for doing scientific work e.g. networkx, vpython ... - Thanks to Python's large set of other libraries, it is trivial to do things such as parsing complex files, interfacing with lab equipment (pyvisa, ...) interfacing with the windows/linux/mac GUIs, using databases, sending data over the network etc. All these things are really handy in the lab. - I don't mind paying for software, but the license management is really a problem: It has happened quite a few times, that Matlab has stopped working because something in the license management had changed. Loosing a day of work of a research group is expensive. - Of course, the fact that students can just install Python for free, and maybe use it in their future non-scientific job is a plus.

You are right: for every upload there must be a download, so, by definition, the average seed ratio is exactly 1.