Monthly Archives: September 2018

Eclipse Photon 2018-09 für PHP – endlich gute Content Assist Performance

Posted on by

Ende August war ich auf die “R”-Version von Eclipse Photon umgestiegen. Der Start der IDE erwies sich zwar als elend langsam; aber immerhin erschien mir das Zusammenspiel mit GTK3 gegenüber Eclipse Oxygen deutlich verbessert. Auch eine Java10-Runtime-Umgebung ließ sich gut verwenden.

Etwas hat mich jedoch zunehmend bei der Arbeit behindert:
Bei großen PHP-Projekten erwies sich die Content-Assist-Funktion [CA] des PHP Editors als bodenlos langsam. Wenn man den Heap beobachtete, so wechselte der während des Wartens auf eine CA-Antwort ständig die Größe. Gegenüber den in Eclipse ablaufenden Hintergrundsprozessen (Neu-Indizierung vieler Files? Update diverser Oberflächenelemente? …) kam die CA-Funktionalität offenbar erst mit geringer Priorität zum Tragen. Das war völlig irregulär. Mal erhielt man eine Anwtort zu einer lokalen Variable sofort; mal musste man 5- 6 Sekunden warten. Die Meldung “Computing proposals ….” ging mir zunehmend auf den Zeiger. Wer will beim Tippen schon 5 Sek warten, bis der erste Vorschlag kommt? Leider hat keine der angebotenen Optionen unter “Preferences >> PHP >> Editor >> Content Assist” viel geholfen. Auch nicht zur “asynchron Code Completion”. Ich war kurz davor, wieder auf Oxygen zurück zu gehen.

Heute habe ich heute aber die neue “September-Version von Eclipse ( “eclipse-php-2018-09-linux-gtk-x86_64.tar.gz” ) installiert, Updates der “webkit2”-Bibliotheken unter Opensuse vorgenommen und auch die “~/.eclipse”-Eintragungen neu erstellen lassen.

Und siehe da: Die Performance der CA-Funktionalität im PHP-Editor ist nun wieder so wie in alten Zeiten. nach nun 6 Stunden Arbeit kann ich sagen: Das Programmieren mit PHP und Eclipse macht wieder Freude ….

Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Posted on by

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beim Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch “Verbinder” aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 dafür aber viel zu langsam:

Klickt man auf das Symbol für “Verbinder” in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt.

Ich habe nun wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des genau einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Bei einer normalen “LO 6”-ImplementierungInstallation ist das Paket “libreoffice-gtk3” installiert; GTK3 wird dann automatisch gezogen. Ein gezielter Start für GTK3 ist im Terminal mit “SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &” möglich. Nun kann man sich zusätzlich das Paket “libreoffice-gtk2” installieren und den Aufruf zu “SAL_USE_VCLPLUGIN=gtk_kde5” abändern.

Ein nachfolgender Test zeigt, dass die Zeiten beim Einsatz von GTK2 im Bereich von 2-3 Sek. liegen! Damit kann ich gerade noch leben. Weitere Tests offenbaren Folgendes:

Die Geschwindigkeit, mit der Draw die Anzeige von Connector-Punkten aller Objekte auf den Schirm bringt, hängt vom Zoomfaktor ab, mit der man sich das odg-Dokument anzeigen lässt; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf

SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &

erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket “libreoffice-gtk2” installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 und gtk3 sowie eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert – funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller …
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates – und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S. zum Thema Menü-Änderungen: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an?
Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf … und kümmert euch lieber mal um die Performance.

Nachtrag 19.10.2018 zur Performance: Es ist inzwischen insgesamt ein wenig besser geworden (LO 6.1.3); dennoch geht das Arbeiten mit Verbindern in DRAW unter GTK2 immer noch schneller von der Hand als unter GTK3.

 

Upgrade auf Opensuse Leap 15.0 – Probleme mit Nvidia-Treiber aus dem Repository und mit VMware WS 12.5.9

Posted on by

Opensuse Leap 15.0 ist nun schon eine Weile auf dem Markt. Zeit, von Leap 42.3 umzusteigen. Also ein Upgrade durchführen. Geht das problemfrei?

Upgrade von PCs/Workstations

Ich habe Upgrades inzwischen an einem Laptop und auf zwei Linux-Workstations durchgeführt. Ich spreche nachfolgend also nicht über echte Opensuse-basierte Server-Systeme. Die gute Nachricht für Leute, die ihre PCs / Workstations bislang unter Opensuse Leap 42.3 mit ext4 und LVM betrieben haben, ist:

Man kann ohne allzu große Schwierigkeiten auf Leap 15.0 upgraden. Das gilt auch, wenn man eine Reihe von Zusatz-Repositories für bestimmte SW eingesetzt hat (in meinem Fall für Produkte aus den Packman-, Security-, Network-, Forensic-, PHP, Java-, …. -Repositories, die Opensuse eben so anbietet).

Einschränkungen:
Da Leap 15.0 bzgl. BTRFS ein paar neue Features mitbringt, traue ich mich nicht, dieses Statement so auch für Systeme zu machen, bei denen das Root-Filesystem auf BtrFS aufsetzt. Auch Laptops mit Optimus-Systemen habe ich noch nicht umgestellt.

Vorgehensweise für das Upgrade
Man folgt für das Upgrade am besten der unter
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
beschriebenen grundsätzlichen Schrittfolge. Der genannte Artikel beschreibt zwar den Wechsel von Leap 42.2. auf Leap 42.3. Die angegebenen Schritte lassen sich aber ganz analog auch auf ein Upgrade auf von Leap 42.3 auf Leap 15.0 anwenden. Natürlich muss man “Leap 42.2” bzw. “Leap 42.3” in den Vorgaben sinngemäß durch “Leap 42.3” bzw. “Leap 15.0” ersetzen.

Das Upgrade von KDE/Gnome und SSDM/GDM3 funktioniert. Auch Apache2- und MySQL-Dienste werden auf den neuesten Stand gebracht und laufen dann mit den alten Konfigurationen weiter. KVM/Gäste ließen sich in der erneuerten KVM/QEMU/libvirt/spice-Umgebung problemfrei starten. Nach dem Upgrade des System-Kerns bindet man die benötigten zusätzlichen Repositories ein und zieht seine Spezialanwendungen und Multimedia-Anwendungen nach. Bzgl. Multimedia primär über Packman; nur im Einzelfall greife ich auf Pakete anderer Multimedia-Repos zu. Unter Leap 15 unterstützt auch eine Implementierung von JAVA 10 etwa Eclipse Photon bei entsprechender Konfiguration sehr stabil. Das Weiterentwickeln von SW mit Hilfe von Eclipse ist also gesichert. Einzig manche Default GTK3-Styles muss man ändern, um sowohl LibreOffice 6 als auch Eclipse Photon mit Dark Scheme ohne Augenprobleme nutzen zu können (s. hierzu frühere Artiekl im Blog).

Natürlich gibt es im Einzelfall aber doch ein paar knifflige Hürden. Nachfolgend zwei, die mir den Umstieg erschwert haben:

Nvidia-Probleme

Für ein KDE-basiertes System “mytux1”, auf dem ich schon bislang die Nvidia-Treiber aus dem Opensuse-Nvidia-Repository genutzt hatte, funktionierte der Wechsel auf Leap 15.0 anstandslos. Man landet bei der Vorgehensweise des oben erwähnten Artikels zwar zunächst (erwartungsgemäß) im Konsolen-Modus. Dort muss man über die ASCII-Variante von YaST Oberfläche das Nvidia-Repository
https://download.nvidia.com/opensuse/leap/15.0
zum YaST-Software-Management hinzufügen und anschließend die passenden Treiber für sein Nvidia-Kartenmodell installieren. SDDM und KDE5 Plasma kamen nach einem Reboot dieses Systems auf Anhieb hoch.

Schwierigkeiten bereitete aber ein anderes KDE-basiertes System “mytux2”, für das ich seit Jahren aktuelle proprietäre Treiberversionen von der Nvidia Web-Site heruntergeladen und manuell über den Nvidia-Installer installiert hatte. Auf diesem System führte der Versuch einer ersten Treiberinstallation aus den Opensuse-Nvidia-Repositories ins Nirwana:

Beim Hochfahren
flackerte zunächst das Konsolen-Terminal mit dem angezeigten Prompt; in diesem Modus sind kontrollierte Eingaben kaum möglich. Das ist mir übrigens nicht zum ersten Mal bei Upgrades passiert. Zur Vorsorge ist es sehr nützlich, vor dem Upgrade den SSHD-Service zu aktivieren (systemctl enable ….). Man kann sich dann beim Hochfahren nach dem Upgrade wenigstens von anderen Systemen aus einloggen und ein “init 3” absetzen, damit sich die Anzeige “beruhigt”.

Nun hat man zwei Möglichkeiten: Download einer aktuellen Treiber-Version von der Nvidia-Website und manuelle Installation. Oder aber: Zuschalten des Nvidia-Repositories und Installation der Treiber über RPM-Pakete und YaST. Ich habe zuerst Letzteres versucht. Systemd initiierte dann nach einem Restart auch den Wechsel zum graphischen “Target” und versuchte erkennbar X und SDDM zu starten; das Ganze endete aber in einem schwarzen Schirm mit Mauszeiger. Und nicht mit der Anzeige des SDDM-Login-Schirm …

In einigen Internet-Beiträgen zu ähnlichen Problemen wird empfohlen, den User “sddm”, unter dem der Login- und Display-Manager SDDM für KDE Plasma-Nutzer ausgeführt wird, zu einem Mitglied der Gruppe “video” zu machen. Das half in meinem Fall aber gar nichts.

Was war da faul?

