I've been seeing a lot of bazzite recommendations recently, and it sure sounds great. An atomic fedora, gaming optimisations out of the box. It just works....
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
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 <your name> to mranachi or <MOK certificate nickname> to MOK-temp-6-9-kernel)
Add your user to /etc/pesign/users if it does not already exist.
Add line %define pe_signing_cert <MOK certificate nickname> 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.
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):
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).
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.
Fedora does test everything before they ship it. Each major kernel release can go through as much as a month of testing for stability and regression. SteamOS is based on Arch, where they don't test the kernel for regression. Despite testing though, this is an incredibly obscure issue, and obviously the Fedora team can't catch every kernel bug. It only happens on some hardware, and only in the event that the VRAM visible to the CPU is filled, and less used portions of the CPU-visible VRAM are moved to other parts of VRAM that only the GPU can see. This is why resizable bar fixes the issue for many, as it makes all VRAM visible to the CPU, so there is no move that happens (moving the VRAM data has an off by one error). This issue goes all the way back to 6.6.30, and was only discovered 3 weeks ago, and took 2 weeks to find the root cause of and patch in the stable version of kernel 6.9. It was only found because the 6.9 release candidates added checks for hardware capabilities, and the off by one error that is the root cause of this issue threw an error with the hardware capability checks. I'm not a kernel developer, so I don't know all the details, but it is discussed in the issue I linked if you want more explanation.
Yes, that may be the case, but that comes with its own downsides as well. The most recent version of SteamOS runs the 6.1.52 kernel from September (thus it should be unaffected by this bug, since it was introduced in 6.6.30). I don't follow kernel changelogs very closely (so I don't know all the new features and improvements that are being missed from new versions), but there are lots of optimizations and new features constantly being added to the kernel. Of course, the tradeoff is that you don't get new bugs, but you also have to backport bug fixes or else you'll have the bugs present in your current version for a very long time (often the kernel devs do this, but depending on what version a given distro uses, the distro maintainers may have to do it themselves). It's not as big of a freeze as Debian based systems (EDIT:Some of the time; right now they are technically behind Debian on the kernel minor release, but in SteamOS 3.6 (which is in beta), they will be updating to 6.5), of course, but it's a choice that has tradeoffs. Different people will subscribe to different opinions on kernel updates, given that no one way is clearly superior for user experience and features alike.
As for proprietary packages that are held from Fedora for copyright issues (media codecs and Nvidia drivers, for instance), there are always uBlue images like Bazzite, Bluefin, and Aurora that fix that. One of the very few stipulations to the Red Hat sponsorship for Fedora is that they do everything possible to avoid legal trouble, hence why those packages aren't included in the base repos or installed by default. It's a small caveat that disappears once you install the correct packages.
I think SteamOS is by far the most optimized OS for the Steam Deck, but I don't think it's very useful to use it on any other hardware (there are better options). Kernel updates will always be a point of conflict for at least some people regardless of what model you use, but I personally appreciate the quick turnaround for major kernel versions in Fedora. It's actually improved my experience on my laptop significantly, as there have been recent changes that apply to my specific hardware (in some of the 6.6 releases, for instance). Of course, anyone can be free to prefer a slower rollout, and that is equally valid. The bug fixes for the issue OP is having should be backported to 6.8 anyway, so it shouldn't necessitate waiting for 6.9 to hit Fedora in a few weeks.
SteamOS currently runs 6.1, which is an LTS kernel, it just isn't the latest LTS kernel (that's 6.6 released at the end of 2023). Steam also makes modifications to the kernel they use in SteamOS, so they have their own versions custom built for Steam Decks. I should revise my previous statement slightly. Debian Bookworm is on 6.1 as well, but SteamOS 3.6 (in beta) uses 6.5 (which is non-LTS). Debian skips every other LTS kernel because they release every 2 years, but SteamOS (eventually) upgrades each LTS kernel or some non-LTS between? They did the same thing with 5.13 a couple years ago (5.10 and 5.15 are LTS). I don't really follow their releases since I don't own a Steam Deck, so I don't really know the rationale there. Funnily enough, looking through posts about it online, it seems that SteamOS is sometimes ahead of Debian on the minor kernel version and sometimes behind (when they're on an LTS kernel). Currently, they are behind Debian on minor release (6.1.52 vs 6.1.76). Very strange, no idea what's going on there.
But I specifically mean the packaging delays. There are sometimes sync issues with drivers, like this recent one with no free stuff that is used alongside the normal stuff.
Hm, interesting. I don't recall experiencing anything like that personally since I hardly use anything from RPMFusion, but that does seem frustrating. Looks like it was fixed very quickly, at least.
And with Cisco-openh264 they cant to anything, Cisco ships the packages which is legally binding, and there are issues sometimes.
Ah yeah, I've heard about that. I can't remember the last time I installed Cisco's openh264 though since I started using VLC, which can handle video and audio formats without installing extra codecs. I think MPV can do the same? I'm not sure what comes with my browser, but it is packaged as a flatpak and seems to run media just fine. Maybe there is some other use for openh264 that I'm not aware of that just doesn't come up in my normal use, but I don't think I've installed any media codecs in Fedora for a couple years now. Granted, I don't play videos often (but I do play MP4s when I do), and all my music is in FLAC format, so I'm probably an edge case. I also don't game, but I remember seeing something recently in this sub where someone may have had codec issues while playing a game.
But Fedora is doing a great job, and the fact that rpmfusion exists alone is pretty hillarious. These are obviously Fedora people maintaining the stuff in secret, in a country where patent laws are not enforced (but are also in place afaik).
Well, Fedora is a community project, so it's very difficult for anything individual maintainers do to come back to Fedora so long as the name isn't put on it directly. If I were to speculate, most of the RPMFusion maintainers are Fedora community contributors (and I imagine they likely wouldn't work at Red Hat, given Red Hat's apprehension towards copyrighted material). I don't think it's really any different legally speaking from a Fedora contributor working on a personal project on the side. The fact that you can manually add the repo to Fedora doesn't connect the two in a legally binding sense. So as long as it isn't being funded by Fedora, and their branding is absent, then it shouldn't really matter. I don't know about the actual legal aspects of the packages they are distributing, or what country/countries RPMFusion repos are hosted in, but so long as nobody is profiting/losing substantial profit, it likely isn't even worth pursuing any legal recourse to begin with.
You are at the bleeding edge, but I often find bugs that are simply there and need to be fixed. Once KDE Plasma 6 is on some LTS release like CentOS Stream, I may think about switching.
Yeah, that's fair. There are definitely bugs that pop up every once and awhile, but for the most part they're minor (at least the ones I notice). This kernel bug is among the more major bugs I've seen with Fedora in the past few years, but I only know about it from this post; I haven't experienced it myself. I imagine there have been similar things (or worse) like this that have gone over my head as I didn't experience them myself. Perhaps my experience has also been more stable because I've been using GNOME up until Fedora 40. I do find my experience with Fedora to be much more stable than Arch, but that is to be expected given their release models. I can only recall having experienced 1 or 2 bugs in the past year on Fedora, which is less than I experienced when I used Ubuntu many, many years ago, and the bugs were fixed much faster than they were on Ubuntu, where it would often take months for a patched version of the package to enter the Ubuntu repos. That's all anecdotal, however.
The reason I usually recommend Fedora to people (and uBlue images by extension) is that it sits on some middle ground between the rolling release bleeding edge distros like Arch, and the stable, LTS, frozen for 2 years distros like Debian. I have grievances with both of those models that are addressed with Fedora, and that's what makes it a good distro for me. My experience with bugs hasn't really been any more common than when I was using LTS distros, but that may be a fluke. I will likely be moving one of my servers to Debian in the future though, because it makes sense for its purpose. Different release models benefit different uses (and people), of course.
This isn't me asking for help or anything, I already replaced it with fedora kinoite. I just felt like talking about this ridiculous venture of mine....
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 rebaserollback 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.
Bazzite also has a lot of extra gaming-oriented changes to Fedora, such as including the System76 scheduler, which can increase performance in games. Since Bazzite has versions with Nvidia drivers in the root image, it makes it easier to use Nvidia cards.
By the way, if you hadn't figured out the install for Nvidia drivers in Kinoite, here is a simple guide for how to do it. Also, there is documentation from the RPM fusion repo on how to install the drivers, which you can find here (that's where the commands from the article came from). There are more details elsewhere in the documentation if you need them, such as how to get the Nvidia drivers to work with Secure Boot on atomic distros (though I'd recommend just using Bazzite for that because it can be a pain to get working manually).
Bazzite is definitely a great option if you have an Nvidia card or you are looking for gaming performance. It includes some gaming oriented features and optimizations like the System76 scheduler that aren't in the regular Fedora Atomic builds that have the potential to increase performance, and make things easier (such as having a build with Nvidia drivers in the root image). I don't really game at the moment, so I don't have personal experience with Bazzite, but I've been on Fedora Atomic KDE for a while now and it has been a great experience. I've heard lots of great things about Bazzite, so I would expect it to be a similar experience (maybe a bit easier). I feel comfortable recommending both, but the more appropriate choice will depend on what you use your computer for and your own preferences, of course.
While I haven't personally rebased to a different image before, it should be pretty seamless, except for some potential config issues if you are switching to an image with a different DE (i.e. switching from GNOME to KDE). I've seen people in this community mention successfully rebasing to another DE, but Bazzite's documentation recommends against it. I imagine that there may be config issues in /etc or in your home folder from switching DEs, just as may be expected when switching to a different DE on a non-atomic system. Your milage may vary there, essentially; Fedora and uBlue just don't officially test rebasing between different DEs. I usually tend to be cautious in my recommendations, so I generally recommend users to try out different DEs on a VM before deciding on one, and to do a full reinstall when switching DEs. There's a chance that is overkill, but it is certainly safe. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example. It seems that the issues can be fixed, but since the rebase between DEs is not officially tested, it is prone to small issues like these (though it appears at least some of the ones in that post have been fixed upstream now). The issues in that post were all incredibly minor, so you could likely fix your system in place if you were to try this (maybe you won't even have any issues; half of the post was about an issue caused by the fish shell, which is not the default), though you'd have to know where to look to find any issues (I'd start by checking overlayed packages and seeing if there are any from the old DE). You can always rollback safely, as each previous version the OS saves has it's own unique /etc folder (even though it isn't part of the root image).
Switching between Fedora Atomic and Bazzite is more supported (when you keep the same DE), but different images can add and remove packages from the root image, so you may find that you'll need to overlay packages/remove overlays when switching between them (such as Nvidia drivers). I don't imagine that posing an issue as an end user in most cases (outside of the Nvidia drivers), just thought it was worth mentioning, as it is an edge case that could pop up. That's one of the reasons that adding overlays isn't the first recommendation for installing packages, as they have the potential to make rebasing a bit more complicated for a handful of packages that may be different between different images. I would imagine that an update (or even the rebase itself) would fix any dependency issues (hence why I don't see it being an issue for an end user in most cases), but I don't know that for a fact. None of my information on rebasing is based on experience, except for rebasing to a new major version (i.e. Fedora 39 to Fedora 40), so you should look into that more yourself if you want more concrete details. Also, I mistakenly mentioned rebasing to a previous version of your image from before an update. That is actually called a rollback, and uses the rpm-ostree rollback command, more info here (I've edited my previous comment to reflect that). Bazzite has some good documentation on rebasing here, and I don't see any mention of package conflicts between Bazzite and Fedora Atomic, though you will likely want to remove an Nvidia driver overlay if switching from Fedora Atomic to Bazzite. You very likely won't need to make any other changes. There are people in this community with far more rebasing knowledge than I can provide/find from searching, so you can always make a post asking about it if necessary, and someone should be able to help.
It's also helpful to note that documentation for Fedora Atomic (sometimes you get better search results by using "Silverblue", as that was the original project name), Bazzite, and Bluefin are often interchangeable, as they are all based on Fedora Atomic. You may find some things more easily documented in Bazzite/Bluefin than on Fedora Atomic or vice versa, but much of that documentation applies exactly the same to any version. For any additional information about rpm-ostree, I would unironically suggest reading the manual page through man rpm-ostree or online at a site like this if you aren't comfortable with the terminal interface for man pages (quick tip: you can search for a term in man by typing / followed by the search term, and you can use n and N to go to the next/previous occurance).
I'm just here to help people out when I can, so if my comments are able to help anyone, I see it as time well spent. Sometimes it even helps me learn new things myself, and cements concepts I was already familiar with, so it's mutually beneficial!
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.
I'm bored and want to practice my Rust skills. I am the creator of open-tv. If you have any idea for a linux desktop app, even if it seems quite complex, I will take it.
This is a very interesting concept, and I would also like it. Would this even be possible on Wayland though? I know it should be possible on X11, but I'm unsure if the Wayland isolation would entirely prevent a usage tracking program like this from seeing what the focused window is, or seeing the total time a process has spent in the background (depending on what type of usage is being tracked).
I've seen a few people in this sub asking for a desktop client, so it seems like something (some) people would be interested in. Maybe reach out to the Thunder devs and see if you can become an official flatpak maintainer (assuming you have flatpak experience and know what you're getting into) if they don't have time to maintain it themselves. You could also maybe get the "desktop" flag added to Thunder in this list if you were to do that, which would help people find it.
LocalSend looks great, but I don't think it captures OP's intention. It would require someone else to download the app if they wanted to receive a file, but OP is asking for something that uses the already existing Airdrop/Quick Share so that they could send a file to someone without them having to install anything. I've had similar wants, as when I've wanted to share something with someone in public that I don't really know, I've just had to upload it to send.vis.ee, but that can be quite slow and inefficient. Something leveraging both Airdrop/Quick Share (that doesn't require you to be connected to the same WiFi network like LocalSend) would be ideal, as those are features included by default on stock iOS and Android (no install required). For instance, there was something similar called WarpShare that allowed you to share something via Airdrop from an Android device to an Apple device (but only in that direction), but its development has stalled and it isn't capable of using Quick Share for Android devices.
So i downloaded opensuse iso on my pendrive with ventoy, but during installation I'm getting errors due to not matching 5SMD code or smh like that, is there a any way to install system to get a fixed iso?
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.
Are you able to manually mount the EFI partition while chrooted? Running an update won't fix the problem if you don't have the EFI partition mounted properly. To that end, are you able to manually mount the EFI partition at all? That would be a very big problem if not.
While chrooted, try the following before updating:
mount /dev/sda1 /efi
I'm a bit confused by the partitioning scheme, as I don't see a /boot mount, are the files usually stored in /boot stored in /efi here? Usually the EFI partition only contains EFI binaries. Unless perhaps your /dev/sda3 is a LUKS encrypted boot partition? Sorry, I'm not very familiar with Arch, it's strange to me to not see a /boot mountpoint in the /etc/fstab
It may be a good idea to just roll back the snapshot if none of this works, though that will only change the btrfs partition, so it won't fix any issues inside the EFI partition if there are any issues there. Here's an article about how to do that with btrfs.
Great choice, I'm running Kinoite (Fedora Atomic KDE) myself! The atomic nature of the distros make them less prone to breakage, and much easier to recover from (since you can just roll back to the previous branch instead of restoring a BTRFS snapshot).
Just to throw another option out there, partclone will only copy data that is being used in a partition, without all the empty space. I don't believe it helps for encrypted partitions, but you could always just image the unencrypted filesystem with partclone to a drive with full disk encryption to work around that (and still prevent storing data unencrypted). Saves a lot of space.
Also, in the context of backups, I often prefer to use btrfs send to create and update backups through snapshots quickly and efficiently instead of imaging (though of course that requires you to use btrfs). Full imaging is pretty inefficient for my needs, and takes a lot of time.
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.
SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of a specific 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. So this means that in order to exploit arbitrary code execution 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 root, even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running with root permissions.
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 a 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, 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?
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):
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.
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...
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
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.
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.
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.
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...
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).
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.
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.
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:
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.
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.
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:
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.
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.
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.
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
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.
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.
I tried different font settings in the font settings and it didn't improve much (font hinting, anti aliasing, custom DPI settings, different font size)...
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.
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?
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:
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).
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.
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'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.
I don't mean for this to become a KDE vs GNOME post. I'm looking at switching to Fedora (because Arch is a pain), and it seems that GNOME is more supported. I use KDE on Arch. What features would I be losing if I were to switch? (ex: toolbar management, KRunner, etc.)
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.
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>" every time, as well. Just be aware that packages installed in toolbox live in a container, and they aren't intended to be able to break out of the container (so if you open a terminal in neovim, which is installed in a toolbox container, it will open a shell inside the container, not on your host). Containers can access your home directory and a variety of different directories in your system, so this often isn't an issue, it's just something to keep in mind (for instance, you can't enable systemd services on your host from inside a terminal).
I was reading the reddit thread on Claude AI crawlers effectively DDOSing Linux Mint forums https://libreddit.lunar.icu/r/linux/comments/1ceco4f/claude_ai_name_and_shame/...
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!
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.
Bazzite ? maybe not for V-rising.
I've been seeing a lot of bazzite recommendations recently, and it sure sounds great. An atomic fedora, gaming optimisations out of the box. It just works....
Crapped my system
This isn't me asking for help or anything, I already replaced it with fedora kinoite. I just felt like talking about this ridiculous venture of mine....
Hey does anyone know how to get microsoft suite apps on linux?
I want to get word, excel, powerpoint, onedrive and copilot on ubuntu, anyone know how?
Taking your ideas for my next linux app
I'm bored and want to practice my Rust skills. I am the creator of open-tv. If you have any idea for a linux desktop app, even if it seems quite complex, I will take it.
Kinda broken linux iso
So i downloaded opensuse iso on my pendrive with ventoy, but during installation I'm getting errors due to not matching 5SMD code or smh like that, is there a any way to install system to get a fixed iso?
[HELP] /efi fails to mount
Context:...
Disk imaging
What are we doing for disk imaging theses days?
Systemd Looks to Replace sudo with run0 ( news.itsfoss.com )
BG3 Vulkan problem? Please help ( lemmy.world )
Run through Bottles (flatpak) on Fedora Silverblue, AMD GPU, lutris-GE-Proton8-26...
Finally made the move ( lemmy.world )
Just don't ask how long it took to get my dGPU working properly :D...
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...
Windows is hell, i need to do something
Yo linux team, i would love some advice....
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...
My /var/tmp folder is endlessly stacking up on "container_images_storage_xxxxxxxxxx" folders? ( slrpnk.net )
The issue at hand:...
Can someone explain Universal Blue (and images based on it) to me?
I think I get the idea of Fedora Atomic (Silverblue, Kionite, etc.), but I do not get what uBlue is about....
Help updating to Fedora 40
Hello, I've installed Fedora 38 (KDE spin), about the time it came out and need a little help updating it....
text clarity on windows is so good, can I get the same on linux?
I tried different font settings in the font settings and it didn't improve much (font hinting, anti aliasing, custom DPI settings, different font size)...
Lutris wont launch on fedora 39
I have the amd 6700 gpu. When i run lutris in the terminal it cant find vulkaninfo or fluidsynth
Did Fedora 40 break something for you? ( gehirneimer.de )
I am running Fedora 39 right now and the last time I did a distro upgrade my graphics drivers were a huge PITA. Did your upgrade to 40 went smooth?
So, Fedora 40 is out, any guess as to when we can expect Nobara 40?
Pretty much the title. I'm not a regular on Discord and the website doesn't have any info about a release plan.
Dual monitor suspend, one monitor does not turn on when waking up. ( lemmy.ml )
Finally got my wife away from Windows and on Fedora 40 (Gnome 46)....
Any way to autologin with LUKS encrypted boot drive?
Hello everyone!...
What features would I be losing if I switched to GNOME?
I don't mean for this to become a KDE vs GNOME post. I'm looking at switching to Fedora (because Arch is a pain), and it seems that GNOME is more supported. I use KDE on Arch. What features would I be losing if I were to switch? (ex: toolbar management, KRunner, etc.)
Blocking AI crawlers with Caddy
I was reading the reddit thread on Claude AI crawlers effectively DDOSing Linux Mint forums https://libreddit.lunar.icu/r/linux/comments/1ceco4f/claude_ai_name_and_shame/...
SteamVR Beta gets Linux fixes, plus Beta updates for Desktop and Steam Deck ( www.gamingonlinux.com )