Para_lyzed

There's no useful information to glean from this image other than the fact that we finally found someone who uses light mode on Discord.

Just to clarity the relationship between Red Hat, IBM, and Fedora, Fedora is only sponsored by Red Hat. They make all their own decisions, and while they receive financial support from Red Hat and Red Hat owns the Fedora trademark, their decisions and development are independent of Red Hat (and by extension IBM), with the single exception that they cannot risk violating the law (i.e. copyright infringement), else it risks Red Hat legal trouble (and Fedora would risk losing their sponsorship as a result). Red Hat benefits from Fedora's development by the community, given that Fedora is RHEL's upstream, hence why it continues to sponsor Fedora. But it isn't Red Hat that is in charge of Fedora's development, it's FESCo, which is entirely community elected, and does not stand for the interests of Red Hat, but rather for the interests of the community.

Eliminating Fedora from contention in that regard is essentially like eliminating Debian because you don't like Canonical, who makes Ubuntu, a downstream of Debian.

Add on top of that the fact that IBM and Red Hat are major contributors to the Linux kernel, and you absolutely cannot avoid connections to them while using Linux. I mean, that's quite frankly a ridiculous exclusion criteria in the context of Linux. If you're looking to avoid an operating system OWNED by Red Hat or IBM, then Fedora should not be included in that list. Neither of them have any say or pull in the development of Fedora, which is a completely community-driven project (no, owning the trademark doesn't change that fact; if Red Hat tried to take over, the Fedora community would simply fork the project, rebrand, and continue on their own). Besides, Red Hat has no interest in controlling Fedora, because it doesn't benefit them. Their only interest is in enterprise applications, which is not a good use case for Fedora. The only operating systems Red Hat actually has any control over are RHEL, CentOS, and any derivatives of those operating systems like Rocky Linux, Oracle Linux, and such (though Red Hat's control over derivatives was only the result of those projects being downstream, not actual ownership).

So with that in mind, I'd recommend the Fedora KDE spin if you want a normal, stable, snap-free, no DIY required distro with KDE, or if you want the immutable version, Fedora Kinoite is what you'd be looking for. And Fedora has the major advantage over Debian-based distros of actually receiving package and kernel updates regularly, so you can stay up to date and enjoy new features, all while maintaining stability.

Fedora Kinoite is absolutely the best immutable distro fitting your criteria. Anything else will have a much smaller community and less support as a result. rpm-ostree has great documentation, and all of the Fedora Atomic Spins have a huge userbase available in case you ever have questions.

Your number is on a list of real numbers with real identities associated with them that was sold to them. Data brokers sell this information daily. They already know your number is real, but in order to comply with the law, they have to provide you with a legitimate option to opt out, so you will actually stop receiving correspondence from them if you ask them to stop (it is legally required). If not, they could be subject to a fine, but you'd obviously have to file a complaint with the relevant regulatory body for that.

If you do not attempt to opt out, they cannot be fined for spam if this is part of a legitimate donation campaign. If you don't reply, they will continue sending messages to you in the future. It costs them almost nothing to do, so even if they didn't know your number was real, they would do it anyway. Most of the people who donate from these messages don't reply through text message anyway. And if this were an actual scam, then there is nothing they gain from receiving a text back so long as you do not open their link. But again, in order for legal action to be taken (since these political reach outs are legal and not spam so long as there is an option to opt out), you must first try to opt out.

EDIT: Feel free to block the number after opting out. If they are legitimate (though the name is really fishy), then opting out will remove your number from all of their solicitors' lists, so you won't get texts or calls from different numbers working for the same campaign. Again, replying doesn't give them anything even if it is a scam, as your number was obtained from a real list sold to them by a data broker; they already know the number is in service. Just don't click the link in the text, and don't reply with anything other than stop.

SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of the owner user (almost always root). Note that this does not require that the user running them has root permissions, the UID is always changed. For instance, the ping command needs to set up network sockets, which requires root permissions, but is also often used by non-root users to check their network connections. Instead of having to sudo ping, any normal user is able to just run ping, as it uses SUID to run as the root user. sudo and doas also require functions that necessitate them running as root, and so if you can find out how to exploit these commands to run some arbitrary code without having to authenticate (since authentication happens after the binary has started running), there is a potential for vulnerabilities. Specifically, there is the privilege escalation, which is one of the most severe types of vulnerabilities.

run0 starts using systemd-run, which does not use SUID. Instead, it runs with the permissions of the current user, and then authenticates to the root user after the binary has already started to run. systemd-run contacts polkit for authentication, and if it succeeds, it creates a root PTY (pseudo-terminal/virtual terminal), and sends information between your session and the root PTY. So this means that in order to achieve privilege escalation with run0 as root, you have to actually authenticate first, removing the "before authentication" attack surface of sudo and doas.

TL;DR SUID binaries will always run as the owner (usually root), even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running anything with root permissions.

Well, since doas has a Linux implementation, stealing that name would cause lots of issues to users who already use it or want to use doas instead of run0. This will be a default part of systemd; not a new package. The reason it's called run0 is because it's just a symbolic link to systemd-run, and instead of executing as an SUID binary, like sudo or doas, it runs using the current user's UID.

Chromium-based browsers have inherently weaker extensions due to Manifest v3 and many other targeted attacks on adblockers. If you want a browser that works far better and provides a much higher level of privacy, use Mullvad Browser (worked on in collaboration with the Tor Browser, just without Tor integration) or LibreWolf. Both are Firefox forks with Firefox telemetry removed and anti-fingerprinting measures. You don't need and absolutely should not install any extensions beyond the default installed in those 2 browsers (except perhaps a password manager), as that will dramatically damage the fingerprinting protection they provide. Both will have a much higher level of protection than you could ever realistically expect from any Chromium-based Browser.

It seems you've chosen a DE that is not particularly well-suited to this task. Cinnamon is meant to be simplistic, and offer an easy transition from Windows with its Windows-like layout. It is purposefully less customizable than many other DEs. I second the recommendation of KDE Plasma, as this is actually available as a shortcut without any extensions, but if you wish to customize your DE deeply like this, KDE is incredibly customizable. You can do essentially anything you want in it and get it to look however you want.

Since you said that you're trying out Mint, now would be a good time to switch distro so you don't get attached to something that doesn't suit your needs. Switching desktop environments can cause lots of issues, so it's often best to just pick a distro with the DE you want. My personal recommendation is Fedora's KDE spin (though there are discussions of Fedora's default workstation switching to KDE in the future). If you're invested into Debian, then I don't really have any experience with Debian-based KDE distros, but I'm sure someone else could recommend you something. To be clear, the benefit of recommending Mint as a starter distro has gradually diminished as other distros have become more user-friendly. Fedora is a perfectly fine distro for someone new to desktop Linux (especially since you're already experienced on the command line); you'll just have to look up how to install Nvidia drivers if you have an Nvidia graphics card. AMD commits their driver to the Linux kernel, so no need to do anything if you have an AMD card. Try out some distros in a VM before you commit to anything though; it's much less commitment than installing so it's far easier to test distros out and see what best suits you.

