How old is too old?

the3ajm

the3ajm

I came to this question with my iMac running a Geforce 9400M showing sign temporary freezes with a screen blackout then recovering. Since the driver is not maintained has anyone also using unsupported driver on your PC and workarounds to keep it working, my scenario doesn't crash the system but reduces productivity time.
 
I had an imac once. I got fed up with it once they told me macos no longer supported the hardware, yet the hardware was perfectly ok. I don't have one now.
 
Maybe it sounds too severe or scary, but basically, any devices that their drivers are EoL'ed upstream should be considered as too old.

We'll need to prune x11/{linux-}nvidia-{kmod|driver|libs}{-304|340|390|470} at some point, as these are already EoL'ed upstream years ago.

Why we didn't yet is just because the driver tarballs are still available for downloading, buildable (at least on amd64) and no never-be-fixed CVEs are issued yet for them. But at minimum, i386 supports for 3xx should be pruned on EoL of final 14.x-RELEASE (scheduled Nov.30, 2028) which is the last branch supporting i386.
 
Nothing is too old, that's just clever marketing. I still maintain a couple of Windows 98 machines to use a certain hardware debug probe as part of my work.

The trick is to jump off the treadmill of "the very latest software" and instead choose the best version for the use-case. From OS to applications. Its actually quite a liberating change of mindset.

In terms of security, with some work, you can even make these things more secure on the internet than current Windows. You can block every port (hardware or Sygate for Win98) and only allow outgoing to a VNC server on i.e Azure running a web browser. Let Microsoft's machines be compromised by their crap 2026 software, no need to risk your own :)

So I would choose the period correct Mac OS X for that machine, choose software versions up to exactly the day the next Mac OS X came out and lock down connectivity (which any modern OS should be doing anyway)
 
cracauer@ said:
Those Macs were prone to hardware failure wrt their GPUs.
Click to expand...
Indeed. Anything can (and will) break. But if it can surpass our own lifespan, then that is basically problem solved.

Speaking of which, I just replaced a few capacitors in my Geforce 4 4800ti. That would be the first thing I would check if the GPUs are prone to failure, it sounds like they got hit by a resurgence of the "great capacitor plague".

If its the vram, then a donor card and transferring across is 50x harder than (de)soldering capacitors. For a rare bit of hardware I would probably send it off to be done properly by someone more skilled and with the right tools.
 
the3ajm said:
Base from my investigation it seems to be an driver frozen in time while the modern environment continues to evolve leading to strange behaviors as Xorg log indicates.
Click to expand...

That GPU (and brand) is probably hit by the slightly awkward Xorg user-space drivers being replaced by DRM/modesetting in the last decade. If it wasn't for this, they *might* have been maintained better.

Out of interest, have you tried with Nouveau (Linux/NetBSD)? Does the upstream open-source drivers support it? So far there are:
  • nvidia - Upstream proprietary driver. Some older cards but mainly focused on new
  • nv - Limited 2D only, old Xorg user-space driver
  • nouveau - Open-source, kms/drm based driver (not ported to FreeBSD)
Sadly, if you want the modern environment, then a $20 machine off AliExpress is probably the fastest path there.
 
kpedersen said:
Does the upstream open-source drivers support it?
Click to expand...
If you mean open-gpu-kernel-modules by NVIDIA, it's only for Turing and later generations of architectures GPUs that have GSP (GPU System Processor) in them.

And as far as I could hear from upstream devs, even if we add and fit FreeBSD specific codes included in proprietary driver tarballs, the resulting binary would be "actually" the same as the same version of proprietary driver (excluding Linux only parts like nvidia-uvm.ko and CUDA libraries).

At the same time, porting Linux only things would be almost impossible unless supports for lacking functionalities on base and graphics/drm-*-kmod side are implemented.

So we (NVIDIA driver ports team under the umbrella of x11 group maintainers) concluded it's NOT worth doing at least at the moment we discussed about it. And things doesn't seem to be changed until now.
 
the3ajm said:
Base from my investigation it seems to be an driver frozen in time while the modern environment continues to evolve leading to strange behaviors as Xorg log indicates.
Click to expand...

Yeah, but some of that is buffered when you recompile the driver. FreeBSD with its compiled drivers is in much better shape that OSes that only have binary drivers and don't recompile.
 
kpedersen said:
That GPU (and brand) is probably hit by the slightly awkward Xorg user-space drivers being replaced by DRM/modesetting in the last decade. If it wasn't for this, they *might* have been maintained better.

