Boot a linux kernel right inside your browser. | Hacker News Reader

Boot a linux kernel right inside your browser.

bellard.org

1,820 pointsneopanz239 comments

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 by the emulator.

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. Efficiently supporting high-performance, high-complexity systems such as an x86 emulator (or a video game, or custom font rendering, or even an application framework) absolutely require efficient low-level APIs.

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

Factor, Racket, and Lua all have ffi's that are very easy to use. I've never quite liked Lua's metaprogramming, though (macros are very useful when you're writing bindings.) and my least favourite Lua quirk would be the lack of integer types - both other languages have fairly sane (and performant!) numeric towers.

That said, I'd give a higher priority for the language in my browser to be safe: some kind of correctness guarantee would be nice. Or even, while we're at it, some kind of way to analyze the script and say "this script GETS from urls x,y, and posts data d to z"

Standard Lua may not have integer types, but as far as I know, LuaJIT does actually support integer types under the hood. At the very least, you can force it by declaring an integer using the FFI, eg:

    local ffi = require("ffi")
    int = ffi.new("int")
    int = 10
    print(int)

I also don't find the lack of macros in Lua as limiting as I do in other languages. For example, if I wanted to create an EDSL in Lua, I would have it parse a string at startup. For example, imagine a state machine DSL:

    fsm = my_dsl[[
        start: foo
        stop:  quux
        foo -> bar
        foo -> baz
        bar -> foo
        baz -> quux
    ]]{ foo = function()
            code for foo here
        end,
        bar = function()
            code for bar here
        end,
        baz = function()
            code for baz here
        end,
        quux = function()
            code for quux here
        end
    }
    fsm.run()

As a real-world example, here is some Lua code I'm using in a hobby game project:

    DEFINE(Traits.Position)[[
        float x;
        float y;
        float z;
    ]]
    DEFINE(Traits.Movement)[[
        float x;
        float y;
        float z;
    ]]
    DEFINE(Behaviors.do_movement){
        input={Traits.Position, Traits.Movement},
        output=Traits.Position,
        frequency=0.01,
	
        -- Update entities position
        fn = function (pos, mov)
            local delta = dark.timedelta
            new_pos = Traits.Position.new()
            new_pos.x = pos.x + (mov.x * delta)
            new_pos.y = pos.y + (mov.y * delta)
            new_pos.z = pos.z + (mov.z * delta)
            return new_pos
        end}

    -- Create a sample entity
    local entity = Entities.new()
    entity.add(Traits.Position, {1.0, 0.0, 0.0})
    entity.add(Traits.Movement, {0.0, -1.0, 0.0})

"That said, I'd give a higher priority for the language in my browser to be safe: some kind of correctness guarantee would be nice. Or even, while we're at it, some kind of way to analyze the script and say "this script GETS from urls x,y, and posts data d to z""

I definitely agree with the above.

> Its a pity that javascript is so in-grained in client-side web now, as its really a terrible bytecode...

Gilad Bracha complains about this at http://gbracha.blogspot.com/2011/03/truthiness-is-out-there....

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

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.

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.

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

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

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.

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.

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.)

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)

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.

"Applets run in their own area on the page and can't interact with the rest of the page like javascript does."

You can actually call methods in a Java applet from Javascript and vice-versa. It just doesn't seem to be used very much:

http://download.oracle.com/javase/tutorial/deployment/applet...

You seem highly optimistic about the JVM's appropriateness here. In reality what the browser needs is something more like the Dalvik VM, which is designed for compactness, efficiency, and multi-process models.

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.

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.

Seriously? .28s is 280 milliseconds, for a result with zero content. That is already at the outside acceptable threshold for being perceived as slow response, and that's before we spend any time at all rendering the page. Certainly a VM of some kind could boot faster, but milliseconds count.

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

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.

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

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

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

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.

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.

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.

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.

Well, that would be the plan :-)

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.

We've used QML in a recent QT/C++ desktop app and it's performance is comparatively poor compared with WebKit rendering and its CSS subset support is woefully inadequate.

