Para_lyzed

@[email protected]

This profile is from a federated server and may be incomplete. View on remote instance

Para_lyzed ,

Idk, I think Gentoo and Void would be worse for a new user. But yeah, most other distros will be more new user friendly. Bazzite has a great new user experience, for instance

Para_lyzed ,

Fedora is what I'd describe as cutting edge, but not bleeding edge. It's still behind from source, and is semi-rolling release, so it's further behind than Arch but way ahead of stable/fixed release distros like Debian

Para_lyzed ,

Then it may be a Ventoy thing, or even just a bad flash drive

Para_lyzed ,

Did you check the MD5sum? If you did (and it actually matches), try using a different media creator. You can use something like Rufus or Fedora Media Writer (yes, you can install non-Fedora ISOs with it, the only extra feature it has is that it will automatically download Fedora ISOs you want). If other media creation tools don't work, try a different flash drive, as that's the next most likely issue.

Para_lyzed , (edited )

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.

Para_lyzed , (edited )

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.

Para_lyzed , (edited )

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?

Para_lyzed , (edited )

Since you're using Fedora Atomic, I'll give you instructions for rpm-ostree:

Run rpm-ostree status and find the deployment with the dot to the left of it. Example output:

State: idle
Deployments:
● fedora:fedora/40/x86_64/kinoite
                  Version: 40.20240509.0 (2024-05-09T00:47:51Z)
               BaseCommit: 2f8263a33190c4e1320233aebbdc8f337b0a6abcba371d4870ae43fba33aea62
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
          LayeredPackages: akmod-nvidia akmods asusctl asusctl-rog-gui libratbag-ratbagd mullvad-vpn rpmdevtools
                           supergfxctl virt-manager xorg-x11-drv-nvidia
            LocalPackages: rpmfusion-free-release-40-1.noarch rpmfusion-nonfree-release-40-1.noarch

  fedora:fedora/40/x86_64/kinoite
                  Version: 40.20240507.0 (2024-05-07T00:44:22Z)
               BaseCommit: c7fb680111ecf1736e473cf6f9169f69e5f2ec6b50814f7017bd6f9f3c1bdaf2
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
          LayeredPackages: akmod-nvidia akmods asusctl asusctl-rog-gui libratbag-ratbagd mullvad-vpn rpmdevtools
                           supergfxctl virt-manager xorg-x11-drv-nvidia
            LocalPackages: rpmfusion-free-release-40-1.noarch rpmfusion-nonfree-release-40-1.noarch

First one has a dot next to it, which means it's the active version. Copy the value after "BaseCommit:" (in my case it is 2f8263a33190c4e1320233aebbdc8f337b0a6abcba371d4870ae43fba33aea62)

Run rpm-ostree db list <paste commit hash here> | grep amd. Example output (my command was rpm-ostree db list 2f8263a33190c4e1320233aebbdc8f337b0a6abcba371d4870ae43fba33aea62 | grep amd):

amd-gpu-firmware-20240410-1.fc40.noarch
amd-ucode-firmware-20240410-1.fc40.noarch

In my case, running the most recent update on Fedora Atomic KDE, it looks like I'm running version 20240410-1 of amd-gpu-firmware. Yours may vary depending on what update you're on.

Para_lyzed ,

Since they're running Fedora Atomic, the commands are through rpm-ostree, as dnf is disabled. I've provided the relevant instructions.

Para_lyzed , (edited )

From a quick search, it seems they're talking about the official OpenSUSE Matrix space.

I don't know anything about Linux and the idea of installing it frightens me. Where do I start?

I bought a laptop yesterday, it came pre-installed with Windows 11. I hate win 11 so I switched it down to Windows 10, but then started considering using Linux for total control over the laptop, but here's the thing: I keep seeing memes about how complicated or fucky wucky Linux is to install and run. I love the idea of open...

Para_lyzed ,

Strange that the download limit was so slow, I've never had that happen. You can download ISOs from a browser to use in the utility, however, and Fedora has done a good job of simplifying it down to a fairly identical user experience as Etcher

Para_lyzed , (edited )

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.

Para_lyzed ,

