Wasmer 3.0 Released As The Latest "Universal WebAssembly Runtime"

[NobodyXu]

That's a kind thought, but BTRFS can't mitigate duplicate blocks in compressed storage overlays, which obfuscate them.

I remember that they can do this since basically compares decompressed blocks.

Storage isn't an issue for me. Snap is using less than 1%. RAM usage, in particular page cache usage, is the real problem. When I see 14GB of page cache to run 4 desktop apps, something is very very wrong.

I think Btrfs dedup will help here.

Once the blocks are deduped, the block cache for the fs will also be deduped.

So instead of loading the same data twice in different blocks, it gets loaded only once.

[linuxgeex]

I'm familiar with docker and roughtly knows its underlying tech (namespace, cgroup, overlayfs2).

For this particular cases where each app use different gnome versions, perhaps this can be migrated by using btrfs.
Btrfs supports offline deduplication using a software called bees https://github.com/Zygo/bees
It also supports transparent compression using lzo/zstd, which is very effective at reducing space usage especially if you have multiple versions of a software.

That's a kind thought, but BTRFS can't mitigate duplicate blocks in compressed storage overlays, which obfuscate them.

Storage isn't an issue for me. Snap is using less than 1%. RAM usage, in particular page cache usage, is the real problem. When I see 14GB of page cache to run 4 desktop apps, something is very very wrong.

[NobodyXu]

If you're familiar with chroot-based containers, snapd/flatpak basically roll all the app dependencies into containers, and then use overlay mounts to share the dependencies between installed apps. So there's a chance that 3 apps depending on GNOME will share the GNOME overlay. Sadly in my experience every app depends a different GNOME release, for no clear reason, resulting in having 7 copies of GNOME installed to support 3 apps. One for the host system, 2 for each app. Why 2 for each app? Because one app wants gnome-18, one wants gnome-20, and one wants gnome-22, snap regularly installs refreshed versions of the overlays and keeps the most recent 2 by default. To support 6 desktop apps I have more installed in /snap than I do for the entire well-appointed host OS. Good thing storage is so cheap these days.

I'm familiar with docker and roughtly knows its underlying tech (namespace, cgroup, overlayfs2).

For this particular cases where each app use different gnome versions, perhaps this can be migrated by using btrfs.
Btrfs supports offline deduplication using a software called bees https://github.com/Zygo/bees
It also supports transparent compression using lzo/zstd, which is very effective at reducing space usage especially if you have multiple versions of a software.

[linuxgeex]

Not familiar with snapd/flatpak since I am currently using MacOS.

If you're familiar with chroot-based containers, snapd/flatpak basically roll all the app dependencies into containers, and then use overlay mounts to share the dependencies between installed apps. So there's a chance that 3 apps depending on GNOME will share the GNOME overlay. Sadly in my experience every app depends a different GNOME release, for no clear reason, resulting in having 7 copies of GNOME installed to support 3 apps. One for the host system, 2 for each app. Why 2 for each app? Because one app wants gnome-18, one wants gnome-20, and one wants gnome-22, snap regularly installs refreshed versions of the overlays and keeps the most recent 2 by default. To support 6 desktop apps I have more installed in /snap than I do for the entire well-appointed host OS. Good thing storage is so cheap these days.

[NobodyXu]

So actually, GUI is in good shape.

That's good to hear.

It's very easy to be better than Electron. It's basically impossible to deliver a Hello World Electron app that can run in under 200MB RAM and 70MB compressed binary, and those numbers just keep getting larger.

Well, that's why I don't like these "modern Apps" and why I don't use code editor like vs code or atom but instead neovim.
Their memory usage is way too much.

To be fair, even native cross-platform package systems like Snap, Flatpak etc also slurp the kitchen sink, use even more silly amounts of disk and RAM, and feature unspeakable startup times due to compressing the slurped kitchen sink. Using Box86 you can start up x86 Windows Zoom client faster on a Raspberry Pi under Linux ARM than you can a native x86 Linux Zoom client on a Threadripper under Linux with Snap... sigh.

Not familiar with snapd/flatpak since I am currently using MacOS.

[linuxgeex]

With the current state of WASI, there's definitely a lot lacking, like standardised networking, async, etc and I'm not sure how efficiently wasm can run GUI.
Though its memory usage is probably going to be less than electron, that memory hog.

So far I haven't seen FFI for a wasm -> binary compiler... instead they seem to like slurping the kitchen sink. With popularity will come FFI and then language bindings for many popular libraries... with Node we've been there for some time. There's also QT Creator's new wasm target. So actually, GUI is in good shape. It's very easy to be better than Electron. It's basically impossible to deliver a Hello World Electron app that can run in under 200MB RAM and 70MB compressed binary, and those numbers just keep getting larger.

To be fair, even native cross-platform package systems like Snap, Flatpak etc also slurp the kitchen sink, use even more silly amounts of disk and RAM, and feature unspeakable startup times due to compressing the slurped kitchen sink. Using Box86 you can start up x86 Windows Zoom client faster on a Raspberry Pi under Linux ARM than you can a native x86 Linux Zoom client on a Threadripper under Linux with Snap... sigh.

