I also started doing this, but using containers locally (on a Mac). The ability to have a set dev environment without needing to install local programs or compilers is great. And really once you flip to this model, it doesn’t matter if you’re running your dev in a container or remote VM. So long as you can get a command line to your dev environment, it really doesn’t matter where it is.

(Or who hosts it)

Though I like this model, the problem with dev containers on macOS is that the disk io is bog slow. This makes some IO heavy tasks (pip install, npm install) painfully slow.

I have started to run some dev tasks on a remote Linux server, with Dockers, and then just configured automatic file sync on save over SSH.

> This makes some IO heavy tasks (pip install, npm install) painfully slow.

Aside/HTH: The new Yarn has "Plug 'n Play"[1]. They claim that committing [their version of] node_modules is a reasonable thing to do, so that's one way to avoid install entirely. I don't trust that claim, yet (it smells like noisy diffs). You can instead re-enable the global cache[2], and then mirror your host cache directory into your container (whatever `yarn cache dir` gives you).

I have tried none of this myself because I'm not working on anything JS right now. pnpm[3] is what I've been using up til now, and is also a direct upgrade in terms of speed (but I suspect it won't work with mounting host directories).

[1]: https://classic.yarnpkg.com/en/docs/pnp/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/

Very true. It really depends on what the workflow is. But once you’ve already moved to a disconnected dev environment, moving from a container to remote server is a small step.

I've never used Docker. Is this sort of like using tmux/vim on a cloud server?

I'm guessing that VSCode has a distinct back-end and front-end. It's able to run the back-end server on the remote machine/container/whatever over a bog-standard SSH tunnel. Any autocomplete functionality, debugging, etc. will use the resources on the remote machine. It also does port forwarding for you. The front-end (GUI) runs on your local machine.

A closer analogy would be using Plan9, and mounting most of your cloud machine locally. Vim would then just be your local front-end into those mount points.

Containers/docker add the ability to share your exact machine configuration with someone else, and have them create their own copy of it with a single command. It would be almost like sharing a VM image with your team. There's been a lot written about the pros/cons of containers, but they achieve similar goals to VMs, and so-happen to bring a lot to the table in this scenario.

I'm not sure why you're being downvoted, that's a very good question. The short answer is yes*, plus some automation around spinning up a new session.

The wrinkle is that the display server is running on your local machine, and connecting to the thread of execution on the remote server. Vim doesn't really have that concept of separating view from control, but tmux does play a somewhat similar roll.

It is hard when you have millions of commits, thousands a day, and your monorepo is measured in gigs.

VS Code remotes are magic. I use a light version of it for 100% of my development on windows with WSL, but I also use it to log into a mac server and edit files on that.

I have no idea what actually went into developing the feature, but I would have to suspect that Electron would have contributed to making the separation of an app client vs server easier than something totally "native".

So how do you edit media files, using some ssh fuse mount magic ? What happen when you need to work from a shitty internet network ? In train ?

> So how do you edit media file

This only does code. You'd probably have to do those locally and SCP them over or, yeah, some mount magic.

> What happen when you need to work from a shitty internet network ? In train ?

You'd have to commit your work, but you'd be able to bring the environment up on your laptop. There are still merits to this, such as the repeatable nature of containers. Depending on where you've worked, you may have been through the hell of a huge list of setup steps when on-boarding a project: that's one thing that containers are really good at automating.

You may not be the target audience, though.

> this only does code.

VS Code remotes allows you to drag and drop files from your desktop and they're placed where you want them in your remote environment. I don't understand why this would be any different.

You edit media file in an editor?, wouldn't you just upload it? You can drag& drop into vscode and probably find the path to the tmp folder and work off that too.

oh right, my home lab server, that must be around here somewhere...

They aren't as expensive as you'd expect[1][2] ($70-$200). Hell, you could use a RPi for many use cases.

In my case, my homelab is my laptop (which I connect to from my desktop). I don't actually have a server blade lying around (although those can also be relatively cheap when big cloud upgrades their servers).

[1]: https://www.ebay.com/sch/i.html?_nkw=dell+optiplex+3040+micr... [2]: https://www.ebay.com/sch/i.html?_nkw=intel+nuc&_udhi=200&_ud...

I pay 30$ a month for a server (yes, a virtual one, if you want docker, you have to pay a bit more) with org-domain and tls cert. I would recommend that to every developer. Yes, some administrative work is required but that is also a valuable learning experience. You would own all the tools that you need to develop efficiently.

Personally I use Gitea, which should be usable by someone used to Github. I don't switch workspaces too often, but I am sure some tools are available.

I have an HP 4u from 2010 with 80 threads and I think a quarter TB of memory, 6 SAS, and 2 1TB ssd, currently running Ubuntu 16 and Wok, for VMs. It took a lot of effort to get this working and it's still a huge pain - I have no UPS for it since it uses 220VAC, and UPS cost more than the server cost me, for example.

I can't use docker in general because my internet is too crappy. That was annoying in 2012 when I first used it, but it's even worse now. I've always worked with VMs, since 2001 or earlier - virtualbox, wok, AWS, wok, and now proxmox.

It helps to know what your use case is, I don't run a ton of VMs, just one or two at a time that can use almost all of the resources of the server, and I generally do infrastructure and computing work in general.

I presume none of this counts as a homelab, though, since I don't program in rust.

> It took a lot of effort to get this working and it's still a huge pain

You make an attractive case it for! :) Yeah, this is why I don't have a "home lab".