Luca Boccassi wrote: > If I am reading this correctly, when Fedora was first released in 2003, > common hard drive capacity was around 80 GB: > https://upload.wikimedia.org/wikipedia/commons/a/a1/Hard_drive_capacity_over_time.png > Today, 1 TB+ hard drives are common. SSD capacity has been lagging behind this though, and as far as I can tell, 1 TB SSDs have only recently (around 1-2 years ago) dropped below 100€. Many smaller SSDs are still in use (e.g., my / partition is on a 256 GB SSD, /home is on a RAID1 of HDDs though). And mobile devices have much smaller SSDs (e.g., the PinePhone has 16 GB or 32 GB of internal eMMC storage depending on the edition). > Hence, even taking your x10 figure at face value, the growth of Fedora's > requirements for disk space has not matched the growth of disk space > availability, but it has stayed below, hence it's a win-win - you get the > benefit and the cost is more than absorbed by hardware improvements. The thing with bloat is that it is not always clear what the benefit actually is. > Furthermore, given an installation with the entire RPM universe installed > (iirc) taking ~10 GBs, with a penalty of ~10 MBs, you'd need approximately > 9000 (nine thousand) proposals "like this one here and there" to get the > x10 you speak of. If I am reading correctly, there are about ~50 fesco > proposals per Fedora release (https://pagure.io/fesco/roadmap?status=all), > so it would take 180 releases over 90 years to get there by accumulating > proposals like this one. There has already been the proposal in this thread to add additional metadata to the binaries for each linked static library, which could increase the cost per executable to much more than the current 200 bytes. And bloat does not always just linearly add up, it can polynomially or even exponentially multiply up. In this case, the per binary cost multiplies up with the constant growth of the number of ELF binaries in the distribution (which is another source of bloat), leading to quadratic bloat. That said, you are probably right that this change proposal is not the worst source of bloat we have ever encountered. There has been much worse. (Just in terms of bloat added to each ELF binary by Fedora-specific settings, I think both MiniDebugInfo and Annobin really ought to be dropped. MiniDebugInfo is no useful replacement for full debuginfo and only wastes space. Annobin has no benefit for the end user at all and should be only enabled in private QA rebuilds.) But the benefit of this change proposal is also very small. And I disagree with the concept that "we have done worse" is a valid argument for doing something bad. Kevin Kofler _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
