Announcing the Alpha release of KDE Linux

Saturday, 6 September 2025 | Nate Graham

Today I have something very exciting to share: the Alpha release of KDE Linux, KDE’s new operating system!

Many of you may be familiar with KDE Linux already through Harald Sitter‘s 2024 Akademy talk about it (slides; recording), or the Wiki page, or its web page on kde.org.

For everyone else, let me briefly explain: KDE Linux is a new operating system intended for daily driving that showcases Plasma and KDE software in the best light, and makes use of modern technologies.

KDE Linux uses Arch packages as a base, but it’s definitely not an “Arch-based distro!” There’s no package manager, and everything except for the base OS is either compiled from source using KDE’s kde-builder tool, or Flatpak. Sounds weird, huh?! We’ll get to that later.

Harald has been leading the charge to build KDE Linux, assisted by myself, Hadi Chokr, Lasath Fernando, Justin Zobel, and others. We’ve built it up to an Alpha release that’s officially ready for use by QA testers, KDE developers, and very enthusiastic KDE fans.

What’s in the Alpha release?

Today we’re releasing KDE Linux’s Testing Edition. This edition provides unreleased KDE software built from source code; a preview of what will become the next stable release.

In practice, we’re being quite conservative, and it’s already pretty darn stable for daily use. In fact, I’ve had KDE Linux on my home theater PC for about six months, and it’s been on my daily driver laptop for one month. Since then, I’ve done all my KDE development on it, as well as everything else I use a laptop for. It really does work. It’s not a toy or a science experiment.

KDE Linux running on an HTPC, a 2 year-old laptop, and a 10-year old laptop — all pretty much flawlessly

Since KDE Linux offers unreleased, in-progress software, you’ll probably notice some bugs if you use it. Good, that’s the point of the testing edition! Report those bugs so we can fix them before they end up shipping to people using released software.

But where to?

If the bug appears to be caused by KDE Linux’s design or integration, use invent.kde.org. Ignore the scary red banner at the top of the page.
If the bug appears to be in a piece of KDE software itself, like Plasma or Dolphin (such that it would eventually manifest on other operating systems as well), use bugs.kde.org.

So if this is an Alpha release, what’s known to be broken?

Great question. To start with, some things are intentionally unsupported right now; see also https://community.kde.org/KDE_Linux#Non-goals. For example:

Computers with only BIOS support (not UEFI)
Loading new kernel modules at runtime
proprietary drivers for pre-Turing NVIDIA GPUs

There are also quite a few things that need work. You can find specific notable examples at https://community.kde.org/KDE_Linux#Current_state. A few are:

No secure boot
Pre-Turing NVIDIA GPUs require manual setup
Immature QA and testing infrastructure
User experience papercuts in Flatpak KDE apps and updating the system using Discover

We’d love your help getting these and other topics straightened out!

Just what the world needs, another Linux distro…

A sentiment I have in the past expressed myself.

However, there’s a method to our madness. KDE is a huge producer of software. It’s awkward for us to not have our own method of distributing it. Yes, KDE produces source code that others distribute, but we self-distribute our apps on app stores like Flathub and the Snap and Microsoft stores, so I think it’s natural thing for us to have our own platform for doing that distribution too, and that’s an operating system. I think all the major producers of free software desktop environments should have their own OS, and many already do: Linux Mint and ElementaryOS spring to mind, and GNOME is working on one too.

Besides, this matter was settled 10 years ago with the creation of KDE neon, our first bite at the “in-house OS” apple. The sky did not fall; everything was beautiful and nothing hurt.

Speaking of KDE neon, what’s going on with it? Is it canceled? If not, doesn’t this amount to unnecessary duplication?

KDE neon is not canceled. However it has shed most of its developers over the years, which is problematic, and it’s currently being held together by a heroic volunteer. KDE e.V. has been reaching out to stakeholders to see if we can help put in place a continuity or transition plan. No decision has yet been made about its future.

While neon continues to exist, KDE Linux therefore does represent duplication. As for unnecessary? That I’m less sure about that. Harald, myself, and others feel that KDE neon has somewhat reached its limit in terms of what we can do with it. It was a great first product for KDE to distribute our own software and prepare the world for the idea of KDE in that role, and it served admirably for a decade. But technological and conceptual issues limit how far we can continue to develop it.

