KVM/Qemu VMs with a multi-screen Spice console – III – local access with remote-viewer via a Unix socket

In the last article of this series

KVM/Qemu VMs with a multi-screen Spice console – II – local access with remote-viewer via a network port
KVM/Qemu VMs with a multi-screen Spice console – I – Overview over local and remote access methods

I discussed "remote-viewer" - a tool to access the graphical Spice console of a virtual machine [VM] on a KVM/Qemu host. Although remote-viewer is thought to be used over network connections, you can also use it locally on the virtualization host itself, e.g. in a desktop virtualization scenario.

To get an overview we first had a brief look at some central libvirt and qemu configuration files which control the interaction of Spice clients with the libvirtd daemonand/or the Qemu-emulator. We then defined a network port (e.g. 20001) in the Spice related entry of the VM's XML configuration file. This file is evaluated when you start a Qemu VM with virsh or virt-manager. Afterward we could access the Spice console of the VM by entering


on a terminal in a graphical desktop session on the KVM host. If the host had an IP like


would in principle work, too. But a successful outcome may, of course, depend on local firewall settings for your network devices.

We verified that remote-viewer supports a multi-screen presentation of any major graphical Linux desktop started on the VM. Present versions of KDE and Gnome on a Kali/Debian/Opensuse guest automatically adapt to changes of the user's Spice client windows (on the host's desktop). XFCE, however, requires a manual configuration of the virtual screens with tools of the guest OS.

I also demonstrated that a Spice console session corresponds to a fragile "one seat" situation: Other local or remote users can kick us out of our Spice session at any time. We could at least protect us against unauthorized session switches by defining a password for the Spice console. So far, so good.

But: Local access via a network port is certainly not the fastest method for local user interaction with a VM: Each transaction triggers operations of a TCP network stack. Can we get around this?

Yes, we can - by working with a Unix socket on the VM host. This is the subject of this article. While we prepare a Spice socket configuration for remote-viewer we also answer the question which sockets the libvirtd daemon offers for its client.

We use our test VM "debianx" again, which has a Kali OS installed together with multiple desktops to choose from (Gnome, KDE, XFCE). The KVM/Qemu host is a Opensuse Leap 15.2 system with a KDE desktop.

Documentation? Not really ...

I did not find any hints in the Opensuse documentation on virtualization of how to use remote-viewer with a Unix socket. Neither the man pages, nor other user-friendly descriptions of remote-viewer gave me a clue. I got a socket based approach to work after an accidental view into two discussions on the Internet plus a bit of trial and error. These are links to the discussions I referred to:


You may find a description of socket based configurations for Spice also in articles on Virgl3D based rendering - a local socket based configuration is essential there.

Spice access via a socket

The first article of this series contains a schematic drawing which shows various access methods to the Spice console of a VM. However, aside TCP ports I had not displayed any Unix sockets there. The following picture gives you an idea how such a local alternative could look like:

You should not take the direct connections to the Spice console too literally. Of course, the real interaction occurs between remote-viewer and the Qemu-emulator.

In the drawing I also indicated that libvirt-based tools (as virt-manager, virt-viewer), which do not directly interact with the qemu-emulator, use a specific socket which is automatically created at a standard location on Opensuse Leap 15.x systems.

Off topic: What sockets are used by virt-manager and virt-viewer?

Actually, libvirtd exposes multiple sockets to libvirt clients - each for a specific purpose; see
for details.

Virt-manager has its own graphical console window. Select a running VM and simply choose the menu-point "Open" to open a Spice client window on your host.

Note: In contrast to remote-viewer and also virt-viewer, virt-manager does not allow you to open multiple "screen"windows.

In a terminal window we ask "netstat" to inform us about relevant active sockets; just for interest we also look into related directories:

MySRV:~ # netstat | grep libv
unix  3      [ ]         STREAM     CONNECTED     554391   /run/libvirt/libvirt-sock
unix  3      [ ]         STREAM     CONNECTED     513499   /run/libvirt/libvirt-sock
unix  3      [ ]         STREAM     CONNECTED     554599   /run/libvirt/libvirt-sock
unix  3      [ ]         STREAM     CONNECTED     515826   /var/lib/libvirt/qemu/domain-1-debianx/monitor.sock
unix  3      [ ]         STREAM     CONNECTED     513581   /run/libvirt/libvirt-sock
MySRV:~ # 
MySRV:~ # la /run/libvirt/ | grep sock
srw-------  1 root root    0 Mar  9 17:48 libvirt-admin-sock
srw-rw-rw-  1 root root    0 Mar  9 17:48 libvirt-sock
srw-rw-rw-  1 root root    0 Mar  9 17:48 libvirt-sock-ro
srw-------  1 root root    0 Mar  9 17:48 virtlockd-sock
srw-------  1 root root    0 Mar  9 17:48 virtlogd-admin-sock
srw-------  1 root root    0 Mar  9 17:48 virtlogd-sock
MySRV:~ #
MySRV:~ # la /var/lib/libvirt/qemu/ 
total 44
drwxr-x--- 10 qemu qemu 4096 Mar  9 17:48 .
drwxr-xr-x 11 root root 4096 Oct 26 11:01 ..
drwxr-xr-x  3 qemu qemu 4096 Apr  2  2017 channel
drwxr-xr-x  2 qemu qemu 4096 Nov 16 17:56 checkpoint
drwxr-x---  2 qemu qemu 4096 Mar  9 17:48 domain-1-debianx
drwxr-xr-x  2 qemu qemu 4096 Apr  2  2017 dump
drwxr-xr-x  2 qemu qemu 4096 Apr  2  2017 nvram
drwxr-xr-x  3 qemu qemu 4096 Sep 10  2018 ram
drwxr-xr-x  2 qemu qemu 4096 Apr  2  2017 save
drwxr-xr-x  2 qemu qemu 4096 Apr  2  2017 snapshot
MySRV:~ #
MySRV:~ # la /var/lib/libvirt/qemu/domain-1-debianx/ 
total 20
drwxr-x---  2 qemu qemu 4096 Mar  9 17:48 .
drwxr-x--- 10 qemu qemu 4096 Mar  9 17:48 ..
-rw-------  1 qemu qemu   32 Mar  9 17:48 master-key.aes
srwxrwxr-x  1 root root    0 Mar  9 17:48 monitor.sock
MySRV:~ # 

