rd VS Vagrant

So, please please solve this request here: https://github.com/rancher-sandbox/rancher-desktop/issues/18...

https://github.com/rancher-sandbox/rancher-desktop/releases

Then in Rancher Desktop you enable WSL integration as shown here:

If using rancher desktop: https://docs.rancherdesktop.io/tutorials/working-with-images/ https://github.com/rancher-sandbox/rancher-desktop/issues/952

> docker desktop is pretty dead now that it's got restrictive licensing etc...

It would probably be nice to hear more about why you think this is! I've certainly heard of some having to move away from Docker Desktop.

However, at the scale where you need a license (250 employees or 10 million $ in annual revenue) it's not quite as big of an issue, especially at their current pricing per seat: https://www.docker.com/pricing/

> stick to standard open source tools like Colima etc...

Sticking to open source is a great idea!

I think mentioning that Colima runs on macOS and Linux only at the moment is also a good idea: https://github.com/abiosoft/colima

A large market share of the Docker Desktop installs are Windows in particular (since it's "the one way" how most install Docker nowadays, as opposed to not really needing a GUI or the supporting tools on Linux).

In another comment I mentioned Podman Desktop as a mostly viable alternative: https://github.com/containers/podman-desktop

Then there's also Rancher Desktop as well: https://github.com/rancher-sandbox/rancher-desktop

Regardless, it's nice to see reputable orgs behind the open source projects as well, which gives a bit more credence to their chances of surviving for the years to come.

Great, then can you speak to whether rancher-desktop supports the "--platform" argument to "run" the same way that finch does?

I wouldn't mind answering it myself, but it looks like rancher-desktop is an electron something or other: https://github.com/rancher-sandbox/rancher-desktop/blob/v1.6... and even downloading the 500MB release zip shows that there's `Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl` hidden in it, but I'm a distrustful sort and I don't want to crawl through unlimited lines of typescript to find out what this is going to do to my system

Maybe it's just that I'm not the right audience for this, since I am the polar opposite of "some gui fanciness," as I came up through the docker-machine universe, and now colima, and thus have a lot more comfort debugging CLI tooling when something inevitably goes toes up

Take a look at Vagrant! https://www.vagrantup.com/ In my admittedly limited understanding I believe it offers closer to a nix like reproducable rather than repeatable deployments.

on the off chance one hasn't been tracking it, there were several "we don't need your stinking BuSL" projects when this drama first started:

https://github.com/opentofu#why-opentofu (Terraform)

https://github.com/openbao/openbao#readme (Vault)

and I know of several attempts at Vagrant <https://github.com/hashicorp/vagrant/forks> but I don't believe one of them has caught traction yet

There are also some who have talked about an "open Nomad" but since I don't play in that space I can't speak to it

It sounds like you're using Nix as a sort of configuration management solution. CM just isn't worth it for managing a single desktop IMO. It triples the effort for whenever you need to add or remove a package, as you must now add that also to your nix configuration. You're supposed to be able to make that back up in time saved restoring to the next machine, but inevitably the next machine will be different enough that you'll have to edit it all anyway. In the end I just got tired of trying to manage my own machine with infrastructure as code (though in fairness I was using puppet at the time not nix).

I keep a git repository with all my dot files in it[1]. This seems to work the best. It has a Windows folder as well, and I copy that out whenever I need to set up Windows.

A lot of people like using WSL but I hate how it hogs on my memory. Hyper-V is a terrible virtualization engine for consumer-grade use cases because it can't thin provision RAM. If I need to use docker, I will spin up a small Linux VM using vagrant[3] with Virtualbox[4] and put Docker on there. Vagrant is an extremely underrated tool in my opinion, particularly in a Windows context.

I use scoop for packages. Typically I will scoop install msys2 and then pin it so that it doesn't get blown away by the next upgrade.

Then I basically do all of my development inside of msys2. I can get most things running in there without virtualization. In my case that means sbcl and roswell for common lisp, senpai for irc, and tmux and nvim for sanity. Msys2 uses the pacman package manager and this is good enough.

All In all, I set up my Windows machine affresh after a while of not using it and it took me about 3 hours. Most of that time was just getting through upgrades though, I felt like it was pretty fast.

1: https://git.sr.ht/~skin/dotfiles

2: https://www.msys2.org/

3: https://www.vagrantup.com/

4: https://www.virtualbox.org/

Tools like Docker and Vagrant can be used to allow local environments to mimic production environments.

There's an open issue [1]. A scripting interface has since been added [2], and updated [3], so there's progress.

[1] https://github.com/hashicorp/vagrant/issues/12518

Someone should fork and maintain Vagrant with an MPL open source license:

https://github.com/hashicorp/vagrant

https://github.com/hashicorp/vagrant/blob/v2.3.7/CHANGELOG.m... ?

The changelog lists both improvements and bug fixes and there's even apparently some effort to port it away from ruby: https://github.com/hashicorp/vagrant/blob/v2.3.7/internal/cl...

If you’ve ever encountered the dreaded “Vagrant fatal error: runtime BSDThread_Register error,” you’re not alone. This perplexing error message can be frustrating and confusing, especially if you’re new to Vagrant and virtualization. But fear not! In this article, we’ll unravel the mystery behind this error, explain its meaning, and provide solutions to help you overcome it.