Excluding Fedora because it's "too close to RH" doesn't make any sense at all. Fedora is not controlled by Red Hat, and Red Hat has no interest in a consumer desktop platform that they can't sell. Fedora's development is managed by FESCo, a community elected board that represents the interests of the community. They are kept intentionally separate from Red Hat's development, and don't tailor their development to Red Hat's wants or needs (in fact they often do the opposite, as Fedora pushes for change in the way things are done, not stability, as can be seen by the exclusion of X11 from Fedora 40, for example). That stands in direct contradiction with RHEL's goals. The features that are pushed by Red Hat developers would not be approved if they stood against the wants of the community, so anything Red Hat does contribute benefits the community as well. Red Hat's entire business is in enterprise solutions, as their business model relies on them selling support for their software. There is exactly $0 in potential revenue from Red Hat trying to take over Fedora, it just doesn't make sense. They can't sell anything, and since Red Hat doesn't employ all of the thousands of active contributors, such a takeover would simply result in a new fork. In fact, it would be against their interests, as Red Hat actively benefits from the developments of the community. Taking over control of the project would lose them all of the constant volunteer work put in by the community, which costs far less for them to sponsor than it would to employ a team a fraction of the size on salary. I've discussed this topic at length many times before, so I'll just link to a few comments that explain the situation in more detail (including how the project is funded, managed, and separated from Red Hat).

