Feeds

back to article Google Native Client: The web of the future - or the past?

Chad Austin believes in Google's Native Client because he believes in the web. He sees the web as the ultimate programming platform – something that spans not only disparate devices but the competing interests of the world's corporate tech giants – and he sees Native Client as a way of bringing most any language to the platform …

COMMENTS

This topic is closed for new posts.

Page:

Silver badge
Unhappy

Sink the Bismarck!

This article is somewhat "fair and balanced" as the USerricans say.

That is, it compares something that may be rather dubious proposition [like torture and the surveillance state] to something that is known to work [e.g. defending civil liberties and keeping state out of your pants] by putting both sides on the same level and explaining away differences by "religious attitudes".

I can empathize with the developers of this thing but can I have some marmalade with this buttery slatherfest of complexity, please?

Clearly a torpedo aimed at the steaming-in-circles Wintel platform. I expect Microsoft to line up the lawyers at some point in the future complaining about various IP violations regarding use of its DLLs.

3
4

poo

What a bunch of poo this is! Let me see, they'll have to drop back to bytecode else are google going to support write many times run manywhere? Or is it google.net? Now this is a joke? Native web, isn't that like when I host the browser control in my app or something and call window.external hahahah. What are they playing at!! What are they trying to solve!

Stick to search. You're good at it. Chrome is just a pretty lame application really compared to even something as simple as textpad.

1
5
Silver badge

But what about the sourcecode problem?

Native Client doesn't deliver the source code, so you cannot change it easily which makes it a lot harder for the user of web applications.

BTW, what if there's yet another CPU bug which can halt the CPU or cause privilege escalation?

3
0
Ru
WTF?

What sourcecode problem?

I'm not entirely sure ywho you're thinking about when you say "[this] makes it a lot harder for the user of web applications". Web app users don't care about the source. They probably don't care about the platform, or the company badge on it either. They just want it to work and get out of their way.

Rewriting chunks of it is about as far removed from this ideal as physically possible.

2
1
Silver badge

Acutally, it fixes the source code problem...

One of the hurdles I'm having convincing management that our app should be converted into javascript is the problem of lusers getting at the source. This might allow me to do less sensitive bits in javascript and keep the more valuable C++ in a plugin.

Where's the "have cake and eat it" icon?

2
2
Silver badge

Do not want.

Sounds like ActiveX. From Google.

17
4
Silver badge

It's not activex but it is proprietary

ActiveX has no safeguards in place. Once you run an ActiveX control it has complete power to do anything that the browser itself could do. So if you run your browser as administrator then the control is also administrator. If you run your browser in safe mode, then the control is also in safemode. So basically there is no sandbox beyond what the browser is running in.

ActiveX is fine when you trust your content. So it's okay that programs use ActiveX controls that you explicitly installed. The problem was when they went onto the Internet. Microsoft's security model was a joke. Random websites could invoke any "safe for scripting" control. It soon turned out that not many controls were safe, even those which said they were such as the ones that shipped with MS Office. So MS added a blacklist of bad controls. Then they flipped to a whitelist for the popular controls (e.g. Flash, Acrobat) and disabled other ones.

I'd note also that NPAPI plugins are not sandboxed and can do anything they like too. NPAPI has been luckier because it's a pain in the backside to write NPAPI plugins and Firefox uses a whitelist so only a few "blessed" plugins can be auto installed.

So NaCl does not suffer some of these issues. It is (allegedly) sandboxed, and I assume it has a some kind of same domain policy so your apps must execute and reside from the site they're hosted by.

Problem is that sandboxes have a tendency to leak. A more serious issue is introducing a technology which is restricted to one architecture and one browser is plain stupid. One has to wonder what Google are thinking here. It's not even in their interests to have an x86 only technology when half the devices they want to target are ARM. Do they really think devs like compiling twice?

If I were Google I would take a step back. Recognize that NaCl is a dumb idea and focus on PNaCl. Open up the APIs, tools and development and offer it on open terms and peer review so other browsers can implement the tech, Other browsers might be more favourable to such an approach.

3
0

The "why bother" isn't very clear...

... and usually that means other unspoken agendas are busy. There's a few things I just don't get about Native Client:

- If its security model is working on x86 instructions, how is that portable to non-x86 machines?

- Given how new the verifying-instructions approach is, how can one claim it is secure? It's not been sitting there getting attacked yet - who knows whether there is a glaring hole that the researchers hadn't thought of? Only time will tell.

