It's still retained by the various instances that lemm.ee federated with, and entering the url of a lemm.ee post on those instances should still let you find their local copies if they have it.
I'm pretty sure they've spent every cent, considering how much they have in fact produced.
The part that boggles me to this day, is that they spend the money on making a litany of insanely high quality assets and features, with seemingly no plan for how they'll fit together.
And then they proceed to spend even more money, and time, on trying to fit it all together into something that functions like a complete system.
And that's before you discuss their obsession with "realism". What there is to play, is marred with balancing issues. Better ships are just... Better. Because they insist on weapons and ships functioning "logically" within the game universe, rather than in whatever way is the most fun.
Fighters beat bigger ships because equipping the same weapons, a fighter can hit every shot it takes at a slow moving giant. Meanwhile the travel-time of weapons make the fighter completely unkillable for the big ship, because the fighter can land shots from a range where its own speed allows it to dodge literally everything the big ship might send its way.
They've been buffing the shields and ammo counts on bigger ships, but all that does is make the fight last longer.
The project is real, but it's a mismanaged catastrophe.
intel-undervolt/amdctl for cpu, lact for amd gpu, gwe for nvidia gpu (although voltage control on linux with nvidia is not possible, you can get a similar result by overclocking+limiting power)
From what I've read, Kent expects others to just take his word for it, when he says his code wont break anything.
The kernel has long had practices around merging and releasing, specifically so that it no longer has to rely on contributors simply promising that their contributions have been tested and confirmed safe.
But Kent has repeatedly skirted or straight up ignored those practices.
This isn't about not agreeing on code needing to be reliable. It's about one person refusing to work with an established way of achieving that when contributing to an upstream effort.
He's been told how to contribute again, and again, and again. And every time he takes it like it's a personall affront to his credibility.
This isn't even something you should be doing for your devs just because being nice to them is nice.
So many indies on their second and third games are showing that once you get the ball rolling on institutional knowledge (skills and tools developed during the making of a game, contributing to the next) you can SERIOUSLY up your game. And for a lot less cost than it would have been to go that big from the start.
Meanwhile big studios are dumping staff and therefore expertise like it's no big deal. Switching to a revolving door of subcontractors who can't possibly get to intimately know the games they work on.
They mean other platforms like GOG or Epic, not stuff like consoles.
Steam games mostly work, with some exceptions. You can check out ProtonDB to see more precisely what games work, which ones straight up don't, and which ones need a fix. ProtonDB will usually also tell you what that fix is, which is handy.
But most of the time, you can just hit play and not worry about it.
A note on dualbooting. Linux uses different filesystems from windows. It can access windows NTFS partitions, but it's not a smooth experience.
A common pitfall is trying use your game library while it is still on a windows filesystem, from linux. Since you can see the folders, and even add them in steam, it'll seem like it should work. But you'll run into issues actually running the games. It's technically possible, but not worth the hassle.
Generally you really want to either format your storage and redownload your games, or if you have the space, copy them over to a fully supported file system.
I think the mangaka said it's never happening. He simply doesn't want it to become that commercialized. A japanese Bill Watterson, I guess.