Last week we got quite some criticism about the quality of KDE Plasma 5 on the Internet. This came rather surprising for us and is at least in my opinion highly undeserved. So far what we saw is that Plasma has a high quality – probably better than previous iterations of what was known as the KDE Desktop Environment – and got lots of praise for the state it is in. So how come that there is such a discrepancy between what we see and what our users see?
The chain breaks at the weakest link
Plasma is just one piece of the user experience our users get. It’s the most visible one and it’s also the one which gets all the blame if things break. But in reality there is much more to it. Plasma depends on other libraries – most importantly Qt – and on drivers (OpenGL/Mesa) and on hardware. All of that is put together by distributions. We don’t ship the software to our users, we ship it to the distributions which then integrate it with the rest of the stack. All we can do is give recommendations to our distributions about common issues and how to prevent that they happen. Now I don’t want to move the blame to the distributions, because that would also be undeserved. I just want to explain how complex the process is.
Some numbers
So let’s start with a look at some numbers. I’m looking at a combination of the applications plasmashell, kwin, krunner and systemsettings. These are the most visible to the users. The numbers will be slightly distorted, because there were also bugs going in for the old 4.11 series and only plasmashell is a 5 only product.
Over the last 365 days 1313 crash reports were reported for these products. That’s quite a number, but means it’s only about 3.5 per day. Given our large user bases that’s not that bad. If we had a huge quality problem we would get hundreds of bug reports per day. And yes we do, I had been in such situations in KWin that we got two digits numbers of duplicates per day.
Of those 1313 crash reports 127 are still unconfirmed (we need to improve here!) and 23 confirmed. The number looks high, but now we need to look at how they distribute. There are a few bugs with a high number of duplicates. Given my limited search skills I found one with 91 duplicates which got a fix released six months ago, but we still see new duplicates for it. I come back to how that happens later. A few bugs reported several times and we get close to the numbers. I just summed up the number of the ten most often reported crashers and that’s already about half of the reported crashes.
So why are there crashes reported so often and are not immediately fixed? This is exactly the weakest link I have been talking about. It’s things we don’t have an influence on.
Graphics drivers
One of the most severe issues we hit with Plasma 5 is an issue with the Intel graphics drivers. I think that this problem is the reason why people complain about instability of Plasma. The only reason. Crashes in drivers (especially Intel) are nothing new, it’s a problem which has haunted us for years. For example the most often reported crash against KWin is a crash in the Intel driver – we worked around that issue by disabling a feature for all Intel users and will never ever enable it again.
Now I know that this sounds like passing the blame to the graphics drivers and I can imagine that you say that we need to QA test. That is true, we need to QA test, also against the drivers. Just that’s not possible. I blogged about why that’s not possible back in 2011. Nothing has changed except that the number of possible hardware and driver combinations further increased.
The biggest problem for us is that the drivers a distro will ship doesn’t exist yet when we develop and test our software. Even if we would use development drivers it would be too old compared to what distros ship.
One could say it’s the responsibility of the distribution to do the QA. Yes, they as a software integrator should make sure that the software works together. And they do, but lots of it runs in VMs which don’t provide the “real” hardware. But expecting distributions to do all the combinations we cannot test, is also wrong. If there is one which can do the quality assurance of e.g. the Intel driver it’s Intel. They have the hardware, they have the developers (AFAIK there are more fulltime devs working on the Intel drivers than we have devs on Plasma), they have the QA team. I do not know how they test, but I am sure they could spot such severe driver regressions.
What to do when we hit such a severe driver issue? Well that’s difficult. If possible we can workaround like the KWin problem I mentioned above. But that still takes time till it reaches the users. In this particular case we informed distributions about a possible workaround on Xserver level and I hope ll distributions applied it. If not please complain to your distribution.
Multi Screen woes
Another source of reported instability is multi screen handling on X11. Again the problem does not lie on our side but in this case Qt. First a word of clarification: auto-testing multi-screen on X11 is extremely difficult. Virtual X servers like Xvfb do not support the randr extension which makes it impossible to mock a correct behavior in X. Also testing with real X doesn’t help as that can only test with the screens one has and physically plugging out a screen during an auto-test isn’t really a solution.
So this sounds like blaming Qt, which of course is not what I want to do. You can rightly question why we as KDE do not help Qt with it. Well we did. Especially Dan Vratil did an incredible job of improving the experience directly in Qt. There were things which one wouldn’t believe are possible. For example there is an xrandr call to read the configuration and that blocks the Xserver in the Intel driver. Now each Qt application did that and caused a freeze. When I figured out the root source for this problem I created a remote denial of service proof of concept against X server and informed the security list about this problem. I did this in January and haven’t got a reply till now and have not talked in public about this. So yeah I just did a full-disclosure. Anyway Dan worked around this problem and fixed many more.
So why is this all still an issue? This is slightly related to how Qt and Plasma releases are not synced. For example at the moment Qt 5.5 will not receive any bug fix releases any more, but all we have in distributions is Qt 5.4. This means any fixes we do will not reach users till distributions roll out Qt 5.6. It’s rather depressive to be honest. You know you fixed an issue, but it doesn’t reach your users. I think this needs works from both Qt and the distributions. We need more bug fix releases and distributions must update Qt more often. I hope that the long term release Qt 5.6 will improve the situation as that gives us also a chance to provide bug fixes and hopefully reach our users.
As it stands there seem to still be crash cases in Qt 5.6. Since recently I have a nice tool which should allow to mock multi screen setup and I want to try to dedicate some time this week to create test cases. If that works I hope we can move this forward.
Issues fixed months ago
Another problem we noticed is that fixes we created doesn’t reach our users. This is mostly to how some distributions work with the exception of rolling release distributions. They create a “stable” and “feature frozen” product. If a major version number increases it’s not going to be updated. I just described the problem with outdated Qt, that’s part of the story. The update didn’t get into the distribution and thus fixes don’t reach our users.
Even more with frameworks we don’t provide bug fix releases and that creates “problems” for distributions. They don’t roll our the new frameworks, although they fix important issues. This is slowly improving, distributions need to get used to this process and also accept that their policy doesn’t apply.
Furthermore one needs to point out that some distributions do have additional repositories to get newer software. If you use e.g. Kubuntu 15.04 I highly recommend to use that. Every non LTS release from Ubuntu is basically a testing distribution. If you use that you decided to go with faster software updates. Please use the ways to get those updates. If you don’t want that please stay with LTS.
This is something which applies to pretty much all distributions. Stay with the long term releases if you don’t want to update to newer software.
Removed features
What we also heard a lot lately are complains about that we removed features. Yes we did that, we streamlined some implementations, we decided to focus on the core, we decided to not port all X11 specific code, but allow 3rd party applications to fill that niche (e.g. SDDM or LightDM instead of KDM). Nevertheless let’s look at some of the complains.
Legacy systray
The biggest problem for our users seems to be the removal of support of the legacy system tray (xembed). This was not a move against our users, but a change we did not expect to cause so many problems. We did evaluate the situation prior to the release and saw that it was possible to do this step without loss of functionality. Nevertheless it created problems. How was that possible?
A key feature to the switch was getting the distributions in. Our distributions had to patch software in the same way as Ubuntu did. So we collected the required changes and informed distributions about it. The patches to Qt 4, which flags to enable in which repositories and so on.
With some distributions that worked awesomely, with some we had problems. In one distributions the GNOME maintainers refused to enable the required flags (boo), one distribution decided to not enable the Qt 4 patch because that’s not what they do, but they already had patches for arm64 (WTF? Support for a theoretical architecture is more important than users on existing hardware? Wtf, wtf!) If your distribution did not do the transition in a sufficient way, please complain to them and not to us.
Now there were things which got overlooked. Skype needed proper multi-arch and the package installation did not always work. Distros were informed about this problem once we noticed. Some proprietary applications used static linking destroying the “magic”. That’s unfortunate, but also not our fault. And also in the area of proprietary applications: wine applications have no fallback. Sorry about that, but we just were not aware of that and we didn’t get a feedback quickly enough.
We noticed that this is a problem and David started to work on a solution for Plasma 5.5. I’m not happy that we had to do that as it just delays solving the actual problem: we need to get rid of the old systray. I’m already seeing the bug reports about unusable systray icons on HighDPI or not working on Wayland. There is also one solution: work together to get this transition done. Bug your distributions to include all patches (if not done yet), bug your favorite projects to port. It’s about time!
Applets per virtual desktop and dashboard
Some of the feedback we got is that users are unhappy that they cannot have different applets and wallpaper per virtual desktop and also on dashboard. Yes we understand that this is seen as a regression, so let’s look at why we changed.
First of all: change is sometimes required also removing features is sometimes required. We are sorry for the users affected by such changes, but we normally don’t do that without good reason. We are extremely careful as you can see in the systray case where we coordinated with distributions months prior to the release to make the transition smooth.
For the features here in question we need to look back at the last iteration of Plasma. Some of the things we learned was that these features just didn’t really work, they were buggy and there were many conditions were it just didn’t really work. An example is KWin which just never really knew when Plasma is in dashboard mode, we failed to properly set up the state and it just resulted in lots of quirks. So when we looked at it for Plasma 5 we realized that it’s extremely close to another mode KWin could handle well: Show Desktop. So we merged those two and improved the Show Desktop experience at the same time.
Multiple virtual desktops in Plasma had always been a quirk. I remember one discussion shortly after starting to contribute to Plasma: we were not able to properly support this feature in Desktop Grid or Desktop Cube. Technically that was just impossible how Plasma worked. We were not able to solve this problem in all of Plasma 4 and we would not be able to solve it in Plasma 5. In addition it also caused problems with various other features, so overall it looked like a better idea to disable this feature in core Plasma. This goes along with the fact that we consider Virtual Desktops as a high productivity and experienced user feature. By default they are disabled.
Now we understand that this is a feature important to some users. But we need to ask you to understand that we cannot maintain all possible features for all possible users and that sometimes the quality of the complete product is more important. Furthermore Plasma is a flexible product and it should be possible to provide this as a 3rd party feature.
Not ported featured
There are a few more features which just didn’t make it to the new release. In many cases that’s because of the features do not have a maintainer. Examples for this are KHotkeys and the application menu. In both cases the port was not trivial due to changes in the underlying infrastructure, so we couldn’t manage it with our limited resources.
But that’s of course a chance for you, dear reader. If you are a developer and loved some of the features we were not able to provide, you can step up and maintain them. We are always looking for more help!
What was important to us is to not overload ourselves with more code than we can maintain. We want to provide a high quality product which we can ensure that it is high quality. This required to cut down in some areas. I think that was the correct decision and I think we reached our goal in providing a foundation for a high quality product.
Improved Workflows
Overall with our new product we put a focus on quality and adjusted our workflows to ensure that we have a high quality. As already mentioned we decided to focus on the core and by that focus only on what we can ensure to maintain. That’s just one aspect to it. Another aspect is the increased usage of automatic testing thanks to continuous integration done directly by KDE and also by our distributions. A big thanks to openSUSE for openQA and Kubuntu for the Kubuntu CI! Those two instances have caught many issues which slipped through our CI.
Additionally we release in shorter cycles (frameworks each month, Plasma every three months). This is only possible by ensuring quality through higher code review, requirements for auto tests, etc. A good overview can be found in sebas’s blog post on the topic.
Let’s start with the most simple issue: A well known software is renamed to Plasma without asking the users first.
It is improved in a way that is unstable, whether for internal oder external reasons does not matter as the competitor are previous stable incarnations. Users feel betrayed about that.
As long as the new incarnation is not as stable as the previous one any user experiencing a crash with the new incarnation will wreck the reputation of the product.
There are victims to that. That is the Wankel motor, a superior way to design a car engine. Yet it was shipped and not ready to replace a otto engine. Thus implementations ruined it reputation and vanished.
Plus there are so many issues of the KDE3 to KDE 4 migration that have never been fixed and resolved. In the 4 to 5 migration we again see stuff that breaks, that is not implemented yet and I don’t really trust that it ever will. Whatever you do, do it smooth. The KDE4 migration happened in a period of time where there was an opportunity for Desktop Linux because Microsoft failed with Vista. What happened here to our KDE was close to sabotage. It does not really matter if what arrives years later has the issues fixed, the damage is done.
Wtf? You bring up the KDE 4 migration and complain that we didn’t ask you with the naming for the Plasma project? If you seriously still want to complain about that, I have a recommendation for you: don’t use our products, we will never be able to satisfy our needs. There’s GNOME, Cinnamon, LXQt, Enlightment and many more. All awesome projects, please pick one of them and have a happy life.
Well, okay. But in the KDE3-4 transition, we were assured that the pain was worth it, because the new KDE4 tree would be designed right for the future, and future transitions will be smooth(er?). This one’s probably smoother than 3-4, but still…
Anyway, my question is – given the complexity of all these moving parts, and the stability and performance of KDE4 these days, why is there any push for architectural changes to the framework at this point? Yes, I’m sure QT5 brings some great new features, but do we really need them right now – and could some of them have been implemented on the QT4 base. Progress is great, but if you don’t have the resources to make it all work well, perhaps the limited resources could be more effective with a little less progress.
Okay, I’m a ingrate who knows not what he’s speaking about, and you can feel free to ignore me. But actually, I’m a quite happy Mint-KDE user that used to be pissed at the Mint guys for not shipping KDE5. Now I guess I ought to thank them. It’s not that I don’t want my favorite desktop to become even better. I guess I just don’t want to see release announcements about a new version that I can’t practically use.
Yeah, it pretty much comes down to “if I can’t login to my box, and it keeps crashing – hence I can’t get my day to day work done” then it’s a major fail. It doesn’t matter whose “fault” it is.
To be honnest with the users, this should be called beta and that’s it. KDE folks want too much with too little resources.
Is there a promise for enterprise how long is Plasma5 going to be maintained before Plasma6 is here?
Any transition is going to have bumps! If all you have to complain about is that you’re hearing release announcements for software you can’t practically use yet, then there’s basically nothing to complain about. Just enjoy what you have and wait for things to settle down more and regressions to smooth out before you go ahead and update to Plasma 5. This transition has been far smoother than 3-4, so the work in 4 has been shown to have been worth it I think, and it shouldn’t be too long now.
By the way, a Wankel engine is not superior for the very simple reason that it is hard to design a non-circular sealing that really seals at an acceptable price for large-scale production (i.e. several million engines). Car manufacturers anually spend billions on engine development, you can be quite sure they tried that.
Something similar is true for plasma: making good software run on millions of heterogenous machines when not controlling the way it’s distributed is simply a difficult task especially when working with such resource constraints while still having to deliver state-of-the-art software. Not producing new iterations of software is simply a no-option; you have to keep running to remain competitive.
Oh, and one more thing, Martin. Your presence on news platforms like pro-linux, patiently responding to questions and criticism, is just great, and is probably very important for KDE’s image outside its direct community. I probably couldn’t stand reading some of such statements on my work 😉
Thanks Martin for the information. Thanks also for taking your time to code for KDE. I have used Linux for quite some time, have tried a lot of different DEs, and I have chosen KDE as my default. I run KDE on both my work and personal computers. I can not recall any distribution / DE / OS that I’ve tried that is without some sort of faults. For those who feel plasma is not stable enough, or don’t like the direction of KDE as a whole, try something else. I think you’ll find that you’ll come back. The good parts of KDE far out weigh the bad. Just my $.02
Yeah, I have to agree… had been using KDE since 1998 and even from 3 to 4 it’s been OK. Thanks for the work and the in depth explanation on the issues.
You went for the weakest point in Chris’ comment. I actually think this metaphorical as an introduction to some “newly introduced technology is not everything and may do harm”. Anyway.
I think the KDE folks should vertically extend more, i.e. towards Qt (which they are doing as I understood) and on the other end also towards the distros. There is for instance no reason not to use Debian’s experimental section with Qt 5.6 (at the moment still on 5.5 https://packages.qa.debian.org/q/qtbase-opensource-src.html ) and nightly builds of KDE. Just do not let me fall for it in Debian unstable if it is too early to be used as a regular desktop environment.
I want to write again, thanks for the elucidation!
Software stack, moving everything forward, elegant software, etc.
… it still stinks for us users though. :-\
In my simple and naive debian based universe: Jessie with KDE4 is stable. Everything else is Beta.
That said, I LOVE Plasma 5. Although I experience occasional problems, it is the “best” DE I ever enjoyed. Regarding both style and functionality. Thank you very, very much for the excellent work, Martin. And please, keep on!
You mention virtual desktops, does this mean they are gone? or were they just disabled by default because some stuff doesnt work with it?
Virtual desktop still exist. The only change regarding virtual desktops is that we don’t support different wallpapers and different applet sets. Everything else still works the same way.
Ouch – I just finished downloading Kubuntu Wily in hopes of installing it parallel to my existing Trusty LTS installation and slowly switching over, but I’m one of those power users who use multiple desktops, a different wallpaper scheme for each and to hear that it’s gone is somewhat shocking…
My first desktop has an xplanet sunlight map, the second is sorta religious, the third is ImageMagick plasma background with programmatically updated astronomy images, and the four is stuff from InterfaceLift. Is there no way that this is going to be possible in Plasma 5?
I felt you were a little vague with exactly what kind of problems were caused by the presence of the multiple wallpaper/applets feature – I certainly never had any problems over the past two years with my setup. Is there any way at all to perhaps recompile the existing source code with a #define flag to get this feature back or something?
I mean, having a limited feature (though I never experienced any such limitation) is better than not having it at all!
I agree on that in general. But users have an expectation and they have the expectation that if we as KDE provide a feature, that it has to work correctly and without limitations. If one is not able to provide this, it might be better to not provide it at all.
Of course this opens up the possibility for 3rd party providers. A “different wallpaper per virtual desktop” can easily be provided through a wallpaper plugin as a 3rd party solution.
KDE has by far been the most persistent of the Linux desktops in my use. The number one reason is the ability to make a consistent configuration of window behavior, keyboard shortcuts, and workable flow. Right now I have a working setup with elements of Ubuntu Unity, Windows, and Mac in its setup. The only regret is that sometimes the best of breed app isn’t integrated into KDE – not a big deal, but I can imagine what it’d be like to have a consistent set of tab-managing keyboard shortcuts between Konsole and my web browser.
Nothing else quite does it for me. Kudos to the development team!
KDE4 sold me back to KDE years ago. Compared to radical GNOME and experimental E17, KDE is the middle of these two providing vast supported/stable software and user choice.
I miss actions with keyboard-only in (any modern) desktop, but KRunner fills some of the gaps plus awesome tasks. I know you provide Activities, but I’m used to Virtual Desktops. May be if someone could explain what’s better when using Activities?
As a long user, I think KDE mature a lot. In my experience, KDE3 crashed often under Mandrake. KDE SC 4 (since 4.1) more stable, but bumped on being semantic desktop. You were far too ahead. The indexing software wasn’t ready yet. Today I’m with KF5 with Kubuntu 15.04 as a daily driver.
One thing that made me proud of being KDE user is if you watch carefully, every Windows iteration has similar look to every KDE iteration. (coincidence, no? xD) #conspiraytheorist
Anyway, kudos to all the developer of KDE.
So I have to agree with most of what Martin wrote. The current Plasma/KDE is far from stable. I use it for many hours per day and have at least one crash occur daily. Varying components crash. Seen krunner, kded, akonadi (regular), plasmashell and kwin. I don’t use Intel graphics but the NVidia binary blob. I’m running Arch so have the lastest stable Plasma installed.
The move to plasma does mirror the launch of KDE4 to me. It seems we get to a stable KDE4 and bam – off we go again with instability in Plasma.
That said I stick it out because I’m sure Plasma will make the grade as KDE4 did before it.
So, why isn’t it called beta?
Thanks a lot for this post. I wasn’t sure if I had missconfigured my distribution or if most of what you mention were not-yet-solved-bugs. Now that I know, waiting for patches will be less painful. Although I’m pretty fustrated with these bugs I really love KDE !
Funny thing that when I tried to report a bug using built-in tool I just couldn’t login. Fortunately it wad resolved by removing configs.
Plasma still crashes a lot when using touchscreen. I have a crazy case with 4k touchscreen on my laptop. Had a bad time with 4k at first so thanks for fixing hidpi issues. I hope you won’t turn your backs on touchscreen users)
I think re-implementing xembed system tray in Plasma 5 is a bad idea. It was removed for a reason. Some of us bugged proprietary software to start supporting KStatusNotifierItems no they have no reason to implement it ever again. 2 years from now you may want to get rid of xembed system tray again and you will end up in exactly same situation. Everyone is going to blame Plasma again.
I refuse to use any app that doesn’t support Plasma and/or doesn’t fit well in Plasma. I strongly refuse to use any distribution that is not heavily invested in Plasma. I think that’s not even fanatic but the convenient way. How will I have good experience if apps I use don’t care about Plasma? That being said most of the popular distros (Fedora, Kubuntu, OpenSUSE, Arch Linux, etc.) have super dedicated KDE folks. Wmsystemtray thing is a perfectly fine solution for apps that don’t support KStatusNotifierItems.
Sad to hear that the Intel workaround(s?) won’t be coming until Qt 5.6; those are the realities, though. Hopefully some of this will turn up the pressure on Intel to fix their bugs. Very much appreciative of the work you and all your compatriots are doing with Plasma (and the rest of the KDE ecosystem). I’ve stuck largely with the mantra you’ve outlined here, ie. either keep as up to date as possible or stay on the LTS, so at work we run Kubuntu 14.04 installs and at home I run fairly cutting edge with the Kubuntu backport PPAs enabled, and (apart from a small bug deepened into a far worse one due to how systemd handles VTs) I’ve been quite happy with both respective approaches.
Where are the bug reports for the Intel driver(s)?
So, basically, if you need to use multiple monitors, you should avoid plasma 5 until Qt 5.6 is released? Have any distributions provided a patch for this?
I’m using plasma 5 on Archlinux on a Dell E6520, and the two issues you’ve described have made plasma 5 unusable for me. Regardless of who’s “fault” it is, I’ve basically resolved that I can’t use plasma 5 for now. I get frequent freezes, with nothing in the logs to indicate the problem, normal CPU and memory usage, a healthy HDD and RAM, etc. I’m guessing that this Intel graphics issue is the cause. That said, it seems to occur when using Cinnamon, as well.
Is there no way, then to have a stable plasma 5 desktop right now, without using different hardware?
I’m sorry to hear about your bad experience. I doubt, though, that your freezes are related to the multi screen problems. Please go to forum.kde.org to get help on identifying the problem and solving it.
Do your crash reports come via the same mechanism used in Plasma 4? (i.e. a crash wizard pops up and usually tells you that the information it was able to gather wasn’t worth reporting? I’ve never yet had one of my crashes with KDE4 actually get reported).