[HN Gopher] Container2wasm: Convert Containers to WASM Blobs
       ___________________________________________________________________
        
       Container2wasm: Convert Containers to WASM Blobs
        
       Author : api
       Score  : 113 points
       Date   : 2024-01-03 17:10 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | ronsor wrote:
       | This is quite cool...
       | 
       | But at the same time, please tell me this is not the future of
       | software packaging.
        
         | withinboredom wrote:
         | Allow me to introduce you to
         | https://www.destroyallsoftware.com/talks/the-birth-and-death...
         | 
         | Everything is on track.
        
         | actionfromafar wrote:
         | _Newt:_ My mommy always said there were no monsters, no real
         | ones, but there are.
         | 
         |  _Ripley:_ Yes, there are, aren 't there?
         | 
         |  _Newt:_ Why do they tell little kids that?
         | 
         |  _Ripley:_ Most of the time it 's true.
         | 
         | ---
         | 
         | But yes, I do believe this has a strong, serverless future.
        
           | ronsor wrote:
           | Downloading a 50MB WASM blob to run an emulator to boot a
           | Linux kernel and then start an HTTP server to handle a single
           | request is utter madness, which is probably why this will
           | become popular to do.
        
             | flir wrote:
             | I can see my house from up here!
        
         | bnchrch wrote:
         | If this is a step on the road to wasm being the primary target
         | for packaging applications (without a docker image + x86
         | emulator intermediary)...
         | 
         | Then I am all for it.
        
       | mteam88 wrote:
       | Would recommend checking out the container examples, they are
       | suprisingly fast.
       | 
       | https://ktock.github.io/container2wasm-demo/
        
       | dave1010uk wrote:
       | Any performance benchmarks or details of the practicality? Eg
       | could this run on something like Cloudflare Workers?
        
       | johncolanduoni wrote:
       | Wow, haven't seen Bochs mentioned since I was doing hobby OS
       | development 15 years ago. I guess there's not a ton of emulators
       | that don't use JIT or hardware extensions these days.
        
         | ex3ndr wrote:
         | Same here! One of my very first apps for android 1.1 was a port
         | of bochs =)
        
       | loxias wrote:
       | Whyyyyyyy.
       | 
       |  _bangs head into desk_
        
       | txdv wrote:
       | Maybe these containers should be build for wasm-wasi instead of
       | x86 from the beginning? Then there would be no need to emulate
       | x86 in wasm
        
         | jedisct1 wrote:
         | Because "wasm-wasi" is not a CPU that Linux runs on.
        
           | traverseda wrote:
           | But, if docker is running on WASM-WASI like it is here, maybe
           | it's possible to do a full build toolchain as well?
        
             | jedisct1 wrote:
             | Docker is not running on wasm. There's a wasm app, that is
             | a x86_64 CPU emulator, used to run a Linux VM, on top of
             | which anything can run. Including existing Docker images
             | for x86_64.
        
       | momojo wrote:
       | Is this a "why not" project, or are there real-world use cases
       | for this?
        
         | simonw wrote:
         | Being able to run ANY Docker container directly in the browser
         | is incredibly useful. The most obvious application is
         | educational environments - this makes it trivial to provide all
         | sorts of software for students to tinker with without needing
         | to run any server-side code anywhere, just some static file
         | hosting.
        
           | Havoc wrote:
           | I very much doubt it's "any" docker image. WASM isn't 1:1
           | feature equivalent with docker. e.g. filesystem access
        
         | jedisct1 wrote:
         | There are tons of real-world use cases.
         | 
         | WASM is more or more being used to extend applications with
         | custom functions/plugins, as well as function-as-a-service
         | services. But they usually require writing custom code,
         | specifically for these environments.
         | 
         | The ability to build standard containers, use any languages and
         | tools, run shell scripts, etc. makes WebAssembly far more
         | accessible. Complex applications can be tested natively, and
         | deployed effortlessly later to environments that require
         | WebAssembly.
         | 
         | From a performance perspective, this is not optimal. But from a
         | productivity perspective, this is awesome, and definitely
         | something to have in your toolbox when all you need is get
         | things done.
        
       | rehitman wrote:
       | If this performs, and it is a big if, it can make life a lot
       | easier for people with stateful services. You just push the
       | service back to the browers and you are done. It can be a lot
       | cheaper and lot faster, and also reduce complexity of making a
       | stateful service scalable and reliable.
        
       | ble wrote:
       | the most amazing, most wirth's law project
        
       | Y_Y wrote:
       | FROM riscv64/alpine:20230208         RUN apt-get update && apt-
       | get install -y curl
       | 
       | The demo really is Debian, but it seems like the docs are
       | confused about which images use Alpine instead.
        
       | apignotti wrote:
       | Shameless self-promotion: https://webvm.io
       | 
       | Powered by a x86->Wasm JIT. Technical writeup:
       | https://labs.leaningtech.com/blog/webvm-server-less-x86-virt...
        
       | jpeeler wrote:
       | Do any GUI frameworks support WASM?
       | 
       | I've been looking for a way to run GUI applications remotely for
       | a while, specifically on a wlroots compositor. Projects like this
       | (maybe one day) and https://github.com/udevbe/greenfield are
       | interesting since they essentially make access universally
       | accessible.
        
       ___________________________________________________________________
       (page generated 2024-01-03 23:00 UTC)