https://lemmy.world/comment/7490965

https://lemmy.world/comment/7494803

The best fit for your criteria is Fedora. If you want uBlue spins, you're still getting Fedora, just a more opinionated version. All of the major development of uBlue's images comes from Fedora though, as they don't maintain their own distro, they just repackage Fedora.

I'm also going to echo the sea of comments praising KDE support on Fedora. I just switched to Kinoite/Fedora Atomic KDE (for the Fedora 40 release) after using Fedora Workstation for about 5 years, and I've loved the experience. My only gripes have been from adjusting to an atomic distro, and have had nothing to do with KDE implementation. It seems that Fedora works very well with KDE, though I suppose I don't have a whole lot of experience with other distros using KDE.

If you want to use KDE with a standard desktop experience, just use the KDE spin (the standard mutable version). If you're interested in atomic distros (not trying to convert you, it's very much a personal preference), then they have the atomic KDE spin as well. I don't think you'll be missing anything by using KDE on Fedora, and unless you wanted to experiment with GNOME, there's no reason to really switch. Workstation and the KDE spin are both maintained at about the same level.

I generally have 2 recommendations for beginners who don't want something specific, one of which is a community favorite, the other is my own favorite.

The community generally recommends Linux Mint for new users. It's based an Ubuntu, so it had a lot of great support, but it has the enshittification of Ubuntu (snaps, tracking, pro subscription ads, etc.) removed. It's a great, simple distro for beginners that generally works all around without tweaking. It's basically the #1 recommendation for new users, and I gladly support that recommendation.

My personal favorite recommendation is Fedora, through I understand why there may be frustrations for those with Nvidia graphics cards who need to install their drivers. The process to do it on Fedora isn't very complex, and can be looked up easily, but new users tend to feel intimidated by the command line, and I must admit that the installation of Nvidia drivers and media codec are more difficult than something like Linux Mint (for Fedora, this is a copyright issue, since their main sponsor is Red Hat, a private company). In every other area, I'd say Fedora is great for beginners, and provides a great way for users to get new features quickly without having to worry about any of the instabilities or quirks of something like Arch.

You couldn't go wrong with either, but you're certainly going to see more recommendations for Linux Mint in general (especially on Nvidia hardware).

Just stay away from Manjaro, Gentoo, and Void (there's a long list of complex distros, but it really isn't going to help to list them all). Gentoo and Void have their place, but are not a great place for a beginner to start. Manjaro simply has no place, just avoid it like the plague.

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.

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?

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.

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.

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.

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.

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.

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).

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.

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.

You should really just use a browser, but I'll at least try to answer the question.

I've never tried any of them myself, as I'd just prefer using the website on desktop, but here's a list of mobile and desktop apps for Lemmy (just look at the right column to see which ones are desktop clients).

It looks like neonmodem is available in the AUR, though it's a CLI utility. If you're looking for a GUI, there's lemoa, but it's currently unmaintained, or lemonade which appears to be pretty minimal.

Your options are pretty sparse, so you're probably best off just using a browser if you're looking for a GUI. I hate to be one of those guys, but you don't need an app for everything; the browser can sometimes provide the best experience.

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.

To check if you deleted a boot partition, use a liveUSB with GParted to verify your partitioning. The Fedora default partitioning scheme should have a FAT32 EFI partition followed by an ext4 boot partition, then the data partition following those. In modern Fedora, that is a BTRFS partition with the subvolumes / and /home, but it is possible you chose to use a different filesystem, such as ext4, xfs, or such. If you are missing either of these boot-related partitions, follow the steps below to recover them.

If you deleted a boot partition, the easiest option is to use testdisk on a liveUSB to restore the partition. Here is a video tutorial for it (despite it being old, it should all still work exactly the same). Just don't follow the instructions for installing testdisk (it's for Ubuntu and very, very outdated) or deleting any partition (as the deletion is to demonstrate recovery). On Fedora, you can install testdisk with sudo dnf install testdisk, and I'll let you look it up yourself if you use another distro for it. If you are unsure of what partition table type you use (GPT or MBR), you can view that in GParted, but testdisk will likely be able to detect it automatically (as is stated in the video). It should be pretty straightforward and easy.

