Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boot a linux kernel right inside your browser.

bellard.org

Post reply on HN
Print view View original

191–200 of 255 posts

Re: Boot a linux kernel right inside your browser.

#191

Post by rbranson »

mythz wrote: post #187
guygurari wrote: post #185

Earlier quoted context omitted.

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing cod…

Have you never used Java Applets? (i.e. JVM in the browser) the load time alone makes that a terrible idea. Not too mention the 'breaking the web/page model' and poor UX that ensued. Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.

While I don't think the JVM is the savior, applets are a far cry from a good example. Applets usually cause the browser to lazy load the entire JVM as a plug-in, from scratch. Very little effort has been put forth to make this process fast. It's likely if the JVM was directly integrated, it would remain resident.

Re: Boot a linux kernel right inside your browser.

#192

Post by rbranson »

nupark2 wrote: post #173
powertower wrote: post #171

Earlier quoted context omitted.

>This is why so many people want to see the browser execution environment offer more complete, low-level APIs instead of high-level APIs locked to HTML/CSS and legacy browser technology. It's called the desktop and offers all the native and low-level stuff you can possibly imagine. And the only people that want to see it, are the ones who have forgotten about it. Maybe there is a middle ground between desktop softwar…

> It's called the desktop and offers all the native and low-level stuff you can possibly imagine. Actually, I'd say it's called 'mobile'; The desktop failed to solve the sandboxing problem. > And the only people that want to see it, are the ones who have forgotten about it. As a desktop-turned-mobile developer, I haven't forgotten anything. Simply put, I want a future in which we aren't forced to re-implement our app…

You're always going to feel hobbled by a standards-based, compatibility-driven platform like the web where you must maintain compatibility with fairly ancient software. This is just the way things are. If it wasn't the web, it'd be whatever layer was used to allow your applications to run across multiple devices.

Re: Boot a linux kernel right inside your browser.

#193

Post by [deleted] »

adrianN wrote: post #184
nupark2 wrote: post #173

Earlier quoted context omitted.

> It's called the desktop and offers all the native and low-level stuff you can possibly imagine. Actually, I'd say it's called 'mobile'; The desktop failed to solve the sandboxing problem. > And the only people that want to see it, are the ones who have forgotten about it. As a desktop-turned-mobile developer, I haven't forgotten anything. Simply put, I want a future in which we aren't forced to re-implement our app…

It might just be me, but it seems profoundly silly to implement what basically amounts to a complete operating system in a browser. Why not use something reasonable like the Java or .Net VM to implement your cross platform applications? I think browsers should stay programs to browse webpages and therefore keep their focus on scripting that enables fancier HTML and CSS manipulation. While running Linux in a browser i…

[deleted]

Re: Boot a linux kernel right inside your browser.

#194

Post by nupark2 »

tectonic wrote: post #190
tlrobinson wrote: post #179

Earlier quoted context omitted.

Imagine what kind of advances could be made if a common bytecode was established I'm beginning to believe NativeClient and PNaCl (LLVM on NaCl: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf ) has the best shot at becoming this. Google is already including NaCl in Chrome developer builds, so I wouldn't be surprised if they enabled it in releases by the end of the year, and started releasing Native Client…

I don't know a lot about NaCl but my gut reaction is that it will be insecure and allow my computer to be remotely exploited. Why am I wrong?

http://www.chromium.org/nativeclient/reference/research-pape...

It's possible that the design could be flawed, but the same is true for browser implementations and mobile application sandboxing.

Re: Boot a linux kernel right inside your browser.

#196

Post by sehugg »

guygurari wrote: post #185
nupark2 wrote: post #127

This is demonstrative of the advantages of the new low-level APIs being added to JavaScript to work efficiently with binary data. Fabrice uses this to implement an x86 interpreter -- it could not be done efficiently without typed arrays. However, it is still slow -- imagine what kind of advances could be made if a common bytecode was established that would be JIT'd by the JavaScript VM, and could be output directly b…

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing cod…

