Rendered at 19:18:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
trashcan2137 18 minutes ago [-]
They don't even sufficiently describe what it actually does and why it would be a better choice than a micro VM or whatever you call it these days
anotherhue 2 hours ago [-]
Does anyone know if it has capabilities that would be useful in running retro-games? I'm imagining a guest KMS-> host SDL conversion, or indeed something like virtio-gpu?
Last I looked (years) those were very much 'not intended use'.
minraws 3 hours ago [-]
Alright does this also mean we are detaching some of the google specific stuff and or are more accepting of open standards related changes?
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
iercan 3 hours ago [-]
gVisor is still pretty useful for untrusted workloads when you don't have KVM, though it gets harder to integrate into workflows where people are running macOS/windows locally
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated:
https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
mintflow 4 hours ago [-]
The networking stack is actually used by many open source project such as tailscale
Hope this shift will make the project get sustainable and evolve fast
xyzzy_plugh 3 hours ago [-]
I like gvisor but I fear this is too little, too late. Microvms are crushing it right now. I believe even Modal, which is one of the few non-Google users deploying gvisor commercially, and heavily called out in TFA, are moving off gvisor in favor of microvms. Unreal!
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.
Last I looked (years) those were very much 'not intended use'.
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated: https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
Hope this shift will make the project get sustainable and evolve fast
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.