Yeah, only thing I can think of is the few banking apps that don't have web versions.

I was lucky enough to have all my banking and 2FA apps work perfectly on GrapheneOS. The only app that gave me a significant amount of trouble was iClicker, which my school uses for attendance. That was fixed by enabling Google Play location services, and there was a (fairly expensive) alternative anyway.

I did have to buy a new phone to use Graphene, because I got my previous one as part of a carrier's cell plan, and it had a locked BIOS. Though I think the purchase was worth it, and just moving my SIM card from one device to another was enough to get it working.

I'm currently on the RHCSA path myself, and I can tell you that the courses are not worth the thousands that Red Hat charges. There are plenty of unofficial video courses on YouTube and Udemy and study guides and practice tests on GitHub that are free or cheap, and other resources for every individual study topic, which will be good enough.

However, though I can't speak from experience, it seems like the cert itself will look good enough on a resume to justify the investment of $500 and a month of studying.

The major tradeoff with zRAM is that programs are much more likely to crash due to running out of memory, but will run faster when memory is running low and freezes are less likely. You can think of it as offloading the pressure that traditional swap puts onto your disk, onto the (much faster) CPU. There will be an impact on CPU usage, but not enough to cause noticeable slowdown; in my experience running Linux, the CPU is almost never the reason something is slow, and is only going to be under significant pressure if you're running a 3D game in software rendering, compiling a large program, or another complex CPU-bound task.

I wouldn't recommend making the switch unless you often encounter system freezes or slowness while running tasks that use a lot of RAM (like web browsing on certain sites, or gaming), but it will improve things in that case.

TOS: The Cloud Minders. One of the show's extremely heavy-handed message episodes, this time about classism and labor rights. It's quite dramatically compelling in addition to expressing its ideas eloquently.

TAS: Beyond the Farthest Star. One of the more "normal" episodes of that series, but it really works for me.

TNG: Contagion. One of the most tense and action-packed TNG episodes, featuring computer malfunctions both amusing and terrifying, but also a great showcase for all the characters, and their ability to combine their talents to solve what seems like an impossible problem, to the point that it's one of the episodes that got me into Trek in general (alongside Remember Me).

DS9: Visionary. Pretty good episode of time travel weirdness, and one of my go to examples of what I think is best way to go about explaining time travel: don't explain it, just do whatever wacky shit you want and laugh off the paradoxes with a recurring joke. "I hate temporal mechanics!"

VOY: Latent Image. In addition to being yet another fascinating exploration of the rights and sentience of artificial life, with a hint of an ethical dilemma in there, I really relate to how the Doctor's trauma responses are described.

DIS: There Is A Tide. I love all of the scenes between Admiral Vance and Osyraa.

PIC: The Impossible Box. I remember that being one of the more tense and well-made episodes of the show, especially Soji's existential crisis and Picard's Borg flashbacks, although I find it hard to think in individual episodes with this one.

LD: Veritas. The show hadn't really clicked with me before this episode. I loved the whole theme about the lack of attention the command crew gives to the ensigns, and how this just adds to their problems.

I've only really seen the consensus classics of ENT, and while I have seen SNW and PRO, my favorites are all consensus favorites that get a decent amount of buzz already.

My guess is that they meant either TOS, or the starship Enterprise as compared to the space station DS9.

Right now I'd say the best open-source DAW for Linux is LMMS if you want to do everything just on your laptop, or Ardour if you want to use external instruments.

LMMS has some shockingly versatile built in synths, including a port of ZynAddSubFX, supports LADSPA/LV2 plugins, and supports using Wine to run 32-bit Windows VSTs. I'm unsure of Ardour's VST support, but it at least supports LV2 plugins. Either of those, if you install them through your distro, will likely include Calf Studio Gear, an extensive collection of LV2 effects and a couple synths. As for ones that run natively on Linux, there's synthv1, samplv1, drumkv1, and padthv1, though I've had trouble getting them working myself.

I've found some good stuff on the Linux Audio Wiki but IDK how up to date most of it is.

1. Create a source control repository containing all your code, and publish it to an online code forge. GitHub's docs might help with this: https://docs.github.com/en/get-started/start-your-journey
2. Choose an open-source license and add it to the repository as a LICENSE file. If you want to require any projects that build upon yours to be open-source too, the GNU GPL is a good choice. If you want to allow proprietary programs to include your library without releasing any source code other than that which is directly based on yours, the GNU LGPL is good for that. If you want to allow people to do whatever they want, even use all your code as the basis of a proprietary program without credit, the Unlicense is a good choice. There are a lot of licenses with different degrees of "copyleft" and attribution requirements in between. Technically publishing with a license file is all you need to do, but there are more things you should do.
3. Create a README text file describing what your program does, and instructing users on how to compile and run it. Consider including more detailed documentation on how to use it, as well.
4. Clean up your code and file layout so that it's as easy as is feasible for other programmers to understand.
5. Promote your project to whoever you think might find it useful!

chmod'd all my home directory's files and folders recursively. First to 600, which prevented me from listing any folders, then to 700, which broke a few programs, then to 755, which broke ssh.

Open-source software is distributed primarily as source code in a human-readable programming language. Computers can't actually read these programming languages directly; they need to be translated into the machine language of their CPU (such as x86_64). For some languages, like Python, code can be "interpreted" on the fly; for others, like C, programs must be "compiled" into a separate file format. Additionally, most programs consist of multiple files that need to be compiled and linked together, and installed in certain folders on your system, so the compiler and additional tools work to automate that process.

Most users of Linux rarely if ever have to compile anything, because the developers of Linux distros, and some third parties like Flathub, curate collections of (mostly) open-source software that has already been compiled and packaged into formats that are easy to install and uninstall. As part of this process, they usually add some metadata and/or scripts that can automate compiling and packaging, so it only requires a single command (makepkg on Arch, dpkg-buildpackage on Debian.) However, some newer or more obscure software may not be packaged by your distribution or any third-party repo.

How to compile depends on the program, its programming language and what tools the developers prefer to use to compile it. Usually the README file included with source code explains how to compile the software. The most common process uses the commands ./configure; make; sudo make install after installing all of the program's dependencies and cd-ing to the source code directory. Other programs might include the metadata needed for something like makepkg to work, be written in an interpreted language and thus require no compilation, or use a different toolchain, like CMake.

It still sounds to me like something's up with the disk. Can't think of any solutions to suggest but I would run a SMART health check on it:

sudo apt install smartmontools  
sudo smartctl -a /dev/sda

If you prefer a graphical tool, you can do the same thing with GNOME Disks, which also has options for disk benchmarking.

In the resulting report, the overall health state should be "PASSED", the "Type" column should show "Pre-fail" and "Old age" values, and the "Media-Wearout-Indicator" should be close to 100. If the overall health state is "FAILED", then you will want to back up your files immediately and consider getting a new SSD.

I suspect a lot of "evil admirals" were promoted by votes from, or just to appease, reactionary political movements.

I'd recommend using Fedora Workstation, it was a great experience back when I myself had an HP ENVY "fliptop". Anything with GNOME as its desktop environment should be perfect.