3 ms·
> A typical solution is to put the work into a thread, so there would still be a context switch, albeit a smaller one. Car wasn't fast enough, so we removed th
by mike_d 5y ago
> A typical solution is to put the work into a thread, so there would still be a context switch, albeit a smaller one.
Car wasn't fast enough, so we removed the rear view mirror to lower weight. You are looking at the sexy fun to solve problem rather than the useful boring solution of throwing away the stack. Users can already run things like Solidworks in a web browser with near native performance using VDI.
> deciding which server to run the threads on becomes complicated because you ideally want to decide based on the server load of each
High end load balancers have done this since the 90s. This is now easily done with the nginx API.
Honestly I am sure there is some need somewhere for your stack. But hiring a good server/network operations team instead would have saved you a lot of code.
- paulgb 5y agoOne way to look at it is that it’s like the architecture Github Codespaces uses internally, made available off-the-shelf. I don’t think using a VDI approach would make Codespaces a better product. In fact, I was partly motivated to build this by frustration with laggy VDI setups I had to deal with (though I don’t think VDI has to be bad.) > High end load balancers have done this since the 90s. This is now easily done with the nginx API. A load balancer doesn’t (or at least shouldn’t) do everything we need to do, which involves statefully mapping hostnames generated on-the-fly to servers in a cluster. This allows our users to create instances that multiple clients can connect to, as opposed to just using “sticky sessions” or something like that. Our approach takes less code than you might think —- we lean heavily on nginx and Kubernetes where we can, so we only need to fill in the missing pieces.