Linux userfaultfd is fascinating and seems like a slam dunk when running a large fleet of mostly homogenous VMs. For a kernel feature that's been around for over a decade it's surprising how little content there is out there about how it's used in practice, so great to see this post.
Okay I'm getting weird vibes from this whole project. While the whole thing looks interesting from an engineering perspective, I feel like this startup's preferred approach of offering cloud browsers by running Chrome on bare metal (??) inside a VM is a very circuitous route to achieve their designated goals of low-latency and overhead rentable browsers.
First, why chrome? I imagine putting this amount of engineering into slimming down an existing browser engine would yield much better results (using CEF/whatever as starting point).
Second, Chrome already has a multiprocess architecture with renderers, why not just rent a boring server, and use renderer sandboxing (as in multiple tabs).
Third, Chrome as a huge OS footprint with GPU, sound, threading etc., non-optional multiprocess sandbox as of late, not sure how they managed to make all that work without a full-fat OS underneath. Cool if they did, but seems excessive.
Fourth, it seems to me they basically rely on 'hot pools' to actually achieve the stated perf goals, I don't really know if the majority of performance of this wouldn't be achievable via running a Chrome process on a boring Linux box, with X renderers running in the background, and dynamically handing them out to requests?
Edit: Also sorry, but please fix that paragraph formatting, it might work on mobile, but on a 1080p screen, it's hard to ready.
Also PS: By looking around on the website, they're demoing Doom 3 compiled to WASM. While an impressive technical feat, and may be the best demo for their usecase, I really hope the future isn't running a WASM sandbox, inside a chrome sandbox, inside a firecracker sandbox, inside whatever cloud sandbox this things runs on top of.
Kernel clearly seems to be winning against vanilla firecraker, but im curious how it compares to other browser infra providers that also use firecraker?
firecracker is an obvious place to start because it offers best-in-class support fast cold starts and hard isolation. we can't speak to what exactly the other browser infra providers are doing, but based on public benchmarks we're up to 5.8x faster
Linux userfaultfd is fascinating and seems like a slam dunk when running a large fleet of mostly homogenous VMs. For a kernel feature that's been around for over a decade it's surprising how little content there is out there about how it's used in practice, so great to see this post.
Okay I'm getting weird vibes from this whole project. While the whole thing looks interesting from an engineering perspective, I feel like this startup's preferred approach of offering cloud browsers by running Chrome on bare metal (??) inside a VM is a very circuitous route to achieve their designated goals of low-latency and overhead rentable browsers.
First, why chrome? I imagine putting this amount of engineering into slimming down an existing browser engine would yield much better results (using CEF/whatever as starting point).
Second, Chrome already has a multiprocess architecture with renderers, why not just rent a boring server, and use renderer sandboxing (as in multiple tabs).
Third, Chrome as a huge OS footprint with GPU, sound, threading etc., non-optional multiprocess sandbox as of late, not sure how they managed to make all that work without a full-fat OS underneath. Cool if they did, but seems excessive.
Fourth, it seems to me they basically rely on 'hot pools' to actually achieve the stated perf goals, I don't really know if the majority of performance of this wouldn't be achievable via running a Chrome process on a boring Linux box, with X renderers running in the background, and dynamically handing them out to requests?
Edit: Also sorry, but please fix that paragraph formatting, it might work on mobile, but on a 1080p screen, it's hard to ready.
Also PS: By looking around on the website, they're demoing Doom 3 compiled to WASM. While an impressive technical feat, and may be the best demo for their usecase, I really hope the future isn't running a WASM sandbox, inside a chrome sandbox, inside a firecracker sandbox, inside whatever cloud sandbox this things runs on top of.
They are probably running a whole Chrome as it will trigger bot detection less often
Kernel clearly seems to be winning against vanilla firecraker, but im curious how it compares to other browser infra providers that also use firecraker?
firecracker is an obvious place to start because it offers best-in-class support fast cold starts and hard isolation. we can't speak to what exactly the other browser infra providers are doing, but based on public benchmarks we're up to 5.8x faster