NaCl
category: code [glöplog]
I see that pNaCL uses LLVM, that's a great step forward for NaCL towards maybe one day cross browser support. But honestly I think (p)NaCL is gonna be hard to sell to Mozilla, Apple, Opera and MicroSoft.
On the other hand that LLVM step makes me think that the resulting code and the browser's JavaScript will be pretty much on par.
JavaScript has become incredibly fast(er) over the last few years: You know, JavaScript code isn't parsed at runtime all the time. It's "compiled" into some intermediary bytecode pretty much like LLVM or something closer to the metal, which is then traced/compiled into native code as much as possible.
What the browser implementors must really optimize is CSS (parsing, style computation, layout/reflow, redraw ) and DOM ( that's usually the #1 perf killer ). Hopefully DOM4 will help there.
On the other hand that LLVM step makes me think that the resulting code and the browser's JavaScript will be pretty much on par.
JavaScript has become incredibly fast(er) over the last few years: You know, JavaScript code isn't parsed at runtime all the time. It's "compiled" into some intermediary bytecode pretty much like LLVM or something closer to the metal, which is then traced/compiled into native code as much as possible.
What the browser implementors must really optimize is CSS (parsing, style computation, layout/reflow, redraw ) and DOM ( that's usually the #1 perf killer ). Hopefully DOM4 will help there.
Hyde: here.
Quote:
But honestly I think (p)NaCL is gonna be hard to sell to Mozilla, Apple, Opera and MicroSoft.
please elaborate. why do you think that's the case ?
The technology is free (open source), and everyone's free to participate in the design discussions and/or incorporate it.
If it eases your (or your boss') mind, Google did not invent this, they "simply" picked up the idea (which stems from the 90ies).
Quote:
On the other hand that LLVM step makes me think that the resulting code and the browser's JavaScript will be pretty much on par.
I don't think so. NaCl performance already rivals native execution speed and languages like JS simply were not designed for that task.
JS may be fast(er) nowadays but a decent C compiler is usually 5-10 times faster.
Last but not least, why limit web programming to one language instead of supporting *any* language ?
What I like about the NaCl concept is that it is *simple*.
Instead of just relying on the security of one rather complex runtime and API, it relies on the safety of the most low level execution environment. That's a good thing, IMHO.
Quote:
What the browser implementors must really optimize is CSS (parsing, style computation, layout/reflow, redraw ) and DOM ( that's usually the #1 perf killer ). Hopefully DOM4 will help there.
amen to that. Code execution speed is one thing but whole system performance is indeed quite a different topic.
Defiance: Thanks, but I was looking for an answer that justifies saying that NaCl is as bad as Active X. What I would like to know is the security design in Active X compared to that of NaCl. My theory is that the opponents use the following line of reasoning: NaCl = Native Code = Active X = EVIL, ==> NaCl = EVIL. It seems like there is a little more to it than that, but I would like to hear it from those who think this is an acceptable conclusion.
xyz: 'free' and 'open source' don't necessarily actually mean 'free' when it comes to using it, if it turns out it uses some patented technology (Google are finding that out with android and webm). Plus, 'open' doesn't always mean 'open' when it's google. That might not apply here, but it's why other companies might be hard to persuade.
Whether it's a good idea or not? It sounds like it. That, with native performance plus webGL for graphics while still being portable, would be pretty damn cool. But I think I'll wait until it's been out in the wild for 6 months and the security researchers have given it a good going over :)
Speaking of security + stability, is webGL 'fixed' yet?
Hyde: I guess it's the same theory of letting random websites start running code on your system, then trying to make sure something bad doesn't happen? I can't see that being a good comparison though, google were surely *very* aware of the security aspect right at the start. Security should be built right in rather than slapped on later when it goes pear shaped ;)
Whether it's a good idea or not? It sounds like it. That, with native performance plus webGL for graphics while still being portable, would be pretty damn cool. But I think I'll wait until it's been out in the wild for 6 months and the security researchers have given it a good going over :)
Speaking of security + stability, is webGL 'fixed' yet?
Hyde: I guess it's the same theory of letting random websites start running code on your system, then trying to make sure something bad doesn't happen? I can't see that being a good comparison though, google were surely *very* aware of the security aspect right at the start. Security should be built right in rather than slapped on later when it goes pear shaped ;)
hyde, compared to activex the nacl is running in a secure context. however, i see a problem with nacl applications and portability. the power of websites is that they can be displayed on a majority of devices.
rasmus: where would portability be a problem? I'm guessing the llvm byte code is reasonably portable between architectures, and I've used llvm with intel and arm - which must be 99% of the clients covered.
I don't know, running native code in browsers should always be taken...
*puts on sunglasses*
...with a grain of salt.
(YEEEEEEEEEEEAAAAAAAAAAAAAAH!)
*puts on sunglasses*
...with a grain of salt.
(YEEEEEEEEEEEAAAAAAAAAAAAAAH!)
Quote:
What I like about the NaCl concept is that it is *simple*.
Instead of just relying on the security of one rather complex runtime and API, it relies on the safety of the most low level execution environment. That's a good thing, IMHO.
The problem is that you forgot that also a NaCl executable must "reach out" to the world in a certain way, and that's where you also have an API. That puts it at about the level of security of Javascript (depending on what said API actually exports), assuming the sandbox is safe.
Apart from that psonice is right - choosing another target platform means simply using another backend for LLVM. The idea behind PNaCl is quite good, even if it's kinda Java/.NET all over again (bytecode based VM and standardised API). But then again the "compile the bytecode to native and run in virtualized sandbox" approach is new, and probably faster than conventional bytecode interpreters or JIT compilers that need to honor lots of security considerations. With PNaCl the safety of the code is back in the programmer's hands again - worst (theoretically spoken) thing that can happen is that you mess up your own sandbox, and that's your own damn problem :)
Also, thanks to Gargaj for making me LOL in the office and uncover the fact I'm procrastinating :D
...aaand there! Hyde suddenly got the salt-joke.
so how was the security of Active X taken care of? was it based on the "use at your own risk"-strategy and then frantically patched when things started going to hell?
Hyde: remember the windows 98 "login" box that asked you for a password, but you could just press escape if you couldn't be arsed? It was that era ;)
@Hyde: Please also see previous page for some low level implementation info.
The basic idea is that the code may only contain certain instructions / instruction sequences / jump targets / constant tables so that a validator can ensure that the code stays sandboxed.
Plus it requires Harvard architecture style NX-bit CPU support (for clear separation between code and data)
As for ActiveX: The big difference is that
a) The code is validated/sandboxed before execution
b) The only access to the outside world is allowed via a strictly defined API.
ActiveX puts the security in the developer's hands (you can do everything a regular exe or dll can) and the only means of
user trust is established via (very expensive!) code-signing.
ah, and
c) it only works on Windows!
@psonice: Yes, let's hope that there are not any patent strings attached. And yea, as I already said, allowing arbitrary web sites to run arbitrary code is always bad, even if the (scripting) VM is secure (just take a look at the recent SSL/TLS security issue, for example).
IMHO the decision which code to run should be left to the user, which should also include a fine-grained access control model. I would not want to see this being abused for advertisement or user-tracking, for example.
However, this might be outside the scope of NaCl and something that the browser implementors must take care of (pretty please!).
@kb: I did not forget about that, that's why I said that the API should be as simple as possible. Heh, and if you take a look at the results of the NaCl security contest(s), the outside-world interface was the main attack vector. IIRC, there was only one ticket where someone found a bug in the code validator.
Now if that outside-world interface would be sandboxed as well.. (just to be sure..)
All that being said, I'm definitely not a Google fanboi but I consider this quite exciting technology. Good to see I'm not the only one :)
This could be a real nice demo platform. As far as I've understood the LLVM concept, the bytecode/bitcode is already an intermediate step
for the Clang C/C++ compiler (sponsored by Apple, for example) so I would expect that pNaCl will not seriously degrade the performance (if at all).
The basic idea is that the code may only contain certain instructions / instruction sequences / jump targets / constant tables so that a validator can ensure that the code stays sandboxed.
Plus it requires Harvard architecture style NX-bit CPU support (for clear separation between code and data)
As for ActiveX: The big difference is that
a) The code is validated/sandboxed before execution
b) The only access to the outside world is allowed via a strictly defined API.
ActiveX puts the security in the developer's hands (you can do everything a regular exe or dll can) and the only means of
user trust is established via (very expensive!) code-signing.
ah, and
c) it only works on Windows!
@psonice: Yes, let's hope that there are not any patent strings attached. And yea, as I already said, allowing arbitrary web sites to run arbitrary code is always bad, even if the (scripting) VM is secure (just take a look at the recent SSL/TLS security issue, for example).
IMHO the decision which code to run should be left to the user, which should also include a fine-grained access control model. I would not want to see this being abused for advertisement or user-tracking, for example.
However, this might be outside the scope of NaCl and something that the browser implementors must take care of (pretty please!).
@kb: I did not forget about that, that's why I said that the API should be as simple as possible. Heh, and if you take a look at the results of the NaCl security contest(s), the outside-world interface was the main attack vector. IIRC, there was only one ticket where someone found a bug in the code validator.
Now if that outside-world interface would be sandboxed as well.. (just to be sure..)
All that being said, I'm definitely not a Google fanboi but I consider this quite exciting technology. Good to see I'm not the only one :)
This could be a real nice demo platform. As far as I've understood the LLVM concept, the bytecode/bitcode is already an intermediate step
for the Clang C/C++ compiler (sponsored by Apple, for example) so I would expect that pNaCl will not seriously degrade the performance (if at all).
xyz: "I would not want to see this being abused for advertisement or user-tracking" and "Made by the world's largest advertising company" might not be compatible :D Actually I'm not aware of any issues with that so far, I suspect they just want to use this to push more software onto the web, where they can sell advertising to go alongside (or inside) it. Fine for us if that's the case.
I doubt there will be any performance issues, like you say llvm is just the intermediate step before the compiler. I've been using that for a while now, as it's the default compiler for iOS + osx these days. It's supposed to produce faster code than gcc I think, not actually tested that myself though.
I doubt there will be any performance issues, like you say llvm is just the intermediate step before the compiler. I've been using that for a while now, as it's the default compiler for iOS + osx these days. It's supposed to produce faster code than gcc I think, not actually tested that myself though.
@psonice: yep, that's why it is important that other, possibly more privacy-conscious browser vendors adapt this ;)
(not to say that some carefully placed advertisement, for example in a free-as-in-beer game, could not be tolerated!)
It is also quite clear to see how that fits into Google's Web-OS strategy.
Don't get me wrong, that's not a bad thing but especially the API/privacy aspect calls for a W3C involvement and should probably
not be left to one single company, IMHO.
For the time being, I am glad they have picked up POSIX (a well respected standard). Everthing beyond that may be subject to discussion. :)
As far as I am concerned, this is the way to go!
(not to say that some carefully placed advertisement, for example in a free-as-in-beer game, could not be tolerated!)
It is also quite clear to see how that fits into Google's Web-OS strategy.
Don't get me wrong, that's not a bad thing but especially the API/privacy aspect calls for a W3C involvement and should probably
not be left to one single company, IMHO.
For the time being, I am glad they have picked up POSIX (a well respected standard). Everthing beyond that may be subject to discussion. :)
As far as I am concerned, this is the way to go!
I was very sceptical about this (as one could perhaps read @ Displayhack) but I've turned around a little. I still think it's conceptually off -- but this implementation isn't half bad. Would like to play with it when I find some time.
JavaScript (HTML5) has all the momentum in the world at the moment, with every browser vendor (including Microsoft) actively pushing it. I'm with p01 on this one; have a hard time seeing this take off. Perhaps if Google decide to go with it full on it could quickly become a serious alternative thanks to Chrome Frame:
http://code.google.com/chrome/chromeframe/
Mozilla would still need to find it in their heart to add support though, and then there's Apple, who certainly wouldn't like to support native-level competition for their App Store apps...
http://code.google.com/chrome/chromeframe/
Mozilla would still need to find it in their heart to add support though, and then there's Apple, who certainly wouldn't like to support native-level competition for their App Store apps...
It seems that Google tries hard to push browser-side execution ahead.
1) Google is participating in the elaboration of ECMA Harmony, the next generation of Javascript (not much an improvement on speed, but more elaborate syntax).
2) Google is launching a new language called Dart (formerly Dash), that is speculated to be a replacement of both Java and Javascript for the browser (with Java-like speed).
3) NaCl, and then PNaCl, based on LLVM, for native-like execution speed.
1) Google is participating in the elaboration of ECMA Harmony, the next generation of Javascript (not much an improvement on speed, but more elaborate syntax).
2) Google is launching a new language called Dart (formerly Dash), that is speculated to be a replacement of both Java and Javascript for the browser (with Java-like speed).
3) NaCl, and then PNaCl, based on LLVM, for native-like execution speed.
they need it for their notebooks to be successful
Personally, I am more excited about Dart than NaCl, even though almost no details have been published yet. Knowing the people who've implemented Dart (the team behind the V8 JavaScript engine in Chrome), I can tell you it is going to be fast. Really fast.
I would rather have one fast, well-designed and well-supported language for browsers than a way to run native code which will only work on x86 platforms. Let's see if Google manages to convince other browser vendors to throw out JavaScript and rally around a completely new language. It's going to require a lot more than execution speed.
I would rather have one fast, well-designed and well-supported language for browsers than a way to run native code which will only work on x86 platforms. Let's see if Google manages to convince other browser vendors to throw out JavaScript and rally around a completely new language. It's going to require a lot more than execution speed.
In order to get NaCL or Dart in other browsers, Google would have to propose them for standardization. So far, it doesn't look like Google is gonna do that.
If Google really wants Dart, NaCL, whatever in other browsers, they should be more open instead of re-inventing the web behind closed doors then releasing one open source implementation and hope other browsers will say hooray.
See Brendan Eich on Dart and NaCL and the more colorful Andrea Giammarchi on Dart.
If Google really wants Dart, NaCL, whatever in other browsers, they should be more open instead of re-inventing the web behind closed doors then releasing one open source implementation and hope other browsers will say hooray.
See Brendan Eich on Dart and NaCL and the more colorful Andrea Giammarchi on Dart.
a) Microsoft chose Javascript for his Windows 8 platform. They certainly won't welcome competing language or VM with open arms.
b) Apple is locking people into his appstore and certainly don't want their users to have access to web apps that are as good as what's on their store.
c) Opera is too small a team to enjoy the perspective of doing significant efforts into supporting yet another language or VM.
d) The creator of Javascript works at Mozilla. So it's not surprising that they're quite protective over it.
To sum it up, Dart and NaCl are epic efforts by Google to leverage the web platform.
But they're pretty much alone in the foreseeable future to make them a success. Only then will other browsers be forced to reconsider their view on these technologies.
b) Apple is locking people into his appstore and certainly don't want their users to have access to web apps that are as good as what's on their store.
c) Opera is too small a team to enjoy the perspective of doing significant efforts into supporting yet another language or VM.
d) The creator of Javascript works at Mozilla. So it's not surprising that they're quite protective over it.
To sum it up, Dart and NaCl are epic efforts by Google to leverage the web platform.
But they're pretty much alone in the foreseeable future to make them a success. Only then will other browsers be forced to reconsider their view on these technologies.
I don't think web apps will ever be as good as proper native ones. It's not just speed, it's all the extra stuff the OS provides to the apps. Like if you made java as fast as c++. Take a look at the average java app, make it faster. Likely you still don't want to use it if there's a decent native equivalent :)
Comparing apple + google's browser strategies is kind of weird btw. Apple are promoting pure html5 + js + css etc., while google are promoting nacl, dart, flash on android etc. And look at html5/css etc. compatibility between iOS and android - iOS seems to come out ahead from what i've read.
Comparing apple + google's browser strategies is kind of weird btw. Apple are promoting pure html5 + js + css etc., while google are promoting nacl, dart, flash on android etc. And look at html5/css etc. compatibility between iOS and android - iOS seems to come out ahead from what i've read.