The HTML/CSS/JS dev model is fine as it is, there's no need to hope for nirvana grass-is-greener frameworks that don't exist. Learn HTML5 like the rest of us.

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?

In theory, someone could create a common bytecode as a library. Such a library would probably use the Relooper algorithm from Emscripten (https://github.com/kripken/emscripten) and JIT the bytecode to Javascript that can then be eval'd for near Javascript-level speed.

The whole idea is to get better performance than current JavaScript interpreters allow. Making something slower than JavaScript is the opposite of why people want a common bytecode.

It can be implemented first on Emscripten to see if people like it; later it can be standardized.

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).

Can you explain the steps necessary to combine a JS x86 interpreter with a binary Linux disk image into a running VM?

The part I don't understand is, what environment does the Kernel need to think is there, and how is that done in JS?

This is explained well in the Technical Notes section of the site.

http://bellard.org/jslinux/tech.html

I saw that, but I don't understand how it's booted.

From what I can see from the minimized JS, it:

- Loads the linux binary and the root memory disk image into 'memory' at the expected addresses (0x100000 and 0x400000, respectively)

- Sets the interpreted x86 CPU's EIP to the kernel's entry point

- Initializes additional requisite register state

- Starts execution.

Take a look at load_binary() and start() functions.

[edit] rickard already discussed this here: http://news.ycombinator.com/item?id=2555552

After FFmpeg (used in all your TVs and gadgets, very likely), QEmu (used also by Xen and VBox and other), tcc and his IOCC entries, the DVB-T emission with an ATI card, Fabrice comes, once again with something crazy...

He is really impressive...

Don't forget that he discovered the fastest known algorithm for computing an arbitrary digit of pi. If you ever are tempted to get egotistical, just think of this guy. If you are prone to low self esteem, avoid reading about him.

And still, he has normal job in a normal company... Not in a start-up or not in a mega-tech-corp...

Perhaps he's able to produce great stuff like this because he has a normal job in a normal company.

It isn't so much the "normal" company thing, I think, as having a good work/playthings/life balance. The main reason none of my personal/toy/experimental projects are languishing on note paper or electronic equivalent is that my balance is very wrong and getting worse!

He is presumably working for a good company (or at least one that is good for him) and has time management skills himself.

That, and a brain to be envious of plus a supply of inspiration!

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

which company is that?

He works for Netgem (http://fr.wikipedia.org/wiki/Netgem).

No more excuses, I'm going to finish those damn projects I have on the backburner...

Seriously, who does Bellard work for?

He seems to leave virtually no trace (other than awesome software) on the Internet. I googled the shit out of him tonite...

"He seems to leave virtually no trace (other than awesome software) on the Internet."

Probably because he spends his time writing awesome software.

He works for Netgem.

Take a look at his IOCCC entry in 2001/02:

OTCC is an Obfuscated Tiny C Compiler for i386-linux. It generates FAST! i386 32 bit code (no bytecode) and it is powerful enough to compile itself. OTCC supports a strict subset of C. This subset is compilable by a standard ANSI C compiler. OTCC compiles, assembles, links and runs C code without the need of any other program.

http://www0.us.ioccc.org/2001/bellard.hint

(Note for those not familiar with the IOCCC: This is done in 2048 bytes)

Whatever happened to IOCCC? Last update was they announced an announcement due a year ago; nothing since.

So pg was wrong, the greatest hackers don't use Lisp, they write in (and invent) obscure versions of C all day.

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 hackers. The tools, be it OS, programming languages, etc, are only a constant coefficient to that complexity, i.e., they can make you noticeably more efficient, but they won't improve your "greatness".

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)).

Because 1.00000000000001 ^ N is not bad for most values of N that you will actually use.

One of my favourite hackers is an academic who creates languages just for fun.

Pity me - I work in pretty much the same role as Fabrice in one of his company's direct competitors...

Any Macarthur Grant folks floating around here? Take note! That's an impressive resume.

Wikipedia says you have to be a US citizen or resident for the MacArthur grant. As far as I know he's French.

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

