Great, your company has a /20 they could share. That would mean 16 different companies could have their own /24.

Currently, the USA has nearly 5 IPv4 addresses per head of population. There's some waste here: maybe a modern, post-industrial economy would function efficiently with 4 addresses each. IPv4 has a hard limit of 4.3 billion addresses. The current global population is 7.8 billion. Give everybody 4 addresses (still less than the USA currently enjoys) and we'll be short of nearly 78 billion addresses.

But, yeah, your company could return 16 /24 blocks to the global pool! That's clearly the solution we've all been missing!

Yes, there are plugins that will block JavaScript. If you run them, you're also in control of WebAssembly. The probably know about it, and even if they don't the WebAssembly won't get run without being bootstrapped by JavaScript.

The idea that every website you visit pushes software at you, and your browser just runs it without confirmation is crazy, but that's the assumption behind a lot of the web now. It isn't more scary because there's a more efficient way of doing it.

Incidentally, NoScript tells me it's blocking 6 different scripts from 5 different domains as I preview this comment. I wasn't at any of the meetings that concluded this was acceptable. I do, as it happens, run WebAssembly on my website, and it's great. For the minority of sites that have a good reason to run CPU intensive dynamic content, it is a really good idea

Wasm is not a low-level version of JS. Wasm is a portable instruction set architecture with some sandboxing capabilities. Wasm even needs to talk to JS to interact with the browser (although there might be experimental support for DOM integration in some browser). JS is a high level language with a garbage collector and threading and stuff. If you compile JS to Wasm, you'll also need to supply it with a garbage collector, and if you want threading you're into nonstandard territory. It's likely much more efficient to use the JIT compiler that a browser will already have and that will go direct to native code

WebAssembly isn't a binary version of JavaScript. That's one of the over-simplifications that got into the original publicity. It is possible to convert WebAssembly into JavaScript, where it will usually be greatly bloated and much less efficient. That's a problem for a Bitcoin miner. Malware authors are giving their vote of confidence in the new technology here. Blocking the scary new thing isn't going to save you from malware, though.

"You" has been used as a singular pronoun for quite a long time now. But it still takes plural conjugation: "you are", "you have".

Right. We hear a lot about "DST all year round" or, up here, "permanent summertime". It doesn't sound as good if you call it "getting up an hour earlier in the winter".

Japanese chess is the most computationally expensive of the three, but Chinese chess is indeed more expensive than the European variant. Also, note that "shogi" and "xiangqi" are written using the same characters (give or take simplification) and there are different rules native to Japan, but the most complicated game is the most popular.

Maybe the OP thinks the Chinese game is more computationally difficult because they've read scientific papers that say this. I know I have. It has a larger board and games tend to run on for longer. There's also much less likelihood of a draw, so apparently equal positions will probably yield a result.

Note that in my experience, Chinese people don't believe this. The think the game foreigners play must be more difficult. I believe this is one reason they undervalue their own game and don't promote it internationally.

After thinking about this far too much, I've concluded that POSIX should go to some form of GMT that isn't UTC, either UT1 or UT2, whatever the difference is. It keeps the numeric timestamp meaningful: you can get the time and date most of us care about with basic arithmetic and no lookup tables. Future timestamps will work the same way. Unless you really need to know the current time in UTC, in which case you'll need a lookup table, which is simple enough as predictions are published that should be good enough. Software that cares about UTC can use lookup tables to give you the real time corresponding to your GMT timestamp, which means full leap second support for software that cares without burdening the hardware clock or software that doesn't care. And your historical timestamp might even record a leap second you didn't know about because your time zones files were out of date when you recorded it. No abrupt changes as we pretend UTC and GMT are really the same. No historical times that can't be represented.

If you really care about UTC, you can always set your clock to atomic time and use the "right" timezones the same way nobody does now and leave the rest of us alone.

Networking protocols can be designed to work if two devices pick different standards and end up being (shock!) up to a second different.

(I don't know how Microsoft are implementing the headline changes. I read the article and the article it links to, and they still gloss over the details.)

Who's with me?

Python has reached its middle-aged bloat. There was plenty of saying "no" for the first ten years or so. It's now got a lot of features that are all useful for somebody, and a lot of cruft that's accumulated as the obvious way to do things has changed. It's becoming an advanced language for experts rather than a simple and versatile language that's quick to pick up. This isn't a unique problem and calling it poorly managed is unfair to the language designer. The time's ripe for a new language designer to come up with a new language that learns the lessons of the past two decades or so. I haven't seen it.

HTTP allows a MITM to run a virus scan and block malicious content. Arguments against HTTP assume ISPs are less trustworthy than random website owners. Which may be true in general, but that doesn't mean it needs to be fixed at the protocol level.

If we're talking protocols, though, secure content that's visible to a MITM but authenticated client-side (signed but not encrypted) is certainly possible. It would allow ISPs to run virus checkers (so viruses can't hide behind a Google certificate, by coming from a Google-hosted website, for example) and caching to save bandwidth, but stop malware and advert injection. And a sensible protocol would allow privacy where it's really needed. It's a shame Google is trying to reform HTTP but not putting any weight behind a proxy-aware HTTPS.

Like every engineering disaster, somebody found the problem, and failed to communicate its severity. In this case, they decided it wasn't a safety issue (cracks in a brand new bridge!) and left a voice mail with somebody else who was out of the office for a few days.

There's no substitute for risk assessments by fully qualified engineers, of course. But those engineers also need communication skills â" including persuasive skills. Engineers who can find somebody in authority and convince them to take action save lives.

Somebody should really invent a thermostat that cuts in automatically when the temperature goes below a certain level.

If you need rebase in Subversion, there is a Python script that can do it https://bitbucket.org/x31eq/om...