5 ms·

Not sure why the obsession with OS size. I don't mind having a 1GB OS that has really good functionality vs a 50MB one that has none. I do want size to be a fac

Not sure why the obsession with OS size. I don't mind having a 1GB OS that has really good functionality vs a 50MB one that has none. I do want size to be a factor for server based images which is a different beast altogether.

yata01 8y ago
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?
- coldacid 8y ago
  I think that comes in under GP's exception for server images.
tbirdz 8y ago
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.
- mbell 8y ago
  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.
deathanatos 8y ago
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.
- saltyhitler 8y ago
  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.

yata01 8y ago

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?

coldacid 8y ago
I think that comes in under GP's exception for server images.

tbirdz 8y ago

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.

mbell 8y ago
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.

deathanatos 8y ago

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.

saltyhitler 8y ago
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.