If you want easy Arch, recommend EndeavourOS. Manjaro is a pile of steaming garbage just waiting to break itself. EndeavourOS is easy for beginners, doesn't break itself constantly, and gets all the features of Arch from mainline Arch, not the Manjaro repos. I strongly suggest you revise your recommendation to EndeavourOS; there's very good reason behind why this community dislikes Manjaro.

Para_lyzed ,

I used Manjaro for about 6 months, never used AUR or made any real modifications to my install (except for troubleshooting), and had to fully reinstall 2 times and fix config issues on files I've never touched a handful of times in that 6 months because a standard update broke everything. I then went on to use EndeavourOS for a year and never had a single issue the entire time I used it, so my problems were not related to Arch, it was Manjaro. Similar stories are constantly echoed about Manjaro, and I have a hard time believing that the entire Internet is astroturfing a Linux distro for no reason. I, as a quite experienced Linux user of over a decade, have never tried any distro that has been anywhere close to as bad as Manjaro. I've had an install brick itself once outside of Manjaro, and that was due to an obscure hardware bug that got through QA. I've never had to spend as much time fixing a distro as I did with Manjaro, and it was on a laptop that I only used for browsing and schoolwork. I didn't even bother to change the wallpaper because I only had it there to try out. So no, nothing that happened was related to the packages I installed, the (nonexistent) changes made to configs, or the use of the AUR. That was a perfectly normal Manjaro install breaking itself for absolutely no reason. You can feel free not to trust my anecdotal evidence, but almost everyone I've seen in this community who has said they've used Manjaro has echoed similar stories. This isn't a unique or rare experience.

EndeavourOS has great value to users new to Arch that don't want to set everything up from scratch. It is basically vanilla Arch without the setup hassle of vanilla Arch. I don't see why that wouldn't have value, and I don't really understand why you'd recommend Manjaro over it. The 2 week freeze that Manjaro does on packages doesn't actually help stability. It does nothing at best, and makes things worse in most other cases.

Help me choose a distro/stay on NixOS

Disclaimer: I know there's a lot of questions and posts like this but generally they're aimed at noobs. I consider myself an intermediate user, and I know generally distros don't matter much and you can have anything another distro has on any distro but I'm looking for something a little "specific" that better suits my need from...

Para_lyzed , (edited )

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.

Para_lyzed ,

There's a question that I feel I don't adequately answer in my previous comments, but I feel as if I should address.

Does Red Hat implement their own features in Fedora, and what does that mean for the community?

The short answer is yes, there are Red Hat developers who do work on Fedora. Just as Canonical developers contribute to Debian, Red Hat contributes to Fedora. There is a very important distinction between the development of Fedora and RHEL though, and it's the same reason no one is up in arms about Canonical contributing to Debian. The changes that Red Hat makes to Fedora still have to be approved by FESCo, so they still have to represent the interests of the community. Red Hat can feel free to pay as much as they like into the development of features, but if those features would contradict the values of the Fedora Project or go against the wishes of the community, they wouldn't be approved in the first place. Red Hat sees Fedora as a very valuable resource that they can use to test features before they arrive in RHEL. Unlike Canonical, however, they don't push proprietary solutions, tracking, or pro subscriptions into a consumer desktop platform. Those changes would not be representative of the wants of the community, and would not be approved by FESCo (hence the benefit of a community elected board).

There's a related follow-up, as well:

Are there Red Hat developers in FESCo? What does that mean for Fedora?

Yes, there are a few Red Hat developers in FESCo, you can view their bios on the Fedora Project website. They were not placed there by Red Hat, however. These are still people that were elected by the community, who would not be there unless users (and other developers) trusted them to make decisions in the interest of the community. You can nominate and vote in the elections as part of the community if you wish.

The biggest factor that I often see glossed over (and perhaps the most important reason Fedora has independence) is that Red Hat doesn't have any reason to even attempt to corrupt it. Fedora users are not an audience they stand to make money from, and if Red Hat believed there was money to be had in the consumer desktop platform, they would already be selling a product. There is mutual benefit between Red Hat and the Fedora Project, and that gets passed onto the community. Red Hat benefits from the contributions of the community, while simultaneously being able to test new features in an audience that they aren't interested in selling to, and the Fedora Project gets money and active development back from Red Hat as a result.