Time will tell how these two products relate to one another in the future. Nothing is settled.

What are the architecture choices? Why did you build KDE Linux the way you did?

For detailed information about this, see https://community.kde.org/KDE_Linux#Architecture.

We wanted KDE Linux to be super safe by default, providing guardrails and tools for rolling back when there are issues.

For example, KDE Linux preserves the last few OS images on disk, automatically. Get a bad build? Simply roll back to the prior one! It’s as easy as pie too; they show up right there on the boot menu:

It’s like being able to roll back to an older kernel, but for the whole OS.

To make this possible, KDE Linux has an “immutable base OS”, shipped as a single read-only image. Btrfs is the base file system, Wayland is the display server, PipeWire is the sound server, Flatpak gets you apps, and Systemd is the glue to hold everything together.

We also wanted to settle on a specific KDE software development story, with the OS built in the same way we compile our software locally — using kde-builder and flatpak-builder. This should minimize differences between dev setups and user packages that cause un-reproducible bugs (yes, this means we would love for you to use the Flatpak versions of KDE software!). There are genuine benefits for KDE developers here.

If these technologies aren’t your cup of tea, that’s fine. Feel free to ignore KDE Linux and continue using the operating system of your choice. There are plenty of them!

Why an immutable base OS? Isn’t that really limiting?

In some ways, yes. But in other ways, it’s quite freeing.

In my opinion, the traditional model of package management in the FOSS world has been one of our strongest features as well as our most bitter curse. A system made of mutable packages you can swap out at runtime is amazing for flexibility and customization, but terrible for long-term stability. I guarantee that every single person reading these words who’s used a terminal-based package manager has used it to blow up their system at least once. C’mon, admit it, you know it’s true! And in some distros, even using the GUI tools can get you into an unbootable state after an upgrade. If this has never happened to you on a traditional mutable Linux distro… I don’t believe you!

The pitfalls for non-experts are nearly infinite, their consequences can be showstopping, and the recovery procedures usually involve asking an expert for help. No expert around? Back to Windows.

Over the past 30 years, many package-based operating systems have made improvements to their own system-level package management tools to smooth out some of these sharp edges, but the essence of danger remains. It’s inherent in the system.

So in KDE Linux, we take on that risk and do the system-level package management for you, delivering a complete OS all in one piece. If it’s broken, it’s our fault, not yours. And then you’ll roll back to the previous build, yell at us, and we’ll fix it.

By delivering the OS in a complete image-based package, we can perform safe updates by simply swapping out the old OS image for the new one. There’s no risk of a “half-applied update” or “local package conflicts”, or anything like that. It’s also super-fast (once the new OS image is downloaded, that is), unlike the “offline update” system used by PackageKit, where you have to wait minutes on boot following an update. Those issues don’t exist on KDE Linux.

Wait… if the whole system is one piece and you can’t change it, how do you install new software?

Well, only the base OS in /usr is immutable; /etc is writable for making system-level config changes, and your entire home folder is of course yours to do what you want with, including installing software into it. So that’s what you do: use Discover to get software, mostly from Flathub at this point in time, but Snap is also technically supported and you can use snap in a terminal window (support in Discover may arrive later).

That’s fine for apps in Flathub and the Snap Store, but what about software not available there? What about CLI tools and development libraries?

Containers offer a modern approach: essentially you download a tiny tiny Linux-based OS into a container, and then you can install whatever that OS’s own package management system provides into the container. KDE Linux ships with support for Distrobox and Toolbx.

That’s right, after trashing package management, now I’m endorsing package management! The difference? This is user-level packaging and not system-level packaging. System-level packaging is what’s dangerous. Take away the danger by doing it in your home folder, and you regain almost all of the benefits, with almost none of the risks.

AppImage apps work too.

Homebrew also works; it’s an add-on system-level package manager that allows you to download tons of stuff you might want for power user and development purposes. Note that Homebrew packages are not segregated, so they can override system libraries and present problems. This should be considered an experts’ tool.

Compiling anything you want from source code is also possible — provided the dependencies are available, and Homebrew or containers can be used for this.

