I know this isn’t something easy to do and Plasma 6 definitely needs to come first, but now that so much progress has been done on Plasma, I find one big thing that holds KDE back is the lack of a stable beginner-friendly Distro where KDE comes first.
What I think would be really helpful would basically boil down to a distro similar to Linux Mint but focusing around KDE
To me this would consist of:
A stable debian base
New KDE versions available whenever Version .2 or .3 of plasma hits (similar as Fedora does it)
To me, this would provide the best out of both worlds. A really stable and reliable base and also a fresh KDE experience. I think the .0 versions of releases should not be included as they tend to have some bugs which is not a welcoming experience for new users, who just want a working system. Still, you would reliably get all bug fixes and nice improvements within a reasonable time and be able to showcase all the newest and freshest niceness of KDE.
Currently, you only get a choice between old Plasma versions or bleeding edge. We have KDE Neon which is a bit similar but just too bleeding edge and development focused to be welcoming for new users, Kubuntu which is hidden behind Ubuntu and also needs backports to have newer KDE versions (Also LTS versions often times don’t work with backports and interim releases are not as stable)
If somebody new to the linux world would ask me which distro to recommend I would love to show them a KDE distro as it’s the best DE IMO, but currently, I just would not feel comfortable to recommend any of the available distros to a beginner so I would probably point them to Linux Mint. A distro like this would also not only cater to beginners but power users who just want a stable base system but love KDE (who probably use Debian currently)
This is the same process used by Manjaro stable branch, they always wait for 2nd or 3rd maintenance release (sometimes more like what happened with Plasma5.25) before pushing KDE, GNOME or XFCE desktops to stable branch. But security upgrades are directly pushed to all branches.
While Unstable branch (which I’m using) is directly synced to Arch stable repo, and Testing branch is the middle testing ground between the two branches.
One thing I advise you: Never approach Arch guys on their forum or bug tracker while saying you use Manjaro, they will curse you and close all your opened tickets and posts.
You’re describing KDE Neon: it has a stable base with KDE packages overlaid on top.
Unfortunately in my experience the result of such a combination isn’t ideal, for a variety of hard-to-fix reasons:
Mixing new KDE packages with the stable base makes the stable base unstable because oftentimes the KDE parts require newer libraries than what the base has or even libraries that the base doesn’t have at all. Adding or upgrading such libraries has a tendency to break stuff in unpleasant and subtle ways. It requires a vast amount of QA to prevent regressions.
All the non-KDE apps from the stable base are old, which isn’t generally what users want. Neon tries to solve this by hiding them in Discover and only letting you use Discover to get apps from Snap and Flatpak (where they’re newer), but people can still use the CLI package manager to get the old apps and this can cause dependency conflicts and blow up the system, and also the user is using something old that’s not supported by anyone (not the app developer and not the distro either).
Since the libraries on the stable base are old, they’re not suitable for doing development work unless you’re deliberately targeting old library versions. This is not the case for developing KDE software, so the distro can’t be easily used by KDE’s own core contributors for their development needs, which means fewer eyeballs on it and worse testing, less development, etc.
This approach can work better if the stable base is made immutable so users are forced to get their apps from Snap or Flatpak, and any newer library versions have to be overlaid on top of the base with some kind of containerization or overlayFS technology; then upgrading to newer libraries can’t break the base OS.
But if you do this, what value is the base OS even providing anymore? Other than booting up, very little.
IMO the only practical option is a rolling or semi-rolling distro that ships updates quickly. This release schedule matches the fairly rapid pace of releases for KDE software itself.
If you want the latest and greatest KDE, then you have no choice as Nate says, but to run the latest and greatest base under it. Tumbleweed is what I go with, but Arch is good too. I find Tumbleweed to be a bit more solid. The YAST installer can be a huge hurdle for some, but if you take your time with it, it will do amazing things.
Please don’t use the Arch forum or bug tracker if you are not using Arch. They make it very clear that this is not wanted. You might disagree with this but please respect their decision, even if you dislike it. They have their reasons.
Use the forum/bug tracker of your arch based Distro instead.
On Topic: Imho rolling distros have been much more easy/stable for me. I admit I haven’t tried non-rolling in years, maybe they have gotten better?
IMO the closest compromises here are Kubuntu and Fedora KDE Spin. I personally have more experience with Kubuntu, so I’ll just say that if you use the non-LTS track, so 23.10 currently, and add the Kubuntu Backports PPA, then you get:
A base that is reasonably recent (at least no less up-to-date than the latest Ubuntu, which a ton of folks are going to be running FWIW)
Reasonably up-to-date KDE (it’s not full rolling speed or anything, but the Kubuntu team keeps that PPA pretty recent)
Six months of general distro feature freeze (a.k.a. “stability” in Debian-speak, although I always feel compelled to point out that usually means you’re stuck with bugs for a while that often get fixed upstream much more timely)
Personally I’d choose Tumbleweed for an up-to-date KDE experience, but I can understand the allure of not needing constant version updates of everything.
I agree that non-LTS Kubuntu and Fedora KDE are good compromises for those who don’t want a true rolling release distro. I generally recommend non-LTS Kubuntu to normal people and Fedora KDE to enthusiasts who don’t want a full rolling release distro or a the DIY Arch experience.
But Kubuntu often has quite old KDE stuff due to the Ubuntu base OS’s policy regarding updating Qt (or rather, not updating it) which can delay Plasma updates from the PPA until the next release that does ship a newer Qt. It’s unfortunately chafing against the base OS’s neglect and disinterest of the Qt world that’s quite important to us.
Imho rolling distros have been much more easy/stable for me.
I have my Manjaro KDE running for 3.5years without needing any reinstall, I even jumped to unstable branch, and truthfully feel so happy about the experience, I will never return to that Ubuntu based locked release model and that hell of ppas.
I do think TUXEDO OS is pretty much exactly what I am looking for, my main concern being that it’s not community driven and it’s continuity is dependent on the success of the (rather small) company Tuxedo computers. Though this is not unlike some other distros like Pop OS. But the apparent lack of a community is quite a disadvantage to me.
I do see that I might underestimate the complexity and drawbacks of such approach as Nate has pointed out. At the same time I wonder how TUXEDO OS seems to be achieving an mixed approach like this, though I can’t tell whether the mentioned problems like dependency conflict might be something that you will encounter using it.
Arch + BTRFS + timeshift is great. TBH, I rarely have issues, but in case I do, the ability to revert to a snapshot quickly is outstanding. IMHO there’s almost no point in using something like Debian for stability when this setup is an option.
I have not had any problems so far - but TUXEDO OS is a distribution I have only used in a private, non-professional context.
And if Arch + Btrfs is mentioned here, one should also mention openSUSE Tumbleweed with Btrfs and snapper , of course (for me it is the most reliable rolling distribution I have ever used).
Another possibility is immutable distros like openSUSE MicroOS/Kalpa, Fedora Kinoite and SteamOS.
The main issue of library incompatibility is due to there being a single source for both base and external apps, and it is completely negated if there are two sources:
the distro’s repository for the immutable base (whether it’s stable, semi-rolling or rolling)
flathub for all external apps
…as is done in immutable distros.
The base is old if the user chose that older base, it’s up-to-date if the user chose that (semi- or) rolling base.
The rest is expected to simply never break because of stable release flatpaks, so it’s recommendable to users.
Plus: you can mix and match nightly flatpaks with stable flatpaks just fine.
But that would have to be strictly targeted towards users instead of developers (which I guess is what most people want in this thread).
Development in immutable distros need to be done in containers, like with distrobox, which can be used even for kdesrc-build, but it can be impractical in certain cases (running a whole Plasma session), so traditional (semi-) rolling releases would continue to be the expected default for developers.
When I ran Arch, I also found this combination to be great, but after moving back openSUSE via Tumbleweed/Snapper, I had to get used to the differences with Snapper. Once I did, I would not go back to Timeshift. SUSE really did a great job figuring out how to do the BTRFS Partition/SubVols with Snapper.
Something happened on a test laptop the other day and all I had to do is try to boot from Snapshots till I was successful. Once I found the last one that booted and ran properly, all I had to do was, “from that running snapshot,” run “sudo snapper rollback” and I was done. It is really that simple.
You can also just make it highlight changes between snapshots and manually fix the file that changed.
There are a couple of packages that replicate this in Arch - snap-pac and grub-btrfs. They create snapshots before updates and add them to GRUB automatically.
But OP specifically said they dont want the latest KDE, but releases from *.3 on and I guess not too many feature releases after that, or did I get that wrong?
Currently until Plasma 6 is set, such a Distro is pretty unlikely, as Plasma6 is a huge cleanup project. From then on, with the massive testing that is currently happening, this could be possible.
Fedora Kinoite is okay and the core packages really dont give many problems. I have tons of bugs, but they are basically all KDE or Firefox. Very often its not Fedora. So yeah I like Plasma, but it could be easier to like it
Something like OpenSuse slowroll in immutable fashion, with that specific release model, could be fitting. Not actually stable, but always a little behind the latest feature releases to catch the bugfixes. But I think ostree is way better, and Fedora has no real semi-stable anywhere. You can always wait a few weeks before updating to a new point release.
kubutu 23.10 fits the bill pretty well at the moment
my experience with 22.04 and then adding backports and backports-extra has brought me nearly there and it seems fine, so were i had it to do over i probably would have opted for 23 at the outset.
I’ve been using Tumbleweed KDE for a few years, Kubuntu and Leap KDE before that, but have switched to TuxedoOS and Leap 15.5 KDE recently. Also, I used SteamOS (Deck) for about a year as a home PC
In my opinion, the best way would be Kubuntu, with regular upgrades to stable releases, no need to stick to LTS, unless you really want that for some reason. And even with LTS, it’s easier now to get newer version of programs via Flatpak/Snap/AppImage, so no need for additional ppas.
Of course, upgrades to new releases shouldn’t be done as soon as possible, better to wait a month or two.
Agreed – immutable is great for 99 % of the humans on this planet.
Assuming that, “only” 1 % are involved with programming computers …
And, devices such as pocket telephones – Android (Linux) or Apple (UNIX® based) – are already using a basic set of operating system plus basic applications – « not really immutable systems because, you can disable and/or remove a couple of the default applications … »
Another plus of immutable systems is that, they update and patch themselves in background without any human intervention …
This is not true, they are immutable. The reason why you can add/delete default applications is because they are not truly deleted from the immutable layer, but disabled. Android makes this more clear than iOS.
