Wasmer 1.0 Can Run WebAssembly 'Universal Binaries' on Linux, MacOS, Windows, Android, and iOS (infoworld.com) 72
The WebAssembly portable binary format will now have wider support from Wasmer, the server-side runtime which "allows universal binaries compiled from C++, Rust, Go, Python, and other languages to run on different operating systems and in web browsers without modification," reports InfoWorld:
Wasmer can run lightweight containers based on WebAssembly on a variety of platforms — Linux, MacOS, Windows, Android, iOS — from the desktop to the cloud to IoT and mobile devices, while also allowing these containers to be embedded in any programming language. The Wasmer runtime also is able to run the Nginx web server and other WebAssembly modules...
Wasmer was introduced in December 2018, with the stated goal of doing for WebAssembly what JavaScript did for Node.js: establish it server-side. By leveraging Wasmer for containerization, developers can create universal binaries that work anywhere without modification, including on Linux, MacOS, and Windows as well as web browsers. WebAssembly automatically sandboxes applications by default for secure execution, shielding the host environment from malicious code, bugs, and vulnerabilities in the software being run.
Wasmer 1.0 reached "general availability status" with its release on January 5, and its developers are now claiming "out of this world" runtime and compiler performance.
"We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside)."
Wasmer was introduced in December 2018, with the stated goal of doing for WebAssembly what JavaScript did for Node.js: establish it server-side. By leveraging Wasmer for containerization, developers can create universal binaries that work anywhere without modification, including on Linux, MacOS, and Windows as well as web browsers. WebAssembly automatically sandboxes applications by default for secure execution, shielding the host environment from malicious code, bugs, and vulnerabilities in the software being run.
Wasmer 1.0 reached "general availability status" with its release on January 5, and its developers are now claiming "out of this world" runtime and compiler performance.
"We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside)."
Congratulations Wasmer! (Score:1, Insightful)
You just invented Java!
Re: (Score:1)
Except Wasmer is language agnostic.
Congratulations Wasmer! (Score:1)
You just invented the thin client!
Re:Congratulations Wasmer! (Score:4, Funny)
Next thing there will be talks of implementing WebAssembly's opcodes in hardware, akin to how, back in the day, there were talks of integrating physical Java processors [wikipedia.org] as co-processors in PCs to speed up Java code execution.
Re: (Score:2)
/Oblog. The Birth & Death of Javascript [destroyallsoftware.com]
So is a JVM you numpty (Score:2)
Ever heard of Jython?
This is just kids re-inventing the wheel. Again. Even the Java JVM was a riff on p-code that was decades old.
Re: Congratulations Wasmer! (Score:2)
So is Java Bytecode.
People just assume it isn't.
Re: (Score:3)
So is Java Bytecode.
In theory, the JVM is language agnostic. In practice, it was designed for Java and other languages don't smoothly compile to JVM. There are projects like NestedJVM and GCC-Bridge that allow C++ to compile to JVM-bytecode, but they are clunky and not widely used.
A big problem is that the JVM has never been as portable as promised. It was supposed to be "Write once, run everywhere" but is actually "Write once, debug everywhere".
Wasm actually delivers what JVM promised. It runs anywhere that has a browser.
Re: (Score:2)
Re:Congratulations Wasmer! (Score:4, Insightful)
I suppose the counter is that multiple languages have targeted JVM and .NET CLI. We don't have a shortage of runtimes available to be a platform that runs on platforms.
Generally speaking each language already has a more tailored strategy for each platform that it supports. I'm not sure there's much to get excited about here compared to the existing mechanisms to run on all those platforms. NodeJS at least has the capability of bringing an otherwise supported directly programmed language out of the browser. No one writes directly in wasm. So you could either compile your C, Go, Rust, etc language to wasm to run under Wasmer, or just compile it to the native platform.
I suppose one could argue that there is an opportunity with a new runtime to set new expectations in a backwards-incompatible way (e.g. a means to implement a different 'deny-by-default' security model). However a lot of platform work has been done to have OSes be able to lock down 'traditional applications', so I'm not sure there's a huge amount of value.
Re: (Score:2)
Re:Congratulations Wasmer! (Score:4, Insightful)
Exactly, which is particularly weird as it's not the 1990s any more. There is virtually no reason to distribute your software as a binary anymore, except for malware. However since the malware industry (mostly calling itself ad-tech now) is fairly big now they were able to create such a monstrosity as WebAssembly.
Although to be fair, in the past we thought that those virtual machines could provide an actual security benefit. People believed that you could somehow put malware in a sand-box so it won't be dangerous any more. This belief has been proven wrong with developments like Rowhammer, Spectre and Meltdown. So the only thing that's left sand boxing against unintended errors. There it could have a hypothetical advantage paling to actual advances in security like the ability for programs to revoke their own access to do syscalls.
So yeah, technically this is a tiny security advantage, however it seems likely that people will just use it to push more malware onto people.
Porting is a hassle (Score:4, Insightful)
The main point is to save time on porting, from OS-specific APIs to maintaining constantly breaking cross-compiling chains for OSes you never actually use personally.
Re: (Score:2)
Yeah, but we are past OS-specific APIs in most areas since we have POSIX. Even Microsoft now supports it!
Re: (Score:2)
And how do I open a window in Posix and draw something into it?
Re: (Score:2)
This is seriously something that is still missing.
Re: (Score:2)
Yeah, but we are past OS-specific APIs in most areas since we have POSIX.
POSIX is great if you trust my code.
What if you don't?
Re: (Score:2)
If you don't trust code, you shouldn't run it. Alternatively run it on hardware you don't care about.
Re: (Score:2)
If you don't trust code, you shouldn't run it.
99% of the time you have no reason to trust a developer's honesty, and even less reason to trust their competence.
Any platform that relies on trust, fails for software distribution.
Alternatively run it on hardware you don't care about.
If an API requires everyone to own a 2nd computer, it isn't acceptable.
Not binaries (Score:2)
That's still not a reason to distribute binaries. The only reason to distribute binaries is to protect and/or obfuscate your source.
Re: (Score:2)
Re: (Score:2)
True, but that's for system configuration. We're talking about WASM, which pretty much by definition is web delivered on request, so they're going to be much smaller.
Re:Congratulations Wasmer! (Score:5, Insightful)
There is virtually no reason to distribute your software as a binary anymore, except for malware
and surveillance - which is a form of malware I guess, technically. There's a reason why Google is such a big proponent of Webassembly.
It's hard enough to filter Javascript shit written in plain text. With Webassembly, it's essentially impossible. That's Big Data's wet dream.
Re: Congratulations Wasmer! (Score:2)
Monsteosity?
Says the guy advocating for, let's be honest, JavaScript source as the execuatable file format... Which, little does he know, is JIT-complied anyway.
Listen, why don't you WhatWG nutters shut up until you get a clue?
Re: (Score:2)
I wonder why people take any criticism of WebAssembly as a praise of JavaScript. JavaScript in the Browser is an absolute disaster from a security standpoint.
Re: (Score:2)
Congratulations Turing Complete! (Score:2)
Anything more capable than TXT is a, security nightmare.
Re: (Score:2)
Java with an even shittier intermediate language. But without stoner Sun or shitty Oracle and that makes it considerably different.
A clean internet. (Score:2)
Damn, name change. I first read that as "washer". No telling what one can run the web on these days.
Write once, run anywhere (Score:2)
Where is OS/2 Warp? (Score:2)
Re: Where is OS/2 Warp? (Score:2)
Inferno or die!!!
Re: (Score:2)
Inferno or die!!!
Whoa there, none of this modern OS stuff. Plan 9 first. Walk before you run!
Another day, another wheel re-invented (Score:5, Insightful)
Horray. So we got rid of Java in browsers because for [reasons] it was insecure. Then 20 years later along comes another generation who are too cool for school and can't be bothered to learn whats already been before, and come up with a brilliant idea - lets have a portable binary format running in browsers and call it Web Assembly! Yeah! And so the wheel turns again.
As Churchill said âoeThose that fail to learn from history are doomed to repeat it.â
Re:Another day, another wheel re-invented (Score:5, Insightful)
As Churchill said ÃoeThose that fail to learn from history are doomed to repeat it.
Actually, you misunderstand Webassembly: those who want it *have* learned something from history, and they want it back very badly: they learned that if you can plant a virtual machine in everybody's computer running obscured code, they can essentially own said computers without the users being able to do a damn thing about it.
The bad actors of today are also in a position to force it down everybody's throat - something Sun and Oracle were never able to do.
Another day, another complaint re-invented (Score:2)
You mean that all those smart hackers out there are incapable of "being able to do a damn thing about it"? People who take apart closed-source software for fun.
Re:Another day, another wheel re-invented (Score:4, Funny)
Don't worry, some hardware fab with too much time on their hands will make a cpu that directly executes wasm. Then the 80's can be calling back with p-code engines for everyone and the cycle will really be complete ;).
Re: Another day, another wheel re-invented (Score:1)
Says the guy who apparently never heard of Turing completeless and different levels of grammars / code formats.
Did you know that pure HTML4 + CSS3 was already Turing complete? (All that was missing, was a clock to drive it, which required somebody to just click the same spot all the time.)
If you got JS, and something as complex as CSS3's layout engine, adding WASM won't change a thing. Especially with webGL and webSockets and WebCluelessWhatWGiPenisExtensionNo374.
I suggest getting a clue yourself before cal
Re: (Score:2)
"I suggest getting a clue yourself before calling out clueless people"
LOL :) Says the gimp who thinks this has anything to do with Turing completeness. Did you see that phrase on a techy christmas cracker and think it would make you look intelligent if you used it in a post? Man, I've heard it all now.
Re:Another day, another wheel re-invented (Score:5, Informative)
Horray. So we got rid of Java in browsers because for [reasons] it was insecure. Then 20 years later along comes another generation who are too cool for school and can't be bothered to learn whats already been before, and come up with a brilliant idea - lets have a portable binary format running in browsers and call it Web Assembly! Yeah! And so the wheel turns again.
As Churchill said âoeThose that fail to learn from history are doomed to repeat it.â
Java applets, flash, and web assembly seem similar on the surface: they all had a binary bytecode type instruction set that browsers could download, JIT compile, and execute.
But when you look underneath, the implementation is completely different. WASM's architecture avoids most of the problems that plagued those predecessors.
When the browser ran a java applet, it basically created an area on the screen and handed full control over to the JVM. The JVM was exempt from the browser's security barriers and thus had it's own. You basically had 2 applications running where one just rendered in an area allocated by the other.
WASM does not work that way at all. WASM uses the same javascript runtime your browser already has, and therefore it reuses your existing battle-tested and mature security mechanisms. WASM is basically a more efficient format than javascript for feeding your existing javascript engine. WASM is a lot closer to javascript than it is to java or flash in that aspect.
Sure, both java and flash died, but if you look back, flash was particularly popular for browser-based games. Clearly there was value in it. WASM is just as good (better?) for games, but without the second engine, and the security nightmare that comes with it. I make games, and I can tell you that WASM is the holy grail for browser-based games.
Browser vendors learned from java and flash mistakes. When designing WASM they didn't repeat history, they learned from it. Check out this article [steveklabnik.com] that goes more in-depth.
Re: (Score:2)
Its perfectly possible to trap operations done by a sub process or a thread (how do you think debuggers work?) so there was no excuse for browsers to just hand over complete authority to a plugin other than the browser devs couldn't be bothered to code in any checks. Sure, WASM using callbacks into browser APIs rather than rolling its own might make it easier to check but in no sense does it suddenly make it possible when it wasn't before.
Re:Another day, another wheel re-invented (Score:4, Interesting)
Besides the security nightmare, Java and flash did not have access to the browser's DOM, they were _forced_ to be a separate application in a rectangle. Even if you trap operations, the bloat of having a separate application with massive runtimes and the complete lack of integration with anything else in the browser was still very much a problem. By leveraging your javascript engine, WASM is part of your web page and can interact with other elements on the web page.
You can mix and match javascript and WASM as much as you want to get both convenience and performance where it matters.
WASM is not really a more secure reimplementation of java and flash. I would describe WASM as a more efficient reinvention of javascript.
the fools! (Score:3)
WASM needs (I repeat NEEDS) to never have access to browser APIs or DOM APIs. Only a simple I/O is all that is required. As soon as you add complexity you create not only security issues but support and maintenance issues! If you want WASM to work well, you'll restrict the API severely so it works everywhere forever without versioning nightmares.
Let javascript deal with the hell of gluing to the ever changing (not necessarily evolving) environment.
As far as security, yes if a DOM api security bug exists,
Re: (Score:3)
Even if (IF) you're spot on -
From the point of view of the end user, Java and Flash did occasionally have legitimate uses. However the majority of the time, they were used for purposes which the end user found problematic and irritating - e.g. advertising, tracking. I expect this will be the same with WASM.
In my view, the vast majority of web sites I visit have no particular reason to run WASM in my browser. I'm going to want to be able to maintain a whitelist of which sites are allowed to execute WASM - by
Re: (Score:2)
You already can right now.
NoScript on Firefox, ScriptNo on Chrome and other browsers already do per-site Javascript, and WASM is just a fancy form of Javascript internally (more efficient to parse, and restricts usage to "fast" Javascript operations).
Re: (Score:2)
But but but this is new and shiny and it's webscale
Re: (Score:3)
As Churchill said "Those that fail to learn from history are doomed to repeat it."
That was not Churchill, but George Santayana [wikipedia.org].
Re: Another day, another wheel re-invented (Score:2)
They said the same thing paraphrased but churchills was more succinct.
Re: (Score:2)
"Those that fail to learn from history are doomed to misquote it."
It's more Web than is Assembly (compact JavaScript (Score:5, Interesting)
WebAssembly is a fundamentally different kind of thing than Flash or Java applets. Flash has actual assembly, native CPU code; web assembly is more Web - there is no actual assembly code.
WebAssembly is essentially a compact representation of JavaScript. To use some JavaScript, the browser must do the following:
1. Download the textual JavaScript file
2. Parse the text of the JavaScript into tokens and the tokens into a syntax tree.
3. Convert the syntax tree into V8 bytecode
4. Run the V8 (JavaScript) bytecode
Those steps happen in every page load. Which is silly because it's a waste to do steps 1-3 over and over, parsing jQuery over and over again.
WebAssembly essentially does steps 1-3 once rather than over and over. That doesn't give scripts written in WebAssembly any access to do anything the original JavaScript couldn't do; it's just more efficient, faster. It's basic capability is exactly the same as JavaScript, it's run by and in the browser the browser in the same way as JavaScript, and has precisely the same security impact as JavaScript. Really if you think of it as just another way to write JavaScript that's not far off (not technically precisely true, but very close).
On the other hand, Flash and Java are full programs, separate from the browser, that have the capability to do anything that any program can. To avoid the obvious security issues with that, the Flash and Java programs try to fence off certain known-dangerous operations. Which leaves Flash and Java exploitable by either a) going around and through the fence or b) finding ways to do dangerous things with allowed operations. That's fundamentally much more dangerous than JavaScript, including JavaScript that has been pre-parsed and handed to V8 as bytecode, aka WebAssembly.
Re: Another day, another wheel re-invented (Score:2)
Java had its own api. Which is why it failed in the browser. Webassemly is just an execution engine, it exposes the hosts api (eg the DOM in the browser)
YAJBLF (Score:3)
Yet Another Java-Bytecode-Like Format.
Anyone old enough here, who can tell me what older, better universal machine code there is? So obviously not x86 due to lack of universality. RISC perhaps? Is there something even older and more universal, that's before my time?
And would RISC-V be an improvement?
I propose lambda calculus. Specifically, unlambda. ;))
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org] and https://en.wikipedia.org/wiki/... [wikipedia.org] come to mind the first time this madness happened...
Re: (Score:2)
The Queen twitted "Let them have LOGO".
Western Digital Microengine CPU (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Behold! I present, THE WHEEL! (Score:2)
I am unsure as to why people think reinventing the wheel this time is expected to go any differently than before. In order to have any real success it will need to be used by companies. However, just how many companies are incapable of targeting multiple platforms? Recompilation is far less of a problem than people make it out to be because there are multiple APIs that target a wide array of platforms as well as free compilers for just about every platform and architecture.
Microsoft proved (via Common La
Re: (Score:2)
This is going to be used by many companies to test only on their favorite platform and claim it works everywhere. If you're not compiling per platform, are you planning on testing per platform?
Re: (Score:2)
This is going to be used by many companies to test only on their favorite platform and claim it works everywhere.
Pretty typical behavior. They do the same thing with Java.
Performance is a Trojan horse for DRMs and ads... (Score:5, Insightful)
Re: (Score:2)
WebAsm will be used to kill adBlockers, Youtube-DL and make web-DRM a standard. JS may be a pain but at least you can inspect/alter what your browser is loading... for now.
You forgot mining bitcoins. How would people like it when every web page come with a WebAssembly program to mine bitcoin using your CPU while you browse?
Of course it would also steal any data it can get its hands on and send it back to mothership.
Yay! One step closer (Score:2)
"Wasmer, the server-side runtime which "allows universal binaries compiled from C++, Rust, Go, Python, and other languages to run on different operating systems and in web browsers without modification"
Hooray! One step closer to universal malware that can run seamlessly on any platform!
Maybe this *will* be the year of Linux on the Desktop after all! woo hooo!
Shellification is ignorance (Score:2)
Instead of packing software into one shell after another to gain more security does the industry need to focus on fixing security problems at the root. Ignoring the causes and wasting performance on fixing only symptoms, while each new performance gain is more costly than the previous one, cannot be a lasting solution. Nobody wants to spend more money on a faster machine when the end users don't get much of the gains and instead it's used on solving problems created by others.
No more Javascript, please. (Score:2)
WASM is supposed to be language-agnostic, but no one can deny that it's really meant to further entrench Javascript and keep it elevated above its station. It was a terrible day when JS, an intern's tech demo prematurely flung into production 25 years ago, was let out of the browser.
Those that are ignorant of the past are doomed (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Does not support RPi 32 bit. (Score:2)
Re: (Score:2)
I'm not ready to give up my 32-bit ARM systems or my Thumb platforms. But if I were to build out a data center or a serious system for use in a business, it'd be all x64 or aarch64 based (like the ThunderX series from Marvell). If there is a big cost in supporting new architectures, I'd choose the ones I support very carefully. I might even pick POWER support over 32-bit ARM, depending on my target user.
Universal computer (Score:1)
Unanswered blockers (Score:1)
WebAsm will be used to run Bitcoin miners, kill adBlockers and Youtube-DL and make web-DRM a standard and
These fundamental problems mentioned above have not been addressed by WebAsm's many defenders.
As I see it, as with Cookies and Javascript, these systems start as optional and the defence is that "you can always disable it".
You can.
But after a few years of infiltration, the normal functioning of web sites is made to DEPEND on them, so you cannot disable them and use that web site.
( e.g. Many anti-social websites still require cookies to function, even those based in jurisdiction that forbid that. )
Why will W
1995 wants its Java platform back (Score:1)
Wasmer == JVM when = (Score:2)
You can compile your C++ legacy code into WASM and get native-like performance, for example:
https://yowasp.org/