Busy months in KDE Linux

It’s been few months since I last blogged about KDE Linux, KDE’s operating system of the future. So I thought it was time to fill people in on recent goings-on! It hasn’t been quiet, that’s for sure:

Project health is looking good

KDE Linux hit its alpha release milestone last September, encompassing basic usability for developers, internal QA people, and technical contributors. Our marketing-speak goal was “The best alpha release you’ve ever used”.

I’d say it’s been a success, with folks in the KDE ecosystem starting to use and contribute to the project. A few months ago, most commits in KDE Linux were made by just 2 or 3 of us; more recently, there’s a healthy diversity of contributors. Check out the last few days of commits:

The next step is working towards a beta release. This is something we can consider the equal of other traditional Linux OSs focused on traditional Linux users: the people who are slightly to fairly technical and computer-literate, but not necessarily developers. Solidly “two-dots-in-computers” users. We’re 62% of the way there as of the time of writing.

First public Q&A and development call

KDE Linux developers held their first public meeting today! The notes can be found here. This is the first of many, and these meetings will of course be open to all.

In this first meeting, devs fielded questions from technical users and discussed a number of open topics, coming to actionable conclusions on several of them. The vibe was really good.

If you want to know when the next meeting will be held, watch this space for a poll!

Delta updates enabled by default

After months of testing by many contributors, we turned on delta updates.

Delta updates increase update speed substantially by calculating the difference between the OS build you have and the one you’re updating to, only downloading that difference, and then applying it like a patch to build the new OS image.

As a result, each OS update should consume closer to 1-2 GB of network bandwidth, down from the 7 GB right now (this is if you’re updating daily; longer intervals between update will result in larger deltas). Still a lot, but now we have a mechanism for reducing the delta between builds even more.

This wonderful system was built by Harald Sitter. Thanks, Harald!

Integrating plasma-setup and plasma-login-manager

KDE Linux now delegates most first-user setup tasks to plasma-setup:

plasma-setup supports the use case of buying a device with KDE Plasma pre-installed where the user is expected to create a user account as part of the initial setup.

Thanks very much to Kristen McWilliam both for not only taking the lead to develop plasma-setup, but also integrating it into KDE Linux!

In addition, KDE Linux now uses plasma-login-manager instead of SDDM. This is a modern login manager intending to integrate more deeply with Plasma for operating systems that want that and use systemd (like KDE Linux does). Development was done primarily by David Edmundson and Oliver Beard, with assistance from Nicolas Fella, Harald Sitter, and Neal Gompa. KDE Linux integration work was done by Thomas Duckworth and Harald Sitter.

KDE Linux has been a superb test-bed for developing and integrating these new Plasma components, and now other operating systems get to benefit from them, too!

Better hardware support

As an operating system built for users bringing their own hardware, KDE Linux is fairly liberal about the drivers and hardware support packages that it includes.

Compared to the initial alpha release last September, the latest builds of KDE Linux include better support for scanners, fancy drawing tablets, Bluetooth file sharing, Android devices, Razer keyboards and mice, Logitech keyboards and mice, fancy many-button mice of all kinds, LVM-formatted disks, exFAT and XFS-formatted disks, audio CDs, Yubikeys, smart cards, virtual cameras (e.g. using your phone as one), USB Wi-Fi dongles with built-in flash storage, certain fancy professional audio devices, and Vulkan support on certain GPUs. Phew, that’s a lot!

Thanks to everyone who reported these issues, and to Hadi Chokr, Akseli Lahtinen, Thomas Duckworth, Fabio Bas, Federico Damián Schonborn, Giuseppe Calà, Andrew Gigena, and others who fixed them!

There’s still more to do. KDE Linux regularly receives bug reports from people saying their devices aren’t supported as well as they could be, or at all — especially older printers, and newer laptops from Apple and Microsoft. No huge surprises here, I guess! But still, it’s a big topic.

Better performance

Thomas Duckworth, Hadi Chokr, and I dug into performance and efficiency, improving the configuration of the kernel and various middleware layers like PulseAudio and PipeWire. Among them include using the Zen kernel, optimizing kernel performance, increasing various internal limits, and optimizing for low-latency audio.

Thanks very much to the CachyOS folks who blazed many of these trails, and whose config files we learned from.

Quieter boot process

Previously, the OS image chooser was shown on every boot. This is good for safety, but a waste of time and an unnecessary exposure of technical details in other cases.

Thomas Duckworth hid the boot menu by default, but made it show up if you mash the spacebar, or if the computer was force-restarted, or restarted normally very quickly after login. These are symptoms of instability; in those cases we show the OS image chooser on the next boot so you can roll back to an older OS version if needed.

Appropriately-set wireless regulatory domain

