[HN Gopher] The Docker+WASM Technical Preview
___________________________________________________________________
The Docker+WASM Technical Preview
Author : soheilpro
Score : 88 points
Date : 2022-10-24 18:33 UTC (4 hours ago)
(HTM) web link (www.docker.com)
(TXT) w3m dump (www.docker.com)
| lolinder wrote:
| Does anyone have a good explanation for what Docker+WASM actually
| is? This announcement explains what WASM is and what Docker is,
| but I already knew both of those and am still confused about what
| Docker+WASM is. Is it just wrapping a WASM binary in a Docker
| container?
| theplumber wrote:
| I guess it's a wasm runtime. Basically a way to execute a wasm
| binary just like you use docker to execute a x64 binary
| stoplying1 wrote:
| Except that would've been too easy to understand, and instead
| seems like they're using wasmedge anyway. Needlessly
| confusing, why do companies do this?
| [deleted]
| timanglade wrote:
| Tim from Docker here. "Docker+Wasm" is just a shorthand for the
| Technical Preview build, which allows you to build both
| traditional container apps, as well as Wasm apps. Behind the
| scenes, we try to let Wasm apps be developed largely without
| interference from any container technology -- just giving you a
| good local environment you can use to code against. That said,
| if you want, we do offer the ability to run Wasm apps within a
| Docker Compose application. We do also offer the possibility to
| package Wasm apps within an OCI image, with an embedded Wasm
| runtime (WasmEdge) so you can a) easily share these via an
| image registry like Docker Hub, AWS ECR, etc. and b) easily run
| this anywhere you'd run a container. That said it's not
| mandatory, and if you want the benefits of (a) without the
| benefits of (b) you can easily unpack the image to just get the
| Wasm payload and run that however you want. We dove into the
| details of the approach at Kubecon today, and the video should
| be coming out shortly.
| [deleted]
| stoplying1 wrote:
| This seems like a good way to muddle the remaining value prop
| that docker has. I have zero idea why I'd want wasm via
| docker tooling vs what exists, especially as people more more
| and more to not-docker for building and running their
| containers. I think I see what someone is trying to do, but I
| don't know any dev looking for this or having a problem
| solved by it.
| artdigital wrote:
| I read through it at first and thought it was the docker
| desktop app rewritten in wasm instead of electron
|
| I guess it's a wasm runner
| enos_feedler wrote:
| I was just coming here to write a comment that says I think the
| blog post is missing a section. Or it at least feels that way.
|
| At the heading "How do I get the technical preview?" I was
| expecting a heading that says "What is Docker+WASM?"
|
| Glad I am not the only one
| nateabele wrote:
| Apologies in advance for a bit of a rant, but I sincerely hope
| the tools growing up around WASM significantly diminish the need
| for Docker. As an industry, we're so bad at isolation that we
| have to put a computer (container) inside a computer (VM) inside
| a computer (hardware) just to achieve any sort of sane
| guarantees.
|
| Then we immediately trade any semblance of sanity for container
| orchestration.
|
| (And please don't try to convince me that Kubernetes is sane. I
| operated a production SaaS on it for 4 years, and spent another
| year at a DevSecOps consultancy with 40+ CKAs--sanity and
| familiarity are not the same.)
| rglover wrote:
| > As an industry, we're so bad at isolation that we have to put
| a computer (container) inside a computer (VM) inside a computer
| (hardware) just to achieve any sort of sane guarantees.
|
| We don't. But shortsighted design, rushing, and herd mentality
| around "hyped" tech make it a virtual certainty more like this
| will exist, just in different shapes and sizes.
|
| You can run most stuff on a baremetal box or VM w/ direct
| install of dependencies. All of this container stuff, sorry to
| say, is a grift save for some extreme multi-tenant use cases.
| VikingCoder wrote:
| Time to watch "The Birth & Death of JavaScript" again.
|
| I don't remember exactly when he says it's time to get rid of
| containers and VMs, but it's in there...
|
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| matai_kolila wrote:
| > sanity and familiarity are not the same
|
| I know this wasn't your main point, but if I could reasonably
| tattoo this onto my forehead I would.
| timanglade wrote:
| Tim from Docker here. Broadly, we agree. The goal of this
| Technical Preview is not to encourage Wasm to be mediated by
| containers in production, but rather to enable people to
| locally build & package Wasm apps easily. In production, that
| could look like a number of different scenarios, from "bare
| metal" edge (just running in a Wasm VM), to running your Wasm
| workloads in a nomad/k8s cluster if that's what you need (e.g.
| if you want hybrid container/wasm orchestration).
| nateabele wrote:
| Hey Tim, I appreciate your willingness to engage. What I'm
| getting at is a bit more pointed. In terms of composability,
| Docker and WASM are opposites: Docker _requires_ a stand-
| alone runtime, and an orchestration layer, etc., whereas a
| WASM module & runtime can be embedded directly into my
| application, into a browser, or into (comparatively) simple,
| time-tested tools like Apache[0].
|
| So, to your point, the opportunity here is to provide WASM-
| native alternatives to existing container-specific
| technologies, that are more composable by design, because
| they don't have to deal with the complexity of trying to ape
| an extra operating system just to run some software.
|
| For example, I'd love to see container orchestration be
| supplanted by something like a la carte Erlang-style service
| discovery--that's a primitive that could easily be composed
| with other primitives, and wouldn't result in the
| combinatorial explosion of nouns we see in systems like k8s /
| Swarm / others.
|
| [0] https://github.com/vmware-labs/mod_wasm
| timanglade wrote:
| No disagreement here! Just to contextualize: Docker -- the
| company as it exists today -- is singularly focused on the
| development experience, i.e. the inner loop of
| code/test/build, not the outer loop of deploying to
| production (which is largely controlled by cloud platforms
| and k8s at this point). I know that separation can seem
| arbitrary, considering containers are largely successful
| because they help bridge the two, but that's just the
| reality of what we're focused on in our daily jobs @
| Docker.
|
| Within that framework, we see Wasm as extremely compatible
| with our goals of improving the local development
| experience, and yes, giving people alternatives to
| container-centric approaches. I'm personally inclined to
| agree with the points you are making about opportunities in
| orchestration, but we're starting today by just trying to
| give people to a solid toolset that lets you iterate on
| your Wasm apps locally, and easily export the resulting
| artifacts, so you can deploy them as you see fit. In the
| process we try to be careful about shedding any container-
| centric assumptions, while porting over some of the wins of
| the docker tooling that we think can translate well to Wasm
| (easy local dev environment, standard artifacts, broad
| platform compatibility across Windows/Linux/M1, etc.) We
| will happily work with anyone interested in working with us
| to improve the production/deployment landscape for Wasm,
| and in fact I would say the main reason that drove us to
| launch this technical preview today, was to attract
| feedback on how the Wasm community (ourselves included)
| could best deliver an alternative path to production for
| applications going forward.
|
| Hope this makes sense and that I understood your point
| accurately!
| nateabele wrote:
| > _Hope this makes sense and that I understood your point
| accurately!_
|
| I'm happy to hear all of that and, yes, I believe you
| did.
|
| > _Docker [...] is singularly focused on the development
| experience, i.e. the inner loop of code /test/build, not
| the outer loop of deploying to production (which is
| largely controlled by cloud platforms and k8s at this
| point)._
|
| I would push back on this a bit: although it may not be a
| focus, and that's totally fair, deployment is undeniably
| part of the developer experience, particularly within the
| context that containers were born into (i.e. DevOps
| values of continuous deployment & no silos). I certainly
| wouldn't presume to tell you what to do, but I would
| suggest that Docker is uniquely situated to address
| developer experience from end to end.
|
| > _We will happily work with anyone interested in working
| with us to improve the production /deployment landscape
| for Wasm_
|
| If you gave us a path out of containers for the end-to-
| end developer experience, I believe many of us would be
| eternally grateful. Let me know how I can help.
| [deleted]
| [deleted]
| gigel82 wrote:
| Insert "BUT WHY?" GIF here.
|
| Seriously, if you're in a position to be running native code in
| your environment why would you chose WASM? If you're building
| WASM for the web, is it really more expensive to build a pure
| native target out of the same source? Surely, performance wise
| you'll always be ahead going native.
| AlmostAnyone wrote:
| The same reason you're using Docker itself
| nateabele wrote:
| Put simply, more powerful isolation than Docker (with explicit,
| granular managed effects), and a simpler operating model, i.e.
| no container orchestration. You can actually compile modules
| from disparate stacks that call into one another in a single
| runtime.
| javaunsafe2019 wrote:
| And for just that give up all the freedom docker runtimes
| give us? I don't want to be forced to use go or rust - maybe
| I'd like to use bash, node or even the jvm depending on the
| problem I need to solve.
|
| And I don't understand why docker is supporting this as
| docker + wasm makes no sense at all as wasm wants to replace
| docker as the runtime provider ...
| nateabele wrote:
| > _And for just that give up all the freedom docker
| runtimes give us?_
|
| Constraints give you freedom because they allow you to make
| guarantees. Checksums, reliable test suites, and good
| software abstractions are all examples.
|
| > _I don't want to be forced to use go or rust - maybe I'd
| like to use bash, node or even the jvm depending on the
| problem I need to solve._
|
| Those are runtimes, not languages. Here's a list of
| languages that compile to WASM:
| https://www.fermyon.com/wasm-languages/webassembly-
| language-...
|
| IMO bash wouldn't make sense, but Java and Kotlin are
| there, as well as AssemblyScript, which is basically
| TypeScript.
| postalrat wrote:
| So that your wasm images (or whatever they are called) can
| continue to run on whatever hardware cloud providers can build
| for as cheap as possible.
|
| Could be x86, arm, some native wasm hardware, who knows. As
| long as it's cheap.
| [deleted]
| [deleted]
| nuc1e0n wrote:
| Very nice. More lightweight virtualisation is a thing to
| celebrate :)
| maxmcd wrote:
| Nice. I'm excited because there are lots of different ways to run
| WASM on a server, different ABIs, different runtimes, etc etc. A
| big move like this might make it easier to standardize around
| some kind of server-side WASM happy path and also provide
| pressure to move some of the Wasi feature work along faster.
| pjmlp wrote:
| Mainframe and microcomputer language environments welcome the new
| kid on the block.
| mikesir87 wrote:
| Michael Irwin from Docker here (and author of the blog post too).
| Happy to answer your questions, hear feedback, and more!
| Raed667 wrote:
| maybe a naive question: is there a way to run some form of
| docker in the browser? It could be a great education / demo
| tool
| mikesir87 wrote:
| Great question! There isn't a way to run Docker directly in
| the browser. But, there are tools (like Play with Docker at
| play-with-docker.com) that lets you interact with a CLI in
| the browser to run commands against a remote cloud instance.
| I personally use this a lot for demos and workshops!
|
| But... certainly a neat idea to think about what Wasm-based
| applications could possibly look like/run in the browser!
| westurner wrote:
| Is it possible to sandbox the host system from the guests
| in WASM?
|
| Are there namespaces and cgroups and SECCOMP and blocking
| for concurrent hardware access in WASM, or would those
| kernel protections be effective within a WASM runtime? Do
| WASM runtimes have subprocess isolation?
| pistoriusp wrote:
| Hey! Peter from Snaplet here. This is really exciting
| stuff. We created the OSS postgres-wasm
| (https://github.com/snaplet/postgres-wasm) example a few
| weeks ago. An idea I'm playing around with is something
| like: 1. Visit
| https://postgresql.com/try?version=14.x 2. Visit
| https://nodejs.com/try?version=16.15.1 3. Visit
| https://edit.com
|
| Edit.com opens a text-editor and terminal where I have
| access to the NodeJS binary and a connection string to
| PostgresQL. Want Redis? Open a new tab at
| https://redis.com/try, where the connection string will
| appear in the edit.com tab.
| Raed667 wrote:
| I used https://wasm.supabase.com/ to make sure some SQL
| commands I was writing for a blog were correct. It was
| super useful and faster than starting docker desktop,
| looking for the postgres image name, starting it etc..
|
| I miss a feature where I can share a link with some
| data/schema pre-seeded (maybe from a gist?)
| pistoriusp wrote:
| We're working on it. We'll allow you to export (via
| SQLite) and import (via SQLite), and even promote to a
| preview database:
| https://docs.snaplet.dev/references/preview-databases
|
| Snaplet.dev is a tool that copies, minimizes and
| transforms your production database into a shareable
| file.
| screamingninja wrote:
| All three links that you posted appears to be either
| broken or malicious. Are you just trying to explain a
| concept using example domain names? Consider " _.example
| " or "_.example.com" (see RFC 2606) instead of
| potentially malicious domains.
| stavros wrote:
| He's saying that the sites could provide ready-to-try
| binaries of their products that run in a tab immediately.
| DeathArrow wrote:
| Why would I want to compile my app to WASM if it's not running
| in a browser?
| saidinesh5 wrote:
| It depends on whom you ask/what your app does.
|
| For serverless usecases, cloudflare etc.. found that it would
| be faster to just call a function from a wasm binary than
| spin up a whole docker container [1]. Which basically
| translated to cost savings.
|
| In the last company I worked for [2], we saw wasm as a way to
| easily ship user code in a cross platform way. We mostly
| targeted edge-ml use cases. Wasm allowed us to package all
| the "libraries"/functions needed to run the user code
| securely. So users created and tested out their ML apps in
| browser and deployed them to all the platforms we supported.
| (Mobile, Browser, Embedded). As an added bonus they could
| write each of their functions in any language that compiled
| to wasm, and just ship it as one "app".
|
| 1. https://blog.cloudflare.com/cloud-computing-without-
| containe... 2. https://hotg.dev/
| mikesir87 wrote:
| Great question! The promise (and excitement) of Wasm is to
| have portable, secure, quick-to-start, and low resource usage
| apps. So, write code in Go, Rust, C++, or any other language
| that can output to Wasm (up to over 40 now!) and you're good
| to go! The binaries are super small too. Happy to dive in
| more too!
| qbasic_forever wrote:
| Why not run that go/rust/etc code natively on the machine
| though? Is there extra sandboxing, network/filesystem
| virtualization or anything gained by compiling to and
| running in a WASM environment?
| nequo wrote:
| AFAIK yes. This interview covers the safety aspects of
| WASM and you might find it interesting:
|
| https://rustacean-station.org/episode/030-krustlet/
| saidinesh5 wrote:
| Gained by you running your app on your own server? not
| much really. Gained by some "serverless" provider who
| tries to run multiple apps like yours, in parallel on the
| same machine? Yes. Less process overhead. _Probably_ ,
| less memory footprint too.
| vbezhenar wrote:
| One benefit of using wasm is architecture-agnostic
| binary. Right now you can't run x86 binary on ARM or
| vice-versa. So basically you need to build your
| containers twice if you have macbook people and x86
| servers. And technically those are different images, so
| there's chance that you'll hit some non-trivial
| difference. With wasm everything could be simpler.
| encryptluks2 wrote:
| A majority of software already does this. WASM seems more
| like a direct attempt to run binary blobs and to simply
| "trust" the intrusive binary sandbox while leaking all
| kinds of information when trustworthy sandbox solutions and
| multi architecture compilation are nothing new and not a
| new problem that needs solving. It seems if anything the
| problem people are trying to solve with WASM is how to get
| people enthusiastic about handing over more privacy.
| petilon wrote:
| What problem is this solving?
| steve_adams_86 wrote:
| I'm curious about this too.
|
| I wonder if it could make testing frontend code that uses
| WASM (but not DOM) fast and easy since you wouldn't need to
| fire up a complete browser environment.
|
| I'm not sure that it's possible at the moment. In the past
| when I needed to test a WASM integration, I ended up using
| that approach and it was kind of a pain not to get immediate
| feedback on the WASM code's API tests since it was
| essentially only testable through the complete integration
| environment.
|
| I like integration tests, but I like smaller and faster test
| suites for easing development in some conditions as well.
|
| You can currently test a WASM-targeted API if you use unit
| tests or other language-level testing approaches, but you
| won't get the constraints of the WASM runtime as far as I
| know. Maybe the lack of garbage collection could be a
| critical constraint to test against.
|
| I suppose you could even test dynamically linked binaries
| without a browser as well.
|
| I'm sure there's far more to it that I'm not aware of, and
| maybe testing really isn't that useful of a feature here --
| I'm just guessing based on my own experience.
| mikesir87 wrote:
| Depends on which "this" you're referring to. We (Docker) are
| trying to make it easier for developers to use the tools and
| capabilities they know and love to build, share, and run Wasm
| applications.
|
| As far as Wasm itself, it's designed to provide a fast,
| lightweight, secure, and portable binary format. While it was
| originally designed to help bring native code to the browser,
| it's quickly spreading to the server side. Many folks are
| using it for edge/IoT, but it's growing into other areas (saw
| demos today of even using it in databases as psuedo stored
| procedures). Happy to dive in more if you have more
| questions!
| Twirrim wrote:
| I'm honestly really confused about the specific role docker
| is playing here.
|
| What, exactly, is Docker doing? Is it compiling the
| application? Is it making a runtime for the wasm binary? Is
| it being the runtime for the wasm binary, so the end user
| builds through whatever usual build processes and gets a
| binary they can then easily run?
|
| If the wasm binary is lightweight and portable, why is
| docker useful?
|
| edit: Given the other comments about "what problem does
| this solve" I think maybe the blog post has missed its mark
| slightly
| VWWHFSfQ wrote:
| Yeah. Not trying to be cynical, but this feels like
| someone at Docker said "we need to have a WASM story" and
| this is what they came up with. I really don't see the
| point.
| [deleted]
| petilon wrote:
| I didn't get anything from that. My question was not about
| WASM but Docker+WASM project. Why problem does it solve?
| synergy20 wrote:
| the only thing I see is that after wrapping wasm inside a
| docker you can leverage all those docker tools(k8n,etc)?
| the docker solves portability and scalability issues with
| a reasonable overhead, so wasm hides inside docker can
| benefit from some?
| saidinesh5 wrote:
| Easy orchestration and deployment is the only thing I can
| think of. Because of docker's infrastructure.
|
| But tbh if orchestration is really the concern, Docker +
| wasm seems less efficient than having a dedicated app
| that can orchestrate multiple wasm modules within the
| same process. But maybe that's something docker can solve
| later as the actual requirements emerge.
| [deleted]
| tester756 wrote:
| Great work, WASM is the future!
|
| But on the other hand I'm not really happy with the fact that I'm
| waiting for GC and DOM access since 2019 or something like that
|
| and it doesn't seem like we're getting close
| k__ wrote:
| They just want to protect the frontend from the C#/Java crowd.
| tester756 wrote:
| No chance, we're already compiling those to our wasm-based
| frontend apps
| throwaway290 wrote:
| You can run Java in the browser now but at least you can't
| touch DOM...
| [deleted]
| skohan wrote:
| What compromises does WASM have relative to plain old native
| code?
| paulgb wrote:
| One thing I've seen come up a lot is that people got used to
| treating containers as a portable unit of code, and then
| Apple Silicon threw a wrench in that assumption. A WASM
| module is the same regardless of whether you're running it on
| arm, amd, or anything. (Alas, the cost of this portability is
| that it's 32-bit)
| saidinesh5 wrote:
| Wasm = just a bunch of bytecode executing in a VM / a
| sandbox. Even with JIT, it will still be slower than the
| native code.
|
| And since it is a sandbox.. either you, or your friendly wasm
| interpreter (via. wasi etc...) needs to provide the system
| access APIs for various things like storage/filesystem
| access, hardware acceleration via. GPU, TPU etc.. And some of
| the standard APIs we take for granted.
| mikesir87 wrote:
| There are a few things we're excited about, many of which we
| fully recognize are used in marketing/buzzword bingo. But,
| they really are around portability (compile to a Wasm module
| and run on any architecture), isolated sandboxing (leveraging
| much of the research and investment used to protect web
| browsers), and super fast startups (obviously depends on the
| app too).
|
| There are a few limitations right now, some of which lack of
| built-in garbage collection and multi-threading. You also
| have to use a language that can completely compile to Wasm,
| making it hard (sometimes impossible) to leverage already
| built libraries/binaries.
|
| But... the tech is growing rapidly and we're excited for it!
| Happy to dive in or answer more questions if you'd like!
| skohan wrote:
| Yeah it's a super interesting topic, thanks for sharing!
|
| A couple questions:
|
| 1. What use cases are you targeting, or which ones do you
| think have the most benefits from wasm?
|
| 2. What tools/stack are you currently using, or which ones
| do you think are the most promising?
| syrusakbary wrote:
| This is great. We've been chatting with Docker for a little bit
| (I'm Syrus, from Wasmer) and it's great to see that they are
| making progress on improving the developer experience around
| WebAssembly.
|
| However, I see Docker (and thus, Kubernetes) is as technologies
| of the past (I don't intend to start any flamewar, I really
| believe this by heart). Metal compute (Web 1.0) lead to VMs which
| then lead to Containers (Web 2.0 / Cloud) and now we are seeing
| what the next wave will look like thanks to WebAssembly.
|
| Of course, there's ton of profit that has been generated thanks
| to the added complexity of current technologies and abstractions.
|
| We have now the opportunity to rethink what the future will look
| like. Long live Wasm
| _mme wrote:
| I don't know Syrus nor Wasmer :)
|
| However, I'm genuinely interested - why would this make
| Kubernetes obsolete? If Wasm rules the future, as you believe,
| why shouldn't it run in a pod?
| syrusakbary wrote:
| Here are some of the thoughts behind my reasoning that I
| posted previously in HN. Hope the are insightful!
|
| https://news.ycombinator.com/item?id=27158187
|
| https://news.ycombinator.com/item?id=26271806
| _mme wrote:
| Thanks, this is interesting, but also very abstract.
|
| What do you mean when you say "scaling on the level of a
| function"?
|
| Do you mean any "plain old" function or a specific REST
| endpoint like AWS Lambda?
|
| If you could just throw distributed computing resources at
| any function that is a bottleneck in your code, that would
| be alien tech.
| vlunkr wrote:
| Even if you change the unit of computation in k8s from a
| container, that's only one problem that it solves. What
| about deployments, services, ingress, configmaps/secrets,
| jobs, volumes, etc. If you're going to create your own
| distributed system, all these concepts are going to exist
| in some form.
| timanglade wrote:
| Tim from Docker here. Long live Wasm indeed! Obviously we feel
| a bit differently about Docker and k8s being in the past --
| Docker is used by 68% of professional developers according to
| the latest SO survey[0], and k8s is still growing in popularity
| at 28%. But obviously the technology landscape changes rapidly,
| and maybe one day (we hope) Wasm will be at 28%, 68% or higher.
| We're frankly just excited about the possibilities, and wanted
| to help along the way :)
|
| [0]: https://survey.stackoverflow.co/2022/#most-popular-
| technolog...
| syrusakbary wrote:
| Hi Tim. The stats logic will probably apply as well for gas
| car makers vs electric ones, or any field to that matter that
| might be at risk of disruption in a perceivable timeframe
| (but are not disrupted just yet).
|
| Don't get me wrong though, I have tons of admiration for
| Docker (in fact, Solomon Hykes is an investor in Wasmer) and
| the great ergonomics you introduced along the way to help
| developers and reach the current status quo. Without you guys
| probably we would have reached the cloud advancements much
| later in time. However, we paid those advances with an order
| of magnitude greater complexity in other layers (with the
| likes of cloud providers profiting from it).
|
| But now I sincerely believe we need more powerful
| abstractions for the edge, serverless and Web 3.
|
| In any case, I'm incredibly excited that you are researching
| more into WebAssembly. That's great for the ecosystem and
| also will help to bring more devs onboard. Thanks for all the
| work!
| tevlon wrote:
| Solomon Hykes, the father of Docker agrees:
| https://twitter.com/solomonstre/status/1111004913222324225?s...
|
| the tweet is from 2019
| samkon wrote:
| Don't forget this tweet from a day earlier, which he quotes:
|
| > "So will wasm replace Docker?" No, but imagine a future
| where Docker runs linux containers, windows containers and
| wasm containers side by side. Over time wasm might become the
| most popular container type. Docker will love them all
| equally, and run it all :)
| redox99 wrote:
| Could you explain how WASM replaces containers? Let's say I
| have a backend API written in Java (spring boot). Containers
| basically solve two things, building and running the
| application. What does WASM solve here?
| saidinesh5 wrote:
| Wasm "solves" running your application in a shared
| environment. i.e not your machine but say a cloudflare
| machine, that has to run dozens of applications like yours.
|
| Without wasm, the unit of containerization for them is
| operating system process. Each process spins up a jvm that
| runs your app/backend API.
|
| With wasm, the unit of containerization is the exact
| functions of your backend API. So they can fit more
| "containers" on a single machine, compared to docker. And
| that brings faster startups etc..
| AkshatJ27 wrote:
| For some reason I thought this was gonna be a demo of running
| docker in your browser through WASM. kinda disappointed that's
| not it :p
| syrusakbary wrote:
| Funnily enough, I believe that's completely achievable with
| enough time spent on it (probably a few weeks of an engineer
| working full time).
|
| We have technology like WebVM [1] (from leaningtech / CheerP)
| or Copy86 [2] that already allows x86 machine code
| execution/emulation on the web. If you add an OCI client layer
| on top that is executable in the browser, it should be possible
| to run Docker containers in the browser.
|
| [1] https://webvm.io/
|
| [2] https://copy.sh/v86/
___________________________________________________________________
(page generated 2022-10-24 23:01 UTC)