That does not necessarily imply modesty, there is another MacArthur grant winner who GNUed all his creations... http://en.wikipedia.org/wiki/Richard_Stallman#Recognition

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.

According to the Wikipedia page, you need to be a US citizen or resident to be eligible. He seems to be residing in France and I doubt he has a US citizenship. Otherwise, he definitely fits the bill.

damn it they should take mine and give it to this guy . i just can not believe what my browser can do . what the f k!

Searching for "tcc" and "tcc unix" returns nothing helpful.

Searching for "IOCC" returns nothing, and "IOCC Fabrice" returns a site that is caching HN in realtime, and it's your post.

Any help?

It's IOCCC. He's Bellard.

http://www.google.com/search?q=site:ioccc.org+bellard

There you go: http://bellard.org/

I'm utterly dumbfounded. Not only does it boot, it's got emacs, and a compiler.

  Welcome to JS/Linux  
  ~ # emacs test.c
  ~ # cat test.c                                                                                                                                                 
  void main(void) {                                                               
      printf("Hello World!\n");                                                   
  }      
  ~ # tcc test.c -o hello                                                         
  ~ # ./hello                                                                     
  Hello World!

[Edit: just realized that there is already a 'hello.c' in the directory that shows just this with better diction.]

adduser works (except you need to create a /home directory)

cd /bin for binaries. I just tried telnet, but fails as "no network"

If you start the httpd you can telnet HTTP requests by hand.

and VIM !

I don't see vim in there, but there's a minimalistic vi.

Looks like it's part of busybox.

I just forkbombed my browser. Nothing is sacred anymore.

  ~ # f(){ f|f & };f
  sh: can't fork
  sh: can't fork
  sh: can't fork
  sh: can't fork
  ...

Fabrice is one of my all time favorite software engineers. Reading his code, studying his methodologies and learning by copying has been a long time task for me.

My first encounter with his code was QEmu, when it was required to run the XO OLPC linux images. Society truly benefits when people like him are devoted in support of open source software.

Fabrice Bellard is truly impressive. There's a nice article about him, called "Fabrice Bellard: Portrait of a Superproductive programmer", here: http://www.softwarequalityconnection.com/2011/03/fabrice-bel...

Another:http://www.freearchive.org/o/55dfc9935a719fc36ab1d1656797273...

Unbelievable, this is like magic. I am totally impressed. It is a real linux instance. BTW. I see the hello.c file someone mentioned here. Have we all mounted the same disk image?

I see so many use cases for this, but I don't fully understand what is going on behind the scenes. Maybe someone can shed some light on it:

  1) How is the disk emulated. Is it a local image, or is it running on the backend?

  2) Is there a remote possibility to get the networking up and running?

  3) Can the disk image be externally accessed to be customized?

1): The disk doesn't seem to be emulated; it's just a rootfs in RAM.

2): See another thread here.