Different countries have different regulations regarding wireless hardware’s maximum transmit power. If you don’t tell the kernel what country your computer is located in, it will default to the lowest transmit power allowed anywhere in the world! This can reduce your Wi-Fi performance.

Thanks to Thomas Duckworth, KDE Linux now sets the wireless regulatory domain appropriately, looking it up from your time zone, and letting your hardware use all the power it legally can. It updates the value if you change the time zone, too! And also thanks to Neal Gompa for building the tool we integrated into KDE Linux for this.

The idea for this one came from reading CachyOS docs asking users do it manually. Maybe we have something worth copying now!

RAR support

Hadi Chokr added RAR support to our builds of Ark, KDE’s un-archiver. Now you can keep on modding your old games!

“Command not found” handler

I built a simple “command not found” handler that tries its best to steer people in the right direction when they run a command that isn’t available on KDE Linux:

Better Zsh config

KDE Linux now includes a default Zsh config, and it’s been refined over time by multiple people who clearly love their Zsh!

Thank you to Thomas Duckworth, Clément Villemur, and Daniele for this work.

Documentation moved to a more official location

KDE Linux documentation was wiki-based for the past year and a half, and benefited from the sort of organic growth easily possible there. However, it’s now found a more permanent and professional-looking home: https://kde.org/linux/docs.

This will be kept up to date and expanded over time just like the old wiki docs — which now point at the new locations. This work was done by me.

Easy setup for KDE development

KDE developers are a major target audience of KDE Linux. To that end, I wrote some setup tools that make it really easy for people to get started with KDE development. It’s all documented here; basically just run set-up-system-development in a terminal window and you’re ready! The tool will even tell you what to do next.

Saying hello to KCalc, Qrca, Kup, and new CLI tools

KDE Linux includes an intentionally minimal set of GUI apps, leaning on users to discover apps themselves — and if that sucks, we need to fix it. But we decided that a calculator app made sense to include by default. After much hemming and hawing between KCalc and Kalk (it was a tough call!), we eventually settled on KCalc, and now it’s pre-installed.

We’re also now including Qrca, a QR code scanner app. This supports the Network widget’s “scan QR code to connect to network” feature:

Next up is KDE’s Kup backup program for off-device backups! Kup is not nearly as popular as it should be, and I hope more exposure helps to get it additional development attention, too.

Finally, we pre-installed some useful command-line debugging and administration tools, including kdialog, lshw, drm_info, cpupower, turbostat, plocate, fzf, and various Btrfs maintenance tools.

This work was done by me, Ryan Brue, Kristen McWilliam, and Akseli Lahtinen.

Waving goodbye to Snap, Homebrew, Kate, Icon Explorer, Elisa, and iwd

Since the beginning, KDE Linux included Snap as part of an “all of the above” approach to getting software.

Snap works fine (in fact, better than Flatpak in some ways), but came with a big problem for us: It’s only available in the Arch User Repository (AUR). Getting software from AUR isn’t great, and we’ve been moving away from it, with an explicit goal of not using AUR at all by the time we complete our beta release.

Conversations with Arch folks revealed that there was no practical path to moving Snap out of AUR and into Arch Linux’s main repos, and we didn’t fancy building such a large and complex part of the system ourselves. So unfortunately that meant it had to go. We’re now all-in on Flatpak.

Homebrew was another solution for getting software not available in Discover, especially technical software libraries needed for software development. We never pre-installed Homebrew, but we did officially document and recommend it. However the problem of Homebrew-installed packages overriding system libraries was worse than we originally thought; there were reports of crashing and “doesn’t boot” issues not resolvable by rolling back the OS image, because Homebrew installs stuff in your home folder rather than a systemwide location. Accordingly, we’ve removed our recommendation, replacing it with a warning against using Homebrew in our documentation. Use Distrobox until we come up with something more suitable.

Another removal was Kate. Kate is amazing, but we already pre-install KWrite, and the two apps overlap significantly in functionality. Eventually we reasoned that it made sense to only pre-install KWrite as a general text editor and keep Kate as an optional thing for experts who need it.

We also removed Icon Explorer from the base image because developers who need it can now get a Flatpak build of it from Flathub.

Next up was Elisa. Local music library manager apps are not very popular these days, and the pre-installed Haruna app can already play audio files. So out it went, I’m afraid. Anyone who uses it (like I do!) can of course manually install it, no problem.

And finally, the iwd wireless daemon leaves KDE Linux. It was never enabled by default; it was just an option for those who needed it. And the one user who did need it eventually found a better solution to their wireless card issues. With news of Intel dis-investing in iwd, we decided it didn’t have a sunny future in KDE Linux anymore and removed it.

This work was done by me.

And lots more

These are just the larger user-facing changes. Tons of smaller and more technical changes were merged as well. It’s a fairly busy project.

You can use it!

It’s also not a theoretical project; KDE Linux is released and I typed this blog post on it! I’ve developed Plasma on it and run a business on it, too. It’s been my daily driver since last August.

You can probably install KDE Linux on your computer too, and become a part of the future. Even if you’re worried about using alpha software because you’re not a software developer or a mega nerd, it’s perfect for a secondary computer. KDE Linux is quite stable, and the OS rollback functionality reduces risk even more.

You can help build it!

If any of this is exciting, come help us build it! Working on KDE Linux is pretty easy, and there’s lots of support.

Highlights from 2025

It’s been a few years since I did an end-of-year “highlights in KDE” post, but hopefully better late than never! 2025 was a big year for KDE — bigger than me or any of us individually.

My focus these days tends to be on Plasma, so that’s mostly what I’ll be mentioning on the technical side. And as such, everything here is just what I personally noticed, got involved with, or got excited about. Much more was always happening! Additional KDE news is available at https://planet.kde.org.

The Wayland transition nears completion

For several years, Plasma has been transitioning to the newer Wayland display server protocol, and away from the older X11 one. 2025 is when it got real: we announced a formal end to Plasma’s X11 session in early 2027.

To make this transition as seamless as possible for as many people as possible, the people involved with the Plasma shell and especially KWin did a herculean amount of work on improving Wayland support on topics as varied as the following:

Accessibility
Drawing tablets
HDR
Color management
P010 video color
Overlay planes
XRandr emulation
Screen mirroring
Custom screen modes
Implemented support for a large number of protocols, including xdg-toplevel-tag, xdg_toplevel_icon, ext_idle_notifier, color_representation, fifo, xx_pip, pointer_warp, and single_pixel_buffer
Pre-authorization for portal-based permissions
Clipboard and USB portals

Thanks to this and earlier work, most FOSS operating systems (also known as “distributions” or “distros”) that ship Plasma are defaulting to the its Wayland session these days — including big ones like Arch Linux, Debian, and Fedora KDE. Kubuntu is planning to for the next LTS as well. As a result, our (opt-in) telemetry numbers show that 79% of Plasma 6 users are already on Wayland. I expect this number to increase once SteamOS and the next Kubuntu LTS version default to Wayland. So you see, it really is driven by distros!

Now, Plasma’s Wayland support isn’t perfect yet (any more than its X11 support was perfect). In particular, the two remaining major sources of complaints are window position restoring and headless RDP. We’re aware and working on solutions! I can’t make any promises about outcomes, but I can promise effort on these topics.

This admittedly somewhat messy and plodding transition has taken years, and consumed a lot of resources in the process. I’m looking forward to having it in the rearview mirror, and 2026 promises to be the year that enables this to happen! Expect a lot of Wayland work in 2026 to make us ready for the end of the Plasma X11 session in 2027.

Plasma continues to mature and improve

In addition to what I mentioned in the Wayland section, Plasma gained a whole ton of user-facing features and improvements! Among them are:

Rounded bottom window corners
Day/night global theme and wallpaper switching
Saved clipboard items
Speed graph in file transfer notifications
Panel cloning
Per-virtual-desktop custom tiling layouts
“You missed X notifications while in Do Not Disturb mode” feature, and auto DND mode enabling while in a fullscreen app or video
Install hardware drivers in Discover (on supported distros)
New app highlighting in Kickoff
UI overhaul for KMenuEdit and Info Center’s energy page
Playback rate selector in the Media Player widget
Three-finger pinch to zoom
UX and video quality and file size improvements in Spectacle
GPU usage monitoring in System Monitor
Use existing user accounts for RDP/remote desktop
Printer ink level monitoring
Inline print queue viewing in the Printers widget
Only show the screen locker and logout screen UI on one screen, not all of them
OCR in Spectacle (coming in Plasma 6.6)
Monochrome colorblindness filter (coming in Plasma 6.6)
Option for automatic screen brightness on supported hardware (coming in Plasma 6.6)
Option for virtual desktops to only be on the primary screen (coming in Plasma 6.6)

Phew, that’s a lot! And Plasma is getting rave reviews, too. Here are a few:

A decade ago or so, it used to be that Plasma wasn’t seen much as the default option for distros, but that’s changing.

Today Plasma is the default desktop environment in a bunch of the hottest new gaming-focused distros, including Bazzite, CachyOS, Garuda, Nobara, and of course SteamOS on Valve’s gaming devices. Fedora’s Plasma edition was also promoted to co-equal status with the GNOME edition, and Asahi Linux — the single practical option for Linux on newer Macs — only supports KDE Plasma. Parrot Linux recently switched to Plasma by default, too. And Plasma remains the default on old standbys like EndeavourOS, Manjaro, NixOS, OpenMandriva, Slackware and TuxedoOS — which ships on all devices sold by Tuxedo Computers! And looking at the DIY distro space, Plasma is by far Arch users’ preferred desktop environment:

It’s a quiet revolution in how Linux users interact with their computers, and my sense is that it’s gone largely unnoticed. But it happened, so let’s feel good about it!

In fact, if we exclude the distros that showcase their developers’ custom DEs (e.g. COSMIC, ElementaryOS, and Linux Mint), at this point the only significant distros missing here are the enterprise-oriented ones: Debian, RHEL, SLE, Ubuntu, and the like. It’s something for us to work on in 2026, but clearly the current state is already great for a lot of people, including gamers, artists, developers, and general users.

KDE Linux grows

On the subject of operating systems, at Akademy 2024, Harald Sitter revealed the KDE Linux operating system project to the world. But in 2025, it spread its wings and began to soar.

Despite technically still being an Alpha release, I’m using this in-house KDE OS in production on multiple computers (including my daily driver laptop), and a growing number of KDE developers and users are as well. Thanks to its QA and bulletproof rollback functionality, you can update fearlessly and it doesn’t feel like an alpha-quality product. You don’t have to take my word for it; ask Hackaday and DistroWatch!

This project has been very special to me because I believe that KDE needs to take the reins of OS distribution in order to offer a cohesive product. The earlier KDE neon project already broke the ground necessary to make this kind of thing socially possible; now KDE Linux is poised to continue that legacy with a more stable and modern foundation.

To be very clear, none of this is an attempt to kill off other distros. Far from it! In fact, an explicit goal is to showcase what a well-integrated KDE-based OS looks like, so others can take notes and improve their offerings. And there’s still lots and lots of room for specialized distros with different foci, and DIY distros that let people build their own preferred experiences.

I’m really excited to see where this project goes in 2026. You can learn more on the project’s documentation wiki: https://community.kde.org/KDE_Linux

Fundraising performance is completely bonkers

This is the second year that Plasma users have seen a donation request pop-up in December. And it marks the second year where this not only didn’t kill KDE, but resulted in an outpouring of positivity and a massive number of donations! Last year I wondered if it was repeatable. It’s repeatable.

That plus an even more ambitious and well-organized end-of-year fundraiser propelled KDE to its best ever Q4 fundraising sum: nearly €330,000 as of the time of writing! KDE e.V. (the non-profit organization behind KDE) is going to end up with a 2025 income that’s a significant fraction of a million Euros, and mostly crowdsourced, too.

I say this a lot, but sums like this truly help keep KDE independent over the long haul. But how, specifically?

First, by being mostly funded by small donors, KDE retains its independence from any powerful and opinionated companies or individuals that happen to be patrons or donors.

Second, with such a large income in absolute terms, KDE e.V. now has resources to rival the private companies in KDE’s orbit that contribute commercially-funded development to KDE (like mine), and that’s a good thing! It means a healthy diversity of funding sources and career opportunities for KDE developers. It’s systemic resilience.

And finally, with money like this, KDE e.V. is able to fund projects of strategic interest to KDE itself, and fund them well. Historically KDE’s software has been developed by volunteers working on what’s fun, companies funding what supports their income, and some public institutions funding their specific use cases. And that’s great! But it leaves out anything that’s not fun, doesn’t make money, and isn’t directly relevant for governments. These are the kinds of large projects or maintenance efforts that KDE e.V. is now able to fund if necessary.

It’s a big deal, folks! This kind of fundraising performance puts KDE on the map, permanently. And it’s mostly thanks to people like you, dear readers! The average donation is something like €26. KDE is truly powered by the people.

If you can make a donation please do so, because it matters, and goes far!

KDE’s overall trajectory

It’s positive. Really positive.

But when I joined KDE in 2017, the community was a bit dejected. After giving my very first public conference talk at Akademy 2018, multiple people came up to me and said some variant of “thank you for this optimistic vision; I didn’t think I could feel positive about KDE again.”

These reactions were really surprising to me; without the benefit of history, I had no idea what the mood was or how things had been in the recent past. But some statistics about contributor and commit numbers bear out the idea that 2013-2017 was a bit of a low period in KDE’s history, for various reasons.

But since then, KDE has come roaring back, and you see it in positive trends like adoption by hardware vendors and distros, great fundraising performance, good reviews, positive user feedback, and new contributors.

Everything isn’t perfect, of course; there are challenges ahead. Bugs to fix and stability problems to overcome. The Wayland transition and a new theming system to complete. Features to add that unlock Plasma for more users. More effort to put into getting Plasma-powered operating systems and devices into the mainstream.

