On 10/4/18 7:33 PM, Thorsten Kukuk wrote:
On Thu, Oct 04, Robert Schweikert wrote:
Can you share the definition of "small and slim". What is the target size we want to get to and why does it matter if the image is a "bit" bigger?
Ever downloaded an image at every boot via LTE? That's what some of our customers are doing, as they don't want to send technicians out in the wild to do that via usb stick.
Wouldn't that be a corner case though as Robert mentioned?
And in virtualisation environments (not public cloud), disks are no longer cheap, as you have many, many virtual machines. So why for you a jump from 8 GB to 10 GB in the public cloud is no big problem, a lot of customers would like to see that we use only 4 GB, as that would allow them to store double as many virtual machines as today. And the LTE fraction would even like to see images in the 150MB range...
I think the statement is accurate that storage prices are going down as technology progresses, not up. There might be stalls in that development from time to time, but I think the trend is clear [1].
Having these numbers is interesting but what is the goal of the image you want to build and what is the benefit of the smaller size for JeOS or MicriOS?
The requested goal by our big customers are less than 500MB, else see above.
And no, we don't want any of your proposed hacks, we are very happy that we were able to remove all of this hacks from building images. This only breaks RPM and updating the images.
I wouldn't consider using KIWI for custom size adjustments a hack but rather the appropriate way customizing images. As long as the method isn't obscure and complicated, I would prefer it over a one-fits-all solution as proposed in the original post. Thanks, Adrian
[1] https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org