Continuing the discussion from The storage type 'wasabi' is not supported:
Thanks for finding that. But could someone with a faster brain than mine help me figure out the exact benefits (and possible downsides) of running duplicacy autobackup rather than duplicacy proper?
One advantage is obviously that it will run on any device that supports docker, regardless of whether @gchen provides binaries for that device or not.
But what else?
That’s pretty much the only reason: To avoid compiling golang compiler for the unsupported OS/CPU.
This can get annoying very quickly: to build duplicacy you need to have golang. But to build golang you need golang. So oops. You’ll have to build old golang version that was written in C first, and then build the current one with the old one.
Which means you need to be able to get or build GCC and all dependencies needed to build golang 1.4 on your target platform.
In other words the only reason to use the container is to avoid boot-strapping golang and possibly gcc.
Otherwise, if you have working go compiler for your target — there is absolutely no benefit in using docker for duplicacy specifically: Golang programs are complete self contained executables with no external dependencies; they are in a way already “containerized” themselves.