But the KDE community is up for it. KDE is a mature institution that’s resisting enshittification, and making the world a better place in ways both big and small. My work on KDE represents by far the most meaningful part of my career, and I hope everyone else involved can feel the same way. What we do matters, so let’s go out there and do it even better in 2026!

Techpaladin is looking for a passionate Plasma hacker

Today I’m putting on a different hat and announcing that Techpaladin Software is hiring! Right now we’re looking for a software developer who loves KDE Plasma and wants to see it thrive and shine, with the passion and self-motivation to make that happen.

In this role, you would be working on topics related to KDE Plasma that Techpaladin’s clients want improved, such as general polish and QA, implementing new features, fixing specific bugs, working on private hardware-specific software that supports Plasma, backporting fixes, release management, and so on. It’s always KDE-related!

This is a fully remote contract position open to anyone in the world not living in a country sanctioned by the U.S. government (sorry, it’s just gotta be that way for legal reasons). The start date is flexible and can be whenever you’re ready.

We have no lists of explicit qualifications, minimum years of experience, or formal education requirements. But working for Techpaladin might be a good fit the more this sounds like you:

You’re a KDE contributor. Your profile page on https://invent.kde.org is more blue or purple than it is white, or at least it has been in the past. You’ve used and developed KDE Plasma, or related technologies (Qt, KDE apps and frameworks, C++, QML, etc).
You’re a good communicator. Your “online voice” is gentle, not harsh. You’ve generally got a positive attitude. You keep on top of your email. You can handle working remotely in written and spoken English with a geographically distributed team split across 6 time zones.
You’re a team player. You review other people’s merge requests and triage bug reports. You’re willing to work on what the clients want done. You accept decisions made in public with your input that nonetheless didn’t go your way.

Does this sound a bit like you? We’d love to hear from you at jobs@techpaladinsoftware.com (please don’t send anything clearly written by AI; it will be discarded immediately) with your resumé, KDE Invent profile, links to KDE-related projects you’re proud of, or anything else that seems relevant.

Looking forward to hearing from folks!

KDE Linux deep dive: package management is amazing, which is why we don’t include it

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 thingy to get my thingy instantly? 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.

Main window of the Discover app showing the results of a search for "Photo editing", and more broadly depicting a vastly better way to find and install apps for normal people compared to a command-line package manager — Pictured: a usable way for normal people to find and install apps

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: git and svn
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:

Terminal window depicting the results of trying to run "nslookup" and "hg", both times being referred to an alternative means to achieve the goal

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!

Happy 29th birthday to KDE!

This week marks KDE’s 29th birthday, which is pretty special. Did you know KDE has been around longer than Google, PayPal, Facebook, Instagram, Netflix, Tesla, Spotify, Uber, VMware, LinkedIn, Yelp, and Github? Seriously! That’s a long time producing high quality, autonomy-respecting, non-exploitative software.

And humanity needs and deserves it, so we’re gonna keep going! We’re celebrating KDE’s birthday by kicking off our annual end-of-year fundraiser: https://kde.org/fundraisers/yearend2025/

The money raised here will support the ability of KDE e.V. (the nonprofit behind KDE) to continue hosting Akademy, funding development sprints, affording server hardware and hosting, and employing engineers, marketers, documentation writers, and support personnel (but not board members; we’re unpaid volunteers).

There’s a big set of initiatives, and they’re growing all the time as KDE gains in prominence worldwide! We have extremely ambitious goals of spreading humane software throughout the world.

Looking at the kind messages people have written in their donations, it seems like we’re seeing some success. Here are a few recent examples:

Thanks for KDE Plasma, can’t wait for KDE Linux!!! HB 🎂

To the most consistently feature rich Desktop Environment and just generally awesome set of applications! Thanks for the hard work!

Happy Birthday! Thank you, the Plasma Desktop and the KDE family of applications have made my life so much better. Keep up the good work on the newly-minted KDE Linux.

I’m giving you guys the money that would have gone to Windows 10 ESL had I not switched to Kubuntu earlier this year!

This might sound dumb but the wobbly windows option convinced one of my friends to install Linux so you win

Plasma is the best, very excited for Bigscreen!

KDE’s really great for both enthusiasts and newcomers. Without it, I’d be worried about “the linux desktop” hehe.

Thank you for you great work! One day I’ll find the time to contribute!

I know it’s only the minimum amount, but I love using your DE and software and want to help out any way I can. Thank you!

Thank you for your work and contribution!

Keep up the kood kork!

With love from Spain!! ❤

Keep up the great work!

thank you for a fine desktop 🙂

KDE is my daily driver for personal computing. It’s abundance of features and the distraction-free experience is great. Keep it going! I’ve been an on-and-off user since the KDE 1 Beta 3.

Thank you KDE team for your wonderful work. I use Neon daily and it’s truly a joy to use

Thanks for making the computing world a significantly better place.

