Vagrant was fantastic pre-Docker and is still arguably more useful for certain cases, but I recall having issues running it last I tried. Based on the website, VirtualBox still lacks stable ARM64 support. Would "boxes" downloaded from the Vagrant cloud need to be built for ARM64 as well, or does it emulate?
It does not emulate. My org has been deprecating Vagrant ever since IT started issuing Apple Silicon as an option. Replacement is Docker Compose, or cloud VMs for software with heavy disk I/O.
Is there such a significant problem with disk IO going to docker for Mac over vagrant?
Now there is overhead for mounting local volumes into the container, but I’ve found them to be negligible on my Apple Silicon Mac’s in the last year or 2. (Apple seems to have been the one to fix it with their new virtualization framework which docker for Mac supports).
Now back when they first added their APFS file system things were atrociously slow when it came to Disk IO (as in 10x slowdowns or more) and there were various workarounds but it seems resolved to me now.
Do you know if Packer is still decent for building cloud AMIs? Or do you have any suggestion for building custom images that can run on cloud platforms as well as locally?
We use packer to build our images for all of Vagrant, Docker and AMIs (multi-arch) and push to the relevant registries. The packer side is probably ~100 lines of HCL, and allows us to have consistent images no matter where it's running.
It's a fairly simple tool in premise and does what's on the tin, would recommend.
I've been using devenv for new projects. I like it so far. Some might find nix (which it requires) to be overkill, but I think that's underestimating how devilish of a problem it's solving.
I'd be cautious about thinking that you'll be able to use it for complex projects without eventually needing to enter the NixOS rabbit hole. This hasn't happened to me yet on a project that I'm using devnenv with, but while using nix flakes I've found weirdness in nipkgs that I wanted to address.
On the other hand, the ability to put non python deps in a place that feels like a venv... feels pretty magical.
Yes for Python it seems to sit between a blurry midpoint of "just use Poetry!" and "just use a container!", but I can see it potentially being useful for a batteries-included devenv in more niche applications like Julia, Elixir, microcontrollers/development boards, etc.
There's also koding.com, which has been around for a while. I tried the service quite a long time ago because I used to find the "cloud coding" concept enticing, though it was definitely not as baked (probably due to Monaco not existing at the time, and likewise, browsers not being as good.) Nowadays I still feel like the user experience problems, limitations, and cost (when not subsidized) with coding this way largely make it a niche for people who have unusual needs. Especially because, there are tons of local options for reproducible dev environments, and they can continue to work without a network connection or on unreliable connections, something that is unimpressive even in the best conditions I've seen so far.
If you happen to have the exact set of needs that one of these products solve, then it can probably work fairly well. But, even when working on "web" stuff, I always find myself feeling like they're just never quite as good as just doing things locally. I feel like devcontainers and cloud coding in general are more impressive to those who haven't managed to tame their own dev environments and are seeing a solution to this for the first time.
It's also clearly useful for people on iPads and other devices that are either too low end to run/compile your code or arbitrarily limited to prevent it. However, with how powerful iPads are nowadays, it feels like if Apple ever allowed apps to use virtualization extensions, it would probably be a better solution for a lot of people who do not need a huge cloud workstation with a lot of RAM. I imagine your average Rails app or Go backend would just have no problem running directly on an iPad.
Daytona will be available as SaaS and self-hosted alternative to cloud-based development environments like Codespaces (also using devcontainer.json). It provides similar capabilities for setting up and managing development environments, but with the flexibility of hosting and managing the infrastructure yourself.
At CodeSandbox (https://codesandbox.io) we're also working on this! Main focus of us is that we're running the environment in Firecracker microVMs, which allows us to snapshot and clone environments very quickly. This enables us to create a VM for every branch, which comes with the added advantage that every branch automatically has a snapshotted preview environment that can resume in ~2 seconds.
Toolbox is not a developer environment, but rather a tool to provide 'a toolbox' to a container host, like the older Atomic, or CoreOS releases that are immutable. Dsitrobox is close to toolbox, but also not similar in providing a coder setup.
Toolbox seems pretty well suited for a console based development setup. It works as a simple wrapper around docker/podman which lets you build your dev environments using Dockerfile syntax which is very nice.
It is not really what DevPod provides as they connect a code-server, jetbrains, remote vscode, etc. Sure, 'Toolbx' can do that to; you can install vim, etc. We advertise toolbox as "interactive command line environments on Linux" foremost. DevPod offers this on Windows, MacOS, beyond the command line. as you said, it is just a wrapper around a 'special' (custom images can cause issues) toolbox container and podman. The tool they offer is much more streamlined to use providers; targeting different environments. Note: Member of the 'containers' group on GitHub/Red Hat.
- Gitpod, a SaaS competitor to Codespaces. http://gitpod.io
- Coder, which I guess is the more enterprisey self-hosted Codespaces alternative? https://coder.com
- This project, Devpod, seems to be a polished experience but not centralized like Coder.
- I recently stumbled upon Recode, which looks like a more indie take on the problem. https://github.com/recode-sh/cli