3): Check out cpux86.js. In the start() function at the very end, the following section might be enlighting (even though it is a bit obfuscated by a javascript compressor):

  function start() {
  [...]
    If=32*1024*1024;
    ya.phys_mem_resize(If);
    ya.load_binary("vmlinux26.bin",0x00100000);
    Jf=ya.load_binary("root.bin",0x00400000);
    start=0x10000;
    ya.load_binary("linuxstart.bin",start);
    ya.eip=start;

The files vmlinux26.bin, root.bin and linuxstart.bin are fetched from the server.

Thanks for the info. I got it running locally with those bins you mentioned. There is currently no further backend action.

is linuxstart.bin the bootloader?

This is completely awesome. When I saw http://cb.vu a few years ago I thought hey, someone has finally done it, but that turned out to be a hack. Kudos to Bellard once again.

Nitpicking: the terminal emulation is messed up. It keeps resizing horizontally, and less gets confused. I'm sure the terminal emulator was fun to play with. A correct vt100 state machine implementation [1] would probably not be quite as fun [2]. There's a vt100.js library used by a couple projects that might improve things. [3]

[1] http://vt100.net/emu/dec_ansi_parser

[2] http://vt100.net/emu/vt500_parser.png

[3] http://fzort.org/bi/o.php

Indeed, this is completely awesome. I first thought it was some remotely hosted virtual machine, but it really runs inside the browser. Insane! Especially considered how fast it is.

When he adds X, we can run Firefox inside Linux inside Firefox inside Linux :')

Edit: seems the terminal emulator supports ANSI escape codes such as the 16 Linux colors, but not the XTerm 256 color mode (\e[38;5;CCm) or Konsole 24 bit (\e[38;2;RR;GG;BBm). Guess it could be easily added as it's HTML.

Interestingly, you can run Firefox inside of Firefox... just enter the url: chrome://browser/content/browser.xul

why??

Because XUL is rendered with gecko.

> When he adds X, we can run Firefox inside Linux inside Firefox inside Linux :')

Skip the middle man, output gtk via html5 http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-upd... (I don't actually know if it still has dependencies on X11 :P)

That would be even better. One could make a Linux device driver to directly access Canvas, WebGL, or even the DOM. It seems that in my post I used "X" as a generic name for "Linux graphics" which is pretty short-sighted.

Gecko's GTK backend has dependencies on X11, if that's what you were asking about.

No network connection yet either :(

~ # ifconfig

     lo   Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0    
                               
          UP LOOPBACK RUNNING  MTU:16436  Metric:1    
                          
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0  
                  
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0    
              
          collisions:0 txqueuelen:0                              
               
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B

This would require a server-side component, as the browser has cross-domain limitations and couldn't generate arbitrary network traffic anyway. You could tunnel through websockets, however.

Sadly my dreams were also crushed when I discovered that lynx wasn't in there.

However, wget is there, so all the building blocks are in place.

As far as I can guess, any networking implementation would have to pass low level requests through a proxy on the server, which would end up making things pretty slow even on an unburdened server.

> When he adds X, we can run Firefox inside Linux inside Firefox inside Linux :')

Reddit has a meme for that. ;) (downvote away, I've earned it!)

HN would appreciate if you left reddit at reddit.

The Esteban one?

"I don't always write Linux Kernels"

"But when I do, it's in browser hosted Javascript"

The "yo dawg".

or the INCEPTION for that matter :)

There's a port of urxvt to JavaScript: https://github.com/paddymul/rxvt-js

I just tried out my ansi_colours.sh [1] script and it mostly worked. A few notes:

wget is available, and it would be cool to piggy back the linux network stack through the browser.

cut & paste support is a must for any terminal

The space characters are very narrow. Needs to be monospace.

All fairly minor compared to the coolness of this.

[1] http://www.pixelbeat.org/scripts/ansi_colours.sh

And you are very proud of your Javascript templating library.

I admire Fabrice a lot, he is a programming hero for me. However it is not true that he is not interested in money, for instance the QEMU module performing the run-time code translation to go fast was not released for free in order to earn from this. I don't know if he managed to earn or not from QEMU in the end, but IMHO that of selling the module to final user was not the right strategy, when QEMU was started and became famous, "virtualization" was an huge buzz and interest for many companies, so many ways to make money from this.

Also this new code is not released under a free license, so by default as far he is not sure what he's going to do with the code the "open source way" is not the default. This is not a critique. I think Fabrice Bellard is a genius, but as an observer he seems interested in making a profit from his work like many other programmers.

Instead subjectively I've to admit today I no longer consider the GPL a completely free license, but this is another matter and may be related not to earning but to the meaning "free software" has for you. For me it is as simple as letting people to do everything with your code. IMHO the BSD license turns out to be better both for users AND for you to earn from your product later.

I think you should replace "making a profit" to "making a living" off his own work. Just because he's a genius does not mean he hasn't every right to monetize his own works as he sees fit.

Monetizing OSS is hard and a lot of the time the possible revenue streams are a time-suck. He may not be interested in spending his own time and prefer just instead to licence his work as-is the norm for software producers.

From all I've read he's more than happy to receive invitations for licensing of his work, whether or not he'd accept a lump sum to Open Source some of his work is not known. Anyway this is all speculation, if you're genuinely curious you should email him (which is active as I received a reply from him today :)

He has remained independent doesn't work for academia or any mega-tech corp and continues to pursue his own interests. I think he has every right to carve out his own path and produce software as he sees fit.

GPL has no restriction on selling code, RMS earned his living money by selling reel tapes of code when GNU was first founded.

I doubt that's what he means. Regardless, very few people would pay for code like that now that the web is ubiquitous.

The emulator code is just 86 kb, and it isn't even aggressively minified!

http://bellard.org/jslinux/cpux86.js

I love how it begins with "use strict";

If it doesn't work for you on Chrome 12, this is probably the reason: "it does not work with Chrome 12 beta. As far as I know, it is a bug in the browser"

From http://bellard.org/jslinux/tech.html

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

3 days. See http://bellard.org/jslinux/tech.html , linked from the page source.

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

Not long ago:

Last-Modified: Mon, 16 May 2011 21:14:50 GMT

This is the most amazing thing I've ever seen in my browser.

I just did 'rm -rf /' then ctrl+D on the terminal. Kernel Panic! Very nicely done! Technical notes here http://bellard.org/jslinux/tech.html

Cloud VPS in the browser. ("Please standby while we create a browser tab for your new instance...")

"The browser as the operating."

Someone must buzzword the hell out of this and then create a new startup based on it.

~ # tcc -o hello hello.c

~ # ./hello

Hello World

That is just too impressive for me to process.

My favorite bit:

# cat /proc/cpuinfo

...

f00f bug: yes

Hah!

20 bogomips by the way, at least on Chrome on a MacBook Pro.

I sense a whole new era of browser performance testing..

Okay, I take that back. My favorite part comes from the tech notes, when he lists all the stuff he added:

[... and] my unfinished but usable emacs clone QEmacs.

?!? I am wasting my life in comparison to this super-hacker.

Further update: qemacs works.

Unfortunately, M-x spook does not, so he clearly still has some work to do for feature completeness.

Esc-x works for me.

For the curious: http://www.rcollins.org/ddj/May98/F00FBug.html

I'd be curious to know if this is was intentional, or a side-effect of the emulation.

Linux on 32-bit x86 assumes the F00F bug on any Pentium CPU, and jslinux emulates a 586.

Heh, I get 'Illegal instruction' when I compile and run:

long main = 0xc8c70ff0;

That used to crash my old Pentium box.

I don't know why it's so amusing, but the network stack is fully functional for loopback. Fire up telnetd, and telnet back to yourself. telnetd -l /bin/sh -p 23 telnet 127.0.0.1 23 plenty of other services: httpd.. what a hoot.

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;
  }

    ~ # cat over.c
    main () {
            int i = 0x00ffffff;
            while (i > 0) i--;
    }
    ~ # tcc over.c -o out
    ~ # time ./out
    real    0m 13.58s
    user    0m 13.57s
    sys     0m 0.01s

I love this stuff.

>"I did it for fun, just because..."

Easily the best hack I've seen on HN.

Any volunteers to wrap a websocket transport in an network interface driver? :)

What are the high-level steps for writing a driver?

It even has an incomplete version of Emacs. Emacs!

And Vi of course ;)

He had to write Emacs somewhere.

When fabrice opens the browser, the kernel compiles itself.

If anything deserves a HackerNews circle jerk, this is it.

Feel bad to miss out on this as I am on FF 3.6. But this remind reminded me of a service from a long time ago. Dont remember their name, this was some 10 years ago. But they used to provide a KDE desktop via the browser as a java applet. It was not terribly snappy, but quite surprisingly usable. Any one remembers this ?

With Guacamole (http://guacamole.sourceforge.net/) you can run a VNC session in Javascript, so you can have your desktop, but alas this still needs a remote (virtual) machine running the desktop.

Hmm if network emulation was added to the javascript VM you could combine it with this.

You can build your own custom Linux distribution, run it in your browser, and share it with others using http://susestudio.com/ — it might not be what you're thinking of (as it's only a few years old, not 10 years), but it does what you mention (and more).

Is there a reason you're still on 3.6, if I might ask? 4.0 is a _much_ better browser....

Fabris should put donate button on the page! I would happily donate to thank him for his great contribution to the Open Source and pushing boundaries of what possible to do with modern technology. thank U Fabris :)

Anyone know how to get the network working? ping/wget don't work. But seriously, this is pretty flippin sweet!

You can't - Javascript can't generate arbitrary network traffic like that. You'll have to wait for someone to write a driver for /dev/json, I guess. ;)

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.

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 even with the obfuscated source.

How complicated is virtio (http://wiki.libvirt.org/page/Virtio)? It's designed for guests that know they're virtualised.

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

WebSockets?

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.

"ping 127.0.0.1" works :)

Now I can buy a Chromebook :-)

