51–59 of 59 posts
I would guess the Steam switch to Linux is mostly driven by the adoption of the Steam Deck.
Earlier quoted context omitted.
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…
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
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.
Earlier quoted context omitted.
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
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 a…
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
Earlier quoted context omitted.
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 a…
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…
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.
Earlier quoted context omitted.
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…
> 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.
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
Earlier quoted context omitted.
> 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.
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 sti…
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.
Earlier quoted context omitted.
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 sti…
> 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.
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
Earlier quoted context omitted.
> 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.
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, li…
Earlier quoted context omitted.
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, li…
Your definition of "bricked" is not congruent with any industry-spanning consensus that I am aware of. You're entitled to your own opinion, but you fundamentally misunderstand how software is deployed to these legacy systems and I cannot help you beyond what I've already explained.
1. outdated legacy OS that has to rely on a limited subset of flatpack, snap, containerization, and CVEs...
2. modern OS with unfix-able driver issues, NVIDIA wanting people to buy a new GPU, and broken abandonware drivers
I'd say a bricked GPU is appropriate terminology, as your screen will be forced into 800x600 by the hardware recovery mode and be functionally useless. For Linux users the only solution is to buy a compatible GPU, and or throw away the laptop/tablet/phone devices that can't run legacy Windows drivers.
When the collapse cycle of spiral development happens: a lot of Applications are also lost in the process, as the original publishers may not be maintaining an application a decade later. dkms with mystery Blobs would fall into the same out-of-band classification.
It is funnier people are upset about slop articles nonsense assertions.
The question about whether something is qualitatively "good" is meaningless if its demonstrably broken. =3