I have the feeling that there is more obsession with small base images (leading to a few unused megabytes of diskspace on my 1TB disk) as compared to some text editors eating up my limited memory and CPU nowadays.

How is that? Do people really realize that there is not much difference between a 52MB base image and a 17MB base image? It's a relatively small waste on my disk. Network wise, it's also not much of a difference. My text editor eating up hundreds of megabytes of memory to show some files, that's ok, though? :(

You must have great internet that has symmetric upload and download speeds. When I’m home (in San Francisco with $100+/month connection), the difference between pushing a 12mb image and a 100mb or 300mb image is 10 minutes.

At work I don’t care because our connection is symmetric but while upload speeds are routinely 1-5mbit, if you are lucky (on dsl it’s worse), it matters.

If you're shipping a binary image back upstream, you're doing it wrong.

Artifact builds absolutely positively should never happen on developer workstations. Perform local builds as a test, but always push your build instructions and source to a centralized builder.

If you even remotely respect the folks who depend on binaries of your code as a developer, you will avoid shipping those binaries yourself. Send build instructions to a 3rd party and allow them to distribute the binary and keep yourself honest.

Solution : no need for super fast home internet when dealing with docker images .. get yourself a server (VPS) on ovh.com for $7/mo 4gb ram and do your docker image builds and push there to avoid having slow uploads from home ... total game changer ... the gives you the liberty to work from even a slow internet connection since there is slim to no bandwidth needed to issue commands on remote server via ssh connection

I don’t know if it’s changed, but it hasn’t been that easy to cleaning up old images in Docker, so small images can save a lot of disk space on a QA environment where containers are continuously created and destroyed, for example.

Also, it’s probably a lot easier to cut off a few megabytes off an image than fixing Atoms ram usage.

I suspect that most of those of us that make a hobby of minification (whether it be container images, JavaScript, images or anything else) use Vim or other non-wasteful text editors.

We’ve moved away from an obsession with a small base container (which balloons the second you install anything useful on it) to a base-image that’s “warm” on most locations. This way the container only has to add a few layers. The downside is a cold host can take up to a minute to warm up. Easy solutions for that one.

An alternative way to create small container images is to not base them off a distro at all: https://news.ycombinator.com/item?id=15415992

Aww. Unmaintained. I desperately want a slim debian-based image I can use in place of alpine (Nothing against Alpine, I'm just a deb-head at heart.)

You could try https://github.com/bitnami/minideb - about 52Mb uncompressed.

What makes you think it is unmaintained? Just because there was no commit for some time? Maybe there is nothing more to add. It's just a small base image which probably does everything it should for the creator. There also are no open issues or PR.

not updated in a year?

There's debase, too, which is Ubuntu-based: https://news.ycombinator.com/item?id=15403629

Source code: https://github.com/tklx/base

Image size: 52MB (uncompressed), 21MB (compressed)

unmaintained, latest commit fae9376 on Sep 12, 2016 ...

Why does that mean unmaintained? Maybe there is nothing more to add. It's just a small base image which probably does everything it should for the creator. There also are no open issues or PR. Funny how no commit in some time equals unmaintained nowadays.

Wouldn't there be security patches/releases in that time? Or do they not sit in the repo?

One can always do apt-get update && apt-get upgrade && apt-clean (the last being a convenience command by TKLX) in their first RUN after FROM.

ARM support?