Hacker News Reader

Comment by morpheuskafka | Hacker News Reader

Wow. This is going to be a major game changer for remote development work, and it's a perfect counterpoint to the "Electron is stupid just write it in C" that we hear a lot. Because of the flexibility provided by separating the Node-based logic and processing layer from the web-based presentation layer, VS Code lent itself well to this kind of innovation. Of course, browser-based IDEs aren't new. But they've always been a beast of their own; this will work seamlessly with the tight VS Code integrations numerous languages and frameworks have.

View on HN

Imagine needing the complexity of docker, browsers, vs code when a much simpler (and compared to this which is running in http? - secure) tool already exists :), ie

  ssh -X

No. The X protocol is objectively shit. It's so shit, modern toolkits don't even fully use it anymore. Instead they do all rendering locally and pipe the composited pixmaps over to the X server via DRI. Over a network, guess what? No DRI. Meaning uncompressed pixmaps get sent over that network link every time a redraw happens.

Wayland, Pipewire, and H.265 will be a much better general solution to remote desktop access. In the meantime, VSCode via browser is a MUCH better approach than trying to forward it over X over any but the fastest network links.

To clarify your statement about Wayland, it doesn't support remote desktop access in itself [1]. A remote desktop server would sit on top of Wayland.

[1] https://wayland.freedesktop.org/faq.html#heading_toc_j_8

I’d rather use the tooling of VSCode than ssh into some shoddy configuration of vim

> I’d rather use the tooling of VSCode

What they're suggesting allow you to do just that.

I tried that in the past and it's unusable over typical internet latency.

That's just a different kind of complexity to transmit interactions and UI rendering. It's built for much more general usage which is why it fails at a fine-grained low-latency coding experience on anything other than a LAN.

Yeah that doesn't really cut it for remoting over the internet into a VM in the cloud. As far as securing this it's as simple as tossing a few lines into your reverse proxy config.

Because there’s nothing simpler than X11, right!? Also there's no dependency on docker - that's just a demo.

X forwarding is not secure at all.

Over an SSH tunnel?

And impossible using Wayland

X forwarding is very slow. Some potential reasons are discussed here : https://superuser.com/questions/1217280/why-is-x11-forwardin...

I like X-forwarding in general, but VSCode and other electron-based apps really run like ass over remote X11.

Definitely not recommended.

Or simply mount a dir with sshfs or similar :)

No one remembers the "No Machine" NX protocol (X protocol with compression, without unnecessary roundtrips and some other optimizations)? I think I've tried it in the early 2000's, looks like they are still alive[0]

