Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

os.js: JavaScript Cloud/Web Desktop Platform

os.js.org

Post reply on HN
Print view View original

31–40 of 100 posts

Re: os.js: JavaScript Cloud/Web Desktop Platform

#31

Post by Lerc »

plaguuuuuu wrote: post #28
narrator wrote: post #24

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

It certainly looks as if each app lives in its own process of sorts - check the 'process viewer' I'm sure they could use some sort of thread/process implementation with a scheduler to do stuff. Speculation, each program could be compiled to some sort of bytecode, use asm.js to implement the guts of the thing, etc. When you think about it, a single-core machine is "single threaded" as well, you just need some interlea…

A single core machine can multi thread, but without a timer interrupt it's hard work. What can JavaScript do to provide an interrupt short of emulating a processor with an interrupt via some form of:

  while true() {
    do an instruction;
    check for interrupt;
  }
It's not an efficient way to go.

Re: os.js: JavaScript Cloud/Web Desktop Platform

#33

Post by desdiv »

Lerc wrote: post #29
narrator wrote: post #24

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else. I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it u…

The single thread limitation is caused by the global interpreter lock[0] that's common to most interpreted languages. Along with JS, it also appears in CPython and Ruby MRI, the reference implementation of Python and Ruby respectively.

[0] https://en.wikipedia.org/wiki/Global_interpreter_lock

Re: os.js: JavaScript Cloud/Web Desktop Platform

#35

Post by Too »

Lerc wrote: post #29
narrator wrote: post #24

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else. I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it u…

I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equally unresponsive as as web worker not picking up messages. The alternative to message passing would be shared data structures and mutexes, not very nice.

Re: os.js: JavaScript Cloud/Web Desktop Platform

#36

Post by [deleted] »

batmansmk wrote: post #30
gedrap wrote: post #2

While it looks like a nice exercise in front end JS, and looks cool, does it solve any problems? Do users actually need some more abstraction layers on top of Google Drive / Dropbx, etc? Either I am getting too sleepy, or they didn't provide any actual use cases in the homepage. It provides some sort of API ("simple, modilarized and flexible JavaScript APIs so you can easily make changes, extend functionality and cre…

A few use cases: 1/ Make a modular backoffice for CMS based website. Make an app to manage users, an app to manage content, an app to upload and manage gallery of media etc. 2/ Make a distributed OS. All services can scale and use backend power beyond what a single node can provide. If you need to burst in the cloud due to a heavy process for instance. 3/ Could use it to provide a separation between the OS and the GU…

[deleted]

Re: os.js: JavaScript Cloud/Web Desktop Platform

#37

Post by witty_username »

batmansmk wrote: post #30
gedrap wrote: post #2

While it looks like a nice exercise in front end JS, and looks cool, does it solve any problems? Do users actually need some more abstraction layers on top of Google Drive / Dropbx, etc? Either I am getting too sleepy, or they didn't provide any actual use cases in the homepage. It provides some sort of API ("simple, modilarized and flexible JavaScript APIs so you can easily make changes, extend functionality and cre…

A few use cases: 1/ Make a modular backoffice for CMS based website. Make an app to manage users, an app to manage content, an app to upload and manage gallery of media etc. 2/ Make a distributed OS. All services can scale and use backend power beyond what a single node can provide. If you need to burst in the cloud due to a heavy process for instance. 3/ Could use it to provide a separation between the OS and the GU…

> 4/ What about reducing the cost of HW it needs to run? Chromebook style.

How so? At least for me the window moving is slightly laggy and is probably going to worse on low-end systems.

Re: os.js: JavaScript Cloud/Web Desktop Platform

#38

Post by Lerc »

Too wrote: post #35
Lerc wrote: post #29

Earlier quoted context omitted.

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else. I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it u…

I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equally unresponsive as as web worker not picking up messages. The alternative to message passing would be shared data structures and mutexes, not very nice.

A pre-emption mechanism would be able receive the message and respond. At the very least a response of "I'm busy" is better than no response that could be for any number of reasons.

Shared data structures would enable this, and while you may not think they are very nice, I would prefer a not very nice solution to no solution whatsoever. I have seen discussions on various mailing that indicate that shared data structures will be implemented in some manner.

Look at the example number crunching worker given in the spec. https://html.spec.whatwg.org/multipage/workers.html#a-backgr...

    var n = 1;
    search: while (true) {
      n += 1;
      for (var i = 2; i
How would you implement this worker in such a way that the host page could call

  worker.postMessage( {"command": "startfrom", "value" : 131071} );
to get the prime calculator change it's search point?

Re: os.js: JavaScript Cloud/Web Desktop Platform

#39

Post by meowface »

Lerc wrote: post #31
plaguuuuuu wrote: post #28

Earlier quoted context omitted.

It certainly looks as if each app lives in its own process of sorts - check the 'process viewer' I'm sure they could use some sort of thread/process implementation with a scheduler to do stuff. Speculation, each program could be compiled to some sort of bytecode, use asm.js to implement the guts of the thing, etc. When you think about it, a single-core machine is "single threaded" as well, you just need some interlea…

A single core machine can multi thread, but without a timer interrupt it's hard work. What can JavaScript do to provide an interrupt short of emulating a processor with an interrupt via some form of: while true() { do an instruction; check for interrupt; } It's not an efficient way to go.

This is just an event loop, no?

Re: os.js: JavaScript Cloud/Web Desktop Platform

#40

Post by tlrobinson »

desdiv wrote: post #33
Lerc wrote: post #29

Earlier quoted context omitted.

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else. I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it u…

The single thread limitation is caused by the global interpreter lock[0] that's common to most interpreted languages. Along with JS, it also appears in CPython and Ruby MRI, the reference implementation of Python and Ruby respectively. [0] https://en.wikipedia.org/wiki/Global_interpreter_lock

That's not the reason.

As I understand it, the GIL is an implementation detail of certain interpreters that prevents threads from running on multiple OS threads (and thus multiple CPUs).

JavaScript has explicitly chosen not to support preemptive multithreading at all (aside from Web Workers which don't share memory), while Ruby and Python do have it, even if it can't fully utilize multicore processors.

Post reply on HN