Up until now we’d been making do with docker-compose and JetBrains’s remote SSH dev; this should be significantly better.

Both .devcontainers and .devfile managed to create more effort than they took away. Some key points:

- long lived containers

- abstracting away the fact that you run stuff inside containers in the IDE and abstracting away the container life cycle

- cryptic error states and error messages, especially when setting up new projects from scratch. This often boiled down to bad plugins (even Microsoft's own VSCode plugins wet the bed often)

- only superficial support for podman

- bad support for arm based HW (and arch translation issues, like a tool requesting arm containers but the host running docker is x64)

At this point I consult teams to try out a plain compose.yml as a CDE and skip the "enterprise" stuff.

For devcontainers even the reference implementation CLI is significantly incomplete.

Looks pretty useable to me...

[0]: https://github.com/devcontainers/cli?tab=readme-ov-file#cont...

Does that require a static ip on remote?

I have skimmed the Jetbrain FAQ [1] and it says "no relay servers are involved"

[1] https://www.jetbrains.com/help/idea/faq-about-remote-develop...

You can use something like the following in your ~/.ssh/config:

    Host devhost
        ProxyCommand        aws --profile DevProfile ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartSSHSession --parameters "portNumber=22"

There were some headaches around the exact specifics since it wasn't designed for this, but I liked the idea of using skypilot to launch dev machines in the cloud since it has plugins to all the cloud APIs and so you don't need to manage a k8s cluster to launch a dev machine. Admittedly it worked better for launching a Jupyter server than a "full" dev machine, but a full dev machine seemed to be just a few ssh/vs code configurations away.

Are there any guidances for how to fix this?

We have many teams using GPUs with Coder for ML workloads but doing GUI/Game remote development where interactivity is essential remains elusive.

0. https://coder.com/docs/v2/latest/templates/devcontainers#dev...

The main downside I can see is that users have to write their workspaces for a particular deployment target. This would be a problem for e.x. open source projects trying to check in a workspace definition file of some kind. We standardize on Kubernetes across clouds and bare metal so it's not an issue for us, but it makes sense that it would be an issue for other use cases.

Devcontainer spec is probably more developer centric than Proxmox templates

I would guess with your Proxmox setup in a team setup, you'd need to assign a hostname/ip for different developers, where with Lapdev you have a single point of access.

Lapdev can proxy http traffic to the workspace containers with authentication, which makes it easy to preview things with security.

Lap dev looks like a much simpler tool

But you could have gotten your answer by just checking my profile. But no. I just use Proxmox to manage all of my infra: https://taoofmac.com/space/blog/2023/12/17/2000

Don’t assume people have business motives for stating technical facts - and don’t downvote because they ask pointed questions. There are good reasons for pointed questions.

But does it provide remote environments or local environments ?

And what's an environment in this context ? A Docker compose file and a .env? Code or vim settings ? A vm à la vagrant ?

It's installed on a remote server so it provides remote environments. If you use VSCode remote, then you can "open" it through VSCode remote ssh.

The environment that Lapdev provides essentially is a container (other format is on the roadmap) with things pre-installed as defined in Devcontainer(https://containers.dev/) format.

The way I'm hearing what you're saying is: Lapdev sets up a remote environment that I access with my terminal via SSH, and do editing in using something like VSCode running on my local machine, accessing the remote environment with something like VSCode's Remote-SSH extension.

So by using lapped I can replicate the remote environment I normally access through those things easily on remote servers and cloud services? Is that right?

To start with, I would suggest you to try VSCode Remote out with your own Linux box if you've got one, just to get a feel of "remote" development. You might like it or might not.

I haven't yet made the jump to remote/cloud development, I don't have a clear mental picture of how the pieces fit.

Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide?

Why do we need another layer on top? What am I missing?

If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this.

And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned.

It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode.

For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.

Thanks for the info.

Another angle is rent-seeking and locking you into a proprietary, expensive ecosystem. Big Tech has successfully convinced most companies to overpay by orders of magnitude for compute and bandwidth, but so far local development machines were excluded. This aims to tackle that shortcoming and make sure you enjoy all the "benefits" of the cloud even during development.

Devcontainer was created by Microsoft to support Visual Studio Code's remote development features, so it works best in Visual Studio Code. Inasmuch as other IDEs support it, that's up to the IDE vendor.

What about Linux? Or... the internet?

- Vagrant already supports VM or Container environments, and has a well defined system for building and distributing "base" boxes;

- Vagrant uses a Ruby file to define the environment, so it's much more powerful than a Yet Another Migraine Looming file.

Like I said, a `Vagrantfile` is ruby, so besides having all the power of Vagrant and its plugins, you can also just do straight up ruby stuff, or even shell out to do other stuff.

The remainder is AGPL, which many people (including myself) consider nonfree as well.

This immediately killed it for me. I need to install a Postgres server just to try out a tool? And if I recommend it to my team, do we need to run and maintain a Postgres instance?

OP- you are creating too much work for me. And don’t ask me to use your hosted version, the easiest solution is to use Vs code devcontainers