Another method you could choose would be to run testdisk on a liveUSB to find the boundaries of that deleted partition (here's an article from RedHat about that), and then restore the partition map with GParted. In all reality, it achieves the same result, but requires more work, so try the other method first. I'm only really including this for the sake of completeness in case testdisk for some reason doesn't want to restore the partition for you itself. Again, if you use the Fedora liveUSB image, you can install testdisk with sudo dnf install testdisk, but if you use anything else you can look that up yourself.

As described in the article, you can find the boundaries of the deleted partition, and then use those in GParted to create a new partition at the same start and end points and with the same filesystem type. With Fedora's default partitioning scheme, the first partition (EFI partition) is formatted as FAT32 and the second partition (boot partition) is formatted as ext4.

Unless you moved/resized partitions into the space created by your deleted partition, then this should just work with no problem.

Take this as a learning experience not to delete partitions randomly; you'll end up breaking things by doing that. Be absolutely sure that all of your GParted queue is doing what you want to the partitions you want before selecting apply, and never do anything to a partition if you don't know what it does. The only cases you should be deleting partitions are if you know what the partition is for, and no longer need it, or if you are deleting everything and reinstalling (which you can do by simply creating a new partition table instead of deleting partitions manually, or do through a GUI installer on a liveUSB).

Perhaps it's useful to provide some clarification here. As the other user stated, Linux is set up for multi-user setups and provides logical protection, but you seem to misunderstand how operating systems and file permissions work.

If someone steals your unencrypted hard drive and boots into their own operating system, they are able to circumvent all access control and permissions on your hard drive. This is because when they mount your hard drive your operating system isn't running; they're simply reading the stored data, so the access control and permissions set up by your operating system don't mean anything. This happens with ALL operating systems (Linux, BSD, Windows, MacOS, etc.). Logical protection like access control is only useful while the OS is running, and it cannot help otherwise.

This is why encryption is important, because it prevents unauthorized access when the OS isn't running. If you'd like to see just how easy it is to access unencrypted data, make a live USB and boot into it on any unencrypted computer (assuming you have permission to do so if you don't own the computer). You don't even need to extract the hard drive in most cases to read file contents, you can simply boot into a live USB. The only situation where this isn't the case is when USB booting is disabled in the BIOS and the BIOS is password protected, but you could always just remove the CMOS battery to clear the settings to bypass the BIOS password anyway.

Unencrypted data will always be trivial to retrieve when the attacker is allowed physical access to your computer.

/etc/fstab is a file that controls auto mount points at boot. You can read about it with the command man fstab, or search up how to add something to it in a search engine. There are plenty of resources to help you online with creating a mount in the fstab.

Political organizations and non-profits are exempt from this list.

Actually, this particular issue is a bug in the Linux kernel that has been patched in version 6.9. The display manager isn't going to change anything other than (maybe) the issues their wife had on Bazzite. In fact, OP stated in their post that they are running an AMD GPU (5700XT). You can always install the X11 package as an overlay and switch to it if you want with Fedora Atomic or Bazzite. It's still in the repos, it just isn't the default anymore. There's no need for an image with X11 in it by default, especially with explicit sync support coming soon that will fix many of the remaining issues with Nvidia on Wayland.

Yes, this is patched in 6.9. Since it's a new major release, it'll take a few weeks before we see it in Fedora while they check for major regressions and stability. Stable updates (like 6.8.8 to 6.8.9) are much quicker, usually taking only a few days, but major releases add much more to the kernel and need to be properly tested for regression. If you wanted to use Bazzite, you'd have to compile the 6.9 kernel yourself and overlay it, though I'm not sure the steps you'd need to take exactly given that I've never tried compiling the kernel for an atomic distro before. Perhaps you can find something online about it, but I didn't find an easy guide when I searched it (just non-atomic kernel compilation). I did find documentation on how to change the kernel in an rpm-ostree based system, but you'll still have to compile it yourself and then override the rpm you compile with that method. Instructions on compiling a kernel for Fedora can be taken from here for reference.

I'm going to hack together some stuff from both sources with what I think will work in Bazzite using rpm-ostree (and a toolbox so you don't have to overlay a bunch of packages as build dependencies). This is untested, as I really don't want to have to compile a kernel myself; my computer isn't nearly fast enough for that to be reasonable right now. If anyone tries this, please let me know if this works or not. Luckily, based on the custom kernel documentation, it seems this process is quite easy with Fedora's kernel dist-git. No manual configuration should be required, just a few commands (Secure Boot complicates things dramatically, but the Fedora documentation already has the instructions for getting this to work with Secure Boot, so that should hopefully just work).

None of the commands I provide are irreversible, and can be reverted easily. Since we are working with an atomic distro, you can always rollback to a previous version if you encounter issues. Reverting to the default kernel is as simple as removing the override we create for the compiled one.

WARNING: This will use Fedora 41's kernel configuration. It may differ from both Fedora 40 and Bazzite's kernel configuration. Understand that there is a small chance this will cause problems, in which case you can rollback to the previous version or remove the override at any time to uninstall and revert back to the base kernel.

Open up a terminal, and enter the default toolbox (if you do not have a default toolbox yet, you can create one with toolbox create)

toolbox enter

From the Fedora custom kernel documentation

Install dependencies inside toolbox

sudo dnf install fedpkg
fedpkg clone -a kernel
cd kernel
sudo dnf builddep kernel.spec

Checkout from the Fedora kernel dist-git

git clone https://src.fedoraproject.org/rpms/kernel.git

Switch to Fedora 41 branch (since it has 6.9 already)

git switch f41

Do you use Secure Boot? Because if you do, then it gets WAY more complicated and I don't know for a fact that this will work properly. Only do the stuff in the Secure Boot section if you use Secure Boot!

---------------SECURE BOOT CONFIG---------------

NOTE: Update values enclosed in <> to appropriate values (for example, changing to `mranachi` or to MOK-temp-6-9-kernel)

Add your user to /etc/pesign/users if it does not already exist.

nano /etc/pesign/users

Run authorize user script

sudo /usr/libexec/pesign/pesign-authorize

Create a new Machine Owner Key

openssl req -new -x509 -newkey rsa:2048 -keyout "key.pem" \
        -outform DER -out "cert.der" -nodes -days 36500 \
        -subj "/CN=/"

Import MOK into your UEFI key database

mokutil --import "cert.der"

Create a PKCS #12 key file

openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der

Import the certificate and key into the nss database

certutil -A -i cert.der -n "" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
pk12util -i key.p12 -d /etc/pki/pesign

Add line %define pe_signing_cert to the kernel.spec file (I am assuming it is in the current directory based on the wording of the Fedora documentation, though I have not seen any of these files. It may be located elsewhere, but I have no idea where if that is the case)

nano kernel.spec

---------------SECURE BOOT CONFIG---------------

Build RPMs using the default Fedora 41 configs (this could take a very long time on slow hardware, but assuming you have a good CPU, it could actually take as little as 4 minutes)

fedpkg local

Exit the toolbox so we can install the RPM

exit

From the rpm-ostree kernel change documentation

Install the new kernel. I don't know what the name of the RPM will actually be, so you may want to ls x86_64 and modify this command to match the appropriate RPM(s). Also, I can't remember if exiting the toolbox keeps you in the same folder, so you may need to navigate back to the correct folder with cd kernel after exiting.

rpm-ostree override replace ./x86_64/kernel-*6.9*.rpm

Clean up

cd ../
rm -r kernel/

You may also optionally want to remove the build dependencies inside the toolbox if you want to save space.

Reboot, and in theory, you should be done (if you did the Secure Boot steps, you'll have to accept the key when you reboot). I'd like to remind you that you can rollback any changes if you encounter any issues, as that is one of the many benefits of atomic distros.

Uninstalling compiled kernel

To revert the override (once 6.9 releases to Fedora 40 repos), simply do the following (this effectively uninstalls the compiled kernel and reverts back to whatever is in the base image):

rpm-ostree override remove kernel-*6.9*.rpm

I don't have much to comment on native installs that hasn't already been said, but if you go with a VM, please don't use VirtualBox. It's a pile of hot garbage that pales in comparison to the already existing, kernel-level virtualization offered by KVM/QEMU. Use a package like virt-manager for KVM/QEMU based VMs and your experience and performance will be infinitely better. The Linux kernel has KVM built in for a reason, so take advantage of that.

Otherwise, Distrobox is a great recommendation, as are many of the other install methods listed in these comments.

Seconding partclone here, it's the easiest solution for imaging that only backs up the data on the partition that is used. Plus, it's in RescueZilla, which is pretty intuitive and user friendly for those that prefer GUIs

Actually, this particular issue is a bug in the Linux kernel that has been patched in version 6.9. The display manager isn't going to change anything other than (maybe) the issues their wife had on Bazzite. In fact, OP stated in their post that they are running an AMD GPU (5700XT). Fedora 40 (and Bazzite by extension) ships without X11 installed now. You can always install the X11 package as an overlay and switch to it if you want with Fedora Atomic or Bazzite. It's still in the repos, it just isn't the default anymore. So realistically, the solution here is to wait for the 6.9 release to be added to the Fedora 40 repos, or for a 6.8 version which has the fix backported (which will be much sooner, probably a few days after the backport is merged, though I don't know if that has already happened yet or when it will if not). The reason Mint works is because it uses a much older kernel version, so this bug is not present. The bug was first introduced in 6.6.30.

Fedora has pretty good SELinux configured out of the box, and isn't focused on opsec. It's just sane defaults and proper limitations to access. It also switched to Walyand-by-default this release, completely removing X11 from the default packages, which mitigates many of the "app spying on other app" scenarios that a previous user in the thread was talking about. That's not to say that Fedora is the pinnacle of Linux security or anything, but it comes with pretty good defaults for the average user. You'd have to get into kernel hardening and deep into SELinux to do better as an end user, which is not something that most users are inclined to spend time or energy on.

Just to clarify, I'm not trying to stand up for Red Hat in any of the following, just explaining the relationship between Red Hat, CentOS, and Fedora. My stance on Red Hat has historically been neutral, but recently is erring towards negative after the IBM aquisition. My stance on Fedora has always been positive.

Probably because of what happened to CentOS.

Red Hat bought out CentOS in 2014. They took over their trademark, hired their development team, and placed Red Hat developers on the CentOS team. CentOS was downstream of RHEL, so Red Hat had an invested interest in it, since it actually resembles RHEL.

That's an important distinction: CentOS was downstream of RHEL, and could be used to replace it in enterprise applications. Fedora is upstream of RHEL, and not suitable for enterprise applications (too many package and kernel updates, everything changes frequently, short term release lifetime, etc.). When CentOS was discontinued in favor of CentOS Stream, it no longer had the same value in enterprise use as RHEL, and its competition to RHEL was mostly eliminated. Again, the most important distinction there is that CentOS competed with RHEL, which is why Red Hat took it over and killed it.

Fedora is entirely community managed and developed, with FESCo being community-elected and making decisions in the interest of the community, not in the interest of Red Hat. Red Hat sponsors Fedora, but that relationship is merely financial. It provides money to the Fedora Project because RHEL is downstream of Fedora, and benefits from its continual development. Fedora does not compete with RHEL, so Red Hat has no interest in controlling Fedora, nor could they if they wanted to with the way the project is managed.

Who owns the Fedora trademark?

Red Hat, of course. But again, Red Hat does not have the means to control the development of Fedora, and they would get nothing but backlash from trying, and gain nothing from it. If Red Hat tried to take over Fedora and were somehow successful, the project could easily be forked and rebranded, with the community currently managing it taking over the new fork and developing from there. Fedora would become stale, and Red Hat would have to manage it entirely, which they clearly don't want to do in the first place. The only significant difference would be that the new Fedora fork would not be sponsored by Red Hat, and development would slow down as a result. But again, this has nothing but disadvantages for Red Hat. Red Hat benefits from the Fedora Project's active development, and since it doesn't compete in their market, they get nothing from destroying it.

How independent is Fedora really?

That depends on what aspect of independence you question. Red Hat has no control over the development of Fedora, as that is managed by FESCo. So in that way, Fedora is completely independent. FESCo and the Fedora Project don't develop for the sole interests of Red Hat; they develop for the community. Of course, Red Hat still benefits from that development regardless, but RHEL specific development is handled by Red Hat, not the Fedora Project, and changes to Fedora from Red Hat developers that would stains against the interests of the community would not be approved. The members of FESCo were elected because the community trusts them to make decisions the benefit everyone.

Financially, the Fedora Project is quite dependent on Red Hat. That's where the vast majority of their funding comes from. That funding is given to the Fedora Project because its development is mutually beneficial for both the Fedora community and Red Hat. That fact won't change anytime soon. The testing, bug fixes, security patches, and feature upgrades from the Fedora community are incredibly valuable for Red Hat, and without a consumer desktop platform to test those changes, Red Hat would be greatly disadvantaged.

I am not saying anyone should avoid Fedora, I can just understand why someone would.

Personally, I can't. At least I certainly can't understand if their reasoning had anything to do with Red Hat or IBM. The Fedora Project is independently developed, and does not seek to satisfy the interests of either of those companies. I can understand someone not liking how frequently the kernel is updated, but then again, you don't have to update immediately if you don't want to. I can understand someone being apprehensive because there is some software available on Ubuntu or Debian, but it isn't released for Fedora. I can understand someone not liking the dnf package manager; it is quite slow. I can understand someone not liking the folder structure of Fedora over Debian based operating systems. But I cannot understand someone disliking Fedora because they hate Red Hat or IBM. As fas as the end user is concerned, Fedora might as well have nothing to do with Red Hat or IBM. Yes, RHEL is downstream of Fedora, but that doesn't affect Fedora in any way, it's downstream, not upstream. Fedora is, always has been, and always will be a community driven project that primarily has the interests of the community in mind. The Fedora Project doesn't care about what Red Hat wants or does with RHEL, as it doesn't affect Fedora in the slightest. CentOS was destroyed because it competed with RHEL (or at least Red Hat believed that it did), and Fedora does not. If you don't like Red Hat then don't use RHEL, CentOS, or any of their downstreams, but don't falsely associate the development of Fedora as being at risk of damage by Red Hat.

Anyone who avoids Fedora because they dislike Red Hat or believe it is at risk from Red Hat is misinformed at best.

Going through the GitHub page for the bot, it seems that this is intended behavior by the dev. In their own words:

I think it still serves its purpose of people not having to leave the community to see what the article is about.

I agree with this, personally, as I don't like having to follow links to read articles. It's nice having a comment with a TL;DR, or for very short articles having the whole article in the comments. Plus, it's not like one (relatively short) comment really adds bloat to the comments section, it's something that can be easily scrolled past.

shady VPN company

First off, everything Mullvad deploys is open source, from their clients to their servers. They have been audited and checked by 3rd parties to ensure their servers are running the source code they released. They are not some "shady VPN company" like Nord. They have a continual commitment to transparency that has been tested and true for many years.

Second, MullvadVPN has very little to do with the development of the Mullvad browser. It's just a fork of Tor Browser maintained by the Tor Project as a collaborative effort towards a uniform browser with the benefits of Tor Browser, but to be used without the Tor network. It is funded by Mullvad, but maintained mostly by the Tor Project. Do you not trust the Tor Project? The non-profit that has been open source and audited constantly throughout its lifespan? Here's the source code on the Tor Project's repo: https://gitlab.torproject.org/tpo/applications/mullvad-browser

The only Mullvad affiliation is the Mullvad extension that comes preinstalled (which you can uninstall, of course), the name, and the logo. That's about it. No need to use their VPN, no need to buy anything from Mullvad, it's basically just the Tor Browser without Tor.

You could also run the command automatically every time your screen is unlocked depending on your DE. For instance, if you use GNOME, this will likely work

EDIT: see comment below for better solution

The name "atomic" in the context of operating systems refers to an operation in which all steps are applied without interruption (for instance, atomic operations like locking a file cannot be stopped by system interrupts, and once started are ran to completion regardless of the scheduler). Atomic operating systems take that concept, and apply it to base operating system updates. All changes to the operating system are applied simultaneously without interruption. The methods that different operating systems use for this vary, but since we're talking about Fedora, I'll explain Fedora's image based atomic model using rpm-ostree.

Fedora Atomic is based on an image of the root filesystem that is perfectly consistent across all installs. When you update your system (with rpm-ostree), you fetch the entire root image from the repo instead of fetching individual packages. Updating works similarly to version control software like Git, where each version has a list of changes from the previous one, branches, and a variety of other similar features like rebasing. The operating system essentially runs similarly to a Git repository. rpm-ostree pulls the latest image from the image repository, and creates a new local branch on your system with all the changes in it. The root filesystem covered by the image is immutable (which means it is read-only and cannot be changed), to ensure that the root image is always perfectly consistent with the image from the repo (everything is perfectly reproducible). In order to switch to the new branch, you must reboot into it. This ensures that nothing changes while updating, and since the whole root filesystem is immutable, it's best for stability to load into the new branch through a reboot (to ensure all behavior is consistent). Technically, you can apply changes live, but it is not recommended to do that and requires you to use an additional flag with the rpm-ostree command. This ensures that, in practice, your system is never in a state "between" updates. Once an update starts, it will finish to completion (or it will fail and the update won't be applied), making updating an atomic operation (an update runs to completion, or it essentially doesn't run at all; nothing in between). This is a great safeguard against crashes or power losses during updates.

The benefit of atomic distros is that all installations have a perfectly consistent root filesystem, so the system can be tested by the developers in the exact configuration in which it will be deployed to the end user. Any packages you want to install on top of the root filesystem can be installed in a few ways. Most GUI apps should be installed as Flatpaks where possible (installed to the home folder, which is read-write, so you can do it without rebooting), terminal apps can be installed in a toolbox (a default containerization system installed in Fedora that allows you to emulate a read-write root filesystem by mounting extra folders inside the container), or you can overlay the packages on top of the root filesystem through rpm-ostree. Toolbox has dnf installed in it, so you can install packages inside a container as you would install them in non-atomic Fedora. Package overlays download the packages from the Fedora repos, and mount them read only on top of the root filesystem (hence the "overlay", as the packages are independently mounted over top the root filesystem). Overlays have the highest chance to change the behavior of your system, so they are generally recommended as the last option, since they decrease the benefit of consistent install behaviors, meaning that your extra packages aren't tested as thoroughly as the root filesystem. In practice, overlays don't generally cause any more "instability" than installing a package on a non-atomic distro, but again, it slightly diminishes one of the main benefits of atomic distros.

Essentially, all updates are applied at reboot, which means that you can just have updates running in the background and keep doing whatever you want, and as soon as you reboot, changes are instantly applied (no "installing" to wait for). Your operating system will keep some amount of previous branches (usually the current branch and 2 or 3 most recent branches) so you can boot into a previous branch from GRUB if an update breaks anything without having to restore from a backup. You can then rebase rollback to the previous branch (make the image of the branch you selected your current root image) once you can be sure that everything works properly. You can also rebase into another image entirely at any time (from Fedora Atomic GNOME to Fedora Atomic KDE, or into Bazzite or Aurora for example). The root image will change, but all of your overlays and persistent data will stay. EDIT: Note that rebasing into an image with a different DE might cause config issues, as /etc is mutable, and would be essentially the same as installing a new DE on a non-atomic distro. Some recommend against doing it, whereas some have success at it. YMMV. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example.

Atomic operating systems are emerging as a great option for desktops, as they increase stability, reliability, and recoverability greatly over the traditional model.

Yes, basically. uBlue doesn't maintain distros, really, it just repackages Fedora Atomic with some minor changes (including non-free drivers, for instance). That way if you need the software they repackaged into the image (like Nvidia drivers), you don't have to use overlays, and instead can use uBlue images. In fact, you can actually rebase Fedora Atomic to uBlue and vice versa with a single command. All it does is change where the base images are fetched from, and it's a potentially easy way to switch between images without having to perform a reinstall (do note that different packages in the base may modify config files that will persist between rebases, though). I haven't personally tried it, so I don't know if there's a likelihood to run into issues, but it's an interesting option nonetheless.

GNOME is basically nothing like Windows, in fact KDE Plasma is much closer. Cinnamon isn't in OP's list of DEs, though it should be available as a pre-installed option for Debian based on what I see in their live ISO list. At that point, it would probably be better to go with Linux Mint though, given the target user. I assume OP would have their reasons for choosing Debian over Mint if they wanted to use Cinnamon, though.