3 ms·

No, 580 is the new legacy driver branch, it's still supported for a couple years. Just not optimized for new titles iirc. I'm not sure what the state of the op

No, 580 is the new legacy driver branch, it's still supported for a couple years. Just not optimized for new titles iirc. I'm not sure what the state of the open-source drivers is for the really old nvidia GPUs, but for Pascal and such it's pretty decent. No video hwaccel though. However, for hardware encoding, NVENC has improved a lot over the generations. So the old chunkers are probably beat on every metric by e.g. a T400 card. Or Intel Arc (business model: "Quick sync for AMD").

Joel_Mckay 10mo ago
I have yet to see a fully working nouveau based system, as most people are just looking to blacklist the mod given the collateral problems. Depends on the hardware codecs use case, as some legacy cards are valuable to people that own legacy workflows. Without CUDA + hardware-encoders a GPU is just a paperweight regardless of age for some use-cases. =3
- bigyabai 10mo ago
  I don't know why you're making this distinction. Windows has the same issue unless you're content using a depreciated OS; Linux has the same solution, in the form of LTS kernels that do not break DKMS modules. It's been like this for decades. You've repeated this FUD about DKMS breaking, but it's exclusively a rolling-release issue. And even then you can still fix it, tons of places will containerize their workload and dump it into a proxmox:latest instance.
  - Joel_Mckay 10mo ago
    Some communities tried to keep EOL legacy nvidia drivers viable on newer OS kernels, but it is a poor allocation of resources prone to failure. It is not FUD, but rather the consequences of out-of-band proprietary mystery blobs, dependency injection, and major structural changes within the kernel or user space programs. Many legacy dkms simply don't survive the code permutations over the long term (usually Wifi cards, equipment, and GPUs.) Thus, projects relying on such drivers break eventually as people start to abandon the legacy platforms. Linux is good at many things, but LTS only slows the compatibility decay cycle to years instead of weeks. The several thousand tonnes of waste hardware it turns into garbage, and locked offline Application licenses do matter to some folks. It is the hidden Spiral development liability in most FOSS projects. =3
    - bigyabai 10mo ago
      > LTS only slows the compatibility decay cycle to years instead of weeks. Windows Service Packs do the same thing. Install Windows 10 software on a Windows 7 machine and you'll end up with a similarly-bricked system.
      - Joel_Mckay 10mo ago
        Back-porting modern drivers/security patches is another issue, but most static-linked applications tended to work fine up until Windows 11. If you wanted to play legacy games in old Windows environments it usually works up to the final patch level of the product. Note active Windows Service Packs meant the release was still supported, and most companies would maintain driver compatibility if and only if they were still in business. Abandonware popularity is a relatively recent phenomenon, as hardware became cheap enough to be disposable... and SaaS/DRM hit the entertainment industry. Most people are not going to port AAA title dependencies to ancient hardware, but the "Doom will run" on just about anything meme is usually still true. =3
        bigyabai 10mo ago
        > Back-porting modern drivers/security patches is another issue That is goalpost-shifting. You started this by critiquing Linux' drivers and security patches, you don't get to carve out excuses for Windows. > but most static-linked applications tended to work fine Sure. Most static-linked applications tend to work fine on Linux and macOS with a modern Wine environment. It's a moot point.
        Joel_Mckay 10mo ago
        Another straw man fallacy is silly. And "all software is terrible, but some of it is useful." NVIDIA abandoning legacy drivers had to happen eventually, but it isn't an excuse for Linux bricking the hardware. The vestigial deprecated areas of the kernel is covered in foundation courses to help explain what mess to avoid, as the rule to never break user space hid a lot of the uglier bodges. In terms of code volume, linux source has been mostly driver code for quite a few years. Trying to mix commercial blob binaries in a FOSS project is rarely stable over the long term (hence why recent RTX and AMD open drivers is very important.) Yet how many android devices are in garbage or recycling heaps? Answer, _all_ of them eventually, and usually in less than 3 years on average. Linux will also soon no longer include 32bit x86 support if upstream planning goes as planned. It also had to happen eventually. It should be noted the CUDA enabled drivers on windows is quite a bit more complex than the windows kernel itself. Yes it is still an awful adware OS, but it will still let you run 10 year old titles mostly without an issue. YMMV =3