By the way: A nice tool to list sockets is "ss"; try "ss -axeo | grep libv" or

ss -a --unix -p | grep virt

for instance.

Some sockets obviously have very restrictive rights settings. However, the rights situation seems to be totally relaxed for two of the sockets in "/run/libvirt". As we shall see in a minute these sockets are the relevant ones for Spice clients using libvirt.

Readers of the last article may have guessed that we configure access rights to these sockets in the file "/etc/libvirt/libvirtd.conf". Sorry, but on a standard Opensuse Leap system this is wrong. Instead the sockets are created by systemd during the start of the libvirtd.service. See the respective files libvirtd.service, libvirtd.socket, libvirtd-ro.socket in the folder "/usr/lib/systemd/system":

MySRV:/usr/lib/systemd/system # cat libvirtd.service 
Description=Virtualization daemon
# Use Wants instead of Requires so that users
# can disable these three .socket units to revert
# to a traditional non-activation deployment setup

and e.g.

MySRV:/usr/lib/systemd/system # cat libvirtd-ro.socket
Description=Libvirt local read-only socket

# The directory must match the /etc/libvirt/libvirtd.conf unix_sock_dir setting
# when using systemd version < 227


A standard rights setting of "666" is used. You could change this in a special local file under "/etc/systemd/". We shall return to respective settings in another article.

Virsh and virt-manager require a (rw) socket which allows for VM re-configuration, i.e. writing operations to the Qemu-emulator configuration data for a VM. This socket is "/run/libvirt/libvirt-sock".

Regarding access to a Spice console, however, a so called "ro"-socket, namely "/run/libvirt/libvirt-sock-ro", is sufficient. You can verify this by trying

virt-viewer -c qemu:///system?socket=/run/libvirt/libvirt-sock-ro

The "ro" refers to a denial of configuration writing and changes of Qemu-process parameters controlling the VM. It is NOT directly related to the Linux access rights of the socket itself. Actually, the socket is a "stream" socket; this already implies that the user needs write access to it. Which is given in an Opensuse Leap system. See the generous "rw-rw-rw-"-setting in the listings above!

This raises the question:
What restricts the access to these libvirt standard sockets at all on an Opensuse Leap system?

Its a policy setting; see the Opensuse documentation in "Virtualization guide - Connecting and authorizing". More on this topic in another article.

How would we specify an URI, which points to a Unix-socket, for remote-viewer?

To force remote-viewer to use a Unix socket we first have to find out how we specify an URI pointing to such a socket. Well, the first of the named articles above together with the man-pages for remote-viewer gives us an idea. The right form for a local access is:

remote-viewer -v spice+unix://Path-To-Socket

Note that a path down from the root "/" of the Linux directory tree will lead to three "///" !

You cannot use the libvirtd-sockets with remote-viewer!

Can we use the sockets provided by libvirtd with remote-viewer? The answer is: No. More precisely: I do not know how, if it should work against my expectations. We use the above recipe and try:

MySRV:~ # remote-viewer -v  spice+unix:///var/lib/libvirt/qemu/domain-1-debianx/monitor.sock
Guest (null) has a spice display
Opening connection to display at spice+unix:///var/lib/libvirt/qemu/domain-1-debianx/monitor.sock

With the result:

Something equally negative happens with

MySRV:~ # remote-viewer -v spice+unix:///run/libvirt/libvirt-sock
Guest (null) has a spice display
Opening connection to display at spice+unix:///run/libvirt/libvirt-sock

(remote-viewer:22055): GSpice-WARNING **: 19:29:01.691: incomplete link header (-104/16)

We are stuck. Well, it would have been too simple. And it would have been strange, too, because remote-viewer was made to directly access Qemu. So, the next logical question is:

How can we tell Qemu to provide a suitable Unix socket for the Spice console?

Required settings in the XML domain file for the VM => specify a socket for the Spice item

We can use the information provided in the Red Hat bug tracker mentioned above. We guess that we can change the Spice settings according to the following pattern in the VMs' domain definition file "/etc/libvirt/qemu/debianx.xml":

    <graphics type='spice' autoport='no' keymap='de' defaultMode='insecure'>
      <listen type='socket' socket='/tmp/spice.socket'/>
      <image compression='off'/>
      <gl enable='no'/>

You see that I choose the "/tmp"-directory to create a socket. The directory must of course be writeable. For whom? And which access rights will our aspired socket get?

It is reasonable to assume that we will see the rights of the specific system user, which is used to run Qemu processes for VMs. We already saw in the last article that this is the user named "qemu" (single member of group "qemu") on a standard Opensuse system.

OK, let us see whether we can start our "debianx" test VM with this new Spice item in its XML configuration.

No problem! To check whether the VM really is operational we start virt-manager's integrated Spice console window and log into Kali's KDE desktop:

No problem there either.
Note the settings for the Spice window - the last menu point must be checked to guarantee an automatic adaption of the VM's desktop to the dimensions of the Spice console window.

If you now would use

virt-viewer -c qemu:///system?socket=/run/libvirt/libvirt-sock-ro

again, virt-manager's Spice window would be closed (one seat!) and a virt-viewer window would open (NOT a remote-viewer window; see the top bar of the window below).

But all of this is no proof that a new socket has been created. virt-manager and virt-viewer use the sockets "/run/libvirt/libvirt-sock" and "/run/libvirt/libvirt-sock-ro" (to connect to libvirtd) - as we already know. But a look into the "/tmp"-folder

MySRV:~ # ls -lisa /tmp | grep spice
1452545    0 srwxrwxr-x   1 qemu  qemu        0 Mar 13 14:31 spice.socket
MySRV:~ # 

actually shows that we indeed have a new socket. We get an additional confirmation by netstat:

MySRV:~ # netstat -ax | grep spice
unix  2      [ ACC ]     STREAM     LISTENING     137989   /tmp/spice.socket
MySRV:~ # 

Remote-viewer with a local Unix socket

Let us use the prepared socket as user "uvma". Unfortunately, a first trial with

remote-viewer spice+unix:///tmp/spice.socket

fails due to insufficient access rights. Obviously, the user "uvma" needs write rights on the specified "stream" socket.

The most simple solution for the moment is to add the user "uvma", which we already put into a privileged group "libvirt" in the last article, to the group "qemu", too. (This is probably not the best solution. We come back to security aspects later.) But for the time being we enter (as root)

