Announcement

Collapse
No announcement yet.

Fedora 21 Drops Support For A Bunch Of Old GPUs

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

  • #41
    Originally posted by RahulSundaram View Post
    Nothing that cannot be solved via participation.
    That's a truism in Open Source. Of course one can participate and maintain the UMS drivers in Fedora, or even write and contribute a KMS driver for SiliconMotion and XGI server graphics. But the question was whether owners of such hardware would want to run a modern Linux distribution and what options they have when choosing a distro.

    Comment


    • #42
      It is also a little harsh to say that it is Fedora doing this purely on its own - it is representative of the larger problem of backwards support. And there are workarounds involving different solutions and trade-offs when it comes to dealing with this, which makes the small crowd affected by these changes diminish even further. As disconcerting as it is for those it affects, it is actually a rather small problem as opposed to the other issues facing distros and the Linux graphics stack.

      Comment


      • #43
        I think the main problem with backwards compatibility is that nobody cares until it's officially unsupported. It makes the ones who actually work with the code look like the bad guys who cut you off, when usually this dropped support is for drivers which has been already unmaintained for a long time.

        Comment


        • #44
          Originally posted by Hamish Wilson View Post
          It is also a little harsh to say that it is Fedora doing this purely on its own - it is representative of the larger problem of backwards support. And there are workarounds involving different solutions and trade-offs when it comes to dealing with this, which makes the small crowd affected by these changes diminish even further. As disconcerting as it is for those it affects, it is actually a rather small problem as opposed to the other issues facing distros and the Linux graphics stack.
          Right. It's probably worth repeating every 10 posts or so that the issue here is not "arbitrarily dropping drivers for old hardware" as much as dropping *unmaintained* drivers.
          Test signature

          Comment


          • #45
            Originally posted by chithanh View Post
            That's a truism in Open Source. Of course one can participate and maintain the UMS drivers in Fedora, or even write and contribute a KMS driver for SiliconMotion and XGI server graphics. But the question was whether owners of such hardware would want to run a modern Linux distribution and what options they have when choosing a distro.
            That is not a real question IMO. If you want the latest features for a old system, there is no choice that would work out well. On the other hand, someone just volunteered to pick the drivers, so everything remains the same likely.

            Comment


            • #46
              I was more worried about the example being set

              Originally posted by Hamish Wilson View Post
              But shouldn't longer supported distros be able to fill that void somewhat, such as LTE versions of Ubuntu, stable versions of Debian, or enterprise solutions such as RHEL?

              This is Fedora that is dropping them, remember.
              Where Fedora goes, others may follow. I'd actually be less worried if this was Ubuntu because Debian often does NOT follow them. Ubuntu's LTS's get 5 years support but I don't know if it is possible to install packages from repo beyond that. Here's a thought: Why are drivers for graphics cards that were no longer made in 2003 included and supported in 64-bit versions of anything? There were no x86-64 machines made before then, so has anyone here heard of a use case for Mach64, etc on a 64 bit system? If not, then these drivers need only be maintained by anyone in 32 bit.

              In the longer run, I do think the whole Linux world will have to fork, with one sector dedicated to supporting older hardware but keeping up with newer peripherals, while the other focusses on maximum performance from newer machines. After all, the generation spread of existing and in-use machines that can do certain workloads that really never change just keeps getting wider and wider. Until then, it might be enough for X to mantain compatability with older drivers, no need to put them on install disks or pull them into a default X install. Wayland and Mir, obviously, need only support OpenGL capable cards from the get-go, but so long as Xorg is in repo, it should support all drivers even if they have to come from a 3ed party repo.

              Comment


              • #47
                Originally posted by Luke View Post
                Here's a thought: Why are drivers for graphics cards that were no longer made in 2003 included and supported in 64-bit versions of anything? There were no x86-64 machines made before then, so has anyone here heard of a use case for Mach64, etc on a 64 bit system? If not, then these drivers need only be maintained by anyone in 32 bit.
                /me exists.

                From 2006 to 2008 IIRC I used a setup like that: 64-bit system, but with pre-03 gpus. First Rage II+dvd and later Matrox G200 Millenium.

                inb4 why: because I could I wasn't going to pay for a gpu when I didn't need a beefy one, so I put in some old PCI one I had in the closet.

                Comment


                • #48
                  Originally posted by Luke View Post
                  Wayland and Mir, obviously, need only support OpenGL capable cards from the get-go, but so long as Xorg is in repo, it should support all drivers even if they have to come from a 3ed party repo.
                  Wayland does not need OpenGL. It works fine without acceleration.

                  Comment


                  • #49
                    Originally posted by Luke View Post
                    In the longer run, I do think the whole Linux world will have to fork, with one sector dedicated to supporting older hardware but keeping up with newer peripherals, while the other focusses on maximum performance from newer machines. After all, the generation spread of existing and in-use machines that can do certain workloads that really never change just keeps getting wider and wider.
                    But that does seem like a lot of effort over a rather small problem of older hardware not being able to access the latest Linux features.

                    When old hardware hobbyists want to use older hardware with other operating systems they use older/longer supported releases. As much as we appreciate that Linux is more flexible here than most, we can not expect miracles for such small use cases.

                    Forking the entire Linux ecosystem certainly seems like an overreaction for not being able to use Btrfs on a Pentium III.

                    Comment


                    • #50
                      Originally posted by Hamish Wilson View Post
                      But that does seem like a lot of effort over a rather small problem of older hardware not being able to access the latest Linux features.

                      When old hardware hobbyists want to use older hardware with other operating systems they use older/longer supported releases. As much as we appreciate that Linux is more flexible here than most, we can not expect miracles for such small use cases.

                      Forking the entire Linux ecosystem certainly seems like an overreaction for not being able to use Btrfs on a Pentium III.
                      Not only that, but it sounds overly complicated, comparing to step up and just maintain the drivers and make them use the current way of doing things. Also, the same way nobody stepped up to support them, makes clear nobody will step up to support a whole fork of the OS, which is a harder task.

                      Comment

                      Working...
                      X