Update KDE 4.8 – Nepomuks hohe CPU-Last

Habe gerade unter Opensuse 12.1 auf KDE 4.8 upgegraded. Danach erzeugt Nepomuk samt virtuoso-t ähnlich wie früher bei KDE 4.6 eine enorm hohe CPU-Last, die sich leider nicht so ohne weiteres beseitigen lässt.

Bei mir hat folgendes geholfen:

  • Stoppen von Nepomuk über die KDE-Systemeinstellungen.
  • Stoppen von Akonadi (man benutze das Kommando “kcmshell4 kcm_akonadi”,
    gehe dann im sich öffenenden Fenster auf den 2-ten Reiter für die “Einrichtung des Akonadi-Servers”
    und stoppe dort den Akonadi-Server).
  • Zur Sicherheit : Herunterfahren in den Runlevel 3
  • Löschen des Verzeichnisses ~/.kde4/share/apps/nepomuk
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/nepomuk*
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/akonadi_nepomuk_*
  • Hochfahren in den Runlevel 5 und Log in in den KDE-Desktop.

Danach wurden bei mir neue Konfigurationsdateien angelegt und auch das Nepomuk-Verzeichnis wurde erneuert.

Nepomuk begann dann mit einer Reindizierung aller möglichen Ressourcen, aber beanspruchte die CPU dabei viel, viel weniger als zuvor. Ferner verhält sich Nepomuk jetzt bei mir sogar adaptiv und begrenzt die CPU-Belastung auf Zeiten, in denen ich mit anderen Programmen nicht so viel macht.

Siehe hierzu auch https://bugs.kde.org/show_bug.cgi?id=289932, Kommentar #3 und weitere Kommentare.

Schade, dass die KDE-Entwickler immer wieder solche Schnitzer produzieren. Es muss doch möglich sein, die Programme neuer Versionen so zu gestalten, dass es möglich wird KDE-Updates durchzuführen, ohne Konfigurationsdateien von Schlüsselkomponenten löschen und neu anlegen zu müssen.

Nachtrag 15.02.2012:

Ich habe ein anderes System, auf dem folgende Voraussetzungen gegeben waren:

1) Opensuse 12.1 wurde von scratch neu installiert – und zwar zunächst ohne KDE, aber mit XFCE.
2) Danach habe ich direkt KDE 4.8 aus dem Repository http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/ installiert. Es gab also kein Update von KDE 4.7.2.

Nach der Anbindung an einen IMAP-Server begann der Nepomuk-Indexer zu arbeiten und zwar ziemlich lange. Als nach ca. 30 Minuten kein Ende absehbar war, bin ich in die KDE-Systemeinstellungen (“systemsettings”) gegangen und dort in die Einstellungen zur “Desktopsuche”. Dort habe ich in der angegebenen reihenfolge folgende schritte durchgeführt:

  • Deaktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Semantik-Dienste aktivieren” -> Button “Anwenden”

Danach geht die CPU-Belastung durch Nepomuk auf 0. U.a. ist der Email-Indexer gestoppt. Dann habe ich folgendes gemacht:

  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Aktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden” und Durchlaufen lassen ! Ggf. über “Erweiterte Einstellungen” den verzeichnisbereich, der indiziert wird, einschränken.
  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”

Danach war Ruhe und die hohe CPU-Belastung durch virtuoso-t / nepomuk ging auf fast 0! Vermutlich wurde der erstmalige Neuindizierungsprozess von Nepomuk (kontrolliert?) abgebrochen. Danach scheint es aber leider so, dass der Email-Indexer gar nicht mehr läuft – zumindest werden bei Suchvorgängen nach Begriffen
im Text von Emails keine Treffer mehr unter neuen Emails gefunden.

Posted in KDE

Kann man KDE professionell nutzen ?

Kann man ein aktuell gehaltenes KDE als professionelle Arbeitsumgebung einsetzen? Diese Frage stelle ich mir vor allem seit der Einführung von KDE 4 immer wieder.

Meine Antwort:

Ja, schon – wenn man denn viel Zeit zum Testen und Spass am Basteln hat – und man immer eine Rückversicherung in Form älterer KDE-Versionen auf anderen Linuxinstallationen im Arbeitsumfeld vorrätig hält.

Ich möchte in diesem Beitrag auf ein aktuelles Beispiel eingehen – nämlich Veränderungen an KJots. An diesem Beispiel kann man, glaube ich, sehr deutlich festmachen, wo die Probleme liegen.

Zuvor aber ein kleiner Exkurs zu einer der wichtigsten Voraussetzungen für einen professionell einsetzbaren Desktop:

Exkurs: Stabilität der Desktop-Umgebung und ihrer Standard-Anwendungen – gibt es das unter einem sich rasend schnell entwickelnden KDE?

Die obige Antwort deutet das Nein fast schon an. Dann wäre der professionelle Einsatz eines KDE4-Desktops aber wirklich ein Problem. Denn in einer professionellen Arbeitsumgebung gibt es wenig oder gar keine Zeit für Basteleien.

Nun könnte man sagen, dass sich Fehler und zugehörige Basteleien durch eine konservative Upgrade-Politik für den Desktop vermeiden ließen. Damit ist gemeint, dass man halt nur Releases einführt, die man als durch und durch stabil verifiziert hat.

Aus meiner Erfahrung muss ich aber leider sagen: Das kann man bei der enormen Frequenz an Änderungen und der Vielfalt an Applikationen als Administrator nicht wirklich durchhalten. Soviel testen und zurechtbiegen kann man gar nicht – das ist bei dem Umfang und der Vielzahl allein an KDE-Applikationen und der Wechselwirkung mit vielen anderen Open Source Applikationen (Browser, Office-Pakete, etc.) viel zu zeit- und personalaufwändig. Zudem gleicht das Fehlerverhalten unter KDE eher einer Hydra – man muss zum Beleg dieser These nur mal regelmäßig in die KDE-Bugliste reinschauen. Interessant wäre in diesem Zusammenhang eine Statistik von Regressionsfehlern …

Fehler gibt es in der IT immer wieder. An was mache ich die Frage nach dem professionellen Einsatz also fest?

Letztlich an vielen Beispielen, bei denen “Verbesserungen” der Desktopbasis oder aber bestimmter Applikationen immer wieder zu Defiziten im Vergleich zum bisherigen Leistungsumfang des KDE-Desktops oder bestimmter Applikationen führten.

Es geht also eigentlich nicht um “Fehler” sondern um immer wieder auftretende Probleme in Bezug auf die Funktionalität des Desktops oder seiner Applikationen. Solche Probleme können ja auch durch andere Faktoren als durch echte Programm-Fehler induziert sein – z.B. technischen Innovationsdrang, der zum Einsatz neuer zentraler Komponenten führt, die langfristig echte Vorteile versprechen, aber kurzfristig ganze Applikationen an den Rand der Unbrauchbarkeit führen können, weil die Anpassung zu komplex ist. Als Beispiel verweise ich auf die Akonadi-Einführung als zentrales Element der KDE-Umgebung ….

Leider und oft genug bedeuten “Modernisierungen” deshalb für den Anwender plötzlich (mit einem Releasewechsel) auftretende Einschränkungen der Funktionalität und damit der täglichen Arbeit. In einer professionellen Arbeitsumgebung muss man sich jedoch auf die Stabilität seiner Tools verlassen können.

Liebe KDE-Entwickler und/oder Distributoren:

Stabilität bedeutet wesentlich mehr als keine Fehler im Code-Ablauf. Stabilität bedeutet u.a. auch, dass ich mich als Anwender in der täglichen Arbeit auf ein Basis-Set an Applikationen und deren Funktionalitäten verlassen können muss. Das schließt Innovation und Modernisierung nicht aus. Aber es schließt u.a. aus, dass wichtige Funktionalitäten plötzlich ersatzlos verschwinden. Sprich:

Führe substanziell geänderte Applikationen erst dann in ein Release ein, wenn neben der
Fehlerfreiheit auch der alte Funktionsumfang der Applikationen sichergestellt ist oder es einen adäquaten Ersatz gibt.

Nun ist aber eine wiederkehrende Standardsituation bei KDE-Updates folgende:

Release 4.x.y weist endlich einen Fortschritt oder eine Fehlerbehebung in der Applikation A auf, auf die man schon lange gewartet hat. Mit dem gleichen Release wurden aber andere Applikationen B oder der Desktop selbst so stark modifiziert, dass sich die angeblichen “Verbesserungen oder Modernisierungen” dort zunächst eher als substanzielle “Verschlechterungen” erweisen.

Ein kleines Beispiel aus der jüngeren Vergangenheit von Kmail:

Ab einem bestimmten Qt-Upgrade war es über 1,5 Jahre hinweg nicht mehr möglich, unter aktuellen Kmail-Versionen ein “Drag und Drop” von Mails in Richtung Folderhierarchie so durchzuführen, dass sich die Sub-Folderhierarchie beim Überfahren eines Mailordners mit der Maus automatisch öffnete. Alle Umwege, die man als User nutzen konnte, waren unpraktisch und kosteten in der täglichen Arbeit erheblich Zeit. Dabei ging das alles schon mal ganz wunderbar unter KDE 3.x und den ersten KDE 4-Versionen. Unter KDE 4.7 ist dieses Problem dann endlich behoben worden.

Nun lässt sich dafür aber die Reihenfolge von Mailordnern in der Folderhierarchie nicht mehr einstellen. Man hat also in einem Release endlich eine funktionale Einschränkung beseitigt – aber über die Hintertür an anderer Stelle eine neue Funktionalitätseinschränkung eingeführt. Das neu Problem wird nun möglicherweise zur Version KDE 4.7.4 behoben. Frage: Was geht dann nicht mehr ? Und das war nur die Situation innerhalb einer Applikation.

Noch viel öfter tritt der Fall der Verbesserung an einer Stelle und der gleichzeitigen Verschlimmbesserung oder gar Funktionalitätsverlust an einer anderen Stelle auf, wenn man sich KDE applikationsübergreifend von Release zu Release ansieht.

Was sollst du als Admin mit dieser Situation vernünftig umgehen? Eine Umfrage unter den Usern durchführen, ob sie lieber den Teufel in Applikation A oder Beelzebub in Applikation B wollen? Oder eben unter erheblichem Testaufwand auf den eher immer unwahrscheinlicheren Zustand warten, dass mal alle wichtigen Applikationen des Desktops gleichzeitig hinreichend gut funktionieren? Oder sich gleich eine eigene Desktopdistribution zusammencompilieren?

Man versucht halt sein Bestes – bastelt, so gut es geht – und schließt auch als User manchmal erhebliche Kompromisse.

Eine Schlussfolgerung wäre :

Die Planung für KDE-Änderungen oder KDE-Applikationsänderungen muss viel stärker user- und funktions-orientiert erfolgen als bisher und nicht allein technik-orientiert. Und: Es muss eine Qualitätssicherungsinstanz eingeführt (und bezahlt) werden, die die Autorität hat, manche Verschlimmbesserung aus Releases trotz allem berechtigten Innovationsdruck der Entwickler schlicht und einfach fern zu halten.

Aber wem soll man das in einer “Community”, in der der Spaß am Experimentieren und der Innovation der stärkste Motivationsfaktor ist, als Aufgabe mit auf den Weg geben? Müssen die Distributoren hier besser werden? Bei der Effizienzoptimierung, die auch dort unter Kostendruck betrieben wird?

Ich weiss es nicht – am besten wäre aus meiner Sicht eine von der Community selbst organisierte und anwender- und nicht entwickler-dominierte Qualitätssicherung und Release-Politik. Wahrscheinlich gibt es so was schon – ich kenne mich da ehrlich gesagt viel zu wenig aus ….. ich kann nur sagen, es funktioniert irgendwie nicht hinreichend …. man muss in diesem Bereich vielleicht ein paar Aspekte von Open Source neu überdenken – besser die Offenheit und den bisherigen Innovations- und Qualitätsicherungsprozess neu überdenken und um ein paar Komponenten ergänzen.