Joel_Mckay 10mo ago

I have yet to see a fully working nouveau based system, as most people are just looking to blacklist the mod given the collateral problems. Depends on the hardware codecs use case, as some legacy cards are valuable to people that own legacy workflows. Without CUDA + hardware-encoders a GPU is just a paperweight regardless of age for some use-cases. =3

bigyabai 10mo ago
I don't know why you're making this distinction. Windows has the same issue unless you're content using a depreciated OS; Linux has the same solution, in the form of LTS kernels that do not break DKMS modules. It's been like this for decades. You've repeated this FUD about DKMS breaking, but it's exclusively a rolling-release issue. And even then you can still fix it, tons of places will containerize their workload and dump it into a proxmox:latest instance.
- Joel_Mckay 10mo ago
  Some communities tried to keep EOL legacy nvidia drivers viable on newer OS kernels, but it is a poor allocation of resources prone to failure. It is not FUD, but rather the consequences of out-of-band proprietary mystery blobs, dependency injection, and major structural changes within the kernel or user space programs. Many legacy dkms simply don't survive the code permutations over the long term (usually Wifi cards, equipment, and GPUs.) Thus, projects relying on such drivers break eventually as people start to abandon the legacy platforms. Linux is good at many things, but LTS only slows the compatibility decay cycle to years instead of weeks. The several thousand tonnes of waste hardware it turns into garbage, and locked offline Application licenses do matter to some folks. It is the hidden Spiral development liability in most FOSS projects. =3
  - bigyabai 10mo ago
    > LTS only slows the compatibility decay cycle to years instead of weeks. Windows Service Packs do the same thing. Install Windows 10 software on a Windows 7 machine and you'll end up with a similarly-bricked system.
    - Joel_Mckay 10mo ago
      Back-porting modern drivers/security patches is another issue, but most static-linked applications tended to work fine up until Windows 11. If you wanted to play legacy games in old Windows environments it usually works up to the final patch level of the product. Note active Windows Service Packs meant the release was still supported, and most companies would maintain driver compatibility if and only if they were still in business. Abandonware popularity is a relatively recent phenomenon, as hardware became cheap enough to be disposable... and SaaS/DRM hit the entertainment industry. Most people are not going to port AAA title dependencies to ancient hardware, but the "Doom will run" on just about anything meme is usually still true. =3
      - bigyabai 10mo ago
        > Back-porting modern drivers/security patches is another issue That is goalpost-shifting. You started this by critiquing Linux' drivers and security patches, you don't get to carve out excuses for Windows. > but most static-linked applications tended to work fine Sure. Most static-linked applications tend to work fine on Linux and macOS with a modern Wine environment. It's a moot point.
        Joel_Mckay 10mo ago
        Another straw man fallacy is silly. And "all software is terrible, but some of it is useful." NVIDIA abandoning legacy drivers had to happen eventually, but it isn't an excuse for Linux bricking the hardware. The vestigial deprecated areas of the kernel is covered in foundation courses to help explain what mess to avoid, as the rule to never break user space hid a lot of the uglier bodges. In terms of code volume, linux source has been mostly driver code for quite a few years. Trying to mix commercial blob binaries in a FOSS project is rarely stable over the long term (hence why recent RTX and AMD open drivers is very important.) Yet how many android devices are in garbage or recycling heaps? Answer, _all_ of them eventually, and usually in less than 3 years on average. Linux will also soon no longer include 32bit x86 support if upstream planning goes as planned. It also had to happen eventually. It should be noted the CUDA enabled drivers on windows is quite a bit more complex than the windows kernel itself. Yes it is still an awful adware OS, but it will still let you run 10 year old titles mostly without an issue. YMMV =3