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

201–210 of 255 posts

Re: Boot a linux kernel right inside your browser.

#201

Post by guygurari »

rbranson wrote: post #189
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…

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.

Yes, seriously. In what sense are JVMs "specialized for long-running applications"? If you mean they start slowly, that's hardly the case even if you start from scratch:

   > time java HelloWorld
   Hello, World!
   java HelloWorld  0.28s user 0.06s system 135% cpu 0.248 total
In any case, the JVM is just an example (although I still argue it can serve this purpose well). My main point is that the "correct" model for the web is a bytecode-running VM inside every browser that lets you do everything javascript does through APIs.

Re: Boot a linux kernel right inside your browser.

#202

Post by dkersten »

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…

I've always wished that, instead of a "browser language", browsers exposed a LOW LEVEL bytecode environment (which browsers are then free to interpret, JIT compile or on-the-fly AOT compile at page load time). It should be reasonably low level, in that it should provide an abstraction from the hardware, but still allow for very efficient execution of lower level code. Then high level languages and frameworks could be layered on top. This way, browser languages would be 1) more efficient if they need to be and 2) more diverse.

Its a pity that javascript is so in-grained in client-side web now, as its really a terrible bytecode... Hell, failing the above, I would have liked to see Lua as the default client-side language, rather than Javascript (for reasons I will mention shortly), but of course that will never happen now that Javascript has been the default for fifteen years.

The reasons I would like Lua as the default language, besides the fact that LuaJIT is very fast (certainly for number crunching code, especially if you use the FFI to operate on low level structs (I mean, without calling into C) - the FFI is also one of, if not the, simplest FFI I've seen in any language[1]), it is, at least under my impression, a much more consistent language, while being just as flexible, easy to learn and dynamic. The thing I dislike most about Javascript is that it has lots of little gotchas and inconsistencies. Having said that, though, perhaps Lua does too and I just haven't used it enough yet to get bitten by them. Then again, it didn't take long for this to happen in Javascript, so Lua does at least seem to be a little friendlier.

[1] Actually, I think Factor's FFI is similarly simple, if my memory serves me correctly

Re: Boot a linux kernel right inside your browser.

#203

Post by neopanz »

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…

Agreed. And for those who pull the Java applet as the perfect counter-example, they need to ask themselves: does it take this long to start an Android app? Of course not! Because you can use the JVM in many different ways to eliminate the load time. In a way, one could imagine Android has a better example of how to mix OS/Web/Multi-Architecture(CPU)

Re: Boot a linux kernel right inside your browser.

#205

Post by guygurari »

powertower wrote: post #171
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…

>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…

The desktop has several limitations. First, you have to code separately for each platform because there's not even a common runtime, let alone API. Second, installation and updates are not seamless. Third, it is less secure since native code can have many long-lasting side effects, even without security exploits.

Web apps more or less solve all these problems (code can't be completely browser-agnostic, but it's close). Why not add also the benefits of desktop apps?

Re: Boot a linux kernel right inside your browser.

#206

Post by Aissen »

Aissen wrote: post #121
wesnet wrote: post #110

Earlier quoted context omitted.

compiling 2.6.38.6 ?

If you wanna know what I did: #from a 2.6.38.6 vanilla tree wget http://bellard.org/jslinux/config_linux-2.6.20 -O .config yes "" | make oldconfig # small edit in drivers/tty/serial/8250.c to copy Bellard's patch (http://bellard.org/jslinux/patch_linux-2.6.20) make vmlinux cp arch/x86/boot/vmlinux.bin /path/to/copy/of/jslinux/hosted/with/a/simple/httpd/ Edit: I just tried again with a 2.6.20.21 kernel using more or l…

Well the answer was simply in the technical notes: jslinux requires an FPU emulator in the OS, and in Linux it seems it was disabled after 2.6.20 for x86.

Re: Boot a linux kernel right inside your browser.

#208

Post by equark »

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 would agree, but watching the NativeClient talk at Google IO this year made me much less certain about the commitment. The presenter's answers to questions just seemed to suggest nobody was using it and Google/the developer didn't really care or expect anybody to actually adopt it.

Hopefully this was an inaccurate impression, because NaCl could have a huge impact on both the client and server

The best path to adoption would be for Google to very aggressively push NaCL as a Flash-like plugin. If they could get adoption -- through Unity3d on Facebook or something like that -- perhaps they'd win in the long run. If they just keep it part of Chrome it seems rather hopeless.

Re: Boot a linux kernel right inside your browser.

#209

Post by KonradKlause »

Aissen wrote: post #206
Aissen wrote: post #121

Earlier quoted context omitted.

If you wanna know what I did: #from a 2.6.38.6 vanilla tree wget http://bellard.org/jslinux/config_linux-2.6.20 -O .config yes "" | make oldconfig # small edit in drivers/tty/serial/8250.c to copy Bellard's patch (http://bellard.org/jslinux/patch_linux-2.6.20) make vmlinux cp arch/x86/boot/vmlinux.bin /path/to/copy/of/jslinux/hosted/with/a/simple/httpd/ Edit: I just tried again with a 2.6.20.21 kernel using more or l…

Well the answer was simply in the technical notes: jslinux requires an FPU emulator in the OS, and in Linux it seems it was disabled after 2.6.20 for x86.

2.6.23 boots also fine. x86 and x86_64 were merged in 2.6.24, maybe here support for 486 without fpu got broken...
Post reply on HN