The applet model had/has major issues:

* Takes way too long to load the JVM. Deal-breaker for many sites.

* Horrible (AWT) and complicated (Swing) UI toolkits that ignored any look-and-feel parity with the rest of the web site or even the web browser itself.

* The environment is controlled by Oracle. I don't think they're looking to compete with JS, Flash and Silverlight. Thus web applets (except for niche internal apps) are dead, RIP.

Re: Boot a linux kernel right inside your browser.

#197

Post by wicknicks »

He even ported his tcc compiler to it. Brilliant! I wonder if we could tap into the device file system. Given the increasing number of sensors in mobile phones and no standard way of reading from them, a linux like interface would be awesome.

  int main (int argc, char **argv)
  {
       int f = open("/dev/android_accelerometer");   
       double ax = f.read();
       double ay = f.read();
       double az = f.read();
       printf ("Current 3d acceleration: %d %d %d", ax, ay, az);
       return 0;
  }

Re: Boot a linux kernel right inside your browser.

#198

Post by tlrobinson »

tectonic wrote: post #190
tlrobinson wrote: post #179

Earlier quoted context omitted.

Imagine what kind of advances could be made if a common bytecode was established I'm beginning to believe NativeClient and PNaCl (LLVM on NaCl: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf ) has the best shot at becoming this. Google is already including NaCl in Chrome developer builds, so I wouldn't be surprised if they enabled it in releases by the end of the year, and started releasing Native Client…

I don't know a lot about NaCl but my gut reaction is that it will be insecure and allow my computer to be remotely exploited. Why am I wrong?

The entire point of NaCl is to run native code securely.

I won't get into the details because there's tons of information out there (http://www.chromium.org/nativeclient/reference/research-pape...), but code must be compiled using a special NaCl compiler, then before it's executed the client runs it through the NaCl verifier to ensure it's safe to execute.

Of course it's possible there are bugs in NaCl, but Google won't enable it in Chrome by default until they're very confident it's secure.

Re: Boot a linux kernel right inside your browser.

#199

Post by guygurari »

mythz wrote: post #187
guygurari wrote: post #185

Earlier quoted context omitted.

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing cod…

Have you never used Java Applets? (i.e. JVM in the browser) the load time alone makes that a terrible idea. Not too mention the 'breaking the web/page model' and poor UX that ensued. Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.

I have used and written applets, and they are horrible, but it's not what I'm suggesting. Applets run in their own area on the page and can't interact with the rest of the page like javascript does. I'm suggesting to replace the javascript runtime with a JVM runtime, while supporting everything javascript does through an API. Here's the use case I'm imagining:

1. When a user starts loading a page (read 'web app') the browser spawns a new JVM for that page. How long does this take? You can bring it down to the price of a fork if you keep a JVM running at all times.

2. Instead of running javascript that's embedded in the page, you compile and run Java/JRuby/Jython. Better yet -- have the server precompile the embedded code and send you the bytecode. Load it dynamically into the JVM and run it in the page's thread. With a modern JVM you get JIT for free and the code runs at near-native speeds.

3. Want long-running background tasks? No problem -- the JVM code can start its own threads. Suddenly AJAX, and all the other stuff we use to make web apps behave like desktop apps becomes trivial.

4. User leaves the page / web app? Kill the JVM.

Re: Boot a linux kernel right inside your browser.

#200

Post by guygurari »

sehugg wrote: post #196
guygurari wrote: post #185

Earlier quoted context omitted.

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing cod…

The applet model had/has major issues: * Takes way too long to load the JVM. Deal-breaker for many sites. * Horrible (AWT) and complicated (Swing) UI toolkits that ignored any look-and-feel parity with the rest of the web site or even the web browser itself. * The environment is controlled by Oracle. I don't think they're looking to compete with JS, Flash and Silverlight. Thus web applets (except for niche internal a…

Applets are terrible but it's not what I'm suggesting. See my reply to mythz.
Post reply on HN