Is the KDE 5 desktop stable enough for normal users?

This not a rant! I just want to share some concerns about the quality of the current KDE desktop and its deployment to normal users.

I upraded to KDE 5 by upgrading from Fedora 21 to Fedora 22. I did this rapidly on four laptops because I liked the new fresh look. Two of them I use heavily for personal work. The plasma version in use was 5.3. But after some weeks of work I collected a long list of heavy issues with that desktop. They all showed up doing very general things. Especially problematic are multi screen configurations. Things you usually do when you plug in and plug off your laptop from the display at your working place.

Here is a (incomplete) list of issues I currently face with the plasma desktop 5.4

  • Attaching and removing screens from the laptop does not change the screen configuration. That means attached screens get not actived and removed screens not deactivated. Usually I have to reconfigure the screens manually in systemsettings. Afterwards killing and restarting plasmashell is required, exspecially to get rid of disconnected screens. If that does not help I usually try restarting kwin too, although I’m not sure that helps. Multi-screen switching somewhat worked with plasma-5.4 but broke again with a kdeframework upgrade. If you have configure multiple panels in a multi monitor setting you can find them jump around (even stacking) if you change anything in the screen positioning. If you attach a new screen and activate it, sometimes plasma moves on to the new screen (good!) but the old screen gets black. I can move windows onto it but there is no plasma running in its background (bad). But that is relatively small bug.
  • As not all applications have been moved to KDE 5 yet, some of them use kdewallet4 and some use kdewallet5. This means that you are asked for a password to open the wallet twice in the same session – and those passwords can be different! Even if you know that you often have to try one password and after that the other one. Since the last updates the kdewallet5 password window can be visually distinguished from the kdewallet4 one what helps me with that. This is not a real bug but very very uncomfortable for users.
  • The digital clock applet just stops and shows an old time.
  • The digital clock applet will never show another timezone than UTC if UTC is your system timezone, no matter what timezone you configure in its settings. Really I never had so much problems getting the correct time displayed on my desktop – because I had not find out that the system time ist the problem.
  • The window taskbar gets out of sync with the application windows. That means you can click on firefox in the taskbar and what open up is a dolphin window (or no window at all).You see taskbar entries for applications you have closed and you miss them for ones you have opened.
    When you have two screens with two taskbars each of them configured to show only the windows of the current screen -> windows get mixed up and are shown in the wrong taskbar. Worst: Sometimes the taskbar(s) do not work at all. Praise the “Show windows” desktop effect, it saves your day.
  • krunner will sometimes not execute commands. In that case I have to restart plasmashell via terminal.Very annoying because I have to do that often.
  • krunner sometimes does not appear at all (maybe fixed in 5.4)
  • If you have two screens with two identical panels, sometimes applets in one of the panels will not be able to show a plasma popup on one of them. That means if you have a application starters on your right and left screen, the application starter just works on the left one. (maybe fixed in 5.4)
  • After having changed the screen positioning the plasma applets do not recognize that and do open somewhere on the screen and not beside the panel (maybe fixed in 5.4)
  • Moving plasma pannels between screens works only with patience and it is really messy. This becomes a problem in conjunction with the issues making panels jumping around on screens in dynamic multi-screen configurations.
  • On three systems with intel based graphics of different generations I did not find one with a opengl version and interface combination which did not sometime create a garbled screen. I know that the linux graphic stack is a nightmare and the fault is likely in there exspecially as Fedora is on its bleedings edge side. But this was better in plasma 4.
  • UPDATED: File search in dolphin does not work at all. It never finds anything.

This is the situation now – and it is much better than it was when Fedora 22 came out with Plasma 5.3.

I found the following additional heavy problems in the plasma 5.3 desktop (which has been shipped out to end users by various distributions):

  • Migration from kdewallet4 to kdewallet5 lets you enter a password for the new wallet. Unfortunatly the password you enter did not work to open the new wallet afterwards. I had this on three systems and I’m sure I did not make a typo three times. The problem got fixed afterwards but the systems upgraded with that bug are somewhat of broken. There is no obvious way to get a new working system wallet.
  • Plasma animations running long start to eat up one CPU core completly. This means if the network applet tries to connect too long or telepathy tries to connect to IM accounts with broken down servers (making the panel icon spin all the time) you burn your laptop battery. Oh – and do not do long file transfers with dolphin because the progress spinner in the panel will fight with the copy process for cpu cycles. This bug has been fixed in 5.4 but people report to still see it occasionally.
  • Too many windows caused plasma to eat one CPU core too. I often work with several firefox windows. The second one usually made the whole desktop slow and made plasmashell burn half the cpu power. The problem went away when the window was minimized. So you were not supposed to have more than a few windows open in plasma 5.3. I think system memory is something that can limit the amount of open windows – your desktop should not.

