PNaCl: The 2010s answer to ActiveX.
*waits for the inevitable Eadon rant*
At its annual I/O conference in San Francisco this week, Google unveiled a new version of its Native Client technology that allows developers to deploy binary code for web applications in an architecture-independent way. With the original version of Native Client (NaCl), developers could write modules in C or C++ and compile …
PNaCl: The 2010s answer to ActiveX.
*waits for the inevitable Eadon rant*
No need for the joke alert icon.
It is a fair comparison, although I'm not sure other browsers were/are allowed to implement ActiveX even if they wanted to? PNaCl seems a dumb idea to me, you could just write a desktop app, so I can't seem other browsers wanting it really. It's technically very cool but I don't want every app to be inside the browser.
PNaCl is different than ActiveX. First, programs are expressed in an intermediate format called LLVM bitcode so they either run in a VM, or they can be laced with memory & security checks as they are turned into native code. So the program would essentially have its own address space, heap, stack and file storage space separate from other apps or the OS. Second, the APIs that they can use are restricted and implemented by the browser host which can do additional security checks. Thirdly apps are only hosted through the Chrome Webstore which IMO limits the tech's usefulness but does allow them be tested for malicious behaviour and removed if necessary.
An ActiveX component is just a native DLL or EXE. It can literally do anything it likes, OS security permitting. So if it was registered as as safe for scripting, and was exploitable, any malicious website could instantiate it, exploit it and own you.
None of this means that PNaCl is going to be bug free but that's an implementation issue which can be fixed rather than a flaw in the concept itself.
I wish other browsers would implement something similar but browser agnostic. Emscripten is a project that allows C to run in a browser by compiling it to LLVM bitcode and compiling that into JS which is what gets run. Performance is naturally horrible. Running the bitcode directly would be much faster, potentially near native.
Well done for missing the point, nobody said NaCl and ActiveX are alike technically (I know exactly what an ActiveX or NPAPI plugin is since I've written one). Rather that they are both attempts by dominant browsers to force standards on the world.
Since the point wasn't spelt out or even implied, I chose to address the technical aspect. Also, it's not like there was an open standard for plugins in other browsers. Netscape's NPAPI is as proprietary in its own way as ActiveX.
And maybe Google are forcing it, which is why it's more important than ever that there be an open standard equivalent to it in terms of capability and performance.
Cross platform compiler tech is high art. That's why we revere Dennis Ritchie so: not only did he do it, he made it look easy. 40 years later we can't simplify his work because he reduced it to least principles before publishing. Every derivation of his art we try to advance the field leads to self-defeating complexity. He is the Einstein of code.
"An ActiveX component is just a native DLL or EXE. It can literally do anything it likes, OS security permitting"
That's quite a big if, since one of the functions of any half-decent OS is precisely to sandbox user-level processes with "address space, heap, stack and file storage space separate from other apps or the OS" that you mention earlier on. ActiveX got its deservedly dismal reputation because Microsoft did not do this, so you ended up with arbitrary code from untrusted sources running with all the (usually administrative) privileges of the logged-on user.
This is the problem that doesn't really go away with PNaCl, although it's clear here that Google's strategy is to create a world of Chrome-only web applications, paving a way for Chrome OS only webapps and ultimately a closed web controlled by Google.
"ActiveX got its deservedly dismal reputation because Microsoft did not do this, so you ended up with arbitrary code from untrusted sources running with all the (usually administrative) privileges of the logged-on user"
A common misconception. ActiveX actually had more support for security than NPAPI (the only real alternative). The difference was the Microsoft's tools made ActiveX control creation and consumption very, very easy. As a result lots of non-web applications were built from ActiveX controls without any consideration for what that meant in terms of the risk that they were inadvertently exposing to the web. If VB5 had marked ActiveX controls as unsafe for scripting by default and made it just a tad harder for web development, it would have never have developed the bad reputation in ultimately did.
If NPAPI is proprietary how come it is supported in WebKit/Chrome and was even supported in older IE.
Not being able to grasp the point under discussion and going off on a technical tangent is a typical nerd failing. Only nerds would find it ambiguous what was being discussed.
And we do have a standard for running native code on different platforms - it's called an application. No reason to run it through the browser at all, unless of course you are trying to turn the browser into the OS and show that you don't need anything else... hardly a coincidence it's Google doing this.
Having said that, plugins are a pig and NPAPI is pretty ancient, but browsers are moving away from plugins already.
The asm.js FAQ suggests it could reduce the 5x overhead of running code over JS down to 2x compared to native execution. Sounds like a worthy thing to do for the likes of emscripten. The bottleneck is still the need to convert to JS, even a subset.
The first thought that occurred to me was, hmm doesn't run on Java. I know I am missing some steps, but I get the feeling that Oracle is the next company to get its lunch eaten by Google.
Google already ate Oracle's lunch. Oracle sued and Google won. Have you been asleep for a decade?
> Have you been asleep for a decade?
Sometimes it seems that way.
I'd say that case was about stolen recess cookies since it was really an acquired property from Sun (and judge Alsup found that the cookies had been dropped anyhow - guy's middle name is a programming language, how ironic and to boot, he learned Java for the trial). I was surprised when Google didn't pony up the 6 bil for that sale, guess we know why.
< I'll see your beer and raise you a shipload of rum (some pirate's lunch :), stolen, naturally), cheers mate
Until Google can make make a reliable high performance db which you can run on your own hardware l think Larry can keep counting his income in billions.
Yes Google has big table, but it only runs in Googles data centre and is not acid.
If you own a mobile phone you probably update an Oracle database about 500 times a day. Everytime you change base stations you will update at least three databases and probably as many as ten. Most telcos use Oracle for this because its fast and doesn't lose data.
That is an excellent point James, about the own hardware. I also have this preference personally, but I see many businesses going the other route. Thanks for the example about telecom providers, it gave me a few ideas for how to investigate my initial thesis further as I still think that even a small fraction of businesses migrating away can hurt profitability.
About the no-ACID, it actually has that now with Datastore (though I haven't looked into it in depth):
With all this in mind, it would likely be companies which utilize their data primarily internally rather than for customer facing instant data needs that are the prime target for such a switch.
When logging into our online bank, we recommend you don't use Google Chrome ...
I still don't see where the advantage is. JS-interpreters are so amazingly fast these days, you will have problems getting any advantage from having some byte code.
However the disadvantages are obvious. Byte code is much harder to check for malware, and it's much harder to edit it when you have found some.
> JS-interpreters are so amazingly fast these days,
My experience of google docs spreadsheets would disagree with that and JS is relatively hard to code for if you've grown up with C.
A lot of the benefit is in application delivery. The idea is to devalue microsoft on the desktop by making apps cross-platform and delivered via http, which cuts out the wintel support team and reduces the cost of trials and roll-outs. It replaces the windows interface libraries with a browser one, which is an easier direction to take than to do java on the desktop or find some other reason to drop win32 interfaces.
I like the idea.
In theory its an excellent idea.
But in practice it will be a niche product at best, too many applications require use of OS-specific APIs, so even if the delivery method is cross-platform, the vast majority of apps will not be.
> too many applications require use of OS-specific APIs, so even if the delivery method is cross-platform...
Well, this may change pretty fast in a way not well-becoming to the "too many applications".
...doesn't Sodium Chloro-phosphate sound both unstable and toxic?
...pinochle - Sundar Pichai is the jack of diamonds and he knows the secret identity of the queen of spades...
And we all know how well Sun and Oracle have done with that don't we?
I'm hoping this is not just a plugin replacement.. After all, the point of plugins was that they are OS-specific and managed by a third party.
I'd like it to be an aid for people who currently do cross-platform to make their lives better. For example, network management tools - currently in windows executables could go x86/Chromium to cover off windows, linux and osx. Perhaps an accounting package for small business, where OSX compatibility might be handy. Chat clients would also be good. Even a google-docs type spreadsheet, but with lower latency and local execution.
How good would it be to give people a clean OS and point them to http://apps.corp.com/ ? There are you base apps, talk to your manager if you need something more. It will be interesting to see if the performance turns out to be adequate.
from one tool chain and hosted by one browser.
Can you say "Cross platform proprietary lock in?"
Technically a formidable logistical exercise.
Cutting edge stuff in the 1970's and 80's.
Biting the hand that feeds IT © 1998–2017