Now I'd also like to clarify, because I could understand confusion as to what I meant when I said Red Hat doesn't control the Fedora Project. Red Hat is allowed to make contributions to Fedora, so long as they meet the same approval criteria as any other merge request from any other person/entity. Red Hat, however, is not able to control how money is spent, or where the priorities of community developers are focused (the direction of the project). So they are free to make contributions to Fedora that benefit everyone (so long as their changes are approved), but not free to test RHEL specific features that don't have a place in Fedora, for example. In fact, since Red Hat wants to keep their source code away from anyone that doesn't pay them a subscription, they actually have a vested interest in keeping those RHEL specific features separate from Fedora, as to not make them easily accessible to potential competitors. This is how they're addressing the competition posed by Rocky/Alma/Oracle Linux.

Para_lyzed ,

The only reason that the Fedora Project exists is for community development. There is simply nothing Red Hat could ever stand to gain from changing that model, as they'd lose the entirety of what they are paying for by sponsoring the project. In order to do anything, they'd first need to dissolve FESCo, which would make HUGE waves across the internet. You and anyone else in the community would see news and posts about it immediately. Once that happens, the project dies. Community members are not going to contribute to a project that betrays their trust, after all. So in trying to change anything, the only thing Red Hat would be doing is moving a project that they are paying a relatively small amount of money for (relative to the number of contributors) from community developed to Red Hat developed. That means that they have to personally invest money into maintaining and employing contributors themselves, completely defeating the point of Fedora existing in the first place. If they wanted to privately fund development, why wouldn't they instead do it in RHEL, or CentOS Stream?

Let's analyze Red Hat's current gains from Fedora one by one:

  1. Fedora is a place for Red Hat to test new features before they move to RHEL.