Happy Bday, KDE has be rock solid this year!

VIEL ERFOLG von der Alten (84) !! (GOOD LUCK from the old folks (84) !!)

I love your work – thank you for everything! Greetings from Germany 🙂

Hope this helps you keep up the great work!

Thanks for the hard work! Keep it up! From a french user!

To many more birthdays to come.

Great work, KDE!

First time donating. I really love to use KDE.

Thank you, KDE developers & KDE application developers, for 29 years of FOSS-licensed desktop software for Unix.

Grazie mille per tutto quello che fate. Fedora KDE è fantastico!

Thank you for bringing Plasma and Kdenlive to the world. Keep doing what you’re always doing.

Just a small donation for now, more in December 🙂

I dunno why, but I really love what you are doing! I really enjoy KDE’s vibe overall and everything that you guys did!

We’ve set the comparatively modest goal of raising €50,000, and I’m happy to see that we’re already a quarter of the way there after only three days. But we need to keep up the push, as typically the first few days see the most donations. So please donate if you can, and spread the word far and wide!

A Mac-like experience on Linux

In 2016, after being a Mac guy for 23 years, I took the plunge and made a full-time switch to Linux. I did my research, and over and over again encountered the idea that GNOME was good for MacOS refugees like myself. So I gave it a try!

But my experience didn’t support the meme. I think a lot of people make this assertion without really having a deep understanding of the MacOS user experience, or the actual positive qualities of the software, because I don’t think GNOME offers a particularly Mac-like experience at all.

Don’t get me wrong, I think GNOME shell is pretty good, and largely succeeds at doing what it sets out to do. But that thing does not appear to be “offer an experience that’s a lot like MacOS.”

I still see this mentioned on forums and YouTube videos today. I don’t think it’s helpful, and today I want to provide a bit of context from my perspective.

So let’s compare MacOS and GNOME! Right away we see some obvious differences:

MacOS image from https://betawiki.net/wiki/File:25A354-Desktop.png; GNOME 49 image screenshotted by me

Dock

One of the the two major anchoring user interface (UI) elements on MacOS is the dock. It’s an app launcher and switcher, an unread count notifier, a place for minimized windows to go, a quick shortcut to the trash, downloads folder, and any other files or folders you put on it.

GNOME doesn’t have this. Its anchoring UI element is the Activities Overview screen, which contains a small program launcher, but the whole thing is hidden by default, meaning it can’t be easily used for monitoring unread counts or switching between apps. It’s also not customizable at all, while the MacOS dock is extensively customizable. It’s just a very different experience.

Global menubar and app functionality

The other major anchoring UI element is the global menu. Every Mac app exports a global menu structure, including the desktop itself. This allows Mac apps to be visually simple, because all the powerful features are hidden away in the menu structure.

GNOME has a top bar, but there’s no global menu on it. And while GNOME apps do generally have a level of visual simplicity that’s similar to Mac apps, they’re usually more limited in functionality, and they don’t export menu structures full of extra features.

Desktop icons

On MacOS, you can put files and folders on the desktop, and use it for managing frequently or recently used files. Internal and removable drives appear there, too.

GNOME doesn’t have this. The desktop is just a picture; you can’t use it for anything functional.

Window minimize/maximize buttons

On MacOS, if you need to get a window out of your way, you minimize it, just like you do on Windows, Plasma, etc. It flies into the dock and it’s clear how you get it back. You can also maximize a window from another button on the titlebar, and it goes into another.

GNOME apps have neither of these buttons. As a result, it’s not clear how to get a window out of the way or make it bigger without a lot of manual work. You can add those buttons later using the separate Tweaks app, but it’s clear that the system was not designed for it.

At-a-glance app status monitoring

MacOS includes a classic “System Tray” style UI on the top bar holding the global menu. Here apps can put little icons that communicate their state while running but without any visible windows. The MacOS dock also displays unread counts and progress information for running apps.

GNOME doesn’t have these features, either at all, or in a way that’s always visible. Instead, it relies on apps sending notifications about changes to their status.

Configurability

Contrary to popular belief, MacOS is surprisingly rich in personalization options. You can customize the widgets on the desktop or notification center, the text size, highlight colors, sidebar icon sizes, places panel items, screensaver, scrollbar appearance and behavior, lock screen message, menubar positioning, UI alert sound, almost everything about the dock, and so on.

GNOME’s approach to configuration is much more minimal, and the officially-supported options are pretty sparse. Instead, mostly the way you personalize the system is by using Extensions, which can do much more than you can in MacOS, but also offer no long-term compatibility guarantee, so there’s a chance any of the extensions will break with every new release.

So where does the bridge from MacOS lead?

