Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla’s Rejection of NativeClient Hurts the Open Web

chadaustin.me

Post reply on HN
Print view View original

31–40 of 106 posts

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#31

Post by sid0 »

1337p337 wrote: post #23
mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

FYI, Firefox extensions can contain native code. Of course, you need to include a binary for every OS/arch/Mozilla version triple you wish to support.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#32

Post by sfvisser »

mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

> "If you want to use performance critical software that pushes the limits of your machine, download it, use Java or whatever."

This is a bit too simple. The web is becoming a platform for rich interactive applications more and more. Nowadays we can use tons of applications without downloading and installing any software. Most people would agree this is a good thing.

However, the web as a platform is inherently broken. Engineering large scale web applications with the sheer combination of HTML, CSS and JavaScript is just a pain in the ass. Every level of abstraction you introduce is pushing the limits of the browser already. Having a sandboxed machine code interpreter would allow developers to spend their time on developing software using their own favorite abstractions. This can save time and frustration.

Maybe NaCl or even some bytecode alternative have their disadvantages, but they solve a very annoying problem for sure.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#33

Post by othermaciej »

junkbit wrote: post #28
1337p337 wrote: post #23

Earlier quoted context omitted.

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

NaCl works on both ARM and x86 using the same downloadable bytecode. The long term goal seems to be to translate the bytecode in the client using a sandboxed LLVM to target the local architecture See the following video from the recent LLVM Developers' Meeting Portable Native Client, David Sehr, Google [mp4,269mb] http://www.llvm.org/devmtg/2010-11/videos/Sehr_NativeClient-...

As I understand it, if you use Native Client now, you get an architecture-specific binary. The LLVM bitcode based portable version is still a work in progress. So it's more accurate to say "long term goal" than "works".

The problems with Native Client go beyond its currently x86-specific nature though. The Web is based on open standards, and a requirement for most standards is having multiple independent implementations. Native Client is a complicated enough technology that it might be completely impractical to spec it in sufficient detail and independently reimplement.

You might think this is only a technical issue of standards process, but a standard with only one implementation ends up de facto controlled by a single entity, even if the implementation happens to be open source. In practice, you'll get support for the platforms and CPU architectures that Google cares about, in their priority order. You can see how that might not be so appealing for an entity that doesn't want Google to be setting the agenda quite that much.

In addition to this, the security architecture of the whole thing seems pretty dubious. It does have a better attempt at security design than ActiveX. But given the basic approach (binary-level validation of binary code), it has a lot of attack surface.

All that being said, it's a neat project with a lot of hack value. It just doesn't seem like a great fit for the Web. It is likely more driven by Chrome OS at this point.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#34

Post by sid0 »

mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

I doubt the app-store model will survive long term

In general, yes, but there's a good chance more niche stores like Steam will survive for a fairly long while.

* Compared to e.g. either of the Apple app stores, Steam is a very open platform: there are very few demands imposed on the publisher, and developers can release updates whenever they wish, for example. The only other platform where the sort of iterative development Steam can provide is possible is the Web.

* It provides a tremendous value-add: infinite game downloads, automated patching and save file syncing in the cloud. Of course, none of these are issues with a Web-based game, but at least some of the stuff available on Steam isn't going to be possible in the browser any time soon.

* Games are generally much less fungible than the average application, Valve's own games even more so.

* Valve's earned the trust of most PC gamers, including mine. It's probably (percentage wise) the most trusted app store vendor currently in business.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#35

Post by cdavid »

chadaustin wrote: post #6
DjDarkman wrote: post #3

It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…

Hi, original author here, Responding to your bytecode argument, modern JavaScript JITs are already compiling JavaScript to machine code. That means JavaScript is becoming the de facto bytecode of the web. Then the argument becomes "what's the most appealing bytecode for the web?" I'd argue that SWF isn't (closed), Java isn't (for the same memory layout and language translation issues I discussed), and JavaScript isn'…

While you're right that memory is the bottleneck in many CPU intensive programs, the idea that you need low level access to circumvent it is far from obvious. For example, several well known people have argued that C makes it more difficult to use memory effectively, because pointers make compiler job so difficult (Fortran still beats C for most numerical benchmarks).

I think we are at a point where architectures are so different that even though in theory, controlling memory pattern is potentially more powerful, in practice, it is impossible to do it right except when you can spend insane amount of time on it. The difference between P4 and core duo, for example, is enormous as far as organizing memory accesses. This is exactly like ASM vs C: you can still beat C with ASM, but doing so across all architectures is almost impossible to do it by hand.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#36

Post by mfukar »

1337p337 wrote: post #23
mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

While you make fair points that I mostly agree with, I have a tiny nitpick: Lua isn't really a simpler Javascript; although I understand the point you were trying to make so I won't argue over it. :-)

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#37

Post by megaman821 »

People are going to want to target their C, Java, Python, etc. code to the browser. The only question is what is the better target, Javascript as a VM or a sandboxed LLVM?

Honestly the inclusion of NaCl wouldn't change that much. JavaScript would still be the easiest path for most developers to choose. It will be only language that the browser hosts the interpreter and has no compilation step.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#38

Post by mfukar »

daeken wrote: post #9
BonsaiDen wrote: post #5

Earlier quoted context omitted.

> The author fails to point out why would anyone want low level memory access. To get out of the sandbox and wreak havoc? No really, NativeClient is the __last__ thing the Web needs. In the end people will either port their old, bug ridden and insecure C++ code to that thing or they will write new platform dependent code... or both at the same time. That's completely against the OpenWeb.

> To get out of the sandbox and wreak havoc? NaCl, on the whole, is sound. There have only been a few attacks against it, and those were largely during the "come own us" phase. I'm sure there will be further attacks against it, but that is the last issue in play here. Cross-platform and existing standards compatibility are by far the more important ones, not to mention the benefits of code you can optimize as you see…

I'm sure there will be further attacks against it, but that is the last issue in play here.

I'm sure this attitude will survive for many years to come, although it really shouldn't.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#39

Post by [deleted] »

pedrocr wrote: post #29

The only way I can see PNaCl catching on is if Google deploys it in Chrome and the Android Browser and creates an automatic fallback to a javascript PNaCl interpreter for the browsers that don't have it. Then it becomes about "why is Firefox/IE/iOS slower at running this webapp?" But even then you'd need Google or someone else to deploy some interesting PNaCl apps to make having it worthwhile. It's a pity that this i…

[deleted]

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#40

Post by BonsaiDen »

pedrocr wrote: post #29

The only way I can see PNaCl catching on is if Google deploys it in Chrome and the Android Browser and creates an automatic fallback to a javascript PNaCl interpreter for the browsers that don't have it. Then it becomes about "why is Firefox/IE/iOS slower at running this webapp?" But even then you'd need Google or someone else to deploy some interesting PNaCl apps to make having it worthwhile. It's a pity that this i…

Well JS is very dynamic, people have for a long time focused on the optimization of static typed compiled languages. The JVM did awesome things in the area of JITs, V8 Crankshaft is already pushing the limits once again, up to 3x gains over the current version in the Browser. There's still a lot of potential in optimizing a language like JavaScript, but Rome wasn't built over night, give JS some more time.
Post reply on HN