Category Archives: LibreOffice, OpenOffice

Beiträge zu Office-Programmen

MariaDB, LibreOffice 4.x, Konnektoren – Performance Problem wg. Primary Keys

Posted on by

Vor einigen Tagen habe ich für ein Projekt verschiedene Varianten des direkten Zugriffs von Office-Anwendungen (MS Office, Libreoffice unter Windows und Linux) auf MariaDB -(MySQL-) Datenbanken eines Remote Linux-Server getestet. Dabei habe ich mir für LibreOffice [LO] unterschiedliche Konnektoren für den Datenbankzugriff angesehen – JDBC, ODBC und den direkten, nativen Zugriff über einen MySQL-Konnektor. Letzterer wird unter Opensuse -Linux mit dem LibreOffice RPMs mitgeliefert. Unter Windows steht der Konnektor dagegen als LO-“oxt”-Extension zur Verfügung. Siehe:
http://extensions.libreoffice.org/extension-center/mysql-native-connector-for-libreoffice-4.x/releases/1.0

Bei den Performance-Tests hatte ich dann ein Erlebnis der Sonderklasse, das sicher auch andere interessieren dürfte.

Testvoraussetzungen

Libreoffice habe ich mir in der Version 3.6, der Version 4.0.3 aus dem aktuellen LO Stable Repository des Build Services von Opensuse (12.3) unter Linux angesehen. Unter Windows die Versionen 3.6.7 und 4.0.6. Die Clients (Opensuse 12.3) und Windows 7 unter VMware liefen auf ein und demselben System mit einem i7 Quad 950 Prozessor und Raid-10-System. Der Server ist ein von Strato gehosteter V-Server mit 100Mbit -Anbindung ans Internet und 32Bit Opensue 12.3. Als RDBMS wurde eine MariaDB installiert, die bei Opensuse ja die Nachfolge des MySQL-RDBMS von Oracle angetreten hat.

Die Performance des Serversystems ist hinreichend – wir führen dort Simulationsrechnungen für industrielle Prozess- and Supply Chain Netze mit mehreren Zig-Tausend Knotenpunkten und mehreren zig-tausend Datenbanktransaktionen in wenigen Sekunden durch. Für das bisschen Transfer von Tabelleneinträgen im Bereich von 100 KByte bis zu wenigen MByte zu einem Client reicht die Serveranbindung völlig.

Alle Tests wurden mit SSH-Tunnelverbindungen zum Server durchgeführt. Wie man solche Verbindungen absichert, ist in einem vorhergehenden Artikel
https://linux-blog.anracom.com/2013/11/22/ssh-getunnelter-datenbankzugang-fur-gehostete-lamp-server-i/
ausführlich erläutert. Unter Windows wurden diese Verbindungen über PuTTY realisiert.

Die konkret untersuchten Tabellen hatten zwischen 200 und 220.000 Einträgen. Es handelte sich durchweg um MyISAM- und nicht um InnoDB-Tabellen.

Das Laden einer Datenbanktabelle erfolgt unter LibreOffice so, dass man über BASE Datenbankverbindungen zum RDBMS eines Remote-Servers definiert. Unter CALC läst man sich dann die definierten Datenquellen anzeigen (Taste F4), wählt eine Bank und eine zugehörige Tabelle aus. Deren Werte werden dann in einem besonderen oberen Bereich des CALC-Fensters zunächst als Base-Tabelle dargestellt, die man auch zum Ändern der DB-Werte verwenden kann. Der CALC-Schirm teil sich durch F4 also in einen oberen Bereich, der an Base angelehnt ist und einen unteren Bereich, der eine normale CALC-Spreadsheet-Tabelle enthält.

Der Import der Daten der DB-Tabelle erfolgt dann durch Drag und Drop der Tabelle aus der mittels F4 angezeigten Base-Tabellen-Liste in den darunter liegenden CALC-Spreadsheet-Bereich. Alternativ wählt man in der Base-Tabellen-Anzeige alle Werte aus, wählt ferner ein Zelle im CALC-Tabellen-Bereich als Startpunkt des Imports aus und betätigt dann eine Taste für den Import.

In der CALC-Spreadsheet-Tabelle wird dann ein mit der Datenbank assoziierter Bereich angelegt, der nach etwas Wartezeit mit den RDBMS-Tabellen-Daten gefüllt wird. Dieser mit der Datenbank verbundene Bereich kann später jederzeit mit den aktuellen Daten des RDBMS-Systems upgedated werden. Details hierzu findet man in der LO-Hilfe.
Ich gehe hierauf in diesem Artikel nicht weiter auf di CALC-Anbindung an ein Remote-RDBMS ein.

Erste Tests: Erhebliche Performance-Unterschiede zu MS Excel ??

Der Schock entstand über einen Befund, den ich erst gar nicht glauben wollte. Nach etlichen Stunden, viel Konfigurationsarbeit und vielen Tests mit Zeitmessungen hatte ich folgendes Ergebnis vor mir:

Das reine Laden großer Datenbanktabellen über einen ODBC-Treiber schien unter Excel viel, viel schneller zu funktionieren als unter dem Gespann LibreOffice/Base/Calc mit direktem SQL-Konnektor.

Ich spreche hier wie gesagt von Tabellen mit 10.000 bis 220.000 Einträgen. [Das ist für die Belange des Kunden nicht besonders viel.] Und “schneller” ist dabei so zu verstehen, dass die Kombination Excel 2010/ODBC unter Windows 7 (64Bit) in den Tests zunächst erheblich – d.h. um Faktoren – schneller lief als jede Connector-Variante (ODBC, Direct MySQL-Connector, JDBC) mit Libreoffice/Calc/Base.

Dabei läuft Win 7 bei mir nur unter VMware. Die Linux-Tests wurden auf demselben nativen Linux-Host durchgeführt, der auch VMware beherbergt.

Ich nenne ein paar Zahlen für Tabellen mit ca. 14 Zahlenspalten (Integer, Double) :

  • Laden/Importieren Tabelle mit 224 Records : ca. 1 Sek.
  • Laden/Importieren Tabelle mit 6000 Records : ca. 8 Sek.
  • Laden/Importieren Tabelle mit 60.000 Records : ca. 95 Sek.
  • Laden/Importieren Tabelle mit 138.000 Records : ca. 4:40 Min.

Updates dieser per Base nach CALC importierten Tabellen dauerten etwa genauso lange. Den Versuch, eine Tabelle mit 250.000 Records zu laden, habe ich nach mehr als 10 Minuten Wartezeit abgebrochen. Ich merke ausdrücklich an, dass diese Zeiten nicht durch die übertragene Datenmenge über eine evtl. schlechte Internetanbindung erklärbar sind. Ferner gilt/galt:

Dem gegenüber stand eine Zahl für das Laden einer Tabelle mit 138.000 Records nach Excel per ODBC Konnektor von nur ca. 6-8 Sekunden.

Ich empfand diese extreme Diskrepanz zu Linux wirklich als unakzeptabel.

Man muss dazu sagen, dass die genannten Zahlen für das Linux-System bereits optimale Werte darstellen. Typischerweise ergaben sich auch sehr seltsame Effekte, wenn man zwischen den Tests die LO-Versionen durch Neuinstallationen der RPMs wechselte und die Konfigurationsdateien des aktuellen Linux-Users nicht komplett löschte. Teils lief dann das Laden auch kleiner Tabellen unter Calc unendlich lang. Ich deute diese Instabilitäten im Zusammenhang mit Up- oder Downgrades der RPMs – auch bei Auflösung aller Abhängigkeiten. Vielleicht ist das ein Hinweis darauf, dass irgendwelche Überbleibsel und Konfigurationseinstellungen nach einer Neuinstallation noch zu Interferenzen führen.

Die oben genannten Werte stellten sich nur ein, wenn man die jeweiligen Konfigurationsverzeichnisse im Home-Verzeichnis des Linux-Users nach einem Up- oder Downgrade vollständig gelöscht hatte. Ich konnte sie ferner nur für die 4.0.x-Version erzielen. Die Zeiten unter der 3.6 Version waren z.T. noch erheblich länger.

Schlechte Performance-Werte auch unter Windows

Der wirklich frustrierende Befund für die Datenanbindung von LO an eine MySQL-Datenbank wurde leider durch nachfolgende Tests für die LO-Versionen 3.6 und 4.1.3 unter Windows voll bestätigt.

Einschränkend sei angefügt, dass die Philosophie dessen, was ein Load/Import von Datenbankdaten leisten muss, vermutlich in Excel etwas anders ist als in LO. Aber beide Systeme verankern Datenbank-Verbindungen – in BASE geschieht dies innerhalb der Applikation, unter Windows werden die ODBC-Verbindungen über die Systemsteuerungen im Betriebssystem hinterlegt.

Excel lädt
und importiert auf den ersten Blick eher passiv; auf der LO-Seite sind dagegen jederzeit Änderungen der DB-Inhalte und nachfolgende Updates aus der Datenbank für spezielle datenbank-assoziierte “Bereiche” von Calc-Tabellen möglich. Dennoch:

Schon beim Hantieren unter LO-BASE fallen die Geschwindigkeitsunterschiede ins Auge: BASE aktualisiert bereits beim Scrollen über große Tabellen die angezeigten Daten laufend im Hintergrund aus der angeschlossenen Datenbank. Ich habe keine Einstellung gefunden, das zu unterbinden. Vielleicht war ich dazu schlicht zu blöd.

Es zeigte sich unter Windows zudem, dass ein ODBC-Konnektor fast die gleichen Zeitwerte für den Datenbank-Import nach CALC lieferte wie die direkte MySQL-Anbindung durch den MySQL-Konnektor. Leider erwies sich die Performance einer JDBC-Anbindung noch deutlich schlechter als die der MySQL- und des ODBC-Konnektoren. Dass mindestens der ODBC-Konnektor aber eigentlich deutlich mehr leisten kann, beweisen gerade die hervorragenden Ladezeiten für Excel.

Performance-Problem des MySQL-Konnektors wegen Primary Keys?!

Die Frustration spornte mich zu weiteren Experimenten an. Ganz zufällig stieß ich dann bei weiteren Test unter Linux auf ein Tabelle mit 78.000 Einträgen. Überraschenderweise galt für diese Tabelle: Statt Minuten warten zu müssen, konnte ich die Tabellen-Daten in ca. 4-5 Sekunden über BASE/CALC in ein Calc-Spreadsheet laden.

Bei der weiteren Analyse stellte sich dann heraus, dass ich vergessen hatte, für diese Tabelle einen expliziten Primary Key festzulegen. Das führte zu dem Verdacht, dass explizit definierte Primary Keys evtl. mit verantwortlich für die schlechte Performance der LibreOffice-Anbindung waren – so idiotisch sich das auch anhören mag ….

Lösung: Ersetze Primary Keys durch Unique Keys !

Natürlich habe ich dann mal testweise auch in anderen Tabellen die explizit definierten PRIMARY Keys gedropt und durch schlichte UNIQUE-Keys ersetzt. Ja, das geht: MySQL oder Maria DB nehmen laut Doku stillschweigend den ersten passenden UNIQUE Key und setzen ihn als Primary Key ein. Große Probleme habe ich diesbzgl. bislang nicht erlebt.
Ergebnis meiner Versuche war:

Bei allen Tabellen, in denen der explizit gesetzte Primary Key durch einen reinen Unique Key ersetzt wurde, erfolgte der Daten-Import in LibreOffice-CALC mit annehmbaren Zeiten, die sich von denen von Excel nur noch wenig unterschieden (Faktor < 1,25).

Dabei ergab sich durch gleichzeitiges Beobachten der Datenbank und der Netzverbindung der begründete Eindruck, dass CALC nach dem eigentlichen Laden der Daten aus dem RDBMS noch erhebliche Zeit für den internen Aufbau der CALC-Tabelle aufwendet. Nurmehr Letzteres und nicht mehr das Laden der Daten aus der Bank selbst erwies sich für die vom Primary Index befreiten Tabellen als verantwortlich für die noch feststellbaren Zeit-Unterschiede gegenüber Excel beim Füllen der lokalen Spread-Sheet-Tabellen.

