yangl1996

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

Looks like there is no mentioning in the blogpost of the paper (poster) [1] in which the two-level broadcast idea is proposed.

[1] https://dl.acm.org/doi/pdf/10.1145/3548606.3563494

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.

Gosh... This is not some random guy. He wrote the release announcement

https://lists.freebsd.org/archives/freebsd-announce/2023-Nov...

A nice reference for traffic prioritization on major mobile networks. https://coveragecritic.com/2019/06/19/prioritized-and-deprio...

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.

The Japanese Navy had similar ideas [1] in WWII. The plan was to sail undetected to near the west coast, launch the planes, and drop some biological weapon. Basically the predecessor of today's missile-carrying submarines.

[1] https://en.wikipedia.org/wiki/I-400-class_submarine

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.

From a network/system perspective:

- MapReduce: Simplified Data Processing on Large Clusters by Jeff Dean et al.

- The Design Philosophy of the DARPA Internet Protocols by David D. Clark

- Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications by Ion Stoica et al.

Rust compiler forbids multiple threads to access the same memory location not protected by a Mutex.

It does, however, allows "double spending" attacks. In such attacks the attacker first spends a coin to buy some real goods from the victim. She then launches a 51% attack on the blockchain and "rewrites" the ledger to remove the transaction to the victim. Now the attacker gets back her money, plus the goods from the victim.

Webkit's webauthn support is in development [0]. Hopefully the adoption will improve a lot once all major browsers support it.

[0]: https://bugs.webkit.org/show_bug.cgi?id=181943

MTA has this interesting animation to explain the same problem, but in the context of subway.

https://www.youtube.com/watch?v=eShtZSx4kWc

Cool, thanks! This one does have deep integration with Shortcuts.

Thanks! I think Shortcuts has access to some lower-level system configs/functions which Pythonista doesn't have. Also, although Shortcuts can invoke a Pythonista script, control won't automatically return to Shortcuts after the script is executed. So I'm looking for a way to do everything within Shortcuts.

Thanks, that's really cool!

Used Hashcat in the Student Cluster Competition[1] of SC16 conference. There was a task where students were asked to recovery as many passwords as possible from a vault consisting of md5crypt and bcrypt hashes[2]. The performance was amazing - 8400k md5crypt per second with 2 NVIDIA K80.

I also profiled the code trying to discover possible optimizations, and found that the code has been heavily optimized. Computation and data transfer are well overlapped, so GPU utilization is pretty high. It's a really great tool.

[1] http://studentclustercompetition.us/2016/applications.html

[2] https://docs.google.com/document/d/1tXBy9-ajFtO_b8hvbuleqRbc...

\+1 for this. Mosh solved all problems an iPad ssh client may have. It allows the client to go offline and reconnect in no time when the client is back online, which is a common case on iOS (apps get killed when being in background for a short time). Lower latency (thanks to local echoing) and seamless switch between networks (cellular and wifi roaming) are also definitely nice to have. I tested Blink (a client on iOS with Mosh support) on a high-speed-rail trip from Shanghai to Beijing and it was rock solid.

It seems that they implemented an OpenACC 2.0 compatible complier and named it Sunway OpenACC.

As for compliers, they use a fork of OpenACC 2.0, with some extensions to exploit the data transfer features of the new CPU.

They've tested it with some earth modeling applications and got fairly good results.