You do not want obstacle penetration, unless you have that 10-story building with less than 10 wifi users. Obstacle penetration is just a nice word for interference these days. 2.5GHz is TOO good at obstacle penetration; in many places you can reach dozens of access points at 2.5GHz and the result is that none of them get decent performance.

Do you have lots of 10-story buildings with less than 10 wifi users? That seems like a very small market.

Bluetooth wifi coexistence is an ugly hack. Get your wifi to 5GHz (or 60GHz...) and leave the 2.5GHz mess to crippled protocols like Bluetooth.

Of course it is doable. It is probably even fairly easy with tun/tap. However, it requires programming; I doubt there are any pre-built solutions for doing this.

He is plenty good at dealing out abuse himself. Interacting with him is not a pleasant experience.

Why would you switch trucks to a less efficient system? Would you really put a 200kW+ electric motor in just to get rid of first gear?

The requirement was that the code would simultaneously compile with gcc in C mode (through the use of a few macros). That prevents any use of C++ features.

For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.

The effort did not last long.

This would make sense if HTTP requests were typically bandwidth-limited. Almost none of them are, most are way too short and never actually get TCP going at line-rate. HTTP is most often latency-bound, not bandwidth-bound, and the compression is meant to help with latency (reducing number of request packets), not bandwidth.

It is actually surprisingly complicated.

It turns out that a typical HTTP/1.1 request requires multiple TCP packets to get all the headers across. With TCP slow start, this takes a long time because only one packet gets transmitted per round trip in the beginning. Obviously this gets even worse if you try to browse to a different continent, with 100ms+ latency.

HTTP/2 manages to fit most requests into one packet, assuming a reasonable MTU. To do this requires both a binary protocol encoding and header compression. Without those, you need two packets which is half as fast.

Of course you could argue that this is all because TCP is a stupid ancient protocol which no one sane should be using in 2014.

It is difficult to imagine a destroyed Earth that is less hospitable than Mars. Not impossible, but difficult. In almost all cases it is easier to terraform Earth than Mars.

It would even be easier to build deep underwater communities on Earth.They are unlikely to be destroyed by climate change or ecosystem collapse, and resources are vastly easier to get there.

Anders Behring Breivik. Alas, he also had the skills to obtain guns legally.

Yes, the typical use case for a MacBook is serving bash scripts over HTTP. Patch quickly!

One of the challenges is that there is just so much data from modern experiments. E.g. the LHC throws a lot of irrelevant data away before it even hits the hard drives. To a layman like me it seems likely that some potentially useful data gets thrown away in this process.

You cannot fault the LHC designers for doing this; the data handling and storage there is awe-inducing. Transporting and storing orders of magnitude of (probably useless) more data is just not feasible.

That is the trick: You do not need to pump water anywhere. You just avoid using water when other forms of energy are delivering. If there is a power surplus even with the turbines off, you try to export that somewhere, and if no one wants it even for free, you stop the wind turbines or solar plants or whatever. If you happen to have pumped storage available for the few hours a year with low or negative prices, great, but otherwise it is not a great loss.