Announcement

Collapse
No announcement yet.

Fedora Developers Discussing Possibility Of Dropping Legacy BIOS Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by AmericanLocomotive View Post
    You're neglecting the fact that SeaBIOS is the coreboot default payload. It's also the most mature, least buggy and most easy to compile payload available for coreboot right now. Many people experience issues getting TianoCore to work correctly or even compile.
    That too shows the true uselessness of UEFI: if UEFI was really that beautiful and vitally important for modern computing, the coreboot community members would've fixed these Tianocore issues long ago. I'm one of those people - have been contributing to coreboot since 2016 - and I haven't ever bothered even trying to run this UEFI crap on any of my coreboot machines.

    Comment


    • Originally posted by AmericanLocomotive View Post
      You're neglecting the fact that SeaBIOS is the coreboot default payload. It's also the most mature, least buggy and most easy to compile payload available for coreboot right now. Many people experience issues getting TianoCore to work correctly or even compile.
      Mr. Chromebox seems to do just fine with it. Ditto for that Raspberry Pi project.

      Comment


      • Originally posted by AmericanLocomotive View Post
        You're neglecting the fact that SeaBIOS is the coreboot default payload. It's also the most mature, least buggy and most easy to compile payload available for coreboot right now. Many people experience issues getting TianoCore to work correctly or even compile.
        Do you even know what you're talking about? TianoCore doesn't need Coreboot - it can do hardware init on it's own. People choose SeaBIOS because they need BIOS emulation. It's funny because people are using SeaBIOS with Coreboot because...what? They're not booting Linux on it? Coreboot can boot Linux natively. So they're using an open source hardware init to boot closed source operating systems? That's hilarious!

        Comment


        • Originally posted by michaelb1 View Post
          That too shows the true uselessness of UEFI: if UEFI was really that beautiful and vitally important for modern computing, the coreboot community members would've fixed these Tianocore issues long ago. I'm one of those people - have been contributing to coreboot since 2016 - and I haven't ever bothered even trying to run this UEFI crap on any of my coreboot machines.
          Who uses a payload for an open source firmware? Linux can be used as a payload with Coreboot already without SeaBIOS. You only use a payload to run an alternate operating system and what else are you going to use on it? Closed-source Windows?? What a laugh.

          Comment


          • Originally posted by michaelb1 View Post
            That too shows the true uselessness of UEFI: if UEFI was really that beautiful and vitally important for modern computing, the coreboot community members would've fixed these Tianocore issues long ago. I'm one of those people - have been contributing to coreboot since 2016 - and I haven't ever bothered even trying to run this UEFI crap on any of my coreboot machines.
            You're trying to turn this into an argument of the usefulness of UEFI over BIOS. It's about whether or not it's a good idea to drop BIOS support. The answer is short term - no, long term - maybe.

            - The corporate world moved on to UEFI a long time ago, except for maybe some really cash strapped holdouts, but they're probably not running Linux anyways
            - CoreBoot SeaBIOS Fedora users represent an extremely tiny portion of Fedora Linux users who represent a tiny portion of FOSS Linux desktop users who represent an extremely tiny portion of all desktop users. This decision would affect what, 200 - maybe 300 people in the entire world? If anything, it would just push a few developers over to TianoCore or other UEFI payloads to make them more viable.

            The only real reason they should delay this change is because of the number of systems from the 2009-2011 era that were BIOS-only, but still very viable today. However even then, many of those systems are UEFI compatible, with basically all systems 2012 and newer having UEFI support. With the current advancement of multi-core CPUs, I think those older systems realistically only have 2-3 "good" years left before they get too slow for modern software and browsers. So in 2022 or so, I think it'd be "safe" to drop legacy BIOS support.
            Originally posted by Giovanni Fabbro View Post

            Mr. Chromebox seems to do just fine with it. Ditto for that Raspberry Pi project.
            I never claimed it didn't work (clearly it has to work), just that many people have more problems with Tianocore than SeaBIOS.
            Do you even know what you're talking about? TianoCore doesn't need Coreboot - it can do hardware init on it's own.
            You should take that up with the CoreBoot people then. I'm not saying that the below is correct, but it's what's on the official CoreBoot wiki.

            "TianoCore is an open source implementation of UEFI, the Unified Extensible Firmware Interface. UEFI (formerly EFI) is intended to replace the traditional PC BIOS. TianoCore as in implementation cannot do that, as it lacks the code to do hardware initalization. Since hardware initialization is exactly what coreboot does, the combination of coreboot + TianoCore is the most straightforward option to provide a complete, opensource UEFI environment"
            Last edited by AmericanLocomotive; 02 July 2020, 01:15 PM.

            Comment


            • Originally posted by Giovanni Fabbro View Post
              TianoCore doesn't need Coreboot - it can do hardware init on it's own
              That's not true: coreboot is required to do a low level hardware initialization, then it transfers a control to its' payload - be it a SeaBIOS or Tianocore. All that chipset code etc - is inside a coreboot, and SeaBIOS/Tianocore don't even know about these low level specifics


              Originally posted by Giovanni Fabbro View Post
              People choose SeaBIOS because they need BIOS emulation.
              Not necessarily: mostly, they are choosing SeaBIOS for an easy & convenient boot menu for choosing a boot device.

              Originally posted by Giovanni Fabbro View Post
              It's funny because people are using SeaBIOS with Coreboot because...what? They're not booting Linux on it? Coreboot can boot Linux natively
              Yes, you can use a Linux kernel as a coreboot payload - but you'll have to update it from time to time, and these extra flashes of a BIOS chip aren't convenient. Also, there is a wide range of nice useful floppy-based OS like KolibriOS and FreeDOS which could be added to a coreboot image and then booted with the help of SeaBIOS. Meanwhile, Tianocore doesn't provide this useful capability.

              Comment


              • Originally posted by AmericanLocomotive View Post
                CoreBoot SeaBIOS Fedora users represent an extremely tiny portion of Fedora Linux users
                Indeed, it's true - but if this dumb trend set up by RedHat/Fedora catches on (just like SystemD), it could be a matter of time before there would be just a few distros we, the coreboot+SeaBIOS users, could run to: just like there are only a few decent not-SystemD distros like Artix. So, we should fight this "drop legacy BIOS" idea in its' infancy, before it spreads like a fire.


                Originally posted by AmericanLocomotive View Post
                So in 2022 or so, I think it'd be "safe" to drop legacy BIOS support.
                There are no technical reasons for dropping a legacy BIOS support, much fewer reasons than tying almost every Linux distro to SystemD with nails. They raised this idea only because want to replace GRUB with some new systemd stuff and its' too dumb to boot the legacy systems. So I hope that legacy BIOS support will never get dropped in this century, regardless of the actions of "standard pushers" corporate strongmen

                Comment


                • If you use always the same name for kernel+initrd inside ESP then you don't need any additional bootloader at all. You configure this directly with efibootmgr and UEFI already has got a boot menu. The only drawback of this method is that some boards, especially ASUS ones after a specific firmware release, delete entries as long the efi binary is the same. You can use a trick and use different upper-/lowercase writing but this is hard to do that in an automatic way. Btw. the bug was introduced 2012 and I reported it to ASUS of course but as expected they did not intend to fix it.



                  With legacy mode you need an extra boot loader, gummiboot or sd-boot is coming close to the native speed but GRUB is certainly a bit slower. However these tiny differences have no huge impact in general use, but are fun to try.

                  Comment


                  • Originally posted by michaelb1 View Post
                    That too shows the true uselessness of UEFI: if UEFI was really that beautiful and vitally important for modern computing, the coreboot community members would've fixed these Tianocore issues long ago. I'm one of those people - have been contributing to coreboot since 2016 - and I haven't ever bothered even trying to run this UEFI crap on any of my coreboot machines.
                    UEFI really is great, it's the embedded software industry players that have screwed everyone. They bitch on every post from the second UEFI was invented to now, have done nothing to get the open source components with robust UEFI support, and have opposed distros from creating UEFI native workflows. They even had a whole bullshit FUD campaign, saying the UEFI was some MS scam to take away our freedom, all to protect established players at our expense.

                    Drop native BIOS support, and provide a grub2 built in UEFI on BIOS compatability layer of some sort, that is the obvious solution forward. Don't drop support before the layer is ready to use though.
                    Last edited by techzilla; 16 July 2020, 02:23 PM.

                    Comment


                    • Originally posted by michaelb1 View Post
                      Indeed, it's true - but if this dumb trend set up by RedHat/Fedora catches on (just like SystemD), it could be a matter of time before there would be just a few distros we, the coreboot+SeaBIOS users, could run to: just like there are only a few decent not-SystemD distros like Artix. So, we should fight this "drop legacy BIOS" idea in its' infancy, before it spreads like a fire.


                      There are no technical reasons for dropping a legacy BIOS support, much fewer reasons than tying almost every Linux distro to SystemD with nails. They raised this idea only because want to replace GRUB with some new systemd stuff and its' too dumb to boot the legacy systems. So I hope that legacy BIOS support will never get dropped in this century, regardless of the actions of "standard pushers" corporate strongmen
                      The corporate argument really falls flat these days, when Linux is deployed to be a walled garden, and RedHat is way better than than Google. I used SystemD on all my new systems, and I like it actually, it manages very nicely. I think a couple of the implimentation details were less than ideal, but adding it all together, it is not a bad move.

                      The hard reality is this though, my whole career was doing Linux, and there are plenty of things I like about the *Nix world... there are plenty of things I don't like about it, and plenty of things that MS has that we don't. Now with the explosion of ARM devices, on different SBC platforms, the reality is that Linux cannot sustain an ecosystem that empowers everyone. By nature of its fundamental design, it requires a very severe degree of centralized control to maintain, which inherently chokes off innovation and evolution. Source code isn't enough, is not the end of the story, and in many cases is less important than the freedoms we don't have now. Most people don't want to tied together in a bureaucratic source control morass, but the OS design ensures that nothing independent is maintainable, unless you are a tech monopoly. In addition said centralized bureaucracy has become intolerably woke, and outright hostile to meritocracy.

                      I'm ready to make a switch the second an OS pops up that allows developers to write and maintain their own code, but fit into the larger whole... a truly componentized OS so to speak. I needs a clean build system, and components shouldn't be in one gigantic single root codebase. (in case Google is reading this)
                      Last edited by techzilla; 16 July 2020, 02:40 PM.

                      Comment

                      Working...
                      X