Yeah, I guess that's true.

The final result is a 78% smaller docker image, not container. But the way they achieve it, is by running a container of the image, running the functional test suite, then remove everything that was unused when the test suite ran, creating a new image from the results of the removal.

I don't think the title is purposefully misleading, it's just incorrect by mistake (confusing image/container).

TBH, I thought that they would delete a part of a running container, something to do with de-allocating memory pages in runtime and all that low-level C magic, but now I see that it was just a really weird way to read this on my part.

No I read it that way too.

> then remove everything that was unused when the test suite ran

What tooling does one use to determine this? How can you see what files are being hit or not? Ptrace?

Edit; I RTFA and think that’s the product they sell. But how would one go about this without their product?

My guess would be a combination of ptrace/strace/overriding libc and/or eBPF.

Maybe this would help in that regard: https://github.com/docker-slim/docker-slim

Docker slim would help in limited ways. EBF filtering fails at scale and has I here t limitations.

We deleted files from a pre-built container and not Dockerfile.