Hacker News Reader

Comment by cycomachead | Hacker News Reader

This is a valid point, but definitely a misleading title.

How is it misleading? The entire post reads like a PR piece for their company, but the title seems faithful.

They didn't delete a part of container, they deleted a part of the docker file. Actually removing data from already built container image, as title suggests, would be much more impressive.

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.

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.

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

I would like to understand what’s misleading. You could download the container and compare sizes and binary with source container.

I have updated the title to remove confusion. Thanks for calling it out. There was no intention to mislead the community.

Reply on news.ycombinator.com