This is a fantastic in-depth look at debugging a complex problem, and the fact that the rest of the system remained stable is a testament to the quality of the engineering work that the Oxide team put into this. I'm personally quite inspired by this and plan on applying similar techniques in my day job!

Do be aware, though, that this is just a way to make builds fail fast if you have an older compiler. It doesn't put the compiler in a mode that makes it reject features introduced after that version. If projects want to maintain an MSRV policy, they should be using CI to confirm that they keep compatibility. This flag only exists for improved communication to downstreams.

This depends on the CNI plugin you're using. In particular, Cilium implements the entire firewall in eBPF.

CNI plugins is one thing, while k8s subsystems itself still use iptables for KUBE-FIREWALL, KUBE-FORWARD, KUBE-NODE-PORT. At least that how I understand the k8s internals.

cillium reimplements kube-proxy's functionality. There may still be a couple of features missing, but it can definitely take over service routing more efficiently. I haven't checked in a bit but I'm pretty sure it covers NodePort too

Could you elaborate the benefit of doing it that way?

Disclaimer: I'm not an expert in Cilium! Only recently got into reading about it because of Jessie Frazelle's tweet about it. Still planning on deploying it into my small homelab.

It's my understanding that Cilium chose to do it this way because it allows low-level control of each network namespace that containers launch in, in addition to a high-level view of the system from the k8s API. This allows Cilium to build firewalling features that operate at a different level -- iptables/nftables filters on IP addresses and ports, but Cilium can filter on k8s resources and L7 protocols.

I highly recommend you do a search for Firesheep - the tool that really started the push for HTTPS everywhere. You're right that a malicious network operator would be in a position to request users install root certs, but the problems with plaintext HTTP are deeper than just that.

Another fascinating look into text on computer screens is this article: https://gankra.github.io/blah/text-hates-you/. Just goes to show that text rendering is actually absurdly complex, unless you drastically restrict the problem space.

This sometimes makes me think we're still on the skeuomorphism phase of text. Its more and more complex to render realistic looking with proper illumination and textured faux leather for your UI until until you just admit you're rendering a ui on a screen and then you're back to colored rectangles. We're still trying to render ideas and words resembling handwriting and print press characters, until we embrace screens and render arial and images or even monospaced fonts which are perfectly readable (I do that all day long on my code editor)

And then comes unicode and all the simplicity is gone again as the rest of the world uses more than 26 letters.

> until we embrace screens and render arial and images or even monospaced fonts that are perfectly readable

This is part of what I meant when I said "drastically restrict the problem space".

Honestly, even with minor versions, I'd prefer to use something like dependabot, or for a bot to open a pull request bumping versions. Tons of authors mess up semver in subtle ways, it's just much easier to avoid problems if you just pin dependencies.

I've started doing this with Nix for my own Rust projects, using the technique described here[1]. Planning on setting up a GitHub workflow to automatically open pull requests with bumped versions of nixpkgs/rust.

[1]: https://christine.website/blog/how-i-start-nix-2020-03-08

For one, respected community member pcwalton has argued against compiling to C, citing the difficulty in producing performant, memory-safe output.

For another, from personal experience, I can comment that compiling to C in such a way that doesn't leak abstractions left and right is quite challenging. It's pretty hard to produce memory-safe C, so it's a ton of work, and the payoff is pretty marginal, as the most important platforms already are supported by LLVM.

Automatically generating “memory safe” C is no harder than automatically generating “memory safe” LLVM bitcode.

I think the issue is all of C's undefined behavior

For the most part, that can be worked around as well, with careful use of unsigned arithmetic. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... for some examples. All arithmetic is unsigned, but I use it to simulate 2's complement signed.

That is not difficult to avoid if you are generating short primitives. You can for the most part just convert the LLVM bitcode that the Rust compiler would output to the equivalent C snippet. Since each snippet is short, you can trivially check if it invokes undefined behavior. LLVM bitcode also can exhibit undefined behavior.

> You can for the most part just convert the LLVM bitcode that the Rust compiler would output to the equivalent C snippet.

Sounds like a good argument to resurrect the LLVM C backend. As it stands, the Rust core team has no desire to implement a C backend, as it would be a ton of work for not much gain.

What's more, the Gentoo maintainer that filed the issue lists a number of platforms that CPython itself doesn't even support.

Indeed, a commenter demonstrates that resolving the issue on Alpine Linux was as simple as adding an `apk add rustc cargo` to their Dockerfile.

Uhh, they do embrace bigotry. The official Gab twitter feed has posted openly bigoted comments, not just quoted from their site.