Again, I think GNOME is pretty good… it just doesn’t offer a MacOS-like experience. What it does offer is a near-zero distraction experience. That’s the design goal, and it succeeds. But it’s not MacOS’s design goal.

So if not GNOME, where’s the more MacOS-like experience for refugees? Honestly, KDE Plasma is what I would recommend. It’s where this MacOS refugee ended up, at least. Let’s compare again, but this time with KDE Plasma:

MacOS image from https://betawiki.net/wiki/File:25A354-Desktop.png; Plasma 6.4 image screenshotted by me

Like MacOS, Plasma has a dock-style panel. Despite a few visual differences, it handles the same things: launching apps, switching between apps, seeing apps’ unread counts, and holding minimized windows. This panel also contains the System Tray UI. It’s here rather than on a top panel, but it’s a small difference.

Though neither screenshot shows files on the desktop, both support it. Similarly, both support desktop widgets for building highly personalized workflows.

You can also minimize and maximize windows in Plasma just like you can on MacOS.

And finally, you can personalize a Plasma system in a wide variety of ways — as much or more than you can can on MacOS, in most cases — and all in a 1st-party supported way. There are also GNOME-style extensions available for people who want even more, but these make use of a stable API that only changes about once every 10 years, so compatibility issues are much rarer.

There are still differences, of course: major ones are Plasma’s Windows-start-menu-style Kickoff Application Launcher and the lack of a global menu. But Kickoff can be swapped out for something else or removed, and the Global Menu is actually a fully-supported 1st-party feature, simply being off by default. If this is a part of MacOS that you really like, turning it on is very easy:

Other smaller differences include disks not appearing on the desktop, and maximized windows not going into new virtual desktops.

But in my opinion and experience, these differences are relatively minor, and I don’t think it’s worth chasing the dream of a 100% pixel-for-pixel clone of MacOS on Linux. Rather, I think it’s best to take the most successful parts and ditch the sources of awkwardness. And in my opinion, KDE Plasma fits the bill.

So if you’re leaving MacOS because you found it too distracting, then I think GNOME may be a good option. But if you’re leaving for other reasons, give Plasma a try!

Talk at Akademy 2025 — minding the big picture: opportunity from chaos

At Akademy 2025 this year, I had the privilege of giving a talk about a big picture topic close to my heart, and you can watch it here:

For those who prefer reading over watching and listening, I’ll give a quick summary:

I believe that the challenges facing the world today present an opportunity for KDE to grow in importance and reach due to a variety of favorable trends embedded in the chaos and conflict, including:

Increasing skepticism of traditional proprietary American big tech
Increasing EU public funding opportunities
Windows 11 sucking and losing its edge for gaming
*Postscript: MacOS Tahoe stumbling and being publicly mocked as well

But this is a window of opportunity that I think will close. So I encouraged everyone to think about how we can make KDE software ready for adoption from the following perspectives:

Being known about in the first place
Looking good enough to be taken seriously
Being easy to download or otherwise acquire
Working properly and having enough features
Having enough support resources and an articulable “lower total cost of ownership” story

Because if we’ve got all five, our offerings will start to look irresistible, and I think we’ll gain market share very quickly!

A few corrections about the transition from Blue Systems to Techpaladin

By now, many have probably read Jonathan Riddell’s blog post yesterday about his departure from KDE and the events that led up to it. And today, an article has been published in ItsFoss about the topic that unfortunately seems to have misunderstood some of the details of Jonathan’s post. I didn’t want to have to write this post, but since I’m named personally in both places, and there are inaccuracies spreading out there, I thought it would make sense to correct the record before this becomes too much of a game of telephone.

Overall it’s a very sad situation, and I want to make it clear that I bear no malice or ill will towards Jonathan. As for the internal details of the transition of many of Blue Systems’ personnel to Techpaladin Software, Jonathan is entitled to his interpretation of events, and that’s fair. But it was a delicate transition, and people also have a right to personal and professional privacy. As such, it wouldn’t be appropriate for me to get into anything non-public about individual people’s personal and work situations, motivations, or decisions.

So there are some parts of the story that are going to have to go un-told in public, at least by me. But I can correct the record about misunderstandings and errors, and offer my own perspective!

I’ll start with the ItsFoss article:

First of all, Jonathan never wrote in his post that he saw KDE itself “moving away from the cooperative and transparent model he valued”, or that decision-making was increasingly concentrated under me. Jonathan’s blog post wrote about his relationship with me in the context of the Blue Systems to Techpaladin transition, not about KDE itself. KDE itself is fine — better than fine, really. KDE is thriving, with competitive board elections this year and an increased base of donations it can use to assert a measure of independence from commercial entities.

It’s also not true that Techpaladin was “meant to continue supporting KDE neon after Blue Systems scaled back.” Jonathan didn’t write this, and it was never the case. Techpaladin was and is a vehicle to take over the contract work that Blue Systems had been engaging in, after its manager made the decision to discontinue that work. KDE neon was never a part of this.

