On 2/4/20 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 03, 2020 at 05:22:55PM +0100, Nicolas Mailhot via devel wrote: >> Le 2020-02-03 17:11, David Cantrell a écrit : >> >> Hi, >> >>> We want input from the community on what the main goal should be and >>> prioritize the rest. For example, is ISO reduction size more >>> important than >>> improving installation time, for instance? If so, why? >> >> This is a nonsensical question > > Great start for constructive discussion ;( > >> without defining the target hardware and connectivity. > >> Hardware with weak CPU (chromebook) and high connectivity (fiber) >> will want as low compression as possible. >> >> Hardware with low connectivity or low storage (chromebooks, vms) >> will want the highest possible compression; because I/O limits will >> wipe out any CPU win, and dnf/packagekit caches get expensive fast. >> >> (chromebooks are problematic in all cases) > > Right. We produce just one image that has to serve all of those cases, > i.e. the hardware we are targeting is "the average" of all Fedora > users. (Producing more than one image with different compression > settings was briefly discussed also, but it seems that the storage of > multiple images is too "costly" to justify this.) That is why we talk > about prioritization of goals: we need to pick something that handles > all cases and the question is which characteristics matter most to > users. I think that is the wrong question. It is not a question which of the three is most important, the question is rather, to what extend are we willing to sacrifice one for the other. As storage has different units than installation time, they are inherently not comparable. We should thus come up with a metric to make them comparable. The obvious way to make them comparable is by multiplying size by "download speed" [MB/s]. Thus if we can agree on a speed, they are comparable, and we can get closer to a solution. However, the time it takes to install isn't a reproducible, well defined quantity, but depends on the device. A way forward is to take an average over several systems. The arithmetic average (sum all up, divide by n = number of samples) will give skewed results towards the slowest device. I think geometric average (multiply all, take the n-th root) could be useful. So if we choose this approach, which IMHO puts the discussion now on a more technical ground, and allows to quantify how much speed we are willing to sacrifice for size or vice versa, we need to choose: a) Constant to convert size to speed b) List of test systems Concerning a) We could again take the geometric average of several connection. Concerning b) Maybe 4 test systems: high-end system with ssd (both install source and target) and high-end cpu medium system 1: good usb drive + target ssd, medium cpu medium system 2: cheap usb drive + target hdd, medium cpu slow system: something like a chromebook I have ignored composition time, because the end user does not care in most cases. As long as it composes in a reasonable time frame, most users don't care. I would thus suggest trying to optimize the above to, and restrict the possible to options, so that compose is still acceptable. David > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
