This.

The irony is that any WordPress site getting any reasonable amount of traffic is already using WP-Super-Cache... which generates static HTML pages for public content to be served directly from the web server. So they get the worst of both worlds: caching issues and a dynamic backend that is still just as susceptible to exploits as without the cache.

The only secure way to use WordPress is as a static site generator, where the live version is deployed with no dynamic functionality and the administration backend is secured by a layer above WordPress (e.g. HTTP BASIC authentication).

WordPress isn't particularly terrible code, but it is written in a particularly terrible programming language where it's practically impossible to write something secure because things are insecure-by-default and you're expected to defend against all the gotchas explicitly.

The flaw was specifically made possible by PHP's eagerness to convert malformed strings to best-guess integers instead of raising an error like any sane programming language. You didn't read TFA, did you?

Parent is mostly correct, except where he lumps together all "scripting" languages. This isn't a problem with "scripting" languages, it's a problem with languages like PHP that were designed by people who had no idea what they were doing. Worse, PHP is designed to be deployed in a way that encourages mistakes (PHP files directly in the webroot). PHP security is a game of whack-a-mole where if you forget to whack all the moles in one of your scripts, your site is toast. This wouldn't have happened with a sane scripting language, like Python.

$ php7.1 -r 'echo (int) "123test";'
123
$ python3.5 -c 'print(int("123test"))'
Traceback (most recent call last):
    File "", line 1, in
ValueError: invalid literal for int() with base 10: '123test'

If you want to worry about legacy stupidity bloating Intel chips, look at their cache model, not their instruction set. Their legacy "everything is coherent everywhere" requirement means they need snooping/invalidation logic around every single little cache block (e.g. the branch predictor). ISAs where, for example, you are not allowed to execute dynamic code without first flushing it from D cache and invalidating that range from I cache don't have this problem.

Except the A9X doesn't have an ARM core, which is what the parent was talking about. It's a chip that implements the ARM instruction set. Big difference.

IP cores from ARM Holdings Inc, today, do not compete with Intel. Nor do any of the other ARM cores around (e.g. Qualcomm's, Nvidia's). But it seems Apple right now has better engineers than all of those and is actually managing to design ARM-compatible cores that are starting to be comparable to Intel chips.

It isn't, but ARM is better at the low-power scale in absolute terms, and less complex chips have lower leakage. It's hard to build a single chip that can scale from high to low power, and Intel doesn't know how to build small chips. But yes, at desktop/server scale, Intel still smokes ARM. High-end POWER does better than ARM but Intel still wins.

You can make a VM look a lot like the host. I don't know if the license allows you to run Windows inside a VM on top of another instance of Windows with one license, but what I actually do is run the natively-installed Windows inside a VM running on my also-natively-installed Linux (so I can boot Windows natively, or boot it inside a VM on Linux) - a single instance of Windows 10, just with or without a hypervisor under it (this should be perfectly legal; I recall actually reading through the EULA and it being ambiguous about this usage). I made sure the VM had the same CPU settings, the same GUID, the same hard disk serial number, and a few other identifiers. Windows isn't complaining and claims it's correctly activated, regardless of whether I boot it on bare metal or on the VM.

This used to be sometimes problematic when I had Windows 7, but Windows 10 hasn't given me any trouble. Perhaps they loosened up the hardware checks.

... which Python only uses for auxiliary purposes. Just call gc.disable(). Poof, no garbage collection. No memory leaks as long as you do not use data structures with reference cycles, either.

Let's assume you're talking about CPython, because Python is a language, not an implementation.

Python explicitly runs as a single thread

No it doesn't. CPython supports threading.

and uses time slicing to simulate multi threading.

No it doesn't. CPython uses OS threads, it does not do its own time slicing.

What you're thinking about is the GIL, which ensures that only one (real) thread is running *inside the interpreter* at any one point. You can spawn multiple CPython threads and they will be *real* threads scheduled by the OS. However, they will mutex each other out of running the interpreter at once in multiple threads. You can make blocking OS calls, or calls out to C code that is thread-safe, and they will run concurrently on multiple cores. No time-slicing.

CPython has perfectly real threads. It just isn't suitable for concurrent computation in pure Python code due to the GIL.

The is also no such thing as a real time processor

There is, however, such a thing as a platform unsuitable for real-time processing. And commodity x86 platforms have been unsuitable for real-time processing ever since BIOSes decided to schedule code behind your back in SMM code without the OS being able to do anything about it. You need a very special BIOS to make sure this doesn't happen.

Smart card access has been broken in Linux Chrome for seven odd years, and that's *with* native PKCS plugins. Browser support for smartcards is still horrible. No wonder they had to go for java.

No. USB-PD is not a "firehose". That is not how electricity works. USB-PD specifies certain discrete voltage levels, but you can draw as much or as little current as you want. Devices are supposed to have a buck converter to adapt the voltage of the input to the voltage of the battery, and they can do so at a wide range of input voltages.

The only reason to raise the voltage at the USB connector is to reduce resistive losses in the cable by reducing the required current. Once the electricity arrives at the device it can be converted to whatever voltage is appropriate for the battery, and it can deliver exactly as much current as it should. There is absolutely no reason whatsoever why USB-PD would cause more damage to a battery than Qualcomm QC, in a correctly designed device.

#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>
int main() {
        sigset_t set; int status; if (getpid() != 1) return 1;
        sigfillset(&set); sigprocmask(SIG_BLOCK, &set, 0);
        if (fork()) for (;;) wait(&status);
        sigprocmask(SIG_UNBLOCK, &set, 0); setsid(); setpgid(0, 0);
        return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

Until Google does exactly the same thing in Chrome... which they probably will, as one of the authors of that document works for Google.

Speaking of Comodo... (bonus: WoSign owner also tries to step in and makes a fool of himself).

It's not a year-long suspension. It's a permanent suspension of trust in their current roots. They can, however, re-apply after one year - with extra auditing over what is normally required - and if and when they pass that they may be let in again. If they do nothing, they don't get back in for free after a year.