Teknikal_Domain on Nostr: npub1trdnq…gussx npub1l3gpk…qvu48 Personally I think FlatPak makes more sense, I ...
npub1trdnqrfstufc45awha43p6xy2n0v6czuhapzh4r09hap08dg0c6s9gussx (npub1trd…ussx) npub1l3gpk6vrudg8r67swqlex5alv9ch59s4lw46kk6hekuxe2n3aczsyqvu48 (npub1l3g…vu48) Personally I think FlatPak makes more sense, I don't think AppImage has the same sort of sandboxing which is the entire point of containers.
Unfortunately this comparison breaks down when you consider that Docker expects a sort of one-container-per-app topology, using stacks to link everything up. So a single application can be made of half a dozen containers, one for the app, one for the database, one for the frontend... All communicating on a loopback bridge network together. Updating these can be fun sometimes.
Also your understanding is good but misses some details, Docker (and the ContainerD runtime and system it uses) is doing basically all the work, the OS isn't doing anything besides cgroup separation. (And don't get me started on how Docker does storage and filesystems)
Unfortunately this comparison breaks down when you consider that Docker expects a sort of one-container-per-app topology, using stacks to link everything up. So a single application can be made of half a dozen containers, one for the app, one for the database, one for the frontend... All communicating on a loopback bridge network together. Updating these can be fun sometimes.
Also your understanding is good but misses some details, Docker (and the ContainerD runtime and system it uses) is doing basically all the work, the OS isn't doing anything besides cgroup separation. (And don't get me started on how Docker does storage and filesystems)