Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Apr 8, 2022, 11:52 Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez <jaredz@xxxxxxxxxx> wrote:
>
>
>
>
> On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel@xxxxxxxx> wrote:
>>
>> On 4/7/22 14:51, Jared Dominguez wrote:
>> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@xxxxxxxx
>> > <mailto:samuel@xxxxxxxx>> wrote:
>> >
>> >     On 4/7/22 08:02, Jared Dominguez wrote:
>> >      > This is a proposal. Nothing has changed yet. The choice is now
>> >     whether
>> >      > to go forward with it or come together with a cohesive
>> >      > alternative, including one of the two listed in the proposal. But we
>> >      > need a solution that accounts for the existing maintainers not
>> >     having
>> >      > capacity to continue maintaining legacy code. I've seen responses
>> >     from
>> >
>> >     I haven't yet seen a clear answer about what code is "rotting" and
>> >     which
>> >     legacy code is too hard to maintain.  Is there something actually
>> >     broken
>> >     right now?
>> >
>> >
>> > For one, syslinux hasn't seen an update in 3 years and a release in 7
>> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>> > getting development attention. The current maintainers in Fedora won't
>> > have capacity to continue maintaining legacy boot support in Fedora. As
>> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>> > not to mention non-UEFI ppc64le and s390x), there is added risk of
>> > regressions on legacy x86 boot that won't be getting developer attention.
>>
>> I don't understand why we're still using syslinux instead of grub for
>> legacy boots, especially since I think now you can use the same grub.cfg
>> file for both.
>
>
> It's development and validation work for something that's not a priority for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
>
>> There is always a risk of regressions, but if there is
>> no current problem, then why is there this push to obsolete a lot of
>> active hardware?
>
>
> There is a problem: the current maintainers don't have capacity to support legacy x86 boot anymore. The code is going to bit rot if no one steps up to fill in.
>
>> This is not comparable to the 32-bit removal where it
>> was only a few really old systems.  This is going to affect decent
>> systems that are less than 10 years old.  I have a work HP laptop from
>> 2012 that has "experimental" EFI support that really doesn't work well
>> and possibly a newer one as well, but I can't check it right now.
>
>
> I'm curious if you've updated your BIOS on that system. If it's really that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
>

Why? It works for Windows, and HP has only done token support for
other platforms over the past decade (see most recent thing promoting
WSL as a good Linux on HP experience[1]). All of my HP computers have
been extremely difficult to get Linux working on properly, which is
why I stopped buying them.

If the experience is buggy with Windows too, HP probably has addressed that as previously stated, which is why I asked about how up-to-date Samuel's BIOS is. On several occasions I've seen complaints about firmware issues that are solved by updating. Firmware is software too.

If not, that sounds like a big in Fedora and possibly Linux in general. Windows is the reference operating system for most personal computer manufacturers, whether we like it or not.

Just because Dell is sometimes good at its job doesn't mean everyone
else is. The reality is that most aren't.

[1]: https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collaboration-workflows.html



--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux