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

51–60 of 100 posts

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

#51

Post by geocar »

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.

There are many alternatives to "fire-and-forget message passing" that JavaScript does, that don't require shared data structures or mutexes.

JavaScript can implement some of these alternatives with it's postMessage/onmessage combination, but it requires cooperation on both the sender and receiver which (in my opinion) is a limitation: The supervisor/operating system can expose just a little bit more information and it means the system isn't equally unresponsive anymore. Two that I'm thinking about are:

• Mailboxes. A process can post a message to a remote buffer and also check the fullness of that buffer so it can make other arrangements (e.g. scheduling another worker, letting the user know that the system is busy, etc). JavaScript can simulate this if both sides cooperate by implementing an ack-on-receive. UNIX allows detection of a full-buffer (EWOULDBLOCK). KDB publishes[1] the number of bytes in the output buffers which would also be preferable to what JavaScript does.

• Bulletin Boards. A process can simply publish information in a local buffer. Workers can then connect to pick up tasks. Again, JavaScript can simulate this if both sides cooperate, and implement a get/put system with postMessage/onmessage, and while this does represent a shared data structure, it's read-sharing which doesn't require any mutual-exclusion. You can also build it into a network protocol: My cexec[2] does this because load+network latency gives me free scheduling. Many mail servers also use this trick- one process writes to the queue directory, and workers pick up new work whenever they have time.

If you're interested in inter-process communication, Tanenbaum gave good writeup[3] on these methods (which I think are specifically relevant), and some other methods (which are useful in other circumstances).

[1]: http://code.kx.com/wiki/Reference/dotzdotW

[2]: https://github.com/geocar/cexec

[3]: http://www.amazon.co.uk/Modern-Operating-Systems-Andrew-Tane...

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

#52

Post by geocar »

Lerc wrote: post #38
Too wrote: post #35

Earlier quoted context omitted.

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

Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.

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

#54

Post by Too »

geocar wrote: post #51
Too wrote: post #35

Earlier quoted context omitted.

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.

There are many alternatives to "fire-and-forget message passing" that JavaScript does, that don't require shared data structures or mutexes. JavaScript can implement some of these alternatives with it's postMessage/onmessage combination, but it requires cooperation on both the sender and receiver which (in my opinion) is a limitation: The supervisor/operating system can expose just a little bit more information and i…

Good points, multiple workers on a single shared queue aren't exactly convenient with just a one way postMessage.

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

#55

Post by haylem »

callesgg wrote: post #46

I cant really see any good use cases. But WOW am i impressed that, is one of the cooler things i have seen on the web.

The French company behind XWiki did something like this called eXoplatform [1] and WebOS more than 10 years ago. Can't put my finger on screenshots or videos now but they must be lying around.

Still impressive, especially with the smaller footprint, but not exactly revolutionary or novel.

There was a time where every company wanted their own portlet framework and implement windowing in their apps (for better or, most of the time, way worse). Bunch of frameworks allowed to do that more or less easily too: ExtJS, GWT, Rialto...

[1] https://www.exoplatform.com/

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

#57

Post by Lerc »

geocar wrote: post #52
Lerc wrote: post #38

Earlier quoted context omitted.

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

Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.

I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript.

I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model.

http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.ht...

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

#58

Post by geocar »

Lerc wrote: post #57
geocar wrote: post #52

Earlier quoted context omitted.

Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.

I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript. I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model. http://lars-t-hansen.github.io/ecmas…

You can get a lot of mileage out of specialised solutions, and I suspect we'll continue to see those instead of a shared model; in an answer to your question about finding prime numbers, simply kill the worker and start another one with a new initial state.

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

#59

Post by millstone »

keithwhor wrote: post #50
callesgg wrote: post #46

I cant really see any good use cases. But WOW am i impressed that, is one of the cooler things i have seen on the web.

Always cool to see these in action, but multiple "online desktops" have come and gone since the mid-2000s. I personally built one myself in 2010 only to realize it had been tried and failed a few times. My next instinct was that to get attention and attract users I'd need a mobile-style UI. My instincts were wrong, and your gut is right. There wasn't a strong enough use case. The motivator for these projects is typic…

> The motivator for these projects is typically something along the lines of, "it would be great if there was just one OS or interface I could use on any device."

A lot of people do have this dream, but in practice it's horrible. The UI on my watch has to be very different than the UI on my flatscreen TV.

This notion that things will move to a web based environment because "engineers want to head towards elegant solutions" has two problems.

The first is that "what engineers want" doesn't matter in the least. We saw this with Windows 8: a single OS that tries to scale from tablets through workstations. That's an engineer's design and an engineer's dream, but users hated it, and Microsoft has since backed off.

The second problem is this notion that the web is "elegant." It has some nice properties, but it's layered hacks upon hacks. Demos like this are impressive because they work despite the web's limitations.

> The sooner we get to an OS just being a glorified web browser, the more we drive development spending way down and cut costs for the consumer.

This is frankly delusional. If web apps cost less, it's because they do less, or do it less well.

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

#60

Post by narrator »

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.

If you're going to do it that way, then might as well use jslinux[1].

[1]. http://bellard.org/jslinux/

Post reply on HN