TL;DR for the impatient: old PC, turned away at the door by Windows 11, rescued by EndeavourOS. A few evenings tinkering with storage, GameMode and GPU power, and my “too old” box runs games smoother than it ever did under Windows.
No new hardware, no bloatware, no regrets. Below is the whole story, with the tech, but explained in plain English.
A PC nearly ten years old that’s officially “too old” for Windows 11, yet flies like new on Linux.
In this article I’ll take you along on that switch: why I picked EndeavourOS instead of going along with the Windows upgrade, what my (by now vintage) hardware is, and the curious driver story around an NVIDIA card the manufacturer no longer supports.
First the why and the hardware, then hands in the engine: storage, GameMode and GPU power. Here for the story? Just read on. Here for the configs? You’ll spot them by the blocks of code. 🎮
The beginning: a PC that creaks and groans
My PC is like an old rally car: it smells of 2017, makes the odd suspicious noise, but give it the right tuning and it still flies out of the corners. The hardware comes from the Ryzen/GTX-1080 era (2016–2017), and lately that was starting to show: Windows 10 felt slow and sluggish, boot times dragged, and everything “creaked and groaned” a little.
Add to that the fact that Windows 10 is end-of-life and the logical next step according to Microsoft would be Windows 11.
But that’s where the shoe pinches. Windows 11 looked at my AMD Ryzen 7 1700 (first-generation Ryzen), consulted the guest list, and said: “Sorry sir, you’re not on it.” Eight cores, still in fine shape — turned away at the door, because first-generation Ryzen is not on the official list of processors supported by Windows 11.
Officially, my machine isn’t even allowed to run Windows 11.
Send a perfectly good PC to the knacker’s yard because a new OS thinks it’s too old? I wasn’t having it. So I walked across the street, where EndeavourOS simply held the door open.
The choice: EndeavourOS instead of Windows
Rather than climbing onto the upgrade treadmill, I chose EndeavourOS; an Arch-based distribution.
Why:
- No bloatware. You get a clean, bare system and build up only what you need yourself.
- Bleeding edge but stable enough. Arch under the hood means up-to-date kernels, drivers and software (rolling release), no waiting years for updates.
- EndeavourOS makes it approachable. Where bare Arch has a steep learning curve, EndeavourOS adds a pleasant installer, handy defaults and convenience without spoiling the Arch philosophy.
- It’s my machine again. Faster, lighter, and I decide what runs.
The result: the same hardware feels fast and awake again.
The specs (the “oldies” still doing just fine)
| Component | Details |
|---|---|
| CPU | AMD Ryzen 7 1700 — 8 cores / 16 threads (Zen 1, 2017) |
| GPU | NVIDIA GeForce GTX 1080 (Pascal, 2016), 8 GB |
| RAM | 16 GB |
| Motherboard | ASUS PRIME X370-PRO |
| OS drive | Crucial MX500 1 TB SSD (btrfs) |
| Games drive | Hitachi 3 TB HDD (btrfs) |
| Extra storage | WD 5 TB HDD + Samsung 960 EVO 500 GB NVMe |
| OS | EndeavourOS (Arch-based), kernel 7.0.x |
| Desktop | KDE Plasma 6.7 on Wayland |
| GPU driver | NVIDIA 580.159.04 (legacy nvidia-580xx, community-maintained) |
The driver story: NVIDIA lets the GTX 1080 go
An interesting detail of “older hardware on Linux”: NVIDIA moved my GTX 1080 to the legacy branch. The 580 series is the last driver branch that supports the Maxwell, Pascal and Volta architectures. The mainline NVIDIA driver has moved on past that and drops my card.
The solution on Arch/EndeavourOS: the community-maintained legacy packages (nvidia-580xx-dkms and friends, from the AUR).
So not nouveau (the open-source reverse-engineered driver), but still the real proprietary NVIDIA driver — just an older branch that the community packages and keeps alive. Exactly the kind of “long tail” support a rolling-release community excels at, and where Windows simply leaves you stranded.
Translated into human terms: the manufacturer said “done with that card”, and the community said “we’re not”. That difference is precisely why my 1080 still runs.
The deferred maintenance I never saw
This didn’t come together in one go. Over several sessions with Claude (Claude Code) a fair few things got straightened out that I hadn’t even noticed myself:
- SSDs that weren’t being used optimally and turned out to be too full as well; the sort of thing that quietly undermines your performance and lifespan without you noticing. In earlier sessions that was cleaned up and set up properly.
- GameMode was missing entirely at first. That I even started looking at Feral GameMode was a tip from Claude; one I then dutifully checked against the Arch Wiki before trusting it. (A tip is nice, but checking it yourself stays the smart move.)
In short: a pile of “invisible deferred maintenance” that got fixed bit by bit. Or, put a little less flatteringly:
My wall of shame (quietly suboptimal):
- 📦 SSDs: too full, like an overstuffed suitcase whose zipper won’t close anymore.
- 🔇 GameMode: installed, sure, but not working; see below.
- 🤷
gamemode.ini: didn’t exist, so everything ran on factory-dimmed settings.
No disaster, but exactly the kind of thing you don’t notice for years because “it works anyway”.
The fun part: tuning everything just right — together with Claude
Now we dive under the hood. More of a road person than an engine person? Feel free to scroll on to “What actually happens when I launch a game?”, where you’ll read in plain English what it gets you, without a single line of code. For the tinkerers: how easy this went was the genuinely surprising part. Always the same approach: first checked on my actual system, then adjusted, then verified.
A selection:
1. btrfs autodefrag on the games HDD
My games live on a real 3 TB hard disk (not an SSD). On btrfs (the modern filesystem I use) a file can, over time, end up scattered across the disk in separate fragments; especially with game updates, savegames and shader caches.
On a spinning disk with a read head that costs extra time; on an SSD it doesn’t, but on my HDD it does.
In plain English: a fragmented disk is like a book whose pages are out of order; the read head has to keep flipping back and forth. Defragmenting puts the pages back in sequence.
Solution: turn on autodefrag in the mount options, plus a one-time defrag of the existing data.
# in /etc/fstab, mount options for the games drive:
# ...,compress=zstd,autodefrag
# one-time defrag + recompress of the existing data:
sudo btrfs filesystem defragment -r -v -czstd /mnt/Programs⚠️ Note: defrag breaks reflinks/shared extents. Got snapshots? Then be careful. In my case there were none on that disk, so it was safe.
2. Feral GameMode on all Steam games at once
Feral GameMode temporarily optimizes your system the moment a game runs (CPU governor to performance, I/O priority, split-lock mitigation off, etc.). You enable it per game via a Steam launch option:
gamemoderun %command%
Sounds simple, until you realize you have to type that little line in by hand, per game. I’ve got over 100 games installed.
And it gets worse: launch options are per Steam account, and at our place the kids play on the same PC too, each with their own account. Three accounts × 100+ games = filling in the same field hundreds of times. Nobody does that voluntarily.
So we made a script that does it blindly and in bulk: it reads the launch options out of Steam’s localconfig.vdf and sets gamemoderun on all installed games, for all accounts in one go. It’s tidy about it, too:
- idempotent: Games that already have it are skipped, so you can run it again without worry after installing new games;
- it makes a backup first;
- and it leaves Steam’s own tools/runtimes alone.
💡 Important: Steam must be fully closed before you edit that file, otherwise Steam overwrites your changes on exit.
In plain English: instead of ticking the same box hundreds of times, for myself and for the kids’ accounts, we press the button once and everyone in the house is sorted.
3. The silent saboteur: why GameMode did nothing
And then we found the culprit. GameMode was running, but secretly did just about nothing, and the logs pointed straight at the offender:
pkexec: Error executing command as another user: Not authorized
gamemoded: ERROR: Failed to update split_lock_mitigateWhich means: GameMode knocked on the door to open up the engine, but the system kept answering “no permission” and shut the door again. All those lovely optimizations were stopped at the threshold.
The cause: on EndeavourOS all com.feralinteractive.GameMode.*-helper polkit actions default to allow_active=no. Polkit is the system that decides who’s allowed to do what with elevated rights… and it had simply given GameMode no key.
The fix is one small rule file that says: “this user is allowed to do this”:
// /etc/polkit-1/rules.d/10-gamemode.rules
polkit.addRule(function(action, subject) {
if (action.id.indexOf("com.feralinteractive.GameMode.") === 0 &&
subject.active && subject.local && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});The result was measurable right away. Before the fix the CPU stayed in its power-saving mode; afterwards it jumped neatly to full power when a game launched:
$ gamemoded -s
gamemode is active
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance # was: schedutilNo more Not authorized in the logs. The saboteur was unmasked.
4. Tuning GameMode for max performance
Here comes the biggest confession. For months I happily pressed my turbo button.
Spoiler: that button wasn’t connected to anything. I was gaming on a placebo.
Because besides the saboteur above, it turned out I had no gamemode.ini at all either. So I’d had GameMode “switched on” for a while, firmly convinced it was doing something (just less than hoped), but without your own config everything runs on meager factory settings, and those were partly refused by the polkit block on top of that. Nothing twice over, then. And I’d never once noticed it myself: it felt faster, purely because I knew it was “on”.
So: I thought I was driving in sport mode, but the car had been in plain old normal mode the whole time. Only when I pulled out the manual did the penny drop.
In ~/.config/gamemode.ini I then really tightened the screws:
[general]
desiredgov=performance
defaultgov=schedutil
renice=15 ; game gets higher CPU priority
ioprio=0 ; highest I/O priority
disable_splitlock=1 ; less CPU overhead
inhibit_screensaver=1
[cpu]
park_cores=no ; keep all 16 threads available
pin_cores=no5. Automatically pushing the GPU to max power while gaming
Finally, a hook that sets my GTX 1080 to its maximum power budget on game start (220W instead of the 210W default) and puts it back afterwards. Because nvidia-smi requires root, that goes through two small, tightly fenced-off scripts (NOPASSWD via sudoers, only those two commands):
# in gamemode.ini
[custom]
start=/usr/bin/sudo -n /usr/local/bin/gpu-perf-on
end=/usr/bin/sudo -n /usr/local/bin/gpu-perf-offAnd yes, it really works too — in a test the power budget rose neatly and then came back down:
$ gpu-perf-on
Power limit for GPU 0000:0A:00.0 was set to 220.00 W from 210.00 W.
$ gpu-perf-off
Power limit for GPU 0000:0A:00.0 was set to 210.00 W from 220.00 W.Meaning what?: the moment a game starts, the graphics card is allowed to pull a little more eagerly from the wall socket; close the game and it drops back to normal.
What actually happens when I launch a game?
The abstract “it’s optimized” suddenly became concrete. The moment I launch a game (via gamemoderun %command%), GameMode flips all of this in one go and neatly puts it back on exit:
| On game start | From → to | What it does |
|---|---|---|
| CPU governor | schedutil → performance (all 16 threads) | Cores stay at a high clock, no slowdown from ramping up/down |
| split-lock mitigation | on → off | Less CPU overhead for certain instructions |
| I/O priority | normal → highest (ioprio=0) | The game’s disk access gets priority |
| CPU priority | normal → renice -15 | Game cuts in front of background processes |
| Screensaver/DPMS | active → blocked | Screen doesn’t blank during play |
| GPU power limit | 210W → 220W (+ persistence) | A bit more boost headroom for the GTX 1080 |
On leaving the game everything is reset (governor back to schedutil, power limit to 210W, and so on). No permanent interventions, no disk running at full power all day.
But the difference I actually feel isn’t in any table of clock frequencies. It’s in this: where the logs used to fill up with Not authorized and GameMode did nothing in practice (❌), there are now zero errors and it finally does its job for real (✅). The placebo button is, for the first time, connected to something.
And what does that actually get you?
Honestly and with realistic expectations, specific to my machine:
- Less stutter and steadier frame times. The biggest, most noticeable gain.
Because the CPU no longer clocks back down during quiet moments, you don’t get a sudden dip when the action kicks off. - Smoother load times and less hitching when streaming assets; precisely because my games live on a real HDD, the higher I/O priority noticeably helps here (and the btrfs
autodefragworks with it). - Smoother under pressure. With a somewhat older 8-core (Ryzen 7 1700) it makes a difference that the game gets priority and the cores stay up to speed; background tasks drag your framerate down less.
- No big jump in average FPS. That’s the honest part: this is about consistency, not a magical +30 FPS. The GPU power bump is marginal on top of that (~5%).
In short: it feels smoother and more predictable, and at this hardware’s age that’s exactly what you want.
Honestly: what does and doesn’t work
No miracles, so the nuances too:
- On Wayland, GameMode’s NVIDIA GPU tuning doesn’t work (it leans on
nvidia-settings, an X11 tool). The power-limit hook withnvidia-smidoes work, because that’s at the driver level. My card already boosts to max clocks under load on its own anyway. - The power-limit gain is marginal on a GTX 1080 (~5% headroom). It’s a bonus, not a cure-all.
- “Max FPS” is mostly about consistency: less stutter, less downclocking, steadier frame times, not a big jump in average FPS.
The greenest PC is the one you don’t throw away
Gaming aside: there’s a nice edge to this story too. The “official” route was buying a new Windows 11 box, easily a few hundred euros, plus a perfectly good computer landing on the e-waste pile (or in wrapping paper as a hand-me-down to one of the kids who can’t do much with it yet). My route cost a few evenings of tinkering and €0 in hardware.
Microsoft thought my PC was too old. A rolling-release Linux distro that keeps even legacy GPUs alive thought it was fine. I know which of those two I find more likeable… and my bin stays empty.
Conclusion
My PC is officially “too old” for Windows 11. On EndeavourOS it feels like new again: fast, clean, and entirely bent to my will. The combination of a rolling-release distro that keeps even legacy NVIDIA cards alive, plus a few targeted optimizations (btrfs, GameMode, GPU tuning), turns these “oldies” back into a perfectly good gaming rig.
And the best bit: what used to be hours of digging and combing through forum posts, I now did in a few relaxed sessions, always with a check on my actual system before anything changed. The most instructive thing was maybe just how much was quietly suboptimal without me noticing: too-full SSDs, GameMode that was “on” but barely did anything, missing configuration. That kind of invisible deferred maintenance is exactly where a second pair of (digital) eyes is worth its weight in gold, provided you double-check the advice yourself afterwards. Old hardware, new fun. 🎮
