<story><title>FreeBSD on Firecracker</title><url>https://www.usenix.org/publications/loginonline/freebsd-firecracker</url></story><parent_chain><item><author>eddythompson80</author><text>Google is moving away from gvisor as well.&lt;p&gt;The &amp;quot;process sandbox&amp;quot; wars are over. Everybody lost, hypervisors won. That&amp;#x27;s it. It feels incredibly wasteful after all. Hypervisors don&amp;#x27;t share mm, scheduler, etc. It&amp;#x27;s a lot of wasted resources. Google came in with gvisor at the last minute to try to say &amp;quot;no, sandboxes aren&amp;#x27;t dead. Look at our approach with gvisor&amp;quot;. They lost too and are now moving away from it.</text></item><item><author>monocasa</author><text>Does google?  I know they use gvisor in production, which is ultimately enforced by a normal kernel (with a ton of sandboxing on top of it).</text></item><item><author>NovemberWhiskey</author><text>There&amp;#x27;s no way an &amp;quot;enterprise grade&amp;quot; cloud vendor like AWS would allow co-tenancy of containers (for ECS, Lambda etc) from different customers within a single VM - it&amp;#x27;s the reason Firecracker exists.</text></item><item><author>garganzol</author><text>I never really realized that Firecracker VM is a full-blown machine and not just some sort of a Linux container tech. At first, it may sound like an ineffective approach, but if you take a closer look on a real-world usage example such as fly.io, you will be surprised: micro-VMs are very small and capable.</text></item></parent_chain><comment><author>Rapzid</author><text>Really? Has gvisor ever been popped? Has there ever even been a single high-profile compromise caused by a container escape? Shared hosting was a thing and considered &amp;quot;safe enough&amp;quot; for decades and that&amp;#x27;s all process isolation.&lt;p&gt;Can&amp;#x27;t help but feel the security concerns are overblown. To support my claim; Well, Google IS using gvisor as part of their GKE sandboxing security..</text></comment>
<story><title>FreeBSD on Firecracker</title><url>https://www.usenix.org/publications/loginonline/freebsd-firecracker</url></story><parent_chain><item><author>eddythompson80</author><text>Google is moving away from gvisor as well.&lt;p&gt;The &amp;quot;process sandbox&amp;quot; wars are over. Everybody lost, hypervisors won. That&amp;#x27;s it. It feels incredibly wasteful after all. Hypervisors don&amp;#x27;t share mm, scheduler, etc. It&amp;#x27;s a lot of wasted resources. Google came in with gvisor at the last minute to try to say &amp;quot;no, sandboxes aren&amp;#x27;t dead. Look at our approach with gvisor&amp;quot;. They lost too and are now moving away from it.</text></item><item><author>monocasa</author><text>Does google?  I know they use gvisor in production, which is ultimately enforced by a normal kernel (with a ton of sandboxing on top of it).</text></item><item><author>NovemberWhiskey</author><text>There&amp;#x27;s no way an &amp;quot;enterprise grade&amp;quot; cloud vendor like AWS would allow co-tenancy of containers (for ECS, Lambda etc) from different customers within a single VM - it&amp;#x27;s the reason Firecracker exists.</text></item><item><author>garganzol</author><text>I never really realized that Firecracker VM is a full-blown machine and not just some sort of a Linux container tech. At first, it may sound like an ineffective approach, but if you take a closer look on a real-world usage example such as fly.io, you will be surprised: micro-VMs are very small and capable.</text></item></parent_chain><comment><author>lima</author><text>&amp;gt; &lt;i&gt;Google is moving away from gvisor as well.&lt;/i&gt;&lt;p&gt;I&amp;#x27;ve been wondering about this - are they really?</text></comment>