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

181–190 of 255 posts

Re: Boot a linux kernel right inside your browser.

#181

Post by nupark2 »

tlrobinson wrote: post #179
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…

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'm beginning to believe NativeClient and PNaCl has the best shot at becoming this.

Me too, although the biggest hurdles seem as much political as they are technical.

My hope is that Google can strong-arm NativeClient into active use, forcing otherwise recalcitrant browser makers (Mozilla, Apple, Microsoft) into adopting it.

Re: Boot a linux kernel right inside your browser.

#182

Post by jonknee »

tlrobinson wrote: post #179
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…

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…

NativeClient is being distributed in the official public build of Chrome, just in a disabled state. You can turn it on in about:flags.

Re: Boot a linux kernel right inside your browser.

#183

Post by VMG »

utoku wrote: post #49
neopanz wrote: post #2

Not sure how long ago he posted this. This guy never ceases to amaze me. He's the Grigori Perelman of Hackerdom.

uname -a shows Linux (none) 2.6.20 #3 Sat May 14 19:08:30 CEST 2011 i586 GNU/Linux

I wonder why he chose this kernel version instead of the latest

Re: Boot a linux kernel right inside your browser.

#184

Post by adrianN »

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…

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 is an impressive feat, to me it is similar in spirit to simulating a Turing machine in the Game of Life.

Re: Boot a linux kernel right inside your browser.

#185

Post by guygurari »

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 codecs without the need for browser support), and for crazy things like this.

3. Most importantly, the ability to run actual desktop-like apps in the browser at near-native speeds, instead of the mess that is currently required to get web apps to behave like desktop apps. (Nowadays Rails and friends are hiding most of this mess, but it's still there.)

Re: Boot a linux kernel right inside your browser.

#187

Post by mythz »

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…

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.

Re: Boot a linux kernel right inside your browser.

#188

Post by mythz »

podperson wrote: post #174
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…

I'd love to see something replace HTML, CSS, and JavaScript, but how would this be different from Java? We already have Java.

>> but how would this be different from Java?

It wouldn't suck.

Re: Boot a linux kernel right inside your browser.

#189

Post by rbranson »

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…

Seriously? the JVM? You listed the pros, but what about all the cons? Modern JVMs are fast, but highly specialized for long-running applications, which web pages are decidedly not. That's just the tip of the iceberg.

Re: Boot a linux kernel right inside your browser.

#190

Post by tectonic »

tlrobinson wrote: post #179
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…

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?
Post reply on HN