301–310 of 313 posts
Earlier quoted context omitted.
Yes, your lack of knowledge was never in question. > The Dunning–Kruger effect is a cognitive bias whereby people with low ability, expertise, or experience regarding a certain type of task or area of knowledge tend to overestimate their ability or knowledge https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...
Lovely Internet discussions.
Earlier quoted context omitted.
> native containers wins If your threat model includes hardware bugs, then a container doesn't really help, no? You can't really trust your containers without sandboxing them, and then you're killing your performance anyway.
Heavily sandboxed container has overhead of few percents. A hardware VM slows things down by 10-20% for a typical application. So even combining VM with a container will still be significantly faster than WASM.
And you're also comparing decades of VM and container investment to a handful of years of investment in WASM. WASM code today will run faster by a huge margin in a few years as the compilers improve.
But moreover, most folks don't care about hardware bugs letting untrusted code break out of a sandbox. Bugs have been letting code break out of VMs, even, for years. If a hardware bug is discovered, you install the microcode update or kernel patch and move on.
Which is to say, the performance isn't the reason for choosing WASM. It's good enough, in many cases. Being able to write a hundred or two lines of code to get pretty-fast and pretty-damn-secure sandboxing without needing to waste your time setting up and maintaining an elaborate breakfast machine of VMs and containers is the draw.
So it's kind of like GraalVM with cgroups? How about Kubernetes, in other words, how does this scale (I understand the single process proposition, but can't see how it replaces multiple containers, which might be deployed on multiple VMs / hardware)? In other words, what is the WASM runtime running on? In the article they show a WASI layer, but that does not replace a VM / container (AFAIK), so you still need an OS t…
Yea, unsure how this replaces compose or how it would work in pods. Is there some kind of runtime planned to replace container.io so that you still get all the k8s orchestration (live/readiness, anti affininity, cgroups limits etc).
The "normal" shim on Linux is the runc shim (io.containerd.runc.v2). On Windows the shim is called runhcs (io.containerd.runhcs.v1).
The docker solution mentioned in the article modifies the "wasmtime" shim from https://github.com/containerd/runwasi so that it uses "wasmedge" instead. It also happens to be using an unreleased version of dockerd.
So how does this work with compose? Currently you need to specify the runtime for the container, there should be an option in the compose yaml for this.
How does it work with pods? You need to configure containerd's cri config with a runtime handler that specifies the wasmedge shim. Then you add a RuntimeClass to k8s and add that to your pod spec.
Earlier quoted context omitted.
I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
Aha! Thanks. :) So it sounds like it's a new capability-based syscall interface, but they've ported big chunks of libc (specifically musl) to that interface so that a lot of things work.
Earlier quoted context omitted.
There are some other aspects that docker cannot be replaced. For example, making sure build works accross different platforms and machines. There are too many ways that something may break, incorrect SDK versions, missing dependencies etc. Docker makes sure the OS (container) to be setup correctly to handle the build.
> For example, making sure build works accross different platforms and machines Unfortunately Docker only works on Linux, since it's tied to specific syscalls. Those on other platforms (e.g. macOS) can only run it in a VM (e.g. the Docker Desktop application is built on top of a VM running Linux) > here are too many ways that something may break, incorrect SDK versions, missing dependencies etc. AFAIK Docker doesn't…
Earlier quoted context omitted.
There are some other aspects that docker cannot be replaced. For example, making sure build works accross different platforms and machines. There are too many ways that something may break, incorrect SDK versions, missing dependencies etc. Docker makes sure the OS (container) to be setup correctly to handle the build.
Something like the docker build tools would still be needed, but not the docker runtime.
[0]: https://nixos.org/
Earlier quoted context omitted.
The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting. Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the…
But how large is this gap? I.e. 10%, 50%, 100% or 1000%. Size of this gap affects trade offs of using WASM vs native code a lot.
That said, from what I've read, it looks like starting up a new WASM instance is pretty fast, so some places are using it for when they need to spawn up tons of instances all at once, without having to wait for a whole process to warm up.
I don't think I get this.
Earlier quoted context omitted.
>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?
You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, muc…
Consider .NET / CLR for another example. Like JVM, it also deals with objects, methods etc conceptually on bytecode level. But it also deals with raw pointers and pointer arithmetic and other such stuff. As a result, you can efficiently compile e.g. C into that bytecode. So wasm isn't really new in that sense, either.
Earlier quoted context omitted.
The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.
Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.