- The only thing I personally see as a bonus is that you can use a compile-checked and statically-typed language, something that I like better than the dynamic typing and loose OO of JavaScript. But you don't need to support native code to do this. You just need a different language, or simply get stricter with JavaScript, exactly like HTML5+CSS does to old-style HTML. The reasoning of "eases porting existing C code to the Web" isn't exactly inspiring.

On the surface, Native Client fills the same role as Java applets (speed + compiled code). However, it seems more likely to me that Google wants more speed to do things with their Web toys to make them more desirable than the competition's, and their tweaks of their JavaScript engine isn't giving it to them. Hence the Native Client idea.

10
0
Unhappy

You mean XHTML, surely

"You just need a different language, or simply get stricter with JavaScript, exactly like HTML5+CSS does to old-style HTML."

HTML 5 has not gotten stricter, no. That's XHTML for you. What HTML5 is, today, is a loose, shaky, half-baked set of specifications that include how to parse CRAP code. No, XHTML as XHTML doesn't do much good for the end user either, but HTML 5 isn't strict in ANY sense of the word.

You want strict? You need to upgrade the so-called "developers".

4
1
WTF?

It is mentioned but I'm going to bring it up again

Isn't this likely to be a security nightmare?

There's enough harm can be done with Javascript, which the guy seems to hold up as a paragon of secure computing, but starting a cat and mouse game with native code hackers seems like a really bad idea.

10
0

This is actually googles attempt at giving you a boot up browser based os. they needs native apps for this to be effective as no one can write a decent word processor or spreadsheet in javascript. They look good but can't really work well with big documents, insert charts, and manipulate on the fly all that lovely stuff we are so used to with excel.

They don't want to be another .net or java but they will attempt that old pony too.

Flogging a dead horse too. Or maybe its horseplay? Its all rather equine, I don't like this hoofing around at all. stick to search.

2
0
FAIL

At least in the Chrome beta you can turn it off. I'm not sure that will remain the order of the day in the future - just as once, JavaScript could be turned off without breaking most of the Internet.

As a web developer I really don't like this idea. Not because it puts my skills out (which it doesn't, I primarily program on the server side, not the client side) but because the so-called sandbox really isn't that secure.

2
0
Silver badge

::yawns::

I already have access to programming languages and interfaces that allow me to set up "world readable" Internet sites.

What's the point of this new kit?

Don't bother answering ... I already know. It's about marketing ...

2
2
Silver badge

Sorry, but quite long...

Good article, thank you.

There’s a whole lot of horse shit being spouted all over by the various people quoted in the article. For instance:

"While JavaScript is a fabulous language and it just keeps getting better, there is a lot of great software that isn't written in JavaScript, and there are a lot of software developers that are brilliant, but they would rather work in a different language,"

Entirely wrong. JavaScript is merely an adequate language for certain purposes. Programmers use other languages for sound technical reasons (performance, libraries, etc), not just because they’d rather not use JavaScript. If Brad Chen thinks that all programmers should somehow want to use JavaScript (or maybe some other single language) then he’s starting off on the wrong foot.

And just who is Linus Upson trying to kid:

"One of the key features of the web is that it's safe to click on any link. You can fetch code from some unknown server on the internet,"

So Google have never got stung by a dodgy web link then? There have never been holes in JavaScript interpreters have there?

"Before, when you downloaded a native application, you had to install it and you had to trust it. With Native Client, you can now download native code, just like you download JavaScript and run it, and it's every bit as safe."

That maybe true but they’re carefully chosen words. “Every bit as safe” doesn’t mean perfectly safe.

And how about this little gem:

"You've added this arithmetic to make sure the jumps are in range. But the real issue is that if it's really clever, a program will arrange for a jump to jump past that arithmetic," says Morrisett. "You might protect one jump but not the next one."

So Morrisett is saying that someone might just do a little manual hacking to insert op codes in order to achieve something nefarious? It depends on where the verification is performed. If it’s done on the client as the code is running, then this whole NaCl sandbox idea will fall to the oldest hacking trick in the book. And using x86’s segment registers is mad. In today’s world of virtualisation there are many fine instructions on x86 from Intel and AMD to make strong sandboxing realistic, yet Google are choosing to ignore all that in favour of an archaic monstrosity from the dark ages of computer architecture history?

And Google haven’t done an ARM version yet. Haven’t they seen the mobile revolution happening just down the corridor in the Android department, in Apple’s shack, at Microsoft and literally everywhere else? Not having an ARM version is soon going to look pretty stupid if it doesn’t look stupid already… And isn’t PNaCl just mimicking Microsoft’s .NET and Sun’s Java? Does the world really need another one?

“Chrome will only accept Native Client applications distributed through the Chrome Web Store, and Google will only allow Native Client apps into the store if they're available for both 32-bit x86 and 64-bit x86”

