With apologies to Edmund Burke: Those who ignore GNU tools are bound to reimplement them as a webapp.
Assuming that the author had "pedagogical use cases" in mind, I'll have to ask: why not just a plain server with ssh access and screen w/ multiuser support installed? It's really hard to believe that it would take anyone more than 10 minutes to learn how to use screen to the point they can share a session remotely.
10 minutes? Really? I've found screen to have a huge learning curve. From inside screen, I have to keep looking up what the hotkeys are, and I can never remember the exact Control-A hotkey I'm after to operate it. Imagine teaching an entire class how to use screen, before you can even begin to touch on your real lesson material!
If anyone else is struggling with screen, I recommend launchpad.net/byobu, for a more humane/learnable/menu-based multiplexing program
I'm not saying you can be proficient with screen in 10 minutes. Far from it. What I did say is that, if I were somebody who wanted to teach and share a session with someone, I would put a page with the following instructions to Joe:
1) open a terminal
2) ssh joe.student@teacherserver.net
2.a) your password is "PASSWORD_FOR_JOE"
3) screen -x joe.session
What else does the student need to do, besides having a ssh client?
The service is way more than just a simple front for ssh. The fact that you can boot up a free instance, from anywhere, with access to various ports, means that you could theoretically:
Share files with a friend
Run a (sinatra web app? whatever) and get feedback on it for 20 or so minutes
Do anything that requires a few open ports.
And basically anything else you can think of. (of which, I'm sure I've only scratched the surface)
No I'm not joking. I'm not really sure why it seems like a joke. I agree SSH clients are ubiquitous. But ChromeOS probably will not have one. I'm not even sure you'll be able to get to a shell in ChromeOS without hacking it apart and keeping it from booting to whatever window manager runs the browser. But then you're just running a stripped down linux, which kind of defeats the purpose.
What I don't understand is how one can justify spending all this time to build one application that is an inferior, resource-hogging clone of a GNU tool that is probably older than him. And the only possible explanation that you could give me is "you could run this on ChromeOS"?
I don't mean to be rude, but it looks like you are saying the right things, but not stopping to wonder if it makes sense or not. Is it really that much of an advantage to have this "feature"? If all you have is a ChromeOS device, you are probably not the person who would need to have an Erlang REPL. And if you are that kind of person, you'll probably get a computer that runs an actual operating system, one that actually gives you a terminal and a SSH client.
I don't think you're being rude. You make a decent point about the likelihood of erlang repl users and chrome os users not overlapping too much. But I wasn't trying to suggest that the only justification for building such a tool is to have it available on something like chrome os. My statement was more meant to make people think about situations in the future where this might be useful, and to draw attention to how little you need to know to be able to use this. Pretty much everyone now knows how to use a web-browser. That's all I need to know to use runroot. I don't need to understand screen. I don't need to understand ssh (and install a 3rd party client if I'm on Windows). I don't need to have any erlang libraries installed. In order to share what I'm doing with others I don't need to make any assumptions about their environments except that they have a web-browser.
I know to you and me these aren't major hurdles. But we have years of experience and knowledge of these "basic" tools that most other people don't. So as a teaching tool for those without such experience this is great. Also I think you underestimate how much inertia needs to be overcome for most people to try something new. This drastically reduces the friction to trying out new languages.
Assuming that the author had "pedagogical use cases" in mind, I'll have to ask: why not just a plain server with ssh access and screen w/ multiuser support installed? It's really hard to believe that it would take anyone more than 10 minutes to learn how to use screen to the point they can share a session remotely.