Not sure what the title was before you changed it, but if I see a post in my feed that looks like this (without the "very bad take" part), I wouldn't even want to open the post to see the description. I'm glad you clarified by editing the title, but without making your stance clear in the title from the very beginning, it would be bound to receive a barrage of downvotes.

This is not very common knowledge, but it is no longer recommended to press S or U before B for SysRq. The official documentation of sysrq has stopped recommending this practice, as it may be harmful to modern filesystems. Writing to a storage device while the kernel is in a bad state has the potential to cause corruption, and modern journaling filesystems like EXT4 and BTRFS are designed to survive crashes like this with minimal (or no) corruption. Instead, you'll likely want to use Alt+SysRq+REIB (and make sure you are waiting multiple seconds between each keypress, as they do not complete instantly!).

You may instead try to kill the most memory intensive non-vital process with Alt+SysRq+RF, which may stop you from crashing to begin with (this works especially well for memory leaks). SysRq+F will invoke the oom (out of memory) killer, which will kill the most memory intensive non-vital process without causing a kernel panic.

If you need to restart, the most ideal situation is to enter a TTY and cleanly reboot, in which case you can do Alt+SysRq+R to grab control from the display manager, then Ctl+Alt+F3 or Ctl+Alt+F4 (I believe most distros have the first login session run on the TTY accessible from Ctl+Alt+F2) to switch to another TTY. You can then log in and do sudo systemctl reboot if your computer is still responsive. You may need to kill some processes before your system becomes responsive enough to log in on a TTY, which is where Alt+SysRq+F is useful, but in extreme situations it may require Alt+SysRq+EIB.

So a basic order of steps to try may look like:

1. Try Alt+SysRq+RF and wait a few seconds to see if your system starts responding. If not, you can either try it another time or two, or move on to 2.
2. See if you can switch to a TTY with Ctl+Alt+F3. If so, try to log in and sudo systemctl reboot. Else move onto 3.
3. If you are in a TTY, switch back to the main login with Ctl+Alt+F2. Then do Alt+SysRq+REIB.