So NaCl won’t be the web then. Users won’t be able to click on any link out there in the Web and get a NaCl app because they’ll have to visit a Google run store? That sounds *very* inconsistent with what Linus Upson was saying earlier.

But hang on, Chris Blizzard is talking junk as well:

“Once you download the native code, there's no opportunity for browser optimizations.”

Err, isn’t that the whole point of native code? Isn’t it supposed to be fully optimised already, no room for improvement without a hardware upgrade? No amount of software re-jigging inside a browser is ever going to make a properly written decently compiled piece of native code run any quicker than it already does?

“A source code–based world means that we can optimize things that the user hasn't even thought of, and we can deliver that into their hands without you, the developer, doing anything.”

Hmmm. I wonder how many web site authors, plug in developers and the like have spent feverish hours in the middle of the night trying to fix a web site or plug in to cope with Mozilla changing something YET AGAIN. Hasn’t Blizzard heard about the debacle over Firefox version numbers? His statement is correct only if the ‘optimisations’ don’t effect the standard, but Mozilla (and everyone else I guess) hasn’t exactly agreed what the standard is nor kept to it:

"What are you going to do about version compatibility? What are you going to do about DLL hell?”

Indeed. What are you going to do about plug in hell?

And this is a real beauty:

“Chen and Upson also point to efforts like the Emscripten project, which seeks to convert LLVM bit code to JavaScript. Even if Native Client isn't available in other browsers, Upson says, this would allow all Native Client applications to span the web.”

So we’re going to write in C++. That’ll get compiled to LLVM. Ordinarily that would get executed in some sort of VM, just like .NET and Java, in which case I might have chosen to use C# or Java in the first place. But just in case that VM is missing, the LLVM will get re-compiled to JavaScript, which in turn will get interpreted to x86 op codes. IN THE NAME OF HOLY REASON HOW IS THAT SUPPOSED TO BE A GOOD IDEA? Sorry for the shouty shouty, and I’m not religious in anyway either, but sometimes things make me snap. It’s not April 1st is it? No, good; I thought I’d better check.

Right, enough of the rant. Web apps (Java, JavaScript, whatever) are Web apps. Native apps are native apps. They serve different purposes. NaCl is another Google effort to corner more on line advertising revenue by means of setting up another app store eco system that doesn’t actually deliver any tangible benefit to the end user. All this talk of ‘trust’ doesn’t matter two hoots. In both models you have to trust either the app developer or Google. Why is trusting the app developer worse than trusting Google? You could even argue that a Single Point of Trust is worse - just look at the problems we've had when a single CA (Diginotar) gets hacked.

Unless they pull their fingers out very quickly NaCl is going to wither and die as the consumer world transitions wholesale to ARM. This transition is likely going to be driven like we’ve never seen before by Microsoft bringing out Win8/ARM.

On the face of it Linux (well, Android), Apple’s and Microsoft’s propositions are far more sensible (though Oracle might do for Android yet in the law courts). Java and .NET do a decent enough job. Microsoft will also have to do a decent job of making the x86 / ARM choice a non-issue to native developers (and the word is that they’re doing quite well on that front). Apple has made it relatively simple for developers of native apps to target the whole Apple eco system.

Battery life is going to be king for many years to come, and NaCl looks like a very bad way of extending battery life to me, not least because it’s currently stuck in the land of x86. If Win8/ARM machines start issuing forth in large numbers and last whole days on a single charge, who’s going to want a power hungry x86 machine running anything, least of all Chrome and NaCl?

17
1

@bazza

Very good and insightful post. However, I do find one fault:

>>>>>>

Err, isn’t that the whole point of native code? Isn’t it supposed to be fully optimised already, no room for improvement without a hardware upgrade? No amount of software re-jigging inside a browser is ever going to make a properly written decently compiled piece of native code run any quicker than it already does?

<<<<<<

I believe that was exactly Blizzard's point, especially considering that not every single native application is a "properly written, decently compiled piece of native code."

-dZ.

2
0
Silver badge

@DZ-Jay

"Very good and insightful post."

Thank you very much :-)

>>>>

I believe that was exactly Blizzard's point, especially considering that not every single native application is a "properly written, decently compiled piece of native code."

<<<<

Well, maybe. Blizzard is right in that a piece of JavaScript can be run better by having a better interpreter as well as the developer actually improving the source code's own efficiency. But I suspect that Blizzard is being rather optimistic if he thinks that an interpreter can make JavaScript better than ordinary native code.

