asciinema VS toolbox

> https://github.com/asciinema/asciinema-server

and

> Web player for terminal session recordings

It's not mine, it's asciinema, lol. I tried finding it, but fell short, look around here https://github.com/asciinema/asciinema-server/tree/develop/assets/css.

I've used the script command and asciinema [1] before. Easy way to record steps without missing anything.

[1] https://asciinema.org/

You're welcome! I just stumbled across another one that looks promising, too: https://asciinema.org/

Check out https://asciinema.org, a tool for recording terminal commands.

These days I reluctantly prefer embedding a static screenshot in my READMEs with a link to an asciinema animation. They're easy enough to record, and at least I'm not costing some poor sod who accidentally loaded my page $0.10 to download a giant GIF on mobile data.

I you'd like to know what it is like to use Podman, I've found those Asciinema snippets by Matthew Heon (Podman contributor) quite helpful: https://asciinema.org/~mheon

I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx".

https://github.com/89luca89/distrobox

https://containertoolbx.org/

It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop.

https://podman.io/

There is some challenges related to usermode networking for non-root-managed controllers and desktop integration has some additional complications. But besides that it has almost no overhead and you can have unfettered access to things like GPUs.

Also it is usually pretty easy to convert your normal docker or kubernetes containers over to something you can run on your desktop.

Also it is possible to use things like Kubernetes pods definitions to deploy sets of containers with podman and manage it with systemd and such things. So you can have "clouds of containers" that your dev container needs access to locally.

If there is a corporate need for window-specific applications then running Windows VMs or doing remote applications over RDP is a possible work around.

If everything you are targeting as a deployment is going to be Linux anything then it doesn't make a lot of sense to jump through a bunch of hoops and cause a bunch of headaches just to avoid having it as workstation OS.

I'm really, really happy with my current setup of Fedora immutable + toolbox [0]. This tool lets you create containers that are fully integrated with the system, so you have acces to the entire Fedora repos, can run graphical apps, etc. while still having everything inside a container in your home directory. That means no Flatpak required. Highly recommended.

[0] https://containertoolbx.org

Seems like toolbox is also in this space; https://github.com/containers/toolbox

With Silverblue the core repos are very similar to what you'd have on regular Fedora. With more of a philosophical shift about where you're supposed to install things from. The idea being that the base OS is immutable and you keep it fairly minimal - even though you are technically free to install any of Fedora packages to it. And then you install user applications through Flatpak and toolbx. Where these more user space focussed applications are installed to your home directory and are sandboxed away from actual access to your OS. With iOS/Android style application permissions like "Give app permission to access camera" and "Give app permission to modify files in home directory". Allowing you even further customise the sandboxing of applications. Do you really want that app to have access to your microphone?

I'd probably try running it on the host system first. If you want to use your nvidia gpu inside toolbox, you would indeed need to install the drivers in the container: https://github.com/containers/toolbox/issues/116