Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Container2wasm: Convert Containers to WASM Blobs

github.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Container2wasm: Convert Containers to WASM Blobs

#61

Post by buildfocus »

benno128 wrote: post #54

Really impressed by the depth and breadth of this project, well done! A particularly interesting part is the socket layer inside the browser. Other people solving this problem have previously used a proxy to a server that does the real socket implementation. This means you can't have a "browser-only" solution. The author has solved this (for HTTP/S only) by proxying HTTP requests and then re-creating them as fetch re…

That does have some major caveats of course: some headers will be totally ignored by the browser due to web restrictions, some will be added/overridden (e.g. user agent), and CORS will apply (which will seriously surprise most Linux tools!).

Still, very neat, agreed. Almost certainly the best you can do without having some kind of backend proxy running on either the server or the user's own machine.

Re: Container2wasm: Convert Containers to WASM Blobs

#62

Post by jedisct1 »

charcircuit wrote: post #28
jedisct1 wrote: post #14

Earlier quoted context omitted.

Because "wasm-wasi" is not a CPU that Linux runs on.

Why is that relevant? txdv was suggesting to ditch Linux, so what CPUs Linux supports is not relevant.

If you ditch Linux, you now have to write a kernel, not an application.

Re: Container2wasm: Convert Containers to WASM Blobs

#63

Post by nanaian »

kelvie wrote: post #40
apignotti wrote: post #22

Shameless self-promotion: https://webvm.io Powered by a x86->Wasm JIT. Technical writeup: https://labs.leaningtech.com/blog/webvm-server-less-x86-virt...

It's a bit hard to tell, but this isn't open source (well, assuming we all don't consider wasm source :)), right? I got as far as "powered by cheerpx", which leads me here: https://leaningtech.com/webvm/ And I'm also guessing that you guys just allow free use of the compiled wasm for demos such as this?

Yep! CheerpX's documentation is available here: https://labs.leaningtech.com/cheerpx

Re: Container2wasm: Convert Containers to WASM Blobs

#64

Post by berkes »

jpeeler wrote: post #25

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.

Not exactly what you are looking for, probably, but Leptos[1]. Dioxus[1.1], Yew[2] and almost all "frontend web frameworks in rust" run primarily/only on WASM. Larger list here[3]

[1] https://github.com/leptos-rs/leptos, https://github.com/dioxuslabs/dioxus

[2] https://yew.rs/

[3] https://github.com/flosse/rust-web-framework-comparison#fron...

Re: Container2wasm: Convert Containers to WASM Blobs

#65

Post by londons_explore »

rehitman wrote: post #18

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.

And all the users have to download a 200MB web page every time they use your service...

Re: Container2wasm: Convert Containers to WASM Blobs

#68

Post by xyzzy_plugh »

nox101 wrote: post #50
xyzzy_plugh wrote: post #48

Earlier quoted context omitted.

If the issue is that implementations are feature lacking, that's a different story. The world is littered with half baked frameworks. Hell, I've used plenty of retained mode frameworks that lack all of those things too. My concern was moreso that there is nothing inherent to immediate mode that prevents all of those things. Someone just has to build it. RTL tends to be more of a layout problem and has little to do wi…

I disagree that "someone just has to build it." For example, when iOS shipped it did not have spell checking, word lookup, translation, password insertion, etc built in as context menus on text. When those features were added by the OS, every app using the native widgets got those features for free with no work on their part. Apps that rolled their own though, had to re-release their app. If they don't have time or t…

Sure, I'm not arguing against using native widgets. I'm not suggesting that immediate mode necessitates eschewing all of those things or hand rolling them. There is a difference between native frameworks and cross-platform frameworks.

Did Qt magically support all of those features on day 1? Xamarin doesn't completely support all of the iOS input properties, for example.

This feels like a straw man.

Re: Container2wasm: Convert Containers to WASM Blobs

#69

Post by traverseda »

jedisct1 wrote: post #21
traverseda wrote: post #16

Earlier quoted context omitted.

But, if docker is running on WASM-WASI like it is here, maybe it's possible to do a full build toolchain as well?

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.

Sure, fine, if an largely-compliant OCI runtime is running in a wasm-wasi context, then I see no reason you couldn't stub out syscalls to reduce dependence on linux-kernel syscalls, and gradually replace the kernel with a minimal set of stub syscalls that make sense, sort of like how gvisor has implemented 200+ linux syscalls in GO and presents an alternative OCI runtime for docker containers.

Gradually reduce dependence on an emulated linux-kernel in favour of an alternative lightweight POSIX implementation that runs in pure WASM. This is something that is already done with other OCI runtimes like sysbox and gvisor.

Re: Container2wasm: Convert Containers to WASM Blobs

#70

Post by pseudosavant »

nox101 wrote: post #45
xyzzy_plugh wrote: post #43

Earlier quoted context omitted.

Immediate mode UI frameworks are not inherently less appropriate than any other framework. Curious what the source of that is.

In my experience Immediate mode UI frameworks are almost always not very internationalization friendly (right to left text like Arabic, problematic IME support) and, they are almost always not very accessibility friendly. Also things like system context menus to offer features like translation, system level spelling correction with the user's custom dictionary, system password memorization and recall, word lookup, et…

This was exactly my experience building an app at my last company that used an immediate mode UI. You get so much baseline accessibility 'for free' if you use the DOM.
Post reply on HN