View mode: basic / threaded / horizontal-split · Log in · Help
April 24, 2010
Re: JavaScript is the "VM" to target for D
Fri, 23 Apr 2010 23:26:18 -0400, Nick Sabalausky wrote:

> And even if
> you really did need client-scripting (and the vast majority of the time,
> you don't), there are better ways to distribute cross-platform code
> across a network.

Really, such as? The largest problem by far has been to increase the 
global user base of these better technologies. The most widely used side 
virtual machines are for Flash and Javascript. Java had a good position, 
but now its dying away (on the client side). Silverlight has patent 
issues. What else do we have? You can't just run python or ruby in a 
windows box -- it doesn't have any runtime support.
April 24, 2010
Re: JavaScript is the "VM" to target for D
On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:
> What else do we have?

If I had my way, I'd just be rid of the virtual machine altogether. Simply run
native programs as a restricted user. (Indeed, I'd run the browser itself
with that restricted user, then let it create whatever processes it
wants, possibly stripping the child processes of more privileges.) The
operating system keeps it from doing anything evil.

We could define a new header in the HTTP request that lists the kind
of code you'd accept, from highest priority to lowest. For example, a
linux box with Wine might say:

X-Accept-Code: linux64; linux; win32

Meaning it'd prefer 64 bit linux apps, but if you don't offer that, it'll
settle for a generic 32 bit linux binary, or a Windows one if that fails.
The application is responsible for getting its own dependencies resolved -
if a dll load fails, download it from your site automatically.

A statically built standard library could simplify this for the programmer.


This gives the programmers huge freedom by taking the code
execution out of the browser's hands. Want to use a different language? Just
compile it, or bundle an interpreter for it. The accept-code header could
list various VMs the system has installed too.


If the browser didn't send the accept-code header, you have two options:
offer the binary as a download in a link or fallback on javascript. The
only problem with the former is users without the right security setup
probably shouldn't get used to approving binary downloads.


But, fixing the browser's create process powers are the direction I'd take
instead of adding more and more to their javascript interpreters. If they
can create the appropriately restricted token (which they should be running
under themselves anyway!), you're in business.

Seems like a lot less work than what they've put in the javascript, and
gives a lot more flexibility.

-- 
Adam D. Ruppe
http://arsdnet.net
April 24, 2010
Re: JavaScript is the "VM" to target for D
Sat, 24 Apr 2010 11:27:27 -0400, Adam D. Ruppe wrote:

> On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:
>> What else do we have?
> 
> If I had my way, I'd just be rid of the virtual machine altogether.
> Simply run native programs as a restricted user. (Indeed, I'd run the
> browser itself with that restricted user, then let it create whatever
> processes it wants, possibly stripping the child processes of more
> privileges.) The operating system keeps it from doing anything evil.
> 
> We could define a new header in the HTTP request that lists the kind of
> code you'd accept, from highest priority to lowest. For example, a linux
> box with Wine might say:
> 
> X-Accept-Code: linux64; linux; win32
> 
> Meaning it'd prefer 64 bit linux apps, but if you don't offer that,
> it'll settle for a generic 32 bit linux binary, or a Windows one if that
> fails. The application is responsible for getting its own dependencies
> resolved - if a dll load fails, download it from your site
> automatically.
> 
> A statically built standard library could simplify this for the
> programmer.
> 
> 
> This gives the programmers huge freedom by taking the code execution out
> of the browser's hands. Want to use a different language? Just compile
> it, or bundle an interpreter for it. The accept-code header could list
> various VMs the system has installed too.
> 
> 
> If the browser didn't send the accept-code header, you have two options:
> offer the binary as a download in a link or fallback on javascript. The
> only problem with the former is users without the right security setup
> probably shouldn't get used to approving binary downloads.
> 
> 
> But, fixing the browser's create process powers are the direction I'd
> take instead of adding more and more to their javascript interpreters.
> If they can create the appropriately restricted token (which they should
> be running under themselves anyway!), you're in business.
> 
> Seems like a lot less work than what they've put in the javascript, and
> gives a lot more flexibility.

It gives different kinds of flexibility. The advantage of Javascript is 
easy interfacing with the DOM, the html document and all kinds of powers 
the browser is providing. The hypertext widget is actually pretty good at 
modelling user interfaces even though it's not optimal by modern 
standards.

The web applications have many contradicting goals and as a systems 
programmer you only have a narrow view which is from the pov of the 
traditional local applications. It's true that you can restrict 
privileges on operating system level. However, there is no cross-platform 
way of controlling this system manually on a proper abstraction level. If 
you fail to see the advantages of a middleware layer, you need to think 
more about it.
April 24, 2010
Re: JavaScript is the "VM" to target for D
On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:
> It gives different kinds of flexibility. The advantage of Javascript is 
> easy interfacing with the DOM, the html document and all kinds of powers 
> the browser is providing.

Yeah, this came to mind only after I made the last post. The best solution
would probably be exposing the DOM objects to the child process somehow,
probably in a process similar to how browser plug-ins work.

Dynamically linking the DOM API to the application and passing opaque
pointers to and from it should do the trick, while insulating the downloaded
code from different browser implementations. Hopefully.

An alternative is interpreting Javascript through a pipe to manipulate
the webpage, but then the native code is kinda pointless.

> However, there is no cross-platform 
> way of controlling this system manually on a proper abstraction level. 

I don't know what you mean here... for security, there are no controls
on Javascript, you just get what the browser offers you and nothing more.
An OS level security restriction would be the same thing.
April 24, 2010
Re: JavaScript is the "VM" to target for D
Sat, 24 Apr 2010 14:06:19 -0400, Adam D. Ruppe wrote:

> On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:
>> It gives different kinds of flexibility. The advantage of Javascript is
>> easy interfacing with the DOM, the html document and all kinds of
>> powers the browser is providing.
> 
> Yeah, this came to mind only after I made the last post. The best
> solution would probably be exposing the DOM objects to the child process
> somehow, probably in a process similar to how browser plug-ins work.

The problem is, the most common object code interfaces on top of the OS 
have been optimized for C/C++ and that won't change anytime soon. The 
layer isn't really language agnostic. If favors C/C++ compatible 
languages.

>> However, there is no cross-platform
>> way of controlling this system manually on a proper abstraction level.
> 
> I don't know what you mean here... for security, there are no controls
> on Javascript, you just get what the browser offers you and nothing
> more. An OS level security restriction would be the same thing.

The Javascript world is a bit naive today, but the middleware layer will 
likely become more complex later. You can see some security features in 
most browser plugins. Javascript will eventually replace these.
April 24, 2010
Re: JavaScript is the "VM" to target for D
On 4/24/2010 09:27, Adam D. Ruppe wrote:
> If I had my way, I'd just be rid of the virtual machine altogether. Simply run
> native programs as a restricted user. (Indeed, I'd run the browser itself
> with that restricted user, then let it create whatever processes it
> wants, possibly stripping the child processes of more privileges.) The
> operating system keeps it from doing anything evil.

Congratulations, you just invented ActiveX.  I hope you like your
platform lockdown and your security vulnerabilities.

> X-Accept-Code: linux64; linux; win32

99% of web pages will offer just the win32 version.


-- 
Rainer Deyke - rainerd@eldwood.com
April 24, 2010
Re: JavaScript is the "VM" to target for D
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.)

