Incorrect, I've flown multiple times with British Airways between continental Europe and destinations in the US. I've never needed to touch my checked baggage at LHR, it's been checked all the way in both directions. I've also flown from continental Europe to Glasgow with an LHR transit. Checked all the way. But, hey, even if the UK is outside Schengen, the country is part of the customs union (for now...).

If you're getting that kind of performance difference, it sounds like you're really bound by I/O or (faulty?) thread synchronization. But, yeah, I would never use WSL for performance. For easy transparent prototyping, it's great and I've basically stopped using cygwin.

And, overall, what do you think the tech community would be most open to? A person that sounds like a woman, but comes off as a bit of a tomboy (on account of actually being a man), or a man that seems oddly feminine or "weak", "fuzzy" or whatever attributes you would assign to socially acceptable female behavior? And how did men that had their voice masked into female fare, compared to non-masked men?

Not anymore than saying that a bash script breaks if you run it on a non-C locale. It MIGHT be true, if you actively rely on other stuff behaving in certain ways. And, if you're completely blind to the issues involved, it might very well happen. I've seen Java and C# code generate invalid SVG files etc by using decimal comma (taken from the current locale), rather than a decimal point. But, again, that doesn't mean that the software itself is broken. The author of Excel macros might, on the other hand, be far more likely than either of these groups to just cobble something together based on what seems to work.

Yeah, that's precisely what you would expect for a vulnerability in user space code. "Just" unzip a 7-zip file and suddenly any file in your home directory can be compromised... or gone. Run a vulnerability scanner on your e-mail server (with insufficient sandboxing), or on your web server for uploading files, and things get... worse.

By assuming random sampling, that's how. Whether that assumption is correct is a critical issue, but that is the case for any universe population significantly larger than your sample set. 500,000 or 400 million really does not matter - if you are ignorant of the demographics and how those interact with your sampling strategy, you're not gonna get a correct result.

If, on the other hand, you somehow manage to do random sampling of the true population, 400 people would be enough to nail preferences down to a few percent, (almost) no matter the total population size. And I guess this is the danger of statistics and big data. Intuition says one thing, simple statistical assumptions say another, and a more thorough treatment is rare.

It seems like NCQ, write and read caches (sometimes with flash hybrid modes) etc in current drives would bring enough complexity that additional physical heads would also be reasonable to implement. The abstraction in the drive firmware is much thicker these days.

If they are able to detect lock screen digits versus other things and only find 3 digits, that will result in less than 24 combinations, not more.

Denial of service by crashing the process is of course not as nasty as remote code execution, but it can easily be nasty enough, especially if the properties of DNS would allow you to penetrate deep inside networks and services generally believed to be protected. My personal favorite vector here would be XML exposed to parsers that auto-load whatever DTD or other schema that is specified.

The bug can hit you with DNS over TCP as well. While that is somewhat of an oddity, I am not yet confident to say that you can rule it out, especially if you have a MITM that might be able to trigger fallbacks. Since the TCP response could be fragmented over several packets, things rapidly grow beyond iptables capabilities there. (But the "TCP DNS response fragmented over several packets" would thankfully not propagate through layers of caching internal DNS servers.)

If you use C/C++ right, you do not end up writing a JIT compiler for a language never intended for it. This is a bug in v8. Now, we don't know where, but that's the kind of code that does things no one sane should ever do. It is supposed to take shortcuts and patch things on the fly. It's of course fully possible that this exploit is not in a performance-critical path, and then your comment is rather well placed. But I do think that anyone writing C/C++ in this context is a fool himself. It is for all practical purposes impossible to use C without doing bare pointer addressing. It is highly possible to use C++ without doing it, even though such use is not terribly widespread.

It's not like putting a sliced tomato on the kitchen sink in a humid climate will prevent other parts of your kitchen from attracting any mold spores around. Bacteria and prokaryotes are mostly incapable of macrosopic movement (especially in air). They are also able to rapidly expand populations. Therefore, a "colonist" doesn't choose to move to the best spot, foregoing a worse one. They will try everywhere. If they gain a foothold, that foothold is likely to just unleash further colonists into the less hospitable, but still slightly viable, habitats.

Well, for making this "frame rate" theory relevant, the question is not only if anything happens at or close the frame rate, but what is the frame stepping function? And, throwing relativity into the mix, in what reference frame?

A discretized spacetime would mean that the continuous solutions to the Schrödinger/Dirac equations are actually approximations that are better expressed by some discrete time stepping scheme. That could have macroscopic consequences. Especially so if for some weird reason Nature has a rather simple first-order scheme at its frame rate core. But, it does also mean that we would get slightly different results from different objects in free fall, depending on their overall speed relative to the reference frame. This would control the factor between the "local passage of time", and the actual number of "Planck time frames" used by the process. In addition, the discretization of time almost necessitates a discretization of space. This not only means that space has some small grid (not likely either, based on current theory). It also means that there are some absolute directions in space and that some physical processes would behave slightly differently (even if aggregated along macroscopic distances) if they are algined to these directions, or not.

Well, electron states being quantized has helped us to (truly) understand chemistry and create transistors as well as LEDs. By realizing that things are only allowed to make certain transitions under certain conditions, you can "cheat" and build up high-energy states that are far more stable than they really should be. I am not saying we would get macroscopic anti-gravity or a "Faraday cage for gravity", but this is kind of the space where we would get more specific explanations for how you might be able to accompish those things in theory. For very delicate experiments (similar to the one described!) and possibly sub-nanoscale manufacturing procedures, an understanding of a quantized nature of gravity influences might be useful, if only for better understanding the noise in measurements and tolerances.

Even if mass would be quantized, the Newtonian equation is m1m2/r^2. Even with discrete mass quanta (which is also false, see other replies), you would get a continuous spectrum of resulting forces. Inserting relativity here changes the expressions, but it would really just muddle things. So, no, there is no specific reason to believe gravity to be quantized - outside of an actual theory of quantum gravity.