Boot a linux kernel right inside your browser. • Hacker News Board

Re: Boot a linux kernel right inside your browser.

#171

Post by powertower » Tue, May 17, 2011, 6:00 PM UTC

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 software and browsers, but personally I'd like to keep them apart.

Re: Boot a linux kernel right inside your browser.

#172

Post by adambyrtek » Tue, May 17, 2011, 6:14 PM UTC

vixen99 wrote: post #135

StavrosK wrote: post #72

Earlier quoted context omitted.

I would think he'd be a patent office clerk...

But do you think he'd be passed over for promotion until he 'fully mastered machine technology'? http://en.wikipedia.org/wiki/Albert_Einstein

Judging from his performance review, there's definitely room for improvement :)

http://norvig.com/performance-review.html

Re: Boot a linux kernel right inside your browser.

#173

Post by nupark2 » Tue, May 17, 2011, 6:16 PM UTC

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…

> 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 applications multiple times for disparate, proprietary mobile platforms.

I already lived through that on the desktop. The only reason I haven't embraced the web for application development is that the technology stack is, by comparison, hobbled.

> Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.

Treating the browser as the sacrosanct temple of HTML, CSS, and JavaScript is throwing away the limited opportunity browsers have to pre-empt Android and iOS as a first-class, standardized application platform.

Re: Boot a linux kernel right inside your browser.

#174

Post by podperson » Tue, May 17, 2011, 6:35 PM UTC

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…

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

Re: Boot a linux kernel right inside your browser.

#175

Post by powertower » Tue, May 17, 2011, 6:35 PM UTC

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…

I am not able to apprehend the kind of confusion of facts and ideas that could provoke your statements.

1. The function of the desktop, the browser, and the mobile is not the same thing.

2. Desktops have not failed, as you claim, in sandboxing/security/virtualization; (especially when compared to browsers).

3. Turning the browser into the desktop (low level APIs), is in turn re-implementation of the desktop.

Re: Boot a linux kernel right inside your browser.

#176

Post by azakai » Tue, May 17, 2011, 6:38 PM UTC

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 agree that for CPU emulation, something low-level like typed arrays is absolutely necessary.

However, with more high-level code, in general there shouldn't be such a need. For example, RPython is very high-level, but is compiled into very efficient C. The same could be done for JavaScript (and to some degree already is).

Re: Boot a linux kernel right inside your browser.

#177

Post by onewland » Tue, May 17, 2011, 6:40 PM UTC

phaedrus wrote: post #149

cygwin98 wrote: post #134

Earlier quoted context omitted.

Great hackers can use whatever languages/tools they like. The fact that they're being great is not the consequence of the tools they chose, but of the masterpiece work they achieved. I am always fond of such an analogy: in terms of efficiency, the greatest hackers has an algorithmic complexity of O(1); meanwhile, the majority of us may be O(n), if you can manage to get a O(log n) you can make into the club of good ha…

Close but I think you have your orders understated. A normal programmer faces O(n^2), while a great programmer achieves O(n log n). Really bad programmers do O(k ^n) amount of work to achieve the same, with k>2.

Why k > 2? k > 1 is bad enough. Otherwise, recursive fib(n) would be just fine (O(~1.618^n)).

Re: Boot a linux kernel right inside your browser.

#178

Post by [deleted] » Tue, May 17, 2011, 6:45 PM UTC

powertower wrote: post #175

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 am not able to apprehend the kind of confusion of facts and ideas that could provoke your statements. 1. The function of the desktop, the browser, and the mobile is not the same thing. 2. Desktops have not failed, as you claim, in sandboxing/security/virtualization; ( especially when compared to browsers). 3. Turning the browser into the desktop (low level APIs), is in turn re-implementation of the desktop.

[deleted]

Re: Boot a linux kernel right inside your browser.

#179

Post by tlrobinson » Tue, May 17, 2011, 6:48 PM UTC

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 applications soon after.

http://blog.chromium.org/2011/02/native-client-getting-ready...

Re: Boot a linux kernel right inside your browser.

#180

Post by VMG » Tue, May 17, 2011, 6:55 PM UTC

SomeIdiot wrote: post #109

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

Off the top of my head, this seems to be one possibility of having something like a persistent development environment. I could fire up vim, the server could store the environment and I could easily write code from every place with a decent browser.