There really should be not that much of a power or performance difference. Also, docker is essentially a “cgroup” and network namespace technology too, just like systemd-nspawn and lxc.
Like you said, in a sandbox you can control the version of docker installed, but unfortunately, that also means you are responsible for the version of docker installed, ie you are responsible for updating the entire sandbox os and docker, which is fine, but when using the electric eel docker support, you don’t have to do that, and the updates will come with system updates.
In a sandbox you have better isolation… ie its perhaps easier to install docker on a bridge network and have it be completely separate to the host… but the corrallary is that you then need to mount datasets into the sandbox, and then into the docker containers… you can by pass that layer on Eel’s docker… but of course, that means that you lose that protection too
You don’t necessarily have to set each capability that the docker requires from the sandbox because the docker is running with full root privs on Eel… agains… swings and roundabouts.
Both methods of running docker work just fine on Eel, and there’s no urgency or even requirement to migrate out of a sandbox.
At the end of the day, its probably simpler for new users to avoid the sandbox, unless they want to do something which is easier in a sandbox.
And one of the purposes of the video is to show how simple it is to migrate… but also… that you don’t have to.
Well, you can use the nvidia graphics just the same in the docker compose script… there will be enhanced support in the apps I believe, and there is no need to pass the graphics drivers into the sandbox
It seems that IX is planning to have nvidia graphcis drivers be updated separately to the base OS
It should actually be simpler on Eel than in a Sandbox to use graphics acceleration in docker.