usermod -a -G qemu uvma

As user "uvma" we afterward log out and in again to our desktop session on the host. In a terminal window we then enter (as user "uvma")

remote-viewer spice+unix:///tmp/spice.socket

It works! A new Spice client window for remote-viewer is opened. I added one more "screen" and also started some applications to see, if we can really interact with the VM - which is indeed the case. Even sound works (if pulseaudio is used on the host):


Security considerations

Besides an improved performance, working with a Unix socket avoids opening a network port and related potential security issues. But, as we saw, we need some special rights for such a scenario. Which also has security implications ....

Regarding this point I do not think that putting a user into the "qemu"-group is a good idea. Well, you could argue that our user "uvma" is already privileged regarding VMs. Yes, true enough. But we may change this in the future and separate users which can use virt-manager from others which use remote-viewer for a specific VM: The user who gets the right to open the Spice console may be different from the special user which is allowed to start the VM.

Another problem is that a user being member of the qemu group has almost the same rights as the "qemu"-user itself. But, in contrast to the special user "qemu" on an Opensuse Leap system, a normal user as "uvma" has a login-shell:

MySRV:/etc/libvirt/qemu # cat /etc/passwd | grep qemu
qemu:x:484:483:qemu user::/sbin/nologin
MySRV:/etc/libvirt/qemu # cat /etc/passwd | grep uvma

"uvma" needs a login-shell as he/she shall work with remote-viewer in his/her desktop session on the host. So, if this user gets hacked (e.g. via a browser bug) this would have consequences for all VMs on the host.

We can at least confine a selected user's impact to a specific VM. Let us take a user "uvmb". We want to allow this user to access our test-VM "debianx" locally via a socket - but only this VM!

For this purpose we create a special group "spicex" and add both "qemu", "uvma" and "uvmb" to this group.

usermod -a -G spicex uvmb
usermod -a -G spicex uvma
gpasswd -d uvma qemu

We also remove user "uvma" from the "qemu"-group.

Then we create a special directory "/var/spice/spicex". You can, of course, choose a different path. We set the group of this folder to "spicex". Then we set the "s"-flag on the group and use ACLs to enforce a default group for the user and the group with certain rights on an files created in this folder.

chown qemu.spicex /var/spice/spicex
chmod g+s /var/spice/spicex
setfacl -dm u:qemu:rwx,g:spicex:rwx,other::--- /var/spice/spicex

In addition we stop our VM and change its XML configuration to

    <graphics type='spice' autoport='no' keymap='de' defaultMode='insecure'>
      <listen type='socket' socket='/var/spice/spicex/spice.socket'/>
      <image compression='off'/>
      <gl enable='no'/>

Afterward we restart the libvirtd-daemon. That's it. Te next time, you start your VM by virt-manager as "uvma" you get something like

MySRV:/var/spice/spicex # la
total 12
drwxrws---+ 2 qemu spicex 4096 Mar 17 19:26 .
drwxr-xr-x  9 root root   4096 Mar 15 16:32 ..
srwxrwx---+ 1 qemu spicex    0 Mar 17 19:26 spice.socket

Now, you change to user "uvmb" by logging out and starting a new X-/KDE-session on the host or by just entering "su - uvmb" in a terminal. We login as "uvmb" and try

uvmb@MySRV:~> remote-viewer -v  spice+unix:///var/spicex/spice.socket

This should work; if you stayed in the KDE session of user "uvma" you probably get some error messages regarding audio and a denied pulseaudio access. But the Spice graphics should be OK. Similar precaution measures should be taken for other VMs. ACLs give you enough flexibility to control VM-specific access. Now, you could remove "uvma" from group spicex - and get some kind of tool access segregation. It would not make much sense however as long as uvma still is privileged by being a member of the libvirt group; uvma still can open the Spice console at any time via libvirtd and its special sockets. Regard "uvma" as a VM administrator.

The configuration of a VM with a Unix socket has the advantage that we can control the Spice session access, and thereby a potential session switch to another user, a bit better. We restrict the access to libvirtd to selected members of an administrative group and the access to the socket to a selected user of the VM. Though it does not hurt to have a password in place in addition ...

Off topic hint 1: Adjustment of Spice screen positions relative to each other on the guest system

When you open a second Spice windows with remote-viewer it is not guaranteed that the guest's desktop system initially places these virtual Spice screens seamlessly side-a-side. But both KDE, Gnome and XFCE provide graphical tools to adjust the geometrical relation of multiple screens. With the help of these tools you can specify how relative corner positions of the virtual screens are handled. You only have to do this once, afterwards you can move your Spice windows around on the host's desktop as you like :

Relative positioning of two virtual Spice screens with the monitor tool of the guest's KDE desktop

Independent positions of the Spice windows on the KDE desktop of the KVM/Qemu host

Even resizing of the Spice windows won't disturb the relative position definition of the virtual screen corners in the guest.

Off topic hint 2: Workaround for faulty Clipboard interaction between the KDE sessions on the host and in the Qemu guest VM

I noticed a strange dis-coupling between the functionality of the clipboard of KDE main session on the host and the clipboard of guest VM's KDE session. Due to the spice-vdagent they should work seamlessly together. It looked OK in the beginning for the exchange of data between the host and the VM. However, when I tried to copy between two terminal windows on the host I got error message in the terminal from which I started the guest VM:

Spice-CRITICAL **: 14:46:03.424: clipboard_request: assertion 's->clipboard_by_guest[selection] == FALSE' failed

And no data were copied! This disappeared as soon as I activated the "system" tray in the control bar of the guest's KDE desktop, activated the clipboard entry there and adjusted the clipboard settings there to those of the KDE session on the host.


Remote-viewer works very well with a local Unix socket instead of a TCP socket as the interface to the Qemu-emulator process of the VM. A socket based local access scenario to a Spice console can easily be configured via respective settings in the XML-definition file of a VM. However, to improve security you should avoid adding a standard user who wants to use remote-viewer to the "qemu" group. Involving ACL rights will help you to confine users to access the Spice console of specific VMs via placing a socket into a specific directory and controlling access to it and its contents.

Note by the way that using Unix sockets locally on the host also allows for a new remote-access scenario via SSH. Such a scenario could even be more efficient than a TLS encrypted standard connection over a network port in a LAN. Much to discover! Stay tuned. In the next article

