On Tue, Jan 7, 2020 at 9:58 AM Gary Buhrmaster <gary.buhrmas...@gmail.com> wrote: > > On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler <kevin.kof...@chello.at> wrote: > > > I think increasing the size of the live images, also affecting the download > > time and the time to write the image to media (even USB sticks are not > > instant), to get a one-time installation speedup is a very bad tradeoff. > > While not exactly the same, the measured increase in size > by the Arch community for their packaging by moving from > xz to zstd was ~0.8% (and gaining a huge reduction in CPU > utilization at the decompress end). > > If those (approximate) numbers hold for this use case > (someone would clearly have to test to confirm or > refute those numbers) I would have to suggest that is > likely a good tradeoff that is worth further consideration.
Even at 8% bigger it would be worth it. And probably 16%. Gaining additional features, like on the fly checksumming is worth considering (at least not making it harder to implement in the future, by taking it into account with the work implied in this proposal). The monolithic ISO check is terrible. It's dog slow. It's optional. And it's a one time check. Typically real optical media tends to work or persistently fail; whereas USB sticks can have transient bad reads (explicit or silently corrupt). Stacked images on the same media functionality is in the kernel, it's not complicated, it's well tested, doesn't require any gymnastics in the initramfs - your bootloader entries can each point to different root=UUIDs and image assembly is figured out entirely in kernel code, no special handling in the client side deliverable. Yes the image creator needs to know some things to achieve this. Why stacked images? Consider a single base.img that's maybe 1G, and now you don't have to do separate composes for server, cloud, GNOME, KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps, including expensive steps like compressing the same things over and over again. Just do a 'dnf group install' tacked onto that base.img, the work being done is custom for that output, rather than repetitive. Not complicated. It would be fast enough that the high level variants could be composed on demand. Seconds. It'd be fast enough to queue it for download within the hour. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
