It’s been a month and a half since the alpha release of KDE Linux was announced during Akademy 2025, and so far reception has been pretty good. A number of people have started daily driving it and even contributing, which is great!
For anyone new to this project, I’d recommend reading the high-level overview here.
Today I’d like to talk about package management a bit. The lack of a user-facing package manager is a big difference between KDE Linux and most other Linux distros (even immutable/atomic ones), so it bears some discussion!
Let me start by saying:
I absolutely love package management.
No, really!
Before Linux, I came from the Mac world which lacks real package management. To install apps back then, you would fail to successfully drag them to the /Applications folder. Software requiring more integration was installed using Windows-style wizards with no dependency management and no provision for uninstalling them later. (!!!!!)
Moving to Linux was a revelation.
You mean I can just do
sudo apt install thingyto get mythingyinstantly? And it gets upgraded with the rest of the system automatically? And I can easily remove it if I don’t want it anymore?
It’s just 1000% better. We all know this. It’s a crowning jewel of our ecosystem.
However! There’s package management to get add-on software… and then there’s package management for assembling the base OS on your own computer.
The former is incredibly convenient and amazing. The latter is a Tool Of Power™ best suited for use only by OS builders and true experts.
I feel it’s a problem that historically we’ve used this amazing tool for both of those use cases, because building the base system from packages on users’ computers suffers from a number of nearly unsolvable challenges:
It deteriorates and explodes
As you install, remove, and update packages on your system, you inevitably encounter problems over time:
- Conflicts and incompatibilities with add-on repos
- Heisenbugs from orphaned packages still present on the system
- The ability to uninstall important functionality without realizing it, breaking the system
- Updates that break bootability due to some untested condition present only on your system
True experts and OS engineers can usually resolve these issues as they crop up.
What about everyone else? There’s usually no recovery method exposed in a normal-person-friendly manner, or at all. You’re just screwed unless you have a second computer or a phone set up to be able to talk to the distro developers on Matrix or IRC, and one can walk you through fixing it live.
It’s not a targetable platform
No installation of a package-based operating system can be guaranteed to have the same set of system software and libraries as any other one.
This means if you’re a developer, your software can’t make safe assumptions, and it’s running in an untested environment pretty much all of the time. You can contend with this complexity via a forest of conditional “if this thing is present, enable that behavior” logic, but versions of dependent libraries you didn’t test with can still break your app, and users will report bugs that you can’t reproduce.
It’s a barrier to raising quality levels
Package-based OSs allow for and encourage self-service to fix problems. Install this package. Edit that config file. Replace the version of some package with the one from another repo.
This is great for current you in the short term. But it’s less great for future you, after you’ve forgotten about your local fixes and encounter the same bugs the next time you re-install on a new computer, or after the local fixes have become unnecessary and are now causing issues that nobody will be able to debug.
It’s also less great for the whole project, its ecosystem, and others who might encounter the same issues but lack your level of technical skill or available time for troubleshooting.
But what about the really good distros?
I do think these challenges are manageable, even if they can’t be fully eliminated. My best experiences with a package-based KDE-focused distro have been with Fedora KDE, where they do a great job of it:
- They prevent removing critical packages that would break the system.
- They have a huge main repo with almost everything you could want, and RPMFusion (the only add-on repo you really need), has a close relationship with the primary packagers so conflicts are rare.
- They work hard on shipping a good product out of the box, rather than making you fix bugs yourself, and they regularly make bug-fixy tweaks to improve the out-of-the-box experience.
- In 4 years of usage, I’ve never had a system update break bootability.
And the result is fantastic. I 100% recommend Fedora KDE to anyone who wants a good experience with a GUI-focused package-based operating system. It’s hard to go wrong with it.
And obviously those of us building KDE Linux also think Arch Linux is great, since we use their packages for building our base system! It’s is an amazing tool for OS builders and experts wanting to create the personal OS of their dreams.
Others that I have less experience with are excellent, too. But still, none of them can fundamentally solve the problems I outlined earlier. It’s not for lack of labor or expertise; these simply aren’t easily solvable problems with a mutable system-level package-based design.
So what’s the solution?
Well the world is messy and everything has drawbacks. So there’s no solution that’s better in every way, and worse in none. But the approach we’ve chosen in KDE Linux does solve the above problems:
Stability
In KDE Linux, we build the base system out of Arch packages, but freeze the contents and take responsibility for the result being functional; we don’t offload responsibility onto the user.
Updating the system swaps out the old OS image for the new one; it’s both fast and safe. And you can keep around the old OS image (three of them, in fact) and easily roll back if you have a problem. It doesn’t become “quirky” and degrade over time.
It isn’t 100% perfect, of course. Users can still mis-configure their software and manually install user-level libraries that conflict with system-provided libraries. But it’ll be more obvious that you’re about to shoot yourself in the foot.
Being a platform
Specifically, Flatpak is a platform.
With Flatpak, developers target a specific version of a discrete SDK and its corresponding runtime. This runtime will be the same on every user’s computer. Now developers can make safe assumptions and reproduce bugs — at least, bugs not caused by hardware problems or users’ configurations differing from their own.
And developers who target this platform make their apps available not only on KDE Linux, but also most other Linux-based operating systems, too.
There are problems with Flatpak, of course; I’m not gonna claim it’s perfect. It’s opinionated, restrictive, can’t be used for deeper parts of the OS the way Snap can, and multiple installed versions of each runtime can end up consuming a lot of space. But it solves the platform problem, and traditional system-level package management just can’t.
Quality
Every KDE Linux user is going to to have image and video thumbnails, all the KDE wallpapers, the Desktop Cube effect, KDE Connect, a working installation of Plasma Vault, well-tuned power management, and support for as much exotic hardware as we could stuff in. None of this comes in optional add-on packages you can find yourself missing. You’ll just automatically have it.
If you find that something significant is missing or broken, you’ll need to tell the developers, and then they can fix it for everyone. If you’re an expert who likes fixing problems, you can still make those fixes; you’ll just be doing it for everyone in the world and not just yourself! The project and its entire userbase will benefit.
But what about the glaring, obvious drawbacks?!
The most obvious drawback of not having a package manager, is, well, not having a package manager. I’m pretty sure I don’t need to explain the lost benefits to anyone reading this. 🙂 We all know how amazingly flexible and powerful real package management is.
Thing is, its absence isn’t a problem for regular people because they weren’t using package managers to install gimp and rust and waydroid and whatever anyway. The Discover graphical app store is a waaaaaaay more user-friendly way to get GUI apps from Flathub or anywhere else. It isn’t actually a problem.
But the lack of a package manager does become a problem for power users and software developers. Let me group the usages into a few broad categories and explain how KDE Linux handles them:
GUI apps not on Flathub
This category shrinks all the time as Flathub cements its position as the de facto repository of GUI apps on Linux.
Still, for the remaining omissions, there are other options such as Snap, finding an AppImage of the app, or installing it using the package manager of another distro using a container. But these don’t offer the level of integration we’re aiming for in KDE Linux, so for that reason, we focus on boosting Flathub as its primary supported repository of GUI apps.
Command-line productivity and software development tools
In KDE Linux, we already pre-install most of the common and modern ones. This includes:
- Performance monitoring/debugging:
drm-info,htop,iotop,lsof,lspci,lsusb,nvtop,powertop, and loads more - Productivity/automation:
kdialog,rg,tree,vim,wget,wl-clipboard,ydotool, and many more - Network management:
hostnamectl,ip,iw,resolvectl,tracepath, and more - Version control:
gitandsvn - Compilers etc:
ccache,gammaray,gcc,gdb,llvm, and lots of ancillary tools - Build systems: Automake, CMake, Make, Meson, Ninja
For anything you need that isn’t pre-installed, there are multiple options including containers and the add-on Homebrew or Nix package managers. We even include a custom “command not found” handler that can direct you to available options:
Drivers and support packages for hardware
This is a tricky one, as a lot of these include kernel drivers or need to be installed systemwide. So we pre-install as many as we possibly can: support for printers, game controllers, filesystems, fingerprint readers, drawing tablets, smart card readers, braille displays, Yubikeys, specialized audio/video processor boxes; lots of stuff. However there are cases where this isn’t possible, which is a legitimate problem with KDE Linux right now.
Input methods
KDE Linux aspires to pre-install state-of-the-art input methods so you don’t have to install and configure everything yourself. However we haven’t reached this goal yet. We’re building a virtual keyboard with built-in support for CJKV languages, but it’s still a work in progress.
Languages
KDE Linux pre-installs support for all available languages; any that are missing are the result of bugs we should fix!
Support packages for VM guest OS integration
KDE Linux pre-installs all the ones that are available on Arch Linux. Similarly, anything missing is something for us to fix.
Software development languages and toolkits
Qt is obviously included, and so is GTK. There’s also Python, JavaScript, and Rust.
But we can’t pre-install everything here, as software dev stuff tends to be huge. If a large high-level toolkit/language/build dependency/etc. that you need isn’t pre-installed, the best way to use it anyway is by installing it or its development environment a container. Distrobox and Toolbox are fully supported.
And that should about cover it, I think!
Basically, we’ve tried to eliminate the need for traditional package management as much as we can, while preserving your ability to use a package management tool if you’re an expert or a developer who benefits from one. It should just be a userspace package manager (via a container, Homebrew, or Nix — your choice) so it can’t impact the stability of the system so strongly, and so any problems can be easily undone.
And to be clear, if you prefer a traditional OS that’s 100% mutable using a system-level package manager, that’s completely fine. There’s no shortage of Linux-based operating systems using this model out there, and KDE Linux is an admittedly opinionated divergence from it.
On the other hand, if all of this seems really exciting, please feel free to install KDE Linux somewhere and help us build it! At the time of writing, we’re a little over 40% of the way through the Beta milestone, at which point we’ll declare it suitable for general use by current Linux users. Progress is steady but slow; with more help, it can become a polished product much faster!
Adventures in Linux and KDE 
I would say KDE Linux is BASED. If I would make a distro, I would make it the same way: make it immutable, use Arch packages as a base, let users install software via Flatpak, Snap, AppImages, Nix and Distrobox/LXC/Docker.
The only thing I wonder is there a way to restore system files easily? That is, I had situations when e.g. the drive was failing and system files getting corrupted. Windows has SFC but it never helped me, be that a drive failure or I applied some patch to system files, or used a bloatware remover and wanted to return system files to the out-of-the-box state.
On Arch, I could do simple `pacman -Qqn | pacman -S -` and that’s all. Even if pacman isn’t starting due to some library being corrupted, I could still do it from Live USB as long as the database is OK.
What about KDE Linux?
LikeLiked by 1 person
Various recovery tools are planned or in progress. We’ll be taking Btrfs snapshots that are stored locally and building a UI around it so you can restore individual files from those snapshots.
Of course, if the disk’s hardware is dying, there’s really no substitute for replacement.
One of my long-term daydreams is a laptop that includes two 2230 form factor NVME SSDs from different vendors in Btrfs RAID 1, which should basically be immune to data loss from disk failure and take up barely more space than a single 2280 form factor disk.
LikeLike
Fedora, yepp, because this i use Fedora…
Packetmanagement in Plasma/KDE, i use dnf/apt for see => and learn something about decencies,
and if dnfdragora bugfixed for rpm5 i want use dnfdragora again, what menas not, i do not use at moment not dnfdragora, but it is a bit buggy because dnf5 and the packetseach works at moment only if it is use “joker” so “*” infront of the word or/and behind the searchword, in the / with the KDE/Plasma package management you don’t get what else is needed and the user doesn’t learn anything from it because it only happens in the background. In the prompt with apt and dnf it let it see what’s all is need for install the headpacket and then do i know what’s all installed or not, as example in Fedora with dnfdragora is the checkbox selected or is not selected if not installed, You can see for yourself what is installed and what is not.
Appimage, this can any user in his account download and Start the App in the Appimage and is not installed in the System and can get per “Container” and put in a Folder and double kick it for start.
Is not Distributions depended …
Flatpak is problematic in that it may interfere with the system or the program infrastructure.
This makes Appimage not and make possible for the user to download a appimage packet, put in a folder and doubleklick it.. in the Useraccount and as User because it runs in the Userspace and this is then not installed in the system but only runs by the user. Uninstall this Program as User ? => delete the packet..
What I really miss is Kuser so that you can see, learn and manage the users and groups. As well as learning how users and groups are related and how the whole thing is structured the way it is, that’s why the KUser user administration should be bug-fixed again and become the standard program for KDE/Plasma where you can manage the users and groups as an admin.
well you could take 4 Rasberrys Pi with 16Gig ram, NVME SDD’s inside, put it together as really fast server over flatband , 2×4 USB3 as Datastore and you have really energy saved Server in your basement.. like i have tholt in the past, my RPI5 in my basement is also really fast at my Net-domain 🙂
And a RPI5 is more energy saved as a Notebook 😉
best regards
Blacky
LikeLike
I think Discover is the most incredible peace of garbage-software i have ever seen in 25 years of linux use…
It’s a pity that is an important part of kde now ( i love kde)
LikeLike
I’m afraid I don’t find it very usable either, especially compared to the fantastic Muon. Discover rarely shows the things I want, so I’m always forced to use the terminal against my will. It’s presumably okay for installing updates, but even there it prompts for passwords multiple times in between different backends. I’d use Synaptic if it didn’t require entering passwords just to look things up and if it didn’t keep a lock the entire time.
With Flatpaks I’ve also had a need for something like Muon since there was all manner of (gigantic!) lingering junk which couldn’t be cleaned through Discover, but in the end I resolved that by getting rid of Flatpak since I found it terribly annoying with incessant library duplication and most apps rendered unusable in some manner. But if I did use it, I’d still need to use the command line.
LikeLike
The fact that Discover doesn’t show CLI packages is intentional (it’s an “app store”, not a package manager), but also inapplicable to KDE Linux because it doesn’t include a package manager.
How well Discover works is very much tied to the quality of the app sources it’s connected to. On distros that don’t maintain their PackageKit support very well, it often works quite poorly.
In KDE Linux we mostly don’t have this problem because the primary source of apps is Flathub using Flatpak, which is a data source that works quite well in Discover. Not perfectly, of course; there’s always room for improvement.
What are some of the ways you think it needs improvement in the context of KDE Linux?
LikeLike
KDE Linux is everything I want in my next distro, it’s very close to how I’m running my system already, but I sadly won’t be able to use it 😭
Our whole family backup system is ZFS based (just data, not on root) and ZFS support is very unlikely for obvious reasons.
I’m fine with running Arch directly myself, but there’s no upgrade path for family members currently on KDE Neon (Ubuntu kernel = ZFS support), so I’ll have to switch those devices to a non KDE distro at some point in the future when Neon goes away…
LikeLike
ZFS support will probably be possible to add in the future once we sort out a way to let people use DKMS to add their own kernel modules.
Sounds like a cool setup. Would you be able to comment on why you settled on ZFS, and what advantages you find that it brings over alternative technologies you evaluated?
LikeLike
DKMS support would be amazing ☺️
ZFS replication is the essential feature for me. You send a snapshot over the network once and subsequent transfers only send incremental data.
Very elegant and efficient, and great if you’re bridging multiple households.
I also listened to too much of the 2.5 admins podcast, that’ll make you ZFS curious pretty quickly… 😏
LikeLike
How does KDE Linux compare with Fedora Kinoite?
LikeLike
See https://community.kde.org/KDE_Linux/Background_information#Differences_from_other_immutable_distros
LikeLike
Really great job keeping people informed Nate et al. Thank you.
I’m itching to try/use the alpha.
How are alpha updates handled? To new alpha versions and to beta.
LikeLike
I apologize. Would have been good to read the whole wiki where several update issues are covered, along with other goodies.
LikeLike
There is nothing that KDE Linux does that Fedora Kinoite doesn’t.
The only reason for KDE Linux existing is that KDE wants to distribute their software themselves to avoid picking favourites. Fedora’s distribution of KDE software does nothing different anyway so this means nothing for the user.
And Kinoite is superior. If you need to install hardware drivers or developer tools, you can just layer them on top of the image, in a way that is safe (if something does break, it’ll just cancel the update, it’ll never leave you on an unbootable state).
It’s really weird that KDE chose to develop the underlying system from scratch instead of going with ostree or any of the other proven and tested tools. It just led to an inferior product and wasted development resources.
… I hope KDE backtracks on this the same way Microsoft backtracked on Windows 10 S. KDE’s system takes the immutability concept to such an extreme that it’s an inferior OS as a result.
LikeLike
I’d agree that Kinoite could of been a solid base for KDE Linux
Kinoite has some technical issues though:
However, as we’ve seen with the Universal Blue projects, all these problems can be solved for the user.
LikeLike
KDE development follows the rule of «Who does the work, decides».
Someone wanted to create their own distro, and other people joined.
LikeLike
On Plasma 6.5, I’m forced to install Flatpak, even though I don’t use it. This is not amazing at all.
LikeLike
i had that attitude for years, but eventually i realised that my efforts to control exactly what was installed were costing me far more time than unwanted and unnoticed packages ever had. i switched to slackware and took a liking to the BSDs with their big (for the time) base systems.
LikeLiked by 1 person
Fedora KDE is really great, but it’s not without packaging issues. There has been the attempt to upgrade protobuf for now two years, but it got again postponed to F44. [1]
Protobuf is a dependency for many other packages, that means, those packages are older than on Debian. For an incomplete list, please see the discussion link. Fortunately some apps can be replaced by Flatpaks, but not all. Let’s cross our fingers, that this issue finally gets resolved in the next release.
[1] https://discussion.fedoraproject.org/t/f44-change-proposal-protobuf-5-x-6-x-system-wide/140620
LikeLike
Forgive me for asking the obvious question but what’s the end goal here for KDE Linux? Be a general purpose Linux distribution of KDE/Plasma flavor in opposition to Gnome one?
If these are the plans for both projects then what will happen to other distributions? Will we’ll be slowly heading towards some bipolar homogenization of Linux world?
For quite some time I’m having this weird feeling that Gnome tries to appeal to business world by hands of people within the project who willingly or not are pushing all this simplified approach to the interface. People in various places online are also pointing out that this community acts in a really hostile way towards ordinary users and feedback they’re giving.
So again, what’s your plans? Be another flavor people could pick from or something bigger?
LikeLike
I don’t think KDE Linux is going to kill off Debian, Ubuntu, openSUSE, Fedora, Gentoo, etc. The idea is to provide a more vertically integrated product for those who want that. There’s demand from OEMs and institutions who like what KDE is doing, and a need with KDE neon fading out.
LikeLike
I agree with the point made here. The idea should include the thought about the log term effect of such a project. I fear it will only increase the tribalization/balkanization of the Linux community, i.e. as it can already seen in Wayland.
That desktop environments are sort of neutral towards distributions is good thing for user, distribution and as well the eco-system.
Further there quite many established distributions that are like this or exactly like this.
The description of how this is supposed to work sounds exactly like openSUSE except with KDE instead of GNOME. That base also has established testing in form of openQA.
LikeLike
This isn’t true. I don’t want to be the “Nix/NixOS fanboy” again, but this is exactly the one reason why nix based package management is superior to all the other stuff. In nix: if it works on my machine, you can be sure that it works on other ones too.
LikeLike
Yeah, I was mostly talking about the “traditional” distros that use package managers based on deb/RPM/pacman, etc. I don’t have any experience with Nix, but from what I have seen so far, the technology is as impressive as the user interface to control it is intimidating! 😄
LikeLiked by 1 person
Thanks, I found this both informative and entertaining to read!
I find interesting that you mentioned the Arch base and freeze of the packages. I have some trouble understanding it: would the update cadence be the same as Arch? I wonder this because, for example, the Linux kernel, because I tend to use somewhat older hardware and may not benefit much for the “regular” release. (compared to an LTS kernel, that it’s packaged in the Arch repos, if I am not mistaken). But I totally understand the need to support/test newer hardware!
Another reason I pointed out the cadence, was because of the network usage while downloading a new OS image, because in the wiki it mentions about delta updates not being implemented into KDE Linux update mechanism, at the moment. This is one of my main “concerns” with not using package-based distros. (Full disclosure, I use Linux Mint 😅 so the system updates seems “leaner” and the flatpak updates seems “heavier”, especially runtimes. I do wonder if flatpak/flathubs offer delta updates?)
With that being said, I hope to do a test run of a image-based OS in “real” hardware in a few months.
LikeLike
how big is one image if it includes so many things?
LikeLike
About 5.2 GB. See https://files.kde.org/kde-linux/?C=M;O=D
LikeLiked by 1 person
One of the things I don’t like about linuxes is the “everything is included” concept. I don’t need every language installed. I only speak one, English, so everything else is waste of space. I don’t need ten thousand fonts. I don’t need every single Plasma app.
LikeLike
Well that was clever. I saw the “login to post” note below, so tried to, and waddya know, it posted my half finished post.
To continue, I would prefer at least the option of being able to select what gets installed. I don’t use many programs. Browser, email, office suite, spotify, couple of other bits and pieces but that’s about it. I don’t need five browsers and three email programs and four music players. I don’t need a paint program. Please, let me choose what to install. The alternative is to spend hours getting rid of everything I don’t want, and yes, sometimes deleting things that stop other things that I do want from working.
I’m not particularly technical, I’m more of your bog standard end user. For the record I like Discover. It suits me fine. I will use a GUI, if there is one, over the command line, but happy to use the command line as well. I like flatpaks, they make a lot of sense to me, especially when used in conjunction with an “immutable” distro. I like the idea of an immutable distro and have experimented with a couple. I never found a need to layer anything into the base system though, and don’t really understand why anybody would want to, but I’m assuming there must be important use cases of which I am blissfully unaware. I will use an appimage if there is no flatpak. I won’t use a snap.
Just my two cents worth.
LikeLike
If everything and the kitchen sink is included doesn’t this immensely increase the attack surface as there are many more daemons/programs to target?
I also guess images aren’t updated on every package update so I guess security fixes (if they are declared as such) also only land in batches when the next image is packaged, correct?
LikeLike
The attack surface increases only if those programs and daemons are all running.
LikeLike
Have you thought about doing something similar to Crostini on ChromeOS?
Putting a terminal and a package manager inside of a container could give people the flexibility to install almost any packages they want and even compile packages inside of the container. It would be separate from the rest of the OS, but give power users more than just Flatpak or Snap. And theoretically people could have multiple containers allowing them to run Fedora, Debian or Arch apps at the same time. All while keeping the base system safe and stable.
LikeLike
I don’t think we’ve looked into that approach. It certainly looks interesting.
LikeLike
that sounds similar to UserLAnd on android, though the container there is just a chroot. it has a choice of several distros you can install in the chroot.
i think i’ll be happy with no container, just compiling packages to install to their own dirs in /opt.
LikeLike
“and then there’s package management for assembling the base OS on your own computer.” YES! this. i never figured out how to say it so neatly, but this is what i’ve been thinking and trying to express since maybe 2011. i switched to using plan 9 for all my scripting and fun stuff that year, and soon switched my web & game computer to slackware for this reason. i actually gave up all that for windows in 2017, but i’m ready to come back to linux now, at least for web and games… 🙂
*read read…* huh! i was thinking i didn’t want a desktop environment, but kde connect is very tempting, and it’s always good when a system comes with compilers by default. i always like the little kde games, too. 🙂
and an app store… y’know, it’s been years since i thought about this, but i remember a time when i thought android was doing it right with a big base system and an app store. i still do in principle, but google play is too cluttered and spammy for me now, and f-droid is a special kind of annoying with its anti-feature warnings, listing incompatible apps, and worst of all, opening a pop-up for every single app install or upgrade! lol
LikeLiked by 1 person