KVM/Qemu VMs with a multi-screen Spice console – IV – remote access via SSH, remote-viewer and a Unix socket

I will show you how to use remote-viewer via SSH.


The ss-command to list up sockets

lbvirt and authentication on Opensuse

SSH – Qt5-Anwendungen – KDE/Plasma 5 – falsche Fonts und fehlende Icons

Wenn man sich unter KDE 5 mit
"ssh -X remoteuser@sshhost"
auf einem Host "sshhost"einloggt und dann Qt5-Anwendungen startet, werden die in der Regel nicht richtig angezeigt: Es fehlen Icons und die Fonts sind falsch.
("remoteuser" und "sshhost" sind im Beispiel natürlich nur Dummy-Bezeichnungen, die durch richtige Werte ersetzt werden müssen.)

Ursache des Darstellungsproblems:
Qt5-Applikationen suchen die Einstellungen der aktuell laufenden Desktopumgebung - im Beispiel also auf auf dem per SSH angesprochenen Host "sshhost". Dort wird aber KDE nicht erkannt, weil eine Umgebungsvariable nicht gesetzt ist, die normalerweise beim Start der Desktop-Umgebung belegt wird. Dort läuft ja aber für die ssh-Shell gar kein Desktop.

Ich hatte das Problem schon mal behandelt - allerdings für root-Shells und lokale Starts von Qt5-Anwendungen auf ein und demselben System (siehe https://linux-blog.anracom.com/2016/01/27/opensuse-leap-42-1-kde-5-unzureichende-darstellung-und-kleine-fonts-in-qt5-anwendungen-die-von-root-gestartet-werden/).

Die gleiche Thematik verfolgt einen aber natürlich auch in Shells, die mit SSH geöffnet werden.

Man kann der SSH-Sitzung die notwendige Umgebungsvariable am Prompt nachliefern. Nämlich über:

remoteuser@sshhost:~>export XDG_CURRENT_DESKTOP=KDE

Erfolgte die SSH-Sitzung aus einem Gnome-Desktop heraus, so wählt man natürlich eher:

remoteuser@host:~>export XDG_CURRENT_DESKTOP=GNOME

Arbeitet man lokal und remote grundsätzlich nur unter KDE, so kann man die Einstellung


auch in der Datei "~/.profile" verankern. Die Umgebungsvariable wird dann für alle Login-Sitzungen gesetzt.

Arbeitet man allerdings nicht nur remote auf dem Host "sshhost" und wechselt man dort (!) gelegentlich zwischen KDE und Gnome, so ist wohl eine vorherige Abfrage in der "~/.profile" sinnvoller - und man entscheidet sich nur im Zweifel für KDE:


Bessere interaktive Lösung:
Man verankert in der "~/.profile" für den Fall einer SSH-Verbindung eine interaktive Abfrage, die den SSH-Nutzer festlegen lässt, welche Desktop-Umgebung den anschließend gestarteten Qt5-Anwendungen vorgegaukelt werden soll. Die entsprechende Desktop-Umgebung muss auf dem SSH-Host natürlich vom User konfiguriert worden sein.

Der Aufbau eines entsprechenden Shellskripts ist eine nette kleine Übungsaufgabe, bei deren Lösung ggf. folgender Link weiterhilft:

Nachtrag 01.11.2016: SSH, KDE und User root

Will man aus irgendwelchen Gründen für den User "root" über SSH grafische Anwendungen starten, so nützt im Gegensatz zur Situation in einer bereits laufenden grafischen KDE-Umgebung nichts, einfach "kdesu ..." zu benutzen. Wir hatten dieses Vorgehen im Artikel Opensuse Leap 42.1 / KDE 5 – unzureichende Darstellung (kleine Fonts, fehlende Icons) von Qt5-Anwendungen, die von root gestartet werden empfohlen. Ist eine SSH-Shell dazwischengeschaltet, so muss die oben erläuterte Umgebungsvariable vor Anwendung des "kdesu"-Befehls für eine grafische Qt5-Anwendung explizit gesetzt werden.

Opensuse Leap 42.1 mit KDE 5 – Eindrücke nach 2 Monaten Nutzung – anfänglich viel Schatten, nun ein wenig Licht …

Ich sag's mal gleich vorweg:

Leap 42.1 gehört aus meiner Sicht nicht zu den Opensuse Versionen, die sich auf einem Desktop-System auf Anhieb problemfrei installieren und danach ohne weiteres auf persönliche Bedürfnisse hin umkonfigurieren lassen.

Diese Aussage bezieht sich vor allem auf die auf DVDs ausgelieferte Version bzw. auf die Download-Version von Anfang Januar 2016. Die war und ist aus meiner Sicht eher ein kleines Desaster und keineswegs Werbung für das Leap-Projekt im Sinne einer stabilen Linux-Version für einen KDE-Desktop.

Viele der Probleme hatten und haben allerdings wohl mit KDE 5 zu tun - und können daher nicht unbedingt Opensuse angelastet werden. Auf meinem Testsystem sind auch OS 13.2 und OS 13.1 installiert und konnten seit geraumer Zeit produktiv und stabil genutzt werden. Die im Januar noch regelmäßig festgestellten Abstürze und Instabilitäten unter OS Leap 42.1 mit KDE5 sind daher nicht auf die Hardware zurückzuführen.

Die Stabilität des gesamten Leap-Systems hat sich inzwischen - nach zahlreichen Paketupdates und auch Repository-Wechseln - allerdings deutlich verbessert. Man kann inzwischen mit Leap 42.1 produktiv arbeiten - Ende Januar hätte ich diesen Satz so noch nicht ausgesprochen. Hier ein erster Erfahrungsbericht.

Produktives Opensuse 13.2 auf jeden Fall weiternutzen und nicht upgraden

Grundsätzlich würde ich jedem, der über einen Wechsel nachdenkt, empfehlen, ein stabil laufendes Opensuse 13.2 auf keinen Fall aufzugeben oder upzugraden. Der von mir selbst regelmäßig gewählte Ansatz, ein neues Opensuse-Release (speziell mit einer grundlegend neuen KDE-Version) zunächst in einer separaten Partition als das aktuell produktive Desktop-System zu installieren und auszuprobieren, erscheint mir gerade im Fall von Leap 42.1 der absolut richtige zu sein. Es gibt immer noch Dinge, die mich ab und zu veranlassen, wieder OS 13.2 zu benutzen.

Neuerungen und der Hybrid-Ansatz unter Leap 42.1

Neuerungen unter Leap 42.1, wie etwa der Mix aus KDE4 und KDE5 sowie der sog. Hybrid-Ansatz als Mischung aus stabilem Unterbau auf Basis des aktuellen SLES 12 Servers und einem relativ aktuellem Desktop, sind bereits in vielen Reviews beschrieben worden. Ich möchte diesbezüglich daher nur auf einige Artikel verweisen:


Persönlich überzeugt mich SuSE's Hybrid-Ansatz noch nicht völlig. Da wir in unserer kleinen Firma Opensuse aber auch als Server-Plattform einsetzen, erhoffe ich mir - nach einer Phase noch zu findender Stabilität auf der Desktop-Seite - doch langfristig einen einheitlicheren Verwaltungsaufwand für Entwicklungssysteme (mit einigen Serverkomponenten) einerseits und für die von uns genutzten reinen Server- und Virtualisierungsplattformen andererseits. Die größten Probleme mit aktuellem System sehe ich eindeutig auf Seiten von KDE 5 - genauer Plasma 5.

Windows-ähnliches Look and Feel von KDE 5 mit Breeze

Persönlich bekam ich anfänglich fast einen Schock als ich das "Breeze Look&Feel" für KDE 5 vor Augen hatte. Das erinnerte mich doch zu stark an MS Oberflächen. Aber inzwischen habe ich mich daran gewöhnt; zumal man sich doch viele Eigenschaften des Plasma5-Desktops so zurecht biegen kann, dass die Ähnlichkeit zu Windows am Ende recht weitgehend verschwindet.

Dennoch vermisse ich ein wenig die Vielzahl von vorgefertigten Designs und Stilen für Bedienelemente, die unter KDE 4 bereits gegeben war. Ich denke aber, das ist nur eine Frage der Zeit ...

Höhere Stabilität als OS 13.1/OS 13.2 ? Nein, wegen KDE 5 Plasma nicht wirklich ....

Dass OS Leap 42.1 zumindest in Teilen auf SLES 12 aufsetzt, wurde wegen der zu erwartenden Stabilität in vielen Reviews gelobt. Desktop-seitig kann ich diesen Eindruck jedenfalls nicht teilen.

Dies liegt wie gesagt vor allem an KDE. Ich habe mir nämlich mal die reinen Serveranteile in Form eines LAMP-Test-Servers und eines KVM-Test-Virtualisierunsghosts, auf den ich Guest-Images aus einem Produktivsystem migriert habe, auch mal separat ohne KDE angesehen. Fazit: Der Server-Unterbau - ohne KDE-Desktop - wirkt grundsolide.

Eine Standard-Installation der Desktop-Pakete aus dem heruntergeladenen ISO Image führte bei mir dagegen früher oder später zu größeren Problemen. Besonders zu nennen sind vor allem anfänglich extrem häufig auftretende Instabilitäten des gesamten KDE 5 Plasma-Desktops und Probleme mit den Abmelde- und Shutdown-Funktionalitäten. Die ersten 4 Versuchstage im Januar waren von folgenden Erfahrungen geprägt:

  • Erratische Absturzmeldungen von "konsole"-Fenstern,
  • Freezes des Plasma-Desktops (trotz damals aktuellstem Nvidia-Treiber),
  • Abstürze des neuen Window-Managers "kwin_x11"
  • Ungereimtheiten in der Fensterdarstellung, wenn man als User root Qt5-Anwendungen von der "konsole" aus startete. Es wurde/wird dann nicht erkannt, dass die Applikationen unter einer KDE5-Umgebung laufen. Die resultierende reduzierte Darstellung von Applikationen für den User root (zu kleine Schriften, fehlende Grafiksymbole,etc. ...) ist dann mindestens mal ärgerlich. Das ist heute noch so, lässt sich aber umschiffen (s.u.)
  • Erhebliche Probleme mit der Sound-Einrichtung - mit und ohne Pulseaudio.

Siehe auch: https://www.curius.de/blog/13-linux/40-opensuse-leap-42-1-im-test.

Nach vielen Updates sowie Repository-Wechseln für Multimedia-Komponenten sowie zwischenzeitlichem Löschen und Neuaufbau des kompletten "~/.config"-Verzeichnisses hat sich das Bild inzwischen aber verbessert. Zumindest Abstürze und Freezes von Plasma treten inzwischen nur noch äußerst selten auf.

KDE5 bietet aber leider noch nicht die Funktionalität, die unter KDE 4.14 gegeben war; einige liebgewonnene Plasmoide sind z.T. noch nicht für KDE5 umgesetzt oder aber es fehlt noch an gewohnten funktionalen Elementen. Ärgerlich ist zudem der z.T. noch häufig vorkommende Mix aus deutschen, englischen und manchmal auch norwegischen Menü-Einträgen in einigen Schlüssel-Applikationen (wie den KDE PIM-Anwendungen) - wie auch im Bereich der KDE-Systemeinstellungen.

Typisch sind auch kleinere Ungereimtheiten wie etwa die, dass grafische Operationen unter KDE5's Dolphin extrem langsam werden, wenn k3b gleichzeitig CDs rippt, oder Daten zwischen Partitionen kopiert werden, obwohl das System insgesamt weit von einer Auslastung entfernt ist.

Ärgerlich ist auch, dass Symbole im Systemabschnitt der KDE5-Kontroll-Leiste, die nicht speziell für KDE5 entwickelt wurden, keine Funktionalität aufweisen. Sie reagieren auf keine Art von Mausklick. Beispiele sind etwa das "virt-manager"-Symbol oder auch das Symbol der "Open eCard-Anwendung" für den neuen Personalausweis.

Aus dem Reich des wirklich Üblen erwies sich u.a. das Plasmoid zur Ordneransicht auf dem Desktop. Ich sage einfach: Finger weg davon, wenn man sich Ärger ersparen will. Und wenn man "Ordneransichten" dennoch nutzen und Änderungen an deren Konfiguration und Inhalt vornehmen will, dann sollte man das am Besten ausgehend von einem Dateimanager mittels Kopieren von Einträgen in "~/Schreibtisch" und danach durch Anpassen der Einträge der zugehörigen Datei über einen Editor tun. Funktioniert deutlich besser und fehlerfreier als entsprechende grafische Operationen am Desktop selbst (Stand Ende Januar; habe mir das bisher nicht mehr genauer angesehen, sondern verankere nur noch Einzel-Icons auf der Plasma-Oberfläche).

Interessanterweise stürzte/stürzt auch Libreoffice 5 manchmal, wenn auch selten, unvermittelt ab. Das muss jedoch nicht zwingend etwas mit KDE5 oder der GTK-Integration zu tun haben.

In jedem Fall gilt:

Ein Update aller System- und KDE-Pakete sollte nach einer DVD-Installation möglichst unverzüglich vorgenommen werden. Am besten lässt man die Standard-Update Repositories von Opensuse schon zum Installationszeitpunkt einbinden. Dennoch kommen ggf. immer mal wieder Abstürze des Plasma-Desktops, von konsole-Fenstern oder des Window-Managers "kwin_x11" vor. Dann sollte man im Besonderen die Dateien und die Unterverzeichnisse des ~/.config"-Verzeichnisses komplett neu aufbauen lassen. (Z.B. durch Umbenennen dieses Verzeichnisses). Danach verliert man zwar etliche der bislang vorgenommenen Desktop-Einstellungen; der resultierende Aufwand war im Vergleich zum Gewinn an Stabilität aber ein geringer Preis ...

SuSE-spezifische HW-Inkompatibilitäten

Durch einen mehrtägigen Mail-Verkehr mit einem Leser dieses Blogs musste ich leider lernen, dass sich Leap 42.1 auf mancher Laptop-HW (etwa auf bestimmten UEFI-basierten Asus-Systemen) nicht zu einer Installation bewegen lässt, bei der am Ende das Grafik-System, Tastatur, WLAN-Komponenten problemfrei laufen würden. Ganz im Gegensatz übrigens zu "Linux Mint 14" - in dessen KDE-Variante. Kein Wunder, dass Linux Mint in Deutschland die populärste Linux-Distribution geworden ist! Dass Opensuse hinsichtlich der HW-Kompatibilität mit Mint nicht mehr mithalten kann, hat mich als alten Opensuse-Anhänger denn doch etwas deprimiert.

Einige Punkte zur Installation und Grundkonfiguration

Kleine Unterschiede zwischen LEAP 42.1-ISO-Images?
Offenbar gibt es geringfügige Unterschiede in publizierten ISO-Images. Die DVD, die der letzten Easy Linux DVD-Ausgabe beigelegt war, unterscheidet sich in Kleinigkeiten von der des ISO-Images, das man von der opensuse.org-Website herunterladen kann - u.a. durch die Voreinstellung zur Größe der Grub BIOS Partition. Besondere Auswirkungen konnte ich nicht feststellen. Ich habe mich aber dennoch gefragt, was da noch alles unterschiedlich sein mag ....

BTRFS als Filesystem?

Ich habe die BTRFS-Diskussion schon seit Opensuse 13.1 ein wenig mitverfolgt. Nach einigen vorläufigen Tests, die ich unter OS 13.2 durchgeführt hatte, sehe ich für meine Systeme keinen einzigen Grund, im Moment von "ext4" wegzugehen.

Ich bin deshalb nicht den Partitionierungsvorschlägen des SuSE-Installers gefolgt, sondern habe die Linux-Partitionen meiner Systeme durchgehend mit dem Filesystem ext4 versehen. Neben dem auch von Herrn Kofler ins Feld geführten Argument, dass BTRFS komplexer als ext4 ist und vom Administrator entsprechend mehr Wissen verlangt, waren für mich folgende Punkte ausschlaggebend:

Bzgl. Snapshots: Ich setze auf den meisten meiner Systeme sowieso LVM (und die zugehörige Snapshot-Funktionalität) ein. Für Snapshots benötige ich BTRFS deshalb nicht.
Bzgl. Performance: ext4 erscheint mir - zumindest auf SSDs (mit und ohne Raid) - im Schnitt auch für die Systempartition hinreichend schnell zu sein. Für Datenbanksysteme gibt es neben ext4 jedoch deutlich performantere Filesysteme als BTRFS.
Der einzige Serverdienst, der nach meiner Erfahrung wirklich von BTRFS zu profitieren scheint, ist ein NFS- und/oder Samba-Fileserver-Dienst für im Schnitt kleine bis mittlere Dateigrößen.

Aber bildet euch selbst eure Meinung; nachfolgend dazu ein paar Artikelhinweise:


Extrem langsamer YaST-Partitionierungsassistent während der Installation aus einem ISO-Image

Die Installation auf einem bereits komplexen System mit vielen Partitionen und Raid-Systemen erfordert ggf. eigenhändige Partitionierungsarbeiten. Hier werden diejenigen, die eine Installation über ein DVD-ISO-Image durchführen, ggf. eine Überraschung erleben, wenn mehrere komplexe GPT-basierte Harddisk- und Raid-Konfigurationen mit vielen Partitionen unter LVM ausgelesen und bearbeitet werden müssen. Der ursprüngliche YaST-Partitionierungsassistent, zu dem man während der Installation wechseln kann, reagiert dann unglaublich (!) träge. Ganz im Gegensatz zu einfachen Installationen auf einem Laptop mit nur 2 Standard Partitionen (ohne LVM).

Nach einem umfassenden Rundum-Update der Yast- und anderer Leap-Pakete im Anschluss an die Grundinstallation gibt sich YaST's "Partitioner" dann allerdings wieder so spritzig, wie man das von Opensuse 13.2 gewohnt war. Das sind halt die typischen Kinderkrankheiten, wie sie bei neuen Opensuse-Releases mit substanziellen Änderungen immer mal wieder auftreten.

Einbinden von Online-Repositiories während der Installation

Das funktioniert wie gehabt. Je nach Netzkonfiguration und Firewall-Einstellungen ist dafür zu sorgen, dass die DHCP-Zuweisung einer IP-Adresse funktioniert und das System durch evtl. Firewalls nach außen zu SuSE-Servern über HTTP Kontakt aufnehmen darf.

Zusätzlicher Dummy-User für Tests der Desktop-Stabilität

Ich empfehle, nach der Installation einen Dummy-User einzurichten, dessen KDE- und Desktop-Einstellungen man unverändert lässt. Treten mit KDE 5 unerwartete Probleme auf, sollte man erstes immer mal testen, ob auch der Dummy-User darunter leidet - oder ob zwischenzeitliche, user-spezifische Einstellungsveränderungen zu dem Problem geführt haben. Das war bei mir mehrfach der Fall.

Proprietärer Nvidia-Treiber

Der während der Installation automatisch konfigurierte Nouveau-Treiber bringt auf der Nvidia-Karte meines Desktop-Systems mit 3 Schirmen alle Boot-Meldungen (im Framebuffer-Modus) und auch den grafischen Anmeldebildschirm von KDE auf allen 3 angeschlossenen Schirmen zur Ansicht.

Das tut der später installierte proprietäre Nvidia-Treiber nicht mehr - der zeigt Boot-Meldungen nur auf genau einem Konsolen-Schirm (in meinem Fall am DVI-Ausgang der Grafikkarte).

Ein paar Hinweise zur nachträglichen Installation des proprietären Nvidia-Treibers:

  • Schritt 1: Auf Basis des zunächst automatisch installierten Noveau-Treibers das Erscheinen des KDE-Login-Schirms abwarten. In KDE 5 einloggen. Bei mehreren angeschlossenen Schirmen zunächst eine vernünftige Anordnung der Displays herstellen. Da ist u.a. möglich über KFDE's "Systemeinstellungen >> Hardware >> Anzeige und Monitor".
  • Schritt 2: Dann den aktuellen Nvidia-Treiber von "nvidia.de" herunterladen. Ausloggen von KDE.
  • Schritt 3: Ctrl-Alt-F1, um zur Haupt-Konsole zu wechseln. Dort als User "root" einloggen. Das Kommando "init 3" absetzen, um das X-Window-System zu stoppen.
  • Schritt 4: Zum Verzeichnis mit dem heruntergeladenen Nvidia-Treiber wechseln. Dann:

    mytux:~ # bash NVidia-Linux-x86_64-352.63.run

    Sich durch die verschiedenen Meldungen durchklicken. Bestätigen der Anlage eines Files unter "/etc/modprobe.d" (!). Danach alles bestätigen => alle Error-Meldungen akzeptieren. Das nvidia-Treibermodul ist und wird wegen der Fehler nicht geladen, wie man über ein "lsmod | grep nvidia" sehen kann. Nun nicht booten; das führt nämlich auch nicht zu einem Laden des nvidia-Kernel-Moduls im nächsten Boot-Prozess.

  • Schritt 5: Statt dessen init 5 => Einloggen => Schirmreihenfolge noch OK => root-terminal => Dolphin starten => hunderte Fehlermeldungen auf der Konsole tapfer ignorieren.
  • Schritt 6: Unter "dolphin" die Datei "/etc/modprobe.de/nvidia-installer-disable-nouveau.conf" suchen und mit kwrite öffnen. Parallel die Datei "/etc/modprobe.de/50-blacklist.conf" öffnen.
  • Schritt 7: Den Inhalt von "/etc/modprobe.de/nvidia-installer-disable-nouveau.conf", nämlich

    # generated by nvidia-installer
    blacklist nouveau
    options nouveau modeset=0

    mit Hilfe von z.B. kwrite an das Ende der Datei "/etc/modprobe.de/50-blacklist.conf" kopieren. Erst diese Aktion stellt sicher, dass das nouveau-Modul beim nächsten Bootvorgang nicht mehr geladen wird. Die vom Nvidia-Installer bereitgestellte Datei "/etc/modprobe.de/nvidia-installer-disable-nouveau.conf" wird von systemd nicht ausgelesen.

  • Schritt 8: Die modifizierte Datei "/etc/modprobe.de/50-blacklist.conf" speichern und kwrite schließen.
  • Schritt 9: In einem Terminalfenster meldet man sich dann erneut als User root an und setzt den Befehl

    mytux:~ # mkinitrd

    ab. Fehlermeldungen am Ende erneut tapfer ignorieren.

  • Schritt 10: Alle Fenster schließen => Neustart-Button (blau) im Startmenü
  • Schritt 11: Der erneute Boot-Prozess endet dann ggf. in der Hauptkonsole. Falls der KDE-Login-Schirm aufgrund des geladenen langsamen nv-treibers angezeigt werden sollte: Ctrl-Alt-F1 => als User root einloggen => Kommando "init 3".
  • Schritt 12: Nvidia-Treiber erneut installieren - das sollte nun anstandslos funktionieren.
  • Schritt 13: System neu starten (init 6). Nun sollte der grafische KDE-Login-Schirm erscheinen.

Es ist zudem sinnvoll, eine ggf. vorhandene Mehrfach-Schirm-Kombination in der Datei "/etc/X11/xorg.conf" zu verankern. Das sieht in meinem Fall etwa so aus:

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 352.79  (buildmeister@swio-display-x64-rhel04-15)  Wed Jan 13 17:02:24 PST 2016

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 352.30  (buildmeister@swio-display-x64-rhel04-18)  Tue Jul 21 19:35:20 PDT 2015

# 14.01.2016: Modified by Ralph Moenchmeyer

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"

Section "Files"

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Ancor Communications Inc PB248"
    HorizSync       30.0 - 83.0
    VertRefresh     50.0 - 61.0
    Option         "DPMS" "false"

Section "Device"

# Addendum RMO https://bugs.kde.org/show_bug.cgi?id=322060
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 960"

Section "Screen"

# Removed Option "metamodes" "DVI-I-1: 1920x1200_60 +0+0, DVI-D-0: 1920x1200_60 +1920+0"
# Removed Option "MultiGPU" "On"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DP-4: nvidia-auto-select +0+0, DP-0: nvidia-auto-select +2560+0, DVI-I-1: nvidia-auto-select +5120+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "Off"
    Option         "TripleBuffer" "True"
    SubSection     "Display"
        Depth       24

Die Anweisungen im Screen-Bereich sorgen dafür, dass der Treiber beim Starten des X-Window-Systems die Zuordnung der verschiedenen Schirme zu den Grafikkarten-Ports korrekt umsetzt. Danach erscheint die KDE-Login-Oberfläche schließlich auf allen drei Schirmen.

Achtung: Ich rede hier über ein Desktop-System. Eine Nvidia-Installation auf Laptops mit Optimus-Technologie erfordert andere Schritte. Siehe z.B.:
Bumblebee auf Laptops mit Opensuse 13.1 / 13.2
Ich habe das dort beschriebene Verfahren allerdings noch nicht mit Leap 42.1 ausprobiert.

Ist der nvidia-Treiber erstmal installiert, so findet man die Konfigurationsanwendung "nvidia-settings" im neuen Startmenü übrigens unter dem Punkt "Einstellungen".

Im Falle von Mehrschirm-Arbeitsplätzen sollte man abschließend prüfen, dass die Schirmanordnungen und die schirmbezogenen Einstellungen unter "nvidia-settings" mit jenen unter KDE's "Systemeinstellungen => Anzeige und Monitor" sind. (Anfang Januar war das nämlich nicht unbedingt der Fall).

Sound-Konfiguration - schwierig - unvollständige Anzeigen

Zur leidigen Sound-Konfiguration unter Linux mag ich mich schon fast nicht mehr äußern. Wie immer verweigere ich "pulseaudio" (das mit Mehrkanalkarten bis heute nicht vernünftig bzw. nicht fehlerfrei umgehen kann) für den normalen Gebrauch des Desktops die Dienstaufnahme. Das Abschalten von Pulseaudio ermöglicht unter Opensuse auf einfache Weise eine entsprechende Option unter YaST.

Während mir aber unter KDE 4.14 nach einem Neustart unter "Systemeinstellungen => Mulitimedia" für meine 3 Soundkarten eine ganze Phalanx von funktionstüchtigen Alsa-fähigen Geräten unter den Phonon-Einstellungen angezeigt wurde/wird, ist dies bei Opensuse Leap 42.1 mit KDE 5 nicht der Fall.

Das ist durchaus ein Problem: Durch diesen "Fehler" (?) fallen dann auch Änderungen an der Priorität der Devices und ein einfacher Tests unter den Tisch. Solche Dinge treiben mich als Anwender zu Verzweiflungsausbrüchen.


Interessanterweise zeigt aber Amarok 2.8.0, das noch für KDE 4.14.17 entwickelt wurde, unter dem Menüpunkt "Einstellungen > Amarok einrichten => Wiedergabe => Phonon einrichten" alle Alsa-tauglichen Geräte inkl. der selbstdefinierten Alsa-Devices korrekt an!



Es liegt also nicht an der Hardware, nicht am Alsa-System, nicht am Gstreamer-Backend, sondern an irgendwelchen Lücken zwischen der Darstellung der Phonon-Konfiguration unter KDE 5 und Alsa. Da ich zumindest für meine XONAR D2X spezielle Alsa-Profile für den Multikanalbetrieb eingerichtet habe, benötige ich eigentlich die Anzeige der darüber definierten eigenen Alsa-Geräte unter KDE5. Daher mein dringender Appell:

Liebe KDE- und/oder Opensuse-Entwickler: Bitte orientiert euch bei der Programmierung der Masken für die Phonon-Einstellungen nicht ausschließlich an den Features eines (nach wie vor unzureichenden) Pulseaudio-Interfaces. Es gibt Leute, die wollen aus guten Gründen mit einem direkt nutzbaren Alsa-Interface (ohne fehlerhafte Pulseaudio-Zwischenschichten) leben!

Denn auch bei aktiviertem Pulseaudio wird neben den üblichen Problemen (plötzliches Springen auf 100% Lautstärke bei Systemnachrichten; die erzwungene gekoppelte Regelung der Lautstärke von verschiedenen Input und Output-Kanälen, massive Fehler in der Mehrkanal-Regelung, dauerndes ungwolltes Resetten der individuiell gesetzten Lautstärke pro Ausgangskanal auf einen gemeinsamen Wert....) nur eine gebündelte Darstellung von Audiooptionen angeboten - aber nicht die gegliederte Darstellung der alsafähigen Subdevices.

Ich hatte alles in allem erhebliche Probleme, unter Opensuse Leap 42.1 meine Xonar D2X neben der Createive XiFi in der Form zum Laufen zu bringen, wie ich das von Opensuse 13.2 gewohnt war. Aber eine Beschreibung der Schritte würde diesen Artikel sprengen.

Auch Amarok funktionierte nach der Grundinstallation zunächst überhaupt nicht - auch nicht mit Ogg Vorbis-Dateien. Man muss sich da durchkämpfen. In jedem Fall sollte man eine Reihe von sound-relatierten Paketen auf die unter den Packman-Repositories und im Opensuse Multimedia Repository angebotenen Versionen umstellen. Vorabtests selbst definierter Alsa-Devices sind zumindest im Moment noch über das Phonon-Interface von Amarok (aus dem Packman Repository) möglich


systemd ist unter Leap 42.1 wegen des SLES12-Unterbaus noch auf einem veralteten Stand (Version 210). So stehen die für bestimmte Zwecke (wie Virtualisierung) nützlichen Möglichkeiten zur permanenten Konfiguration von z.B. "veth"-Devices in der Datei "/etc/systemd/network" unter Leap 42.1 noch nicht zur Verfügung (wohl aber unter Tumbleweed; systemd-Version 225).

Zur Umgehung eines Problems mit YaST auf Mehrschirm-Systemen siehe
Opensuse Leap 42.1 – nerviger YaST Bug

Erstes Fazit

Insgesamt komme ich nach nun 2 Monaten intensiver Alltags- und Entwicklungs-Arbeit unter Leap sowie vielen Einzeltests zur Sound/Video-Einrichtung wie dem Ausprobieren von KVM/VMware-WS unter Opensuse Leap 42.1 zu dem Schluss, dass z.B. Opensuse 13.2 mit KDE 4.14 immer noch stabiler läuft als Leap 42.1 und sogar mehr Funktionalität bietet.

Inzwischen nutze ich Leap 42.1 aber zunehmend produktiv.

Dennoch habe ich mich zeitweise schon gefragt, ob ich mich nicht langsam nach einer anderen Distribution umsehen sollte. Vielleicht wechsle ich auf meine alten Tage sogar zum Gnome-Desktop. Da ich z.Z. öfter mal mit Debian- und Kali-Systemen arbeite, zeichnet sich die Richtung schon ab ....