For example, imagine that they were to develop a Javascript engine that automatically spots opportunities for parallelisation in the source code. Fantastic!!! That can all be vectored up, maybe executed on a GPU if its big enough to warrant it, amazing!

However, all those tricks will also exist in the native application world too. Many already do (loop unrolling, etc. The native C/C++ compiler writers have been trying pretty hard over recent years, especially Intel). All you have to do is set the right comiler switches to tell it to do what it can, et voila, a faster application is produced. And ATI and Nvidia are trying very hard to make useful APIs (OpenCL and CUDA) available to developers to simplify the task of doing really big number crunching.

So there's nothing special about JavaScript that means that there are some magical optimisations that can automatically be applied that couldn't also be applied to C, C++ or indeed any other language. And if they are applied to a native application at compile time that's likely always to be better than suffering the overhead of an interpreter. Concievably one might run the interpreter in a separate thread on a different CPU core to get round this. But that is consuming a core's runtime which might otherwise be dedicated to executing application code.

Similarly I think Google are crazy if they think they can successfully and usefully abstract all the fancy high performance computing APIs that are currently available to native application developers. For instance, will they make NVidia's CUDA or ATI's OpenCL available as a standard part of the NaCl environment? If not then already they're way behind the curve. It will likely always be the case that as APIs for high performance come along (like CUDA and OpenCL) NaCl will always be playing catch up, won't be able to support them on all platforms, or will just not bother.

The only way to achieve better performance on given hardware than is achievable through compilers / interpreters spotting the obvious or off-loading this 'n' that to a GPU is to have explicit parallelisation in the original source code. This has traditionally been perceived as very difficult, so most people and indeed almost the entire computing industry has tried to avoid tackling this head on.

There is some progress though. SCALA (for those who've not heard of it that's a superset of Java) is a language that brings the old fashioned Communicating Sequential Processes paradigm from 1978 (!!!) back to life. This simplifies the business of developing applications that are inherently parallel. It takes a big shift in how one goes about designing a computer programme, but trust me it's worth it. This is (currently) a much better starting point than trying to get a compiler or interpreter to work it out for itself. Likewise OpenCL and the like are making it easier to exploit the mass parallelisation available in a GPU.

0
0
Headmaster

"Right, enough of the rant. Web apps (Java, JavaScript, whatever) are Web apps. Native apps are native apps. They serve different purposes. NaCl is another Google effort to corner more on line advertising revenue by means of setting up another app store eco system that doesn’t actually deliver any tangible benefit to the end user." -- Completely agree

NaCL distributes binaries, why bother, I can download a binary (.exe), install and run it.. my trust is in my virus scanner..

Java distribures web applications, these are self contained.. maybe a little slower than NaCL but browsers improve.

