Slashdot Mirror
Google Native Client Puts x86 On the Web
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.
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).
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/ where software developers share revenue from the apps they create together
Does it run Linux??
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.
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 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?
Javascript + Nintendo DSi = DSiCade
I for one welcome our new sentient web-based overlords.
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?
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?
This is my sig.
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.
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.
The only question remains whether it can be secured (ala ActiveX)
HAHAHAHAHAHAHAHAHAHAHAHAHAHA *gasp* HAHAHAHAHAHAHAHAHAHAHAHHAAHHAHA *wipes eyes*
HAHAHAHAHAHAAHHAAHAHAHAHAHAHAH
Talk about an oxymoron.
"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?
Security isn't a problem when even safe (in theory) content like PDF is plagued by exploits 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.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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 :)
meh
Firefox within Firefox within Firefox within Firefox?
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.
BIG thanks from Russia. i hope it catches on!
Does this mean I can run old DOS games in a browser?
Silent Service II!
5 years of beta - like gmail?
Way to go Google!
It will go far.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
or you will be in for an unpleasant surprise.
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Does Linux run on it?
(Prompting a possibly valid "In Soviet Russia" gag).
Genesis 1:32 And God typed
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!
Is it ironic that this doesn't work in Chrome?
-Styopa
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.
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.
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.
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.
Nothing on Netcraft yet...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Oh and I noticed this little titbit in the paper:
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.
I haven't coded java in a while but is java still missing the catch all error? For example, in C you can code a for any error that I didn't handle do this... That was missing from java when I worked with it. I thought that was wrong. The program writer should code in a way to exit the program cleanly without crashing for an unexpected event.
Clearly, playing Quake in the browser is the killer app for this technology.
Great ... Google just invented ActiveX.
Tired of FB/Google censorship? Visit UNCENSORED!
Security? Is there any evidence that any of Google's products have a robust security attitude to security? From direct stuff like GMail allowing people to MiTM your session cookie (if you're not using HTTPS) to almost anything going unecnrypted through the text-based web, there isn't a lot to inspire my confidence about the Google approach to computer security.
It might be safe on a local node -- but then you could write straight to the hardware. There's something about virtual machines (Java, ActiveX) having already been done and only with a certain degree of success that puts me right off. But maybe Google will disallow certain opcodes and have a robust product. Most likely not.
Most web services are just data collection machines, designed primarily to capture as much data about the user as possible. Yes, they are sometimes useful to the user but the amount of data collected by companies is ridiculous. I think applications should be run locally on local machines so the user can have a bit of privacy. Companies are recording our every move and that kinda sucks. We live in a big brother world and the only way to escape is to unplug yourself the net.
Adobe Alchemy lets you compile C/C++ code into efficient bytecode for Flash.
Doesn't handle x86 ASM directly, but IMHO C/C++ is a much better target to start with in the first place.
The Alchemy toolchain is open-sourced, as is the Tamarin-backend that it uses. (Theoretically it doesn't require all of Flash to be deployed, just Tamarin.)
beside any heavy computing task (like bruteforcing a bank account or chess games) this *may* help big software company to go web.
That means a way to 'port' an application to web with minimal compiling issues. Like what is said in google blog, adobe will finally deliver a plugin to let you photoshop on the web. This will improve our experience with photo-printing web sites, I already see new facebook applications coming out with "let's do so-and-so to your friends faces!"
And, lastly, in time of crisis one can imagine that big company are not going to fund IT dept. as in the past, and this is a good chance to share some computing load with clients! :-)
I'd love a in my homepage!
In fact all activies which requires big load on servers can be moved on clients. It's like: let me open my gmail to run antispam plugin!
It really sounds like IKEA leit motif: it's cheap because you do part of the work, like help yourself food buffet (you pay what you take, not the service).
Hope in the future users will be able to create computing groups, like "Let my machine do part of my friends machine work when I'm finished".
Whoa, this will also have impacts on so-called cyber-strikes, web-strikes!
so many dreams.. so little time... let's go play google quake (gooake?) online! :-)
nop, nop, nop #VBLANK
They went to all the work of writing an in-browser sandbox for a real world instruction set, and they choose x86? Really? What the hell are they thinking?
At least choose something that we can code in without gouging out our eyeballs. ARM, 68k, anything but x86, please! Just 'cuz that turd's been polished the most doesn't mean it should be propagated into yet another execution space.
- I'd love a in my homepage! :-)
was meant to be "I'd love a seti at home plugin in my homepage! Find extraterrestrial while you read my terrestrial blog!"
nop, nop, nop #VBLANK
If the idea is to let websites stream in precompiled excutables to your browser and then execute the code in your machine to supplant Javascript, Java, Flash and Silverlight, it is a remarkably stupid idea. We do not want undecipherable cruft coming down the ethernet executing commands in the local machine.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Sounds like a cross between VMWare and streaming, delivered in a browser-sandbox.
---- Booth was a patriot ----
class Main implements Object {
public staic void main ( String[] args ) {
try {
}
catch ( Throwable T ) {
...
}
}
}
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
So, if we have a "plug in" that virtualizes/emulates 80x86 code, we still need a language to program in.
What I want to say, is: if you want to make the plug in "safe" you need to prohibit downloaded code from accessing something outside of this "sandbox". The only way to do that is by restricting the instruction set or even sequences of instructions to a subset. In other words: load address from data area into register X (who knows where this points to?) and then jump to contents of register X is an illegal combination of instructions, further more: a data flow analyzer needs to know that register X now contains a tainted value and has to guarantee that this value is never "abused".
Long story made short: existing C/C++ compilers (not to speak about assemblers) basically everything that is generating 80x86 code, in other words every existing programming/compiling environment currently produces code that a sandbox would reject.
Remember what the Browser does with JavaScript and what the Java VM does with Java Byte Code and what the .NET runtime does with JIL: they sandbox it. Access to internet sites except the original site (I simplify) from where the code came is restricted. Access to the file system of the client is restricted. Access to the process memory in which the code is running is "impossible" etc.
If you want to have a browser that has an emulator/sandbox for c86 code, you also need to compile the code against this sandbox, in other words you wont be able to just choose freely what "standard libraries" you use in programming your "browser plugins" ... you end with the very same problem that Java and AWT faced: if I want to create a widget on the client computer I have "to ask the sandbox" to make me a widget and this will likely be different on Linux, Mac, Windows etc. Not to mention: the software I craft is written in Java ... and is not running on x86 machines exclusively but also on HPs (oops, what processors do they even use in our days? Still PA RISC?) SUNs and finally x86 windows machines.
Bottom line: the "byte code" is not that relevant. Who cares if it is emulating x86? I rather find it interesting to emulate x86 code in Java or in .NET :D than having a x86 sandbox. Everything .NET and Java offers has to crafted again for such a sandbox ... IMHO a waste of time (except for academic/research/playing/exploring purpose).
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
This is a fascinating effort. Read the research paper.
This is really a little operating system, with 44 system calls. Those system calls are the same on Linux, MacOS (IA-32 version) and Windows. That could make this very useful - the same executable can run on all major platforms.
Note that you can't use existing executables. Code has to be recompiled for this environment. Among other things, the "ret" instruction has to be replaced with a different, safer sequence. Also, there's no access to the GPU, so games in the browser will be very limited. As a demo, they ported Quake, but the rendering is entirely on the main CPU. If they wanted to support graphics cross-platform, they could put in OpenGL support.
Executable code is pre-scanned by the loader, sort of like VMware. Unlike VMware, the hard cases are simply disallowed, rather than being interpreted. Most of the things that are disallowed you wouldn't want to do anyway except in an exploit.
This sandbox system makes heavy use of some protection machinery in IA-32 that's unused by existing operating systems. IA-32 has some elaborate segmentation hardware which allows constraining access at a fine-grained level. I once looked into using that hardware for an interprocess communication system with mutual mistrust, trying to figure out a way to lower the cost of secure IPC. There's a seldom-used "call gate" in IA-32 mechanism that almost, but not quite, does the right thing in doing segment switches at a call across a protection boundary. The Google people got cross-boundary calls to work with a "trampoline code" system that works more like a system call, transferring from untrusted to trusted code. This is more like classic "rings of protection" from Multics.
Note that this won't work for 64-bit code. When AMD came up with their extension to IA-32 to 64 bits, they decided to leave out all the classic x86 segmentation machinery because nobody was using it. (I got that info from the architecture designer when he spoke at Stanford.) 64-bit mode is flat address space only.
Why not use JPC to run x86 code in Java. They already do that in an applet! That's bulletproof security for you! http://www-jpc.physics.ox.ac.uk/
One wonders why Google don't just buy Sun - they'd get Java (which Google are massively dependent on in their backend), the new JavaFX (Flash/Silverlight competitor) which could replace Native Code and has a massive install base, which Native Code just isn't going to achieve overnight and there is a vast amount of Java libraries out there.
Things like Niagara are quite possibly interesting to a company like Google too.
Not to mention that Sun is massively undervalued - their market cap is similar to their cash balance, in other words, Sun is basically 'free'.
I love MS's numbers showing Xax being faster on Linux than native code on XP ...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
If it just runs in a box inside the page, then this may die the same death as Java applets. That was the main thing that killed them (other than the startup speed, which is fixed in Java 1.6r10 and later). I filed a feature request for Java to have full access to the DOM through Gears here: http://code.google.com/p/gears/issues/detail?id=368 This would allow a whole new generation of web apps...
(Prompting a possibly valid "In Soviet Russia" gag).
In Soviet Russia, Linux runs it on You!!
The paradigm examples of "interpreters" involve directly interpreting an abstract syntax tree of the program being run. Basically, a simple interpreter will have a parser spitting out an AST for the program, and a core that "runs" the AST. A compiler, on the other hand, will transform the program AST into a substantially different object code that's simpler than the language AST. In particular, language ASTs tend to be recursive tree structures, while object code tends to be sequences of instructions. Therefore, a pure interpreter would deal with a complex algebraic expression by recursing into the expression tree; a compiler would transform it into a linear sequence of instructions to compute the result.
However, don't put too much thinking behind the compiler/interpreter distinction; nowadays, mixed systems like bytecode compilation are common, if not the norm. Basically, a lot of "intepreters" out there actually consist of a first part that looks just like a compiler, which outputs bytecode, and a bytecode VM, which looks like an interpreter, though written for a dramatically simpler language than pure interpreters (sequences of instructions, no recursive syntax).
just write a JIT compiler from x86 to your native machine code, thus COMPLETELY nulling any advantage this has over other JIT languages :)
The C++ language can be compiled to x86 bytecode. As far as I know, it can't be compiled to JVM or CLR bytecode. There are plenty of other languages in this same situation.
And anyone who works for me who downloads it will be fired. Native code running in a browser is the WORST FUCKING IDEA I HAVE EVER HEARD. We might as well install telnet and run it as root without a password on a well known port.
And here I thought Google had some intelligent programmers.
FUCK.
They do disallow certain opcodes. They don't allow at least some computed jumps and they don't allow ret, and they don't allow int or syscall.
This is my sig.
Of course it can be secured "a la ActiveX". Just like my super powers make me faster than a speeding monument.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Flash/Flex, Silverlight, JavaFx, JavaApplets, and JavaScript. Yeah, we totally need another runtime environment for the browser.
their demo is the Quake game engine, which is a virtual machine that allows untrusted third parties to contribute game mods.
If you had any, you'd know.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Java applets are not "dead and buried". Neither on the Web, nor on mobile phones (with the distinction increasingly meaningless), or on embedded devices, like DVD players and settop boxes (most of which have Java VMs in them, especially Blu-Ray players and other HD players for menus).
What is "dead and buried" is ActiveX, which is x86 code running in a browser's "sandbox". But even that is clearly no barrier to resurgence, as this story shows.
x86 is a lousy architecture for modern purposes. Its design was determined by optimizations for executing Pascal programs, which was the primary programming market for the IBM PC when it was originally designed. That was a long time ago, and only the huge legacy of existing apps (and their forward momentum maintained by huge backwards compatibility design and sacrifices) keeps x86 code popular. I'm all for a SW x86 emulator, especially for newer CPUs so they don't have to be shackled to design compromises just to run the legacy code, instead of doing it newer and better ways with a more modern instruction set. Just like I'm all for the game emulators that will play old Atari 2600 games on Core Duo PCs and ARM mobile phones. Let's just not enslave ourselves to 1980 design priorities optimizing for a really dead language for yet another decade of programming, now going on 30 years, which is 20 generations under Moore's Law.
--
make install -not war
The only purpose of this I can see is to force a compile of Firefox before serving my page. I'd never have to edit a standards compliant page again. But alas, Google have yet to heed this wish.
This signature is esoteric
Right you are. Let's go after Apple now. Gotta be something in here we can jump on Jobs for.
Faster! Faster! Faster would be better!
Does this mean I can play World of Warcraft in my web browser!?~
FORTH FTW!
The problem with Virtual PC on the G5 is that it needs to emulate the X86 application code plus the Windows OS.
Since most apps strike a pretty reasonable balance between application logic and library calls, most emulators only need to emulate a relatively small portion of the code. They can drop down into native implementations as soon as the app calls library code. That's why script languages are viable at all.
Where I work, we had a large set of applications written in assembler (don't ask) for an '80s vintage minicomputer that was discontinued. Rather then junk the whole thing, we wrote a machine emulator and reimplemented key libraries in C on unix. The result was faster than the original minis, since modern unix hardware was so much faster and the app/library mix was skewed toward the native libraries.
I think one of the problems with traditional desktop Java apps was that major libraries (like Swing?) were not available on all platforms as native code. Again, that leaves you essentially emulating the application plus the platform, which shouldn't be necessary. Don't know if that's still an issue with Java. Certainly Eclipse seems to perform pretty well (once it starts up)...
Posted from my Android phone. Oh, I can change this? There, that's better...
There you go! Google has done it. With this you can download GIMP natively to your browser from the "cloud" and run it. Taking innovation to the next step!
You all seem to not notice something: This stuff is mainly for writing (fast) libraries that JavaScript can use. Try calling Java from JavaScript!
JIT emulation is the worst of both possible worlds! The extra overhead of the bytecode to native translations and the extra overhead of emulation!
Already been done.
Well, except for the daft part about embedding it in a browser.
I have not read the paper.
But, Native Code doesn't seem likely to be sandboxed.
Sand boxed virtual machine code I could see.
Secondly, the idea that Java applets are dead and buried I think is a little too naive.
The first implementation of Applets was prone to lots of problems.
Secondary implementations are being thought out right now, and with access to numerous cores on a typical desktop system, would be much more practical, and WAY WAY safer than executing native code.
As others have also pointed out here, you would need a emulator for x86 machine code on certain platforms as well (phones...web tablets....Nokia for example.)
Also, I would like to point out, we tried native code already. On the server side at least it was called CGI a long time ago.
It was also shown to be incredibly risky to do.
Execution must take place with instructions which cannot be executed on the secured hardware should something go wrong with the sandbox.
Java solves that very important problem, and at both ends (client and server).
With what I already know, I will be reading his paper tonight and will probably hack it too pieces. :-)
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
I personally think that a sending out LLVM IR bytecode to be run sandboxed is a much better idea, since that can be JIT'd to the native platform on which the browser is running, or interpreted if JIT is unavailable; almost as fast on x86, much faster on other architectures, and very portable.
Actually, Microsoft's .NET compiler can compile fairly generic C++ source into .NET IL.
True, Visual C++ 2005 can recompile generic C++ into /clr:pure MSIL, but it won't run in Silverlight or XNA. You have to rewrite the C++ into Microsoft's /clr:safe (verifiably type-safe) dialect of C++ to get it to run in such fully managed environments. Because a C++ program in /clr:safe can't use the C++ standard library, porting a C++ program to /clr:safe would probably be almost as much work as rewriting it into C# in the first place.
Thats a new joke, right?
Imagine the possibilities of new worms and malware using this amazing feature.
Actually, this makes perfect sense to me. Java's real problem is that the VM is tied to the language (Java people would disagree with me, but I challenge you to show me a Java Applet written in C).
I want a web-based VM/OS that really is just that, an OS (ala Inferno/Plan9). Let me as a programmer decide what language I want to write the thing in. Python, Java, C, C++, Intercal, whatever.
Java, C#/Mono, etc... all suffer from this problem. (Well that's not exactly true, .Net is probably the closest in offering a real VM OS... but they really don't talk about languages outside of C# and VB).
Now I'm not sure x86 is the "best" platform to use as your "platform independent architecture." Though it is definitely one of the most prevalent and well supported architectures out there.
The upshot of all this, though, is that we can get Linux running in a web browser (I'm sure someone will figure out some cleaver caching), which will *finally* get us all of our Gnome/KDE/Xaw tools available to larger audiences.
This means *finally* a write once, run anywhere world.
And it means we've just turned all web application developers into Linux developers.
This thing will probably be secure before QuakeLive EVER gets out of testing. Give me an account!
All applets run in the same JVM. This has ALWAYS been true. Each one has its own isolated class loaders and the security manager isolates threads, etc., but your browser will not start multiple JVMs.
That being said, the class loader isolation does mean that aside from standard JavaSE classes (which are already on the client) even stuff which is identical between two applets will get loaded individually by each one.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Meh... I'm running Linux x86_64 but using the 32-bit Firefox. With the 3.2 alpha version of Firefox I get an empty black box. Clicking in it and pressing space does nothing. Using 3.0.4 Firefox crashes when I go to the Quake demo page. The plugin seems to be loaded and active (about:plugins) but otherwise it seems totally broken on Linux.
Your browser runs your operating system!
Please come back when you pull your head out of your ass. thanks.
Um, a pure interpreter never "compiles" its program, in the sense of transforming the code into equivalent code in an object language. A pure interpreter usually works this way:
The easiest example to learn here would be a typical Lisp meta-circular evaulator.
A compiler, on the other hand, translates the AST into equivalent object code in a different language, which can then be run in an implementation of that second language (which can be either a real machine, a virtual machine, a language interpreter, ). For a pure interpreter to "compile each instruction every time it gets executed," there would have to be a program in the object language involved somewhere... and there isn't one, only an model of the successive states of a computation.
Are you adequate?
Does anyone actually enjoy programming JavaScript?
Yes.
No real objects
You might have meant "classes" rather than objects, which is a legitimate formal point, though on a practical level, creating things that act very much like classes is easy.
weak typing
Sometimes, this is a feature, not a bug.
It's fine for small bits of code, but for larger apps?
There are increasing numbers of proofs by example that dynamic languages are able to create large applications.
In fact, there's a half-decent chance that you're browsing this comment in a browser that's a collection of components scripted and glued together via... Javascript.
Tweet, tweet.
From TFA, Native Client is abbreviated as NaCl aka table salt?
I just read this sentence "enables x86 native code to be run securely inside a browser."
After Chrome and Android...I'm just glad I wasn't drinking milk or it would've squirted it of my nose and that would've been lame for a while.
http://bochs.sourceforge.net/
The motive could be to deploy client-side web applications without code. This would give more control without creating network traffic. But...
So, this thing:
1. Requires user to download and install a plugin to run.
2. Requires developer to recompile his code specifically for that plugin (no, it doesn't run arbitrary x86 code).
3. Kills many advanced native code optimization techniques due to verificator restrictions.
4. Only runs on x86 (as described in the paper, it won't even work on an x64 OS!)
So, how, exactly, is it any better than Java applets or .NET browser controls and Silverlight?
Looks like a bad case of NIH syndrome combined with "we can do it in more perverted way than you could even think of". And particularly surprising from Google, as they are one of the bigger Java backers - it would make much more sense for them to work on improving Java applets; say, make a small & fast JIT to improve loading times, better compression for applets for faster download, and a cut-down version of JRE with simplified install a la Flash/Silverlight.
The web browser was originally designed as a distributed network-based display client.
Web 2.0, flash, RIA, JavaFX, Silverlight, etc . are attempting to turn the browser into a processing or compute client.
The browser *can* be a compute client, but it is not an ideal one with the current architecture.
This is yet another attempt to turn the browser into a compute client.
Meanwhile the cloud and GRID guys are working on making the compute server infrastructure.
It would be nice if someone actually designed a robust, secure, scalable and well-thought-out compute client/ compute server net infrastructure.
*NOT* the web.
Maybe the grid?
The cloud?
The Matrix?
Why some one wants to run native program in a web browser? Does quake look cooler in a web browser? I do not think so. Especially when today every browser are becoming so bloated, running program on an extra complicated layer is just wrong.
Per a list of online emulators (written in Java as applets) at http://www.atariage.com/forums/index.php?showtopic=129627, there has already been online x86 emulation done for a while: x86 PC Online Emulator: http://www-jpc.physics.ox.ac.uk/ (try for example: type "c:", then "cd mario", then "mario") PC/XT emulator: http://www.xs4all.nl/~rjoris/retro/ "With Java applets already dead and buried" - umm... I think you are either thinking Java 1.1 or you are exaggerating a bit. While applet development went down quite a bit, there are still an abundance of Java applets around the web and a number of them still being developed. I think that applets will be around and continue to be developed for as long is it is supported in-browser.