On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez <jar...@redhat.com> wrote: > > > > > On Thu, Apr 7, 2022, 19:46 Samuel Sieb <sam...@sieb.net> wrote: >> >> On 4/7/22 14:51, Jared Dominguez wrote: >> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <sam...@sieb.net >> > <mailto:sam...@sieb.net>> 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. 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@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
