This will justifiably be used to disable IPv6 in many places, which will sadly set back IPv6 adoption just that little bit more.

I'm IPv6-only on my personal infra, and it's pretty nice. End to end reachability between machines and containers, and reduced need for middle boxes like reverse proxies.

Supposedly disabling IPv6 still doesn't prevent exploitation, so lazy IT will get hacked anyway.

The article says the opposite:

> As a mitigation measure for those who can't immediately install this week's Windows security updates, Microsoft recommends disabling IPv6 to remove the attack surface.

and

> "That means it's wormable. You can disable IPv6 to prevent this exploit, but IPv6 is enabled by default on just about everything."

> I would love to understand where the war-like anti-Chinese sentiment is coming from in US elite circles.

I think they're predicting large military spending and are seeking the power, influence, and money that can come from being an early leader.

The classic for Java is "Java Concurrency in Practice", a great book for more than just Java.

Java's happens-before memory model is similar to C++'s.

I'll prob get this book, if only for the memory model chapter.

Java atomics are actually sequentially consistent. C# relaxes this to acquire/release. Though the general concept of happens-before is still immensely useful for learning atomics as sequential consistency is a superset of acquire/release.

Thanks for correction/clarification. Much as C# has a weaker memory model than Java, my mental model for memory models is weaker than I thought.

Where do Rust and C++ lie wrt C# and Java?

All of the memory models in question are based on data-race-free, which says (in essence) that as long as all cross-thread interactions follow happens-before, then you can act as if everybody is sequentially-consistent.

The original Java 5 memory model only offered sequentially-consistent atomics to establish cross-thread happens-before in a primitive way. The C++11 memory model added three more kinds of atomics: acquire/release, consume/release (which was essentially a mistake [1]), and relaxed atomics (which, to oversimplify, establish atomicity without happens-before). Pretty much every memory model since C++11--which includes the Rust memory model--has based its definition on that memory model, with most systems defaulting an otherwise unadorned atomic operation to sequentially-consistent. Even Java has retrofitted ways to get weaker atomic semantics [2].

As a practical matter, most atomics could probably safely default to acquire/release over fully sequentially-consistent. The main difference between the two is that sequentially-consistent is safer if you've got multiple atomic variables in play (e.g., you're going with some fancy lockless algorithm), whereas acquire/release tends to largely be safe if there's only one atomic variable of concern (e.g., you're implementing locks of some kind).

[1] A consume operation is an acquire, but only for loads data-dependent on the load operation. This is supposed to represent a situation that requires no fences on any system not named Alpha, but it turns out for reasons™ that compilers cannot reliably preserve source-level data dependencies, so no compiler really implemented consume/release.

[2] Even Java 5 may have had it in sun.misc.Unsafe; I was never familiar with that API, so I don't know for certain.

> as long as all cross-thread interactions follow happens-before, then you can act as if everybody is sequentially-consistent.

I don't think that's the actual guarantee. You can enforce happens-before with just acquire/release, but AFIK that's not enough to recover SC in the general case[1].

As far as I understand, The Data Race Free - Sequentially Consistent memory model (DRF-SC) used by C++11 (and I think Java), says that as long as all operation on atomics are SC and the program is data-race-free, then the whole program can be proven to be sequentially consistent.

[1] but it might in some special cases, for example when all operations are mutex lock and unlock.

There's quite an escalation of topics for Rust.

If you want to write a HTTP server, people are guided towards Axum/Tokio, and thus async rust.

If you want to use async Rust, read this book?

This books covers assembly level atomics, and creating your own channels, in beginner chapters.

Is that necessary for writing a HTTP server in Rust?

From the topics in the TOC, this book is useful of you want you write concurrency primitives. I wouldn't recommend it if you just want to _use_ Arc/Mutex/crossbeam-channel.