Logs

Get a better job so you can afford better drugs. This is "Minimum Wage Methy", and you want to be "Salaried Methy".

Gotta say... This is not how you'd generally do any of this. Where you get this info?

It's not the CPU. All that will do is consume CPU and raise your energy bill.

1. Get some sort of resource monitor running on the machine to collect timeseries data about your procs, preferably sent to another machine. Prometheus is simple enough, but SigNoz and Outrace are like DataDog alternatives if you want to go there.
2. Identify what's running out of control. Check CPU and Memory (most likely a memory leak)
3. Check logs to see if something is obviously wrong
4. Look and see if there is an update for whatever the proc is that addresses this issue
5. If it's a systems process, set proper limits

In general, it's not an out of control CPU that's going to halt your machine, it's memory loss. If you have an out of control process taking too much memory, it should get OOMkilled by the kernel, but if you don't have proper swap configured, and not enough memory, it may not have time to successfully prevent the machine from running out of memory and halting.

Mkay. So you're just some person out here on the Internet who has zero concept of how this works as well I'm assuming?

Feel free to dispute any single point I've made.

Well, let me break it down for you since you don't seem to work in this space:

1. A Roadmap is a strategic timeline of targeted goals that are estimated to be completed in a specific timeframe that is NOT nebulous. It's done this way to provide consumers of a product some knowledge of where the product is going to entice them to buy-in to said product to allow them to estimate their own commitments to the project and adoption.

2. A backlog is NOT a Roadmap. I planned orchestration of tickets is a Roadmap. We create this to ensure users that problems they are experiencing will be resolved, and in what order to expect them to be resolved. This works for both for-profit engineering, and also FOSS projects. A great example of this is the Roadmaps provided by distros uses by Enterprise customers.

3. Your comment about "inflexible commitment" seems to say you don't understand the above points. If you're pushing a product which you want people to adopt, and you're communicating to them why they should adopt it, the last thing you would want to do is say "Hey, we're kiiiiinda going this way, but maybe not. We'll see."

4. Programming DOES work like an assembly in a sense. That's why you have tickets, tags, classification, triage, status, and...backlog. What gets thrown in the floor is what I'm talking about.

Regardless of how you feel about the pace of the project, it's absurd to throw out a bunch of ideas as tickets and expect them to all get done without a commitment. Or, dare I say, a roadmap.

Fullscreen means the entire screen.

Windowed/Borderless Fullscreen means you can pin other windows above it.

If you're playing via Proton YMMV because of the various rendering tricks needed to make certain games work, but mostly it should be fine.

https://gist.github.com/camullen/0c41d989ac2ad7a89e75eb3be0f8fb16

Just cut Windows out as much as possible and run everything in WSL. Setup everything to boot straight to all your WSL layers, and aside from the absolute shit Base OS, it should be the same.

Okay, but give a little look into where your disk is using space.

du -hsc /

And work from there.

It depends on where that storage was used. Some details would be useful.

At its core, you shouldn't need to keep any previous layers than the one you're using for the OS.

You also technically don't need snapshots for anything but your personal file space.