Zunächst besorgte ich mir zum Vergleich den aktuellen Treiber manuell von der Nvidia-Website; in der gleichen Version wie im Nvidia-Repository hinterlegt. Und siehe da: die manuelle Installation (inkl. Kompilation etc.) über den Nvidia-Installer (also das “run”-Skript ) funktionierte! Allerdings kam eine Warnung, dass die vorhandene “libglvnd“-Installation nicht vollständig sei. Man wird dann vom Nvidia-Installer gefragt, ob er die Installation aus eigenen Ressourcen korrigieren solle. Ich habe dem zugestimmt. Danach kamen SDDM und KDE Plasma anstandslos hoch. Durchatmen: wenigstens die manuelle Installation führt zum Erfolg. Es gibt also kein fundamentales Problem zwischen Leap 15 und den Nvidia-Treibern. Was aber, wenn man aus bestimmten Gründen zu den Opensuse-Nvidia-Repos wechseln will?

Eine komplette Deinstallation des Nvidia-Treibers über das zugehörige Run-File per

bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run –uninstall

und eine anschließende Installation des gleichen Treibers per Opensuse-Nvidia-Repo führte leider wieder ins Nirwana.

Auffällig war bei der manuellen Deinstallation allerdings eine Meldung zu nicht ordnungsgemäß herstellbaren Links im Verzeichnis “/usr/lib64”. Dort liegen bekanntermaßen *.so-Libraries. Ein genaues Studium der im Zuge der verschiedenen Installationen angelegten Links in diesem Verzeichnis brachte dann die Lösung:

Nach einer funktionierenden manuellen Installation des Treibers von der Nvidia-Website gab es dort folgende relevante Einträge : 

mytux2:/usr/lib64 # la | grep libGL
-rw-r--r--   1 root root       656 Sep 21 18:46 libGL.la
lrwxrwxrwx   1 root root        10 Sep 21 18:46 libGL.so -> libGL.so.1
lrwxrwxrwx   1 root root        14 Sep 21 18:46 libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x   1 root root    665720 Sep 21 18:45 libGL.so.1.7.0
....

Das Vergleichssystem “mytux1” zeigte hingegen folgende Konstellation: 

mytux1:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0

Andere Versionsnummern, aber eine ähnliche Verlinkung.

Nach dem manuellen Uninstall per “bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run –uninstall ” auf “mytux2”
und einem Installieren der Treiberdateien aus den Opensuse-Nvidia-Repositories für Leap 15.0 ergab sich hingegen folgendes Bild: 

mytux2:/usr/lib64 # la | grep libGL       
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    430760 Nov 21  2016 libGL.so.1.2.0
...

Hier war zwischenzeitlich offenbar etwas Altes aus dem Jahre 2016 restauriert worden! Woher der Nvidia-Uninstaller das auch immer genommen haben mag… Dass der Nvidia Installer/Uninstaller damit zu tun hatte, ergab sich aus der Tatsache, dass die Datei “libGL.so.1.2.0” sich keinem RPM-Repository zuordnen ließ, die libGL.so.1.0.0 aber schon : 

mytux2:/usr/lib64 # rpm -qf libGL.so.1.0.0
libglvnd-1.0.0-lp150.1.1.x86_64

Wer immer da wann was im “libGL/libglvnd”-Umfeld verbrochen hatte; dieser Schaden ließ sich beheben. Offenbar ist für die Repository basierten Treiber nur die “libGL.so.1.0.0” maßgeblich. Ich habe daher eine Umsetzung der Links vorgenommen und die “libGL.so.1.2.0” gelöscht. (Auch die manuelle Treiberinstallation nutzt diese Bibliothek ja nicht …; s.o.). 

mytux:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1.2 -> libGL.so.1.0.0

Die Dateien aus dem Opensuse-Nvidia-Repository habe ich dann zur Sicherheit nochmal überinstalliert. Und siehe da, danach lief alles. Den Link “libGL.so.1.2” konnte ich schließlich auch ohne Schaden wegschmeißen.

Merke: Eine Historie mit Wechseln von Nvidia-Treiber-Installationen aus dem Opensuse-Repository und manuellen Installationen per Nvidia-Installer-Daten bleibt nicht immer verwerfungsfrei. Ein Blick in die Links unter “/usr/lib64” ist hilfreich.

Problem mit VMware WS 12.5.9 unter Leap 15.0

Auf einem meiner Systeme läuft eine relativ aktuelle VMware WS 14.1.1-Umgebung. Die überlebte das Upgrade auf Leap 15.0 anstandslos. Die Module wurden im Hintergrund neu kompiliert und erfolgreich gestartet.

Auf einem anderen System lief aber die WS 12.5.9. Die ließ sich zunächst nicht dazu bewegen zu starten. Die Module für den “Virtual Machine Monitor” wie das “Virtual Network” konnten nicht erfolgreich kompiliert werden. Hier hatten findige Menschen aber dankenswerterweise schon vorgearbeitet; das Problem ist bekannt und gelöst. Die notwendigen Schritte, die auch auf meinem System zum Erfolg führten findet ihr hier

https://communities.vmware.com/message/2777306#2777306

Addendum, 25.03.2020: The steps described in the referenced community article work on Leap 15.1, too.

Viel Spaß dann mit Opensuse Leap 15 ! ZU Leap 15 und Optimus bald mehr, wenn ich Zeit finde …