11–20 of 32 posts
If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
I tend not to use that sort of thing, but not just because of docker - there's a bundle of related practices that tend to turn my eye elsewhere. YMMV.
If you're bored (or your code is still compiling), you can also try: SerenityOS: http://copy.sh/v86/?profile=serenity (one of their developers contributed PAE support to v86, which is extra cool. I believe it contains their own browser.) ReactOS: http://copy.sh/v86/?profile=reactos Haiku: https://copy.sh/v86/?profile=haiku 9front: http://copy.sh/v86/?profile=9front Android: http://copy.sh/v86/?profile=android Kolibri…
If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
There's a generation of people who appear to treat docker images as a combined packaging/distribution mechanism. Instead of learning to create a .deb or .rpm, they write a dockerfile. I tend not to use that sort of thing, but not just because of docker - there's a bundle of related practices that tend to turn my eye elsewhere. YMMV.
If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
There's a generation of people who appear to treat docker images as a combined packaging/distribution mechanism. Instead of learning to create a .deb or .rpm, they write a dockerfile. I tend not to use that sort of thing, but not just because of docker - there's a bundle of related practices that tend to turn my eye elsewhere. YMMV.
Earlier quoted context omitted.
There's a generation of people who appear to treat docker images as a combined packaging/distribution mechanism. Instead of learning to create a .deb or .rpm, they write a dockerfile. I tend not to use that sort of thing, but not just because of docker - there's a bundle of related practices that tend to turn my eye elsewhere. YMMV.
It's very true. However what is intrinsically better about a .deb or .rpm apart from having been there first? Are they the epitome of something? This is an honest question, I am really not sure. I vaguely remember that making an rpm was unpleasant and not very well documented, but it's been about ten yeats now...
Rpm/deb packages can also install man files, command line tools, gui apps, and so on that can run directly in your operating system.
If you're bored (or your code is still compiling), you can also try: SerenityOS: http://copy.sh/v86/?profile=serenity (one of their developers contributed PAE support to v86, which is extra cool. I believe it contains their own browser.) ReactOS: http://copy.sh/v86/?profile=reactos Haiku: https://copy.sh/v86/?profile=haiku 9front: http://copy.sh/v86/?profile=9front Android: http://copy.sh/v86/?profile=android Kolibri…
If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
It makes for a cool demo (and it's a reference to the recent "wasm in docker" announcement).
If you're bored (or your code is still compiling), you can also try: SerenityOS: http://copy.sh/v86/?profile=serenity (one of their developers contributed PAE support to v86, which is extra cool. I believe it contains their own browser.) ReactOS: http://copy.sh/v86/?profile=reactos Haiku: https://copy.sh/v86/?profile=haiku 9front: http://copy.sh/v86/?profile=9front Android: http://copy.sh/v86/?profile=android Kolibri…
Can you explain in more detail how this recompilation works? When is it triggered? Because your emulator is still very slow, and recompiling doesn't seem to help. A wiki or blog post would be helpful.
It's much faster with recompilation than without, but I agree that it's slower than expected (compared to, for example, qemu-tcg).
There is still room for improvements (e.g. eflags updates, 16-bit instructions, call/ret optimisations, main loop), but part of the problem is limitations of web assembly (no mmap, only structured control flow) and browser engines (memory blow up on large generated wasm modules, related to control flow).
The webvm folks explain the control flow problem quite well, and seem to be doing a better job than v86: https://medium.com/leaningtech/extreme-webassembly-1-pushing...