Announcing the Alpha release of KDE Linux

World Domination 11 Minutes

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.

See also https://community.kde.org/KDE_Linux#Differences_from_KDE_neon/Prior_art

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.

See also https://kde.org/linux/#this-is-so-cool-how-can-i-get-involved-with-development

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!

Unknown's avatar

Published by Nate

Published

50 thoughts on “Announcing the Alpha release of KDE Linux”

  1. Flatpak disables a namespace-based sandbox layer in Firefox that normally isolates tabs, which weakens the security barrier. Chromium-based browsers use workarounds within Flatpak for sandboxing, but these are not as mature as the native implementations. Flatpak protects the host system well from the app, but the internal browser sandbox is less effective. Or is that no longer the case?

    Like

    Reply

    1. To my knowledge, this “double sandbox” situation is still a known issue for browsers. That said, all of them are still sandboxed somehow.

      Like

    2. AI:
      “Given KDE Linux’s Flatpak-first/immutable approach, the usual advice (“install the browser natively for the strongest renderer/tab sandbox”) isn’t really available. That keeps the known trade-off in place: Flatpak gives excellent app→host isolation, but browsers inside Flatpak typically lose the user-namespace layer of their internal sandbox, so intra-browser isolation isn’t as strong as upstream native builds.

      A reasonable path forward would be a browser exception:

      Offer an opt-in native browser (layered package/system extension or an official upstream tarball wrapper) with auto-updates, SELinux/AppArmor, and Wayland by default.
      In parallel, work with Flatpak/bubblewrap to see if nested user namespaces or an equivalent renderer isolation model can be safely enabled for the browser Flatpaks.
      In the meantime: prefer Wayland, don’t grant broad Flatpak permissions (no full home FS), and you can verify the current state via about:support (Firefox) or chrome://sandbox (Chromium).”

      Like

  2. My first Linux steps began on KDE. I don’t think that anyone will remember Caldera OpenLinux 2.3 with KDE 2.x. As a former Windows user I loved KDE from the first time. Later Kubuntu 10.04 (Lucid Lynx) became my daily driver. Only in some VMs I have others DEs than KDE.

    The concept of an immutable OS sounds very interesting and I will give it a try in a VM for sure. But why the hell with FlatPak? I’m not using this or Snap either. On my machines I use many apps and I fear the disk space wasted by this.

    The last couple of years I’m on Manjaro with KDE and I love it. I never had any great issues with the Arch base. They plan an immutable variant too. This will be all very interesting…

    Like

    Reply

    1. On an “immutable base OS” distro, you need some way to get apps. Flatpak is a technology that works for this, and it’s got more supporters and contributors within KDE compared to Snap, so that’s why we chose it as the primary solution.

      The disk space usage is fairly minimal, about 1.8 GB per OS image. There are experiments de-duplicating by using the libraries in the Flatpak runtimes for Plasma and other software shipped on the base OS. Even then, it likely wouldn’t result in a full 1.8 GB of space savings, as there are some things in the FreeDesktop and KDE runtimes that aren’t duplicated, so we’d still need them anyway.

      Like

  3. Cool project! As a KDE Neon user, I’m mostly worried about theming and customizability. My trouble with FlatPack, besides taking up much space and often not working well together with the rest of the system, is that theming and special system settings doesn’t work well with it at all. I really like customizing my Linux system and using theming engines like Kvantum or QtCurve is something I enjoy as well as giving me a system that feels good to work with. It also comes with an important accessability issue since high-contrast themes are important for many users. Do you have any plans to adress this? Will I be able to use the beautiful Kvantum themes on KDE Linux? 😀

    Like

    Reply

    1. The customizability that Plasma already provides with respect to Plasma theming, color scheme theming, etc. is already fully supported, so anything that doesn’t work right is a bug.

      KDE Linux doesn’t currently support getting new themes that require installing binary plug-ins, which will exclude Kvantum and other 3rd-party QStyles. You can probably make it work anyway, but you’ll be in “there be dragons” territory.

      Over the medium to long term, the new Union theming system should replace the need for these, and overall offer a better theming experience because theme files will be simple CSS files and also be much more broadly applicable to more parts of the system.

      Like

    2. i use Fedora and the first what i make is deactivating flatpack because the mix of package format in a Distribution is in my opinion b.s. i stay fully behind you Daniel ! And as multidistro package is in my opinion appimage, this woks as own pack and don’t install/mix up in the system and is so far portable…

      best

      blacky

      p.s. in your icontheme manager, search for blacky or “kry” , Happy Modding 😉

      Like

    3. Hi Nate,
      could you check the Theme-manager-downloader, the window’s where let caching the themes out of store.kde.org or pling.com, there is not a correct caching if i scroll down, stopps the chaching and i cant scrolling more down, because the cachesystem is imo broken … the other, the Icon-theme-downloader-windows, exist an filter into the themebrowsing-manager ? because, if i filter for “blacky” become i mostly all of my iconthemes, but not krystalsvg, except if i type in “kry” then become i the krystalsvg to see .. but all be market with “blacky” too.. just as info..but more important is, the theme-browsing-manager works in caching not pretty well, this should be check … it opened only 4-6 themes and recaching not really .. so reload the other themes for exploring the themes.. and that’s a bit bad ..

      best
      Blacky

      Like

  4. “…We need to be embracing that future, not ignoring it. KDE Linux both helps and forces us to do it.” […]

    Please integrate support for modern authentication processes like FIDO2/Webauthn and Hardware keys for login, LUKS, gocryptfs etc. into KDE Linux.

    Like

    Reply

  6. I completely endorse this approach, I have used it for ~2 years and I wrote a bachelor degree thesis on it: this can finally make Linux mainstream.

    But the real question is: we had this for years thanks to Fedora, OSTree, now Bootc and ComposeFS. Why didn’t you build on top of it?

    Everything mentioned here is already implemented in uBlue Aurora (except systemd-boot). uBlue Bazzite is featured on many mainstream gaming channels. Many are replacing SteamOS on their Steam Deck with Bazzite. On Aurora and Bazzite drivers aren’t a issue, not even the Nvidia ones. Secure boot supported.

    With Bootc we can reuse all of the tooling and infrastructure from containers: registries, CI, image building tools etc. We can derive one image from another just like with containers images and there is a project (EU OS) to take advantage of the whole approach and this derivation mechanism in particular in the public sector. We can also already layer on top of /usr just like with systemd-sysext.

    With ComposeFS we get the same deduplication that OSTree provides to Flatpak and Git to source code. ComposeFS can also provide integrity using fs-verity, allowing cryptographically sealed devices while still using files instead of images.

    Podman also has experimental support for ComposeFS and in the future the same object storage could be shared between the host system and the containers. ComposeFS itself enables higher density containers with its deduplication mechanism that works both on disk and on RAM, so it will be adopted and supported by the industry because of the containers use case.

    There must be reasons for not using Bootc and ComposeFS… maybe because Bootc only supoort Fedora, CentOS, Alma and RHEL? People are trying to port Bootc to Debian based distros and Arch too. Bootc is designed to be distro-agnostic.

    Maybe you don’t like that uBlue uses GitHub Actions? You don’t need to copy them, it’s just standard OCI images, you can use any CI.

    I am genuinely curious about what are the arguments against Bootc, ComposeFS and uBlue Aurora/Bazzite.

    Liked by 1 person

    Reply

    1. These are deep questions, and it’s clear you really know your stuff. Definitely more than me! I do promotion, project management, and small UX polishing for KDE Linux; I’m definitely not a tech lead who can answer these kinds of questions. I might recommend asking them in the project’s Matrix room where they might find smarter ears and spark a conversation.

      Like

  7. I can’t say I’m particularly excited (or at all) about something like this and immutable distros as a whole, but good luck with it.

    Like

    Reply

  8. I moved away from Bazzite at one point because they insisted on making Wine not layerable because according to them “it could break things”. Basically it was impossible to update the system if it was layered… would something like that happen with KDE Linux?

    How much limited would the user be? Was ever a non-immutable version ever considered?

    Like

    Reply

    1. A feature of KDE Linux is that it’s always updateable; there are no “local file or package conflicts” that can render the system unable to update. That’s one of the advantage of the immutable /usr and getting packages from Flatpak. To my knowledge WINE is available as a Flatpak from Flathub, so that would be the supported way to get it on KDE Linux.

      Like

    1. We make use of a number of Btrfs features already, and plan to leverage even more in the future. Ultimately this project is intended for people who are comfortable leaving technical details like filesystem formats up their OS builder. If that’s you, a general purpose package-based OS may be the better choice.

      Like

  10. A feature of KDE Linux is that it’s always updateable; there are no “local file or package conflicts” that can render the system unable to update. That’s one of the advantage of the immutable /usr and getting packages from Flatpak. To my knowledge WINE is available as a Flatpak from Flathub, so that would be the supported way to get it on KDE Linux.

    Thanks for the reply Nate.

    In my case, back when I used Bazzite, I had it installed as a system package because I ran into issues with the Flatpak version (and was an easy decision to make because I’m not a fan of Flatpaks). Based in your comment, I’m assuming that KDE Linux wouldn’t have an issue with this nor it’ll complain about it when updating, which is great.

    Will definitely keep an eye on it, maybe oncee it gets a stable release I’ll try and hopefully, my questionable experience with Bazzite in that regard will be erased from my memory 😄

    Like

    Reply

    1. You’re welcome. I think your reply highlights a challenge we have a lot of in our ecosystem: “I had a problem, so I found a workaround for it.” And that’s great for you, but later the next person will run into it, and apparently your workaround caused you other issues, too! This is so common. Something we have to start retraining ourselves to do is report issues to the source, and even help get them fixed. Ultimately we all want to use software that doesn’t have avoidable issues, and we can be a part of the solution to get there!

      Like

  11. Trying to install KDE Linux Alpha release and everything goes well, but it doesn’t create any UEFI entry so after reboot I cannot boot to the newly installed system. What I’m doing wrong?
    (additional info: there is another Linux system on the same SSD)

    Like

    Reply

    2. No, I’m using 202509031309 and 202509060254, both doesn’t create UEFI entry as if it wasn’t installed at all. But KDE partition manager from second OS “sees” the newly installed KDE Linux.

      Like

  12. It would be nice if there was a way to just download what package you want, then run the package file (which could contain a signature and such required to verify it), like Windows has. One thing I hate about Flatpak is that it is hopeless at dealing with CLI apps, the “sandbox” is often too constrained and isolated, and you quickly find yourself downloading 100 different versions of GPU libraries, desktop runtime environments, and literally copies of large chunks of the OS, just to run simple applications.

    I hope KDE Linux can figure out a way around those problems in Flatpak. I think Fedora has their own repository for Silverblue and Kinoite, maybe some inspiration from them?

    Like

    Reply

    1. And there’s always the old argument “oh i would rather not download random executables, better to download from the top-notch curated central repository where apps are checked, screened, scanned, tested in the lab, and vetted and found to be bug free and totally not cybersecurity nightmares.” – I would argue that it doesn’t matter, even the central repository can bungle sometimes, and dare I say more than a package file from somewhere else.

      Like

  13. The overall direction is kinda right I guess. But sometimes people have quite unexpected demands. Like I need a dkms module for apfs in order to read files from an external drive with a test Hackintosh system, or my relative has a laptop with Broadcom WiFi chip hence another dkms module is needed. Or a person decides to lockdown his OS and firmware using LUKS plus custom SecureBoot certificates, or what if someone needs fscrypt based encryption which is impossible on btrfs, etc, etc.

    But for an average Joe such a distro could be a good choice I suppose.

    Like

    Reply

  14. This sounds great. Thank you a lot for your effort!

    Haven’t tried any immutable distro yet and am very sattisfied with debian 13 at the moment but if I ever try anything immutable this will for sure the one.

    Wish you success very much success.

    Like

    Reply

  15. It looks beautiful and promising, and even my annoying MIPI webcam works out of the box. 😀 I like the idea and keep my fingers crossed for KDE Linux!

    Liked by 1 person

    Reply

    1. That’s great! I’m really happy to hear it, because I tried KDE Linux on a laptop with another annoying MIPI camera, and it wasn’t recognized. Good to know it’s not a general problem with that whole class of device.

      Like

  16. While I think that immutable is the way to go, I wonder why someone tries to do this in 2025 with multiple (somewhat complex) techniques like Btrfs, Arch and Flatpak layered on top of each other when something that is way more pretictable exists: nix and NixOS. Even development setups are “easier” in the nix world, because each dependency can be pinned to the exact same version, which makes sharing development setups between developers a lot less error prone.

    But iI’ll keep a look at KDE Linux and will see what the future brings…

    Like

    Reply

    1. The Nix package manager is installable on KDE Linux for those who want to use it as their method of getting additional software. However I’m not sure if it makes sense to go all in on it. It’s quite complex, and I’m sure there would be integration challenges. Although admittedly, I haven’t looked into it in detail.

      Like

  17. Meh, I am not sure if it is just that I don’t get who the target audience is or this is technology is not really ready for that audience yet… Until there is an easy way for a normal user to install a deb/rpm package in some layer, immutable distros are not really ready for wide-spread usage.

    There are still so many 3rd party packages that are only available for Ubuntu, or in some cases RedHat/Fedora, but not as AppImage, Flatpak or snap, which is shitty anyway.

    Here are just some examples of the apps, that I had to install in the past few months and are primarily distributed by deb packages. WPS office, Tencent Wemeet, Weixin (Wechat) desktop client, DingTalk by Alibaba. Another example is Yandex Browser, which is popular in Russia, which ships only debs and rpms. This kind of apps is often also not open source, so often you can’t just repack it let alone distribute it yourself. While these apps might not be so well known in the west, they actually have millions of users as these countries try to develop national alternatives for Microsoft/Apple ecosystem and will mandate Linux support from main software providers. This can also be observed in Europe to a smaller extent. Many e-signature plugins for government services, such as proxsign by setcce in Slovenia, also do not or did not support AppImage in the past and only shipped deb for latest version of Ubuntu LTS.

    Preinstalling Distrobox is a good first step, but you can’t really expect that people will first configure distrobox, figure out how to enter it, then install app in it, and possibly debug why the window don’t show up or why it doesn’t see some files, other apps (that are installed in another container)…

    This should be done seamlessly, and preconfigured environments should be included for the most popular distros that 3rd party deb packages target (last couple of Ubuntu LTS versions, Fedora).

    Alternatively, deb packages could be converted to one of the supported app containers in the background whenever user tries to install it by discover. This could possibly be achieved by a proper integration of AppImageCommunity/pkg2appimage.

    Like

    Reply

    1. Apps being available for only specific distros is a problem, right? That’s what both Flatpak and Snap solve, and it’s why we’re going all in there.

      Like

  18. From a technology point of view this seems interesting and I can fully understand people investing time in developing it.

    From a user point of view I’m not so happy. I’m a KDE neon user and use it at work. Many closed source tools, which, if you like or not, are distributed only as dep or rpm. Most such software is developed to run on Ubuntu and maybe also RHEL. So many people have simply NO choice.

    I like my neon system: I have a Ubuntu base system where I can install all the tools, which sometimes I don’t want to install but have to due to work. And I can still enjoy the latest KDE technology which I really appreciate.

    So my hope is KDE neon is not dying because of this new project and will serve people like me for a long time.

    Like

    Reply

    1. Your concern is understandable.

      I wouldn’t say KDE neon is dying because of this project. The reasons for its decline (maybe “dying” is too strong a word at this point in time) are complex, but they predate KDE Linux. If anything, the causality goes in the other direction.

      Like

  19. I haven’t been hyped about anything for at least 10 years…but I think I’m really kinda hyped.

    KDE, and then this post showing all the right vectors.

    Many comments about issues in the current state of the surrounding technologies for this direction, but with KDE as a supporting motor I feel these can develop and mature real fast and healthy, and become what it should be.

    Without ever being a developer, it points on so many things I’ve had issues with regarding Linux without the deep digging knowledge to explain why, more of a “tech-intuition”.

    If one considers 1,8gb is too much for an application due to the current state of sandboxing it (like another commenter mention), when a 1tb M2.SSD is $50 and 24tb HDD is $300, there’s thousands of distros that service that. Use one of those for your 32gb HDD computer from 2005. Bulk of people download or stream 50gb just to see a 90minute of 4K today. Let specialized usecases be specialized. There’s zero reason for every linux distro to have the oldest, weakest, or most obscure usecase in mind when created, to the suffering of everyone else. That’s what the linux core is for to build upon for that fit. Not every-distro.
    Efficiency and minimalism is great and all, but have become too much of a mantra in the linux world. 99% of all linux distros are already 99% better than e.g. Windows that 99% uses as desktops. The obsession of being 99,1% is WAY out of proportion compared to the actual need for most anyone.
    It really is time to focus on some of the other branches, like usability, stability, and safety, when it comes to desktops*, where it’s far behind compared to its efficiency.
    *It has taken big steps there as well, where a big portion is thanks to KDE in my opinion. But the minimalist efficiency crowd seems to hinder Linux development with shame based in mainstream and elitism at the same time, like they think they won’t be able to compile linux from scratch and exactly like they want it just because there’s other distros out there with a different mantra.

    I’m happy with all the choices made, and the implied big picture goal. It’s well needed, especially with likes of KDE in the back. I see a positive future.

    Liked by 1 person

    Reply

    1. I’ve been pleased by how many people see the big picture here, and clearly you’re one of them!

      You’ve got it right except for one thing: Flatpak apps are waaaaaaay smaller then your example would suggest. Flatpak apps themselves are mostly very small, under 25 MB. A very small number of huge apps like Chrome and Thunderbird might be 400 MB; these are apps you’ll have 1 or 2 of on your system. What’s larger are the shared runtimes used by apps; each of these is about 300 MB, and you’ll probably have several. But they’re shared. In practice, a system using Flatpak for as much as possible will probably consume an extra 1-5 GB over a system where everything is made of granular mutable packages. In KDE Linux, the space overhead of Flatpak is 1.9 GB right now.

      And that’s only because there is content duplication between Flatpak and the base system; our aspiration is to make the base system even smaller by putting more KDE software in Flatpak and pulling more libraries from it. In this case, I expect we’ll be able to shrink the “overhead” down to below 1 GB. Possibly closer to zero (asymptotically, I imagine).

      Like

    2. Even for old devices,

      I’ve installed it on a 10 old PC with a 3rd gen i7 processor, and even as an alpha, it’s a smoother experience than a 3-year-old laptop with stable Windows 11

      Liked by 1 person

  20. Very cool initiative; I do think the tooling for composing your own distributions is reaching awesome heights, and there is room for someone to sweep the board with a modern immutable OS.I think Distrobox would satisfy the needs of (what will be) a vocal subset of your prospective users; people who want to manage/mangle their own distributions. With Distrobox you can give them back this power, and when they screw the pooch they will be destroying a containerized Linux (one of as many as they want) instead of the machines primary OS which basically always needs to be functional.

    Lots of complex problems still to solve, but good show getting this out the gates. I wish you people the best.

    Like

    Reply

  21. Where in all this does KaOS Linux sit? They claim to be the clean KDE Plasma distro yet it never really took off for some reason and you never mention it either.

    Like

    Reply

    3. I knew it existed, but I don’t know much more about it than that. I can’t know everything! 😀 In the end there are only so many hours in a day.

      Like

  22. That looks very promising. I have a quick question: I use (Arch) Linux on a Tuxedo notebook with dkms kernel module drivers, among other things. How would that work under KDE Linux?

    Like

    Reply

Leave a reply to mdatab Cancel reply