JavaScript is text, read and interpreted/compiled on the fly (if I'm wrong let me know but no flames needed)..

The comparisons are between NaCL and Java from what I can see, JavaScript is a herring rouge.

To be honest, I won't be using NaCL, it is another tool for Google to harvest data to enable them to "better serve" us advertisements.

To all Americans, it is "different from", an infinitive, never is it "different than" or "different to".....

0
2

A good idea

I am one of the only one who seems to think that native client is not only a good idea but something that is needed by the web?

What most seem to forget is that for a lot of things web apps have failed miserably.

- Gaming is one of them: why do web games look like some 2D thing out of the 90' ? Why can't I play battlefield 3 or Skyrim from my browser if my computer has the 3d hardware to do so? The only thing that currently looks like a decent "console quality games on the web" is OnLive and that's because all the processing happens on the server (and it needs a plugin anyway)!

- Video is only remotely good with the flash plug-in. Youtube exists for years now but the only way to get decent (meaning hardware accelerated) web video on desktop and mobiles is still flash with no useable standard in sight. and don't get me started with video editing in the browser.

- Mobile web apps are also a failure. Initially the iPhone was supposed to support only web apps, no app store. Have you seen how well that turned out: developers are fighting to get into the app store and the Android marketplace!

The fact is that current web apps and Javascript are OK for apps that mostly display data or do some limited data manipulation such as email, word processing or spreadsheet, but as soon as you want something more consistent there is not much. Where my web base GIMP (with all its filters and plugins)? where's my web based Audacity? Where is my web based premiere? where's my web base PowerDVD?

If you think current web technologies are good enough try to use a browser without plugins for a month to perform all you do with you computer (and that means watching DVDs and Blu-ray, video gaming, office work, watching video etc...) and tell me how you fare. End users expect web apps to deliver the same level of functionality and processing as native apps, can Javascript deliver that?

4
6
FAIL

"Where my web based <name any app you fancy>"

To which my only response is "Why would you want that ??"

3
1

A bad idea

>> What most seem to forget is that for a lot of things web apps have failed miserably.

What you seem to miss is that your comment completely undermines your point. Web apps *have* failed miserably in certain respect *precisely* because they are not part of the core strengths of the Web.

Your post starts acknowledging this and then rams into a wall of bad logic. It all starts with your definition of what the "Web" is. Just like Google, you seem to define "Web" as "Browser." It doesn't matter if it is portable, or consistent across platforms, or distributed, or completely open; as long as it executes within a browser it is "Web."

Right-o.

I'll tell you what, take the executable of Battlefield 3 and rename it "iexpore.exe," et voila! it's now "the Web."

-dZ.

2
1

"The only thing that currently looks like a decent "console quality games on the web" is OnLive and that's because all the processing happens on the server"

Personally I think this is the long-term future for graphics/cpu intensive applications. As internet connection speeds and latency improve over time "cloud gaming" would mean you no longer have to upgrade your hardware to play the latest games, install patches or buy a new console. And there's no need to run native code in the browser.

0
0
WTF?

.....

"One of the key features of the web is that it's safe to click on any link. You can fetch code from some unknown server on the internet,"

hahahahahahahahahahahahah

14
0
Silver badge

NaCl waste of time, PNaCl not a waste of time

NaCl uses processor hacks to enable a browser to execute native code within a sandbox. The theory being that the sandbox stops the code from doing anything it shouldn't. Even assuming the sandbox is secure, the fact that the code is processor dependent makes it a really dumb idea. People don't like having to write the same code for multiple architectures.

PNaCl on the other hand is a good idea. It uses LLVM to virtualize the environment so devs can build one app and in theory it will run anywhere. Also, because the instruction set is virtualized it means there less chance of the sandbox being exploitable, or if it is of fixing the issue.

Without or without PNaCl, people are already trying to produce native client code. LLVM bytecode can be turned into Javascript via Emscripten, and x86 emulators have even been written for JS. So we've see various C++ apps appear from Doom to even a Linux kernel all running in JS. But performance is all over the place. With PNaCl, Emscripten wouldn't be necessary and apps could benefit from near native execution speeds.

2
1
Facepalm

x86 emulators have even been written for JS.

Seriously?

Some people just have too much time on their hands.

0
0
Silver badge

Fabrice Bellard

He's the author of QEMU and he wrote a JS emulator for x86. You can even run Linux on it:

http://bellard.org/jslinux/

It's not working for me at the moment, don't know if its an issue with the site or my browser but I have played around with it and it's a little Linux dist and shell.

The obvious problem with JS is it's not memory mapped so everything has to be faked out in a clunky and non-optimal manner. The emulator uses typed arrays for example which are basically byte buffers to simulate memory.

0
0
Silver badge

@DrXym

>>>>

Even assuming the sandbox is secure, the fact that the code is processor dependent makes it a really dumb idea.

<<<<

Well, except that currently that's what you have to do to get ultimate performance. Until either x86 (eek!) or ARM or PowerPC or SPARC or MIPS (all much nicer) achieve a complete world wide instruction set monopoly we're stuck with that. And if ultimate performance isn't needed then you'd probably use Java, JavaScript, etc.

In effect Google are trying to provide a completely standardised API for native app developers on all platforms so that apps are write-once-compile-many-debug-once. History is shown that such things tend to fall to the lowest common denominator, which is a sure fire way of not being able to exploit the maximum potential of any given hardware platform which rather defeats the whole point. I wouldn't be surprised if they couldn't make that out perform a really well written .NET or Java (dare I say even Javascript? On second thought's, meh) virtual machine *and* keep it truly platform independent.

>>>>

With PNaCl, Emscripten wouldn't be necessary and apps could benefit from near native execution speeds"

<<<<

Yes, but PNaCl on top of LLVM gets away from the main thrust of NaCl which is to be purely native on the client. If PNaCl becomes their main effort then really they're just trying to compete with any other VM based cross platform ecosystem like .NET, Java, etc. Why bother doing that when they're years behind all of those?

0
0
Happy

Fabrice Bellard

Thanks. Yes, I already found it. I couldn't do much with it because it seems to require a US keyboard, but it's amusing. rm -rf / has the expected catastrophic effect on the Linux user account.

>> The obvious problem with JS is it's not memory mapped so...

You mean, apart from the more obvious problem that it's like building a Mercedes with a hamster running in a wheel as the power source?

1
0
Silver badge

Ultimate performance

"Well, except that currently that's what you have to do to get ultimate performance. Until either x86 (eek!) or ARM or PowerPC or SPARC or MIPS (all much nicer) achieve a complete world wide instruction set monopoly we're stuck with that. And if ultimate performance isn't needed then you'd probably use Java, JavaScript, etc."

Not really. They could generate native code from LLVM bitcode upon first invocation and cache it somewhere. Then it would run natively thereafter at native speeds. Or they could choose to execute LLVM bitcode through a JIT / interpretter. I assume they'd compile most of the time but on small devices they might prefer JIT.

The advantage is that developers write once and run anywhere, rather than pick and choose which architectures to support.

"Yes, but PNaCl on top of LLVM gets away from the main thrust of NaCl which is to be purely native on the client. "

I don't see why. As I said, LLVM bitcode can be compiled to native code. The performance impact from this is minimal. That's the whole point of LLVM. Benchmarks from gcc vs gcc-llvm / clang suggest the performance gap is quite small and closing.

0
0

Provide vector and matrix types in javascript

There really is something attractive in the speed-up from using just one or two machine operations to perform a single source code operation e.g. x = x + 1 (rather than many arising from interpreted steps).

But if one of the objectives of Native Client is to speed up vector and matrix operations, then why not add fundamental (i.e. native) vector and matrix types to javascript, in which case the interpreted overhead would occur only on the single expression involving vectors e.g. vec_a = vec_b + vec_c. The repeated underlying addition and indexing operations would occur at 'native' speed. If the vectors have more than 10 elements such code would excute at close to native speed.

1
0
Silver badge

@John Miles 1

Careful - you'll be turning JavaScript in to MatLab, and you reeeeeeeeeeeeeeeally don't want to do that it you want high performance!

Other languages have done just that. Motorola extended C (and hence C++) on PowerPC with new types like "vector float" and "vector int". If you wanted to add four floating point values to another set of four values then it is a simple operation along the lines of ans_vec = vec_add(vec1,vec2), guaranteed to complete in a single clock cycle. A very good way to easily get stunning performance out of quite slow clock rate PowerPCs (equivalent to a x4 on the clock rate if you were really good).

I think that deeeeeep down in the Intel C compilers there's a very similar idea hidden away from view but still accessible if you go looking. Intel seem much more focused on providing complete libraries of useful routines that hopefully mean you as the programmer doesn't have to get that low level. But the low level stuff is still there somewhere.

0
0
Def
Bronze badge
FAIL

Optional

All I see this as is a way for Google to try and address the failings of Chrome OS. And it's still doomed to fail. Google moves to x86 just as the rest of the sane world is moving away from it.

Implement a .net sand box and give people a more secure choice of languages to use. The world+dog is moving away from languages like C and C++ for a reason.

0
3
Anonymous Coward

Agreed - Chrome OS might be a pretty neat idea, but it can't play anything other than Flash games (although Flash 11 will have native 3D support).

If Google want to sell bucket loads of web-only PCs, then also being able to play proper games is important to them. It could then be more than a simple web and email only computer that seems a little pointless.

2
0
Silver badge

@Def

"The world+dog is moving away from languages like C and C++ for a reason."

Not entirely correct. Those who really want the ultimate in performance are using them in a big way. Many datacentre people are wondering if C/C++ are a better bet than PHP, etc. from the point of view of electricity bills. And a surprisingly large fraction of the HPC community are still using Fortran. Almost all OSes are in C / C++ one way or another. Big applications like database engines, CAD packages, CFD modellers, etc. are not written in Javascript.

0
0
Def
Bronze badge
Happy

Re: @Me

Sure, there are always going to be die hard fans of a language. And yes, there are more-niche-than-the-desktop markets that will do what they think they need to do. I'm sure I could find some people still writing COBOL if I really wanted to.

I remember 15-20 years ago, die hard performance junkies refusing to move to C++ because it was too slow compared to C. At the time they may have been right. Right now you still have a small performance hit moving to C++ from C, (and a big hit if you don't know what you're doing) but these days nobody really cares. C++ has effectively replaced C as the defacto choice of language in the majority of industries.

It's the same with the move from C++ to C#. Right now you lose a small percentage of performance rising to a large percentage if you don't fully understand the language or think you can design systems the same way you're used to with C++. In 10 years time, nobody's going to notice or care - C# will be in the position that C++ is in today.

Look at the direction Microsoft are heading with .net though. Windows phones don't run anything but .net. XNA, the indie game system, is currently .net based, and I wouldn't be surprised if the NextBox is .net only - most games will still be written in C++ but with the managed extensions that everybody hates. Windows has been slowly adopting .net more and more as it's primary platform for years and Windows 8 with its support for multiple architectures will justify the decisions made by some developers years ago to embrace .net. At some point in the not-too-distant future there will be a version of Windows with the kernel written entirely in a managed language (most probably C#) with native application support bolted on as a sand boxed virtual machine.

Whether you like it or not, it's the way things are heading. (I'm not sure I entirely like it at times, but I do know that the software industry as a whole needs to seriously look at how to produce more secure and more stable software - we are still in the stone age in that respect. .net is not going to move us into the 21st century in this respect, but it is a stepping stone in the right direction.)

And Google's native client is a huge step backwards.

0
0
Pint

Again... Great! A new way for malware to exploit our browsers!

If they can't sandbox Java, which is a BYTECODE interpreted language FFS, how the heck are they going to sandbox Intel machine code?

They aren't, obviously.

Just as this:

WebGL: Interwebs 3D tech emerges from puberty

http://www.theregister.co.uk/2011/03/03/webgl_one_dot_o_released/

Became this:

New graphics engine imperils users of Firefox and Chrome

http://www.theregister.co.uk/2011/05/11/chrome_firefox_security_threat/

This will become something bad too.

6
0
Gold badge

What's the point?

Technically, this is pointless. It will fail in the market, just like it did last time.

1) If you want to sandbox native code, use the facilities in your OS. I'm fed up with web browsers trying to re-invent security models and sandboxing techniques that were developed by OS designers in the 60s and that are implemented in every desktop OS that these browsers run on. You can run IE6 in the "Safer" sandbox provided by Windows and it is more secure than the latest version of your-browser-here running normally. The OS people are *much* better at this game than the Web people.

