WebAssembly: Docker Without Containers

Post by greiskul » Wed, Dec 21, 2022, 5:09 PM UTC

ptx wrote: post #171

nine_k wrote: post #102

Earlier quoted context omitted.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software This sounds like a recipe for disaster to me and is why I haven't gotten into Docker. If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is se…

Post by flohofwoe » Wed, Dec 21, 2022, 5:13 PM UTC

kllrnohj wrote: post #147

afavour wrote: post #145

Earlier quoted context omitted.

The web has SharedArrayBuffer. It’s just difficult to work with.

Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.

Post by erk__ » Wed, Dec 21, 2022, 5:21 PM UTC

cmeacham98 wrote: post #87

ClumsyPilot wrote: post #77

Earlier quoted context omitted.

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker). This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Post by ridruejo » Wed, Dec 21, 2022, 5:23 PM UTC

pjmlp wrote: post #64

ridruejo wrote: post #27

Earlier quoted context omitted.

Yes! Wasm builds on top of 20 years of experience and improvements of JVM, CLR. There are a few key differences, but one important one is the universal adoption by the industry (no ActiveX vs Applets war, .NET vs Java) with companies as varied as Google, Apple, Amazon, Microsoft actively cooperating on moving the standard forward. I have never seen anything like that and I hope it continues for as long as possible!

> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pas…

Post by sitkack » Wed, Dec 21, 2022, 5:26 PM UTC

mike_hearn wrote: post #155

orf wrote: post #120

Earlier quoted context omitted.

Let me rework and clarify my point here a bit. The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases. WASM is built to sandbox untrusted/partially trusted code. WASM is built as a compilation target rather than a complete hosted VM with bells and whistles. There are advantages and disadvantages…

"The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases." We need to drill into this a bit more, because the WASM ecosystem can certainly learn lessons and do better than the JVM but this isn't quite the right set of lessons to learn. The JVM spec was written from day one to sandbox arbitrary an…