> 99% of web pages will offer just the win32 version.

Meh, works for 91% of users.
April 24, 2010
Re: JavaScript is the "VM" to target for D
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/

Bye,
bearophile
April 24, 2010
Re: JavaScript is the "VM" to target for D
Sat, 24 Apr 2010 13:53:10 -0600, Rainer Deyke wrote:

> On 4/24/2010 09:27, Adam D. Ruppe wrote:
>> If I had my way, I'd just be rid of the virtual machine altogether.
>> Simply run native programs as a restricted user. (Indeed, I'd run the
>> browser itself with that restricted user, then let it create whatever
>> processes it wants, possibly stripping the child processes of more
>> privileges.) The operating system keeps it from doing anything evil.
> 
> Congratulations, you just invented ActiveX.  I hope you like your
> platform lockdown and your security vulnerabilities.
> 
>> X-Accept-Code: linux64; linux; win32
> 
> 99% of web pages will offer just the win32 version.

Indeed, it's hard to believe that a "web 3.0" application vendor would 
suddenly support several platforms after 25+ years of Microsoft 
dominance. The second platform might increase the development costs 
10..50% and bring 4% more money. It doesn't make sense to support other 
platforms unless enforced by the law. This problem won't go away in the 
long run, on the contrary, as new (mobile/htpc/whatnot) platforms emerge.

A middleware is about building the infrastructure. Later (ideally) there 
are no platform specific costs involved. A history lesson might help 
Adam. Both Apple and Microsoft are afraid of middleware solutions. That's 
why Microsoft corrupted Java & Javascript and Apple recently banned all 
non-Apple middleware tools on iPhone. 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.
April 24, 2010
Re: JavaScript is the "VM" to target for D
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.

-- 
Adam D. Ruppe
http://arsdnet.net
1 2 3 4 5
Top | Discussion index | About this forum | D home