Out of interest, have you tried with Nouveau (Linux/NetBSD)? Does the upstream open-source drivers support it? So far there are:
  • nvidia - Upstream proprietary driver. Some older cards but mainly focused on new
  • nv - Limited 2D only, old Xorg user-space driver
  • nouveau - Open-source, kms/drm based driver (not ported to FreeBSD)
Sadly, if you want the modern environment, then a $20 machine off AliExpress is probably the fastest path there.
Click to expand...
I've looked into the open source driver option they have limitations in video playback. There's a similar event happened during the black screen recovering with my desktop pop up saying it's falling back to software rendering due to unsupported opengl driver issue so the acceleration is bound to my CPU.
 
To retire, or not to retire...that is the question.

To me it depends on a lot of things so it's not a one size fits all answer. I believe that any business venture should keep their systems modern, but concede that in some cases it is preferable to use legacy systems: such as the ability to use "owned" software instead of "subscription" software. I have an architect friend who is fighting this battle right now. He doesn't want to upgrade his modelling/rendering software/machine because the new stuff is subscription based and must be run "online". ie no air-gapped usage.

Personally, I'll keep legacy systems running for as long as they are not "flaky". In designing specailized "applied science" apps I don't see a need to run them on high end uber-core machines...and I'm often miffed about how FOSS OSs drop support for older CPUS: i386 comes to mind. that move bugs me but ya get what you pay for, right?
 
the3ajm said:
What about freebsd removing the driver from the port collection?
Click to expand...
It doesn't matter. If it works on your machine and doesn't cause you any issues then just use it. You just won't be able to upgrade it using port or packages through FreeBSD repositories. If you can get the source, then later on you might be able to compile it yourself and get it working or upgraded.
 
T-Aoki said:
If you mean open-gpu-kernel-modules by NVIDIA, it's only for Turing and later generations of architectures GPUs that have GSP (GPU System Processor) in them.
Click to expand...
Oh, apologies, I did mean the upstream kernel drivers (nouveau). Admittedly, confused further by me later mentioning upstream nvidia drivers (proprietary).

Good point though, I completely forgot about Nvidia's open-source ones. But yeah, you are right, they are focused on their newer products.

T-Aoki said:
At the same time, porting Linux only things would be almost impossible unless supports for lacking functionalities on base and graphics/drm-*-kmod side are implemented.
Click to expand...
Out of interest, can you give a very general approximation for how far the LinuxKPI infrastructure is from being able to support nouvea and/or nvidia's open-source code from Linux?
 
the3ajm said:
I came to this question with my iMac running a Geforce 9400M showing sign temporary freezes with a screen blackout then recovering. Since the driver is not maintained has anyone also using unsupported driver on your PC and workarounds to keep it working, my scenario doesn't crash the system but reduces productivity time.
Click to expand...

Have you looked into OpenCore Legacy Patcher? You can install macOS Seqouia on it.
 
I've run into this question with "family". They wind up using/depending on a specific software package (OS and specifics don't really matter). Works great on the hardware today. They get notification "software update available" so they update software for "features" they don't need/use. Software update a few times and "you need to update your hardware". What do you do?
Hard example is accounting software like Quicken/QuickBooks.
At the core accounting is simple: money in here, assign to categories there, costs/liabilities there and make it all balance. Pencil and paper have worked forever.
So Do I need to update QuickBooks for features I never use? Only because the license terms say they will lock me out of my data if don't. Not even give me a ready only copy of locally stored data, just "no license, no access".

To me, bottom line, if the hardware and software combination works, does what I need, I don't need to update. But I also need to acknowledge that not updating may be harmful in the long run (security stuff).
 
kpedersen said:
Out of interest, can you give a very general approximation for how far the LinuxKPI infrastructure is from being able to support nouvea and/or nvidia's open-source code from Linux?
Click to expand...
I'm not a NVIDIA insider, but as far as I could hear, nouveau is already outdated and having issues on Linux, thus, not worth trying to port.
If it can support all GPUs last supported by any of 3xx branch of proprietary drivers and works fine for them, and if enough new developers having such old "working well as hardwares" GPUs pops in, it could (hopefully) become realistic.

And for open source version of codes to make missing-on-FreeBSD features available, at least Linux compatible UVM interface and Linux compatible fbdev would be needed (maybe more, though, as I could hear these as examples).

And another thing to consider in the future could be nova driver.
But it requires far newer LinuxKPI and Rust in kernel (at least for device drivers). I don't think Rust in kernel is NOT realistic, as it's still too much a "moving goals". Standardization on ISO/IEC and forcing 100% backward compatibilities would be mandatory to start actually considering (and start attempting to learn Rust). 50 years of stable buildability in the future is wanted for OS kernels, just as C does.
 
You must log in or register to reply here.
Back
Top