p2004a
For me, it nails the convenience vs isolation aspect quite well, and I would like to get to a point where I can use it for all my development by default.
The main challenges that I still have, which none of the solutions I've found so far resolve, are:
- development of containerized applications, where e.g., docker/podman compose is used to bring up services
- development of GUI applications with hardware acceleration, like games (maybe security contexts for pipewire and wayland, like what's done in flatpak would be a good path?)
When I did my research in this space last time, https://litterbox.work/ was another option I've considered, and it is very nice too, but the friction is a bit higher than drop: it's slower to rebuild envs, lacks a "base" config, etc. Drop was much easier to adopt for me so far.
Bridging also didn't map all the discord functionality so it caused some confusion at times.
- All the code is GPLv2, MIT and other open licenses.
- Some assets are CC-BY-SA but there are also a quite a bunch proprietary ones
On the Recoil engine releases (https://github.com/beyond-all-reason/RecoilEngine/releases) page, we have had experimental Linux arm64 builds since March of this year.
Additionally, several people are trying to get the graphical pipeline and overall build working on Mac; you can follow their progress at https://github.com/beyond-all-reason/RecoilEngine/issues/936
The challenge with arm64 is that Recoil Engine does deterministic lockstep simulation using actual native floats for performance. Porting all of those operations (which were implemented using the mentioned library) to work on arm64 and produce the exact same bit-perfect results as on x86_64 has been challenging.