Replit rebuilt its sandbox engine with microVMs
Posted by gaplong 7 hours ago
Comments
Comment by ghshephard 5 hours ago
I wonder what ecosystem replit exists in that seems to completely not overlap with any of the other AI technologies and companies....
Comment by 1e1a 3 hours ago
Comment by robgough 4 hours ago
Generally it's entrepreneurial types who would have gone to an agency to get something built, or would have wanted to go to an agency but couldn't afford the costs involved. These platforms are far cheaper and quicker, and if we're really honest not necessarily worse quality than what they would have gotten from the vast majority of those agencies, especially the cheaper ones.
This is not a comment on whether this is a good thing or not, and I have all sorts of concerns, but it's undeniably something I'm seeing, and the nearshore/offshore agencies are certainly starting to feel the impact.
Comment by mritchie712 3 hours ago
Comment by benoau 1 hour ago
There was so much that wasn't done, it was basically an Airbnb-like service and it lacked any capacity to register users or hosts, pay for or disburse payments, create or manage listings, notifications, administration. They went from expecting to launch in a couple weeks to looking at my roadmap and quote of about 3 months more development work just for a launchable MVP, which wildly exceeded their budget or commitment to the project.
I don't know how much of this was Replit's fault but some of it certainly was, like despite being a monorepo the frontend had no connectivity with the backend, there was no barriers between user data and most endpoints were not secured, the server had zero hardening, some endpoints would take the user's id as a posted value.
Comment by doomspork 2 hours ago
Having used lovable.dev as well, I must say Lovable is a much better product.
Replit is easily one of the worst products and platforms I've use. I wouldn't even recommend it to my enemies.
Comment by tmpz22 2 hours ago
1) they were inexperienced or just hesitant to use even managed infrastructure
2) they started with a small Replit footprint and kind of got stuck there out of some niche convenience
3) it started free* and was thought of as a cost cutting measure to use this temporarily VC subsidized service (we've all been there)
Comment by nafey 3 hours ago
Comment by schainks 4 hours ago
Is that about right?
Comment by tptacek 47 minutes ago
A thing I wish more people would do: ask prospective cloud hosting companies "is there a mode of this offering where my workloads might share a kernel with other tenants I don't trust, as would be the case with Docker?", and if the answer to that question is ever "yes", disqualify the provider.
Comment by clhodapp 6 hours ago
How do people feel about the hardware isolation provided by microVMs versus strong software isolation techniques like gvisor?
Right now, we put a huge amount of stock in "hardware isolation". If that starts falling to agents to any substantial degree, I wonder whether we might end up seeing a transition toward patchable software isolation, similar to the rise of software RAID that occurred a while back.
Comment by tptacek 5 hours ago
I think "hardware" vs. "software" is the wrong way to frame this. The big difference is between shared-kernel multitenant and guest kernels. gVisor (in some configurations) is like an 80% solution; a partially emulated guest kernel. I think the verdict is in on shared-kernel vs. not: don't share kernels between tenants.
The hardware isolation itself --- AMD-V, VT-X, &c --- has held up for almost 2 decades now. You never know, of course, but if you were going to place a bet it probably wouldn't be on hardware isolation failing before software did.
Comment by oooyay 2 hours ago
gVisor and Firecracker are nothing alike. gVisor is an application kernel written in Go. Application kernels will make your system much slower and can only solve a subset of security issues that would affect the kernel. They're like a kernel proxy of sorts.
Firecracker is a KVM virtual machine but made much more efficient. It's the most desirable of the two. Firecracker and KVM don't require bare metal, but in a virtualized environment they will require nested virtualization support. Nested virtualization is supported by just about every hyperscaler.
The reason KVM is preferable is because it provides strong isolation of the host kernel interface and independent emulation of host devices.
Comment by tptacek 53 minutes ago
Firecracker doesn't require bare metal, but (1) you want it for performance and efficiency at scale and (2) you take a security hit for nesting.
Comment by oxcartctl 5 hours ago
Comment by curiousgal 5 hours ago
Comment by robby_w_g 19 minutes ago
Comment by pearcoder 5 hours ago
Comment by stevekemp 5 hours ago
I avoided reading the piece, just in case.
Comment by iberator 4 hours ago
Comment by slatedale 3 hours ago
Comment by qingwind_gal 4 hours ago
Comment by guhcostan 6 hours ago