I totally agree with that view. Making such decisions without public discussion is not respecting user's freedom of choice. And this list doesn't count as a public discussion. Nobody will know about it outside a very closed circle. If you don't know exact numbers or reasons why people still use that architecture, then rushing to drastic measures just won't have enough rationale and will be viewed as a lack of care. The reasons to use 32-bit userland might be more than you think. There are different use scenarios besides browsing Internet or virtualization. There could be a high cost of upgrade (think about replacing many computers at once). There could be a unique peripheral equipment. There could be compatibility concerns. And there could be just not enough memory. OTOH, what could justify removing repository entirely? Why not make it an option which could be installed on demand? That would be better than leave everyone out on the cold. Is the cost to build it really that high? Safety could not be a reason in a tightly contained environment. Let users decide for themselves. There is no black and white distinction: multilib or i686 kernel. There are reasons why using x86_64 kernel with i686 userland might be a better option. Some older office computers were manufactured with 64-bit CPU but without support for more than 4 GB RAM. In such case using i686 userland on a x86_64 kernel provides much more free memory than using 64-bit userland. Such configuration is unsupported, but neither is i686. Giving users a choice is always better than decide for them behind their backs. And of course there is still an option to switch to another OS. Do I need to remind that Linux and Red Hat were not created just to replace some other OS, but to respect freedom of choice? What happened that this is not even mentioned in such discussions? Is this just business as usual? _______________________________________________ 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