Die Distributoren haben ja versucht, eine Qualitätsverbesserung über die kostenpflichtigen “Enterprise Desktops” zu erreichen. Ich hatte eine solche
Desktopversion mal ein Jahr von Suse – es bringt ehrlich gesagt nicht viel.

Und es erscheint mir eher eine grundsätzliche Frage zu sein:

Soll oder muss die “Qualität” für den professionellen Einsatz eines Open Source Desktops erst durch kostenpflichtige und z.T. intransparente Leistungen von Distributoren gewährleistet werden? Ist das nicht vielleicht die falsche Stelle in der “Produktionskette”? Das würde ja letztlich eine Drei-Klassen-Gesellschaft” an Anwendern bedeuten:

  • die Kaste an superfitten Freaks, die sich in jeder Situation selbst zu helfen wissen.
  • Otto-Normal-Anwender, der gerne von Microsoft, Apple, etc. unabhängig werden möchte, dabei aber leider zum laufenden Beta-Tester mutiert, wenn er denn nicht irgendwann entnervt aufgibt?
  • Den Besserverdienenden oder Unternehmen, die sich die Gebühren für einen Enterprise-Desktop leisten können?

Irgendwie kann es das doch nicht sein!

Was gar nicht geht – das aktuelle Beispiel KJots

Ich habe mich vor ca. einem halben Jahr mal intensiv nach einem Tool umgesehen, mit dem ich schnell und einfach Notizen und Einfälle strukturiert und formatiert festhalten und sie danach in “Büchern” und “Kapiteln” organisieren konnte. Zudem wollte ich die Möglichkeit für einen Backup sowie einen Export in XHTML-Dateien haben.

Nach einigen Tests von etwa 5 Open Source Produkten bin ich bei KJots hängen geblieben. U.a. auch wegen der Integration in Kontact. Besonders gefallen haben mir aber die Möglichkeiten zur Strukturierung in Büchern, die Formatierungsmöglichkeiten und die Exportmöglichkeiten.

Also habe ich angefangen, das Tool in einer kreativen Phase im Juni und Juli dieses Jahres wirklich intensiv zu nutzen. Damals lief bei mir irgendeine KDE 4.5.x-Version. Vorgestern – also nur 3 Monate später – und mit einem KDE 4.7.2 ausgestattet, wollte ich mich mit den Ergebnissen meiner früheren Arbeit, die ich in Form von “*.book”-Dateien abgelegt und gesichert hatte, mal wieder befassen. Genauer gesagt: ich brauchte die alten Kjots-Dateien dringend als Ausgangspunt für eine Auftragsarbeit.

Man muss dazu sagen, dass ich mir wegen vieler Änderungen auf dem Weg von KDE 4.6 zu KDE 4.7 und der schon gewohnten Probleme mit Akonadi-Ressourcen und Kontakt etliche Teil des Desktops neu aufgebaut hatte. Dabei ging auch die frühere Verzeichnissstruktur (der KDE 4.5-Installation) für KJots unter .kde4 bzw. unter anderen Dateien des Desktops den Weg alles Irdischen.

Na und, denkt der Leser sicher – was solls – daür hattest du ja deine Kjots Dateien ordentlich exportiert und gesichert – importier sie halt einfach. Tja, dachte ich auch … .

Nur hat sich halt inzwischen KJots bzgl. der Datenhaltung und -organisation – vielleicht auch aus sehr guten Gründen – neu aufgestellt. Dummerweise haben die Entwickler dabei offenbar nicht die Zeit gefunden, eine geeignete Importfunktionalität für die alten Kjots-Export-Formate bereitzustellen – nicht einmal für das frühere “native” “.book”-Format.

Nein, nicht nur das – im aktuellen Kjots gibt es gleich gar keine Import-Funktionalität mehr! Siehe

