For a while I daily drove a Purism Librem 14 with Debian's fully free kernel, and installed as few non-free packages as possible, including firmware blobs (which I didn't install any of until I decided I needed Bluetooth). My experience with gaming was generally fine.

With linux-libre you really have to buy your hardware specifically with support in mind. You're limited to Intel and non-bleeding-edge AMD graphics cards, a very small range of wifi cards, and no Bluetooth. Otherwise, video games should work as well as they would on any other computers with the same specs. Especially if you're also limiting yourself to games with free engines - I'm not aware of a single libre game that demands more than a modern Intel integrated graphics card can provide, even on high settings.

I came across a bunch of those recently, which is how I came up with the idea for this, as a parody :)

Internet horror is disappointingly un-creative. I have no idea why the weakest works (sonic.exe, anti-piracy, kill screens) always end up becoming huge trends, or why so few people try to put a significant twist on said trends.

Saru and Kelvin Spock would probably get along really well. Everyone else would be having heated arguments that I think would be amazing to witness, if not take part in.

I think I'd most like to sit between Mariner and Pike, though.

1. I believe there is still an issue with Windows deleting Linux bootloaders during some updates. You'll be fine if you install Linux on a separate disk, and even if you dual-boot on one disk and the bootloader gets deleted, there are ways to recover it. You don't strictly need to have separate data and OS partitions, and I've gone back and forth on whether I prefer it - it makes distro hopping and disk encryption easier, at the cost of potentially inefficient use of space and serious consequences if your OS partition fills up.
2. Disk encryption is very straightforward if you use separate OS and data partitions. You literally just tick a box during the install and enter an extra password. It won't upset Windows any more than a normal install does (i.e. Windows might think it's corrupted, but won't do anything without your input). With one partition for everything, it's still possible, but the encryption will be much weaker and handled by the bootloader in a somewhat clunkier way, and I'm not sure if Mint even supports that setup.
3. I don't have much experience with this myself, and certainly not on Linux Mint, so I'll leave this one to other commenters.
4. Synaptic is just a fancy frontend to APT, and I think Mint also has something called mintInstall, which was just an apt frontend back when I used it, but I think it also supports Flatpak now. It's entirely up to personal preference as to which UI you prefer. I do recommend you set up Flathub if it's not there by default, as it gives you access to a ton of useful apps that can't be packaged by Debian, Ubuntu, and Mint for various reasons.
5. Don't download software from random websites unless it's absolutely necessary. Chances are, their version either won't work well, if at all, or will break your system. Try APT first, Flatpak second, everything else is a last resort option. If a program you used on Windows doesn't have a (working, native) Linux version, try finding and learning to use an alternative that is in the APT repositories before downloading the Windows version and using it on Wine. Back up your most important files from Windows before installing Linux in dual boot, just in case you make a mistake somewhere. To answer the last question, stick to the default terminal emulator and Firefox installation unless there's a feature you really want in another one; the distro's developers picked them for a reason, after all.

VLC's file format support is amazing for a project that rolls its own codecs, etc, but it's missing some important features for me on the music front, primarily gapless playback and library management. I generally prefer to use software tailored to my DE. I've yet to find a better video player anywhere though; GNOME Videos and Kaffeine come closest and are a little easier to use, but are still far away from VLC's capabilities.

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!

https://framatube.org/w/9dRFC6Ya11NCVeYKn8ZhiD

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.

I still follow Planet KDE and Planet Debian, and can vouch for both. They're great for both learning about the development processes of those projects, and finding interesting blogs on unrelated topics that happen to have been written or linked by the contributors.

I find it really fun to browse the Debian repository and its source code with their dedicated websites for doing so ( https://packages.debian.org/ and https://sources.debian.org/ ), to find all the obscure utilities, and silly code comments.

Depends on a few factors, AFAIK as a non-lawyer. If the license allows closed-source derivatives (i.e. is permissive rather than copyleft), then anyone can create a closed-source version with all of the contributors' changes, including the original maintainer. And anyone can choose to keep it open-source. The community contributions still to some extent belong to the contributors, though the license waives most of their rights.

Some projects are copyleft, but contributors are required to sign a license agreement (a CLA) which allows a single entity to change the license as they desire, including to closed-source - this is a good reason to avoid such projects. The contributors don't own their work in such a case, but they can still fork the old project as it was before being taken closed source.

In a copyleft (e.g. GPL) project with no CLA, it's illegal for anyone to make a closed-source version, and a major contributor could sue even the maintainer for doing so.

In all such cases, the change to a closed-source model does not erase the existence of the open-source code with community contributions. A fork is always possible.