There are also a few topics from Jonathan’s original post that need addressing. First of all, Blue Systems is not shutting down. I was just talking to a happy Blue Systems person at Akademy last week. As I mentioned, what actually happened is that Blue Systems divested itself of the consultancy element that it had picked up a few years prior. Blue Systems is still around as a company, and is still employing people who want to work there. Several people opted to stay there rather than moving over to Techpaladin. And at no point was I or Techpaladin ever Jonathan’s employer.

I also want to make it 100% clear that I never made any effort to shut Jonathan out of anything in KDE, never encouraged anyone else to cut off contact with Jonathan or shut him out of anything in KDE, and never pulled strings behind the scenes to make it happen without looking like it was happening. Nothing of the sort! If Jonathan came back to KDE, I would be happy to rebuild a collegial relationship over topics of shared interest.

Finally, regarding company structure and employment details, I went into this a few months ago in https://pointieststick.com/2025/03/10/personal-and-professional-updates-announcing-techpaladin-software/#comment-40233. Techpaladin’s current company structure actually allows people interested in making it more “co-op-like” to buy their way into partnership, which is how Igalia — the “cooperative socialist paradise” that Jonathan mentioned — does this as well. I’m confident that no laws are being broken here; I exhaustively researched the employment laws of 7 countries and then confirmed my conclusions with a lawyer before moving forward with anything. In addition, we practice financial transparency and cooperative decision-making on the topics of hiring, new contracts, etc. So internally it’s quite “co-op like” already.

But this is my first time co-running a company of this size and complexity, so I’m sure I’m making mistakes and can do better. Now that the company has survived the initial setup and been around for 7 months, there’s some breathing room to explore that. But from the start, the whole point has been to put money into the hands of people doing extraordinary KDE work that makes the world a better place, and to provide all of us with more agency over our KDE careers.

Hopefully all of this makes sense. If anyone has any further questions, I’d encourage them to ask publicly or privately, and I’ll do my best to answer what I can that doesn’t compromise anyone’s personal or professional privacy.

Akademy 2025: something big is happening

I’m back from Akademy 2025 in Berlin, and what an experience it was.

At this point, I’ve gotten a reputation as a “big picture guy”, so that’s what I’ll focus on here, rather than the details of my experiences in specific events. Lots of other folks are starting to write blog posts you can find on https://planet.kde.org about their Akademy experiences that I’m sure will be full of juicy details!

But basically, to me this year’s Akademy felt like it had a theme: “KDE is on the cusp of something big.”

Here’s one example: at the very cool C-base hackerspace, I was talking with someone who mused that 15 years ago, Akademy was full of KDE hackers talking about the government one day using our software… and then fast-forward 15 years and our two keynote speakers are from the German government talking about using KDE’s software!

Then we had a talk from the “End of 10” crowd about KDE’s campaign encouraging people to upgrade to Linux rather than buying new hardware capable of running Windows 11. And then as if to reflect on the success of this initiative, Patrick Fitzgerald gave a talk about how to do massive migrations from Windows to Linux, with examples provided of cases where literally thousands of machines were migrated to KDE software at a small fraction of the cost of moving to Windows 11.

Till Adam gave a talk about how commercial work changes relationships with respect to his experience in KDAB, a software consultancy founded by KDE contributors. I found this talk highly relevant given that David Edmundson and I just started a KDE-focused company this year ourselves. Alexandra Betouni also gave a talk about rising to the top of a company. Hmm, lots of companies!

We heard about how Mercedes is rolling out a vehicle powered by KDE technology under the hood.

In the “hallway track”, I had a fascinating discussion about how KDE’s efforts to improve accessibility have the potential to be an industry-wide force multiplier.

And then I gave a talk myself about the big picture of all of these trends — that as the world falls apart around us, everything being on fire includes tremendous opportunities for change that KDE is well-positioned to benefit from.

Basically, at age 29, KDE is all grown up now. Our software solves real problems for real people, at scale. It works for governments and big businesses. It saves or earns money for a lot of people. Our competitors are beginning to falter and look weak. But through it all, KDE remains healthy and strong, and grows in stature.

So I found Akademy 2025 to be an unexpectedly serious conference, full of heavy topics and sharing of priceless wisdom from hard-earned experience. There was of course also a lot of fun hacking and group gatherings and renewing of social bonds, but throughout everything was that underpinning that KDE isn’t just a fun little online community anymore, but rather a player with a growing significance on the world stage.

Pretty cool stuff, I think! Personally, I get energized by working on things that matter, and boy did Akademy 2025 leave me with the impression that KDE matters.

Announcing the Alpha release of KDE Linux

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!