This requires an active userbase, and by privatizing or taking over the project, that userbase would rapidly diminish. Red Hat cannot increase this benefit by any means, other than by leaving the project be as is.

  1. Fedora is community developed, so Red Hat can benefit from commits made by the community (people they don't pay).

Privatizing or taking over the Fedora Project would immediately end that community development. There's nothing in this respect that Red Hat could possibly intend to gain from such an action.

  1. Red Hat's image appears better by sponsoring a community developed project.

It should go without saying that their image would only be damaged if they tried to modify their current relationship.

These are the things that Red Hat is paying for by sponsoring the Fedora Project. A hostile takeover would have exactly zero potential gain and very high potential losses in each of these categories; thus it doesn't make sense in the slightest.

Now let's analyze some new potential gains that Red Hat could get by a hostile takeover:

  1. Monetizing Fedora.

This is Linux we're talking about, attempting to sell a consumer Linux distro for money will not fly, and no one will buy it. After all, even when enterprises by RHEL licenses, they aren't paying for the software itself. What they're really paying for is the support package and direct hotline to Red Hat for any technical difficulties. Red Hat makes its money by offering support services, something that does not have any realistic market for the general populace, especially considering the userbase we're talking about are Linux users.

  1. That's really it.

There's just nothing else Red Hat would even stand to gain from any hostile takeover. The only potential motive is money, and Fedora is not a product that will ever generate them revenue. Consumers don't want to purchase licenses, and enterprises don't want consumer desktop distros with 6 month release cycles.

Red Hat funds Fedora because it is of great benefit to them to keep it alive, and continue its development by the community. Changing their relationship with the Fedora Project would not only lose the exact benefits they are receiving, but also cost them money, as they will no longer have thousands of community members volunteering their work, and they would have to hire contributors to fill that gap. Additionally, why even bother speculating? It isn't difficult to move distros nowadays, so if anything ever were to change, you can jump ship on any day of the week to another distro. We seem to live in a world where logic is challenged by a thousand "but what if?" statements that have no basis in reality. It's quite a pointless endeavor, honestly. What if the distro you choose gets bought out by Google, or Microsoft? What if the distro you choose is secretly funding antisemitism with donation money? What if the distro you choose suddenly dies? These are all absurd questions to speculate on, all to no real end. They each have the very simple solution of "just install a different distro if that happens". But what if a company tries to exploit a distro for money? There's no point in even speculating that because there isn't even any money to be made from consumer desktop distros. The money to be made from Linux is not in the consumer desktop platform, it is in the realm of businesses (enterprise software, embedded systems). There are far too many free options out there owned by nonprofits to ever consider marketing a consumer Linux distro like that. Even with stuff like Ubuntu Pro, you aren't paying for a license to the distro; you're paying for extra support.

Why are we treating Red Hat like the most evil company in the world, anyway? As far as tech companies go, they're pretty damn ethically sound. They're not nearly as bad as Google, Microsoft, Amazon, Apple, IBM, or any number of other tech companies that release proprietary software with no access to source code, massively violate their users privacy, exploit consumers in harmful ad campaigns, etc. Google, one of the most unethical companies in the world owns Android, but we still have AOSP, which is the foundation for custom ROMs like GrapheneOS and LineageOS. If they believed that trying to shut down AOSP would make them money, they would have tried it years ago. Of course, doing so wouldn't even be legal, as it would be violating GPL.

I'm just not seeing what exactly you're imagining Red Hat could take away from Fedora for their own gain. Nothing they could do that would have a negative effect on users would result in a gain for Red Hat, as they'd be losing everything they gain from the Fedora Project. In order to make any changes to the development of Fedora, they either have to pay developers to make those changes, or convince community members to do it for them (which is not going to happen if these changes are negative), and that's assuming that they manage to dissolve FESCo to get these malicious changes approved.

You don't want to rely on a project that's funded by corporations? Where do you think the funding for the Linux Foundation comes from? Companies like Google, Microsoft, Amazon, and IBM fund the Linux Foundation, so any OS that uses the Linux kernel will be financially dependent on corporations. That's something you're never going to be able to avoid.

I don't understand why this has been blown so far out of proportion. What's the point in excluding a very good distro that suits your needs perfectly over a fear that some day, somehow, in the indeterminate future, that there would be some new financial incentive created out of thin air that would cause Red Hat to try to take over Fedora? What guarantees that same situation or one similar wouldn't happen to any other distro you could choose? And to that end, why would Red Hat take over Fedora instead of creating a new fork that they could sell so they can still get all those benefits of community development? I don't see how any financial incentive created by Fedora wouldn't be possible to gain downstream.

Para_lyzed , (edited )

This makes the false assumption that a CEO would make every decision in the company, but I'll humor this anyway. If this were to happen, Fedora would lose Red Hat's sponsorship. There have been a number of community discussions detailing the friction that contributors have already had with Red Hat, some even left after they privatized the RHEL source code. Some are looking for any reason to stop because they dislike Red Hat. This simply would not fly, and you'd see contributors leaving en masse. Similar discussions have been echoed by contributors before, and I don't expect volunteers to stay around and work for a project that they couldn't trust to uphold the interest of the community anymore. Both Fedora and Red Hat would be immensely damaged, and Red Hat would have to spend far beyond the amount that they spend sponsoring Fedora to hire new contributors so that RHEL can be maintained, as Red Hat does not have the resources to maintain RHEL without the Fedora community. This would be career suicide for the CEO, and given how much Red Hat relies on Fedora, the threat would be empty in any case. It does not benefit Red Hat to destroy the project fueling their enterprise distro. RHEL already modifies Fedora substantially, as it does not share the same design principles, and Fedora does not actually reflect the direction of RHEL. Even if this were to happen, the answer to all of the "but what if?" questions is the same: you can switch distros. Things like this make waves in this community; it wouldn't go unnoticed, especially given how popular Fedora is. It's the same situation with any distro. "But what if they run out of money and development suddenly slows to an unreasonable pace?" Switch distros. Speculating about situations like this is not constructive. You can speculate unlikely situations for any distro you choose, and be caught in an endless loop of irrational "but what if?" questions. The answer, as with all things Linux, is the same: fork it, or find an alternative. Money isn't going to appear out of nowhere, so the reality is that the Fedora Project (or the fork of it following this) would have to rely solely on community donations, or perhaps try to secure a sponsorship from another company (like Amazon, which uses Fedora as a base for their distro iirc). Worst case scenario: Fedora dies and you install a different distro. I don't really see the point in asking these kinds of questions.

Para_lyzed ,

From what I understand, zram only works on a small portion of the ram, and it used as essentially a buffer between ram and swap, as swap is very slow. It actually benefits systems with more ram, if anything. The transparent compression takes far less time than swapping data to disk

Para_lyzed ,

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.

Para_lyzed ,

I've had this happen before, and it was due to conflicts between installed packages and the new repos. If you try to run the upgrade through command line, it will let you know if it comes across any issues while trying to upgrade. In my case (I think this happened to me on Fedora 37, maybe it was 38 though), I believe I had some Python package installed that wasn't in the new repo, so it stopped my upgrade, and I had to use the --allowerasing flag on the command line upgrade to fix it.

The other user linked to the appropriate docs for using the DNF System Upgrade plugin, but I would like to point out that the docs specifiy that upgrades are tested from the 2 previous releases (meaning that you should be able to skip from Fedora 38 to Fedora 40 without installing Fedora 39). So you should be good to upgrade straight to Fedora 40 with a single dnf system-upgrade. Read the output carefully, and if it suggests to use the --allowerasing option, review the incompatible packages (I recommend writing them down if they are important), and then rerun the command with --allowerasing. I strongly discourage running a dnf system-upgrade with --allowerasing before you know what packages it may erase.

Para_lyzed ,

Sounds like a fractional scaling issue. Keep the scaling at 100% to avoid those kinds of issues

Para_lyzed ,

I explain a lot about release schedules for context, but you could skip to the last paragraph for the more direct answer to your question if you don't care.

Fedora is on a semi-rolling release schedule, which only really means that its release schedule is in between that of Debian (fixed release schedule) and Arch (rolling release). A fixed release schedule freezes packages at the time of release and keeps major packages at the same version (plus bug/security updates) for the lifetime of the operating system (usually 2-4 years, LTS support can last longer for some distros). Major versions will have next fixed package versions, hence the need to perform a full system upgrade when going to a new version. Rolling release distros don't fix packages at specific versions, and you'll hear them referred to as "bleeding edge", because they always get the newest updates quickly. Since they don't fix package versions, there are no "major versions", they just updates constantly (Arch is just Arch; there's no Arch 10 or Arch 11). Semi-rolling release (Fedora) fixes some packages at a specific major version; usually large packages that could be troublesome to update to a new major version of because of dependencies (i.e. the DE, core system components, it depends on the distro). So when you perform an upgrade to a new major version of a semi-rolling release distro, you're changing fewer packages, and there is (usually) less of a gap between versions than fixed releases among the packages that are fixed.