With version 4 of their protocol they went closed source, but before that it was released as GPL (don't remember if it was the case of their client/server, IIRC they were proprietary) anyway I think V3 is used in the X2Go[1] client/server. There was also a Goggle client in Python years ago...

[0] https://www.nomachine.com/

[1] https://wiki.x2go.org/doku.php/doc:newtox2go

I use x2go actively for all my servers. It is very fast, even over slow connections (much better performance then VNC and RDP used to have) -- thanks to great compression techniques (so do not expect 256 colours when connecting over GSM network). It is a lovely piece of (OSS!) software.

Nice to hear it's working well.

I found out today that X2Go version 4.1 is available on Debian Stretch via "backports"; I don't need it at the moment but if I'm bored in the future, I could play with it without much friction...

Can Nomachine/X2go run a server on a windows machine?

X2Go shouldn't work, unless you intend to run it on a VM or maybe the WSL as it's a modified Xorg X11 server, but probably it's not what you are asking.

NoMachine, according to their download page, should support Windos/Mac/Linux on the server front, but I don't have a direct experience.

Ten years ago, UltraVNC or RDP were the fastest remote desktop options for Windows. I also can recommend TeamViewer, despite it has a slightly different focus.

NoMachine runs on a Windows server. It accesses the remote desktop. But if what you want is a Terminal Server like NoMachine's Terminal Server for Linux, I think you'll be disappointed. That's not possible from a legal perspective.

I used it until a few month ago: it worked better (lower latency and no need to specify the resolution) than VNC but clion doesn't work well with NX, so I switched to VNC.

NoMachine essentially made themselves irrelevant by not upgrading their client software often enough, IMHO. I was using all sorts of VNC hackery to make it fast and loved NX, but it was weird and niche (never worked quite right on the Mac) and still slow when compared to RDP and Citrix, so the rise of Ansible and other sorts of automation blew it out of the water for server management.

For end-users, Citrix was just way better, even if more expensive, and there was no compelling reason to switch...

I'm a huge fan of RStudio server.

I splurged on an expensive desktop, while I'm using an old laptop with an i3 processor and 4GB RAM my brother gave me.

RStudio server let me work from the same R sessions, wherever I was, while giving me (high end) desktop performance for running simulations like MCMC, wherever I was -- from R.

I did similarly with Jupyter for Julia, but I always preferred Atom/VS Code. So my work flow, away from home, was using things like remote-ftp and ssh. But I can't seamlessly continue a session I had at home from my laptop. Needless to say, I am excited about this.

Looks good, but it's for R only, I guess?

Effectively. These days you can use a Python kennel in notebooks and get syntax highlighting, but not much else. Python and SQL are supported but second class use cases.

The new version (in preview) has better Python support:

https://blog.rstudio.com/2018/10/09/rstudio-1-2-preview-reti...

Yes, I was quite happy with reticulate, when I tried it.

I like the workflow of working on code in a script, with hotkeys to run code blocks in the REPL and jump to the next block. If I am actively working on code, I'm unlikely to want to run the entire file, but that is the default in Python for VS Code, for example. So in terms of quickly getting comfortable and focusing on the work, reticulate with RStudio worked well for me. I also like it more than Jupyter, unless you're making reports where mixing code with markdown and LaTeX is great -- although RStudio supports this too.

But I've also used a lot more R than Python, and am already comfortable with RStudio. For someone who hasn't used RStudio before, there's probably better options to jump into Python for data analysis.

I brought up RStudio Server in the first place because I find it to be convenient, and even use it at home in place of RStudio Desktop, so that I can resume the same session I left at home remotely on my laptop.

Code-Server looks like the equivalent of RStudio Server. While I still haven't tried code-server (still planning on it -- just haven't yet because I'm not used to downloading and running binaries I find online), it has those same benefits, and much broader language support. I am happy to see it.

Can you elaborate on the remote development use cases you have in mind? I struggle to see what makes this better than developing locally and pushing/pulling code via git or some other VCS.

My work involves a lot of smaller scripts that need to run on very large datasets. Git was impractical for the frequency of my pushes so I resorted to the old scp or ssh and paste to my workstation. With this I can streamline my whole process.

There are many cases where there is a desire not to have a company’s code base floating around on people’s laptops. For these folks remote development is a good option. It mitigates the risk of losing intellectual property.

My understanding is that much, if not all development at Google works like this. I don’t know their specific policy but a friend works on a similar project internally.

Google devs access the repo locally most of the time through a FUSE file mount. So the code is never written to local disk, but still accessible locally as far as you can tell.

(The other ways of writing code aren't publicly mentioned yet in any talks or papers that I know of, so I'll leave that one alone)

From the 2016 ACM paper.

> Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository

https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...

Scientific computing, specially when you'd like to do visualizations of data that is big/can't leave the server. It's also possible in Jupyter notebooks using port forwarding, but I don't see it for development involving data, as much as for data exploration or presentations.

I could see this being useful if you needed to get some work done and you don't have access to your usual development machine.

HIPAA - I want to be able to build data pipelines against patient data without the data itself leaving the server. Having my dev loop live on the same server as sample data is better than working against fake or synthetic data locally

Doesn't that just mean that the data is constantly leaving the server every time you run analysis on it? Or at least the reports on said data.

If the reports contain only aggregated or de-identified data (i.e. no PHI) then that is fine.

Aggregate reports are fine flying on and off. Individual-level data, exactly the opposite.

Potentially but not necessarily. Two thoughts:

1) I may not need to see the data itself during most (or all) of my dev loop, but just see any errors that are thrown.

2) Taken as risk mitigation, data temporarily cached in your browser is less risk than data permanently stored on your laptop, esp. when the threat you are mitigating is lost / stolen laptop.

Until recently I was stuck on a very locked down Windows machine (no vm, no docker, no admin rights..) while we target Linux on the cloud. The only way I could be productive is through remote development. We got macs and I still just develop remotely because the data in all in there.

I've used something like this in the past when working with tools that are difficult to host locally.

Why setup your codebase and all the dependencies to run locally on a laptop when you can just spin up an instance on a server that matches your production environment and remote into it to work?

I currently use a Windows 10 dev laptop because I use it for other non-development tasks (ex. Creative Cloud) that require Windows. So I'd already need to run in a VM. And then there's the issue of making SSL certs and setting the hosts file to capture our domains, and installing all the build tools. I've got a 1.5 Mbps connection with horrible latency, my server has gigabit fiber somewhere in NoVa. With this, I can throw up a remote IDE with high quality plugins on our dev server, which is just a low-spec clone of prod. I can do a docker system prune and rebuild everything from scratch in seconds instead of hours because the npm packages download instantly. And it helps to stop "non working code -- push to test" commits in our GitHub.

Another would be developing ARM code using native ARM toolchains on a SoC board.

> Because of the flexibility provided by separating the Node-based logic and processing layer from the web-based presentation layer, VS Code lent itself well to this kind of innovation.

Game Changer? Innovation? This sort of thing has been possible with x-windows for decades.

X forwarding is totally unusable over crowded, throttled, public WiFi or even good internet speeds with hardly any latency at all. The web is designed for those environments.

"browser-based IDEs aren't new. But they've always been a beast of their own; this will work seamlessly with the tight VS Code integrations numerous languages and frameworks have."

Yes, I evaluated AWS Cloud9 and walked away, because it was obvious that it could never compete with the ecosystems of the major editors. New tools and frameworks will keep coming, and proprietary cloud developer environments won't keep pace.

This project or Theia[1] look much more viable, if they can maintain enough compatibility with VS Code.

1: https://www.theia-ide.org/

Theia relies only on stable and documented APIs for compatibility which are not move fast and don't get removed, not on patching and exposing of VS Code internals.

Reply on news.ycombinator.com