2) If you want an app that has the speed of native code and the connectivity of a web page, find a sockets library and implement the web bit on native code rather than the native code bit on the web. The latter is about as sane as that guy who wrote an x86 virtualisation engine in Javascript. Alan Turing would be completely proud, but you are still a dick.

3) If you want something portable, try shopping for a decent implementation of a language that has an ISO standard behind it, rather than settling for the sole implementation of a language where the owner bought the standard. I won't recommend one, because there are several languages out there with decades of practice, extensive supporting libraries and standards specified to a level of detail and precision that would make a Web 2.0 programmer's eyes water. If you can't handle the choice, find a new career.

So if standardised and fully portable languages for general purpose programming already exist, and the capability to sandbox them already exists, and if they have all the connectivity of the web already, why are Google (and others) constantly trying to re-invent the wheel?

My guess is that these projects are driven by people who enjoy programming but have rather less idea about marketing. Ironically, the problem with these languages is that they behave the same way on every platform and therefore fail to integrate really well with any of them. Given the choice, most commercial developers choose to use non-portable features (or languages) to produce a better product for a smaller market. As long as the academics and hobbyists fail to understand this point, we'll see a constant re-invention of this particular wheel.

Off topic, but an example of the same broken mind-set, application designers and technology evangelists should note that Real People also "don't want" the same application UI on their mobile phone (touch screen, just several inches across) as they do on a desktop device (mouse and keyboard, screen several feet across). They don't want that any more than they want their bodily appendages to be re-scaled by an order of magnitude.