[NobodyXu]

It details a JVM buffer overflow to begin with, then talks about best practices. But this is only one presentation. Simply google US-CERT JRE and you'll get thousands. Oracle publishes their vulnerabilities semi-annually. Typically there's 3-6 JRE vulnerabilities in JAVA SE affecting a broad cross-section of releases from 8 - 17. I'm not talking about components like Log4j. I'm talking about Java SE Core like Hotspot.

Well I did the google and find quite some CVE reports.
It certainly isn't 100% safe, but what I was trying to say is that JIT itself isn't inherently unsafe or terrible as long as it is properly implemented.

While for some use cases, compiled language is indeed better as you can even disable mmap executable code altogether to avoid some potential bugs, I think it is mostly OK to use.

Jargon/marketing. Rust primarily avoids buffer overflows and use-after-free. Those are important, but Rust is still far from a magic bullet against human error.

It certainly isn't and there is still some code required to be written using unsafe, though these unsafe lines are quite small compares to other safe code and easy to audit.
That is to say, I still think this is an advantage.

Wasmer needs to parse the wasm bitcode, load it plus the compiler like cranelift and singlepass, which is also very complex.
These tasks are typically error prune and there are often out-of-bound bugs in the parser (I heard libexpat also have a CVE which firefox migrates by running it inside wasm, which won't be there if it is just rewritten into Rust) and same for the compiler.

P.S. There's ongoing effort to use the cranelift codegen in rustc to speedup debug build.
I am looking forward to this, in additional to the rustc_codegen_gcc backend.

As I said: in spec, it's safe. But in implementation it is not. I provided links to 2 vulnerabilities disclosed October 2022. There's more.

There will no doubt be CVEs in there, though it is from https://github.com/WebAssembly/wabt which is written in C++.

IMO wasm is still quite an interesting technology.
With "wasmer create-exe", it is possible to distribute binaries by wasi (which is still ungoing standardisation, a shame that makes it less useful) and use wasmer create-exe to generate native executable, compile once and run everywhere with near native performance and near native memory usage compared to JVM.

That's going to speed up development time as it no longer needs to run the CI for every target to be supported and add workarounds for them, plus release and distribute is also going to be way easier.

I am one of the maintainers of cargo-binstall, which has to run cargo or use syscall to detect target, add fallback like x86_64-unknown-linux-musl, x86_64-apple-darwin and newly added, not standardised universal-apple-darwin, and then trying to discover the archives on their repository if the link is not explicitly specified.

With wasmer, it's easier as one wasm file can be run everywhere and they even have a dedicated platform to upload and download the wasm files.

I'm not to say cargo-binstall is useless as native still performs better, and sometimes they might link to local dynlibs, and there's now lots of thing wasi cannot do, and probably there are situation where wasm may not be trusted by someone, but having wasm as a fallback really sounds interesting to me.

I wish you'd say something bad about wasmer that's wrong so I get an opportunity to say something nice about it, so I don't have to come across like a hater. I don't hate it. I just think there's better tech available which doesn't reinvent the wheel, fragment the market, and guarantee worse performance in the future. I think wasm is good for what it was designed for - as a way to provide near-native performance for compute-intensive parts of web apps. I think web tech as an app platform in general though is a very bad idea... and this is coming from someone who makes their living delivering web apps.

It's definitely good for web, and maybe for serverless or whatever it is called.
I think it will be interesting to use wasm in distributed computing where traditionally JVM is used, since compiling C/C++/Rust to wasm is way easier and wasm can be used to compile them down to native executable before running.

Though with Graalvm from Oracle, it is also possible to compile C/C++/Rust to run on JVM and maybe mix with Java (IDK if can it optimize them together though) but having some competition here is good because it's Oracle and they already starts charging for enterprise Graalvm which has some more features.
If they have a monopoly, maybe they would even close source it.

When I commented on wasm, I didn't think about app platform.
It might be a reasonable expend of usage in web app and I've seen people trying to do that.
With the current state of WASI, there's definitely a lot lacking, like standardised networking, async, etc and I'm not sure how efficiently wasm can run GUI.
Though its memory usage is probably going to be less than electron, that memory hog.

[linuxgeex]

The link you gave mainly talks about programming error, which has nothing to do with JVM or JIT.
There isn't anything that inherently makes JIT unsafe.

It details a JVM buffer overflow to begin with, then talks about best practices. But this is only one presentation. Simply google US-CERT JRE and you'll get thousands. Oracle publishes their vulnerabilities semi-annually. Typically there's 3-6 JRE vulnerabilities in JAVA SE affecting a broad cross-section of releases from 8 - 17. I'm not talking about components like Log4j. I'm talking about Java SE Core like Hotspot.

BTW, wasmer is written entirely in rust.

Jargon/marketing. Rust primarily avoids buffer overflows and use-after-free. Those are important, but Rust is still far from a magic bullet against human error.

Wasm sandbox is not wishful-thinking software sandbox.

It is a capability based sandbox...

As I said: in spec, it's safe. But in implementation it is not. I provided links to 2 vulnerabilities disclosed October 2022. There's more.

I wish you'd say something bad about wasmer that's wrong so I get an opportunity to say something nice about it, so I don't have to come across like a hater. I don't hate it. I just think there's better tech available which doesn't reinvent the wheel, fragment the market, and guarantee worse performance in the future. I think wasm is good for what it was designed for - as a way to provide near-native performance for compute-intensive parts of web apps. I think web tech as an app platform in general though is a very bad idea... and this is coming from someone who makes their living delivering web apps.

[NobodyXu]

And that requires TLB flushes, which is part of why it's slow. WASM is worse because it's more fine-grained and supports dynamic types, so the pages are more fragmented, requiring more page walks and more flushes.

I'm not familiar with the details design, but AFAIK there have been attempts to speed it up.
There's wizer https://github.com/bytecodealliance/wizer which pre-initializes the program and gives a huge speedup.

Also, I think wasmer actually does not support JVM-like JIT where each function is compiled to native when needed, but the entire image is compiled down the native code at once.
You can also use wasmer create-exe to convert wasm to native elf that can be run directly on the platform.

wasmer supports three compilers: llvm, the one gives the best performance but takes some time to compile.
cranelift, much faster but generates slower code.
singlepass, emit compiled code at linear time and not prone to JIT bombs, but slower than cranelift.

In the 2000's there was apocryphal belief among CEOs that Java was secure by design. There's nothing inherently safe about JVMs. Just because it's used in Enterprise doesn't make it safe. In Enterprise security is almost always hamstrung by compatibility needs, and/or incompetent policy makers relying on narcissistic middle management who would rather throw the company under the bus to make themselves seem important rather than grease the wheels and let frustrated competent security professionals do their jobs. Choice of language in Enterprise has nothing to do with security. If it did, they would use Rust. The vast majority of exploits are implemented in C and Python, but that doesn't stop Enterprise from using C and Python for speed and convenience.

The link you gave mainly talks about programming error, which has nothing to do with JVM or JIT.
There isn't anything that inherently makes JIT unsafe.

BTW, wasmer is written entirely in rust.

Elizabeth Holmes may as well be at the helm promoting WASM. Yes in theory that sandbox is safe in spec. But what about in implementation? The reality is that vulnerabilities are being found regularly still. Like any young project its security will mature with age, but its performance will suffer with mitigations, which was my point... if we want high performance cross-platform binaries there's far more mature (well researched if not decades in implementation) tech to make that work, and I would much rather rely on hardware-enforced security (ie AMD-SEV) than a wishful-thinking software sandbox.

Wasm sandbox is not wishful-thinking software sandbox.

It is a capability based sandbox, where each capability has to be explicitly passed to the program for it to use.
For example, in order for the wasm program to connect to the internet, a capability must be explicitly pass.
For it to listen on ports, another capability is needed.
Same for filesystem operations and other I/Os.

Each wasmer program also operates in separate memory regions, a memory bug in one would not affect other programs and would likely trigger that program to exit.

It also has built-in migration against ROP and it uses clang CFI according to https://webassembly.org/docs/security/

[linuxgeex]

Also it doesn't have unsolvable security problem, the program simply allocates a read-write only mmap first and then writes the generated native binary code to it,
then changes the permission from read + write to executable + read only.

And that requires TLB flushes, which is part of why it's slow. WASM is worse because it's more fine-grained and supports dynamic types, so the pages are more fragmented, requiring more page walks and more flushes.

JVM is used in enterprise all the time so I absolutely have no idea what you are saying.

In the 2000's there was apocryphal belief among CEOs that Java was secure by design. There's nothing inherently safe about JVMs. Just because it's used in Enterprise doesn't make it safe. In Enterprise security is almost always hamstrung by compatibility needs, and/or incompetent policy makers relying on narcissistic middle management who would rather throw the company under the bus to make themselves seem important rather than grease the wheels and let frustrated competent security professionals do their jobs. Choice of language in Enterprise has nothing to do with security. If it did, they would use Rust. The vast majority of exploits are implemented in C and Python, but that doesn't stop Enterprise from using C and Python for speed and convenience.

Well, wasm also supports sandboxing, which also makes it a replacement for docker in some scienarios.

Elizabeth Holmes may as well be at the helm promoting WASM. Yes in theory that sandbox is safe in spec. But what about in implementation? The reality is that vulnerabilities are being found regularly still. Like any young project its security will mature with age, but its performance will suffer with mitigations, which was my point... if we want high performance cross-platform binaries there's far more mature (well researched if not decades in implementation) tech to make that work, and I would much rather rely on hardware-enforced security (ie AMD-SEV) than a wishful-thinking software sandbox.

Sadly, the CEOs will continue to be swayed by golf course gossip instead of listening to their engineers, and making risk-averse decisions to keep insecure, unpatched, unsafe-by-design platforms so they can keep running software that they feel they can't dare replace, because the people who wrote the software have retired lol.