moosingin3space

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.

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.

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

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.

> 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".

> 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.

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.

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.

That's unfortunate, since an IOMMU is an excellent solution to this kind of problem, especially when one considers all the potential Linux USB stack vulnerabilities that can be exploited if you assume the modem is untrustworthy.

You can use an IOMMU to isolate DMA to a separate security domain. This is how Qubes OS works.