April 24, 2010
Sat, 24 Apr 2010 16:29:55 -0400, Adam D. Ruppe wrote:

> On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:
>> Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.
> 
> ActiveX controls don't run as a limited user account. That's the key here: the entire browser should be running as a restricted user, and it creates processes even more restricted than itself.

How does this prevent platform lockdown?

> (When Google did this in Chrome, it was hailed as brilliant and
> innovative.
>  I saw it as them finally doing what they should have been doing from
>  the beginning.)

I haven't really seen the native client system used in any crucial real world site.

> 
>> 99% of web pages will offer just the win32 version.
> 
> Meh, works for 91% of users.

So, what technologies should the minority use then? Nothing? You're suggesting a cross-platform solution but you don't even believe yourself that it really should be cross-platform. That's pretty dishonest.
April 24, 2010
On Sat, Apr 24, 2010 at 08:32:25PM +0000, retard wrote:
> A middleware is about building the infrastructure. Later (ideally) there are no platform specific costs involved.

We have that already. I write programs for Linux and release them on Windows by expending no effort beyond typing "make windows".

> The web 2.0 apps were built because people got tired of Microsoft monoculture. Web 2.0 is a crappy technology, but we haven't got anything better.

Web 2.0 emerged due to two things:

a) Developers are grossly incompetent. They are too damn stupid to
   even recognize a correct solution when they see it, much less to
   use one.

b) Ease of deployment. The existing web platform could be used to
   distribute applications without expending much effort.

c) Centralized control.

Being tired of Microsoft has nothing whatsoever to do with it.


-- 
Adam D. Ruppe
http://arsdnet.net
April 24, 2010
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.71.1272140482.3522.digitalmars-d@puremagic.com...
> On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:
>> Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.
>
> ActiveX controls don't run as a limited user account. That's the key here: the entire browser should be running as a restricted user, and it creates processes even more restricted than itself.
>
> (When Google did this in Chrome, it was hailed as brilliant and
> innovative.
> I saw it as them finally doing what they should have been doing from the
> beginning.)
>

I remember reading an online comic explaining all of Chrome's wonderous advances and thinking much the same thing.

>> 99% of web pages will offer just the win32 version.
>
> Meh, works for 91% of users.

Maybe I'm just naive about this, but it would seem to me that it should be possible to have a single compiled-native-code format that could be "framed" by the client to work on the whatever the client's OS is. I mean, x86 is x86 regardless of OS. Of course, that still leaves a need for a CPU architecture request header, and 99% of sites would ignore anything but x86, but it'd be an improvement over needing both CPU and OS.

Also, a web server could be set up to automatically convert or cross-compile to whatever CPU or OS was requested by the client (and then internally cached, of course). Probably involving LLVM or something. Having standard plugins like that even for just for Apache and IIS would fix the issue for 99% of sites and 99% of users. And there could certainly still be fallbacks for the oddball servers and clients.