Gets stuck at "Freeing unused Kernel memory: 124k freed" on my Cr-48...

Getting the same thing on Google Chrome 12 on Ubuntu 9.04.

Didn't know about this guy! Unbelievable track record of consistently releasing groundbreaking software. Oh, and the x86 js emulator is cool too! made my day!

Anyone know why he used 2.6.20 ? I tried compiling a 2.6.38.6, but it doesn't boot. It's stopped at "Starting Linux" and CPU stays at 100% all the time.

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 less the procedure showed above: it works! So it must be something with more recent kernels (scheduler ? dynticks ? merging of i386 and x86_68 arch in x86 ? something else ?) that is not emulated by jslinux.

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

Anyone else wondering if they're now part of this guys compile/render farm!?

  ~ # httpd
  ~ # telnet 127.0.0.1 80     
  get / http/1.0

  HTTP/1.0 404 Not Found                                                          
  Content-type: text/html                                                         
  Date: Tue, 17 May 2011 20:10:52 GMT                                             
  Connection: close

  <HTML><HEAD><TITLE>404 Not Found</TITLE></HEAD>                                 
  <BODY><H1>404 Not Found</H1>                                                    
  The requested URL was not found                                                 
  </BODY></HTML>                                                                  
  Connection closed by foreign host                                               
  ~ #

