> If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.
It just sounds like a long migration process (and office politics), to me.
eperot 12 hours ago [-]
Try running `dmesg` in your Cloud Run instance and see for yourself if that's actually the case :)
minraws 2 days 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.
anotherhue 2 days 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'.
eperot 12 hours ago [-]
gVisor does support NVIDIA GPUs and some Vulkan ioctls are supported. If you want to run games in it and find incompatibilities, patches welcome :) Agents are great at completing gVisor's nvproxy ioctls nowadays.
I've personally run Unreal Tournament 2004 at 40fps on my laptop, with pure software-rendered OpenGL a few years ago (GPU support wasn't there at the time).
iercan 2 days 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 2 days 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
trashcan2137 2 days 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
bananaquant 2 days ago [-]
Good night, GVisor.
aidiveyt 23 hours ago [-]
[flagged]
xyzzy_plugh 2 days 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.
https://cloud.google.com/blog/products/serverless/cloud-run-...
https://docs.cloud.google.com/run/docs/configuring/execution...
> If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.
It just sounds like a long migration process (and office politics), to me.
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.
Last I looked (years) those were very much 'not intended use'.
I've personally run Unreal Tournament 2004 at 40fps on my laptop, with pure software-rendered OpenGL a few years ago (GPU support wasn't there at the time).
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.