Plus, there's still other VM-bytecode possiblities besides just JVM. There's LLVM. Or you could transmit a standardized precompiled JS bytecode (even though JS may be quick to parse, I've still thought it was a bit silly to have the clients do the JS compilation since 99% of it is all the same code being sent out to all the different clients). Etc.

-------------------------------
Not sent from an iPhone.


April 24, 2010
On Apr 24, 10 18:04, Justin Johansson wrote:
> KennyTM~ wrote:
>> On Apr 22, 10 14:52, Lutger wrote:
>>> I don't think javascript is suited for this purpose, but perhaps
>>> silverlight
>>> / moonlight is. A D compiler targetting the CoreCLR could be big,
>>> depending
>>> on how this platform takes off.
>>
>> D.NET?
>
> D.NET (D.CLR), D.JVM, D.ECMAScript, anything except D.assembler would
> have a lot of market appeal. I would hesitate at D.LLVM though as that's
> not where the "money" is, sadly (imho).
>
> Thanks everybody for commenting; this thread could have some really good
> suggestions/outcomes if only these could be put into effect.
>
> Justin Johansson

Er, I mean D.NET (http://dnet.codeplex.com/).
April 24, 2010
On Sat, Apr 24, 2010 at 08:41:07PM +0000, retard wrote:
> How does this prevent platform lockdown?

It doesn't. I don't particularly care.

> I haven't really seen the native client system used in any crucial real world site.

I'm referring to how they run browser components all as separate processes with restricted tokens to improve stability and security, not the native client, which I find completely useless.

> So, what technologies should the minority use then? Nothing? You're suggesting a cross-platform solution but you don't even believe yourself that it really should be cross-platform. That's pretty dishonest.

The websites that want to cater to them can offer alternative methods, and/or gracefully degrade.

The websites that don't care about them lose out on that market opportunity.

Web 2.0 works like this now, but instead of operating systems, it is browsers. If you don't use IE7+ or Firefox (which require two separate code paths in a number of cases), you're pretty much on your own. Nobody cares when their website doesn't work in Lynx.
April 24, 2010
On Sat, Apr 24, 2010 at 04:54:17PM -0400, Nick Sabalausky wrote:
> Maybe I'm just naive about this, but it would seem to me that it should be possible to have a single compiled-native-code format that could be "framed" by the client to work on the whatever the client's OS is.

It probably could be done, especially if all calls were done through a dynamically linked interface.

But it seems simpler to just recompile the source for the other platforms.

> Also, a web server could be set up to automatically convert or cross-compile to whatever CPU or OS was requested by the client (and then internally cached, of course).

Yes, this should work excellently. The cross-platform aspect is the easiest thing to solve to me.

> I've still thought it was a bit silly to have the clients do the JS compilation since 99% of it is all the same code being sent out to all the different clients). Etc.

The biggest problem there is each browser would surely insist on having their own separate bytecode.

April 24, 2010
Nick Sabalausky:

> Also, a web server could be set up to automatically convert or cross-compile to whatever CPU or OS was requested by the client (and then internally cached, of course). Probably involving LLVM or something.

It's called pNaCl (PDF file):
http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

Bye,
bearophile
April 24, 2010
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.72.1272141444.3522.digitalmars-d@puremagic.com...
> On Sat, Apr 24, 2010 at 04:26:55PM -0400, bearophile wrote:
>> I keep posting this link here, and it keeps being ignored, despite I think it can become one important usage of D: http://code.google.com/p/nativeclient/
>
> It is absolutely useless; it has no market penetration and since it forces
> you
> to use their tool chain the whole way, it will never get any.
>
> Any time spent getting D to run on it would be a complete waste of time. At least compiling to javascript would have a potential user base.
>

"it forces you to use their tool chain the whole way"

Can you elaborate on that or post links?

-------------------------------
Not sent from an iPhone.


April 24, 2010
On 4/24/2010 14:29, Adam D. Ruppe wrote:
> On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:
>> Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.
> 
> ActiveX controls don't run as a limited user account. That's the key here: the entire browser should be running as a restricted user, and it creates processes even more restricted than itself.

Running the browser as a restricted user is good (and indeed necessary), but when you're running native code, you're only as secure your OS and CPU allow.  Running on a VM provides an additional layer of insulation.

I like native code, but only for applications that I choose to install.


-- 
Rainer Deyke - rainerd@eldwood.com
April 24, 2010
On Sat, Apr 24, 2010 at 06:17:25PM -0400, Nick Sabalausky wrote:
> "it forces you to use their tool chain the whole way"

Check out the README:

http://nativeclient.googlecode.com/svn/trunk/src/native_client/README.html

Notice how the instructions don't say to use gcc and gdb, but instead nacl-gcc and nacl-gdb. The downloads say "source and toolchain".

Wikipedia says that it is simply because the code have 32 byte alignment:

http://en.wikipedia.org/wiki/Google_Native_Client

(second paragraph) but nevertheless, an out of the box compiler isn't going
to work for it.


Then, once the code is written, you can't execute it without the Google browser plugin, integrated with Chrome and offered for Firefox, but not available for Internet Explorer. Maybe they'll offer one once it goes live, but I wouldn't count on it. Even so, odds are good that users won't have it installed anyway.