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

Reply via email to