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

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.

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.

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.

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.

Fellow UMich grad here. Shapiro library (formal name for UgLi) was always a great place to study because you had plenty of noise isolation from other people, especially the upper floors.

On North Campus, CS majors had two major study spaces: the Beyster computer lab/atrium, and the Duderstadt Library. Course staff would provide office hours in Beyster, and if you wanted to study in a more collaborative environment, that was the place to be. Duderstadt had a mix of collaborative spaces (in closed rooms) and quiet workspaces (the benches near the stacks). I studied in both locations, depending on my needs at the time. Was a pretty effective setup.

I'm excited about this project too, but how does it "reduce the influence that Google and Facebook have on the Web"? It seems pretty orthogonal if you ask me.

On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior.

I believe the kernel core developers are good programmers and good at code reviews. That said, a huge proportion of Linux CVEs are memory-safety problems -- use-after-free, race conditions, out-of-bounds access, etc -- which do not exist in safe Rust.

I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead.

I can understand this too! It takes time for large communities to change, and the only real research we have on `unsafe` is the RustBelt paper, which demonstrates that the concepts of the borrow checker are sound provided that `unsafe` code respects its invariants. The way this framework has been pitched, though, is for building optional modules. If everyone takes this seriously, I think it'll result in wins all around -- Linux benefits from memory-safety improvements, Rust benefits from kernel developers' experience, and the world benefits from having more secure code running in ring-0. I'm looking forward to this.

All of these sources show memory safety problems getting worse or staying equally prevalent, which directly contradicts the parent's claim that memory safety is "much less of an issue than it used to be".

Memory safety is much less of an issue than it used to be.

This is demonstrably false: https://twitter.com/LazyFishBarrel/status/112900096574140416...

Additionally, new "safe" C++ APIs aren't: https://bugs.llvm.org/show_bug.cgi?id=34729

Apple's iOS 12.4 release fixes 37 CVEs, 28 of which are memory unsafety (75.7%).

Microsoft's statistics corroborate this: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety.

That can be made a runtime concern - if you use Kata Containers as a runtime for Docker, it'll use a VM instead of kernel namespaces.

Algebraic data types!

This is an excellent analogy and I can't understand why it's being downvoted. Software is only as useful as its surroundings find it useful.

To those of us who actually contribute to the Linux desktop ecosystem, this isn't news.

Signal can use WebSockets, as their non-FCM version (downloaded from their website) does. I've come to agree with Daniel Micay about the best way to separate apps from Google services: https://www.reddit.com/r/GrapheneOS/comments/b9j6pe/compatib...

The UMich network isn't "improperly configured". NAT-less networks have been around since the beginning of the Internet, and IPv6 networks don't use NAT (unless they're accessing IPv4-only targets, but that's CGNAT). I think you'll find a great deal of university/research settings have networks configured without NAT. If you can come up with a solution that works in all cases, I'd love to hear it.

I'm no Linus Torvalds fan, but his rant (and follow-up) on PAE explains why this is actually a terrible idea:

1) https://www.realworldtech.com/forum/?threadid=76912&curposti... 2) https://www.realworldtech.com/forum/?threadid=76912&curposti...

What if your DHCP doesn't give you a private IP address? When I was at the University of Michigan, my personal laptop always received a public IP address. Or if I'm in a pure-IPv6 setup, using prefix delegation/SLAAC? This problem is a lot harder than "just use the RFC1918 list of reserved private IP ranges".

GeckoView doesn't support addons yet. This is pending discussion, but it looks like the goal is to focus on mobile optimization first.

As a tester of Firefox Preview: WebRender has been a godsend for mobile browsing -- I have yet to see it choke!

Yes, like `miri`, which is awesome.