d.rymcg.tech VS singularity

> What if the docker daemon is on a storage server and the host volume of /stuff contains, say, 10 terabytes of photo album content?

In this extreme example I think probably a bind mount might make sense, especially if the files are already there. But the named volume would just be stored in /var/lib/docker/volumes/some-volume-name, so as long as that /var/lib has 10TB I don't see the problem.

I can use my sftp container [1] to be able to sftp directly into a volume, but I've not yet transferred 10TB with it :)

[1] https://github.com/EnigmaCurry/d.rymcg.tech/tree/master/sftp

yea, I've mostly come to the same conclusion, podman is a hobby, I can see its potention so I actively track it, but I I do mostly do stuff with vanilla docker and docker-compose, for single one-off installs, and k8s for bigger distributed stuff, either in a VM locally, or on a DigitalOcean dropet(s). I've been collecting my compose files [1]

[1] https://github.com/EnigmaCurry/d.rymcg.tech

Old Singularity repo: https://github.com/apptainer/singularity

This sounds exactly like Singularity http://singularity.hpcng.org/

never used it but a very popular example of a container is docker (that link says what a container is) and singularity just looks like another container flavour (maybe specific to HPCs?)

The re-exec pattern is not the only way you can solve this in Go. I actually rebuilt a container runtime from C to Go (for the HPC market) and we had to solve this problem. We did it by essentially forking before any Go code gets run. Here’s the code for the main binary that actually spawns the container process. It’s half C, half Go. https://github.com/hpcng/singularity/tree/master/cmd/starter