Live data from Hacker News

Mozilla’s Rejection of NativeClient Hurts the Open Web

chadaustin.me

11–20 of 106 posts

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

#11
post #9

Earlier quoted context omitted.

> 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 don't worry about NaCI itself, I worry about someone who's too stupid to implement it correctly. And those people are everywhere, especially in big companies. i.e. Nintendo, broken (self built!) RSA in the Wii or even better Sony, using the same "random" number for all their crypto on the PS3... yes FX and Chrome are Open Source, but MS and Opera are not. Anyways, I'd rather spent a lot of time improving the JITs i…

You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though.

Personally, I'm a huge fan of the everything-managed approach (hell, I started a pure-managed OS project for a reason), but I don't think that's a reason to avoid NaCl.

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

#12
post #11

Earlier quoted context omitted.

I don't worry about NaCI itself, I worry about someone who's too stupid to implement it correctly. And those people are everywhere, especially in big companies. i.e. Nintendo, broken (self built!) RSA in the Wii or even better Sony, using the same "random" number for all their crypto on the PS3... yes FX and Chrome are Open Source, but MS and Opera are not. Anyways, I'd rather spent a lot of time improving the JITs i…

You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though. Personally, I'…

Most standards bodies require at least two independent implementations of a specification before labelling it a standard.

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

#13
I disagree with the article's sentiment. I'm glad the web is focusing on Javascript. Here's why: the web is a nice, text-based environment that is safe to execute on your computer. Each web resource may contain active scripts but they are pretty innocuous.

Native applications are binary and can do all sorts of nasty things. Sure, this sandbox is supposed to be safe, but what if it's not? When an application is delivered over the web, one should really make sure that it wasn't somehow changed or sabotaged. Right now this is impossible. At the very least, this proposal would have to be implemented so we can trust what is being downloaded: http://news.ycombinator.com/item?id=2024164

Here is what I suggest: native libraries should expose their objects to javascript, which should do the majority of the work. Kind of like PhoneGap does on the phones. These native libraries (like OpenGL, say), should be served from cdns over httpc:// and the user agent can verify that they are safe after downloading them.

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

#14

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…

Forget all this crap... if you need to remote out the UI part of some complicated app, just write a Java front-end and deploy it using JNLP. Let web-browsers remain good at what they're good at, and what they were meant for: Browsing the web. Web browsers make great hypermedia navigation / browsing tools... but they're really not so great at being the universal standard remote client interface for complex application…

Yeah, that whole applications on the web thing is totally just a fad. I'll right get on rewriting Google Maps using a Java front-end.

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

#15
post #11

Earlier quoted context omitted.

You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though. Personally, I'…

Most standards bodies require at least two independent implementations of a specification before labelling it a standard.

Apparently ISO is not one of them, OOXML required zero implementations

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

#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 have such master-record. You will see this pattern repeat itself; the chaotic nature of the web beats any attempts to impose "order" upon it. Cf. the dismal failure of dmoz and other curated directories, compared to search engines.

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

I doubt the app-store model will survive long term; individual merchants and vendors tend to move faster than the infrastructure that houses their shops and supports their business (almost literally.) The moment a few merchants diverge from the proscribed machinery of the market, and exploit inefficiencies, as they will, is the moment you will see this model come apart at the seams. If the entire model isn't killed along with its platform by changes in technology.

The one good example I can give you is the buildings built throughout South East Asia to house street-vendors. Specially in Cambodia and Vietnam, the governments built multi-story shopping centers, just piles of concrete, and invited vendors to push their carts in and congregate. The markets might have looked like proper malls at some point, but with time, they're just shaded bazaars like any other street market, except this one isn't dried by the sun and there is no drainage. Over time, the building has all the appeal of a street market, except you have to climb up some slippery stairs tightly packed with pickpockets. However, most higher-end merchants gather around the vertical-bazaars and open proper walk-in shops with more products, better presentation, and all the amenities of a private property (fan, seats, water cooler, bathroom, TV/radio, etc.)

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

#17
post #14

Earlier quoted context omitted.

Forget all this crap... if you need to remote out the UI part of some complicated app, just write a Java front-end and deploy it using JNLP. Let web-browsers remain good at what they're good at, and what they were meant for: Browsing the web. Web browsers make great hypermedia navigation / browsing tools... but they're really not so great at being the universal standard remote client interface for complex application…

Yeah, that whole applications on the web thing is totally just a fad. I'll right get on rewriting Google Maps using a Java front-end.

I don't think Google Maps does any heavy lifting and number-crunching in javascript in the browser; in fact, all it does in js is "remote out the UI part".

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

#19

Earlier quoted context omitted.

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'…

> like the ones I listed (games, simulations, video, DSP). Those should not run in a Browser, they should on a real OS (or Emacs). What's next VMWare inside your Browser? Then it's OS -> Browser -> VM -> OS -> Browser... Sorry but just because things are possible, doesn't mean that they should be done...

but you can't just right-click on a binary executable and "view soure", bro! ~

Seriously, people managed to write successful, cross-platform software without expecting everyone with any kind of gadget or device to run it with one click.

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

#20
●---------------------------------------● Happy New Year◎,◎appy shopping ●---------------------------------------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●---------------------------------------● Happy New Year◎,◎appy shopping ●---------------------------------------●
Post reply on HN