Hacker News Reader

Comment by michaelbuckbee | Hacker News Reader

I realize it's super early, and this look interesting, but I'm unable to figure out if "cloud" in this case means:

- Runs in a Browser for the purposes of editing files locally

- Runs in a Browser and we have a whole backend way of spinning up a VM/Docker/something for you to do things with as well (The new defunct https://www.nitrous.io/ did this so you could do things like remotely run pg, your Rails stack, etc.)

Both are good/bad for different reasons, mostly just curious.

View on HN

There's nothing that prevents you from doing the first one, if for some reason you prefer working in the browser rather than in some Electron application. For fully local scenarios, it is expected that it will be able to work like a standard editor: you just launch it and work, you don't have to be aware of this frontend/backend separation.

The use case I am interested in is the following: at my company, code has to stay on central servers/infrastructure, you shouldn't clone it on your laptop. The only choices to work are either a graphical editor through a remote X session or a terminal-based editor, both having important shortcomings. Having a complete IDE (electron or browser) that edits files remotely be really nice in that situation.

How about emacs in tramp mode? Or even mounting the remote file system with sshfs and using whatever editor you had installed locally?

Theia does not only provide remote file access you also have LSP (language server protocol) for code-completion / docs ala eldoc , company) etc..

Almost all of Theia's features are based in the backend.

The emacs equivalent would be like having emacs in daemon mode and a tcp based emacsclient locally. (I wish that existed)

Also the idea is to have something a bit more modern and appealing to the mass of javascript/web devs out there.

Theia is still far from replacing emacs, but as an emacs user myself and a Theia dev I hope I can bring what I love about emacs to Theia :)

Theoretically, couldn't you use socat and ssh tunnels to proxy the emacs server to another machine?

So emacsclient/emacs deamon work with a tty, basically emacsclient opens a tty and sends it to the emacs deamon and it uses it to send output/receive input, so you really need to be local there's no way that I know to forward a tty on the network.

The local socket opened is used only for configuration between emacs and emacsclient see: https://github.com/emacs-mirror/emacs/blob/master/lib-src/em...

Just found out http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

So it seems possible with socat indeed, I'll have to give it a try :)

One problem that I see however is that emacsclient also forwards signals to emacs when the window changes size for example, I don't think that will work with socat

It's off-topic, but I just have to ask. Why? Why would local copies be disallowed?

To prevent someone to copy it all on a laptop and sell it for example.

That's completely ridiculous (and, unfortunately, also completely plausible with companies) - see the so-called "analog hole" (or in this case even digital - if it hits the browser as textual content).

Everything is relative, making it a bit harder may be worth it to some people and also maybe more detectable. But it's always possible of course.

There is still a big difference in terms of attach surface between a complete repo cloned in /home/$USER and some transient partial information that is gone (in theory) once you close the application/browser, so I don't see why it's completely ridiculous.

I doubt the code is that valuable, but if you don't trust your employees to not do that (seriously, nearly every other company trusts their engineers at least that much), then why did you hire them in the first place?

Do you mean "trust" as in trusting they don't have malicious intents, or trusting they won't be lazy or distracted sometimes? In this case I don't think it's the former, since nothing technically prevents an employee from cloning the repos and running away to a competitor. I think it's part of good security "hygiene" that helps protect you from yourself.

I guess it's a (perhaps debatable) security argument. If I leave my unlocked laptop unattended (but not connected to the VPN) in a public space, for example, then it makes it harder for a third party to steal that code. I'm sure you'll find one thousand counterexamples where it wouldn't help, but no policy is perfect.

But a more practical reason is that some legacy software is designed to be run on these company servers, it expects certain things to be at particular places, so you need to work on them. Again, this is not ideal (and we try to change that little by little when possible), but that's how it is right now.

I think the second, because of this line from the article:

"So you would build one application and run it in both contexts. Theia even supports a third mode, which is a native desktop app connecting to a remote workspace."

Which implies the browser version is connection to a remote workplace by default.

It's the latter, the backend process (that exposes the filesytem etc) can be anywhere and the frontend (browser or electron) will connect to it over tcp.

How you setup vms/docker or something is up to you however as long as the theia backend (nodejs) can run in it.

Reply on news.ycombinator.com