Eclipse Oxygen3 – old bug blocks certain key combinations in editors – e.g. Ctrl+Right/Left for next or previous word

After changing to Eclipse Oxygen 3 for my PHP work I have spent an hour to find out out what was wrong with the keyboard actions for navigating through code. One of the key combinations one typically needs is "Ctrl >" and "Ctrl <" to jump from one word to the other - more precisely between some whitespace/letter-combinations which are interpreted as word separation borders.

Whenever I restarted or reopened Oxygen3 the already opened editors on files I had worked with during the last session did not show any reaction to such key combinations. However, when I closed the file and reopened them again with the structured PHP-editor the key combination did work. But after a restart of the workspace no reaction again. It really took me a while to find out that all this was due to the "welcome" screen, which I had not deactivated, yet, in the new installation. After knowing this, I even did find a corresponsing bug and stack overflow report.

https://stackoverflow.com/questions/18341928/eclipse-ctrlright-does-nothing

Just deeactivating the welcome screen did the trick. I find it very frustrating that this is really a rather old bug - and I could bet it cost a lot of people nerves and useless efforts.

phpmyadmin 4.6.4 ist buggy – nicht für Sicherungen verwenden !

Ich hatte heute die Aufgabe, die Daten eines WordPress-Blogs von der MySQL-Datenbank eines Hosting Providers zu sichern und den Blog dann auf eine neue Datenbank bei einem anderen Provider umzuziehen. Dabei hat ein übler Bug in der phpMyAdmin-Version 4.6.4 etliche meiner Nerven verschlissen:

Auf Exports von Tabellen mit Kommentaren oder Spalten mit bestimmten HTML-Inhalten kann man sich bei der aktuellen Version (Stand 03.10.2016) leider nicht verlassen; der nachfolgende Import scheitert unter Umständen - vermutlich wegen einer fehlenden oder fehlerhaften Maskierung von Anführungszeichen.

Es dauerte aber eine ganze Weile, bis ich anfing, der Exportfunktion von phpMyAdmin zu misstrauen - vor allem, weil mir bei dem Provider keine Datenbank-Logs zur Verfügung standen. Ich konnte den Fehler aber an einer reduzierten "posts"-Testtabelle der WordPress-Installation nachvollziehen; der Export und nachfolgende Import schlägt mit der Version 4.6.4 reproduzierbar fehl - in meinem Fall sogar mit einem internen Server-Error.

Gott sei dank war die alte Datenbank noch nicht gelöscht! Ich konnte den Export/Import-Vorgang mit der auf die Schnelle installierten phpMyAdmin-Version 4.4.15.8 anschließend anstandslos und fehlerfrei durchführen.

Solche Bugs können üble Folgen haben, wenn man nach einer "Sicherung" naiverweise den alten Datenbank-Zustand löscht, ohne vorher an einer anderen Datenbank den Reimport getestet zu haben. Auch für phpMyAdmin gilt bei Sicherungen die alte Regel:
Immer erst die ganze Kette zur Restaurierung testen, bevor man irgendetwas löscht!

Dennoch: So ein Bug ist wirklich übel! Ich bin ein wenig sauer .... im Nachhinein fand ich dann unter github folgende Bug-Einträge:
https://github.com/phpmyadmin/phpmyadmin/issues/12086
https://github.com/phpmyadmin/phpmyadmin/issues/12453
Der erste davon wurde geschlossen, obwohl er offenbar immer noch oder wieder vorhanden ist.

Opensuse Leap 42.1 – nerviger YaST Bug

Auf meinem Mehrschirm-Arbeitsplatz offenbarte sich in den letzten Tagen ein sehr nerviger Bug von YaST:

Startet man YaST (yast2) über das Startmenü, authentifiziert sich danach als root und ruft dann die "Softwareverwaltung auf, so geschieht u.U. und erratisch Folgendes: Das Fenster für die SW-Verwaltung öffnet sich, die Repositories werden eingelesen und das Fenster strong>schließt sich sofort wieder.

Das passiert nicht, wenn man "yast2" als root über ein Terminal startet, u.U. aber auch sehr wohl, wenn man als normaler User in einem Terminalfenster "/usr/bin/xdg-su -c /sbin/yast2" absetzt.

Es hat mich ein Weilchen gekostet herauszufinden, unter welchen Umständen dieser Bug überhaupt auftritt:

Es geschieht nur in Mehrbildschirm-Konfigurationen und immer nur dann, wenn YaST nicht von der Kontroll-Leiste des Hauptschirms gestartet wird. Oder: Wenn das anschließend gestartete YasT-Übersichts-Fenster auf einem anderen als dem Hauptschirm positioniert wird. Dito für den Start über ein Terminalfenster.

Workaround:
Das grafische YaST unter Leap 42.1 z.Z. immer über das Startmenü des Hauptbildschirms starten. Das sich öffnende YaST2-Übersichtsfenster anschließend auf den Hauptschirm verschieben, falls es nicht dort geöffnet worden sein sollte. Erst dann die Softwareverwaltung aufrufen.

Na, es wird wohl noch eine Weile dauern, bis Leap mit KDE 5 so stabil sein wird wie Opensuse 13.2! es ist bei weitem nicht so schlimm wie bei der Einführung von KDE 4.0 oder systemd. Aber bei dem einen oder anderen Erlebnis der letzten Tage werden bei mir jedenfalls finstere Erinnerungen wach ....