Announcement

Collapse
No announcement yet.

Fedora 37 Looks To Deprecate Legacy BIOS Support

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

  • #41
    Originally posted by sinepgib View Post
    "Ulterior" sounds so evil here. I'd say those "ulterior" motives are rather reasonable. And an example of where older hardware support actually holds back leveraging newer hardware
    ymmv, but I definitely don't want my Linux system locked down like an Apple or Windows 11 with pluton system.

    And that's also why Microsoft bumped their requirements with Windows 11 (secure boot, tpm), and is working to require pluton as well, so they can lock down the system even more from the system's owner.

    "Ulterior" was the correct term as that is exactly what Lennart's blog was about, locking down Linux as hard as Apple/Microsoft.

    Why use Linux at all if you want to be highly restricted in what you can do.

    Comment


    • #42
      Originally posted by calc View Post

      ymmv, but I definitely don't want my Linux system locked down like an Apple or Windows 11 with pluton system.

      And that's also why Microsoft bumped their requirements with Windows 11 (secure boot, tpm), and is working to require pluton as well, so they can lock down the system even more from the system's owner.

      "Ulterior" was the correct term as that is exactly what Lennart's blog was about, locking down Linux as hard as Apple/Microsoft.

      Why use Linux at all if you want to be highly restricted in what you can do.
      There's a different between locking your system from yourself and locking it from others. I can do all Lennart says without being locked myself. I can use SecureBoot with my own signed keys, etc. "Ulterior" is forcing you a given path. That path is most likely to remain optional, and even if it isn't, there will always be a community interested in keeping distros that don't make it mandatory alive, right? That's what open source software is about.

      Comment


      • #43
        Originally posted by sinepgib View Post
        There's a different between locking your system from yourself and locking it from others. I can do all Lennart says without being locked myself. I can use SecureBoot with my own signed keys, etc. "Ulterior" is forcing you a given path. That path is most likely to remain optional, and even if it isn't, there will always be a community interested in keeping distros that don't make it mandatory alive, right? That's what open source software is about.
        Maybe you can for now, but building out the support to fully lock users out of their own systems for vendors to use will definitely be exploited.

        Theoretical example:

        For example with the current Valve Steam Deck (Linux) you can do pretty much anything you want on it, its essentially a portable Linux PC. So many game companies won't allow their games to run on it, because they want it locked down hard with kernel rootkits.

        A second gen Valve Steam Deck, with Lennart's changes, could keep from you doing anything on it as Valve will have the keys and will have locked you out. That way Valve can convince all the game companies to support it.

        So you would get access to some extra games but lose the ability to do anything with your own hardware other than what's been approved by Valve.

        Comment


        • #44
          Originally posted by calc View Post

          Maybe you can for now, but building out the support to fully lock users out of their own systems for vendors to use will definitely be exploited.

          Theoretical example:

          For example with the current Valve Steam Deck (Linux) you can do pretty much anything you want on it, its essentially a portable Linux PC. So many game companies won't allow their games to run on it, because they want it locked down hard with kernel rootkits.

          A second gen Valve Steam Deck, with Lennart's changes, could keep from you doing anything on it as Valve will have the keys and will have locked you out. That way Valve can convince all the game companies to support it.

          So you would get access to some extra games but lose the ability to do anything with your own hardware other than what's been approved by Valve.
          And yet you can build an alternative. With open source, everything is pretty much optional, as long as there's enough interest and will

          Comment


          • #45
            Originally posted by calc View Post

            A second gen Valve Steam Deck, with Lennart's changes, could keep from you doing anything on it as Valve will have the keys and will have locked you out. That way Valve can convince all the game companies to support it.
            If Valve wanted to sell you a locked down system, they can even without any of Lennart's proposed changes. Tivo did it so many years back. So you are conflating locked down appliances and systems where you can enforce security for yourself. Similar concerns apply to encryption. Encryption can be used for security and encryption can be used by malicious actors. Just because malicious actors can be misusing encryption doesn't mean we need to accept devices with government backdoors because the government can make up a scenario involving a terrorist plot with encrypted devices. That doesn't mean encryption itself is ulterior. Lennart's proposed changes are just like encryption here. They add to security and there isn't nothing nefarious about it. Your problem isn't with the tech itself, it is about the potential for misuse which exists in any security tech.
            Last edited by RahulSundaram; 05 April 2022, 07:20 PM.

            Comment


            • #46
              Originally posted by tildearrow View Post

              That's something called stability.
              The latest version of Mesa isn't always the most stable - for example, Mesa 19.1 hangs my card when encoding with VA-API whereas Mesa 19.0 doesn't.
              The latest version of X.Org (21.1) crashes a lot more often than the previous release.

              For user-space applications I suggest you use their AppImages or even Flatpaks (usually in the latest version) rather than distro packages (which tend to break more often).
              That was an example, I'm on Fedora 35 actually. I replied to the person who tried to "answer" what to use instead of Fedora 37.

              Comment


              • #47
                Originally posted by user1 View Post
                Windows 11 is capable of running on pre-UEFI systems without modifications to the installation in that area, while with Fedora removing pre-UEFI support, it seems like it won't work without manual modifications or alternative bootloaders emulating UEFI, as others have mentioned.
                Hey, I could give you $1000 and you will show me how to use the official Windows 11 ISO to install Windows on a system without Secure Boot and TPM 2.0 without modifying anything or messing with the boot media.

                From the horse's mouth:
                • System firmware UEFI, Secure Boot capable
                • TPM Trusted Platform Module (TPM) version 2.0.
                • Graphics card Compatible with DirectX 12 or later with WDDM 2.0 driver.
                Fedora 37 even with the possible EFI requirement (I'm 99.9% sure it will be cancelled) is nowhere near what Windows 11 requires.

                Microsoft is not honest about the Graphics card though. Windows even at version 11 has a perfectly working Microsoft Basic Display Adapter driver which supports most VESA compatible GPUs.
                Last edited by birdie; 05 April 2022, 10:37 PM. Reason: Fixed an important omission in a bet, my apologies

                Comment


                • #48
                  Originally posted by microcode View Post
                  Is there a point to this? Fedora doesn't really maintain anything to do with BIOS except packaging a BIOS compatible bootloader and a small portion of the installer.
                  This is directly answered in the proposal and yes, this is only a proposal and may not ever be accepted, so let's keep that in mind as well:



                  "While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro."

                  Comment


                  • #49
                    From the proposal page:

                    Contingency Plan
                    Leave things as they are. Code continues to rot.


                    What?? What's there to rot if there are no modern PCs with BIOS and ADL/Zen 4 systems lack compatibility mode/CSM altogether? It works, it doesn't need to be maintained. Open Source developers sometimes say crazy things. It's like saying that true/false utilities from coreutils need maintenance.

                    Comment


                    • #50
                      I like lilo

                      Comment

                      Working...
                      X