Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Native Client Puts x86 On the Web

timothy posted more than 5 years ago | from the which-can-then-be-virtualized-ad-infinitum dept.

Software 367

t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey). The only question remains whether it can be secured (ala ActiveX) and whether the advantages carry over onto non-x86 platforms. The package is available for download from its Google code site. Hopefully, I can finally write my web apps in asm." Note: the Google code page description points out that this is not ready for production use: "We've released this project at an early, research stage to get feedback from the security and broader open-source communities." Reader eldavojohn links to a technical paper linked from that Google code page [PDF] titled "Native Client: A Sandbox for Portable, Untrusted x86 Native Code," and suggests this in-browser Quake demo, which requires the Native Code plug-in.

cancel ×

367 comments

Sorry! There are no comments related to the filter you selected.

doesn't sound too secure yet (5, Insightful)

alain94040 (785132) | more than 5 years ago | (#26046981)

This is not a good thing: by definition x86 code is not portable across platforms.

Secure or not, it goes against the main founding principle of the web, which is portability. There are other ways to solve the performance issue, I thought just-in-time compilers were getting pretty close anyway (50% according to http://www.mobydisk.com/softdev/techinfo/speedtest/index.html [mobydisk.com] ).

On the security side, I'll just quote Google's description: "modules may not contain certain instruction sequences". That doesn't sound like a robust way to detect malicious code.

http://fairsoftware.net/ [fairsoftware.net] where software developers share revenue from the apps they create together

Re:doesn't sound too secure yet (4, Funny)

Sockatume (732728) | more than 5 years ago | (#26047087)

You could work around that compatability issue easily, just set up the browser so it runs inside a preset virtual machine or emulator on the host, so that you can just write x86 code for that virtual machine/emulator rather than executing it directly.* (I heard you like programs, so I put a machine in your machine so you can execute while you execute.)

*Someone may have thought of this already.

Re:doesn't sound too secure yet (1)

MightyYar (622222) | more than 5 years ago | (#26047191)

Yeah, but you'd still have the issue where your subnotebook/phone/PS3/Mac/etc runs slower than your desktop because it has to emulate an x86. This on top of the fact that it may be running a much slower chip...

Re:doesn't sound too secure yet (2, Insightful)

Chyeld (713439) | more than 5 years ago | (#26047321)

Isn't Java run in an emulated fashion on all platforms? Isn't that part of the 'slow' image that it cultivated in it's early years, that it was too slow due to the emulation of the java 'virtual machine'?

Is the problem here that this could mean some machines won't be as slow as others or just that its x86?

What exactly is the difference, outside of one having a much larger code base to 'exploit' and the potential for a huge speedup on machines that can natively handle x86 code?

Re:doesn't sound too secure yet (4, Informative)

fbjon (692006) | more than 5 years ago | (#26047479)

Java is compiled Just-in-time, though I don't know about smaller, obscure or embedded platforms.

Re:doesn't sound too secure yet (1)

saforrest (184929) | more than 5 years ago | (#26047667)

Java is compiled Just-in-time, though I don't know about smaller, obscure or embedded platforms.

Not all Java is compiled JIT.

Re:doesn't sound too secure yet (4, Interesting)

binarylarry (1338699) | more than 5 years ago | (#26047765)

Pretty much all of Sun's offerings have HotSpot built in, which provides JIT compilation for the JVM. IBM's JVM, BEA, etc. all have JIT features. Google's Android has Java-like Dalvik, which is slow as balls and doesn't have JIT functionality.

Some ARM processors are capable of executing Java bytecode natively. The device developers have to pay for that feature though.

Really, it sounds like Google is poorly trying to reinvent Java. They've tried this with Android already and it doesn't work so hot from a performance standpoint.

Re:doesn't sound too secure yet (0)

Anonymous Coward | more than 5 years ago | (#26047847)

>which is slow as balls

Why are balls slow?

Re:doesn't sound too secure yet (2, Interesting)

MightyYar (622222) | more than 5 years ago | (#26047805)

Well, a couple of things...

First, today there isn't a "first class" platform for Java. It's JIT everywhere (excepting a few devices with chip-based Java execution). So a web developer has to consider performance when using Java or Flash. In contrast, native x86 execution obviously favors x86 machines and creates a web ghetto - similar to ActiveX, though not quite as bad.

The second problem is that while Java, and now even Javascript, have been pretty well optimized on non-x86 hardware, I've yet to see a x86 bytecode emulator perform as well. Earlier in the thread someone pointed out how JIT-compiled languages are now about 50% as efficient as natively compiled languages. If this is true, then it seems really foolish to eek out that extra 50% by destroying the performance on all other platforms - especially when those platforms are growing so fast.

My experience with emulation is a bit underwhelming. My G5 Mac can emulate an x86 processor using Virtual PC, but it's slow enough that anything beyond Windows 98 is pretty annoying. I'd hate to see performance of x86 emulation on a phone!

Re:doesn't sound too secure yet (3, Funny)

K. S. Kyosuke (729550) | more than 5 years ago | (#26047339)

The industry will solve it the usual way: They will put an x86 chip inside!

Re:doesn't sound too secure yet (5, Insightful)

larry bagina (561269) | more than 5 years ago | (#26047231)

Those that don't understand java are doomed to repeat it.

Re:doesn't sound too secure yet (2, Funny)

VGPowerlord (621254) | more than 5 years ago | (#26047379)

It's a Java system! I know this!

Re:doesn't sound too secure yet (2, Funny)

phoenix321 (734987) | more than 5 years ago | (#26047459)

Yep, they're re-inventing the wheel, how cool is that?

Re:doesn't sound too secure yet (2, Interesting)

tomhudson (43916) | more than 5 years ago | (#26047715)

Those that don't understand java are doomed to repeat it.

Worse - their example doesn't even make sense ...

Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

So you still end up downloading code ... and probably a lot more code, since you don't have libraries like javax.swing sitting on the users' machine to tap into, you have to download an entire UI ...

What would be better would be to more tha apps out of the browser completely. There's no reason that a java app sitting on your local machine can't do the photo touch-ups w/o having to be embedded in a browser, just like there's no reason you can't open up a remote file in the GIMP and edit it directly if you have the url, username, and password, without having to go through the hassle of right-click in your browser, save to disk, open in GiMP, edit, save to disk, then ftp'ing it back.

Of course, if too many people start relying on apps that interact directly with the net rather than through a web browser, google's business is threatened.

Re:doesn't sound too secure yet (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26047111)

On the security side, I'll just quote Google's description: "modules may not contain certain instruction sequences". That doesn't sound like a robust way to detect malicious code.

Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.

It's true that this does not allow all x86 code to run; it's at least practically (and probably theoretically) impossible to correctly determine whether or not a piece of code is safe, but as long as the VM errs on the side of caution, there shouldn't be any problems with this approach.

I will grant that this makes it unclear what the advantage is over (say) Java applets. What can this technology do that the Java VM couldn't? As far as I'm concerned, the failure of Java in the browser has more to do with the lack of a standard library for high-performance multimedia applications (think: Flash) than with shortcomings in the bytecode language.

Re:doesn't sound too secure yet (0)

Anonymous Coward | more than 5 years ago | (#26047217)

no.

java has a securoty manager to which most of the api refer to, and different profiles for application, for applets and for jnlp programs.

Re:doesn't sound too secure yet (4, Insightful)

AKAImBatman (238306) | more than 5 years ago | (#26047255)

Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.

One of the key differences is that Java code and data are separated to the point of paranoia. I cannot load a classfile as data and pass through execution to the native system. With the x86 instruction set, I can load a data file and execute a jump to a data segment without the code having passed through any sort of system loader. A VM would have to take this into account. Not to mention common issues of stack smashing, heap overflows, and other common memory tricks to execute unwanted code.

When you're managing native code, it only takes one slip-up to hand over the keys to the kingdom. That slip-up may be as simple as a two byte exploit, but it's a slip-up none the less. One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.

Hypervisor features in modern processors simplify the issue somewhat, but it is still not proven that hypervisors are without exploits. Not to mention the overhead of running dozens of simultaneous hypervisor environments.

Java and Javascript have it right. Java bytecode is provably correct because it targets an ideal machine. Thus the code can be translated into well-behaved native code with the linkage between data and code managed during or after translation. Javascript is just as good because it provides an abstract execution environment that must rely on exposed APIs to accomplish any interaction with the system. It is provable not possible (shy of an underlying flaw in the browser) for Javascript to break through its execution engine into a native runtime.

The two platforms may be paranoid, but when you're dealing with security on the scale of the World Wide Web, "better safe than sorry" is a good motto.

Re:doesn't sound too secure yet (0, Redundant)

meepzorb (61992) | more than 5 years ago | (#26047573)

With the x86 instruction set, I can load a data file and execute a jump to a data segment without the code having passed through any sort of system loader.

...and that won't be insecure at all!

(I just love it when my browser runs unmanaged code full of unverified branch statements!)

Re:doesn't sound too secure yet (1)

larry bagina (561269) | more than 5 years ago | (#26047269)

Historically, there have been a LOT of undefined x86 opcodes that cause the cpu to shit all over itself, stomp memory, elevate priveleges, etc.

Re:doesn't sound too secure yet (1)

characterZer0 (138196) | more than 5 years ago | (#26047539)

Java failed in the browser because MS abused its monopoly position to prohibit the OEMs from pre-installing a functional JVM.

Re:doesn't sound too secure yet (2, Informative)

Anonymous Coward | more than 5 years ago | (#26047175)

by definition x86 code is not portable across platforms

Sure it is, you just write a JIT compiler from x86 to your native machine code, thus COMPLETELY nulling any advantage this has over other JIT languages :)

Re:doesn't sound too secure yet (1)

rallymatte (707679) | more than 5 years ago | (#26047189)

Well, that's a good point.
However, it would be very useful for certain applications. Today already we have portability issues. It's not like we're sticking to just html and css as it is. Just think of Java for example.

Re:doesn't sound too secure yet (2, Interesting)

jellomizer (103300) | more than 5 years ago | (#26047313)

Yes all new technology is bad even R&D concepts. Dag Nabbit I want my ASCII (no freaking colors) 300BPS BBS back you know the ones where you need to put your phone headset into the modem. Back then everything was secure. The password was the telephone number that you dialed. Brute force attacks were expensive. And if the BBS had a Password protection you were secured to no end, where no one can get in who you didn't want.

Um the way things work with software is the program sends opt-codes to the CPU which interns translates them to particular basic actions. You could emulate X86 across platforms and it has been done before. Virtual PC did that in the past allowing you to run x86 code on a PowerPC processor. For applications all that we really care about putting input in a black box that will do stuff and getting output back. The Web Interface is good at taking input and giving output (By no means the best, but it can get the job done with a lot of tricks) So if google approach is server side then it would in general be available across clients platforms. Allowing you to run a wide array of applications regardless of your client.

Re:doesn't sound too secure yet (1)

penguinbrat (711309) | more than 5 years ago | (#26047453)

This is not a good thing: by definition x86 code is not portable across platforms.

I think the article/download site may disagree with you, and I believe that VMWare [vmware.com] and VirtualBox [virtualbox.org] would also disagree.

FTA...

"1. Download the Native Client distribution for your development platform: Linux [googlecode.com] , Mac [googlecode.com] , or Windows [googlecode.com] ."

Secure or not, it goes against the main founding principle of the web, which is portability.

How is this going against the principles? Having the same code, run on multiple platforms I would have sworn is the definition of portability...

All this is, is virtualization ported to the browsers - why wouldn't this be a good/cool thing?

Re:doesn't sound too secure yet (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26047473)

Fuck off with the advert pasted into your otherwise reasonable comment you cunt.

Re:doesn't sound too secure yet (4, Interesting)

Ed Avis (5917) | more than 5 years ago | (#26047557)

x86 code runs natively on 90% of the processors out there. Java or .NET bytecode runs natively on about 0% of them (Sun did have a Java chip once but it is long dead). So it is hardly any worse than the alternatives. There are many x86 emulators and some of them have reasonable performance.

If we were starting from scratch now, nobody would choose the barnacle-encrusted i386 instruction set as a way to distribute programs. But given the hardware and software that exists, it's not such a bad choice.

On the security side, I'll just quote Google's description: "modules may not contain certain instruction sequences". That doesn't sound like a robust way to detect malicious code.

Of course, the way to do it is to define what instruction sequences are safe and allow only those. I assume that's what they are doing and 'modules may not contain certain instruction sequences' is just the one-line summary.

That said, you can make any instruction sequence you like using the assembler and run it on your Linux system, and it cannot break out of the process virtual machine to access hardware or memory belonging to other processes or the kernel. If it can, this would be a bug in Linux. So there is no reason why arbitrary instruction sequences couldn't be allowed in principle, if you let the operating system do the work of sandboxing the process. After all why reinvent the wheel?

Re:doesn't sound too secure yet (1)

Keith_Beef (166050) | more than 5 years ago | (#26047705)

http://code.google.com/p/nativeclient/?tbbrand=GZEZ&utm_campaign=en&utm_source=en-et-osrcblog&utm_medium=et

Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps.

This sounds to me like the Native Client is a virtual machine that will execute x86 code inside a browser, regardless of the underlying OS. It doesn't specifically mention hardware, but why not go the whole hog and make this work on any hardware?

K.

Re:doesn't sound too secure yet (1)

Flying Scotsman (1255778) | more than 5 years ago | (#26047845)

This sounds to me like the Native Client is a virtual machine that will execute x86 code inside a browser, regardless of the underlying OS. It doesn't specifically mention hardware, but why not go the whole hog and make this work on any hardware?

From the article linked from the story, emphasis mine:

The release contains the experimental compilation tools and runtime so that you can write and run portable code modules that will work in Firefox, Safari, Opera, and Google Chrome on any modern Windows, Mac, or Linux system that has an x86 processor. We're working on supporting other CPU architectures (such as ARM and PPC) to make this technology work on the many types of devices that connect to the web today.

So it is OS dependant and CPU dependant (won't work on my SPARC box running Solaris).

The important (and finally valid!) question (4, Funny)

Faw (33935) | more than 5 years ago | (#26046995)

Does it run Linux??

Re:The important (and finally valid!) question (2, Funny)

Anonymous Coward | more than 5 years ago | (#26047073)

Does it run Linux??

I just tried Debian PPC, and apparently, no it doesn't.

Re:The important (and finally valid!) question (3, Funny)

mikeee (137160) | more than 5 years ago | (#26047363)

So as if javascript isn't bad enough, now we're going to have the inevitable beowulf cluster running across the tabs of our browsers?

Re:The important (and finally valid!) question (0)

Anonymous Coward | more than 5 years ago | (#26047619)

I can imagine that.

More importantly.... (4, Funny)

PinkyDead (862370) | more than 5 years ago | (#26047367)

Does Linux run on it?

(Prompting a possibly valid "In Soviet Russia" gag).

Re:More importantly.... (0)

PinkyDead (862370) | more than 5 years ago | (#26047403)

Never mind.

(D'oh)

Two steps backward (4, Insightful)

AKAImBatman (238306) | more than 5 years ago | (#26046997)

Google has announced its Google native client, which enables x86 native code to be run securely inside a browser.

Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.

With Java applets already dead and buried

And with good reason!!! Plugin engines do not provide a very smooth browsing experience. You must wait for them to download and activate before you can start using the widget. Meanwhile, Javascript is designed for execution as the page is loading.

The heavyweight JVM was probably the worst offender, but look at Flash for another example of an engine that most developers would rather eliminate. While it was hip to create entire websites out of Flash for a while, the platform was very user-unfriendly and almost died out. Thanks to infighting over video standards however, Flash was able to hold on as a video delivery platform and even gained a margin of success as a web-gaming platform. (About the only area where Java Applets really shined back when they were popular.)

My personal opinion* is that this is a step in the wrong direction. Javascript engines are getting good. Damn good. I'd like to see more R&D poured into these engines and the underlying technologies [whatwg.org] rather than reinventing ActiveX and Java. If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.

* ...and 50 cents won't buy you a cup of coffee anymore, so take it for what it's worth.

** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?

Re:Two steps backward (0)

Anonymous Coward | more than 5 years ago | (#26047055)

Not really... they'll just end up developping a VM for it once it's at an advaneced enough state...

Re:Two steps backward (3, Interesting)

Anonymous Coward | more than 5 years ago | (#26047195)

f researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it.

I really hope so. Does anyone actually enjoy programming JavaScript? No real objects, weak typing, etc. It's fine for small bits of code, but for larger apps? Ugh.

A "lite" version of Python would be nice. Shove (erm, specify) lots of interesting libraries into the browser itself, and let us use those.

Re:Two steps backward (2)

ardor (673957) | more than 5 years ago | (#26047375)

Whats the problem with JavaScript? I have written JS code with >20k lines already, and it was quite ok. Among the things that irritate me is this "var" nonsense (declaring a variable without var puts it in the global namespace!), but other than that, it was fine. Also, you are wrong, JS has real objects. And, weak typing can be a very powerful tool if used properly. Note that Python has weak typing too...

Re:Two steps backward (1)

Anonymous Coward | more than 5 years ago | (#26047495)

you need to learn the difference between weak and strong typing. python and javascript have strong typing, but uses dynamic typing to ensure safety.

C/C++ have weak typing, due to void pointer casts, among other things. For example, dividing an integer by zero, or dereferencing a null pointer in c will cause your program to take a shit, while in Python or Javascript such conditions are checked *at run time* to prevent an illegal action. If the check fails, an exception is thrown, and offending action skipped.

Re:Two steps backward (1)

ardor (673957) | more than 5 years ago | (#26047587)

Hmm, right, confused this with dynamic typing.

Re:Two steps backward (1)

maxume (22995) | more than 5 years ago | (#26047533)

Python has strong, dynamic typing (identifiers are not constrained to a type, but you have to create a new object to coerce something).

Re:Two steps backward (0)

Anonymous Coward | more than 5 years ago | (#26047593)

Note that Python has weak typing too...

No, it doesn't. Python has dynamic, strong typing. JavaScript is dynamic, weak. Consult your undergrad Programming Languages textbook for the definitions, or just see here [wikipedia.org] . Python will throw a TypeError if you try to do crap like 1 + "2". And JavaScript will silently concatenate to "12", right? Strong typing means 1 + "2" is nonsense, and you have to explicitly convert the types.

It's a minor aesthetic benefit if you're, say, reading numbers from a form on a website. But in more complex situations, weak typing tends to make programming errors harder to find.

Re:Two steps backward (0)

Anonymous Coward | more than 5 years ago | (#26047413)

> Does anyone actually enjoy programming JavaScript?

Um... Yes? Stunning, really, that language preferences can vary. Never see that in the modern computing world...

Re:Two steps backward (4, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#26047663)

Does anyone actually enjoy programming JavaScript?

I do. And so can you. [yahoo.com] It's the C-based syntax that throws most programmers for a loop. Once you realize that the language is actually of a functional design similar to LISP, everything gets a lot easier.

No real objects, weak typing, etc.

Javascript has one of the most flexible Object systems I have seen in my 20+ years of programming. And its typing system is actually quite strong. Like another poster mentioned, it's dynamically typed not weakly typed. Which is an issue that fades into obscurity once you understand how to properly utilize the language.

It's fine for small bits of code, but for larger apps? Ugh.

Javascript (like most functional languages) is perfect for building large apps out of a massive number of small bits. Look up scoping in Javascript sometime and you'll understand that larger apps get built by having machines within machines within machines to go from simple tasks to ever more complex tasks. It is, in many ways, a more scalable solution than APIs and packaging. But it is different and therein lies the crux of its failure in the minds of many programmers.

Re:Two steps backward (5, Interesting)

MikeBabcock (65886) | more than 5 years ago | (#26047201)

The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).

If other plugins were to be marked as 'frequently used' by the plugin engine and loaded at runtime instead of page load-time, they'd obviously be just as responsive as Javascript (or more so, since Java is compiled to native code in many cases).

Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.

Re:Two steps backward (1)

thsths (31372) | more than 5 years ago | (#26047399)

> Making a browser that integrates Java in a reasonable way

No, it is not. My browser starts faster than the JVM - and I would like to keep it that way.

Re:Two steps backward (1)

characterZer0 (138196) | more than 5 years ago | (#26047579)

Unless your browser is lynx and you start your JVM in server mode, I do not believe you.

Re:Two steps backward (1)

pizzach (1011925) | more than 5 years ago | (#26047703)

Fine then. Build Java into the underlying OS platform like Mac OS X. Take that.

Re:Two steps backward (4, Insightful)

AKAImBatman (238306) | more than 5 years ago | (#26047405)

The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).

The Java runtime was compiled into early browsers like Netscape. So the load time is not caused by the plugin itself. (Though that does play a role in the first activation.) The load time is the time it takes to download the complete application, dearchive the components, load the components into an interpreter or JIT, initialize the environment and/or APIs used, and finally present the application to the user.

Javascript fits in better with the way web browsers are designed in that the browser executes each individual module during the page load. The makes page loading more asynchronous and thus a better experience for the web user. The web developer can still throw up a "loading" progress bar for applications must preload, but they are the exception rather than the rule.

Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.

There is more to the issue than meets the eye. Besides the synchronous aspect I mentioned, the client Java runtime has also grown to meet the expansion in system memory and complexity. Which is a good thing from the perspective of writing rich applications for deployment on the server or desktop. It's a bad thing when we're talking about the time-sensitive environment of the web browser. If you want an ideal JVM for the browser, Sun is going to have to strip it down again and make the platform a better fit than it has been in the past. (A version that relies heavily on the DOM for APIs would be preferable.)

They're also going to have to work out a good method of solving the load problem. Even Flash allows for partial execution prior to the load being complete. (This is how most Flash games show a LOADING screen.) Java was not designed with this in mind and the platform shows it. There are ways a developer could work around it using dynamic class loading, but this requires a great deal of knowledge, effort, and skill on the part of the developer.

My own feeling is that it's best to let sleeping dogs lie. I love the Java platform, but it currently has a higher calling. Best to let it work where it excels and focus on the aspects of the browser that currently excel. (e.g. Javascript)

Re:Two steps backward (0)

Anonymous Coward | more than 5 years ago | (#26047549)

Still, you have to download a Java app before you start using it. And you can make JavaScript app that's usable before it's even fully downloaded.

Re:Two steps backward (1)

Rich0 (548339) | more than 5 years ago | (#26047787)

but it was before we had computers with enough RAM to handle it IMHO.

IMHO, we still don't have computers with enough RAM to handle it. :) I can pretty much count on runnning anything java-based to eat up 50X as much RAM as the equivalent done in C (or anything else).

In fact, I normally run with ulimit -v 1200000 (for all non-root or init.d processes) so that I don't have to worry about a swap-storm when a process goes out of control. I never notice the limit except when I go to launch some java app. Then I have to raise the limit and watch my swap go nuts (and this is on a system that otherwise does fine with apache, mysql, mythbackend, and smbd all running at once with maybe a compile job or two running - granted, with appropriate (io)niceness set on everything).

Sure, I could add an extra GB or two of RAM just so that java would behave, but why would I want to?

Re:Two steps backward (1)

rcallan (1256716) | more than 5 years ago | (#26047871)

Yes, I wish this existed. The problem might be that without modification you need a new JVM instance for each new applet, but it could probably spawn a new one each time one is used so it's ready immediately. There are some projects to run multiple programs within one JVM so that might work too. It's odd to an outsider that there's so much work going into optimizing javascript and flash (and from the crazies, silverlight) when java could fill all those roles. It strikes me (a java fanatic) that java is the unix of the web, it's secure and scalable and to those that use it, it seems perfect for the job, but no one uses it, instead everyone uses a solution cobbled together from different sources (adobe, microsoft, google). Again, I'm just an outsider looking in...

Re:Two steps backward (0)

Anonymous Coward | more than 5 years ago | (#26047287)

** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?

Because JavaScript is fully standardized across browsers? Right. Good luck with that.

And before you make the same response as every other web monkey, that all you need to do is use XYZ library (which one? No one can decide which is why there are so many) to make your web app 'work' with most browsers. Oh, and you have to completely subvert the HTTP protocol, there's that too.

Rather than putting x86 on the web, why not ditch the HTTP/HTML/CSS/JavaScript abomination once and for all? Are web developers so blinded that they can't see just how horrible a solution this is? Year after year, they keep turning out more and more libraries, frameworks, and buzzwords to try and overcome the simple fact that the Web wasn't designed for applications. Anything more complicated than a simple HTML form, and you're done for.

Scrap all this nonsense and come up with something truly new. A company like Google could pull this off.

Re:Two steps backward (1)

ardor (673957) | more than 5 years ago | (#26047431)

Agreed. The web is not a place for applications. HTML is designed for hyper_text_.

A "webapp browser" would essentially be the view and one half of the controller in the MVC pattern. An interesting idea would be to have the browser as an environment for Adobe Adam & Eve scripts: http://lambda-the-ultimate.org/node/563 [lambda-the-ultimate.org] .

Re:Two steps backward (2, Interesting)

vrai (521708) | more than 5 years ago | (#26047563)

As an aside, C/C++ is an incredibly complex build environment ...

C/C++ are programming languages, not build environments. There's nothing to stop developers using qmake, or Jam, or one of many more user friendly build systems. The fact that the examples don't is more indicative of the intended audience (expert native-code developers) than anything else.

As to "why build this at all" ... because they can, they want to and it has the possibility to provide a feature set not currently available. No one who isn't a graphic designer likes websites made entirely out of flash; but flash games are undoubtedly popular and fun. In general I don't like the use of Javascript (if I see another stupid fading menu I'm going to hunt down the developer who wrote it and kill them as they sleep) but I love the GMail interface and wouldn't be without it.

The web is nothing if not Darwinian. If this technology has no real use it will go the way of Java applets and VRML. If a killer app can be found it will become part of the landscape and we'll all forget what it like to live without it.

Re:Two steps backward (1)

CompSci101 (706779) | more than 5 years ago | (#26047689)

I don't think the latest trend in RIAs and the associated frameworks is about changing the way we browse the web. I think it's about unifying desktop and web application development. You can sort of see it happening already with Silverlight, where you're effectively writing against the same WPF API, using the same XAML and .NET classes, for desktop apps and web apps intended to be run against the Silverlight runtime.

I think you're right in that all these schemes are effectively a reinvention of ActiveX and applets. But, honestly, I don't think that's a bad thing. The technologies themselves were bad and poorly implemented, but the ideas and motivations behind them were not.

One problem of adoption in the past, however, was that implementing any of these custom controls was prohibitively expensive from a bandwidth and "user education" perspective -- you absolutely could not count on a user waiting for your plugin to install (or, in Java's case, waiting for the full JRE to come down) or knowing how to install it properly. It's almost braindead with Flash and people still have problems from time to time. Silverlight has the advantage here, as Windows users will already have the runtime installed on their machines. Bandwidth is less of an issue today, but there's still the issue of platform (and which version, etc., etc.). It'll be interesting to see if that piece finally gets worked out.

Anyway, I for one will be glad to see the DOM and its many many many incompatible implementations go. HTML is meant for laying out pages, not for describing user interfaces. It has been 15 years and we still don't have a combobox, for fuck's sake!

C

Java applets Dead and buried (1)

Chrisq (894406) | more than 5 years ago | (#26047737)

Java applets may be dead and buried on the internet but in many corporate environments they are alive and well. The "Oracle Forms Runtime" is a good example.

Obligatory (0)

Anonymous Coward | more than 5 years ago | (#26047033)

I for one welcome our new sentient web-based overlords.

I can see the appeal; but it sucks. (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26047079)

Yeah, as the title suggests, I can see why this would be attractive. x86s are everywhere, as is code for them, sidesteps the hassle of working it out in javascript, etc, etc. That said, though, it seems really, really gross. For those applications where dealing with an embedded add-on is an acceptable tradeoff for higher performance, we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?

Re:I can see the appeal; but it sucks. (0)

Anonymous Coward | more than 5 years ago | (#26047151)

Especially given the improvement we've seen in java performance over the last few years.

Re:I can see the appeal; but it sucks. (1, Insightful)

0xABADC0DA (867955) | more than 5 years ago | (#26047571)

we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?

Isn't it obvious? Google standardized on C++, Java, and Python. As you point out, Java is already there. This 'any x86' lets them use their other two languages, C and Python. It kills two birds with one stone, and securing x86 is a hell of a lot easier than securing C++.

Of course, if they just straight up told people they wanted to choose the wrong tool for the job just because it's what they know they would have been laughed off the web.

This is really f--- cool. (1)

tjstork (137384) | more than 5 years ago | (#26047115)

I understand the whole portability issue is just terrible, but, as a technology goes, I have to say that this is really cool. Everyone else can talk about Javascript, but this technology opens up the browser to any kind of a language in it.

I think it is fascinating, and fun. Assembly language on a browser, why not?

sandboxed desktop app (0)

Anonymous Coward | more than 5 years ago | (#26047121)

sandboxing aside, how is this different from a desktop app accessing a server?

my 2 cents: the web is full of hyped, rehyped, and overhyped ideas that have been reinvented again and again. I think this plain 2D web page + http + xml is already very saturated. Time to move on to VR internet, ala Ghost in the shell.

Re:sandboxed desktop app (1)

Sancho (17056) | more than 5 years ago | (#26047421)

The code is executed natively, which means that execution will not tax the remote server and output can be displayed immediately without waiting for the server to respond to a request.

That said, I'm not a fan of adding sandboxes willy-nilly. They're hard to get right, and this is just one more security issue to be concerned about.

Off topic, but (0, Offtopic)

C_Kode (102755) | more than 5 years ago | (#26047125)

Is anyone else having issues with Google and Gmail lately? (specifically partnerpage.google.com)

It's been slow and sometimes not working at all over the last two days.

Re:Off topic, but (1)

IIRCAFAIKIANAL (572786) | more than 5 years ago | (#26047181)

Yes, I have. Really frustrating.

Re:Off topic, but (1)

Cowmonaut (989226) | more than 5 years ago | (#26047257)

Actually yes. I've noticed issues with some of the other Google domains such as gmodules.com as well. Will be interesting to find out what the cause is. I thought it was Firefox for a bit there but it turns out one of the domains on TechDirt has a script that was crashing Firefox (hurray for NoScript; didn't have it on my work PC before today).

On topic though: I seriously hope they don't plan on hosting virtual x86 boxes, just provide the code. They seem to be obsessing over the whole cloud computing thing but I can't a) think of any practical use to do so or b) see any thing good coming from that.

Does anyone know what the point is to this anyways? Its non-portable really and x86 hardware is fairly cheap. Its also not hard to hook it up to a network so you can access from anywhere. So really, what is the point?

Did they really just... (5, Funny)

geminidomino (614729) | more than 5 years ago | (#26047129)

The only question remains whether it can be secured (ala ActiveX)

HAHAHAHAHAHAHAHAHAHAHAHAHAHA *gasp* HAHAHAHAHAHAHAHAHAHAHAHHAAHHAHA *wipes eyes*
HAHAHAHAHAHAAHHAAHAHAHAHAHAHAH

Re:Did they really just... (0)

Anonymous Coward | more than 5 years ago | (#26047261)

Those funny google guys..!

Re:Did they really just... (0)

Anonymous Coward | more than 5 years ago | (#26047589)

Was about to respond, "Since when has ActiveX been secure?", but you beat me to it in a much more eloquent manner.

"secured (ala ActiveX)" (4, Insightful)

fgaliegue (1137441) | more than 5 years ago | (#26047143)

Talk about an oxymoron.

Beta (2, Insightful)

rodrigoandrade (713371) | more than 5 years ago | (#26047169)

"We've released this project at an early, research stage to get feedback from the security and broader open-source communities."

Just slap a "Beta" on it and move on, that's the Google way, right?

Re:Beta (2, Insightful)

ionix5891 (1228718) | more than 5 years ago | (#26047427)

Nope the google way is:

1. slap "Ads by Google" on everything
2. ???
3. PROFIT !

Re:Beta (1)

YourExperiment (1081089) | more than 5 years ago | (#26047471)

Just slap a "Beta" on it and move on, that's the Google way, right?

No, that's what they do when it's finished.

Finally ... (1)

Lazy Jones (8403) | more than 5 years ago | (#26047193)

After posting rants about crappy interpreted languages, incompatible HTML/CSS/JS implementations, ridiculous W3C "standards" (that their own browser never supported properly), I'm glad that someone finally did this (as suggested here [slashdot.org] a few days ago).

Security isn't a problem when even safe (in theory) content like PDF is plagued by exploits [theregister.co.uk] regularly. People need to learn to a) switch on such features only on trusted web sites (use Noscript e.g.) and b) distinguish trusted from untrusted web sites (i.e. avoid phishing). If they fail at these, they shouldn't be using the web. We had the same security implications with ActiveX when MSIE was much more dominant and unsafe and the world didn't end because of it.

Now let's see some hosted apps with decent performance and good UIs and let's make sure that hitting backspace doesn't destroy all our work.

Re:Finally ... (1)

Beyond_GoodandEvil (769135) | more than 5 years ago | (#26047341)

Now let's see some hosted apps with decent performance and good UIs and let's make sure that hitting backspace doesn't destroy all our work.
Amen to that brother, I can't remember the site, but somehow trying to backspace an error in a form did the old back browse and I lost everything. Like alt-arrow was too hard to do why the hell did backspace need to be tasked to this function?

Re:Finally ... (1)

Lazy Jones (8403) | more than 5 years ago | (#26047451)

but somehow trying to backspace an error in a form did the old back browse and I lost everything.

This happens when the input forms temporarily lose focus because the browser loads something (switches to bee / hourglass icon), then apparently "backspace" gets sent to the browser window and interpreted as "back" instead of just being applied to the text field of the form.

Re:Finally ... (1)

VGPowerlord (621254) | more than 5 years ago | (#26047527)

Security isn't a problem when even safe (in theory) content like PDF is plagued by exploits regularly.

While people could be more careful, allowing native code means that things that used to rely on exploits can now run natively instead!

I, for one, do not welcome our net Botnet overlords.

Regardless (1)

bigattichouse (527527) | more than 5 years ago | (#26047207)

Browser security not withstanding... By effectively emulating a CPU, it does open up some interesting experiments in distributed computing - and, yes, I'd like to see a tiny linux distro running in a browser :)

So can I run (0)

Anonymous Coward | more than 5 years ago | (#26047211)

Firefox within Firefox within Firefox within Firefox?

Something similar from Microsoft (4, Interesting)

Doodhwala (13342) | more than 5 years ago | (#26047221)

Microsoft is doing something similar and is, in fact, presenting a talk today on leveraging legacy code to deploy desktop applications on the web.

You can find more details here [usenix.com] .

GREAT IDEA (5, Funny)

scsizor (1380671) | more than 5 years ago | (#26047251)

BIG thanks from Russia. i hope it catches on!

google x86 (3, Funny)

ablizz (47709) | more than 5 years ago | (#26047273)

Does this mean I can run old DOS games in a browser?
Silent Service II!

5 years of beta - like gmail? (0)

Anonymous Coward | more than 5 years ago | (#26047283)

5 years of beta - like gmail?

Way to go Google!

A remarkably bad idea. (5, Insightful)

John Hasler (414242) | more than 5 years ago | (#26047289)

It will go far.

Re:A remarkably bad idea. (1)

ionix5891 (1228718) | more than 5 years ago | (#26047515)

all jokes aside it might go far,

hows this for an idea

google can farm out computing resources ala seti @ home style to the users browsers (maybe offer financial rewards like adsense credits or something)

dont underestimate how evil google are and how users blindly trust their brand

Re:A remarkably bad idea. (3, Interesting)

freddy_dreddy (1321567) | more than 5 years ago | (#26047801)

from page 3 in the paper:

"In Native Client we disallow such [self-modifying code] practices through a set of alignment and structural rules that, when observed, insure that the native code module can be disassembled reliably, such that all reachable instructions are identified during disassembly."

Ok, when I read the post I had to chuckle when I read the asm joke. I've been programming in asm for 16 years now and there are a few rules of thumb:
- if assembly is allowed then the only real security is executed by hardware.
- malware writers love a challenge like this.

Re:A remarkably bad idea. (0)

Anonymous Coward | more than 5 years ago | (#26047861)

As Leeloo said, "Senno Ekto Gamat" (never without my permission)

Just don't goto fdisk.com (1)

kbrasee (1379057) | more than 5 years ago | (#26047327)

or you will be in for an unpleasant surprise.

What a stupid idea (5, Insightful)

Sloppy (14984) | more than 5 years ago | (#26047361)

Seriously, this is even worse than saving Hitler's brain by putting into the body of a great white shark armed with lasers.

With Java applets already dead and buried

If you want crap like this, you would be a lot better off, by just exhuming Java applets.

I really hope this project dies a quiet death.

Re:What a stupid idea (1)

mujadaddy (1238164) | more than 5 years ago | (#26047555)

Seriously, this is even worse than saving Hitler's brain by putting into the body of a great white shark armed with lasers.

Stupid... or BRILLIANT!!?!?!?!

Gears 2.0 (0)

Anonymous Coward | more than 5 years ago | (#26047465)

But in a much worse state...

I would rather they pursue improvements to JavaScript than waste time on this.
JavaScript is a powerful language, with some changes over time (such as similar permissions to Java, file creation within a sandbox?), it could be much better.
And of course, with the future of HTML and CSS kept in mind when doing such improvements.

Don't add yet another bloody plugin / extension to the web... Java and Flash were bad enough, now we have SilverLight and a bunch more all over the place...

JUST IMPROVE JAVASCRIPT!

Irony, thy name is "chrome" (1)

argStyopa (232550) | more than 5 years ago | (#26047469)

Is it ironic that this doesn't work in Chrome?

Whats with all the hate? (1)

giemer (1066414) | more than 5 years ago | (#26047535)

I can only see good possibilities for this.

As long as a proper framework is put together, you can avoid any major pitfalls. Its basically just another VM ... ?

Its a pretty large step in terms of making virtual web based OS's have value, which is something Google is going for, no?

I can foresee the end of client side applications.

Java applets already dead and buried? (0)

Anonymous Coward | more than 5 years ago | (#26047565)

Really? When did this happen? Someone forgot to tell Sun, and IBM/Lotus. Since Notes is one of the most popular email servers on the planet, and their web access uses Java when available, that's millions of users in just one application. That's hardly the only one.

Sounds like Wired Magazine's obsessing over "wired/tired/retired" every week they would have something marked as obsolete that was the new hot thing two weeks ago. Get real. Languages have a much longer lifecycle than that, and people are still writing Java applets today.

Silverlight & other JIT compilers? (0)

Anonymous Coward | more than 5 years ago | (#26047707)

C# and VB.NET over Silverlight give quite a good performance. Silverlight v3 will support also GPU's with DirectX or OpenGL for Macs (MoonLight for Linux though they are coming late), that should do the job for the few points (games and similar applications) to use this kind of high performance computing.

With Java applets already dead and buried (2, Funny)

Hognoxious (631665) | more than 5 years ago | (#26047795)

With Java applets already dead and buried

Nothing on Netcraft yet...

Could just be another JavaScript optimization... (1)

XDirtypunkX (1290358) | more than 5 years ago | (#26047837)

I mean, it makes sense, instead of interpreting and then JIT'ing the JavaScript, compile it down to x86 code and super-optimize it ahead of time. Browser supports native code? It runs, otherwise, download the Javascript.

Means you can get a whole lot more optimizations into the Javascript code running on the majority of machines and run "decently" on the others.

Native x86 code can not be secured (1)

hAckz0r (989977) | more than 5 years ago | (#26047865)

There are just too many ways to make the tail wag the dog when dealing with native binary execution. Anyone who knows the x86 processor well enough will understand that truth. ActiveX was a big mistake. Using a 'trust model' for something that can't be trusted sure makes a lot of sense. What you are trusting is the key that signed the applet, not the original owner nor the app itself. With a little social engineering even you can own a Microsoft key for signing applets. Others have.

Oh and I noticed this little titbit in the paper:

Better segment support in the operating system might allow us to resolve this problem and allow for better hardware exception support in untrusted code.

Oh yea, right. Like Microsoft is going to rewrite Windows just for Google? On the bright side, if the browser apps only run on Linux then that would certainly be a switch.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>