yangl1996

But then Tether would be holding the collateral, which would continue participating in the nation's (or the world's) economy?

Your last sentence seems fishy to me. Are you suggesting that support for C++ like operator overloading is a necessary condition for, say, autodiff? I thought Go is a Turing complete language.

They could have said "35 out of 36" instead of putting some scary number like "94%".

There are also the "middle boxes" that networking researchers talk a lot about. Such devices sit in the middle of a link and easily become unhappy if the packets transmitted do not fit some (possibly outdated or buggy) predefined scheme. Think of cooperate firewalls with "deep pack inspection" that intelligently shut down connections they do not like. Once all middle box vendors start to assume a certain way that a protocol (say, TCP) should behave, it's impossible to change the protocol because it will break the middle boxes.

Encrypting QUIC datagrams prevents middle box vendors from assuming anything about QUIC (at least the encrypted part), so that QUIC can change if there's a need in the future without worrying about supporting legacy middle boxes. Although I do agree using UDP does not allow QUIC to break out from any ossification in UDP itself.

One thing to notice is that 1440p at 27" (one main criteria set by the author) is ideal for non-Retina macOS UI. For Retina UI, stick to 5k at 27" or 4k at 21.5" (or, look for a DPI of around 218 PPI).

A system like Bitcoin has this functionality. "Time" is essentially represented as "depth" of a block, and a block can only be buried deep into the chain with sufficient time (due to the nature of proof-of-work). A cryptographic primitive called "verifiable delay function" provides a good abstraction for this problem.

Specifically, you may put the hash of your message into a bitcoin transaction, and submit this transaction. If you later want to prove its age, just point to the bitcoin block containing your transaction. The guy verifying it is sure that you have got this message before the block is mined, because otherwise you would not have the hash of the message at that time and successfully embed it into a block.

That sounds unreasonable. Did you directly download the profiles (.mobileconfig) from Fastmail?

Such a scheme depends heavily on whether the cloud providers can efficiently multiplex their bare-metal machines to run these jobs concurrently. Ultimately, a particular computing job takes a fixed amount of CPU-hours, so there's definitely no savings in such a scheme in terms of energy consumption or CPU-hours. At the same time, overhead comes when a job can't be perfectly parallelized: e.g. the same memory content being replicated across all executing machines, synchronization, the cost of starting a ton of short-lived processes, etc. These overhead all add to the CPU-hour and energy consumption.

So, does serverless computing reduce the job completion time? Yes if the job is somewhat parallelizable. Does it save energy, money, etc.? Definitely no. The question is whether you want to make the tradeoff here: how much more energy would you afford to pay for, if you want to reduce the job completion time by half? It like batch processing vs. realtime operation. The former provides higher throughput, while the latter gives user a shorter latency. Having better cloud infrastructure (VM, scheduler, etc.) helps make this tradeoff more favorable, but the research community have just started looking at this problem.