At any given moment, there are a number of sys-kernel/gentoo-kernel and x11-drivers/nvidia-drivers versions available on the repository, with specific versions of the former compatible with specific versions of the latter. Over time, various versions of the kernel and of nvidia-drivers are removed from the repository, forcing updates.
Question: Is there a strategy for selecting a gentoo-kernel + nvidia-drivers version pair so that it will persist in the repository for the longest possible time?
Rationale: Every time nvidia-drivers is updated, a number of packages can no longer run. This includes Zoom, games, etc. If those packages must remain always available, an nvidia-drivers update is tantamount to a forced restart of the X server, or even to a forced reboot when a kernel update happens at the same time (as is often the case). I would argue that being forced to reboot on portage's schedule rather than on the user's own schedule is not ideal (although I do acknowledge that "ideally" one should restart every process that has received an update, which often translates to a reboot...).
I suppose there are valid reasons to remove certain versions from the repository. And there are tricks one can play with masking packages to avoid upgrading nvidia-drivers and/or gentoo-kernel and thus delaying a reboot --for a while-- but this game quickly becomes boring. I am just wondering whether there is a more straightforward and less fussy way to extend the system's uptime, other than switching to sys-kernel/gentoo-sources.
Many thanks for any suggestions!
PS Does anyone know why only some programs are affected by an nvidia-drivers update and not all X programs? Has there to be a specific subset of the nvidia driver functionality that they depend on for this to happen? Just curious...
kernel + nvidia-driver combinations with maximum longevity?
Message
You can always do e.g. emerge --exclude "nvidia-drivers gentoo-kernel dist-kernel" until you do intend to reboot, no real point in updating these if not going to reboot or reload the modules. And even if the old kernel or nvidia-drivers version are gone, you can keep using them, not like you need to rebuild them unless you upgraded by accident and want to downgrade.
Also, old versions of nvidia-drivers are typically kept for a while (maybe 1 month+ depending, unless it was a beta or something special), but the exception to that is when they are affected by security vulnerabilities (which happens often) and then we drop them all right after stabilizations unless there's notable regressions that force us to keep them. The latest batch of drivers was in fact affected what nvidia described could allow code execution by an attacker.
...that does mean that if you do not actually update+restart X or reboot for possibly a long time (or even years), you are affected by security vulnerabilities the whole time though.
nvidia-drivers does not update *that* often too, maybe once every 1-2 months on average, so that means a monthly reboot whenever you are ready after waiting with --exclude (ideally maybe only for a day until done with your work, then reboot), don't really see why you'd need to pin to some ancient version.
Edit:
That also only happen if you restart these applications, given the currently running ones will still be using the old libraries unless they're doing something weird like dynamically opening them or re-opening in new sub-processes (I'd imagine, e.g. zoom may do this). If load the new libraries, then they'll see it mismatch with the kernel module and refuse to work.
Also, old versions of nvidia-drivers are typically kept for a while (maybe 1 month+ depending, unless it was a beta or something special), but the exception to that is when they are affected by security vulnerabilities (which happens often) and then we drop them all right after stabilizations unless there's notable regressions that force us to keep them. The latest batch of drivers was in fact affected what nvidia described could allow code execution by an attacker.
...that does mean that if you do not actually update+restart X or reboot for possibly a long time (or even years), you are affected by security vulnerabilities the whole time though.
nvidia-drivers does not update *that* often too, maybe once every 1-2 months on average, so that means a monthly reboot whenever you are ready after waiting with --exclude (ideally maybe only for a day until done with your work, then reboot), don't really see why you'd need to pin to some ancient version.
Edit:
That depends on if they use GPU acceleration, or more specifically libraries for it like libGL for opengl, or vulkan.orionbelt wrote:PS Does anyone know why only some programs are affected by an nvidia-drivers update and not all X programs? Has there to be a specific subset of the nvidia driver functionality that they depend on for this to happen? Just curious...
That also only happen if you restart these applications, given the currently running ones will still be using the old libraries unless they're doing something weird like dynamically opening them or re-opening in new sub-processes (I'd imagine, e.g. zoom may do this). If load the new libraries, then they'll see it mismatch with the kernel module and refuse to work.
Many thanks for the detailed reply, the --exclude option works very well for what i need!
Indeed, the problem was not that old kernel or nvidia-drivers versions are gone but that portage then wants to downgrade to older versions of them (and, more generally, wants to change nvidia version from the one running). Telling it to stop thinking about them solves the problem nicely
"Interesting" that the nvidia drivers can be affected by security vulnerabilities so often... Though i suspect most of them concern newer drivers and newer cards, so those of us with older cards are probably less affected...
Sure, one has of course to reboot from time to time... For me, this has usually been every couple of months or so, when there was no longer a valid gentoo-kernel + nvidia-drivers pair on the repository and portage could no longer update my world. With your workaround, i guess the only limitation will now be if some package has a dependence on a recent-enough nvidia driver, but i cannot see this happening very often... Still, i do not intend to have an uptime of more than a few months at most.
In fact, my main reason for avoiding reboots is that when i use KDE it just won't resume the session the way it was: Some programs won't be restarted, windows will be opened in different places, and the positions of the various taskbar tabs will not be restored. Plus, i also have to restart several remote sessions... It's a pity that we still have to deal with such issues...
I, too, suspected opengl or vulkan updates as the reason why some programs refuse to start before restarting X, but doesn't Firefox use them when hardware acceleration is enabled? Yet, it never refused to start after an nvidia update. Same thing with stellarium.
Many thanks again!
Indeed, the problem was not that old kernel or nvidia-drivers versions are gone but that portage then wants to downgrade to older versions of them (and, more generally, wants to change nvidia version from the one running). Telling it to stop thinking about them solves the problem nicely
"Interesting" that the nvidia drivers can be affected by security vulnerabilities so often... Though i suspect most of them concern newer drivers and newer cards, so those of us with older cards are probably less affected...
Sure, one has of course to reboot from time to time... For me, this has usually been every couple of months or so, when there was no longer a valid gentoo-kernel + nvidia-drivers pair on the repository and portage could no longer update my world. With your workaround, i guess the only limitation will now be if some package has a dependence on a recent-enough nvidia driver, but i cannot see this happening very often... Still, i do not intend to have an uptime of more than a few months at most.
In fact, my main reason for avoiding reboots is that when i use KDE it just won't resume the session the way it was: Some programs won't be restarted, windows will be opened in different places, and the positions of the various taskbar tabs will not be restored. Plus, i also have to restart several remote sessions... It's a pity that we still have to deal with such issues...
I, too, suspected opengl or vulkan updates as the reason why some programs refuse to start before restarting X, but doesn't Firefox use them when hardware acceleration is enabled? Yet, it never refused to start after an nvidia update. Same thing with stellarium.
Many thanks again!
Old hardware and their drivers often uses the same code and features and are typically affected all the same. The last CVE also needed to be fixed in the old nvidia-drivers-535.x branch which was affected as well. The "legacy" 390/470 for old cards that are no longer getting updated are notably riddled vulnerabilities too, and could potentially be affected by this "new" one still (not that nvidia reports if they are or not anymore, and being closed source we can't check ourselves easily).orionbelt wrote:"Interesting" that the nvidia drivers can be affected by security vulnerabilities so often... Though i suspect most of them concern newer drivers and newer cards, so those of us with older cards are probably less affected...
These issues just take time to be found (and "potentially" get exploited after being found), it doesn't "necessarily" mean that they've been newly introduced and haven't been around for potentially decades.
Some applications may just handle this more gracefully (i.e auto-disable the acceleration rather than fail), the X server itself and things that use its GLX module will also remain fine given the old library is used until restart X. Mileage will vary depending on the application.orionbelt wrote:I, too, suspected opengl or vulkan updates as the reason why some programs refuse to start before restarting X, but doesn't Firefox use them when hardware acceleration is enabled? Yet, it never refused to start after an nvidia update. Same thing with stellarium.
What do you propose be done differently? Per Ionen's remarks, the Gentoo project cannot fix these defects in a closed-source component, and often is not even able to know of the defect's existence prior to publicized reports. Gentoo could speculatively remove from the tree all driver versions that nVidia is no longer actively patching, but that would antagonize users without evidence that such removal was necessary, and still doesn't help for any drivers that are nominally maintained, but have unreported vulnerabilities.
Sorry I was not clear that my comment was not directed at Gentoo, it was about the way nVidia is not somehow forced to pay attention to the security issues of their drivers, especially in view of their popularity. Ionen's posting implied that it's not just an occasional CVE incident here and there but drivers "riddled with vulnerabilities". Of course, other manufacturers may have the same or worse issues with their drivers...
Gentoo is about choice, and i agree that it should not remove a popular package without good reasons and due consideration. In this case, depending on the situation a user could consider using the nouveau driver, different hardware, etc.
Gentoo is about choice, and i agree that it should not remove a popular package without good reasons and due consideration. In this case, depending on the situation a user could consider using the nouveau driver, different hardware, etc.
nvidia is handling this normally, issues are they found when they are found, then they fix them, and there aren't *that* many relative to the software size -- being (mostly) closed source, we do have less control over this though
When I said "often" it was relative to releases, i.e. LTS branches do not necessarily get updated often, sometime they can go months without releases, and then they all get updated at same time for a security fix meaning we "often" need to drop the previous version right away rather than keep any for these.
It's at least not much compared to e.g. web browsers having a security vulnerability fix nearly every weeks (if anyone is delaying updating browsers because they take a while to compile, you're better off switching to a -bin version rather than keep using a week old version ;p)
Edit: and wrt "riddled", this is going to happen to nearly anything that is no longer getting updated save for very basic software, these versions are also masked in Gentoo and the mask message advices to seek alternatives
When I said "often" it was relative to releases, i.e. LTS branches do not necessarily get updated often, sometime they can go months without releases, and then they all get updated at same time for a security fix meaning we "often" need to drop the previous version right away rather than keep any for these.
It's at least not much compared to e.g. web browsers having a security vulnerability fix nearly every weeks (if anyone is delaying updating browsers because they take a while to compile, you're better off switching to a -bin version rather than keep using a week old version ;p)
Edit: and wrt "riddled", this is going to happen to nearly anything that is no longer getting updated save for very basic software, these versions are also masked in Gentoo and the mask message advices to seek alternatives
Last edited by Ionen on Sat Feb 07, 2026 2:51 pm, edited 3 times in total.
Since nVidia offers the closed source drivers without fee, their only motivation to maintain the drivers is the belief that providing the drivers will let them sell more hardware than if they declared that they would not offer any Linux drivers at all. This minimal motivation is probably why they tend to drop card support sooner than most users would like. A five year old nVidia card may still have years of life left in it if properly maintained (kept clean, stable power input, good operating temperature, etc.), but it's unlikely nVidia will sell any more cards of that generation as a result of continuing to support that generation in their drivers. As a result, they probably see dropping the older cards as a net win, because it makes their driver developers slightly more efficient to reduce the matrix of supported hardware, and costs them nothing in lost sales. In that regard, it's unfortunate for the community when a security defect is found in an end-of-life driver series, but it's not likely to move nVIdia to reopen that series just to fix the defect.
- eccerr0r
- Watchman
- Posts: 10239
- Joined: Thu Jul 01, 2004 6:51 pm
- Location: almost Mile High in the USA
- Contact:
rereading the original post, and from my experience with nvidia drivers, every time you up date nvidia-drivers whether due to security or other update, it will build a new kernel module and you have to reload that at the minimum, even if you don't upgrade your kernel. Usually this will require a reboot (if you cant rmmod the old module and this is very frequent),. Most of these programs that have an issue with you updating nvidia-drivers are the 3d programs as the 3d libraries will check the kernel to see if the kernel module version matches or not, and will bomb out when they mismatch. So if you are happy with keeping security holes open, feel free to just mask all versions of your kernel and the nvidia-drivers you have merged so portage won't pick them up....
This is all besides the planned obsolescence that nvidia puts in their cards due to not wanting to fund updates to keep up with kernel development or divulge information needed to make a better OSS driver.
nvidia sucks, Linus has shown his disdain and I agree. Luckily I've only ever acquired ONE nvidia card new (oh crap, edited -- I did not buy the card, it was gifted!). It has subsequently died, all the remaining nvidia gpus I have are second hand e-waste acquired for near nothing so at least I haven't contributed to their policy...
This is all besides the planned obsolescence that nvidia puts in their cards due to not wanting to fund updates to keep up with kernel development or divulge information needed to make a better OSS driver.
nvidia sucks, Linus has shown his disdain and I agree. Luckily I've only ever acquired ONE nvidia card new (oh crap, edited -- I did not buy the card, it was gifted!). It has subsequently died, all the remaining nvidia gpus I have are second hand e-waste acquired for near nothing so at least I haven't contributed to their policy...
Intel Core i7 2700K/Radeon Firepro W2100/24GB DDR3/800GB SSD
What am I supposed watching?
What am I supposed watching?
- rab0171610
- l33t
- Posts: 721
- Joined: Sat Dec 24, 2022 1:41 am
Aww, someone sounds triggered. Nvidia makes high quality video cards. To their credit, the company has provided proprietary Linux drivers for decades at no additional cost to the user. They provide regular updates and most cards have driver support for most of their natural life span. Users have always also had the option to use the Nouveau drivers instead.
As for Linus Torvalds showing disdain towards Nvidia, he has also shown disdain for AMD and Intel over buggy hardware and processor vulnerabilities.
I find it comical that someone would continue to show disdain for Nvidia but admits they have never even been a customer of Nvidia i.e. openly boasting that they have never financially supported the company by buying their hardware, yet complains about their driver support and criticizes the company for "not wanting to fund updates". Apparently, their product is sufficiently desirable if the admission of acquiring multiple Nvidia GPU's second-hand is anything to go by.
As for Linus Torvalds showing disdain towards Nvidia, he has also shown disdain for AMD and Intel over buggy hardware and processor vulnerabilities.
I find it comical that someone would continue to show disdain for Nvidia but admits they have never even been a customer of Nvidia i.e. openly boasting that they have never financially supported the company by buying their hardware, yet complains about their driver support and criticizes the company for "not wanting to fund updates". Apparently, their product is sufficiently desirable if the admission of acquiring multiple Nvidia GPU's second-hand is anything to go by.
- eccerr0r
- Watchman
- Posts: 10239
- Joined: Thu Jul 01, 2004 6:51 pm
- Location: almost Mile High in the USA
- Contact:
They are not "high quality" cards if they fail. That was the main reason for avoiding them the first go after that experience, as well as having to deal with bumpgate. Having to deal with closed source crap is just like running windows and nailed the coffin shut.
There is no credit for providing drivers, ATI also provided closed source drivers at first.
The nouveau drivers are crap, as experienced on the second hand cards, they do not perform to the best the cards can do. Not the fault of the reverse engineers, totally on nvidia.
BTW I paid only e-waste bundle value for most of these nvidia cards, as that's what they were always worth. Really doesn't matter how much was paid for them, the experience was suboptimal and glad I did not pay for the experience and especially vendor lock <<CUDA>>.
There is no credit for providing drivers, ATI also provided closed source drivers at first.
The nouveau drivers are crap, as experienced on the second hand cards, they do not perform to the best the cards can do. Not the fault of the reverse engineers, totally on nvidia.
BTW I paid only e-waste bundle value for most of these nvidia cards, as that's what they were always worth. Really doesn't matter how much was paid for them, the experience was suboptimal and glad I did not pay for the experience and especially vendor lock <<CUDA>>.
Intel Core i7 2700K/Radeon Firepro W2100/24GB DDR3/800GB SSD
What am I supposed watching?
What am I supposed watching?
- rab0171610
- l33t
- Posts: 721
- Joined: Sat Dec 24, 2022 1:41 am
- eccerr0r
- Watchman
- Posts: 10239
- Joined: Thu Jul 01, 2004 6:51 pm
- Location: almost Mile High in the USA
- Contact:
They don't deserve credit for supplying closed source drivers that go out of style in a new kernel rev as the OP observes. ATI supplied data for OSS, and that deserves credit.
I'll need to locate some Arc and see how well these are built. If it's anything like other Intel graphics, even CGC, these have survived the test of time. I think I've only had one intel graphics, CGC, fail - and that wasn't even Intel's fault -- it was the capacitor plague.
I'll need to locate some Arc and see how well these are built. If it's anything like other Intel graphics, even CGC, these have survived the test of time. I think I've only had one intel graphics, CGC, fail - and that wasn't even Intel's fault -- it was the capacitor plague.
Intel Core i7 2700K/Radeon Firepro W2100/24GB DDR3/800GB SSD
What am I supposed watching?
What am I supposed watching?
I'm still rocking a GeForce 650 Ti (late 2012) in the desktop I have at my mom's house (with an AMD-FX8350 on a M5A99FX that I would have bought around the same time), all using a current linux kernel and some ancient drivers (470?) that I keep patched to compile on modern kernels.
The hardware is 13+ years old and still working. It's way outdated, but functional for my mom's need for some web browsing, some document editing along with scanning/printing, etc. Even with modern drivers, the hardware is still limited to what the hardware is and a lot has changed in the CPU/GPU world since then. I really can't complain that it they dropped support in the current driver years ago.
I've got a 1050 Ti (2016) in my work desktop that just lost support at 10 years old, but will still play games of that hardware's era just fine. The 1660 Super (2019) in my home desktop is still supported and I can still play games just fine, though I might not be able to play the most heavy modern games in 4k due to the limitations of the silicon, not the drivers.
Yes, in an ideal world, the drivers would just be open... but I've never had an actual hardware problem with any of my nvidia cards, while my friends running ATI/AMD cards would frequently complain about hardware failure back in the day. And these nvidia cards are still functional, still in computers running the latest kernel, etc. I don't know what their is to complain about.
As for the original question about longevity, I stopped trying to max out my uptime in the late 90s. I realized that, if I don't regularly reboot my computer, not only do I not get the benefit of newer kernels, not only am I exposed to vulnerabilities that have been fixed, but there's no guarantee my computer will even boot if booting isn't tested regularly. Did glibc break my system? systemvinit? bash? If I've had numerous updates to core software over the past year, how do I know something didn't break and where to begin isolating what did break? While I'm at it, when was the last time I tested my repair partition, and how about my backups, and how do I know those will work without testing?
These days, I usually go about 2 weeks between intentional reboots, though sometimes, they happen more frequently if there is a vulnerability I'm particularly concerned about. I compile the new kernels just in case I reboot, and along with that, the drivers. If I upgrade my nvidia-drivers but don't want to full reboot, I can log out of X, remove and reload the new drivers, and start X again. Even then, most of the time, it might only be steam that complains about a driver mismatch.
The hardware is 13+ years old and still working. It's way outdated, but functional for my mom's need for some web browsing, some document editing along with scanning/printing, etc. Even with modern drivers, the hardware is still limited to what the hardware is and a lot has changed in the CPU/GPU world since then. I really can't complain that it they dropped support in the current driver years ago.
I've got a 1050 Ti (2016) in my work desktop that just lost support at 10 years old, but will still play games of that hardware's era just fine. The 1660 Super (2019) in my home desktop is still supported and I can still play games just fine, though I might not be able to play the most heavy modern games in 4k due to the limitations of the silicon, not the drivers.
Yes, in an ideal world, the drivers would just be open... but I've never had an actual hardware problem with any of my nvidia cards, while my friends running ATI/AMD cards would frequently complain about hardware failure back in the day. And these nvidia cards are still functional, still in computers running the latest kernel, etc. I don't know what their is to complain about.
As for the original question about longevity, I stopped trying to max out my uptime in the late 90s. I realized that, if I don't regularly reboot my computer, not only do I not get the benefit of newer kernels, not only am I exposed to vulnerabilities that have been fixed, but there's no guarantee my computer will even boot if booting isn't tested regularly. Did glibc break my system? systemvinit? bash? If I've had numerous updates to core software over the past year, how do I know something didn't break and where to begin isolating what did break? While I'm at it, when was the last time I tested my repair partition, and how about my backups, and how do I know those will work without testing?
These days, I usually go about 2 weeks between intentional reboots, though sometimes, they happen more frequently if there is a vulnerability I'm particularly concerned about. I compile the new kernels just in case I reboot, and along with that, the drivers. If I upgrade my nvidia-drivers but don't want to full reboot, I can log out of X, remove and reload the new drivers, and start X again. Even then, most of the time, it might only be steam that complains about a driver mismatch.
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc
- rab0171610
- l33t
- Posts: 721
- Joined: Sat Dec 24, 2022 1:41 am
I have always had great luck with Nvidia cards. I used their closed source proprietary drivers on Windows for years so I can't really complain about it in Linux.
I just keep a stable version of the kernel on pause for long periods of time and I use the unstable Nvidia drivers. I keep of copy of the kernel version in my local repository.
Occasionally there is an update to the Nvidia drivers.
I shut the computer down daily when I am away. Generally, if I do not have any issues when the older drivers are loaded but I have not rebooted yet unless I try to play a game or do something that requires graphical support like VirtualBox. When something fails to start, I remember that the loaded Nvidia drivers do not match the installed version. I reboot.
As for just the Linux kernel and Nvidia drivers, I am not concerned about security vulnerabilities. I have never had an issue that I know about.
I just keep a stable version of the kernel on pause for long periods of time and I use the unstable Nvidia drivers. I keep of copy of the kernel version in my local repository.
Occasionally there is an update to the Nvidia drivers.
I shut the computer down daily when I am away. Generally, if I do not have any issues when the older drivers are loaded but I have not rebooted yet unless I try to play a game or do something that requires graphical support like VirtualBox. When something fails to start, I remember that the loaded Nvidia drivers do not match the installed version. I reboot.
As for just the Linux kernel and Nvidia drivers, I am not concerned about security vulnerabilities. I have never had an issue that I know about.
- eccerr0r
- Watchman
- Posts: 10239
- Joined: Thu Jul 01, 2004 6:51 pm
- Location: almost Mile High in the USA
- Contact:
need_to_reboot = hardware_failure | power_outage | glibc_changed | kernel_changed | nvidia-drivers_changed | ... would be nice to minimize the number of components in this chain.
Sounds like running nvidia-drivers is not good for servers. A reboot may not be a problem specifically for software that was updated, there may be other stuff that was working before the reboot but stopped afterwards. Whoever's fault it was, it matters not - it still stopped working, someone will complain, and hence uptime does matter for this application. Be lucky that you have a situation where random reboots are acceptable.
I've not run Windows on my machines for decades at this point, winXP was the last windows I touched. I've completely avoided win10, barely touched win7 and win8. All the better, there are some machines I'm still running Gentoo on that have not been reinstalled for over 2 decades and yet still up to date!
Sounds like running nvidia-drivers is not good for servers. A reboot may not be a problem specifically for software that was updated, there may be other stuff that was working before the reboot but stopped afterwards. Whoever's fault it was, it matters not - it still stopped working, someone will complain, and hence uptime does matter for this application. Be lucky that you have a situation where random reboots are acceptable.
I've not run Windows on my machines for decades at this point, winXP was the last windows I touched. I've completely avoided win10, barely touched win7 and win8. All the better, there are some machines I'm still running Gentoo on that have not been reinstalled for over 2 decades and yet still up to date!
Intel Core i7 2700K/Radeon Firepro W2100/24GB DDR3/800GB SSD
What am I supposed watching?
What am I supposed watching?
A high uptime server probably doesn't need a video card to begin with, regardless of brand...
BUT it should still have scheduled maintenance reboots to test things like boot configuration, update kernels (are they still doing live updates of running kernels? I remember that being a thing in some sectors a decade ago, but that's not something I need to keep up with), etc. It should also have redundancy, so that while one server is rebooting, the remaining server(s) can take over the load.
If you don't test your backups, you don't know if you actually have working backups. Likewise, if you don't test your boot configuration, your high uptime server may find itself down for a prolonged period of time while you try to figure out what change broke it in the last 600 days since the last reboot. Keeping it up may keep it up, but you might get exploited in the meantime, have hardware or configuration issues, and it comes with a false sense of "security" that it will remain up when you need it the most.
I still choose when to reboot my hardware and coordinating the downtime is a big part of that. I could easily resolve any downtime at all by adding redundancy, but I generally don't need it. I do have replacement parts on hand, along with spare capacity, for any vital components that may need an urgent fix, however.
BUT it should still have scheduled maintenance reboots to test things like boot configuration, update kernels (are they still doing live updates of running kernels? I remember that being a thing in some sectors a decade ago, but that's not something I need to keep up with), etc. It should also have redundancy, so that while one server is rebooting, the remaining server(s) can take over the load.
If you don't test your backups, you don't know if you actually have working backups. Likewise, if you don't test your boot configuration, your high uptime server may find itself down for a prolonged period of time while you try to figure out what change broke it in the last 600 days since the last reboot. Keeping it up may keep it up, but you might get exploited in the meantime, have hardware or configuration issues, and it comes with a false sense of "security" that it will remain up when you need it the most.
I still choose when to reboot my hardware and coordinating the downtime is a big part of that. I could easily resolve any downtime at all by adding redundancy, but I generally don't need it. I do have replacement parts on hand, along with spare capacity, for any vital components that may need an urgent fix, however.
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc