43
What features would I be losing if I switched to GNOME?
(lemmy.world)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
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.
Kinoite is looking really nice since my Linux is bugged (again).
Maybe give Aurora a chance.
It's basically a slightly altered variant of Kinoite with many QoL-changes and additions.
And there's also Bazzite, which is the same, but for gaming purposes.
They belong to the uBlue-family, which is one of the coolest things ever in the Linux world for me
Your web link (404) appears to be missing something. This is correct : https://getaurora.dev/
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 " 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).