10
1
Anonymous Coward

One correction...

"They don't want that any more than they want their bodily appendages to be re-scaled by an order of magnitude."

Some might to some of them. Just saying.

1
0
Gold badge
FAIL

".....just like you download JavaScript and run it, and it's every bit as safe."

Says it all really.

Any statement on security that uses the words "Javascript" and "safe" in the same sentance without a negative qualifier has an inherent flaw.

5
0
Ru
Paris Hilton

Hmm, sounds familiar.

Program in whatever high-level language you like, compile it to portable bytecode, have it run on a suitable interpreter written for a target architecture in a nice sandboxed environment. Add some open-source, standards-enthusing whitewash to complete the picture.

You could do that with silverlight, if you wanted.

That's been an absolute runaway success for Microsoft, hasn't it?

Frankly, I'm more interested in their ability to support sandboxing of actual native applications in general; that sounds like a massively useful feature for any OS.

2
0

I'm confused, wasn't this invented years ago by Sun and called "Java"? Or have I missed something?

2
0

yes you are confused

Java is not a "native" client. Java programs are turned into a single "byte code" used on every platform.

1
1

Erm...

Which is exactly what Google are planning to do eventually according to this article!

0
0
Silver badge

@Thomas Wolf

Almost right.

A lot of ARM devices implement Jazelle, which is ARM's Java byte code execution engine alongside the ARM instruction set. In essence you can execute Java byte code natively alongside ARM instructions. There's an ARM op code that says that the next instruction to load from memory will actually be Java byte code; it's as seamless as that.

