Experiences with KDE / Plasma in an enterprise environment

[Christian Loosli]

Hello list, 

Thomas Pfeiffer informed me about this list and asked me to post my feedback 
from an enterprise point of view to it, as we were discussing it on a 
different list.  Apologies that my first post thus is already filled with 
(hopefully constructive) criticism.

This is mostly meant to provide a list of points we, in an enterprise 
environment, had issues an what it lead to. It is not meant to talk bad about 
specific products or people, but rather to point out where things could be 
improved.

Also I try to avoid tech as much as possible and "dumb down" and not use / 
ignore technical terms and explanations, because most end users you have 
aren't tech savvy.


Introduction: 

Until recently I worked for a public office which had an open source strategy, 
in the server and software development parts, but also partially in the 
desktop area. This work lead to us winning a FOSS award. 
I worked in, and later on lead, the team of DevOps, so a mixture of software 
and system engineers. We made our own respin of (K)Ubuntu to package it with 
software (e.g. sssd), configuration and certificates we needed. I advertised 
and configured KDE Plasma as the standard desktop, because I am and was active 
in the KDE community. The hardware was a mixture of Dell enterprise desktop 
PCs  (Ati FireGL GPUs) and Dell enterprise notebooks (Intel GPU). Most things 
I mention here can easily be reproduced on my personal notebook, which is a 
Thinkpad T430, so also business hardware, nVidia GPU. 

My team and I recently left said employer due to a management and strategy 
change, so note that this is personal experience and opinion and not the one 
of my former employer.


Experiences: 1)  The login 

The first and probably biggest issue we had was right at the login. 
As many companies (and universities and other entities) we have a directory 
which is used for authentication. In our case: Active Directory, but the same 
applies for any directory, including all LDAP based ones. 
With the default login manager used these days for KDE/Plasma (sddm) and the 
plasma provided team, it is simply not possible to log yourself in if your 
user is in a directory.  The user list is taken from /etc/passwd instead of 
whatever nss provides, and there is no possibility to enter a username 
manually. 
This bug has been reported roughly one year ago and is, today, still valid. 

As a minor sidenote: also unlocking the lockscreen does not reliably renew the 
kerberos ticket, so if you have a session open for too long, it will expire.


Experiences 2) Going mobile  (and: login screen revisited) 

People started using notebooks and docking stations, which is where things got 
quite a lot worse. 

1) Undocking from the docking station leads to shortly no screens being 
available, which leads to the screen locker and the session manager crashing, 
which logs the user out. This leads to a complete data loss in all open 
applications (!). This is a well known bug in Qt which also has been around 
for roughly a year. Even though it is on a high priority, the fix is only 
partially there and won't be backported to Qt 5.5, which is the default in 
most distributions. 

2) Having the laptop docked leaves the small laptop screen and the big 
attached screen overlapping, which leads to numerous interesting bugs, among 
them:

2.1) If the laptop screen is turned off when docked, this leads to the whole 
login screen (sddm) going black, leaving the user blindfolded. The mouse 
cursor is still visible, so you can try to find out where the text entry 
fields are and log in. 

2.2) various elements, such as krunner or kmix, sometimes appear misplaced 
(relative to the smaller laptop screen instead of the attached screen(s)


Experiences 3) Visual glitches 

If one managed to log in, during the session there were various stability 
issues and graphical glitches. The latter was mostly to be experienced with 
the intel driver, which lead to ghost windows after switching virtual 
desktops, and visual artifacts with the nVidia driver when scrolling in plasma 
lists (e.g. when adding new plasmoids) 


Experiences 4) Various paper cuts in enterprise applications

A very common thing to use in an enterprise is personal information 
management. We used the Kontact suite, which had the following issues: 

1) Connections to external DAV sources were sometimes lost. The source was 
still there, but unchecked. Re-adding it lead to some of the previous 
settings, such as calendar colour, being lost. 

2) Mails "forgot" various statuses, among them: whether they have an 
attachment, whether they are signed / encrypted. You could literally look at 
the list and see the little icon denoting it disappearing. This seems to be 
related to filters  (e.g. spamassassin and moving around folders) 

3) Icons. First of all there is some inconsistency between the monochrome 
(new) and coloured (old) icons, e.g. mails are coloured, sent/replied etc. are 
monochrome.  Then, more important, in some cases there are not self 
explanatory icons without any text (unless you mouse hover). The best example 
is the advanced search in the mail view. There are roughly a dozen icons 
there, of which 9 people could not identify their function unless mouse 
hovered. 


