Things like this remind me how much I love open source software. Choice is amazing shout out to all the contributors!

> I'm feeling like it is hard to find a simple GUI to just review a system and manage a bunch of containers and VMs.

Incus does all three through the same web ui

* OCI compatible "app" containers - with support for registries like docker.io and ghcr.io

* LXC "system" containers

* virtual machines with qemu + kvm

This is a built in UI? How do I access that?

Edit: so, this is the incus-ui-canonical package? It feels a bit ironic that canonical ships this, because I thought the whole point of incus was to avoid canonical and the direction they were taking lxd.

Thank you for this, I'll check it out.

Yes that is the package. It's just like the canonical ui for lxd, but it also supports the incus enhancements like OCI containers.

Very handy to generate yaml config for machines and viewing their console / terminal.

That's why I love Incus. It offers all three so you don't have to choose. OCI app containers, LXC containers and KVM.

Just like KIND runs containerd inside docker, you can also run dockerd inside containerd backed pods.

Start a privileged pod with the dind image, copy or mount your compose.yaml inside and you should be able to docker compose up and down, all without mounting a socket (that won't exist anyway on containerd CRI nodes)

To go even further, kubevirt runs on kind, launch a VM with your compose file passed in via cloud-init.

this is OpenClaw's docker compose yml - https://github.com/openclaw/openclaw/blob/main/docker-compos... . Arguably the hottest thing in the world right now. Mac Minis are out of stock because of this.

At no point, have I invented a new/better method. Perhaps your way is better.

I just recognise that Docker Compose is loved by most open source developers. And invariably any project you touch will have a docker compose setup by default. And it isnt going away, no matter hard anyone tries to kill. Some things are just too well designed. Docker Compose is one of those things.

I'm just making it possible to run those on kubernetes seamlessly.

This looks like OVA, firmware can be bundled inside along with additional disks, networking config, machine type and so on.

So essentially a virtual appliance package

The bigger the company the less impressive "senior" is. There are probably three levels of staff above it and then distinguished super fellow territory.

Hardly. Senior at Amazon is pretty prestigious. A Senior at Google is also a pretty nice title. In my experience smaller companies are more likely to give out the Senior title like it's nothing.

A senior software engineer can easily make $300-400K+ at BigTech that’s “impressive” enough to me.

On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.

For instance Delta

https://www.levels.fyi/companies/delta-air-lines/salaries

I loved playing this but could never figure out how to beat it

https://dos.zone/norton-commander/

Kubevirt has some examples passing a vpgu into kvm

https://kubevirt.io/user-guide/compute/host-devices/

Right, vGPUs are explicitly set up to generate BDF addresses that can be passed through (but require host driver support; they're essentially paravirtualized). I'm asking about MIG.

https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supp... says GPU passhtrough is supported on MIG...

In Shared NVSwitch Multitenancy Mode - are there any considerations for leveraging infiniband devices inside each vm at full performance?

We haven't looked deeply at inter-machine communication yet. NVLink/NVSwitch (which this post focuses on) are intra-node, so InfiniBand is mostly orthogonal I think and comes down to NIC passthrough, NUMA/PCIe placement, and validating RDMA inside the VM.