Bandwidth; we deploy frequently, and pushing images around is a fairly hefty part of that deploy, and the less the better. OS images don't update too often, thankfully, and Docker will only upload layers if needed, but it's still much easier to push 5MB than 80-200MB, so Alpine does have a distinct advantage there. 1GB is pushing it, a bit. (We also put much of our tooling on the host VM; generally, this can suffice IME.)

While my office has a great connection, my ISP at home is less so, particularly in the up direction. On mobile, pushing 80-200MB up is essentially not going to happen, both because it eats into my data caps quickly, and because mobile latency is such that that's really slow.

I agree and that's why I said server based images should be small but for user based OSes, for development work or browsing, size should be the last thing on the feature list. It's the development mindset that is pushing for small OS sizes and we should put that in the backburner in exchange for a good user experience.

In some cases, I think users may want that 50 MB OS so that they can add functionality as they need it. Sure, the 1 GB OS comes with some neat built in functionality, but how much of that is unnecessary for your use cases?

I think that comes in under GP's exception for server images.

I think containers have a lot to do with this in a big way. When you are making a container for every app, the OS base size really starts adding up. As a one time fee the disk space for an OS image is not a big deal, but when you have to pay that disk space for every app, then that really adds up.

If you structure your images well you don't pay the base image cost for every app, the layer is cached and stored once on disk.