On Tuesday, 8 November 2022 09:43:40 GMT Richard W.M. Jones wrote: > On Fri, Nov 04, 2022 at 01:44:41PM +0100, Petr Menšík wrote: > > > If there are binaries with different build results, I think some > > code should be refactored out of the binary itself. The common parts > > can remain, but hardware specific parts should be moved to > > dynamically loaded *.so files. The correct files should be loaded > > depending on hardware found on the system. If auto-detection is > > wrong, manual configuration via configuration file should be used > > instead. > > > I think this is right. In particular you cannot assume that "the > hardware" is a thing which remains stable for the lifetime of a Fedora > install. > > Sure, if you install Fedora on your laptop then the hardware is > unlikely to change. But if you install Fedora on a VM then it can be > moved and booted on a VM with different (virtual) hardware. And > there's also the template case where someone prepares a disk image on > one set of hardware (maybe virtual or physical) and then the disk > image is used as a template to clone multiple systems from. > > Having autodetection at run time deals with this, having different > hardware-specific RPMs installed does not. > > Rich. > Even on a laptop or desktop, hardware may change underneath you. For example, early Intel Alder Lake CPUs would expose AVX-512 in CPUID if you turned off all the Efficiency cores, and just left the Performance cores; a later microcode update stopped this working, and force-disabled AVX-512. There's also been efforts to bring mainframe-style "upgradeable silicon" down to the consumer market, like the Intel Upgrade Service[0]. For laptops, this has great appeal to manufacturers - you can build a bunch of machines with a soldered down Celeron CPU, and upgrade them to Core i3/i5/i7 during pre-sale provisioning, allowing you to reduce your stock needs. Once you can do that, why not also sell the upgrade keys to people who bought the cheap Celeron, making a profit on up-selling them to the i7 later? [0] https://en.wikipedia.org/wiki/Intel_Upgrade_Service -- Simon Farnsworth _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
