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

211–220 of 255 posts

Re: Boot a linux kernel right inside your browser.

#211

Post by shawndumas »

plasma wrote: post #54
rickard wrote: post #27

Earlier quoted context omitted.

I guess a tun/tap to some server-side service might be possible too, but perhaps not very interesting. The x86 dynamic library api suggested in the tech notes sounds more useful. Edit: Easier idea might be adding ttyS1 and connecting that to a websocket on the server. Combined with something like socat or ppp, that ought to work. Since the console is already ttyS0 and connected to the js terminal, it might be doable…

Maybe power the network using a server side relay script and an ajax request?

WebSockets?

Re: Boot a linux kernel right inside your browser.

#213

Post by dkersten »

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…

Qt Quick with its QML environment (UI markup + Javascript + native extensions if you need them) is a great middle ground.

It seems that the plan for Qt 5 is to move the enitre Qt toolkit over to the "QML first" model - that is, QML becomes the default way to create interfaces, for both mobile and desktop apps, and native widgets are only used when you require them. They also want to better integrate webkit and web content. In a recent Qt desktop app of mine, I was already doing this: QML + webkit + native backend for the heavy lifting and it works very well. Be awesome to have it as the default in all environments.

FWIW, I think QML/JS would have made a greate HTML/CSS/JS alternative.

Re: Boot a linux kernel right inside your browser.

#215

Post by Lerc »

equark wrote: post #208
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 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 adopt…

I think it may be a bit of a problem being a project from Google. Making the system totally secure is a difficult task. That is true for all sandboxes. People find vulnerabilities, people fix the holes.

The problem is not that NaCl is insufficiently secure, but any vulnerability will be spun as "Google making your system insecure". I think an independent group doing the same thing would be no more or less secure, but wouldn't have the baggage that would come from being seen as a component of a much bigger entity.

Re: Boot a linux kernel right inside your browser.

#216

Post by xilun0 »

limmeau wrote: post #69
neopanz wrote: post #45

Earlier quoted context omitted.

Great idea. That guy deserves it. Though I suspect he would be too modest to accept the money since he GNUed all his creations.

In the days before KVM, he wrote a paravirtualization kernel module for QEMU (kqemu), gave away binaries and tried to sell the source. I don't know what happened with that business.

Yes he wrote that.

Indeed he also wrote QEMU.

Re: Boot a linux kernel right inside your browser.

#217

Post by xilun0 »

terminus wrote: post #17
rickard wrote: post #11

Earlier quoted context omitted.

Implement emulation of a network card... ;) The tech notes page states that "there is no network emulation at this point".

Yeah. That would be a whole interesting can of worms. Would need PCI/USB/whatever bus your ethernet card was on. Plus emulation of the selected ethernet card itself. Loopback (which is present) is so much simpler.

Or you can write a simple paravirtualized eth card driver and its implementation side, without trying to emulate real hardware. Linux is free software, take advantage of that.

Re: Boot a linux kernel right inside your browser.

#218

Post by xilun0 »

dcposch wrote: post #138
SomeIdiot wrote: post #109

So any interesting ideas for what this can be used for?

It might be useful for CS education. I have a bit of experience with this as a course helper in the introductory (CS106 series) CS classes at Stanford. I think it could be a very cool platform for assignments in CS107 (where students are introduced to Unix and C programming) or CS110/CS140 (the core OS classes). Instead of ssh-ing into a locked-down cluster computer, students could boot a machine in their browser and…

Why would you want to use QEMU for CS140 and an inferior solution for CS107?

Re: Boot a linux kernel right inside your browser.

#219

Post by rbranson »

guygurari wrote: post #201
rbranson wrote: post #189

Earlier quoted context omitted.

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

If you're just suggesting that we need to ship a common bytecode to browsers, then I agree.

Re: Boot a linux kernel right inside your browser.

#220

Post by xilun0 »

danvet wrote: post #153
jokermatt999 wrote: post #139

Earlier quoted context omitted.

Crashed Firefox portable 4.0.1 for me. What's the intended result?

Iirc the way to reboot an x86 machine is to triple-fault, i.e. execute an interrupt in an interrupt in an interrupt. Could be done by e.g. marking the pagefault handler's stack space as "not available" in the pagetables. Now if the virtual cpu does not implement that reboot behaviour, the likely result is just an endless recursion of fault handlers. So the script runs an endless loop, hanging Firefox until it notices…

argggggg Might have been an interesting way to proceed because of various weird reasons 15 or 20 yeats ago, but current x86 plateforms are not that convoluted (for at least 10 years). Just outw (or is it outb? don't remember) the correct value to port 0cf9h (which btw has nothing to do with the legacy PCI conf addr register, which is 32 bits starting at io port 0cf8h for great confusion...) and your computer reboot.
Post reply on HN