Another thing was the instant messaging: first of all, compared to the 
competitors  (speaking of lync with exchange), they lack quite some 
functionality. We have kpeople and ktp, but still no presence information 
spread across applications. In outlook/lync this just works, ootb. 

Then: we allowed home office, via a VPN connection. Now unfortunately this 
means that one IM account was only available when you were either in the 
company  network or at least connected to it via VPN. As you can't switch 
accounts on/offline independently, this lead to a lovely bunch of error 
messages every time you went online in ktp when outside of the company 
network.


Experiences 5) Concepts

Some of the core concepts were hard to explain to users. Keep in mind: they 
are software/system engineers with various degrees in computer science. 
Favourite example: an employee wanted to change the power scheme (as he is 
used to from Windows). I had to explain to him that this is possible via 
activities. He had a very hard time understanding why, in his opinion, he had 
to change the visible windows, wallpapers and various settings just to get a 
specific power scheme.  Aside from that use case, activities were not used. 

The distinction between desktop and applications: Also that was a concept hard 
to understand, as it lead to some inconsistencies. E.g. why are the volume and 
mail popups different from the network popup  (because one is an application 
using the Qt theme and one is a plasmoid). 


Experiences 6) Upgrades and updates

Some of us, as usual in an enterprise, where using the LTS of (K)Ubuntu, thus: 
plasma 4. Due to some newer software being needed, people updated to the 
latest version, which comes with Plasma 5. In an enterprise environment, you 
are used to upgrades being possible without too much hassle. In case of KDE/
Plasma,  though, half of the applications lost their settings. And these are 
mostly settings that exist in both Plasma 4 and 5, such as key bindings, 
starts in the taskbar, window rules  (needed for e.g. VMWare) etc. 


Conclusions: 

After two years and shortly before I left, I was the only one remaining using 
KDE Plasma. The others have switched to other environments (Unity, XFCE and 
Cinammon, as far as I remember), where the exactly same hardware with the 
exactly same use cases worked a lot more stable. 

Summarized: 

1) Logging in is not possible with a directory service, which is the default 
in most enterprise environments. 

2) Daily tasks like undocking a notebook lead to the whole session crashing, 
resulting in a full data loss of all open applications

3) Various visual glitches and papercuts all across the applications

4) Base concepts that are hard to understand and rarely used 

5) Unreliable updates to recent versions including data loss 

6) Response times for pressing issues are way too high, two critical bugs with 
either data loss or not being able to log in have been reported and known for 
a year without fix


So, as much as I personally like KDE and Plasma, I fully understand why people 
in my team switched away from it. 
And in conclusion: in it's current state, the KDE software stack and plasma 
are not usable in an enterprise environment. 

I really hope that this improves, and I hope that this list of experiences we 
made helps spotting some of the spots that could do with improvements. 

If you have further questions or need more details, feel free to ask. Keep in 
mind though that I no longer am in that environment and thus can't test some 
things. 


Kind regards, 

Christian


PS: 
As I am a bit experienced with similar discussions on bug trackers, IRC and 
other mailing lists, I recommend saving some time and not coming with the 
following frequently given replies: 

1) It's the fault of $driver.   Maybe. However: it doesn't matter. Business 
perspective is:  Other environments work with the same hardware without these 
issues, so it has to be possible. Also: with all 3 major GPU vendors we had 
issues. 

2) It's the fault of $otherproduct  (e.g. sddm not being part of plasma): 
Maybe. However: it doesn't matter. Business perspective is: it works in other 
environments. If something in your stack is broken, fix it or don't use it. 
It's you who will get all the feedback when things don't work. 

3) It's the fault of the framework we use (Qt): Maybe. However: it doesn't 
matter. Business perspective is: it works in other environments. However, if 
the stack is so broken that critical bugs  (e.g. the data loss) are not fixed 
within a couple of months and won't be backported, then this needs fixing. 
How: doesn't matter, there is competition available where it works right now, 
so: business doesn't care.  I shall get technical for a short moment here: in 
case of the screen being NULL which leads to the data loss mentioned in 
experience 2: Yes, this might be a Qt problem, but you can actually check and 
avoid it in your end. Yes, this is a hack and should not be done, but if 
upstream doesn't manage to fix things within months, maybe you have to 
workaround it. 

4) It's the fault of the user:   No. "The user is always right". As much as I 
hate saying this, having seen users and what they can do: if the user can 
break something in daily operations or says that a certain concept is not 
intuitive, chances are that the user is right, even if you disagree. 

5) It's your fault for not helping out:  No. First of all, while we didn't 
give back code to KDE (because we really didn't operate in that field, at 
all), we sponsored sprints and KDE. In addition to that, we try to at least 
give back via bug reports and experience reports like this one.