That bugs made me step away from KDE until plasma 5.4 was pushed out in Fedora. The last time I did that was during the KDE 4.0, 4.1 time frame.

These are just the bugs I was able to clearly identify and reproduce. I had many more problems. SDDM was some kind of a nightmare when it became the default for KDE. I had heavy problems with it in a multi screen setup and I could not login into a second session. I had to fall back to kdm several times. Luckily the heavy problems have been mostly sorted out in recent updates. Ktelepathy is another area where I had my problems. I migrated to it from pidgin mostly because plasma 5 did not support the old sysicons anymore. Ktp has its issues exspecially when using the OTR plugin and having contacts that are logged on several computers (sending and receiving messages does not always work). I hope to get into good working order by not using OTR anymore and with the latest updates. It still has a preference for crashing plasma when using the contact list applet. Since three weeks its systemsettings module crashed when I tried to modify a specific IM account of mine. Well, I had to delete and recreate it.

I did not search for all of the listed bugs in bugzilla. The ones I search for I found there reported. The bugs are so obvious that I’m sure they are all reported. I’m not sure which bugs are caused by the distribution (Fedora). Maybe a few that I did not look for. I mostly can rule out that they are caused by old config files because I tried to fix them by deleting the old ones several times. The bugs show up even using fresh user accounts.

I find it very hard to work with the KDE desktop in its current state. Again, this is not a rant. I do not complain. I have no time to help development, I live with what I get. I’m sure developers to their best to enhance the situation. I can just say: This is the first time that I’m really not interested in updates because of new features or performance enhancements. I just wish myself bugfixes.

What puzzles me is that plasma desktop is widely reported to be a stable desktop

I have not seen a review of KDE (or a distribution using it) mentioning any of the problems I am seeing daily. This is somewhat of explainable: You will not find the bugs without really working with the desktop. You have to use it some days, do your work on it and plug your device on to different monitor. Unfortunatly I think most press reviewers do not do that. You can cope with the current KDE if you have just one screen, always a stable network connection and restart daily. You normaly do not work under such conditions, do you?

Would I’ve known that KDE 5 has so much rough edges – I just would not have installed it on my production systems. Fair enough. Oh – and I would not have upgraded my wifes computer who thanked me with “No more updates ever! This does not work at all!” And she was even right.

The reality is that I do not see how one could cope with current plasma desktop without good knowledge of the system and the ability to restart kwin, plasma or the whole session from the command line. In the same time I see this desktop being pushed out by many distributions to normal end-users. I personally often try to migrate normal people from Windows to a Linux Distribution. This often works quite well. But would I try to give one of them the current KDE desktop, I’m sure I would not succeed in freeing the person. My problem is: That’s what distriubtions currently do and I do not see one word of warning.

Either the problems I list are just happening to me – or users should be warned that they should currently stick with KDE 4.12 if they are neither experts nor brave. I consider plasma 5.4 somewhat useable for me, but in my opinion plasma 5.3 was too heavily broken. Nonetheless it was shipped by Kubuntu and Fedora. Fedora is a bleeding edge distribution (meaning that is okay), but Kubuntu is directed at less experienced users.

Nevertheless, especially because I had to switch desktops in the last months to get work done, I can only say that I still find KDE the desktop I like most. I just hope that it lets me use it more easily.

Start a service after openvpn connection has been established using systemd

I like to provide services only via VPN for security reasons. That means a server only accepts connections to a service (e.g. imap, jabber) only from a vpn network and not coming from a really network device. Usually it this is easy to do by configuring a service to just listen on the vpn interface.

Unfortunately this creates a problem when starting up a machine. The vpn connection is usually established some time after the networking is established. The services that should listen on the vpn interface are usually started before the vpn service has setup the vpn connection. Most services fail to startup in that case because the interface they should bind to is not there (yet).

Systemd can be configured to start the services in the right order but I found it hard to find working advice for doing that. So this is the way.

  1. Create a copy of the .service-file responsible for the service you want to start after openvpn in /etc/systemd/system. This is required as you are not supposed to ever modify .service files in /usr/lib/systemd directly.

    cp /usr/lib/systemd/system/[yourService].service /etc/systemd/system

    Units found in /etc/systemd/system will overrule the units from /usr/lib/systemd/system
  2. You need to modify the copied service file in /etc/systemd/system. Place this lines in its [Unit] section:


    Note: If there are already Wants or After directives in the file, place the sys-devices-virtual-net-tun0.device behind the existing directive seperated with a space. Wants and After accept multiple units but they must be space seperated.
    Note: This assumes that the vpn you want the service to wait creates the tun0 device. Systemd creates units files for network interfaces that show up. The lines above make systemd wait for tun0 to show up before it starts the modified service.

When you have enabled your service with “systemctl enable” it should now startup after the vpn connection has been established.

This should work with any vpn technology as long as you make sure to use the right device file. If your vpn is behind interface tun1 you should use sys-devices-virtual-net-tun1.device instead of sys-devices-virtual-net-tun0.device.

Running Kodak Scanmate i940 with Linux

I just want to share some insights about using the Scanmate i940 scanner using a linux distribution.  Kodak is claiming Linux support for that scanner and is providing a driver here.On its website Kodak states that specifically Ubuntu 12.04 LTS is supported. But this is only partially true. Here is what I found out about this driver:

  • The drivers is x86 32-bit only! This is a major drawback. You can run the scanner with a 64-bit system, but you have to install sane and all applications which are supposed to access the scanner in 32-bit. There is not much hope of being able to run the scanner using an ARM based Raspberry Pi too.
  • The driver actually contains a setup script, which supports far more than just Ubuntu. Judging from the code It is able to handle Debian, Ubuntu, Fedora (and RedHat-Clones) and OpenSuse out of the box
  • BUT it requires the existence of a and aborts when it cannot be installed. This causes the setup script to break on ALL RECENT linux distributions. The has been phased out for from Ubuntu 13.04 and Fedora 18 upwards

So far, so bad. The linux driver is outdated. At last judging from the look of the windows installer, this is true for the windows driver too (still, that one works).

I managed to get the scanner running with Fedora 20 64-bit. This are the steps which resulted in success.

  • Install a in the system. I forced in a package from a previous Fedora version. A similar step should work on other operating systems too.
  • Modify the setup script in a way that it does not break because of a missing and does not try to install it. Make sure it runs through.
  • Make sure the sane binaries and all applications which should be able to see the scanner are installed in 32-bit and have dependencies fullfilled

After that the scanner worked for me. I tested it under Windows too and the image quality looks like the same. So at least no drawback here. But I see another bigger bug with the linux driver: full duplex scanning does not work. The scanner is able to scan both sides of a page – but that does not work with linux driver. Duplex scanning works only in xsane, but not in more user-friendly apps like simple-scan.

I contacted the Kodak support about the problems of their linux driver. On the positive side they were quick to respond and supportive. A updated linux driver for Ubuntu 14.04 is in the works but there is not date when it can be expected.

As long as there is no updated driver available (I update this article as soon as I get it), I cannot recommend buying this scanner if you want to run it with linux. Not as long as you are not comfortable with the steps outlined above to make it work.


Update 25.1.2015:

I just found the updated driver 3.1 for the kodak i940 on the kodak webpage. It says it supports Ubuntu 14.04 and there is a 64-bit driver. So this driver finally comes out of the stoneage.

I was able to run the setup script on Fedora 21 flawlessly. The scanner now finally is able to scan several pages in one run. Unfortunatly the full-duplex scanning is still only working in xsane where you can choose the (driver specific) mode for that.

Fedora 20 on the Omnibook 4150B

I successfully upgraded this pre 2000 laptop to Fedora 20. Everything went smooth. You can hardly see a difference.

Still, the laptop is missing a usage because of its slowness. Even watching videos became hardly possible after some acceleration drivers for the old mach64 chipset had been removed from Xorg.

The situation will become worse when the drivers for old graphic chips will be purged completely in Fedora 21. From then on only VESA drivers will be available for showing a desktop.

If someone still wants to run a desktop on such an old machine, the current debian stable release is probably a much better choice.

Fedora 20 with Gnome 3.10 works again on the wetab

After having input problems in Fedora 19 (previous post) which made the Gnome desktop unuseable – I can now happily confirm that the problem is solved in Fedora 20. I can work with Gnome 3.10 as you expect it on the touchscreen.

The system is running quite slow nonetheless. This may be caused partially with the SSD slowing down during write access – but what can you do about that with an SSD without TRIM support?

Ramdisk/USB-Disk Raid-1 on a Raspberry Pi

I’m using tinyrss as an RSS reader software which is running on my raspberry pi. While its performance is acceptable I’m always wanting it to be a little snappier. Judging from watching top output the pi is most of the time busy with the

Made from a shoe box. Contains a pi, two usb disk, powered usb switch and a 1000 MBit/s ethernet switch.

My selfbuilt Pi-server rack. Made from a shoe box. Contains a pi, two usb disk, powered usb switch and a 1000 MBit/s ethernet switch.

mysql process. I already tried every hint in the web to make mysql faster. I switched from InnoDb to MyISAM (that helped) and tuned the buffers.

I suspected one of the reasons for the slowness the small usb disks on which the mysql databases are saved. That disks are not fast and using the slow USB 2.0 interface. So what would be a faster disk which would not be bottlenecked by the usb interface?

As even the PIs card reader is quite slow and even the ethernet adapter is connected internally via USB I can only think of one faster storage space: the RAM. A ramdisk would provide the fastest storage the pi can offer.

Why a Ramdisk/Disk RAID-1

According to this (german) Heise article it is possible to run a fast ssd in conjunction with a slow hdd in a RAID-1. Readings would be provided by the fast disk. The write speed is limited to the speed of the lower disk. This way you can save your money for just one SSD and use a cheap HDD as the backup disk. I already installed such a setup successfully on desktop pc.

My idea was to use a ramdisk as the fast disk and a slow partition on a usb stick as the slow write disk. The advantage of this setup would be that you have the speed of the RAM when reading data but still can be sure that your data is saved to mass storage on the usb partition. You do not have to worry about restarts and crashes, the ramdisk would be filled with the latest data from usb disk at each startup. Pretty nice. So lets try it out.

Building a Ramdisk/Disk RAID-1

As the PI does only have 512 MB of RAM there is not much room for a ramdisk. However, was my tinyrss database is only 70 MB in size and usually not more than 100 MB of RAM are used in the pi – there is some RAM left that can be used for experiments. I decided to spent 250 MB of RAM for the ramdisk.

The first thing you need is a ramdisk. You cannot use tmpfs as it does not provide a block device. Instead of that you have to use the /dev/ram* devices. By default they are only 4 MB in size. This must be changed by kernel boot parameter.

Add this option to the command line in /boot/cmdline.txt


After reboot the ramdisks provide 250 MB of space.

Let’s check the speed of the ramdisk:

sudo hdparm -t /dev/ram0
 Timing buffered disk reads: 250 MB in  2.35 seconds = 106.54 MB/sec

Well, a PC can do much more, but compared to the usb disk it is really fast.

sudo hdparm -t /dev/sda
 Timing buffered disk reads:  70 MB in  3.03 seconds =  23.12 MB/sec

Moreover in the ramdisk file access should be more or less instant what is even more important.

Now lets create the raid. I used a small partition on an usb stick as sda1.

sudo mdadm --create -n 2 --level=1 /dev/md0   /dev/ram0 --write-mostly /dev/sda1

And now lets check the read speed on the newly created raid:

sudo hdparm -t /dev/md0
 Timing buffered disk reads: 202 MB in  3.03 seconds =  66.73 MB/sec

Well, much faster than the usb partition alone!

Running mysql from ramdisk/usb raid-1

Afterwards you have to create file system on the raid device /dev/md0 and mount it. I copied the database files from my usb disk to the raid device and pointed the mysql data directory to there.

After restarting the mysql server I did some benchmarks whether tinyrss runs faster in this setup.

Interesting idea, but not faster

In the end the database running from the raid was a little bit slower than when running from the usb disk. So my experiment was a failure.

The mysql database is clearly CPU and not I/O bound. As the data access via raid requires more CPU power it is obvious that the raid slowed things down. The faster access thanks to the ramdisk does not matter.

For this case I gave up the idea of a ramdisk/disk raid-1 because it did not make anything faster. However, there might be other use cases which are not CPU bound. In that cases this might be an idea worth to try out.

Having instant access to your data in RAM and having it written onto a harddisk at the same time might be interesting for some people out there.

Wetab with Fedora 19 and Gnome 3.8 – failure

As described in a previous entry I was quite satisfied with Fedora and Gnome 3.6. running on the wetab. The good impression ended after updating to Fedora 19.

It’s a simple and stupid problem. The Gnome 3.8 shell is simply not recognizing touches on the screen as clicks anymore. Tapping on buttons in the top bar does select them somehow, but does not open open them. That way the interface is unusable, especially as the virtual keyboard is affected by the same problem and is not putting out any key input.

Well, I found out that I can open the “activities” when I slide with the finger to top of the activities button. After that some interaction with the UI elements is possible. Even the virtual keyboard works. But this stops as soon as I leave the activities view and try to enter i.e. an address into the address bar of a browser. Again, the virtual keyboard does not recognize any taps what makes the system unusable.

You cannot even log out from Gnome 3 without attaching a mouse to the wetab.

After this failure I switched the Wetab to KDE. It’s not that optimized for touchscreen usage – but at last I can interact with it via the touchscreen. Sadly the auto-rotation of the screen does not work with KDE. But if you login via GDM you can at least rotate the screen in the correct direction before entering KDE.