Slashdot Mirror


Pure JavaScript Unix-Like Web Based OS

slummy writes " JS/UIX 'is an UNIX-like OS for standard web-browsers, written entirely in JavaScript (no plug-ins used). It comprises a virtual machine, shell, virtual file-system, process-management, and brings its own terminal with screen- and keyboard-mapping.' If only you didn't need an OS to run the web browser on."

7 of 313 comments (clear)

  1. Site slashdotted by Underholdning · · Score: 5, Interesting

    The site is already dead, so here's something else - not a complete OS, but still has a (working) browser, games etc.

  2. Re:Uses? by Goaway · · Score: 3, Interesting
    Related to this (but much cooler), there used to be a site at WebOS.com where the site lauched a full-screen browser window and allowed you to interact with an entirely HTML desktop. Even the applications were downloaded on the fly, and the files were saved on the server.


    Shameless plug: I've made something similar here: http://wakaba.c3.cx/desktop-test/desktop.pl
    Log in as test:test. It's fairly useful for doing management of a web server. Try not to Slashdot it too badly, OK?

    Mor information here: http://wakaba.c3.cx/sup/kareha.pl/1116806324
  3. Lemmings! by Butterspoon · · Score: 3, Interesting

    For another really cool example of what you can do with JavaScript, click here.

    --
    pi = 2*|arg(God)|
  4. Re:SSH client? by Kent+Recal · · Score: 2, Interesting

    Well, actually you can get quite far with polling.
    As you said, latency will be hell (e.g. 2 sec), but the UNIX CLI deals surprisingly well with high latency links.

    Back in the day it was quite common to do stuff over 300bps links with high latency (probably rarely up to 2s but in the ballpark).

    So, first of all you'll decouple Input and Output.
    Instead of sending a char, waiting until the server echos it and printing it you will print the typed chars immediately and probably send the whole line on each poll (these few bytes are dwarfed by http protocol overhead anyways) so the server doesn't even need to "assemble" the line but just gets the whole thing everytime.

    This will basically give you "local" feel on the CLI and latency only kicks in when you actually need the server response (e.g. cycling through the history or firing the command).

    For interactive things (think: editor) it gets a bit more difficult since you actually depend on the editor telling you where to put the cursor etc.
    Even for that stuff there are plenty ways to optimize cuz, as said, people have been tackling the "slow-link" problem very exhaustingly a long time ago.

    Well, why anyone would want to spend all that effort when they can just use SSH is beyond me, tho... ;-)

  5. i crashed it by Anonymous Coward · · Score: 2, Interesting
    Awesome, i crashed it with a shell command that once caused a kernel panic in mac os x:
    [ted@mirrordot.org:2]$ mkdir foo
    [ted@mirrordot.org:2]$ cd foo
    [ted@mirrordot.org:2]$ mkdir foo
    [ted@mirrordot.org:2]$ mv foo ..
    it just died!
    1. Re:i crashed it by pluggo · · Score: 2, Interesting
      Heh... I took a cursory look at the source code, and I thought it had permissions...
      [guest]$ ls -l ls
      -rwxr-xr-x 1 root wheel bin/n.a. 2005/06/16 22:09:14 ls
      [guest]$ rm ls
      [guest]$ ls
      command not found: "ls"
      [guest]$
      It won't allow deletion of /etc/passwd, however... some kind of hardwired check I wonder?

      Whatever the case may be, it's still a very cool toy to play with. What I think would be a cool next step is to use AJAX and actually store data on the server... maybe I'll hack on it a little myself. Not that I could redistribute it... (the header of the sources says all rights reserved, copyright, blahblahblah...) but it might be fun.
      --
      Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to mak
  6. your first 8 words by Anonymous Coward · · Score: 1, Interesting

    Why all the restrictions? If you accept the single caveat that you've got an extra n hops before getting to the other end of your "socket" connection, where n = number of hops between you and your server, then you've got zero real hurdles to creating a "socket" and some sort of "socket" library that would look very similar to whatever you're trying to emulate. XMLHttpRequest is perfectly capable of presenting some encoded version of a TCP/IP packet which then web server host can then decode and send on it's way, relaying the resulting responding packets to the browser.

    I actually met the guy who first did TCP/IP through the water between subs. I think he'd agree that he had a lot less to work with.

    With that said, I _could_ run around dit-dah'ing everybody in an attempt to get the world around me to communicate in morse-code. But I probably won't.