Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > "In the bios, upgraded to 810 the option to enable legacy boot is greyed > out" > > So how do people propose the situation to be handled when firmware from > vendors, disables the legacy boot option via firmware update. I haven't seen anyone arguing that Fedora should drop UEFI support and enforce BIOS-booting even on brand new hardware, so I don't even understand what you're arguing against here. Obviously buyers of new computers whose bioses support only UEFI will have to use UEFI – and hope that those UEFI implementations are capable of booting Fedora. In case you meant to argue that bios updates will remove the need for Fedora to support BIOS-booting, this example does not support that position. The computer in question is at most a few months old. Twelve- year-old computers that never had UEFI support get no more bios updates and will never get UEFI support added. Anyway, it's not clear that the computer was shipped with a working legacy boot option. The forum post doesn't say that. It says only that the legacy boot option is unavailable and that the bios has been updated. By the way, the forum post is an example of a user who is dissatisfied with UEFI for some reason, and wants to boot in BIOS mode instead. Dropping BIOS-boot support from Fedora would presumably not make that person any happier. Björn Persson pgpTOibEFEGtI.pgp Description: OpenPGP digital signatur ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > For example EU has regulation that requires vendors to have spare parts > available for 7–10 years after date of manufacturing so it makes sense > for the project to support hw no longer than a decade from the date of > it's manufacturing. I fail to imagine what use case you might have in mind where that requirement would interact with Fedora. If such regulation would be applied to Fedora, the closest equivalent would be that the Fedora Project would be required to provide bug fixes to old releases for seven to ten years, so Fedora would essentially have to be RHEL. If I had the kind of strictly specified system where any broken part must be replaced with an identical part, then I would definitely not run the constantly changing Fedora on it. Such a system would rather run RHEL, or something even more stable than RHEL. It makes no sense to take special care to keep the hardware unchanging for ten years, even when repairing it, and then replace the software twice a year with different user interfaces, changed behavior and a new set of bugs in every release. As for the kind of computers that Fedora is suitable for, I'll use them until they break, whether that happens after five or fifteen years, and then I'll replace the broken part or the whole computer with modern hardware that can be expected to last for many more years. If a broken part is less than three years old, then I have a right to get it repaired or replaced. Past the three-year limit I won't make any attempt to buy the exact same model to replace a broken motherboard (where the bios is stored). I'll take the opportunity to upgrade to the latest stuff when I need to buy a new motherboard anyway, so it will remain useful for as long as possible. That doesn't change at any seven- or ten-year limit. I seriously doubt I could find a seven-year-old motherboard on the market anyway. Used perhaps, but not from the vendor. If a computer doesn't break, I may eventually have to replace it when the processor can no longer keep up with the software's demands, but that takes much longer than ten years nowadays. Björn Persson pgpZ7ENGcIhpJ.pgp Description: OpenPGP digital signatur ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 09:29:27PM +, Jóhann B. Guðmundsson wrote: > >That’s maybe true for desktops, but in the server world any server needs > >to be able to do bios boot, because of the data center requirements. > > > Interesting I would assume that those data center requirements would > make it a requirement for example to be using uefi's native http > protocol to address the shortcomings of traditional (i)pxe, so which > data center requirement are those and where can I find documentation > about them? I think Peter's referring to "practical requirements" not "compliance requirements" — the latter probably indeed better with UEFI, secure boot, and a lot more, but the former in the real world being "yes, we've got way more legacy hardware, configuration, and policy than ideal, but we also don't have the staffing or budget to change it all at once". That's unlikely to be publically documented — but nonetheless is believably true. (And I think it's probably _particularly_ the case in small-medium environments which might choose Fedora Server.) -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 15/04/2022 00:53, Jóhann B. Guðmundsson wrote: Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. fwupd operates only in UEFI mode. Problem solved. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 15/04/2022 03:51, Nikolay Nikolov wrote: But I'm still surprised that Fedora by default downloads and updates proprietary firmware, downloaded from the Internet. 1. Fedora itself doesn't download anything. The user must manually allow installation of such update. 2. Vulnerable firmware is a bigger problem. 3. LVFS is maintained only by hardware vendors. Btw, does this work in legacy boot mode as well? No. UEFI is mandatory in order to use UEFI update capsule. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 15/04/2022 01:25, Nikolay Nikolov wrote: At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? https://fwupd.org/lvfs/devices/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> Am 15.04.2022 um 00:24 schrieb Nikolay Nikolov : > > If you want to deprecate legacy boot on new installs on UEFI-capable BIOS-es, > that's another story. E.g. if the installer detects that the BIOS is modern > (e.g. later than 2017-2018) and UEFI capable, but is running in legacy boot > mode, it could prints a warning and suggest to the user to restart and turn > off legacy boot from the BIOS setup. The installer promises better hardware > support, firmware updates and happier times to the user if the operating > system is installed in UEFI mode. Finally user decides whether to do that, or > choose to continue on their own risk. That is totally reasonable, IMHO. But > it is a completely different thing than dropping legacy BIOS support > completely. ++1 That’s a really reasonable plan to start „deprecating“ Bios boot. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 11:39 AM Kevin Kofler via devel wrote: > I am also worried that this is just a delayed retirement, as it was for 32- > bit i686, where the SIG was very quickly declared a failure, without even > being given time to organize. Well, presumably, if you are a member of the SIG(*) you will get to make sure that that does not happen. Gary (*) And if you choose not to be an active contributing member of the SIG you really don't get to tell others how to use their time/resources (in other words, I as I said with many other projects and forums, you get to actively contribute, or you get the results from those that do (i.e. your "opinion" is worth about as much as the electrons it was posted from)). ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/15/22 04:01, Jóhann B. Guðmundsson wrote: On 14.4.2022 23:25, Nikolay Nikolov wrote: On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. Really? I didn't know that. At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? It's fwup/lvfs [1] and nope you dont need to jump through any additional hoops for that, it just work ( or it does not if the vendor is not part of lfvs ). Oh, wow! Yeah, my new desktop has an ASRock motherboard and my laptop is an HP and, and while both vendors (HP and Asus) participate in lvfs, they don't seem to upload a lot of firmware updates (HP has uploaded 34 firmware files, for comparison Dell has uploaded 2033 firmware files). But I'm still surprised that Fedora by default downloads and updates proprietary firmware, downloaded from the Internet. Btw, does this work in legacy boot mode as well? If I recall correctly, someone in the 2020 thread mentioned that fwupd requires boot in UEFI mode, but I don't remember the exact details. And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. I think we should check the BIOS date in the installer and deprecate (as in, print warnings to the user in the installer) legacy boot on newer systems (e.g. newer than 2017 or some other cutoff date, when we decide that UEFI becomes more stable), an by deprecate, I mean, show warnings to the user and suggest that they continue on their own risk. Of course, we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not show the warning in them, even if the BIOS date is new (although SeaBIOS seems to use an old date - 06/23/99). That's something that needs to be worked out with the Anaconda team but I think Javier already provide the best path forward with regards to Anaconda when I started the dialog two years ago but for whatever reason that's not part of Robbie's proposal. What was Javier's proposal? Best regards, Nikolay JBG 1. https://fwupd.org/ ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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 Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure___ 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.fedo
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 15:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. That only applies to a UEFI system, so it doesn't matter if legacy mode gets disabled by the update since it's already using UEFI to boot. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 15.4.2022 00:44, Kevin Kofler via devel wrote: One of the reasons people use GNU/Linux is exactly to escape the hardware manufacturers' planned obsolescence treadmill. True but that does not mean Fedora is the best distro for that + it looks like hw vendors are taking lessons from the Apple playbook and starting to vendor lock parts for their hw. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 23:25, Nikolay Nikolov wrote: On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. Really? I didn't know that. At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? It's fwup/lvfs [1] and nope you dont need to jump through any additional hoops for that, it just work ( or it does not if the vendor is not part of lfvs ). And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. I think we should check the BIOS date in the installer and deprecate (as in, print warnings to the user in the installer) legacy boot on newer systems (e.g. newer than 2017 or some other cutoff date, when we decide that UEFI becomes more stable), an by deprecate, I mean, show warnings to the user and suggest that they continue on their own risk. Of course, we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not show the warning in them, even if the BIOS date is new (although SeaBIOS seems to use an old date - 06/23/99). That's something that needs to be worked out with the Anaconda team but I think Javier already provide the best path forward with regards to Anaconda when I started the dialog two years ago but for whatever reason that's not part of Robbie's proposal. JBG 1. https://fwupd.org/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Justin Forbes wrote: > The i686 SIG was given multiple releases to organize. The original > proposal which triggered the SIG to form was for F27, the proposal to > finally kill it and declare the SIG inactive was F31. But, the way I remember it, the SIG was declared inactive just because of *one* unfixed kernel bug (the primary platforms have hundreds) and perceived lack of mailing list activity (IIRC, the complaints were that there were too few messages, but that limit is arbitrary, and that the bug was not discussed on the mailing list, which is normal because that is what Bugzilla is for). > But this is different from the i686 kernel SIG in some critical ways. But is this going to help, if the SIG will be held to unreasonable standards just to have an excuse to kill it at the next opportunity? Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 15.4.2022 00:38, Kevin Kofler via devel wrote: Jóhann B. Guðmundsson wrote: Trying to support that legacy scenario where certain hw may or may not work is a nightmare for developers, support teams and Fedora since Fedora is not a distribution with a long term support, LTS distributions are better suited to support legacy hw then Fedora ever will. Nobody is asking Fedora to provide support for fixing old hardware if it breaks. All we are asking for is for Fedora to continue running on old hardware that is *not* broken. Yes I got that it's the hw version of "if it builds let's ship it, even if upstream is dead" approach. The thing is we could elimination so much of technical debt in Fedora if we would drop the legacy bios support and could move the distro quite a bit forward in coming releases if we did but from the looks of it, it seems to have been already decided to "form a sig" and drop this proposal so meh Fedora 40 then... JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > No but it does mean that they cant run indefinitely Only if the spare parts that are not available actually fail (and if you cannot find the spare parts through less official channels, such as buying another broken computer where the part you need is still working). And, as explained elsewhere in this thread, the parts most likely to fail can actually be replaced with generic replacements. Also keep in mind that many Fedora users have one or two computers, not hundreds. That makes it much less likely to run into a hardware failure in a given time interval, and there is very little incentive to "fix" what is not broken. > And there needs to be a number on this to adjust users expectation and > 10 years is a reasonable number from a business, parts and > recycle/re-use availability, 10 years is *not* a reasonable number when a notebook still runs great after 14 years. > What is unreasonable is to be expecting that it's supported indefinitely > from OS and or HW vendors. One of the reasons people use GNU/Linux is exactly to escape the hardware manufacturers' planned obsolescence treadmill. Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > Trying to support that legacy scenario where certain hw may or may not > work is a nightmare for developers, support teams and Fedora since > Fedora is not a distribution with a long term support, LTS distributions > are better suited to support legacy hw then Fedora ever will. Nobody is asking Fedora to provide support for fixing old hardware if it breaks. All we are asking for is for Fedora to continue running on old hardware that is *not* broken. Some parts are hard to swap, others are easy. My soon 14-year-old notebook has a relatively new hard disk (standard SATA laptop/notebook HDD, thinner than the original one, but the screws hold it in the correct position, so that does not matter and actually improves cooling airflow) and power supply adapter (cheap generic universal power supply, one of the offered plugs is both physically and electrically compatible with my notebook). The old HDD might even have worked longer, I replaced it after the first failed sector, with a faster (7200 rpm instead of 5400 rpm) one with twice the capacity (512 GB instead of 256 GB, though, if I had waited a bit longer, I could have gotten an SSD of the same size instead for that price, but now I do not want to replace the storage again in that ancient notebook). The power supply adapter was the only thing I *had* to replace, as the old one had failed completely. (And, realistically speaking, the HDD and the power supply are statistically among the parts most likely to fail to begin with.) Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > Then there is the fact that clinging to legacy bios is working against > Fedora's own foundation "First" in which is stated "Fedora always aims > to provide the future, first". How is it against "First" to continue providing the future also for hardware of the past? "First" means that Fedora *delivers* the latest&greatest, not that it *requires* the latest&greatest. Doing the latter actually goes against the "Freedom" (where is my Freedom Zero, run the software as I wish?), "Features" (desupporting old hardware = removing a feature) and "Friends" (people dropping support for my hardware are not my friends!) foundations. As I already pointed out once, continued support for old hardware does *not* preclude shipping the latest software first. You keep bringing up this false dichotomy. The repetition does not make it any truer. Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. Really? I didn't know that. At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. I think we should check the BIOS date in the installer and deprecate (as in, print warnings to the user in the installer) legacy boot on newer systems (e.g. newer than 2017 or some other cutoff date, when we decide that UEFI becomes more stable), an by deprecate, I mean, show warnings to the user and suggest that they continue on their own risk. Of course, we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not show the warning in them, even if the BIOS date is new (although SeaBIOS seems to use an old date - 06/23/99). Nikolay JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
If people are wondering how it looks like when Fedora's code of conduct is violated when people partaking in community discussions and receive attacks in private as an result of that here's an example of that. This individual has already sent at least me death threats ( privately ), been blocked on other projects ( non fedora related ) mailinglist ( not involving me in those ) shown questionable behavior on the ISC mailinglist and now two years later he's at it again. Word of advice when attack like these happen in private the best way to deal with it first and foremost try not let it discourage you, secondly expose the attacker to the broader community ( which I'm doing with this post and did last time as well ) since Fedora CoC is powerless to deal with this ( Often these attackers frequently change email addresses ) and the attacker knows it, like his response to me in private when I exposed him last time here on devel. "little idiot: the Fedora COC don't apply for pruvate mails just because the topic is fedora relevant" On 14.4.2022 21:46, Reindl Harald (privat) wrote: Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmundsson: "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? are you mentally ill? there are tons of physical hardware and virtual machines which don't give a shit and just work in BIOS mode and smome are installed that way because UEFI has no fucking way to keep /boot on RAID1 over multiple disks JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem, which they need to resolve. Most people never update their BIOS [1], because their system is working just fine. Only power users do, and they know how to read changelogs and how to backup their previous working BIOS. So, no, it's not Fedora's problem if a users installs a BIOS update that bricks their system, or renders it unbootable (for whatever reasons, doesn't matter whether they're related to legacy boot or not). We have no obligation to prevent that. The right approach to BIOS update is "don't do it, unless you have to". If it ain't broke, don't fix it. I've been burned so many times, due to buggy BIOS updates, most of them unrelated to legacy boot. We don't prevent BIOS updates that break UEFI or secure boot, or which brick the system, so why should we prevent BIOS updates that break legacy boot? And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? If you want to deprecate legacy boot on new installs on UEFI-capable BIOS-es, that's another story. E.g. if the installer detects that the BIOS is modern (e.g. later than 2017-2018) and UEFI capable, but is running in legacy boot mode, it could prints a warning and suggest to the user to restart and turn off legacy boot from the BIOS setup. The installer promises better hardware support, firmware updates and happier times to the user if the operating system is installed in UEFI mode. Finally user decides whether to do that, or choose to continue on their own risk. That is totally reasonable, IMHO. But it is a completely different thing than dropping legacy BIOS support completely. 1. It is indeed still universally called BIOS, even though it's UEFI: https://www.asrock.com/support/BIOSIG.asp?cat=BIOS10 Best regards, Nikolay JBG 1. https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 18:29, Peter Boy wrote: Maybe "legacy BIOS on physical hardware" is on its way out, but it doesn't seem that it is true across the board in VM environments. That’s maybe true for desktops, but in the server world any server needs to be able to do bios boot, because of the data center requirements. Interesting I would assume that those data center requirements would make it a requirement for example to be using uefi's native http protocol to address the shortcomings of traditional (i)pxe, so which data center requirement are those and where can I find documentation about them? JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? JBG 1. https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 16:38, Ben Beasley wrote: I’m not talking about refurbished parts or new old stock. I’m talking about the brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other components that are backwards-compatible in systems pushing twenty years old (SATA) or older (PSUs, fans). Maybe I misunderstand, but your argument seems to be based on the idea that all replacement parts are custom designs tied to OEM support policies rather than commodities based on long-lived standards. I'm talking about the entire hw range in the computer, every single component which can break not just the nuts and bolts on the computer case, or the PSU fans etc. ( It's interesting how you always avoid mentioning motherboard/GPU failures etc ). As much as people may dislike it, the fact is those long lived standards have been replaced with a newer standards and not all replacement parts are backwards compatible like for example for a video device to work on a motherboard with a legacy BIOS, or in CSM mode, it needs a VGA option ROM to initialize the card. Most video cards/IGPs for the last few years have dropped legacy BIOS support and only have UEFI ROMs ( which means they wont work on legacy bios or in CSM mode ) so we already are in an era when people are buying replacement parts which either needs to be old enough or legacy-friendly enough to work on that legacy hardware and as much as I dislike it, entering an era of vendor locked replacement parts ( Like AMD epyc CPU's getting locked to computer vendors. AMD epyc CPU's from Dell HW wont work on Lenovo HW and visa versa even if those are the exact same CPU models etc. ) Trying to support that legacy scenario where certain hw may or may not work is a nightmare for developers, support teams and Fedora since Fedora is not a distribution with a long term support, LTS distributions are better suited to support legacy hw then Fedora ever will. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 12:18:12PM +, JadoNena via devel wrote: > All of this discussion waves a red flag at us. [...] > But only a few people are talking about the real costs to users. Please don't read too much into everything you see in big mailing list threads like this, especially as you go into the their deep depths. We absolutely do care about these things! -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 6:39 AM Kevin Kofler via devel wrote: > > Ralf Corsépius wrote: > > I do not agree with this statement. Like previous "Legacy SIGs" this is > > a red herring to obfuscate RHATs lack of disinterest with topics, which > > do not match into their business objectives. > > I am also worried that this is just a delayed retirement, as it was for 32- > bit i686, where the SIG was very quickly declared a failure, without even > being given time to organize. The i686 SIG was given multiple releases to organize. The original proposal which triggered the SIG to form was for F27, the proposal to finally kill it and declare the SIG inactive was F31. But this is different from the i686 kernel SIG in some critical ways. First, the rate of churn around the boot code is massively smaller than the churn in kernel code. Second, it seemed that most of the people who showed interest in the i686 SIG had little to no kernel experience, while Hans and others interested should be capable of doing the work as long as they are willing. And lastly, many of the i686 issues which popped up were issues which kept the kernel from building, so there was more urgency around them. While I don't have plans to participate in the BIOS boot SIG, I do think it is in capable hands provided the people who have commented interest in participating continue to do so. Justin > Still, it is better than retiring it immediately. But like you, I am worried > that this is not really a long-term commitment and that people will be > attempting to kill BIOS support again at even the smallest dent in SIG > activity. > > Kevin Kofler > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 2:29 PM Peter Boy wrote: > > > > > Am 14.04.2022 um 20:20 schrieb Chris Adams : > > > > Once upon a time, Robbie Harwood said: > >> Given there is consensus that legacy BIOS is on its way out > > > > I don't think this statement is true, unless Fedora doesn't want to be > > considered for a bunch of popular VM hosts (e.g. Linode and such) that > > have no stated plans to support UEFI. > > 1++ > > > > Maybe "legacy BIOS on physical hardware" is on its way out, but it > > doesn't seem that it is true across the board in VM environments. > > That’s maybe true for desktops, but in the server world any server needs to > be able to do bios boot, because of the data center requirements. > This is not completely true for servers either. Proprietary BMCs like iDRAC and iLO both have transitioned to UEFI in the past few years. At least the first one I got my hands on that didn't mark EFI support as experimental (and worked properly) was in 2016. Supermicro IPMI has supported UEFI boot on most servers since about 2018, so it's certainly in place in a number of places. The Redfish standard became supported in EDK2 in 2019 as well. Server adoption is definitely *much* slower than desktop adoption because servers are much more expensive to deal with and replace. Not to mention, Microsoft just didn't bother making it matter for Windows Server certification until last year (even though Windows is a small part of the market relative to Linux). The tooling is there, it's just going to take the next decade to catch up to desktops. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
That’s a step into the right direction, but needs some corrections: > Am 14.04.2022 um 20:02 schrieb Robbie Harwood : > > > The overall goal of the SIG needs to be to reduce load on existing > bootloader contributors. If it is not doing this, it needs to be > dissolved. The first overall goal is to maintain bios boot and by doing this to expand the existing boot loader contributors. > > ## SIG package maintenance > > If the SIG wants to maintain any BIOS-only packages, that's up to them. > Assuming Brian's change to use grub2 instead of syslinux on legacy > install media ( https://github.com/weldr/lorax/pull/1226 ), the only > other packages in question here would be those to support VESA/fbdev: > > - xorg-x11-drv-vesa > - xorg-x11-drv-fbdev > - xorg-x11-server-Xorg Somewhere else I read these are going to vanish because nothing is still using it? > - syslinux > > ## Fedora deliverables > > Given there is consensus that legacy BIOS is on its way out, we think > Fedora release criteria in this area should be re-evaluated. Not only > does support change from "fully supported" to "best effort", but we > should re-evaluate what is/isn't release blocking, and probably clarify > who owns what parts. The goal is not to touch or modify the release criteria and blocking issues > > ## grub2 > > By default, the Legacy SIG is expected to perform contributions in the > form of triage and PRs. Normal “upstream first” rules apply here (i.e., > send it wherever possible, otherwise send to the downstream rhboot > repo). > > Current grub2 maintainers consider splitting the package (probably grub2 > and grub2-pc, to match current naming, or grub2-legacy or something) > undesirable for a number of reasons. A nonexhaustive list of what would > need to be satisfactorily resolved before a split could considered: > > - There needs to be a primary (and probably secondary) package owner > from the SIG as a prerequisite for a new bugzilla component. > > - Everything in grub2-common, grub2-tools, and grub2-tools-extra is > available on both UEFI and legacy. In most cases, the content is in > fact shared: one file works on both. > > - The new grub2-bios is secondary to the main grub2 package, which means > that the Legacy SIG is responsible for not conflicting with any grub2 > subpackage, and nothing in grub2 can depend on anything in the legacy > package. Both groups cooperate in a way that best fits the goal to keep Fedora able to boot from any of the supported media (for a probably limited time, e.g. 5 years) > > - More generally, problems with the shared core can and will manifest > primarily on one platform. The maintainer of that platform lead the problem solving. > - Feature incompatibilities can and will occur. (Maybe this is okay, or > just the Legacy SIG's responsibility to sort out in all cases.) Feature incompatibilities will get resolved by the lead of the part that is affected most with support from each other. It is the common responsibility to resolve issues. Responsibility ping-pong needs to be avoided. > - Current maintainers do not have much capacity for mentoring, and since > the point is to be rid of legacy, we can't help much at all with > bugfixes. In the initial phase, the "Bios-Boot-Maintainers" receive a detailed briefing to ensure their working preconditions. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hi Robbie, On 4/14/22 20:02, Robbie Harwood wrote: > Hans de Goede writes: > >> What I envision for the SIG is: >> >> 1. I'm not sure if it is possible to setup group ownership >> of pkgs in pagure? So to keep things simple the few packages which >> are only necessary for BIOS boot can be handed over to me and then >> I'll just add other people willing to help out as co-maintainers. > > As I've mentioned multiple times elsewhere, this isn't about packages, > and I don't think it's helpful to think in terms of them. > >> And I would also like to have a discussion about splitting >> the BIOS boot grub bits out into a separate src.rpm >> (using the same Source0 as the main grub) so that this can >> be build by the SIG without needing help from the bootloader >> team (the main grub package can only be built by a few people >> because of secureboot signing). The idea is to avoiding >> bottlenecking on the bootloader team when some BIOS boot bugs >> in grub need to be fixed, quoting from my original email about >> this: > > Trying to avoid re-hashing our lengthy off-list conversation, here are > some thoughts (mine and other interested parties's): > > At minimum, we need a Legacy BIOS SIG to provide: > > - a "place" to assign bugs (e.g., email address) > - a means to fix issues > > By default, we understand the former to be the SIG's email address, and > the latter to be PRs to dist-git of relevant packages. > > The overall goal of the SIG needs to be to reduce load on existing > bootloader contributors. Ack I agree that bugzilla triage of BIOS boot bugs + fixing them once identified needs to be the main focus of the SIG. That and regularly testing N + 1 boot media BIOS booting to catch any regressions early on. > If it is not doing this, it needs to be > dissolved. > > ## SIG package maintenance > > If the SIG wants to maintain any BIOS-only packages, that's up to them. > Assuming Brian's change to use grub2 instead of syslinux on legacy > install media ( https://github.com/weldr/lorax/pull/1226 ), the only > other packages in question here would be those to support VESA/fbdev: > > - xorg-x11-drv-vesa > - xorg-x11-drv-fbdev > - xorg-x11-server-Xorg I personally do not believe that it will be necessary to keep maintaining VESA support, I agree that without legacy BIOS support it definitely is not needed though. I believe that ajax has submitted a separate change proposal for this, so this is best discussed there. > - syslinux As you say it looks like this one may no longer be necessary and otherwise the SIG can pick it up. > ## Fedora deliverables > > Given there is consensus that legacy BIOS is on its way out, we think > Fedora release criteria in this area should be re-evaluated. Not only > does support change from "fully supported" to "best effort", but we > should re-evaluate what is/isn't release blocking, and probably clarify > who owns what parts. Given what the server product folks have indicated that BIOS boot support is quite important for them I'm not sure if changing the release criteria is in order. I do agree that any blocker bugs related to legacy BIOS booting should be assigned to; and taken care of by the legacy BIOS boot SIG. > ## grub2 > > By default, the Legacy SIG is expected to perform contributions in the > form of triage and PRs. Normal “upstream first” rules apply here (i.e., > send it wherever possible, otherwise send to the downstream rhboot > repo). > > Current grub2 maintainers consider splitting the package (probably grub2 > and grub2-pc, to match current naming, or grub2-legacy or something) > undesirable for a number of reasons. A nonexhaustive list of what would > need to be satisfactorily resolved before a split could considered: > > - There needs to be a primary (and probably secondary) package owner > from the SIG as a prerequisite for a new bugzilla component. > > - Everything in grub2-common, grub2-tools, and grub2-tools-extra is > available on both UEFI and legacy. In most cases, the content is in > fact shared: one file works on both. > > - The new grub2-bios is secondary to the main grub2 package, which means > that the Legacy SIG is responsible for not conflicting with any grub2 > subpackage, and nothing in grub2 can depend on anything in the legacy > package. > > - More generally, problems with the shared core can and will manifest > primarily on one platform. Bugzilla ping-pong needs to not be played. > > - Feature incompatibilities can and will occur. (Maybe this is okay, or > just the Legacy SIG's responsibility to sort out in all cases.) > > - Current maintainers do not have much capacity for mentoring, and since > the point is to be rid of legacy, we can't help much at all with > bugfixes. Ok, if you prefer going through PR-s then lets give that a try, I'm a bit worried that always needing to go through the bootloader team may get in the way of expedient fixing of BIOS related bugs and that this may cause ex
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> Am 14.04.2022 um 20:20 schrieb Chris Adams : > > Once upon a time, Robbie Harwood said: >> Given there is consensus that legacy BIOS is on its way out > > I don't think this statement is true, unless Fedora doesn't want to be > considered for a bunch of popular VM hosts (e.g. Linode and such) that > have no stated plans to support UEFI. 1++ > Maybe "legacy BIOS on physical hardware" is on its way out, but it > doesn't seem that it is true across the board in VM environments. That’s maybe true for desktops, but in the server world any server needs to be able to do bios boot, because of the data center requirements. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Once upon a time, Robbie Harwood said: > Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out, but it doesn't seem that it is true across the board in VM environments. -- Chris Adams ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hans de Goede writes: > What I envision for the SIG is: > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. As I've mentioned multiple times elsewhere, this isn't about packages, and I don't think it's helpful to think in terms of them. > And I would also like to have a discussion about splitting > the BIOS boot grub bits out into a separate src.rpm > (using the same Source0 as the main grub) so that this can > be build by the SIG without needing help from the bootloader > team (the main grub package can only be built by a few people > because of secureboot signing). The idea is to avoiding > bottlenecking on the bootloader team when some BIOS boot bugs > in grub need to be fixed, quoting from my original email about > this: Trying to avoid re-hashing our lengthy off-list conversation, here are some thoughts (mine and other interested parties's): At minimum, we need a Legacy BIOS SIG to provide: - a "place" to assign bugs (e.g., email address) - a means to fix issues By default, we understand the former to be the SIG's email address, and the latter to be PRs to dist-git of relevant packages. The overall goal of the SIG needs to be to reduce load on existing bootloader contributors. If it is not doing this, it needs to be dissolved. ## SIG package maintenance If the SIG wants to maintain any BIOS-only packages, that's up to them. Assuming Brian's change to use grub2 instead of syslinux on legacy install media ( https://github.com/weldr/lorax/pull/1226 ), the only other packages in question here would be those to support VESA/fbdev: - xorg-x11-drv-vesa - xorg-x11-drv-fbdev - xorg-x11-server-Xorg - syslinux ## Fedora deliverables Given there is consensus that legacy BIOS is on its way out, we think Fedora release criteria in this area should be re-evaluated. Not only does support change from "fully supported" to "best effort", but we should re-evaluate what is/isn't release blocking, and probably clarify who owns what parts. ## grub2 By default, the Legacy SIG is expected to perform contributions in the form of triage and PRs. Normal “upstream first” rules apply here (i.e., send it wherever possible, otherwise send to the downstream rhboot repo). Current grub2 maintainers consider splitting the package (probably grub2 and grub2-pc, to match current naming, or grub2-legacy or something) undesirable for a number of reasons. A nonexhaustive list of what would need to be satisfactorily resolved before a split could considered: - There needs to be a primary (and probably secondary) package owner from the SIG as a prerequisite for a new bugzilla component. - Everything in grub2-common, grub2-tools, and grub2-tools-extra is available on both UEFI and legacy. In most cases, the content is in fact shared: one file works on both. - The new grub2-bios is secondary to the main grub2 package, which means that the Legacy SIG is responsible for not conflicting with any grub2 subpackage, and nothing in grub2 can depend on anything in the legacy package. - More generally, problems with the shared core can and will manifest primarily on one platform. Bugzilla ping-pong needs to not be played. - Feature incompatibilities can and will occur. (Maybe this is okay, or just the Legacy SIG's responsibility to sort out in all cases.) - Current maintainers do not have much capacity for mentoring, and since the point is to be rid of legacy, we can't help much at all with bugfixes. Be well, --Robbie signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 2:08 PM Vitaly Zaitsev via devel wrote: > > On 14/04/2022 15:31, John Reiser wrote: > > Some of them even have "without data loss" in the page title. > > Without moving data to another physical drive this operation is too > dangerous. > > I tried on my testing VM and lost all data from that VM. Restored snapshot. There are certainly cases where this can happen given the power of the tools that can be used. There are also cases where it has been shown to have worked without issue (if one follows all the steps). Having a backup (and testing it) before one modifies your disk partition is certainly one of the recommended steps. Given that one is far more likely to report the failures than the successes, there is no way to draw any real conclusion about how many failures and successes there are, and their causes, if you are one of those that lost their system you tend to get a strong opinion. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 15:53, Peter Boy wrote: Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson : It should be quite apparent prevent the hw support lifecycle dialog from ever occurring again we need a rigid planned supported hw lifecycle. Again, the legacy BIOS discussion is not about hardware, as implied by the name. It is software and support and management software infrastructure. Bios is a software that is directly tied to hw lifecycle from vendors so it most certainly is (in)directly related to hw support discussion in Fedora. Then there is the fact that clinging to legacy bios is working against Fedora's own foundation "First" in which is stated "Fedora always aims to provide the future, first". JBG JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
It happens that way in some places but not everywhere. I believe someone earlier mentioned how this whole discussion is security theater - some companies know this to be true and have fiscal policies that reflect that. I have direct experience working for a large organization where 3-5 years was more a guideline than a rule. Please be aware of that, is all I am asking here. 7 years is common and some assets I saw in use for well over 10. Hardware security is a factor but by no means the overriding one. Thanks, > On Apr 14, 2022, at 10:47 AM, Jóhann B. Guðmundsson > wrote: > > On 14.4.2022 14:07, Martin Jackson wrote: >> In many industrial and retail use cases, 10 years is the low end. 3-5 years >> is an accounting timeline (for depreciation) not necessarily the useful life >> of the asset. If the asset can be used after it’s done depreciating that is >> a bonus for the company using it. > > > HW security is one reason the companies are replacing their hw after 3-5 > years and in those cases the assets being deprecated are removed from the > premise. > > > JBG > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hans de Goede writes: > On 4/13/22 21:27, David Cantrell wrote: > >> OK, given this proposal, I'd like the original change proposal >> amended to essentially say "transfer legacy BIOS boot support to >> newly formed Legacy BIOS SIG" or something like that. The logistics >> at that point can be sorted out as the SIG sees fit. I'd like to see >> the original proposal advance forward and this gives a plan for the >> legacy BIOS piece. > > TBH I'm not sure if that is the direction in which the proposal owner > (Robbie) wants to go, Robbie ? More complicated than that. As alluded to elsewhere in the thread, a SIG doesn't actually require a change proposal ( https://fedoraproject.org/wiki/Creating_a_Fedora_SIG ) and I'd feel weird proposing the creation of a SIG that I'm not going to participate in. I don't oppose others stepping forward if they wish. Regarding the change proposal itself, there seems to be consensus that legacy bios booting will be going away "eventually", even if for my purposes "eventually" means "we have this mudslinging again in x releases". Absent a formal date or even consensus around what "deprecation" means, I'm not sure what purpose a revised/new proposal would serve at this juncture. > I've send Robbie an offlist email asking him to weigh in here. My pronouns are they/them. Be well, --Robbie signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
I’m not talking about refurbished parts or new old stock. I’m talking about the brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other components that are backwards-compatible in systems pushing twenty years old (SATA) or older (PSUs, fans). Maybe I misunderstand, but your argument seems to be based on the idea that all replacement parts are custom designs tied to OEM support policies rather than commodities based on long-lived standards. It also feels like this is an argument in favor of intentionally forcing people to retire old hardware “for their own good” because it is too unreliable or hard to fix. That isn’t a goal of this Change as far as I can tell, and if you are in fact suggesting that removal of hardware support should be an objective rather than an unfortunate necessity based on limited resources, I don’t think you’ll find much community support for that position. On Thu, Apr 14, 2022, at 11:33 AM, Jóhann B. Guðmundsson wrote: > On 14.4.2022 13:09, Ben Beasley wrote: >> For desktop-class hardware, the parts that are most likely to fail around >> the decade mark are storage drives, power supplies, and perhaps fans. All of >> these are fully standardized and in plentiful supply; there is no reason >> that first-party hardware vendor support should be required to keep old >> desktop systems in service. > > > We need to actually see some real hard data involving those fail parts > from the manufactures themselves and or official repair shops since > there are plethora of "refurbished" hw out there ranging from "cosmetic > imperfections" to outright "motherboard replacements". I've experience > and seen plethora of spectacular computer failures as part of my dayjob > and in my own hw. > > > >> >> Dropping support for old hardware in Fedora should always be based on the >> costs and benefits, not on a rigid planned lifecycle. > > > Well here's the thing this is one of these reoccurring long threaded > discussion ( which means they are stuck in status quo ) that happen > every once in a while, back in the day it used to be Alan Cox that was > advocating for lifetimes support of steam powered devices, today the > dialog involves deprecating legacy bios. > > It should be quite apparent prevent the hw support lifecycle dialog > from ever occurring again we need a rigid planned supported hw > lifecycle. > > That can be 10 years project wide or simply something that each WG > tailors for their own target audience ( shorter, longer that's for them > to decide since they should be doing all the work involving their > "products" and their maintenance ) but as I said we need a rigid > planned supported hw lifecycle, leaving this things are one more time > just means that we will have this dialog again further down the line. > > > > JBG > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson : > > It should be quite apparent prevent the hw support lifecycle dialog from ever > occurring again we need a rigid planned supported hw lifecycle. > Again, the legacy BIOS discussion is not about hardware, as implied by the name. It is software and support and management software infrastructure. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14/04/2022 16:21, John Reiser wrote: Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print) command (then 'q' to quit), both before and after the attempted conversion. I no longer have legacy BIOS configurations. VMs have been reinstalled from scratch after trying to convert them. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 14:07, Martin Jackson wrote: In many industrial and retail use cases, 10 years is the low end. 3-5 years is an accounting timeline (for depreciation) not necessarily the useful life of the asset. If the asset can be used after it’s done depreciating that is a bonus for the company using it. HW security is one reason the companies are replacing their hw after 3-5 years and in those cases the assets being deprecated are removed from the premise. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 13:09, Ben Beasley wrote: For desktop-class hardware, the parts that are most likely to fail around the decade mark are storage drives, power supplies, and perhaps fans. All of these are fully standardized and in plentiful supply; there is no reason that first-party hardware vendor support should be required to keep old desktop systems in service. We need to actually see some real hard data involving those fail parts from the manufactures themselves and or official repair shops since there are plethora of "refurbished" hw out there ranging from "cosmetic imperfections" to outright "motherboard replacements". I've experience and seen plethora of spectacular computer failures as part of my dayjob and in my own hw. Dropping support for old hardware in Fedora should always be based on the costs and benefits, not on a rigid planned lifecycle. Well here's the thing this is one of these reoccurring long threaded discussion ( which means they are stuck in status quo ) that happen every once in a while, back in the day it used to be Alan Cox that was advocating for lifetimes support of steam powered devices, today the dialog involves deprecating legacy bios. It should be quite apparent prevent the hw support lifecycle dialog from ever occurring again we need a rigid planned supported hw lifecycle. That can be 10 years project wide or simply something that each WG tailors for their own target audience ( shorter, longer that's for them to decide since they should be doing all the work involving their "products" and their maintenance ) but as I said we need a rigid planned supported hw lifecycle, leaving this things are one more time just means that we will have this dialog again further down the line. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 5:09 PM Hans de Goede wrote: > > Hi Michel, > > On 4/13/22 22:29, Michel Alexandre Salim wrote: > > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: > >> Hi, > >> > >> > >> 1. I'm not sure if it is possible to setup group ownership > >> of pkgs in pagure? So to keep things simple the few packages which > >> are only necessary for BIOS boot can be handed over to me and then > >> I'll just add other people willing to help out as co-maintainers. > >> > > yup, Python, Rust, and Go SIG does this all the time > > > >> 2. Setup a mailinglist for this and have that in bugzilla + PR > >> Cc for all the relevant packages. > >> > > The group will get emailed just like a normal maintainer, IIRC. Someone > > will need to register that group's email in Bugzilla just like a normal > > account > > Interesting, so how does this work. I just realized that to allow > adding a list to the Cc in pagure (src.fedoraproject.org) it probably > needs a FAS account too and then log in with that account and then > hit the "watch" button ? No, that's not how this usually works. The steps would be something like: 1. request a FAS dist-git group (not a fake-group user, but an actual group!) 2. request a mailing list for this group 3. create a bugzilla account, using the email address of the mailing list 4. set the bugzilla account of the FAS group to be the address of the mailing list This is what we did for the Rust SIG, and the - now defunct - Stewardship SIG and Java Maintainers SIG: https://pagure.io/fedora-infrastructure/issue/7638 https://pagure.io/fedora-infrastructure/issue/8902 Fabio ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hi, On 4/13/22 23:11, Matthew Miller wrote: > On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote: >> If that proves acceptable for change owners here that would perhaps take >> care of the short term problem. What about longer term though? Would the >> thought be that the BIOS sig would remain around for the forseeable >> future maintaining BIOS boot? Or would there be some kind of roadmap to >> retirement? > > I think it would make sense for the group to be set up with with some sort > of "retirement becomes the default if the SIG stops being active" policy. I > mean, not as a surprise, but so the situation is clear. That is fair, although I hope that if the SIG runs out of steam for this, that at least it will still have enough life in it to send out a proper notice about BIOS boot support is really going away. Regards, Hans ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hi Michel, On 4/13/22 22:29, Michel Alexandre Salim wrote: > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: >> Hi, >> >> >> 1. I'm not sure if it is possible to setup group ownership >> of pkgs in pagure? So to keep things simple the few packages which >> are only necessary for BIOS boot can be handed over to me and then >> I'll just add other people willing to help out as co-maintainers. >> > yup, Python, Rust, and Go SIG does this all the time > >> 2. Setup a mailinglist for this and have that in bugzilla + PR >> Cc for all the relevant packages. >> > The group will get emailed just like a normal maintainer, IIRC. Someone > will need to register that group's email in Bugzilla just like a normal > account Interesting, so how does this work. I just realized that to allow adding a list to the Cc in pagure (src.fedoraproject.org) it probably needs a FAS account too and then log in with that account and then hit the "watch" button ? So does this require creating a "fake" FAS account for the SIG ? So the steps would be: 1. Request mailinglist 2. Create FAS account using mailinglist address as email 3. Create bugzilla account using mailinglist address as email ? All I can find on this is: https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/#current_solution Which does not describe haivng actual groups at all ? And I don't see how I can put the mailinglist in the Cc for bugs + PRs without creating a FAS account for it ? Regards, Hans ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hi David, On 4/13/22 21:27, David Cantrell wrote: > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: >> Hi, >> >> On 4/13/22 18:07, David Cantrell wrote: >>> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell wrote: > The core issue still comes down to having resources to continue > maintaining > BIOS boot support in Fedora and so far no one has come forward to work > on > that. It's not true, although you can be forgiven for missing it in such a massive thread. Hans proposed to start a BIOS SIG to handle this. This seems like a very credible proposal. >>> >>> Ah, yes. I do remember the post from Hans, but thought he was more >>> outlining >>> how a Legacy BIOS SIG could work and what would need to happen rather than >>> volunteering to set one up and do that. But I went back and reread that >>> post >>> and yes, he did volunteer to do just that. >> >> Correct. >> >>> If a video call happens to discuss this feature proposal, ensure Hans can >>> attend. >> >> FWIW, ATM I think everything which can be said about >> this has been said and I'm not sure if having a video >> call about this will add anything new. > > Agreed. > >> As for setting up the SIG if necessary, my plan is to >> try to keep the SIG lite weight on the process side >> and focus on the practical things. >> >> What I envision for the SIG is: >> >> 1. I'm not sure if it is possible to setup group ownership >> of pkgs in pagure? So to keep things simple the few packages which >> are only necessary for BIOS boot can be handed over to me and then >> I'll just add other people willing to help out as co-maintainers. >> >> 2. Setup a mailinglist for this and have that in bugzilla + PR >> Cc for all the relevant packages. >> >> 3. Have people from the SIG regularly test Fedora N and >> Fedora N + 1 (after branching) on machines which only support >> BIOS booting and file bugs (if any) + report the results to >> the mailinglist. >> >> 4. Have people from the SIG try to regularly do bugzilla >> triage of relevant packages. >> >> And I would also like to have a discussion about splitting >> the BIOS boot grub bits out into a separate src.rpm >> (using the same Source0 as the main grub) so that this can >> be build by the SIG without needing help from the bootloader >> team (the main grub package can only be built by a few people >> because of secureboot signing). The idea is to avoiding >> bottlenecking on the bootloader team when some BIOS boot bugs >> in grub need to be fixed, quoting from my original email about >> this: >> >> """ >> I've been thinking about how this could be done for grub; also >> because of the issue that the EFI builds of grub need to be >> signed with Fedora's secure boot keys, which means only a few >> people can do grub2 builds atm. >> >> One option which I think we should consider is sticking with >> a single downstream git fork (until we have managed to get >> everything we need upstream), so stick with: >> >> https://github.com/rhboot/grub2/ >> >> As the Source0 provider for the packages and then next to: >> >> https://src.fedoraproject.org/rpms/grub2 >> >> Add a: >> >> https://src.fedoraproject.org/rpms/grub2-bios >> >> And moving the build of all sub-packages which are >> only necessary for BIOS support to the second src.rpm. >> >> This way the Legacy BIOS SIG could maintain >> the grub2-bios src.rpm (and binary pkgs it builds). >> The SIG _must_ then of course still submit pull-reqs to: >> https://github.com/rhboot/grub2/ for any changes. >> >> But in case of e.g. a beta blocking BIOS only bug they >> could solve that with a patch in the src.rpm and kickof >> a build right away without blocking on the bootloader >> team and thus without causing a spike in >> work-pressure/load for the bootloader team. >> >> And then once the pull-req is merged (possibly >> a revised version of it) the next build of >> the grub2-bios src.rpm can pull in the new Source0 >> and drop its local changes (IOW grub2-bios _must_ >> not become a separate fork). >> """ > > OK, given this proposal, I'd like the original change proposal amended to > essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS > SIG" or something like that. The logistics at that point can be sorted out as > the SIG sees fit. I'd like to see the original proposal advance forward and > this gives a plan for the legacy BIOS piece. TBH I'm not sure if that is the direction in which the proposal owner (Robbie) wants to go, Robbie ? > Can you followup with the proposal owners to make that amendment? I've send Robbie an offlist email asking him to weigh in here. Regards, Hans ___ 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/
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Am 14.04.22 um 13:39 schrieb Kevin Kofler via devel: Ralf Corsépius wrote: I do not agree with this statement. Like previous "Legacy SIGs" this is a red herring to obfuscate RHATs lack of disinterest with topics, which do not match into their business objectives. I am also worried that this is just a delayed retirement, as it was for 32- bit i686, where the SIG was very quickly declared a failure, without even being given time to organize. IMO, the 32bit "retirement" never was a serious "retirement" nor a serious attempt "to pass it to the community", either. Some people will find this rude, but I perceived as a long term planned assassination! Ralf ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 07:07, Vitaly Zaitsev via devel wrote: On 14/04/2022 15:31, John Reiser wrote: Some of them even have "without data loss" in the page title. Without moving data to another physical drive this operation is too dangerous. I tried on my testing VM and lost all data from that VM. Restored snapshot. Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print) command (then 'q' to quit), both before and after the attempted conversion. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
In many industrial and retail use cases, 10 years is the low end. 3-5 years is an accounting timeline (for depreciation) not necessarily the useful life of the asset. If the asset can be used after it’s done depreciating that is a bonus for the company using it. Thanks, > On Apr 14, 2022, at 7:24 AM, Jóhann B. Guðmundsson wrote: > > On 14.4.2022 11:42, Kevin Kofler via devel wrote: >> Jóhann B. Guðmundsson wrote: >> >>> For example EU has regulation that requires vendors to have spare parts >>> available for 7–10 years after date of manufacturing so it makes sense >>> for the project to support hw no longer than a decade from the date of >>> it's manufacturing. ( which makes the oldest hw being support being >>> manufactured in 2012 ) and every process,workflows and decision being >>> bound by that. >> Lack of availability of original spare parts does not mean that the hardware >> suddenly magically stops working for everybody. >> > No but it does mean that they cant run indefinitely > > And there needs to be a number on this to adjust users expectation and 10 > years is a reasonable number from a business, parts and recycle/re-use > availability, > > What is unreasonable is to be expecting that it's supported indefinitely from > OS and or HW vendors. > > JBG > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14/04/2022 15:31, John Reiser wrote: Some of them even have "without data loss" in the page title. Without moving data to another physical drive this operation is too dangerous. I tried on my testing VM and lost all data from that VM. Restored snapshot. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 02:01, Vitaly Zaitsev via devel wrote: On 13/04/2022 23:11, Matthew Miller wrote: It'd be cool to see if we can make a bios-to-uefi thing like Clover work. I don't think it's possible because the MBR -> GPT conversion will destroy all partitions on the original drive. An internet search for "convert MBR to GPT" yields many results, including some from authoritative sources including Microsoft and Dell. Some of them even have "without data loss" in the page title. I myself have done this at least twice in 5 years with no data loss, using the 'gdisk' utility (man 8 gdisk) in Fedora. The conversion is particularly easy when the MBR partitions do not cover the first and last 1MB of the drive, which has been a prevalent practice for many years. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 8:58 AM JadoNena wrote: > > Hello, > > > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa > > wrote: > > Thank you very much for your reply. You are one of those several people that > we have been reading has some good sense for users! > > > First: do not panic! > > Of course panic is a bad idea. > I am just observing this largest ever (?), very loud public thread. > Our response is to start planning. It it our "anti-panic" approach and we > work to never kick the can too far along. > > > Second: This is not a foregone conclusion yet. It's merely a > > Yes that is a possibility too. > > But I do not even now see it as a choice to NOT begin to plan and act. > Not with this discussion, even if there are some user-supporting voices. > > > Third: You pay for enterprise support from Red Hat, Inc. That means > > you have the ability to inform Red Hat through your business > > relationship of your needs. > > It is good advice. Of course we are doing that too. > They listen to be sure. The usual action if not the answer is that RedHat is > not Fedora. So use more RedHat. > Of course it is many @redhat voices here, in this Fedora discussion, that > look like they are making these proposals. > It is a circle of logic that we have not so much luck with. > In our experience there is there also a disconnection too often between > revenue, customer requirements, and developers. That is a different > discussion and, today, it does not really matter what "we" think about it, it > is just the way of things. > I've heard this before in the past too. Thankfully nowadays, it's much easier to refute that. While it is true that RHEL is not Fedora and they can (and sometimes do) make substantially different choices for RHEL than Fedora did, they largely don't (especially since they've been burned fairly recently doing that once). With Fedora ELN providing that RHEL-ish build of Fedora Rawhide continuously[1], the goal is to be able to take that to build the next major version of CentOS Stream faster, which directly becomes Red Hat Enterprise Linux[2]. With this information in hand, it's easy to see that Fedora Changes are a good proxy for how future RHEL might evolve, and it's worth giving feedback early about those changes to your Red Hat account team. I certainly know of others who do that with decent success. :) [1]: https://docs.fedoraproject.org/en-US/eln/ [2]: https://www.redhat.com/en/resources/centos-stream-datasheet -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
For desktop-class hardware, the parts that are most likely to fail around the decade mark are storage drives, power supplies, and perhaps fans. All of these are fully standardized and in plentiful supply; there is no reason that first-party hardware vendor support should be required to keep old desktop systems in service. Dropping support for old hardware in Fedora should always be based on the costs and benefits, not on a rigid planned lifecycle. – Ben On 4/14/22 08:25, Jóhann B. Guðmundsson wrote: On 14.4.2022 11:42, Kevin Kofler via devel wrote: Jóhann B. Guðmundsson wrote: For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade from the date of it's manufacturing. ( which makes the oldest hw being support being manufactured in 2012 ) and every process,workflows and decision being bound by that. Lack of availability of original spare parts does not mean that the hardware suddenly magically stops working for everybody. No but it does mean that they cant run indefinitely And there needs to be a number on this to adjust users expectation and 10 years is a reasonable number from a business, parts and recycle/re-use availability, What is unreasonable is to be expecting that it's supported indefinitely from OS and or HW vendors. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hello, > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa > wrote: Thank you very much for your reply. You are one of those several people that we have been reading has some good sense for users! > First: do not panic! Of course panic is a bad idea. I am just observing this largest ever (?), very loud public thread. Our response is to start planning. It it our "anti-panic" approach and we work to never kick the can too far along. > Second: This is not a foregone conclusion yet. It's merely a Yes that is a possibility too. But I do not even now see it as a choice to NOT begin to plan and act. Not with this discussion, even if there are some user-supporting voices. > Third: You pay for enterprise support from Red Hat, Inc. That means > you have the ability to inform Red Hat through your business > relationship of your needs. It is good advice. Of course we are doing that too. They listen to be sure. The usual action if not the answer is that RedHat is not Fedora. So use more RedHat. Of course it is many @redhat voices here, in this Fedora discussion, that look like they are making these proposals. It is a circle of logic that we have not so much luck with. In our experience there is there also a disconnection too often between revenue, customer requirements, and developers. That is a different discussion and, today, it does not really matter what "we" think about it, it is just the way of things. > As for anyone else looking at this thread with RHEL-tinted lenses as > more activist RHEL customers, please direct your feedback to your > account managers. We cross fingers that like you advise maybe those voices that pay the bills will have some effect. Jado ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel wrote: > > > The question is: how many users do we want to leave behind? Or: how many > > users must we leave behind because we can’t do the job. > > We are just users. Our expert development is for other professions than > writing drivers and operating systems. > > My company has about 200 Fedora user PCs around the world. > Plus about 20 servers in real hardware and 30-50 in virtual. > More are in RedHat too but I am not talking about those here. > > We had decided on the RH+Centos+Fedora Eco system. > > All desktops and some laptops (that equals about 170) use NVidia graphics. > In every case we use the NVidia drivers. They are built with the DKIM > software. It is not convenient but it is worth the effort. We can rely on > the NVidia software to work all the time. And we have access to the CUDA code > and so on. > > For the servers plus the user PCs about 60% are on BIOS boot not UEFI. May > be half of those are BIOS only. > > My company has a budget. We do the planning for 2-3 years. > It pays for developers salarys. And for new hardware. And for VPS rental > costs. And for user training. > And for our Enterprise support products and services like RedHat. > > Unplanned and unexpected changes cost to my company a very large amount. > We always plan our strategy to control and best minimize that cost. > We must operate successfully for to pay those salarys and to purchase that > hardware and services. > > All of this discussion waves a red flag at us. > We think we hear that Fedora has philosophy arguments about opensource and > propietary and BIOS and UEFI. > We read the crazy mathematics about numbers of users based on I don't know > what. > > But only a few people are talking about the real costs to users. > > Okay, the developers here are interested only in what makes the life easier > for them. > And want to not have "3rd party vendors now dictate" decisions. > I can understand that theory too. > > But for here we deal with the real world where budgets require plans and > hardware exists for years. > With this decision making the red flag means that "today & now" we must start > with planning for alternatives to the RH+Centos+Fedora Eco system. > > We did not expect this from the RH+Centos+Fedora Eco system. > That maybe is our mistake? > > And that is all just one person at one company's opinion. > First: ***do not panic!*** Second: This is not a foregone conclusion yet. It's merely a ***proposal***, and one that most of the community has reacted negatively to. It may happen someday, but we *do* care about our larger ecosystem and user community. Chances are pretty good we'll have the capability to work with legacy BIOS boot on x86_64 machines for a few more years. Third: You pay for enterprise support from Red Hat, Inc. That means you have the ability to inform Red Hat through your business relationship of your needs. That subscription you pay for your RHEL systems allows you a direct relationship and influence over *their* roadmap. If you tell them that this would be a problem if it made its way into RHEL, they will account for that in their roadmap planning. Take advantage of that capability and talk to your account manager about it. It's their job to listen to your concerns and ensure that is accounted for. That's the value of the Red Hat Enterprise Linux subscription you pay for! As for anyone else looking at this thread with RHEL-tinted lenses as more activist RHEL customers, please direct your feedback to your account managers. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 12:18, JadoNena via devel wrote: But for here we deal with the real world where budgets require plans and hardware exists for years. If you are dealing with the real world with real businesses then you should be aware of the fact that businesses are usually on a 3 - 5 year hw replacement cycle since it save costs as studies like these have found [¹]. After 3 - 5 years those computers are introduced into the re-use/recycle ecosystem and re-purposed elsewhere with the hw vendors being forced to support that cycle. With 10 years of hw support in fedora it would fit nicely into that cycle. That said obviously companies will lose that cost saving if they end up having to spend it in a license cost elsewhere, be it Red Hat, Microsoft or something else.. JBG 1. https://news.microsoft.com/en-nz/2018/10/16/true-cost-of-not-replacing-computers-revealed-in-microsoft-study-more-than-4000-each/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> Am 14.04.2022 um 14:05 schrieb Jóhann B. Guðmundsson : > > On 14.4.2022 11:53, Peter Boy wrote: >> >>> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson : >>> >>> For example EU has regulation that requires vendors to have spare parts >>> available for 7–10 years after date of manufacturing so it makes sense for >>> the project to support hw no longer than a decade from the date of it's >>> manufacturing. ( which makes the oldest hw being support being manufactured >>> in 2012 ) and every process,workflows and decision being bound by that. >>> >>> Is Fedora an distribution that does not revert but always transforms, rolls >>> out and moves forward or is it an distribution that is stuck in the past ( >>> from a software and hardware point of view )? >> Sorry, you simple didn’t get the point. It is not just about hardware. Some >> Cloud providers doesn’t support UEFI boot at the moment - so said various >> voices from Cloud WG. And some data center insist ob BIOS boot because of >> whatever, presumably management infrastructure. So, the hardware does or >> does not support UEFI, doesn’t matter in these cases. > > > So you are saying that 3rd party vendors ( cloud providers ) now dictate and > decide the direction of the project? > Nobody dictates anything. The provider has its good reasons, whatever it is. And Fedora has its own reasons. As I said, it’s just our decision: how many users do we want to leave behind. Or can we think of a good solution and find the strength to organize it so that we don't lose any users or as few as possible. It's our problem, not anyone else's. Or: how much do we care about our users? And how connected do we feel to our users? ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 01:42:26PM +0200, Kevin Kofler via devel wrote: > Jóhann B. Guðmundsson wrote: > > In this case that SIG would be created for no good reason since the > > outcome is inevitable. > > I still do not see what is inevitable about the outcome. Keeping legacy, no > longer changing, interfaces working forever should require next to no > effort. So the SIG would have next to no work to do. Great! In reality, distribution around BIOS booting change, compilers change, there is always some effort required even to maintain status quo. -- Tomasz Torcz “Never underestimate the bandwidth of a station to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 11:42, Kevin Kofler via devel wrote: Jóhann B. Guðmundsson wrote: For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade from the date of it's manufacturing. ( which makes the oldest hw being support being manufactured in 2012 ) and every process,workflows and decision being bound by that. Lack of availability of original spare parts does not mean that the hardware suddenly magically stops working for everybody. No but it does mean that they cant run indefinitely And there needs to be a number on this to adjust users expectation and 10 years is a reasonable number from a business, parts and recycle/re-use availability, What is unreasonable is to be expecting that it's supported indefinitely from OS and or HW vendors. JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> The question is: how many users do we want to leave behind? Or: how many > users must we leave behind because we can’t do the job. We are just users. Our expert development is for other professions than writing drivers and operating systems. My company has about 200 Fedora user PCs around the world. Plus about 20 servers in real hardware and 30-50 in virtual. More are in RedHat too but I am not talking about those here. We had decided on the RH+Centos+Fedora Eco system. All desktops and some laptops (that equals about 170) use NVidia graphics. In every case we use the NVidia drivers. They are built with the DKIM software. It is not convenient but it is worth the effort. We can rely on the NVidia software to work all the time. And we have access to the CUDA code and so on. For the servers plus the user PCs about 60% are on BIOS boot not UEFI. May be half of those are BIOS only. My company has a budget. We do the planning for 2-3 years. It pays for developers salarys. And for new hardware. And for VPS rental costs. And for user training. And for our Enterprise support products and services like RedHat. Unplanned and unexpected changes cost to my company a very large amount. We always plan our strategy to control and best minimize that cost. We must operate successfully for to pay those salarys and to purchase that hardware and services. All of this discussion waves a red flag at us. We think we hear that Fedora has philosophy arguments about opensource and propietary and BIOS and UEFI. We read the crazy mathematics about numbers of users based on I don't know what. But only a few people are talking about the real costs to users. Okay, the developers here are interested only in what makes the life easier for them. And want to not have "3rd party vendors now dictate" decisions. I can understand that theory too. But for here we deal with the real world where budgets require plans and hardware exists for years. With this decision making the red flag means that "today & now" we must start with planning for alternatives to the RH+Centos+Fedora Eco system. We did not expect this from the RH+Centos+Fedora Eco system. That maybe is our mistake? And that is all just one person at one company's opinion. Jado ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 11:53, Peter Boy wrote: Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson : For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade from the date of it's manufacturing. ( which makes the oldest hw being support being manufactured in 2012 ) and every process,workflows and decision being bound by that. Is Fedora an distribution that does not revert but always transforms, rolls out and moves forward or is it an distribution that is stuck in the past ( from a software and hardware point of view )? Sorry, you simple didn’t get the point. It is not just about hardware. Some Cloud providers doesn’t support UEFI boot at the moment - so said various voices from Cloud WG. And some data center insist ob BIOS boot because of whatever, presumably management infrastructure. So, the hardware does or does not support UEFI, doesn’t matter in these cases. So you are saying that 3rd party vendors ( cloud providers ) now dictate and decide the direction of the project? JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson : > > For example EU has regulation that requires vendors to have spare parts > available for 7–10 years after date of manufacturing so it makes sense for > the project to support hw no longer than a decade from the date of it's > manufacturing. ( which makes the oldest hw being support being manufactured > in 2012 ) and every process,workflows and decision being bound by that. > > Is Fedora an distribution that does not revert but always transforms, rolls > out and moves forward or is it an distribution that is stuck in the past ( > from a software and hardware point of view )? Sorry, you simple didn’t get the point. It is not just about hardware. Some Cloud providers doesn’t support UEFI boot at the moment - so said various voices from Cloud WG. And some data center insist ob BIOS boot because of whatever, presumably management infrastructure. So, the hardware does or does not support UEFI, doesn’t matter in these cases. And there is obviously some hardware around younger than 10 years that don’t support UEFI, at least not without problems. And yes, there is some hardware older than 10 years. Currently Linux is known to support older hardware. Do we want to ditch that? Nevertheless, old or new hardware is not the issue. The question is: how many users do we want to leave behind? Or: how many users must we leave behind because we can’t do the job. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > In this case that SIG would be created for no good reason since the > outcome is inevitable. I still do not see what is inevitable about the outcome. Keeping legacy, no longer changing, interfaces working forever should require next to no effort. > For how long should fedora support any given hardware ( electric > components do not last forever ) ? Ideally, as long as there is at least one person still using it. In practice, it probably requires more than one person, but the user base for legacy BIOS is still large judging from the feedback in the thread. > For example EU has regulation that requires vendors to have spare parts > available for 7–10 years after date of manufacturing so it makes sense > for the project to support hw no longer than a decade from the date of > it's manufacturing. ( which makes the oldest hw being support being > manufactured in 2012 ) and every process,workflows and decision being > bound by that. Lack of availability of original spare parts does not mean that the hardware suddenly magically stops working for everybody. > Is Fedora an distribution that does not revert but always transforms, > rolls out and moves forward or is it an distribution that is stuck in > the past ( from a software and hardware point of view )? Running on both old and new hardware does not preclude in any way shipping the most recent software. This is a false dichotomy. Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 13. 04. 22 22:29, Michel Alexandre Salim wrote: On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: Hi, 1. I'm not sure if it is possible to setup group ownership of pkgs in pagure? So to keep things simple the few packages which are only necessary for BIOS boot can be handed over to me and then I'll just add other people willing to help out as co-maintainers. yup, Python, Rust, and Go SIG does this all the time No, Python SIG does not. Each package needs a primary maintainer. The SIG co-maintains it. There are some exceptions when somebody set Python SIG as the primary point of contact, but pagure still tracks the "main admin" user/person -- this cannot be a group. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Ralf Corsépius wrote: > I do not agree with this statement. Like previous "Legacy SIGs" this is > a red herring to obfuscate RHATs lack of disinterest with topics, which > do not match into their business objectives. I am also worried that this is just a delayed retirement, as it was for 32- bit i686, where the SIG was very quickly declared a failure, without even being given time to organize. Still, it is better than retiring it immediately. But like you, I am worried that this is not really a long-term commitment and that people will be attempting to kill BIOS support again at even the smallest dent in SIG activity. Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 9:12 PM Matthew Miller wrote: > It'd be cool to see if we can make a bios-to-uefi thing like Clover work. > That might be something interesting for the SIG to do. But, I don't think > that's really a small project! This is mostly off topic, and while I have not carefully tracked the project in recent years, the clover uefi emulator has been said to work a lot of the time out of the box, but due to some of the ways that vendors choose to implement bios features/tables it can require complex configuration, typically unique for that particular system (type). I also seem to recall there were some utilities to try to assist figuring out that configuration, but those were not always for the faint of heart. The hard part (as is usually the case) was dealing with those edge cases, even as the clover project has a lot of documentation trying to help. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 14.4.2022 09:17, Tomasz Torcz wrote: On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote: Am 13.04.22 um 20:05 schrieb David Cantrell: The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in Fedora. I do not agree with this statement. Like previous "Legacy SIGs" this is a red herring to obfuscate RHATs lack of disinterest with topics, which do not match into their business objectives. Really? Fedora is mainly a volunteer effort, someone has to do the work. SIG is a good solution. RedHat is under no obligation to work on everything. Anything that adds to the bureaucracy level of a project or community in general is never a good thing since such process gets in the way of the people that are actually doing all the work ( more often than not too much energy spent on bureaucracy than the actual work itself ). In this case that SIG would be created for no good reason since the outcome is inevitable. What the project needs to decide upon is... For how long should fedora support any given hardware ( electric components do not last forever ) ? For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade from the date of it's manufacturing. ( which makes the oldest hw being support being manufactured in 2012 ) and every process,workflows and decision being bound by that. Is Fedora an distribution that does not revert but always transforms, rolls out and moves forward or is it an distribution that is stuck in the past ( from a software and hardware point of view )? JBG ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote: > > > Am 13.04.22 um 20:05 schrieb David Cantrell: > > > The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work > > in > > Fedora. > > I do not agree with this statement. Like previous "Legacy SIGs" this is a > red herring to obfuscate RHATs lack of disinterest with topics, which do not > match into their business objectives. Really? Fedora is mainly a volunteer effort, someone has to do the work. SIG is a good solution. RedHat is under no obligation to work on everything. -- Tomasz Torcz “Never underestimate the bandwidth of a station to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 13/04/2022 23:11, Matthew Miller wrote: It'd be cool to see if we can make a bios-to-uefi thing like Clover work. I don't think it's possible because the MBR -> GPT conversion will destroy all partitions on the original drive. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Am 13.04.22 um 20:05 schrieb David Cantrell: The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in Fedora. I do not agree with this statement. Like previous "Legacy SIGs" this is a red herring to obfuscate RHATs lack of disinterest with topics, which do not match into their business objectives. Ralf ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Thu, Apr 14, 2022 at 12:38 AM Kevin Kofler via devel wrote: > > Matthew Miller wrote: > > We've got a 300+ message thread in just one week, with 66 different > > participants. This handily beats discussions systemd-resolved, > > btrfs-by-default, and even switching the default editor to nano. > > > > Clearly there's a lot to talk about here. Would it be useful to have a > > high-bandwidth, moderated conversation via video call about the best path > > forward? > > No. The consensus in the mailing list is pretty clear, so I do not see why > we should move the discussion to another medium… > > > (Because of the number of likely participants, Jitsi probably won't cut > > it, so this would likely be via Bluejeans.) > > … and a proprietary one at that! > > Unless somebody is not happy with the outcome of the discussion on the > mailing list (which is that dropping BIOS support at this time is clearly > not acceptable) and hopes to get another outcome on another medium. Actually, I came out of the discussion with an understand that results in the same (current) status, but has different implications, which is that as long as there are a sufficient number of individuals with competency who are willing to put their own resources (time/effort) into legacy BIOS support it will continue. So I think those of us with BIOS only systems thank you for your commitment of your time and effort (and understand when you and others no longer have those "free" resources to invest). So thank you Kevin for committing your time/effort. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Neal Gompa wrote: > The binary RPM for grub's BIOS boot code is grub2-pc (and > grub2-pc-modules), not grub2. Oh, it used to be just grub2 until F26 (included), I had either forgotten or not noticed at all that it had been renamed back in F27 already. (It used to be the case for years that grub2 was BIOS GRUB and grub2-efi was UEFI GRUB, I still do not see what the point in changing that was.) Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 8:45 PM Kevin Kofler via devel wrote: > > Hans de Goede wrote: > > As the Source0 provider for the packages and then next to: > > > > https://src.fedoraproject.org/rpms/grub2 > > > > Add a: > > > > https://src.fedoraproject.org/rpms/grub2-bios > > > > And moving the build of all sub-packages which are > > only necessary for BIOS support to the second src.rpm. > > > > This way the Legacy BIOS SIG could maintain > > the grub2-bios src.rpm (and binary pkgs it builds). > > Would it not make more sense to rename the locked down grub2 SRPM that will > become UEFI only to grub2-efi and let grub2 be the BIOS one, to match the > naming of the binary RPMs (which are already split)? > The binary RPM for grub's BIOS boot code is grub2-pc (and grub2-pc-modules), not grub2. But "grub2-pc" is not particularly descriptive as a source package name, so grub2-bios makes sense for the source package name if we need to split it. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hans de Goede wrote: > As the Source0 provider for the packages and then next to: > > https://src.fedoraproject.org/rpms/grub2 > > Add a: > > https://src.fedoraproject.org/rpms/grub2-bios > > And moving the build of all sub-packages which are > only necessary for BIOS support to the second src.rpm. > > This way the Legacy BIOS SIG could maintain > the grub2-bios src.rpm (and binary pkgs it builds). Would it not make more sense to rename the locked down grub2 SRPM that will become UEFI only to grub2-efi and let grub2 be the BIOS one, to match the naming of the binary RPMs (which are already split)? Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Matthew Miller wrote: > We've got a 300+ message thread in just one week, with 66 different > participants. This handily beats discussions systemd-resolved, > btrfs-by-default, and even switching the default editor to nano. > > Clearly there's a lot to talk about here. Would it be useful to have a > high-bandwidth, moderated conversation via video call about the best path > forward? No. The consensus in the mailing list is pretty clear, so I do not see why we should move the discussion to another medium… > (Because of the number of likely participants, Jitsi probably won't cut > it, so this would likely be via Bluejeans.) … and a proprietary one at that! Unless somebody is not happy with the outcome of the discussion on the mailing list (which is that dropping BIOS support at this time is clearly not acceptable) and hopes to get another outcome on another medium. Kevin Kofler ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote: > If that proves acceptable for change owners here that would perhaps take > care of the short term problem. What about longer term though? Would the > thought be that the BIOS sig would remain around for the forseeable > future maintaining BIOS boot? Or would there be some kind of roadmap to > retirement? I think it would make sense for the group to be set up with with some sort of "retirement becomes the default if the SIG stops being active" policy. I mean, not as a surprise, but so the situation is clear. It'd be cool to see if we can make a bios-to-uefi thing like Clover work. That might be something interesting for the SIG to do. But, I don't think that's really a small project! -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 03:27:14PM -0400, David Cantrell wrote: > > FWIW, ATM I think everything which can be said about > > this has been said and I'm not sure if having a video > > call about this will add anything new. > Agreed. Works for me -- I just wanted to put the option there in case it _would_ be helpful. -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: > Hi, > > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. > yup, Python, Rust, and Go SIG does this all the time > 2. Setup a mailinglist for this and have that in bugzilla + PR > Cc for all the relevant packages. > The group will get emailed just like a normal maintainer, IIRC. Someone will need to register that group's email in Bugzilla just like a normal account Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
...snip bios sig plan... Thanks for that Hans! If that proves acceptable for change owners here that would perhaps take care of the short term problem. What about longer term though? Would the thought be that the BIOS sig would remain around for the forseeable future maintaining BIOS boot? Or would there be some kind of roadmap to retirement? kevin signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: > Hi, > > On 4/13/22 18:07, David Cantrell wrote: > > On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: > >> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell > >> wrote: > >>> The core issue still comes down to having resources to continue > >>> maintaining > >>> BIOS boot support in Fedora and so far no one has come forward to work > >>> on > >>> that. > >> > >> It's not true, although you can be forgiven for missing it in such a > >> massive > >> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a > >> very credible proposal. > > > > Ah, yes. I do remember the post from Hans, but thought he was more > > outlining > > how a Legacy BIOS SIG could work and what would need to happen rather than > > volunteering to set one up and do that. But I went back and reread that > > post > > and yes, he did volunteer to do just that. > > Correct. > > > If a video call happens to discuss this feature proposal, ensure Hans can > > attend. > > FWIW, ATM I think everything which can be said about > this has been said and I'm not sure if having a video > call about this will add anything new. Agreed. > As for setting up the SIG if necessary, my plan is to > try to keep the SIG lite weight on the process side > and focus on the practical things. > > What I envision for the SIG is: > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. > > 2. Setup a mailinglist for this and have that in bugzilla + PR > Cc for all the relevant packages. > > 3. Have people from the SIG regularly test Fedora N and > Fedora N + 1 (after branching) on machines which only support > BIOS booting and file bugs (if any) + report the results to > the mailinglist. > > 4. Have people from the SIG try to regularly do bugzilla > triage of relevant packages. > > And I would also like to have a discussion about splitting > the BIOS boot grub bits out into a separate src.rpm > (using the same Source0 as the main grub) so that this can > be build by the SIG without needing help from the bootloader > team (the main grub package can only be built by a few people > because of secureboot signing). The idea is to avoiding > bottlenecking on the bootloader team when some BIOS boot bugs > in grub need to be fixed, quoting from my original email about > this: > > """ > I've been thinking about how this could be done for grub; also > because of the issue that the EFI builds of grub need to be > signed with Fedora's secure boot keys, which means only a few > people can do grub2 builds atm. > > One option which I think we should consider is sticking with > a single downstream git fork (until we have managed to get > everything we need upstream), so stick with: > > https://github.com/rhboot/grub2/ > > As the Source0 provider for the packages and then next to: > > https://src.fedoraproject.org/rpms/grub2 > > Add a: > > https://src.fedoraproject.org/rpms/grub2-bios > > And moving the build of all sub-packages which are > only necessary for BIOS support to the second src.rpm. > > This way the Legacy BIOS SIG could maintain > the grub2-bios src.rpm (and binary pkgs it builds). > The SIG _must_ then of course still submit pull-reqs to: > https://github.com/rhboot/grub2/ for any changes. > > But in case of e.g. a beta blocking BIOS only bug they > could solve that with a patch in the src.rpm and kickof > a build right away without blocking on the bootloader > team and thus without causing a spike in > work-pressure/load for the bootloader team. > > And then once the pull-req is merged (possibly > a revised version of it) the next build of > the grub2-bios src.rpm can pull in the new Source0 > and drop its local changes (IOW grub2-bios _must_ > not become a separate fork). > """ OK, given this proposal, I'd like the original change proposal amended to essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS SIG" or something like that. The logistics at that point can be sorted out as the SIG sees fit. I'd like to see the original proposal advance forward and this gives a plan for the legacy BIOS piece. Can you followup with the proposal owners to make that amendment? Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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 Do not reply to spam on the list, report it: https://pagur
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hi, On 4/13/22 18:07, David Cantrell wrote: > On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: >> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell >> wrote: >>> The core issue still comes down to having resources to continue >>> maintaining >>> BIOS boot support in Fedora and so far no one has come forward to work >>> on >>> that. >> >> It's not true, although you can be forgiven for missing it in such a massive >> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a >> very credible proposal. > > Ah, yes. I do remember the post from Hans, but thought he was more outlining > how a Legacy BIOS SIG could work and what would need to happen rather than > volunteering to set one up and do that. But I went back and reread that post > and yes, he did volunteer to do just that. Correct. > If a video call happens to discuss this feature proposal, ensure Hans can > attend. FWIW, ATM I think everything which can be said about this has been said and I'm not sure if having a video call about this will add anything new. As for setting up the SIG if necessary, my plan is to try to keep the SIG lite weight on the process side and focus on the practical things. What I envision for the SIG is: 1. I'm not sure if it is possible to setup group ownership of pkgs in pagure? So to keep things simple the few packages which are only necessary for BIOS boot can be handed over to me and then I'll just add other people willing to help out as co-maintainers. 2. Setup a mailinglist for this and have that in bugzilla + PR Cc for all the relevant packages. 3. Have people from the SIG regularly test Fedora N and Fedora N + 1 (after branching) on machines which only support BIOS booting and file bugs (if any) + report the results to the mailinglist. 4. Have people from the SIG try to regularly do bugzilla triage of relevant packages. And I would also like to have a discussion about splitting the BIOS boot grub bits out into a separate src.rpm (using the same Source0 as the main grub) so that this can be build by the SIG without needing help from the bootloader team (the main grub package can only be built by a few people because of secureboot signing). The idea is to avoiding bottlenecking on the bootloader team when some BIOS boot bugs in grub need to be fixed, quoting from my original email about this: """ I've been thinking about how this could be done for grub; also because of the issue that the EFI builds of grub need to be signed with Fedora's secure boot keys, which means only a few people can do grub2 builds atm. One option which I think we should consider is sticking with a single downstream git fork (until we have managed to get everything we need upstream), so stick with: https://github.com/rhboot/grub2/ As the Source0 provider for the packages and then next to: https://src.fedoraproject.org/rpms/grub2 Add a: https://src.fedoraproject.org/rpms/grub2-bios And moving the build of all sub-packages which are only necessary for BIOS support to the second src.rpm. This way the Legacy BIOS SIG could maintain the grub2-bios src.rpm (and binary pkgs it builds). The SIG _must_ then of course still submit pull-reqs to: https://github.com/rhboot/grub2/ for any changes. But in case of e.g. a beta blocking BIOS only bug they could solve that with a patch in the src.rpm and kickof a build right away without blocking on the bootloader team and thus without causing a spike in work-pressure/load for the bootloader team. And then once the pull-req is merged (possibly a revised version of it) the next build of the grub2-bios src.rpm can pull in the new Source0 and drop its local changes (IOW grub2-bios _must_ not become a separate fork). """ Regards, Hans ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 09:34:18AM -0700, Samuel Sieb wrote: > On 4/13/22 07:54, David Cantrell wrote: > > The core issue still comes down to having resources to continue maintaining > > BIOS boot support in Fedora and so far no one has come forward to work on > > that. > > As far as I can tell from the responses in the other thread, there is not > currently an issue with BIOS support. This is merely a belief that it will > become a problem in the future. Given that supposedly no more BIOS-only > computers are being made, why are you expecting future problems since > nothing will change from where it is now? What you are describing is not a zero-maintenance issue. Even if nothing changes around BIOS boot support in the software, the entire OS around it changes which means as a component of the OS, the boot loader needs ongoing maintenance to ensure it continues to build and work. For example, consider new releases of gcc and binutils. The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in Fedora. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/13/22 07:54, David Cantrell wrote: The core issue still comes down to having resources to continue maintaining BIOS boot support in Fedora and so far no one has come forward to work on that. As far as I can tell from the responses in the other thread, there is not currently an issue with BIOS support. This is merely a belief that it will become a problem in the future. Given that supposedly no more BIOS-only computers are being made, why are you expecting future problems since nothing will change from where it is now? ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: > On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell > wrote: > > The core issue still comes down to having resources to continue > > maintaining > > BIOS boot support in Fedora and so far no one has come forward to work > > on > > that. > > It's not true, although you can be forgiven for missing it in such a massive > thread. Hans proposed to start a BIOS SIG to handle this. This seems like a > very credible proposal. Ah, yes. I do remember the post from Hans, but thought he was more outlining how a Legacy BIOS SIG could work and what would need to happen rather than volunteering to set one up and do that. But I went back and reread that post and yes, he did volunteer to do just that. If a video call happens to discuss this feature proposal, ensure Hans can attend. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell wrote: The core issue still comes down to having resources to continue maintaining BIOS boot support in Fedora and so far no one has come forward to work on that. It's not true, although you can be forgiven for missing it in such a massive thread. Hans proposed to start a BIOS SIG to handle this. This seems like a very credible proposal. Michael ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Tue, Apr 12, 2022 at 07:20:52PM -0400, Matthew Miller wrote: > We've got a 300+ message thread in just one week, with 66 different > participants. This handily beats discussions systemd-resolved, > btrfs-by-default, and even switching the default editor to nano. > > Clearly there's a lot to talk about here. Would it be useful to have a > high-bandwidth, moderated conversation via video call about the best path > forward? > > (Because of the number of likely participants, Jitsi probably won't cut it, > so this would likely be via Bluejeans.) > > It'll obviously be difficult to find a time where _everyone_ can > participate, so this wouldn't be a deciding-things meeting, rather a > "talking about possibilities and hopefully coming to more mutual > understanding" meeting. And I would make sure there are good notes.* > > > (* volunteers who are good at note taking welcome!) Here are some thread stats I took just now: Overall statistics -- Total number of messages: 310 Number of messages that is a reply: 306 (98.71%) Total size: 4191268 Average size: 13520 Total number of writers: 78 Number of people who wrote >1 message: 37 (47.44%) Top writers | # msgs|av size| total|time | e-mail address ---+---+---+--+-+ 1] 40| 14224|568978|13:24| neal gompa 2] 33| 11715|386622|13:30| devel@lists.fedoraproject.org 3] 31| 13173|408389|13:19| robbie harwood 4] 29| 13091|379662|14:56| chris murphy 5] 15| 21574|323617|14:26| jared dominguez 6] 13| 11834|153851|13:37| dominik 'rathann' mierzejewski 7] 11| 19316|212484|17:23| demi marie obenour 8] 8| 10816| 86533|12:56| chris adams 9] 8| 16190|129527|11:26| "thomas schmitt" 10] 8| 11985| 95880|07:52| gary buhrmaster While the thread is busy, here are the top participants (with #2 excepted). The core issue still comes down to having resources to continue maintaining BIOS boot support in Fedora and so far no one has come forward to work on that. If a video call can come up with a community plan to do that, I would say it might be worth it. Otherwise it may just be a continuing of the thread as it is now. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure