Emulated PC Enables Linux Desktop In Your Browser 165
Ianopolous writes "Classic DOOM and DSL Linux Desktop inside your Java-enabled browser! The latest JPC, the fast 100% Java x86 PC emulator, is now available with online demos and downloads. JPC is open source and is the most secure way of running x86 software ever — 2 layers (applet sandbox, JPC sandbox) of independently validated security make it the world's most secure means of isolating x86 software. Visit the website to try out some classic games and play around with Linux all within your web browser. Refresh = reboot!"
Re:Refresh = reboot! (Score:2, Interesting)
Maybe you should run it in some sort of java applet container, I hear they are fairly readily available these days. HIGH TECH SHIT!
Meanwhile, it seems like a cool way to host teeny abandonware DOS games.
The JVM sandbox is amazing but not so for applets (Score:1, Interesting)
As much as the JVM has proved to be rock-solid (buffer overrun/overflow are impossible in Java code: if it happens then the JVM is not specs-compliant... The only buffer overrun/overflow known were in third party, C-written lib [zlib comes to mind]), the applet sandbox inside the various browsers as proven to be a major PITA. Java applet didn't just gave Java a bad name for being so pathetically lame, ugly and slow... But also notoriously insecure: there are so many security issues regarding applets it's not even funny anymore.
Browser inside Damn Small Linux inside JPC inside my browser... Probably hard to break that that said.
But I'm not switching from my "reimaged Xen browsing VM as soon as I close my browser" anytime soon ;)
(yup, I use a Xen [para-virtualized, not hardware-virt] Linux VM which's sole purpose is browsing and everytime I relaunch the "browser", that Xen VM is re-imaged).
Hack that ;)
source code ? site is down ! (Score:4, Interesting)
do they provide sourcecode ?
(really interested if they do )
virtualbox is pretty nifty but inside a JVM is pretty impressive from a engineering point of view
have they published any work on this ?
regards
John Jones
You don't want it, but that's not the point (Score:4, Interesting)
I don' think Applet deployment is the target for that project; if they are offering this option it's certainly just for quick demo sake. Notice also that the applet would need some serious time to download because (1) the emulator itself is reasonably big, (2) you need a virtual disk image containing the whole OS and apps; even a small FreeDOS distro with a couple of tiny DOS games will weight in a few hundred Kb, although the problem is mostly for first run as the Java PlugIn can cache everything.
As I see it, JPC's main goal is showing off some amazing virtualization technology that they have developed - the emulated x86 code is JIT-compiled by JPC's engine into Java bytecodes, which are in turn JIT-compiled by the JVM to native code, so the net result is full native-to-native translation. (If both steps are sufficiently efficient and the host platform is also x86, the compiled code may even be very similar to the original code.) This remembers of similar systems like Transmeta's Crusoe.
As a secondary goal,. JPC is becoming a pretty nice general-purpose PC emulator, so it's potentially just as useful as other PC emulators like Bochs. If JPC reaches sufficiently close to native performance (I tested it ~1yr ago and it's slashdotted now), and includes sufficient hardware compatibility, it's obviously an advantage to be a Java program, fully portable including UI.
Re:obligatory (Score:3, Interesting)
...we put a Operating system in your Browser so you can Browse Operating systems while you browse in yo operating system!
software does seem to have a soft spot for recursive acronyms, (GNU, LAME, WINE,etc). This seems to be the next logical step. Recursive operating systems! neat.
Single point of failure (Score:4, Interesting)
2 layers (applet sandbox, JPC sandbox) of independently validated security make it the world's most secure means of isolating x86 software
I contest this notion (if I understand their setup correctly; the website is broken so I've some uncertainty about what they're doing). I agree that it's likely a very secure setup, but I disagree that the two lawyers of Java VM security makes it the most secure setup for running x86.
The common Java VM is a single point of failure. Both layers of "independently validated security" are running in Java VM, so if there is an exploit in the runtime interpreter (or compiled executable, if they're compiling things now), it may be used to circumvent both sandboxes. Using two different Java VMs would be an improvement, but better still would be orthogonal interpreters (on the plane of security vectors) such as a Java VM and a Python interpreter. Both are nevertheless still probably calling some version of glibc on x86 machine code.
If I were to speculate (and I will), I'd say that Xen et al virtualization has fewer vectors, and better still would be x86 virtualization running on top of a mainframe ala. z/VM. That would, in theory, be more secure than this Java VM on Java VM setup. Of course, it all comes down to the implementations in the end (and, as a practical matter, how big a target they are - Java is a big target for security, z/VM less so).
Again, though, I think this Java VM is likely very secure. Claiming it's the world's most secure is puffery, though, in my humble opinion.
I prefer (Score:1, Interesting)
....the JPC on ClassicDOSGames.com rather than this site.