https://bugs.kde.org/show_bug.cgi?id=277378

http://forum.kde.org/viewtopic.php?f=22&t=97304

http://forum.kde.org/viewtopic.php?f=20&t=95898
http://chakra-project.org/bbs/viewtopic.php?pid=37139
http://forums.gentoo.org/viewtopic-t-880151-start-0-postdays-0-postorder-asc-highlight-.html?sid=6e53049575aa553e582f6a2f24bcdd86

und weitere mehr ….

Nun waren die Ergebnisse meiner früheren Arbeit aber wirklich wichtig und Geld wert, und ich brauchte sie dringend. Der erste Ansatz zu einer Problemlösung führte ins Internet – aber dort fand ich im Laufe einer Stunde auch nur arme, ebenfalls ratlose Betroffene und leider keine für mich brauchbare Lösung – zumindest nicht innerhalb eines Zeitraums von einer weiteren Stunde. Dann habe ich – wenig optimistisch – versucht herauszufinden, ob sich nicht eine ältere Version von Kjots installieren lassen würde. Nein ging nicht, die Änderungen an den KDE-Basisbibliotheken auf dem Weg zu KDE 4.7.2 waren einfach zu massiv. Unter Zeitdruck und bei hinreichendem Wert der alten Kjots-Dateien bleibt als nächste Option für einen normalen Benutzer nun nur der Weg zurück zu einer alten KDE-Version.

Ich konnte glücklicherweise einen anderen Ausweg wählen:

Ich kenne den Entwicklungsverlauf und die Fallen von KDE nun schon so viele Jahre, dass ich weiss, wie gut man daran tut, immer auch ein KDE zur Verfügung zu haben, das mindestens ein halbes Jahr alt ist – entweder auf einem anderen PC/Laptop oder aber – wie bei uns – auf einer virtuellen Maschine. Die konnte ich hochfahren – und dort temporär unter KDE 4.5 im VMware-Fenster eines viel “moderneren” KDE 4.7 dann endlich meine alten Kjots-Dateien laden und bearbeiten, die ich vor gerade mal einem Vierteljahr erzeugt hatte – mit einem von mir selbst “evaluierten” KDE-Produkt.

Wie ich den bearbeiteten Stand meiner Kjots-Bücher jetzt in die KDE 4.7-Welt bringe, ist dabei nach wie vor unklar. Über eine anderes Produkt, das evtl. mit KJot-Dateien umgehen kann? Mit einem aktuellen “KBasket” klappte es jedenfalls nicht. Am einfachsten ist am Ende vielleicht wirklich der Export aller meiner Kjots-Bücher in eine umfassende HTML-Datei mit Hilfe der alten Kjots-Version, danach der Import nach Openoffice sowie das dortige zeitaufwändige Nachbearbeiten.

Und der künftige Verzicht auf Experimente bei wichtigen Dingen eines professionellen Umfeldes mit illustren KDE-Applikationen, auch wenn sie einen zunächst mit einem brauchbaren Funktionsumfang verführen mögen ??!

Professionelles Arbeiten?

Offenbar setzt das bei KDE eine Rückversicherung in Form virtueller oder physikalischer Maschinen mit älteren KDE-Versionen voraus, bei denen irgendein Tool oder eine Applikation noch den gewünschten Funktionsumfang hat.

Das alles für den offenbar wahrscheinlichen Fall, dass dieser für das Arbeiten notwendige Funktionsumfang in späteren KDE-Versionen mal wieder nebenbei der heiligen “Innovation” oder aber irgendeiner Verschlimmbesserung geopfert wird …. und man trotzdem upgraden muss, weil das Upgrade an anderer Ecke wirklich Verbesserungen bringt ….

Liebe KDE-Entwickler: Bei allem Respekt, den ihr wirklich verdient – das kann es einfach nicht sein! Das geht so nicht! Das ist zumindest Otto-Normalverbraucher nicht zumutbar.

Libreoffice 3.4, Scrollbar-Fehler, KDE 4.7

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.