In the spirit of other users giving mnemonic devices, you could remember REIB with Reboot Even If Broken, or the oom killer RF with Resolve Freeze (someone else can probably think of something better for RF; I'm not great at making mnemonic devices).

TL;DR: There are SysRq combinations that are less prone to damage/corruption than Alt+SysRq+REISUB, so use the above flowchart, or just remove the S and U for Alt+SysRq+REIB (if you don't want to troubleshoot first) for less chance of filesystem corruption from a bad kernel. You can often recover the system without having to hard reset (Alt+SysRq+B). And ALWAYS wait between SysRq keys, as they do not finish instantly.

I replied about getting the updated kernel on Bazzite on another one of your comments, but I want to clarify that this is not only a bug for those that have resizable bar and 4g decoding as BIOS options, and it does not always happen on game start. I just want to reinforce that this is very likely the exact issue you are experiencing, and it is patched in kernel version 6.9. The only reason you don't see the popup from the linked issue is because that is a check that was added in 6.9rc-5 to validate hardware capabilities; the root issue underneath has been present since 6.6.30, but only results in a crash with no error dialog. This particular kernel bug happens when the CPU runs out of VRAM space that is accessible to it, and tries to move data to other parts of VRAM (with the help of the GPU) to make space in the section visible to the CPU. Since resizable bar makes all VRAM visible to the CPU, that's why it fixes the issue for some, but that is not the root cause of the problem. There is an off by one error discussed in the kernel bug thread that was linked that incorrectly handles the VRAM swapping and only became an issue after a check was written to validate the hardware capabilities (which fails due to the off by one error). This can happen after some time playing the game, after the CPU-accessible part of VRAM is filled up, however long that takes.

This will be fixed in a few weeks when the 6.9 kernel is pushed to the Fedora repos, or you could compile and install the 6.9 kernel using my instructions on your other comment. Or you could continue to use Mint until the kernel is updated, whatever works for you. Other than this one obscure kernel bug, Bazzite will generally be the much better option for gaming as far as performance and user experience goes. Mint follows the Debian/Ubuntu update cycle, so its kernels are old and without many enhancements to gaming that exist in the newer versions of the kernel present in Bazzite and Fedora. Of course, you can choose whatever distro you'd like, I just wanted to provide a method for you to switch back to Bazzite if you prefer it (and explain what the issue is and how to fix it).

The flowchart is as follows:

LibreOffice or OnlyOffice for desktop apps (no, they are not Microsoft apps, but yes they use Microsoft formats and can edit and save Microsoft documents/spreadsheets/etc). OnlyOffice is the closest of the two to the Windows experience.

If you really aren't open to using alternative software (which is strange given that you're using Linux), then the web apps exist. I've heard they're really close to the actual desktop suite, though I don't have any interest in ever using them as we have very good free and open source alternatives available (see above).

If the web apps don't cut it for you, then you can run the official apps in a VM, or maybe through WINE. Here's the WINE DB page for Microsoft Office, which lists various Office versions and their level of compatibility through WINE.

~~Copilot will likely not be possible to secure on Linux in a standalone desktop app (unless someone somewhere hacked something together through Electron to use a web version)~~. Another user said that Copilot is available inside Microsoft Edge, so I suppose you could install that, though I'd highly discourage that. Reliance on LLMs is quite frankly a plague to society, and often feeds incorrect, biased, or purely fabricated responses, as LLMs merely attempt to predict what word is most likely to occur next based on a set of training data, none of which was vetted for accuracy, racism, zionism, sexism, etc. LLMs like copilot do not have any form of intelligence, and do not understand what they are saying. I highly recommend you just use a search engine in your browser, because it'll feed you the same info all the LLMs were trained on anyway.

OneDrive recently received native support in GNOME, so I think you should be able to access it in your settings under accounts/connected services (whatever GNOME calls it nowadays)? I've never tried to use it, so other people will know better than I will there, but it should be possible to use.

sudo is not a fairly simple program. Last I checked, it had ~177k lines of code. It provides functionality far beyond what is needed of an average user. doas is a simpler alternative (also using SUID) at ~3k lines of code. It comes from OpenBSD. There is absolutely a problem when it comes to SUID binaries. If you can find a way to exploit the permissions given at the start of the SUID binary before user authentication occurs (since the UID is set before the binary runs), you have yourself a full privilege escalation vulnerability. systemd is very well integrated with the distros that use it, being the first process to run after the kernel is initialized. There will never be a point at which systemd is not functioning, but the rest of your system is perfectly fine. It is an absolutely necessary part of the system (assuming your distro uses it), and if it goes down, you have to restart your system. As such, I don't see any validity to the statement "you want to always work, even (especially!) when other things get borked". What exactly do you see as being an issue with run0? What specific part of its implementation do you seem to have a problem with? It's just a symlink to systemd-run, which is already very well tested and has been around for a long time. It's also far simpler than sudo, and removes the attack surface of running an SUID binary of its size. What "points of failure" do you see here, exactly?

TL;DR: Install Fedora from a liveUSB, as recommended in all the official documents and guides. If you have a secure boot issue, it's likely because you installed from a VM. VMs run in BIOS mode by default, so the Fedora installer would install to your SSD without UEFI secure boot compatibility.

It seems like you may be overcomplicating things here. Why install to your SSD from a VM? Why not just make a liveUSB, boot into that, and then install to the SSD? That's the recommended install method, and is far less error prone. The UEFI error you linked is resolved in Fedora 40 (which releases on the 23rd), but I highly doubt that was your issue, it seems like quite the long shot. Additionally, you do not need a swap partition (swapfiles have been standard for a long time), and honestly I'd just recommend you stick to the default partitioning scheme if you aren't already comfortable in Linux. Less room for error that way.

If you believe secure boot to be an issue (like you seem to based on the issue you linked), then you should know that VMs all run in BIOS mode by default, not UEFI, so installing from a VM will not install with UEFI secure boot compatibility (hence why you should use the recommended method of booting from a liveUSB). This is why I don't believe the issue you linked is related, as if secure boot were the problem, than the issue is the fact that you're installing from a VM, since the VM will only know that it was booted in BIOS mode and do a BIOS mode install with no UEFI secure boot compatibility.

Tails is meant to boot from a USB drive, it is not meant to be installed on your system, so I'm not sure why you wanted to partition for it. I'm not even sure that it has an installer, because all the official documents and guides only talk about using a liveUSB (how it's intended to be used).

I'm a bit confused why you chose to go this route to installing Fedora, as I've never seen a guide or any official documentation recommend a setup like this. Any guide you find online should tell you to use a liveUSB for installation, and that's by far the easiest way. So I don't quite understand the complaint about how "difficult" Linux is to install for the average user when you aren't following any official way to install it. The "hoops" you jumped through all seem to be self-imposed. If you are actually experiencing a hardware-related issue, then the next step would be to try a different distro, but you need to try an official installation method before that, because that's most likely your issue. Again, if secure boot is the issue, then you will experience the same thing from any other distro if you try to install it from a VM. That simply won't work.

Fedora's official documentation has you go to this page to download the Fedora Media Writer for Windows (an alternative to Rufus/Ventoy that will automatically download the Fedora ISO for you). You run that .exe in Windows with a USB flash drive plugged in, and it's self-explanatory. Then you boot into the liveUSB you created (you may have to go into your BIOS and enable USB booting), and follow the installer steps. I suggest you wait until Fedora 40 releases on Tuesday, as it's less than a week away. If by some long shot that issue you linked was in any way related, it is fixed in Fedora 40. No need to rush things. Just follow the official installation instructions, don't go off on your own, and see if it works. If it doesn't, you have a hardware issue and you can try to install something like Debian to see if it has the same hardware issues.

While the other user explained what polkit is from a low level, I think it's more practical to give you a high level explanation. Polkit is responsible for the dialog box that pops up when you try to open an app like GParted that requires root permissions (it edits partitions, a rootful task). What the user you replied to is saying is that you never want to run an app as root unless it prompts you for it (like with polkit prompts), or you know in great detail what you are doing. Running random things as root can break your system and the app you're running. Most apps you will be using are not intended to be run as root under any circumstance, and at the very least will likely experience issues because of it (UI issues, data issues because the root home directory is not your home directory, configuration/setting changes, improper scaling, etc). Unless you know for a fact that something has to be run as root (like updating packages with your package manager) or you are specifically prompted when trying to do something, you absolutely do not want to be running things as root.

Just to further explain, even if an app isn't started as root, it can request that permission as needed. For instance, Nautilus allows you to navigate through the root directory, and will prompt you for a password through polkit if you are trying to access something your user does not have permission to read (of course assuming your user has sudo privileges, but that's beside the point). Unlike Windows, there is no practical use for a "run as root" option, because apps have the ability to request root access when it is necessary, and only when it is necessary. In addition to that, polkit limits the root access that an app is given to the specific actions for which it is requested (so an app can't use root privileges to run unauthorized commands). The exception to that is when you start dealing with the terminal, but that falls into the category of "you better know what you're doing and why".

The short answer as to why this isn't a thing in Linux is that the authentication and permission system functions nothing like Windows. In Linux, a "run as root" button is not a solution, it is a problem. The only reason that run as administrator exists in Windows is because sometimes the solution to a problem in Windows is to run an app as admin. That is not the case for Linux, and never will be.

There are many ideological differences between Windows and Linux. You'll find many discussions here about how it is often not a good idea to try to do something the "Windows way" on Linux, because those ideologies and the software principles are incompatible. Part of learning how wonderful Linux is involves unlearning all of the horrible habits and ideological differences that Microsoft forces onto Windows users. This is one of those things that has to be unlearned, because full root privilege is not something that a regular app should ever ask for or even want in Linux. Root privilege is provided on a case-by-case basis from polkit with GUI apps; only when needed.

Red Hat doesn't have influence over the development of Fedora, that's the job of FESCo. Red Hat owns the trademark and is one of the sponsors of the Fedora Project, but their interest is solely in enterprise applications (a task that is not suitable for Fedora), not in consumer desktop platforms. I've already discussed this at length here and here if you'd like more detail; there's no point in rewriting it.

This is a discussion about Docker, which is a complex terminal-based containerization system. This is not a program that is typically used by the average user. Docker's complexity does not imply that Linux requires this kind of set up to use as a normal desktop. This is usually server software. Docker is also available on Windows and MacOS, and is partnered with Microsoft (you know, the company that makes Windows? The desktop OS with the highest market share?). Are you going to complain about how Windows will never reach mass adoption because users are able to install complex tools that require a steep learning curve to use? You can install Docker on Windows and use the same commands and configs, so do you believe that Windows suffers this same problem?

Before you point out the start of that comment with the "Linux mentality" stuff, while some of that is certainly true, you can now do everything an average user needs to do in an intuitive GUI, just like Windows (better in many cases, actually). Half the listed commands (making directories and files) can be done in the file manager just like Windows, normal apps can be managed in app stores, and the rest of it is docker specific, which is (again), server-oriented software. I'm not a fan of their mentality about how things work in Linux, because it's very much an old mentality that doesn't account for the immense amount of change that has happened in the past decade to make Linux more accessible.

I don't understand why people come to the Linux communities to complain that Linux is "too hard" or "too complex" to be usable. If you don't have an actual interest in Linux, find another community. If you want a simple experience, use a simple distro that's meant to be easy to use, and use software that is easy to use.

You came into this with hostility, insulting the commenter instead of nicely asking how to do what they said you can do, and then you have the audacity to complain that they answered your question? Sorry, but it's very clear that you're the problem here. If you're going to complain that Linux users assume you know something when they answer, and then continue to complain when they provide clarification upon realizing they missed some information you needed to know after you complain to them about assuming you know what they're talking about, then the problem here is not the Linux users, and I'm not sure why you're in this community. This goes for every aspect of life, but you can always just politely ask for clarification like a normal person, instead of acting like a child throwing a tantrum. Most people will be conservative with their answers as to not insult you by assuming you don't know anything and bloating the comments with detailed instructions that could be unnecessary. Just ask for clarification.

If your view of Linux users is so negative, then why are you here? Why are you asking us for help? Why are you using Linux in the first place if you have such disdain for it? It makes no sense to me why you are being so hostile to people who are simply trying to help you.

Not the original commentor, but I wanted to share my experience.

I've been daily driving Linux for over a decade now, about 6 months of that was with Manjaro. I have never had a worse experience with a distro than I did with Manjaro, period. I tried it off a recommendation, and figured my initial issues were just flukes, but I couldn't keep coming back to a broken system, so I switched distros. I've used Ubuntu, Debian, Linux Mint, Manjaro, Void Linux, Gentoo, Kali Linux, EndeavorOS, base Arch, Alpine, and my current favorite is Fedora Workstation (though I'll switch to Kinoite/Fedora Atomic KDE when Fedora 40 releases). I have never had a distro break itself like I experienced with Manjaro, and it was consistently breaking. My experience is not unique; many users have the same issues, and that is constantly echoed in this community. I had 8 years of Linux experience under my belt entering Manjaro, so experience has nothing to do with it. Plus, the issues I experienced were never the result of my actions; Manjaro broke itself. Configs I have never touched in my life were broken.

My suggestion to anyone who wants a better user experience with Arch and doesn't want to set it up themselves is EndeavorOS. That's a distro that's capable of keeping its shit together. If you want to stick your head in the sand and deny the problems everyone else has with Manjaro, I can't change your mind, and it isn't worth my time to try. Just wanted to come in and clarify that it has nothing to do with experience. That's just Manjaro, and it isn't just an Arch thing, either. I spent about 2 years with Arch-based distros and never had the issues I did with Manjaro. It's been 3 or 4 years since I last tried it, but everything I've heard has indicated that no improvement has been made in the entire system being broken occasionally department.

If you're referring to ROCm, that's completely open source (AMD's CUDA competitor). I didn't notice anything proprietary mentioned in the linked article. Unless I'm missing something, in which case, please do let me know.