Coolness!

There is EMACS TOO!!! This is insane. I am going mad with happiness. I really really have tears in my eyes.

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 get root access. No setup, no configuration. Everyone gets an identical setup, which would be really nice for the people making the assignments. The main thing people would need is a way to save files to a persistent disk. Maybe a filesystem driver could be added that uses HTML5 Local Storage, or talks to a web service running on the class website?

Incidentally, students in CS140 are already using Fabrice Bellard's software. You write most of a very simple Unix kernel, testing and running it in QEMU.

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

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.

Neat. You can mount sysfs like so:

  # mkdir /sys; mount -t sysfs /sys /sys

That would allow you to look at the emulated hardware that is present. Looks like only virtual devices are present -- ram, loopback network etc.

Makes sense to me. The MVP here is cpu emulation.

How is this thing loads the kernel? I've read the http://bellard.org/jslinux/tech.html but it doesn't say, Does it loads it over the net or what?

It downloads a kernel image (and a disk image) over the network (open the developer tools in your browser and reload the page, you will see 3 .bin files of 1~2MB being transferred)

I'm sad the source has been compressed so there's no easy human-readable View Source, like there was on the VAX emulator that came up a few weeks ago. :( Still awe-inspiring, though. :)

Paste the source at http://jsbeautifier.org/ - It makes the source readable

Thanks both of you, jsbeautify extension now installed. :)

https://chrome.google.com/webstore/detail/kkioiolcacgoihiiek...

Chrome dev tools now have pretty print built in. Probably need dev channel.

Just copy-paste it here: http://jsbeautifier.org/

92.3 KB minified for the two JavaScript files.

wow!

Actually I thought about doing the same via LLVM and Emscripten. This seems like he emulates x86. Which is probably less hackish but also slower.

boots in firefox on android although you can't type anything. I am amazed

