Fedora Linux Workstation features a GNOME desktop environment which is an easy to use, intuitive, and efficient desktop environment. But this is not the only option if you would like to use Fedora Linux. There are other spins that provide alternative desktop environments like KDE, XFCE, Cinnamon, etc. This article describes how you can try different desktop environments if you are using an OSTree based Fedora Linux spins.
Main version of Fedora Workstation
If you installed a non-OSTree Fedora Workstation or one of the Spins and would like to try different desktop environment, you have some possibilities:
- install different desktop environment using dnf
- dual boot multiple spins of Fedora
If you choose the first option, you have to install another desktop environment by using the dnf install command. This technique enables you to select which desktop environment you would like to use on the login screen after system boots. Using this method will pull in a lot of dependencies. This is especially true when you have a GTK based desktop environment (like GNOME) and install a QT based (like KDE), or vice-versa. It can be difficult to completely uninstall one of the installed desktop environment if you are not satisfied with them.
Another issue with this is that system apps may be doubled in the application menu on each environment. For example, if you have installed GNOME and install KDE, you have Nautilus and Dolphin for browsing files, GNOME Terminal and Konsole for terminal emulation, etc. You have to remember which app to use on which environment, because apps from KDE behave worse on GNOME and vice-versa.
If you choose the second option, you have to make some free unpartitioned space on your hard drive to install another Fedora spin alongside one you are currently using. In this way, the systems are separated from each other and the system apps will not be doubled. You can decide to share the /home partition between them. This technique enables you select the system to use in the bootloader menu before system boots. But if you use this method, you have to maintain these systems separately (for example installing updates) and it consumes a lot of free space on the hard drive.
OSTree based version of Fedora Workstation
Some variants of Fedora Linux are OSTree based. OSTree provides immutability and transactional upgrades with the possibility of rollback in case something goes wrong. You can read more about it in this great article. Right now, we have three OSTree based Fedora Workstation variants:
- Silverblue – provides GNOME desktop environment
- Kinoite – provides KDE Plasma desktop environment
- Sericea – provides Sway window manager (not recommended for beginners)
If you are running one of these variants of Fedora Linux, you can easily switch your system to another OSTree compatible one to try different desktop environment. This process is similar to doing a system upgrade. OSTree guarantees that the operation is transactional (finishes successfully or nothing is changed) and you are able to rollback if you are not satisfied with the change. The operation does not consume much space on the hard drive, and system apps are not doubled.
How to use OSTree rebase to switch to a new variant
To start, I recommend executing the following command to pin the current deployment. This makes certain it will not be deleted automatically in the future and provides the ability to roll back to it.
$ sudo ostree admin pin 0
If you have a pending update, the command may fail with the message:
error: Cannot pin staged deployment
In this case, reboot your system to apply pending updates, and try again.
After pinning the deployment, execute:
$ ostree remote refs fedora
It outputs a list of all available branches that you can rebase into. Every branch has an architecture, version, and the name of the variant. Select carefully. In the following examples I assume you would like to rebase into the current stable version of Fedora for x86_64 (version 38).
- for Fedora Silverblue, use fedora:fedora/38/x86_64/silverblue
- for Fedora Kinoite, use fedora:fedora/38/x86_64/kinoite
- for Fedora Sericea, use fedora:fedora/38/x86_64/sericea
Choose the branch you wish to rebase into and execute the following command (change the branch name provided in the example if necessary):
$ rpm-ostree rebase fedora:fedora/38/x86_64/kinoite
When this command succeeds, restart the system to begin using the new desktop environment. If it fails, the system should continue to work unmodified thanks to transactional updates provided by OSTree.
Undo the rebase into an OSTree variant
If you are not satisfied with the new environment the following command will return you to your original variant:
rpm-ostree rollback
Restart your system once again to switch back to the previous variant of Fedora.
Ernest N. Wilcox Jr.
Ostree rebasing sounds very interesting. I’m currently using the Fedora-KDE spin, and I’m very satisfied with it but the promise of an immutable system with transactional updates is very appealing. I have downloaded the kinoite image to my Ventoy drive so I can try it out.
If you don’t know what Ventoy is, check it out at https://www.ventoy.net/en/index.html
Gregory
Great article. I’ve been extremely interested in trying the immutable editions, and this has made me want to dive in asap!
Just wanted to let you know that I spotted a minor typo in the article. In the section “OSTree based version of Fedora Workstation”, the last sentence says “The operation does not consumes much space on the hard drive, and system apps are not doubled.” I believe it should say “consume” rather than “consumes”.
Richard England
Correction made. Thank you for finding that.
Damián
With this approach you still will have the problem of “apps for different environment present” since system Flatpak installation won’t get affected, right?
Well, I’m not using Silverblue but I think file manager and terminal apps are not Flatpak. But for example if you want the full KDE experience you’ll install Kate, but then you’ll see it in GNOME and maybe there you prefer GNOME Text Editor.
Ethan
I can confirm, this is a problem
Jakub Sierżęga
Kwrite app is included in the Fedora Kinoite base image:
https://pagure.io/workstation-ostree-config/blob/main/f/kde-desktop-pkgs.yaml
So, if you install Fedora Kinoite, you will have Kwrite by default, and when you rebase to something other, it disappears.
But you are right that while installing Fedora Silverblue, some GNOME apps are preinstalled as flatpaks and they don’t disappear while rebasing. But if you would like to deal with it, it is very easy to search flatpaks that have “gnome” in its name and remove them unlike if you have gnome apps pulled in as a dependencies in the package manager.
But installing Fedora Kinoite/Sericea does not install any Flatpak by default if my knowledge is actual, so this problem exists only when you initially installed Silverblue and rebasing to something another and is very easy to solve 🙂
Esc
Kuba, super artykuł.
Bill Chatfield
This is a very cool article. I personally don’t see any need for SilverBlue and like systems. Fedora Workstation works fine for me for developing software and general internet access. I think we’re spending an extraordinary amount of resources on unnecessary capabilities when usability is really the most important issue. For example, have you ever tried to setup NFS? You have install the right undocumented packages, you have to configure the undocumented services in systemd and enable them, you have to open the undocumented service names in firewalld. None of the names are consistent. You have to make sure the services start at boot time. The names of the running programs are different from the package names, the service names and the firewall service names. You have to export your file systems with undocumented options for various different operating systems to mount. All of this configuration is different from Ubuntu, so if people are coming from Ubuntu, they’re going to be completely confused. Doing things like running NFS, that use to be simple, are now overwhelmingly complex. Most people would not be able to figure it out. They would give up.
Jakub Sierżęga
Thank you for comnent.
You said you are developing software. Did you have any situation that you had to install some software that is not packaged as rpm? If you would like to compile it from source, you have a lot of dependencies to pull in, and you will not need it anymore after the compilation. Also installation scripts of that kind of apps usually installs these applications by modifying system files directly and the package manager is skipped. It is difficult to maintain this software and keeping track what is installed and completely remove it if necesary.
Immutable system will not permit you to do things that make your filesystem dirty, and forces you to do this kind of things in a toolbox. Toolbox is a container with a complete filesystem which is mutable, and is well integrated with the host system. The whole home directory is shared, launching GUI apps from toolbox is working out of the box etc. You can have multiple toolboxes and creating and removing toolboxes is very fast, so If you mess up something, you can recreate toolbox.
I am also a developer, and I often had a situation when one app required java 11 and another app required java 8. I know that there are solutions that make able to switch java version in the host system, but I prefer to create toolbox from each app andinstall necessary versions of dependencies in it, it ismuch easier to maintain.
I amusing an immutable system for developing apps and it works great.
lampahojd
Nice article, it shows a well defined strength of the immutable system.
(People like to talk about a “clean OS” as if that in itself were a rational thought; “easier to reinstall” is ..fine if you like reinstalling? Or is an IT manager at a company or school, immutable systems would seem handy in those scenarios)
Ordinary Workstation has worked great for me and immutables have held no particular appeal for my personal machine.
What this article describes is a benefit that could be interesting if one was curious about other DEs.
Jakub Sierżęga
Thank you for your comment.
I written this article to promote immutable systems by describing one of the biggest feature, but this is not all, I am using immutable system to develop software in my work as a developer and described how it helped me sometimes in another comment.
I am happy that some people written that they will try this kind of OS after reading this article 🙂
Meowie Gamer
I’ve been using an immutable system since march and i’m pretty happy with it. I use a modified fedora silverblue called ublue-os, and it works very well for me!
John L. Ries
Why would I not simply install multiple desktop environments under standard-issue Fedora, try them out and keep the ones I like (no rebasing required)?
Joao
I suppose on non immutable system with btrfs you could also create a snapshot using btrfs, then install a different desktop environment to try and rollback if you don’t like.
Achim
As far as I understand, when using one of the immutable versions, I’d have to install Firefox or Chromium as flatpak, right ? If so, can flatpak browsers use GPU compositing ? Or would it be software rendering ?
Jakub Sierżęga
Hello
I don’t know if the browser in flatpak can use GPU compositing but if not, you can install the browser using a package layering.
Darvond
Sure, one COULD go though all that rigamarole, rebasing your system with RPM os-tree, or one could just install them and use something like the Terminal Based Session Manager (TBSM) and select them like choosing what tie to wear today.
It even supports Wayland sessions and weird window managers like WMX. As a bonus, it’s basically pure script and a little bit of makefile.
I really think there was some damage done by the naming schemes of certain other distros which lead to the confusion of “One Desktop, One Distro”, rather than “One Distro, Many Desktops”. I have 2 desktops and 13~ window managers installed.
i3 is a whole MegaByte, no user is going to lose any sleep over that.
Bart
For folks already on immutables, what are your thoughts on the size and speed of rpm-ostree update op? I use Kinoite but in comparison, DNF updates are tiny and lightning-fast.
Jakub Sierżęga
Hello
Yes, it is true that rpm-ostree updates are slow if you have layered any packages. But if you don’t use package layering, it is pretty fast.
But, I think this is not a problem, becauae if you are using Silverblue or Kinoite, updates will be downloaded in background, and the only thing you have to do is a reboot to apply them.