Para_lyzed @ Para_lyzed @lemmy.world

Posts

0

Comments

185

Joined

2 yr. ago

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.

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

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

Oh, very strange. Glad you got it figured out!

The remote input issue is related to Wayland, and currently all wlroots based compositors (including Hyperland) have issues with this. KDE Plasma has merged support for remote input to work with KDE Connect, however many other DEs do not have the support merged, and will have to rely on xdg-desktop-portal-wlr to implement it. Here are the related bug reports and issues:

https://bugs.kde.org/show_bug.cgi?id=448604

https://github.com/emersion/xdg-desktop-portal-wlr/issues/2

https://github.com/hyprwm/Hyprland/issues/1775

Also, it seems the other issue is unrelated, are you seeing an error on the command line, or is there a dialog popup, and can you quote what is said? I'm having trouble finding any related issues anywhere on GitHub, even the Hyperland issues around remote desktop did not seem to have this particular error (or didn't mention it at least).

There's a GNOME extension GSConnect that uses the KDE Connect backend if you're on GNOME. I haven't used it in awhile since switching to KDE, but it worked well when I used it.

As far as KDE's documentation says though, you should be able to use it on any DE. What exactly is the problem you're experiencing? Will it not start, will it not connect (if so try re-pairing), or is there functionality that is missing?

All I'm seeing here are jackett errors, which seems to be some kind of torrent downloader (not related to lutris). This is only 6 seconds of logs, there's a very low chance you would have caught anything related to lutris in that short amount of time. Look further back in the journal and find logs related to lutris before posting anything (after opening it again, they'd be gone by now). You could always try to start lutris right at a minute mark and just scroll up to the timestamp to make it easier to find, though it might benefit you to kill the jackett process before taking any more logs; it's horribly misconfigured

You can install sunshine on Fedora 40 with their COPR repo. Their GitHub releases lag behind on OS releases, but the COPR is automatically configured for new versions of Fedora since it doesn't rely on compiling in a Docker container. Haven't tried it myself, but it was recommended on their issues page.

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.

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.

Fedora 40 removes X by default (you'd have to install it yourself), so this is going to be using Wayland. Seems like they're using Ryzen integrated graphics, so at least it shouldn't be related to any of the problems with Nvidia on Wayland.

It is certainly helpful in preventing issues caused by packages updating, as the whole base image should remain consistent (and you could always just roll back to the previous update from grub if necessary and revert a commit that broke your system). Since you were using Arch, I made a baseless assumption that you would want the ability to modify the root filesystem for configuration, but it was a baseless assumption, so if that is not the case, then atomic distros are great for users that don't want to tweak tiny things in root directories like /usr. Granted, you can still overlay stuff if you wanted, so it's not as if you couldn't tweak stuff in immutable directories, it just requires a bit more work to do on atomic distros.

If what you're looking for is a standard desktop KDE experience with a distro that is more resistant to breakage, I'd highly recommend Kinoite. It requires a bit of learning, but not a whole lot. For instance, the typical order of priority for installing packages is flatpak (mostly GUI stuff) > toolbox (terminal-based packages like neovim that aren't already installed) > overlay with rpm-ostree (basically the equivalent of installing through your package manager). The fewer overlays you have, the better your protection from spontaneous breakage is. Of course, there are packages you will have to overlay depending on the situation (like the proprietary Nvidia drivers), but almost everything I need was available as either a flatpak or was practical to install in toolbox (basically a containerized mutable root that lets you install stuff with dnf instead of rpm-ostree). You can add aliases to your .bashrc so you don't have to type "toolbox run

<cmd>

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.

From your recommendation, I found a related project pandoras_pot that I am able to run in a Docker container, and seems to run more efficiently on my Pi home server. I now use it in my Caddyfile to redirect a number of fake subdomains and paths that are likely to be found by a malicious bot (of course all are excluded in my robots.txt for bots that actually respect it). Thanks for the recommendation!

Seems as if there are quite a variety of options, simply by typing a query into a search engine. In fact, KDE Plasma has Google account syncing in the "Online Accounts" section of settings, and it seems Dolphin (the default file manager) has native support for Google Drive in its context menus. I've never personally tried to use it, as I don't associate with Google products, but it seems that it's there natively. As far as GNOME goes, it seems at least Ubuntu (probably a GNOME thing in general) has support for connecting a Google account, but I have no idea what the experience is like as far as data syncing goes.

You don't need a native Google made app to sync with Google Drive. Google has no interest in supporting Linux outside of its investment in ChromeOS (which is based on Linux and has Drive syncing built-in, showcasing that this is a non-issue as its main selling point). There are plenty of apps available that allow you to sync on Linux, and it seems (based on what I see in the settings pages) that there are even native options in certain desktop environments.

Maybe because there's so many Linux implementations?

You mean distros? Linux is a kernel, and it is shared across all distros (with each distro choosing the modules and versions they support). It has nothing to do with Linux being difficult to support, or there being many different versions of it, and everything to do with the fact that Google's only interest in supporting it is to sell a version of it with their brand on it. Supporting any distro outside of ChromeOS would be supporting open source software, which stands directly against Google's vested interest in selling their own proprietary solutions and your user data. After all, you actually have control over your own data when you use Linux, and that's a threat to Google's business model.

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

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.

Fedora Silverblue was released alongside Fedora 30, which was 5 years ago; it is not "untested", in fact it is quite extensively tested by its userbase. It also is not in beta as you claimed previously, its release with Fedora 30 was its full release, after the betas with Fedora 29. Atomic desktops have been around for longer than that, however. They are far more tested and reliable than you seem to be giving them credit for. In fact, they are far more stable and far more resilient because you can simply roll back changes when you boot. A few previous versions of the entire operating system are available to boot from in GRUB, and it's as simple as booting into a previous version if a new one has issues. It's actually the perfect use case for a school computer lab, because each install is perfectly consistent, can be managed and fixed easily if anything were to break (if that were the case then the OS would have broken in non-atomic versions anyway), and nothing the user does will affect the base image of the system. The base image doesn't change unless it is updated. You can overlay things overtop of the base filesystem, but the base filesystem stays the same, so those overlays can be easily reverted.

It's been a few years since my last manual install of Fedora (I've just been upgrading it), but I got Fedora Server to install just fine. I did it one of two ways (again, I can't remember which): I either used the USB boot option to install to an SSD I attach via USB, or I booted the liveUSB on my laptop and installed to the USB SSD. In any case, Fedora has worked flawlessly for me for a few years on Pi now, so I would strongly recommend it.

Just as an aside, I highly recommend against using a microSD card if you have a Pi model that can boot from USB storage. They are far less stable than an SSD, and are not designed to withstand running an operating system from. They are also dramatically slower, and much more painful to work with. Getting a cheap USB enclosure for an SSD is a far better solution, just try to pick up an SSD with a DRAM cache. It will increase throughput and increase the lifetime of the SSD, and I would not recommend running an OS from an SSD without a DRAM cache.

EDIT: I believe this to be the easiest way to install Fedora for a Pi device. You will use a desktop/laptop Linux device, and the arm-image-installer will take an ARM ISO and install it to your storage media (SD card, microSD card, SSD, etc.). It was also the first thing I found when I looked up how to install Fedora on a Pi.