Finally, there’s nothing stopping folks from making command-line tools available via Flathub or another 3rd-party Flatpak repository. Some are already there. So this could be a potential avenue of improvement too.

But as you can see, the story here is fragmented, with a menu of imperfect options rather than a single unified approach. That’s a valid critique, and it’s something that needs more work if we want an obvious default choice here.

For more information about this topic, see https://community.kde.org/KDE_Linux#Installing_software_not_available_in_Discover

That’s not enough power! I want to change the base OS!

Actually I lied. There’s another option for developers and super power users, one that does allow intermingling stuff: you can use systemd-sysext to overlay files of your choice on top of the base OS.

It’s a really cool tool you might not be aware of. I’ve started using it in KDE Linux to overlay my built-from-source KDE software on top of the base system for development and testing purposes, and it’s just been a super great experience. Way better than compiling stuff to a prefix in $HOME. No more weird random DBus and Polkit failures or stale file conflicts.

Now, this is quite a bit riskier as you can destabilize the OS itself by overlaying broken parts on top of working parts. But undoing any such changes is super simple, since, again, it’s all self-contained. That’s gonna be a common theme here.

However, I think the better answer for “I want to change the base OS” is “please get involved with developing KDE Linux!” That way if your changes are amazing, the whole world can benefit from them, and the burden of maintaining them over time can be shared with others.

Still not enough power! I need to be able to swap out kernel modules and base packages at runtime!

Wow, you really are sounding like an OS developer. Maybe you want to help us develop KDE Linux? The OS could benefit tremendously from your skills and experience!

That said, there’s some truth to the idea that an immutable OS like KDE Linux isn’t the best choice for doing this kind of really low-level development or system optimization. That’s fine; there are hundreds of other traditional Linux-based operating systems out there that can serve this purpose.

If your goal really is to build your own OS for your own personal or commercial purposes, it’s hard to go wrong with Arch Linux; it’s one of the tools we used to build KDE Linux, in fact. In a lot of ways it’s more of an OS building toolkit than it is an OS itself.

If it’s all Flatpak and containers and stuff, does it really showcase Plasma and KDE software in the best light? Really?

Well, we’re kind of cheating a bit here. A couple KDE apps are shipped as Flatpaks, and the rest you download using Discover will be Flatpack’d as well, but we do ship Dolphin, Konsole, Ark, Spectacle, Discover, Info Center, System Settings, and some other System-level apps on the base image, rather than as Flatpaks.

The truth is, Flatpak is currently a pretty poor technology for system-level apps that want deep integration with the base system. We tried Dolphin and Konsole as Flatpaks for a while, but the user experience was just terrible.

So for the Alpha release, these apps are on the base OS where they can properly integrate with the rest of the system. There’s no reason to torture people with issues that we know won’t be fixed anytime soon!

Other apps not needing as as deep a level of system integration are fine as Flatpaks right now, and we’re engaging with Flatpak folks to see how we can push the technology forward to work better for the deep integration use cases.

This is because one of KDE Linux’s other goals is to be a test-bed for bringing new technologies to KDE. Our software that behaves awkwardly when sandboxed or run on a filesystem other than Ext4 represents something for us to fix, because those technologies aren’t going away. We need to be embracing that future, not ignoring it. KDE Linux both helps and forces us to do it.

This should be exciting. New technology is fun! You get to help guide the future. Let’s not get caught up yelling at clouds here!

I’m a KDE developer. Why should I migrate to KDE Linux, and how does KDE development work?

Easy setup, speed, safety, DBus and Polkit finally work properly, space savings, consistent platform targets, and more. There’s a lot to like. See also https://kde.org/linux/#im-a-kde-developer-why-should-i-use-kde-linux-and-how-does-kde-development-work

Forget the haters, this project is cool! How can I help?

Great! For starters, install it on your computers. We’re looking to get more feedback from daily drivers. The Matrix room is a great place to get in touch with us.

You can help out with some of the tasks and projects mentioned at https://community.kde.org/KDE_Linux#Current_state. Those are high priority. And lots more easier, lower-priority tasks can be found here. You can submit Issues or Merge Requests on invent.kde.org.

And finally, help spread the news! If you couldn’t tell, I’m really excited about this project, and I think a lot of other folks will be as well… once they hear about it!