Awesome

    cd /
    rm -rf ./*
    echo *

If you have a programmers.stackexchange.com account, you might want to put a vote in here: http://programmers.stackexchange.com/questions/47197/are-the...

I tested the JS/Linux with google chrome 12 (beta and gnu/linux) with a new vmlinux26.bin and root.bin compiled using the 2.6.30 kernel with buildroot and work as expected (fine).

I don't know what is the problem of the original 2.6.20 linux kernel with JS/Linux but with this new compilation work perfectly.

Twice as fast in Firefox as in Chrome.

How long until you see the prompt?

http://www.softwarequalityconnection.com/2011/03/fabrice-bel...

I saw this and thought "how does it know who I am?":

io scheduler cfq registered (default)

This is hot! Needs logging facility too but otherwise I'm blown away!

This looks awesome! I'm just starting to learn ruby and was going to look today on whether there was a way to run it in a browser very easily. Wonder if this is the answer

http://tryruby.org/

Yeah try ruby is a great start. Just need the same interface not just in lesson form to allow you to create Ruby on Rails applications

For Python there exists such a thing, Skulpt ( http://www.skulpt.org/ ). It emulates the Python VM in client-side JS.

This is somewhat more direct than using Python in Linux on a JS-based emu.

I think the Ruby equivalent to that would be HotRuby. http://hotruby.yukoba.jp/

No.

wow, it is projects like this that get the imagination going and makes you feel bad for putting off a problem set that might have frustrated you at the time.

Can i run Node.js on this?

/evil grin

Can I run this in Node.js!?

Should be able to run it in PhantomJS if you need something headless. http://www.phantomjs.org/

Awesome - so could you run a web-server from within the browser? Would it be possible to connect to an instance of jslinux remotely?

Woohoo! Kernel panic! Haven't seen one of those in... well... forever. (Newbie here)

Edit: This is damn cool.

Could someone write a program that would cause a stack overflow, compile it with tcc, and run it?

Why is it that whenever I play with a temporary Linux install, I always end up typing "rm -rf /"?

This reminds me of http://uni.xkcd.com/

Now let's mass-email Bellard to coax him into publishing an open-source version. :)

this can be a good tool to for students to learn basic linux commands

/usr/bin has many goodies

vi, top, ps, grep, awk

A more advanced version would allow to use old DOS PC software such as games.

well I'm sold.

there's naclbox: http://www.naclbox.com/ for google's native client.

I believe this submission got the highest number of upvotes in HN history.

Looks so similar to Linux booted on an embedded device. Nostalgia.

What license do you want use to publish this job???

I mailed him about it earlier, he says he hasn't decided on a license yet.

Thanks.

I expect a response with a lot of emotion.

Josep.

now I'm wondering how hard it would be to write a commodore 64 or nes emulator in javascript to embed games in webpages?

Well, It's a great way to try out rm -rf /

Fun command to use:

reboot -f

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 this and stops it.

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.

First thing I did after booting?

    alias ll='ls -lh'

but not in my android browser apparently

interesting!

this is some crazy shit

The page was near-unreadable for me because the CSS uses the font stack "courier,fixed,swiss,sans-serif", and courier is just too thin and wispy against a black background. I opened Firebug and changed the CSS declaration to be "monospace" and then all was right with the world.

That said, it's a phenomenal achievement, and should be a great way for websites to demonstrate command-line tools to people. :)

(also: browsers let you store more information with DOM Local Storage than you could in a cookie; If you could expose that to Linux as a block device...)

  ERROR: your browser is too old to run JS/Linux.
  You should use a recent browser such as Firefox 4.x or Google Chrome.

No, it isn't. Stop using user-agent matching and start using JavaScript feature detection instead.

It does. It tests for ArrayBuffer support, outputting that message if the necessary constructors aren't found. What browser are you using that you expect to be supported? (Safari doesn't have support for ArrayBuffer, but a recent WebKit nightly does, and this runs in that).

Even in that case the error messages is still wrong. My browser is up to date, it just does not support the needed feature(s).

I believe Opera does not support typed arrays either.

I get that error with Opera 11.10

http://nightly.webkit.org/

I downloaded a webkit nightly from here, and it works now. Also, of note, the nightly picks up all my Safari settings, so it's not too much of a pain.

Yeah, its a poorly worded error message for anyone running the latest version of Opera

Reply on news.ycombinator.com