Konkret ergab sich für das Laden der Tabelle mit 138.000 Records eine Zeit von knapp unter 8 Sekunden – anstatt der früheren fast 5 Minuten.

In unserem Projekt habe ich nun in allen RDBMS-Tabellen explizit definierte Primary Keys durch Unique Keys ersetzt. Seitdem können die Anwender auch mit CALC prima auf der MariaDB-Datenbank arbeiten.

Offene Frage : Wieso behindern Primary Keys die LibreOffice Performance so drastisch?

Ich habe leider keine plausible Antwort. Diese Frage müssen die Entwickler der MariaDB klären. Auffällig ist die dauerhaft hohe Transaktionsrate auf dem Server von insgesamt über 200 Transaktion /sec, wenn ein Primary Key vorhanden ist.

Ich sollte abschließend noch betonen, dass ich den positiven
Befund für das Entfernen der Primary keys explizit nur für eine MariaDB getestet habe. Es wäre sicher interessant, das Performance-Verhalten auch unter einer nativen Oracle-MySQL-Datenbank zu untersuchen. Hierfür habe ich leider noch nicht genügend Zeit gefunden.

Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Posted on by

Ich habe ja vor kurzem auf zwei Systemen Opensuse 12.3 installiert. Im Zuge davon habe ich auch ein Update der Libreoffice-Installation vorgenommen. Danach wollte ich im Rahmen eines Projektes mit Hilfe der Clipart-Gallery ein paar Draw-Zeichnungen anfertigen. Die notwendigen Clipart-Pakete

  • libreoffice-openclipart
  • openclipart-svg (in der Version 0.18

hatte ich natürlich installiert.

Zur Voransicht der Cliparts gibt es in den Libreoffice-Anwendungen ein Fenster, in dem die Cliparts nach thematischen Bereichen gegliedert dargestellt werden. Soweit ich mich erinnern kann, hatte ich dort zumindest in einer OS 12.1 / LibreOffice 3.5-Installation für alle Themenbereiche der Gallery auch eine Voransicht zugehöriger Ciparts gefunden.

Leere Ansicht für viele Gallery-Themenbereiche unter OS 12.2 und OS 12.3

Leider wird nun für die meisten thematischen Gallery-Bereiche in Libreoffice 3.5 bis 4.0.2 unter Opensuse 12.2 oder Opensuse 12.3 gar nichts mehr angezeigt. Beispiele liefern "Science" oder "Shapes" ; im Gallery-Fenster ist zu beiden Themenbereichen kein Clip zu sehen:

gallery_leer_600

Das ist ein typischer Mangel an qualitätsgesicherter Paket-Aufbereitung, wie er mich an der Verbreitung von Opensource-Produkten durch einige Distributoren manchmal an den Rand der Verzweiflung treibt. Was macht denn eine normaler Anwender bei einem solchen Befund? Er zuckt mit den Achseln, wundert sich und geht davon aus, dass es da halt keine Bilder gibt. das ist zugleich falsch und schade!

Eine Fehlersuche zeigt, dass es im Verzeichnis /usr/lib64/libreoffice/share/gallery/ Softlinks auf *sdg-Dateien gibt, die im korrespondierenden Verzeichnis /usr/share/libreoffice/share/gallery/ leider ins Nirwana führen. Für die entsprechenden Themenbereich wird in der Clipart-Ansicht der Libre-Office-Bereiche deshalb nichts angezeigt, obwohl im thematischen Subverzeichnis unter /usr/share/openclipart/ haufenweise svg-Dateien vorhanden sind.

Ein Blick in die Verzeichnisliste des Openclipart-Pakets von Opensuse zeigt, dass die beschreibenden "sdg"-Dateien für viele Themenberieche tatsächlich nicht ausgeliefert werden – also bereits im RPM-Paket von Opensuse selbst fehlen. Warum auch immer …. Ein Bug?

Eine parallele Windows-Installation ist wenigstens ehrlicher – die bietet von Haus aus nur wenige gefüllte Themenbereich an. Den Rest muss man sich sowieso selbst zusammenstellen.

OpenClipart-Download als Alternative ? Nein !

Alternativ und naiv dachte ich nun daran, mir etwas von der OpenClipart-Seite im Web herunterzuladen. Da wurde alles nur schlimmer; ein Download aktuellerer Clipart-Pakete ab Version 0.19 führt in den Abgrund.

Man erhält dann nämlich keine vorsortierte thematische Zusammenstellung an Files mehr, die man in ein Subverzeichnis von "/user/share/clipart/" einfügen könnte. Stattdessen kommen HTML-Dateien mit Bildern aus einem Verzeichnis, das nach allen möglichem (u.a. Autoren) aber nicht thematisch untergliedert ist. Vielmehr wird hier eine komplexe Installation von HTML-Seiten mit PHP-MySQL-basierter Suchmaschine erwartet. Leider funktioniert das vorgesehen “make install” unter OS 12.3 gar nicht. Schauder … – in dieser Form ist OpenClipart 2.x weder für LibreOffice noch sonst irgendwie brauchbar. Keine Zeit, mich damit zu befassen. Ich will doch nur ein paar faktisch vorhandene Cliparts unter Libreoffice sehen und nutzen!

Workaround

Ich habe dann versuchsweise Libreoffice komplett deinstalliert, alle zugehörigen Konfigurationsdateien in meinem Home-Verzeichnis entfernt und Libreoffice neu installiert. Das half leider auch nichts. Aus Zeitmangel habe ich nun einen Workaround per Handarbeit vorgenommen:

Schritt 1: Man muss in Libreoffice im Gallery-Fenster selbst ein neues Thema zu einem der vorhandenen thematischen, aber leider als leer angzeigten Bereiche wie “Shapes” anlegen. Ich gebe dem neuen Thema z.B. den Namen "shapes_2".

Schritt 2: Im Subdialog-Fenster zu diesem neuen Thema lässt man im thematischen Unterverzeichnis von /usr/share/openclipart/ [hier also im Verzeichnis "/usr/share/clipart/openclipart/shapes/" ] alle passenden Dateien zusammensuchen, markiert dann alle oder eine Unterauswahl und drückt auf den Button "Hinzufügen". Die Anzeige des folgenden kleinen Dialoginhalts ist unter meinem KDE 4.10 dann leider nicht vollständig zu erkennen – aber man wartet einfach, bis der Übernahmeprozess erfolgt ist.

Schritt 3: Das Ergebnis sind dann 3 Dateien unter /home/USER/.config/libreoffice/4-suse/user/gallery/ (USER ist dabei dein Username):

  • sgxxx.sdg,
  • sgxxx.thm,
  • sgxxx.sdv

xxx steht dabei für eine 2- oder dreistellige Ziffer. Das eben installierte Clipart-Thema hat die höchste Nummer.
Man wird in unserem Beispiel feststellen, dass Libreoffice nun im Gallery-Fenster unter "shapes_2"alle svg-Dateien von "/usr/share/clipart/openclipart/shapes/" tatsächlich anzeigt. Die drei beschreibenden Dateien, im besonderen die sdg-Datei, sind dafür hinreichend.

Schritt 4:
Nun ermittelt man unter Libreoffice im Galleryfenster durch einen Rechtsklick auf das ursprüngliche “Shapes” dessen "Eigenschaften". In einem Dialofenster wird u.a. ein File-Pfad und ein File-Name einer zugehörigen Deskriptionsdatei sgxxx.sdg angezeigt – bei mir ist Shapes z.B. mit dem File "sg85" assoziiert.

Man fertige nun eine Kopie der obigen drei Dateien sgxxx.sdg, sgxxx.thm, sgxxx.sdv an und benenne die Ziffern "xxx" in "85" (bzw. die eben ermittelte Nummer) um. Danach verschiebe man diese deskriptiven Dateien als root (!) in das Verzeichnis "/usr/share/libreoffice/share/gallery/". (Root-rechte sind dort zum Schreiben erforderlich.

Danach funktioniert auch die Anzeige der Dateien unter dem ursprünglichen Themenbereich "Shapes" und nicht nur unter "shapes_2".

gallery_voll_600

Den für den Workaround angelegten Themenbereich "shapes_2" kann man nun eigentlich auch löschen löschen. Ich würde ihn aber behalten, da die Deskriptonsdateien für "Shapes" bei einer Neuinstallation der Opensuse-RPMs möglicherweise wieder gelöscht werden. Dann kann seine alte Auswahl im Eigenschaftsdialog von shapes_2 aktualisieren lassen und wie oben beschrieben weiterverfahren.

Nach diesem kleinen Desaster zur Korrektur einer unvollständigen OpenClipart-V18–Installation unter Opensuse 12.3 bleibt abzuwarten, wie Opensuse und LibreOffice mit der Integration von OpenClipart-Galleries der aktuellen Versionen 0.19 und 2.X umgehen werden.

Libreoffice 3.4, Scrollbar-Fehler, KDE 4.7

Posted on by

Manchmal gibt es in der Opensource-Welt Fehler, über die man sich aus folgenden Gründen wirklich ärgern muss:

  • Sie brechen nach Wochen halbwegs angenehmen Arbeitens plötzlich aufgrund eines harmlos erscheinenden Updates einer Applikations-Sub-Version über einen herein und machen eine Schlüsselapplikation zumindest teilweise unbrauchbar.
  • Sie sind spezifisch für eine Linux-Desktop-Variante (hier KDE 4.7.x) und treten unter einer anderen (KDE 4.6, Gnome) nicht auf.
  • Die Entwickler und Distributoren haben die verschlimmbesserten Anwendungs-Programme offenbar nicht unter der betroffenen aktuellen Desktop-Versionen getestet.

In diese Kategorie fallen z.B. zwei aktuelle Fehler bzgl. der Integration von Libreoffice 3.4.x und KDE 4.7.x – zumindest unter Opensuse 11.4, wohl aber auch unter anderen Distributionen.

Libreoffice ist GTK-basiert. GTK-Applikationen laufen unter KDE vom Erscheinungsbild her leider nicht immer ganz optimal. Aber im vorliegenden Fall half kein Rumdoktern an Einstellungen oder der Austausch von Bibliotheken für die GTK-QT-Integration; es liegt wohl eher ein Bug vor.

Man betrachte folgendes Bild:

bug libreoffice 600

Man erkennt einerseits eine viel zu große ungeglättete Schriftart, die zur Beschriftung der Lineale herangezogen wird. Andererseits – und das ist schlimmer – liegt ein Teil der Dokumentdarstellung über dem horizontalen Scrollbar, der dadurch letztlich unbrauchbar wird.

Bzgl. der Linealbeschriftung gilt, dass offenbar nicht die KDE-Schriften gezogen werden, obwohl in der entsprechenden LibreOffice-Optionen-Seite

“Extras > Optionen > LibreOffice > Ansicht”

der Punkt

“Systemschriftart für die Benutzeroberfläche wählen”

aktiviert ist. Statt dessen wird auf eine Schrift zurückgegriffen, die auf dem Linuxdesktop nicht unterstützt ist. Zumindest auf meinem nicht – und da sind wirklich viele Schriften installiert …

Beim horizontalen Scrollbar klappt möglicherweise die Integration der gewählten GTK-Styles unter KDE 4.7 in Libreoffice nicht, obwohl ein ansprechender Style unter KDE4’s “Systemeinstellungen > GTK-Stile und Schriftarten” ausgewählt wurde – und bei anderen GTK-basierten Anwendungen auch gezogen wird. Oder es liegt halt ein anderer handfester Bug vor.

Ein Test unter Gnome und KDE 4.6 zeigt im Gegensatz zu KDE 4.7 interessanterweise eine einwandfreie Darstellung der Libreoffice-Oberfläche.

Workaround

Als Sündenbock entpuppt sich nach ein wenig Rumspielen schließlich das RPM-Paket “libreoffice-kde4”. Ein Workaround besteht entsprechend darin, dieses Paket durch “libreoffice-gnome” zu ersetzen und die Einstellungen für die Gnome-Oberfläche zu erzwingen, obwohl man unter KDE4 arbeitet.

Dies geschieht dadurch, dass man in die Datei “/usr/bin/soffice” folgende Zeile einfügt:

export OOO_FORCE_DESKTOP=gnome soffice

Danach kann man mit Libreoffice 4.4.x unter KDE 4.7.x wieder arbeiten. Sogar die KDE-Schriftarten werden für die Menüs gezogen, wenn man einen kompletten Neustart der KDE-Oberfläche vornimmt.

Dieser Umweg ist nicht auf meinem Mist gewachsen – gefunden habe ich den Vorschlag nach einer etwas mühsamen Suche im Internet unter

https://bbs.archlinux.org/viewtopic.php?pid=971669

Ich dachte, ich verweise an dieser Stelle mal auf diesen Workaround, denn in vielen Internet-Beiträgen zum Scrollbar-Problem gehen die verzweifelten Anwender entweder auf eine ältere Libreoffice Version oder gar auf eine ältere KDE-Version zurück.
Das ist unnötig. Aber die Verzweiflung der Anwender verstehe ich gut, denn es handelt sich bei KDE 4.7 und Libreoffice 3.4 ja um fundamentale Bausteine eines Opensource-Desktops, die man zum produktiven Arbeiten benötigt.

Mangelnde Qualitätssicherung ?

Es bleibt wieder der ungute Eindruck, dass es vor der Veröffentlichung mancher “verbesserter”, neuer Versionen von Opensource-Programmen an der Qualitätssicherung hapert. Im aktuellen Fall haben sich die Entwickler wohl mehr um Gnome, ältere KDE-Versionen oder gar Windows als Zielplattform gekümmert. Einen Test für ein aktuelles KDE 4.7 kann wohl kaum jemand durchgeführt haben, denn sonst gäbe es nicht so viele Beiträge zu dem Scrollbar-Problem im Netz.

Was wieder mal meine Überzeugung verstärkt, dass der Opensource-Desktop unter Linux auf Dauer nicht zum Erfolg kommen wird, wenn bzgl. der Qualitätssicherung nicht ein deutlich höherer Standard erreicht wird. Das hier geschilderte Beispiel ließe sich ja um viele weitere Fälle aus der KDE-Geschichte ergänzen. Man denke nur an die Probleme bei der Einführung von Akonadi oder bestimmte Bugs in Kontact.

Ich meine, dass eine bessere Form der Qualitätssicherung wirklich notwendig ist, bevor laufend Verschlimmbesserungen von Opensoure-Programmen ihren Weg in die Repositories der Distributoren finden. Irgendwie scheint mir diesbezüglich ein wichtiges Glied zwischen der Entwicklungstätigkeit der Community und der Publikation der mit sehr hoher Frequenz entstehenden Opensource-Werke in den Repositories der Distributionen zu fehlen.

Hinzu kommt natürlich auch eine für meinen Geschmack zu hohe Frequenz, mit der regelmäßig an fundamentalen Bausteinen der Desktops selbst – speziell von KDE – gerüttelt wird. Der Desktop wird so möglicherweise zu einer unberechenbaren Größe für die Entwickler von Anwendungen. Das hatte ja zuletzt auch Miguel de Icaza zu Recht im Linux-Magazin kritisiert. Vielleicht ist der obige Fall ja auch ein Beleg für dieses Problem.

Ein Desktop lebt schließlich nicht allein von intrinsischer Innovation, sondern in gleichem Maße von den Applikationen, die darauf laufen müssen. Und deren Entwickler brauchen Zeit, um sich auf grundlegende Veränderungen der Desktop-Plattform einzustellen ….

Ein supermoderner Desktop ist nämlich wirklich wenig wert, wenn Applikationen, die vor einem halben Jahr veröffentlicht wurden, nicht mehr auf der neuen Desktopversion laufen.