4 ms·

Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server

• junon 5y ago
  This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker. VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface. Further WASI is a nightmare. Most projects I've personally seen disregard it completely.
  • sitkack 5y ago
    You are putting the cart before the Solomon. He is saying they would have built on WASM+WASI in the way that Docker is built on cgroups. Java is not a target for C++ code compiled via Clang/LLVM. Wasm is. Expert advice done cheap.
    • pjmlp 5y ago
      https://www.graalvm.org/reference-manual/llvm https://www.graalvm.org/reference-manual/llvm Experts happen to know what is actually possible.
      • sitkack 5y ago
        Graal has AoT, you cannot compile Java to native with LLVM. But you know this already. You cannot compile C++ to the JVM w/o heroics or interpreting a RISC machine (nestedvm). Are you going to quip that Burroughs did all this already as well?
        • pjmlp 5y ago
          Of course you cannot compile Java to native with LLVM, the support isn't there, that doesn't mean there aren't other Java AOT compilers to choose from, like the now gone Excelsior JET, or PTC and Aicas still on the market. Not Burroughs, but AS/400 TIMI (now IBM i), Microsoft MSIL, TenDRA compiler suite, if you want to talk about C++ aware bytecodes.
    • junon 5y ago
      But... you can't. They still would have had to have built a custom VM that could forward full-on Syscalls, so Docker (or something similar) would still have to be written. This still doesn't make sense to me. Cgroups are a Linux kernel feature, WASM is a VM. They do not have the same (or similar) scope of features.
      • sitkack 5y ago
        You no longer need syscalls when you can interpose the whole runtime, you don't need cgroups either for a wasm process. Sandboxing becomes a purely user mode construct, no OS magic needed.
        • junon 5y ago
          So you're saying you'd run an entire Linux kernel within a WASM VM? You lose hypervisor speedups, kernel feature parity, introduce a whole new surface area for security exploits since you're throwing away the entirety of linux's history, and what's more, it was still possible with the JVM.
          • sitkack 5y ago
            No, you live Linux behind (or below). You could run the entire OS in Wasm, but what does an OS mean when all the same affordances are now in userland?
            • junon 5y ago
              Userland doesn't have any semblance of I/O. WASI doesn't support arbitrary syscalls, so running containers would not work in WASM.... I'm not seeing your solution to this. Docker and would-be-WASM-docker would have very, very different scopes and thus would not be comparable.
              • sitkack 5y ago
                Both sides of the Wasm env are userland, you can expose any method you wish into the Wasm environment. You don't even need WASI, its just a crutch for programs that expect libc. Wasm is two things, CFI and capabilities, everything else is an implementation detail. Your definition of a container is too limited in scope. You don't understand what I or Solomon Hykes are saying wrt Wasm and isolation. I tried to help.
    • kaba0 5y ago
      > Java is not a target for C++ code compiled via Clang/LLVM. Wasm is Well, it is with GraalVM with proper cross-language inlining.
• pjmlp 5y ago
  He should have gone talk to Microsoft and learn about MSIL.