All of a sudden Java doesn't seem so stupid in the mobile platform, does it? Though I don't know if any of the the Java ME environments out there or Android's Dalvik use it.

1
0
Silver badge
Unhappy

@Thomas Wolf, encore

I've done a bit more digging.

Jazelle exists, but isn't widely used. Japanese phones seem to use it a fair bit, but that would appear to be that. Seems a shame. I tried to find out whether Blackberries use it with no success. Given their pretty good battery life, perhaps they do.

Hardware acceleration has made everything else on ARM pretty good - video/audio codecs, GPUs with adequate grunt, etc. etc. So why not Java?

If the chip manufacturers (TI/OMAP, Qualcomm/Snapdragone, etc) don't put it on then no one can use it. And given that a large fraction of the mobile market (Android & iOS) don't support Java anyway, why bother to put down silicon that's not going to be used?

Seems a shame - hardware accelerated Java could provide a really nice solution to the problem of write once run anywhere in the mobile space, but I guess there's too many vested interests to prevent it ever taking off. There's Apple with the iTunes store and Google with the Android store for a start; and neither of those parties want to open up their platforms to apps from just anywhere...

1
0
Silver badge
Childcatcher

What are you canabalising?

It depends what ends up happening...

If you end up moving desktop apps (which otherwise wouldn't move) to the browser then that's nice - a far better distribution model than currently exists.

If you end up moving what could be a web app to compiled C++ in NaCl then you're going the wrong way.

You might reduce the impetus to move to pure web apps, but then, that might not happen anyway.

Personally, I'd love to see LibreOffice in NaCl because it would be a great way to roll it out and I

don't think we'd see it performing well if it was re-written in pure JS. Of course, a pure web version would be great but I don't think we have the cpu horsepower for it yet.

I'd see NaCl as another architecture, not really a replacement for the true web. Currently we have x86 windows apps, x86 linux apps so there's no reason not to have x86 NaCl apps.

As for Pinnacle, I think a bit of competition for Java from a company slightly less evil than Oracle would be a good thing.

1
1

Unity and Flash 11 Molehill

"Unity Technologies has long offered a plug-in for running 3D games in the browser at its Unity platform, but the San Francisco-based outfit is now porting the game platform to run as a Native Client application. This means that developers can deliver their Unity-based games to Chrome without asking the user to install the plug-in – and at the same time, they can take advantage of the Native Client sandbox."

Unity are also looking into porting their engine to Adobe Flash 11 molehill technology (with its 3D hardware acceleration):

http://blogs.unity3d.com/2011/02/27/unity-flash-3d-on-the-web/

1
0
FAIL

"Native Client democratizes web technology"

I stopped reading at this point...

4
0
Bronze badge
Devil

What are you - a commie? If you don't love NaCL the Russians will win!

1
1
Stop

Facepalm quotes galore

"...the same excellent level of portability and safety that JavaScript provides on the web today..."

Clearly, Mr.Chen has never written JS for more than one browser and has presumably not read any of the numerous articles about JS based exploits.

"One of the key features of the web is that it's safe to click on any link..."

Meanwhile, Mr.Upson is apparently talking about a different 'web' on some planet other than Earth.

"Before, when you downloaded a native application, you had to install it and you had to trust it"

How would providing a sandbox at the OS level be any better or worse than providing a sandbox built into the browser? Are Google completely unaware of all the code signing and sandbox technology that's been going into the mainstream operating systems for the last few years?

So this isn't about safety...

"Native Client doesn't add any new capabilities that aren't actually in JavaScript and HTML5. It just makes them available to C and C++ programmers"

...it's about providing the legendary ease of development, easy of debugging and stability of C and C++ combined with the legendary reliability and security of the cross-platform seamless environment that is the web browser. After all, HTML and CSS are just *the* best thing in the word for making application-like user interfaces, yes?

Good grief.

Just a handful of quotes in the article have managed to give me stronger reasons to avoid Native Client than any number of comp.risks digests might have done! :-)

8
0
Thumb Up

Not the worst idea

I don't like the idea of distributing native code directly with NaCl, but using LLVM is a good idea since it doesn't lock the web to a set of supported ISAs (at worst you need to implement a new backend code generator for LLVM). It's like Java bytecode, but better since you can use a much wider range of languages.

JavaScript has been stretched way beyond what it should have and it's time for real programming languages to pick up the slack. Many design flaws of JS make it very hard/impossible to optimize it like you can other languages (despite the heroic efforts of V8, TraceMonkey, etc.), so it makes a very poor choice as the "assembly language of the web".

2
0

Page:

This topic is closed for new posts.