One of the coolest things about gVisor to me is that it's the ultimate implication of core computer engineering concepts like "the OS is just software" and "network traffic is just bytes". It's one thing to learn these ideas in theory, but it's another altogether to be able to play with an entire network stack in userspace and inject arbitrary behavior in the OSI stack. It's also been cool to see what companies like Fly.io and Tailscale can do with complete flexibility in the network, enabled by tools like gVisor.
Just wait until you read about Wine or captive NDIS. You'll probably enjoy User Mode Linux most of all.
The concept of an OS still makes sense on a system with no privilege level transitions and a single address space (e.g. DOS, FreeRTOS): therefore, mystical low level register goo isn't essential to the concept.
The boundary between the OS is a lot more porous and a lot less arcane than people imagine. In the end, it's just software.
I believe early on Linode used UML for their VPS hosting offering. At that point in history, I recall solutions like OpenVZ being pretty popular in the low end space, too.
gVisor's modular design seems to have been its strongest point. It's not that nobody understood the OS is just software or whatever, but actually ripping the Linux TCP stack out and using it in userland isn't really that trivial. Meanwhile though a lot of projects have made use of the gVisor networking components, since they're pretty self-contained.
I think gVisor is one of the coolest things written in Go, although it's not really that easy to convey why.
Seriously, just check out the list of packages in the pkg directory:
https://pkg.go.dev/gvisor.dev/gvisor
(I should acknowledge, though, that I don't know of that many unique use cases for all of these packages; and while the TCP stack is very useful, it's mainly used for Wireguard tunneling and user mode TCP stacks are not particularly new. Still, the gVisor network stack is nicer than hacked together stuff using SLiRP-derived code imo.)
How does Fly use gVisor?
I don't believe they do, they use Firecracker microVMs for isolation: https://fly.io/docs/reference/architecture/
https://fly.io/blog/ssh-and-user-mode-ip-wireguard/
Quote:
> And, long story short, we now have an implementation of certificate-based SSH, running over gVisor user-mode TCP/IP, running over userland wireguard-go, built into flyctl.
Also:
https://fly.io/blog/our-user-mode-wireguard-year/
https://fly.io/blog/jit-wireguard-peers/
This is another one of those things where the graph of our happiness about a technical decision is sinusoidal. :)
We don't.
I think they mean to say that a part of gVisor is used by Fly, because if I recall correctly flyctl did use the gVisor user mode TCP stack for Wireguard tunneling.
Ahh, that makes sense. Ok, revised answer: yes, we do. :)
I'm trying to understand the point you're making here but don't really get it. The OS is just software, in most circumstances. Most modern OS require at least one binary blob that has to be sent to some hardware device. This is mostly because the the device manufacturer didn't want to include NVRAM and at the end of the day is usually just software as well.
their point is that lots of things everyone thinks of as "OS" things like "tcp" and "doing file IO" can just be done in user space by some new program without the processes that make use of these facilities knowing or caring.
The majority of any OS lives in user space though. Intercepting syscalls is also not that weird of an idea, that's how tools like strace works. Building out sufficient kernel functionality without needing to forward calls to the kernel is definitely impressive though.
What do you mean by that? There's a notion of an "operating system" that encompasses both the kernel and all the userland tools (in this sense, each Linux distribution is an "OS"), and there's a more common notion of an OS that is just the kernel and any userland services required for the kernel to function; the latter is the more common definition.