Ever wondered what happens when you run multiple desktop environments on the same Linux system? I recently put this to the test by installing KDE Plasma alongside Ubuntu’s default GNOME setup. Unfortunately, it turned out to be more of a headache than I expected.
As aKDE Plasma fan, I’ve never really loved Ubuntu’s customized take on the GNOME desktop environment (DE). Still, Ubuntu remains themost popular distro, so I keep it around for testing and experimentation. My latest experiment was setting up a system where I could quickly switch to standard Ubuntu for testing and screenshots, then jump back to my main KDE Plasma environment—all without having to reboot my system. To do this, I decided to install KDE Plasma on top of Ubuntu and work with a system that had two DEs. Here’s how that went!
Installing KDE Plasma Went Smoothly and as Expected
Installing KDE Plasma on Ubuntu is relatively smooth and straightforward. To start, first ensure your system is up-to-date. Run this command:
Once complete, reboot your system if necessary, and then run this command to installaptitude:
Aptitude is a more feature-rich alternativepackage managerthat’s better at handling complex package dependencies compared to APT. Given the fact that installing a completely different DE with its own ecosystem of applications and dependencies introduces a lot of room for conflicts, I wanted to use the Aptitude package manager to install KDE Plasma.
The above command only installs the DE with the basic utilities. You can also usekde-standardto install the full suite of system utilities. I wanted to keep things minimal, so I just installed the DE. If I needed anything extra, I could just install it later.
The installation process was quick and error-free. During the installation, I was prompted to choose between two display managers: SDDM (Simple Desktop Display Manager) and GDM3 (GNOME Display Manager 3). I went with SDDM (the default for KDE), as it offers more theming options and better compatibility with Plasma. Using GDM3 might have created compatibility issues down the line.
After installation and a quick reboot later, I was greeted by SDDM’s sleek login screen. Using the session selector, I booted into a clean KDE Plasma session. Honestly, it looked and functioned like any regularKDE Plasma-based distro.
If and when I needed to switch back to GNOME, I had tolog outof my current session and use the session switcher to log into GNOME. The transition was much faster and smoother compared to switching between two distros in a dual-boot system.
I initially had the idea that my GNOME and KDE Plasma sessions would only have system apps specific to that DE. However, as I started exploring the system, I quickly noticed that I now had duplicate applications for most core functions.
For example, both the file managers, KDE Plasma’s Dolphin and GNOME’s Nautilus, were accessible from within the same session, creating a confusing overlap. This duplication extended to nearly every system application category. Interestingly, I didn’t see GNOME Settings or GNOME Terminal appearing in my KDE Plasma sessions, which suggested some level of session isolation was working. However, the KDE Settings and Terminal app showed up in my GNOME session, which was strange.
One of the most apparent issues was the visual inconsistency. You see, KDE Plasma apps are built using the Qt toolkit, whereas GNOME apps are built using the GTK framework. As such, even after applying different themes and customizations, the visual discord was jarring and made the overall experience feel amateurish.
That said, the app redundancy and visual inconsistency were only half of my troubles, as many of my pre-configured system shortcuts and bash scripts just broke entirely—presumably because they were expecting specific DE components that weren’t active in the current session. This meant I basically had to reconfigure everything from scratch!
The System Got Very Buggy and Unstable
As I continued using the system over the following days, the overall experience deteriorated significantly. Despite running on capable hardware with a Ryzen 5 processor and 32GB of RAM, everything felt increasingly jittery and unstable.
Performance issues appeared across both the DEs. Applications took longer to launch, window animations stuttered, and general responsiveness suffered. I attempted switching betweenX11 and Wayland sessionsto isolate the problem, but the sluggishness persisted regardless of the display server.
Most concerning was that my previously stable Ubuntu GNOME setup—which had been working perfectly before the KDE installation—also started experiencing problems. Clearly, the two desktop environments were interfering with each other at a fundamental level—corrupting configs, causing conflicts, and making the entire system unreliable.
Fixing the Problems Required Finding and Deleting Conflicting Files and Packages
Apparently, KDE Plasma and GNOME store preferences, theme settings, and application configurations in directories that sometimes overlap or interfere with each other. This is likely what was causing the problems I was facing.
Now, the methodical approach to fixing this would involve monitoring error logs, identifying which specific processes or packages were causing conflicts, selectively removing problematic components, and testing stability after each change. While technically possible, this is more trouble than it’s worth.
No wonder the most widely recommended solution I got was just topurgeor deleteGNOME (or the DE I don’t plan on using) along with all its dependencies. This would remove all potential files and packages that could cause any conflict with the other DE.
Unfortunately, completely removing GNOME wasn’t an option for me since my original goal was to maintain access to both DEs. Without that flexibility, the entire project became a lost cause. I was stuck with an unstable system that couldn’t reliably run either DE properly.
It’s Easier to Just Install Kubuntu
Experiments like this bring to lightwhy Kubuntu existsin the first place. If you want Ubuntu as a base with KDE Plasma as the default DE, Kubuntu is what you should use. That said, installing Kubuntu on bare metal means if you want to switch between it and Ubuntu (or any otherGNOME-based distro), you need to wait through the entire reboot process. This can be a huge headache if your workflow demands frequent switching.
The better option, I found, is to simply use one distro as your main and useVirtualBox to virtualize the other. This is what I’m doing right now—where I just keep a virtualized instance of Ubuntu for testing onmy main Garuda Linux distro. It’s not always perfect because virtualization can be finicky with more intensive tasks, which is when I boot into my Ubuntu instance installed on bare metal.
From my experience, installing a new desktop environment on a desktop-designed Linux distro only really makes sense if you’re prepared to completely remove the original environment. If you have a lot of files, configurations, and customizations on your current setup, that would be a hassle to migrate, purging the existing DE and installing a new one lets you keep all your data while changing the look and feel of your system.
However, if that’s not your situation, you’re usually better off dual-booting with a separate distro that features your preferred DE, or running it in a virtual machine. Both options offer nearly the same benefits—without the extra headaches and complications I had to deal with.
