Solved How old is too old?

I think if the old hardware has an unsupported GPU like nvidia then this creates the struggling scenario in the video acceleration context defined as part of my usage on the machine
Due to the separation of display server and application, you can just run a matching Xorg (for the last working nvidia driver) and your program in a separate jail (chroots probably good enough).

Completely unsupported but then again.... almost all aspects of an open-source operating system are ;)

Where there is a will there is a way. Nothings ever too old. But at the same time, not wanting to faff around is also a completely valid excuse to just buy a replacement.
 
My current workstation, the one I'm typing on right now, had a nvidia 1900GT in it till just a couple of months ago when I started running into too many sites requiring something that didn't render in my browser. My processor can do that so I pulled it but, until then, the 1900gt was not obsolete to me and did everything I wanted it to do.
As you can see in this official article, NVIDIA clearly stated the EoL (finishing supports) for 3xx series of drivers at 2022 or before.

470 series are not clearly stated its EoL there, but there's description
Support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 470.* legacy releases for the remainder of the relevant product support lifetime. See the knowledgebase articles for support of Kepler-series [GeForce see https://nvidia.custhelp.com/app/answers/detail/a_id/5202 ] and [Quadro see https://nvidia.custhelp.com/app/answers/detail/a_id/5210 ] for more information.
and digging into the link, GeForce has description
Critical security updates will be available on systems utilizing desktop Kepler-series GPUs through September 2024.
and Quadro has description
Official support will end on January 31, 2023; any subsequent driver releases will not include testing or enhancements for professional features.
so 470 series should be considered as already EoL'ed.

So using any NVIDIA GPUs that are NOT supported by 580 series and later drivers are discouraged.

Why we (NVIDIA driver ports maintaining team) NOT YET deleted 3xx and 470 is just because upstream tarball for latest version of each branches are still available for downloading and no CVEs that would never been fixed and affecting with them are NOT yet disclosed.

More, 304 series are known stopped working as of xorg-server upgrades years ago, but currently kept for anyone locking updates for xorg (strongly discouraged!) on PCs that are NOT connected to any networks.

We'll be forced to remove old branches when
  • upstream tarball become unavailable,
  • not-to-be-fixed CVEs for them are disclosed,
  • or base FreeBSD drops syscons (sc) driver support (16.0 earliest, but maybe 17.0 or later).
 
are you sure that is a Nvidia and not an ATI Radeon GPU?

Generally processor can render web content depends on the capability but less efficient than GPU which should suffice for most websites.
Yes, there are no 1900 GT among NVIDIA GPU models.
But possibly GPU "cards" has such a name, unrelated with GPU model used.
 
T-Aoki Correction. I had a Nvidia 9800gt
So you should be using version 340.108.

Anyway, NVIDIA wouldn't provide any updates even if fatal security issue is found for the version (thus, EoL'ed). And as source codes provided for NVIDIA proprietary drivers are limited with interface layers between binary only part and kernel.

So we cannot fix anything as maintainers unless the issue is in the interface parts that source codes are available.
 
Where there is a will there is a way. Nothings ever too old. But at the same time, not wanting to faff around is also a completely valid excuse to just buy a replacement.
I found the will to keep software running within my tolerance level until nature calls that it's time to move on.
 
Indeed.

Though, as an exception, the dodgy chemical formula leading to the great capacitor plague means the capacitor contents likely bubble regardless of temperature ;)
What you want to avoid is a board that has sited an e-cap right next to the heatsink, like this PNY graphics card. This kind of crappy physical layout is just asking for trouble. The places where you're going to find these are audio amplifiers, power supplies, graphics cards, adjacent to CPU heatsinks... anything that has a heatsink that gets hot. Of course in well-designed gear you should not see anything like this, this is an extreme case imho.

Screenshot_20260805_022025.jpg
 
We'll be forced to remove old branches when
  • upstream tarball become unavailable,
  • not-to-be-fixed CVEs for them are disclosed,
  • or base FreeBSD drops syscons (sc) driver support (16.0 earliest, but maybe 17.0 or later).
Do we know how soon any of those is likely happening in the future or it's one of those "brace for impact' situations?
 
I found the will to keep software running within my tolerance level until nature calls that it's time to move on.
Heh yep. Sometimes its also down to the machine. I look at it and when it looks outright miserable with all of my various bodges to keep it limping along. I feel a bit sorry for it and then put it out to pasture.

This kind of crappy physical layout is just asking for trouble. [...] Of course in well-designed gear you should not see anything like this, this is an extreme case imho.
Ugh, that is a bit crap. GPUs do tend to verge on short lived consumer technology (and the dreaded gamer PC). Its probably more likely to see this here than any other kind of hardware.

I still don't like that only one half of my Geforce 4 has a heatsink, causing potential shearing of the vram. A BGA Rework station is currently beyond my expertise.
 
Do we know how soon any of those is likely happening in the future or it's one of those "brace for impact' situations?
The first one may be unlikely, as NVIDIA still provides driver tarball even for 195.22 on amd64.

The 2nd is completely unknown. NVIDIA themselves would no longer checking for vulnerabilities for EoL'ed drivers, but any of 3rd parties could find one and publish CVE.

The last would be the nearest future, as syscons (sc) driver is already deprecated and waiting for deletion. Hopefully after all features that vt driver currently lacks are implemented, but possibly earlier.
I'm working on preparing for the deletion at PR 277365, but my current plan is for 470 series and later (possibly 390 can be fixed in the same way with some adaptation, but 304 and 340 differs much, thus, not planning to work on it unless new volunteer pops in to work on it).

Another thing to mention is supports for i386.
3xx series are the last branches that supports i386. So once FreeBSD base drops support for i386, at least overhauling are needed for them. And this may be a good timing to drop 3xx series. Note that 14.* are the last major release that support i386 and will EoL at 30 November 2028.
 
Back
Top