Fedora releases a new major version every 6 months, which they support for 1 year. Since I assume you're coming from Windows, the new Fedora major versions are kind of like Windows feature upgrades. For the most part, much of the system is exactly the same, but there are some new features included and packages are updated to newer versions. Fedora doesn't have the real fixed "major" releases like you see from Windows 10 to Windows 11, or any other version. Every major update is just a minor bump, all things considered. In fact, you can even skip a version when upgrading (say from Fedora 37 to Fedora 39 without updating to 38). The differences between major Fedora versions are generally minor enough that you can just press the button and let it do its thing. This is even easier for their atomic distros, but you're likely just using Workstation. There are some cases where new major versions of packages will necessitate config updates (like upgrading to KDE Plasma 6 did with Fedora KDE users), but that's generally rare. So yes, you can just hit the button and upgrade.

Para_lyzed ,

It's fairly common for apps to save login information in Kwallet on your keyring, so anytime those credentials on your keyring need to be accessed (like automatically logging into Discord when it starts), you will need to unlock your keyring. It's generally easier to just log into your profile with a password, as Kwallet won't need to get you to unlock it separately.

Para_lyzed ,

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.

Para_lyzed ,

By the same (virtually nonexistent) logic, neither are games in general, or operating systems, or computers, or anything that is not strictly "necessary" for one to survive. Yet all of these things clearly have a strong intrinsic value to society, else we wouldn't be working so hard on all of it. If you don't enjoy VR, don't use it; it doesn't get much simpler than that. I can guarantee you that no one on the SteamVR dev team is going to care about your opinion or where you think their resources are better spent. Want to change that? Apply for a job at Valve. Pointless comments aren't going to do anything.

Para_lyzed ,

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.

Para_lyzed ,

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.

Para_lyzed ,

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • kbinchat
  • All magazines