In letzter Zeit ist mir aufgefallen, dass ein offener Finder-Ordner mit vielen Dateien den Finder auf meinem MacBook fast durchgehend 100% der Prozessor-Leistung fressen lässt, sodass sogar nach einiger Zeit der Lüfter anspringt.

In einem Forumsbeitrag in der Apple Support Community wird empfohlen, die Datei com.apple.finder.plist aus dem Ordner Preferences im Library-Ordner des Benutzers zu löschen und den Finder danach neu zu starten. Über das Terminal (zu finden im Dienstprogramme-Ordner des Programm-Verzeichnisses) sieht das so aus:

user@mac$ rm ~/Library/Preferences/com.apple.finder.plist
user@mac$ killall Finder

Kurze Erläuterung: Der erste Befehel, rm, löscht die Datei com.apple.finder.plist im Ordner ~/Library/Preferences (wobei das Tilde-Zeichen am Anfang andeutet, dass es sich um einen Ordner im aktuellen Benutzer-Verzeichniss handelt). Der zweite Befehl, killall, beendet den Finder (bzw. seinen laufenden Prozess) komplett, woraufhin sich dieser automatisch wieder neu startet – und dabei eine neue, saubere com.apple.finder.plist-Datei anlegt.

Bei mir läuft nun der Finder mit dem gleichem, vollem Ordner geöffnet seit über einer Stunde im Hintergrund ohne dass der Finder eine nennenswerte CPU-Last verursacht.

In einigen anderen Forumsbeiträgen, die ich bei der Suche nach der Problemlösung gelesen habe, wurde auch angedeutet, dass viele JPEG– oder PNG-Dateien in einem Ordner (oder auch auf dem Desktop) zu hohem CPU-Verbrauch durch den Finder führen könne, da dieser mit diesen Dateien irgendwelche Probleme haben solle – dies konnte ich bisher nicht nachvollziehen, möchte ich aber der Vollständigkeithalber kurz erwähnen.

Darstellungsoptionen der Listdarstellung des MacOS X Finder

Im gleichen Forumsbeitrag von oben wird als weiterer Lösungsvorschlag geraten die Darstellungsoptionen (siehe Screenshot), zu finden in der Menüleiste und Darstellung, der Listenansicht im Finder zu überprüfen: Die Option »Alle Größen berechnen« soll ebenfalls zu hoher CPU-Auslastung durch den Finder führen, da er für alle Unterordner eines Verzeichnisses die Größe berechnet.

Der Standard-Linux-Client von Dropbox, der nur für Ubuntu oder Fedora als kompiliertes Paket zur Verfügung steht, ist nur auf die Desktop-Umgebung Gnome ausgelegt. Versucht man unter Kubuntu den Clienten zu installieren, versucht die Paket-Verwaltung apt-get den Dateimanager Natuilus und den (gesamten) Gnome-Desktop nach zu installieren und dies ist bei einem Linux mit KDE nicht unbedingt wünschenswert.

Eine Lösung für dieses Problem ist bereits auf Englisch dokumentiert, diese Anleitung hier beschreibt eine etwas abgewandelte Lösung (u.a. über die sehr komfortablen Systemeinstellungen von KDE 4.3) mit ein paar mehr Deatails.

Um Dropbox mit KDE zu benutzen, greift man auf das Paket zurück, dass Dropbox für Linux mit reiner Text-Shell zur Verfügung stellt (verfügbar für 32-Bit- sowie 64-Bit-Prozessoren). (Anmerkung: Zwar benutzt dieses Paket für die GUI GTK+, aber der komplette Gnome-Desktop ist zum Glück nicht mehr nötig.)
Nachdem herunterladen und auspacken des Paketes soll der extrahierte Ordner .dropbox-dist (nach der Anleitung auf der Dropbox-Webseite) in das Home-Verzeichnis des jeweiligen Benutzers (/home/benutzername/) verschoben werden. Sinnvoller ist es, meiner Ansicht nach, gerade wenn der Rechner von mehreren Benutzern verwendet wird, den Ordner nach /opt/ zu verschieben (dafür sind allerdings Root-Rechte nötig).
Damit Dropbox kontinuierlich läuft und der Dropbox-Ordner immer synchronisiert werden kann, muss der Dropbox-Client im Hintergrund als Deamon laufen. Dazu sollte der Client immer starten, wenn KDE startet: Dafür geht man in Systemeinstellungen auf »Autostart« (im Reiter »Erweitert«).

[Screenshot: KDE-Systemeinstellungen]

In den Autostart-Einstellungen klickt man auf »Programm hinzufügen«; im Auswahl-Dialog dann auf den blauen Ordner (im Screenshot markiert mit 2.), im sich nun öffnenden Auswahl-Dialog geht man in das eben verschobene .dropbox-dist/-Verzeichnis (in meinem Fall /opt/dropbox/) in dem man die Datei dropboxd auswählt.

[Screenshot: Autostart-Einstellungen von KDE]

Die nun folgenden Dialoge können bestätigt werden und danach sollte der Dropbox-Deamon (dropboxd) unter »Einrichtungs-Datei (.desktop)« auftauchen.

[Screenshot: Autostart-Einstellung von KDE mit Dropbox-Deamon]

Bei der nächsten Neu-Anmeldung in KDE wird dann automatisch der Dropbox-Deamon gestartet. Dabei öffnet sich automatisch das Dropbox-Setup indem dann alle weiteren Einstellungen für Dropbox vorgenommen werden.

[Screenshot: Setup-Assistent von Dropbox]

[Screenshot: Tray-Icon und -Menü von Dropbox]

Im Tray-Bereich von KDE ist nun auch das Dropbox-Icon, dass über den Status des Dropbox-Ordners informiert, über einen einfachen Klick den lokalen Dropbox-Ordner öffnet (in Dolphin oder Konqueror oder des eingestellten Datei-Managers) und über einen Rechts-Klick das Tray-Menü öffnet, in dem alle wichtigen Informationen und Einstellungen zum eigenen Dropbox-Ordners zu finden sind.


Unter meinem Windows XP Professional SP3 hatte ich lange Zeit das Problem, dass sich der Internet Explorer 7 nicht installieren lies. Weder über Windows Update noch manuell. Die Installation ist jedesmal ohne weitere Fehlermeldung abgebrochen und die Tipps aus der Microsoft Knowledge Base (die einem dankenswerterweise als Link direkt auf den Desktop gelegt werden) halfen auch nicht. (Sie können sogar u.U. noch mehr Probleme machen als beheben!)

Heute habe ich, da sich der Internet Explorer 7 immer noch nicht installieren lies, versucht die Beta des neuen Internet Explorers 8 zu installieren. Dort brach die Installation ebenfalls jedesmal – ohne ersichtlichen Grund – ab und die Tipps aus der Knowledge Base für die neue Version halfen genauso wenig wie die für den IE7.
Im Log-File zur Installation, dass man schnell über den »Ausführen«-Dialog (Windows-Taste + R) mit der Eingabe von %windir%ie8_main.log öffnen kann, stand bis auf folgende Zeile nichts auffälliges oder brauchbares: ERROR: |Inst. IE >>> Internet Explorer installation completed with errors, exitresult=0x00000000, exitcode=0x000003f5
Im Log-File des Internet-Explorer 7, dass unter %windir%ie7_main.log zu finden ist, steht übrigens die gleiche Fehlermeldung.

Nach kurzer Suche mit dieser Fehlermeldung fand sich die Lösung in einem Forum: Der Adobe Reader 9 ist schuld!

Problemlösung

Da der Adobe Reader 9 die Installation einer neuen Internet Explorer-Version blockiert hilft nur: Adobe Reader deinstallieren; den Internet Explorer per Setup oder Windows Update installieren; Neustarten und dann ggf. den Adobe Reader wieder installieren.

Eigentlich mag ich WordPress ganz gerne. Seit Version 2.0 arbeite ich (fast) durchgehend damit; mittlerweile betreibe ich zwei Weblogs mit der aktuellen Version 2.6. Da ich mich im Moment intensiver mit WordPress auseinandersetze, fallen mir natürlich auch Dinge auf, die mir nicht so gefallen.

Bevor ich mich den zwei konkreten Punkten widme, die mir Ärger machen, ein kleiner Gedanke zum Konzept von WordPress: Ich finde WordPress mittlerweile für ein Blog-Software ziemlich fett: Mit fast 5 MB ist es leider kein Leichtgewicht mehr. Als CMS kommt es sicherlich schlank und komfortabel daher; aber als Blog-Software ist WordPress schon reichlich aufgeblasen und fett. Dafür ist es sehr flexibel, kann sehr vielseitig verwendet und erweitert werden; es gibt eine große Community die Erweiterungen und Themes entwickelt.
Dies ist aber ein generelles Problem bei der Software-Entwicklung: Große Gegensätze, die schwer gemeinsam zu erreichen sind (klein und simpel gegen flexibel und anpassbar); in der Wirtschaft wird so etwas auch Zielkonflikt genannt.
Auch wenn heute Webspace in rauen Mengen verfügbar und erschwinglich ist, sollte man sich überlegen ob eine große, Speicherplatz-fressende Anwendung sinnvoll ist oder ob man lieber auf etwas schlankeres zurückgreift. Gerade wenn sich Web-Applikationen auf einem Server häufen, so wie bei mir, sollte man über Alternativen nachdenken: Im Moment laufen auf über meinen Webspace zwei WordPress-Installationen, jede mit ungefähr 5 MB und die dritte steht kurz vor der Tür …

Zwei große Ärgernisse verderben mir leider im Moment etwas den Spaß mit WordPress:

  1. Seit Version 2.6 gibt es ein Versions-System für Artikel, wie man es aus Wikis (wie Wikipedia) oder auch aus Content Management Systemen kennt. Dieses Version-System ermöglicht einem, einen veränderten Artikel zu einer früheren Version zurückzusetzen, falls einem die veränderte Version aus irgendeinem Grund nicht gefällt.
    Dies kann sehr sinnvoll sein, wenn ein Weblog von mehreren Personen betrieben wird oder wenn man seinen Lesern erlaubt, eigene Artikel zu verfassen.
    Für mich ist diese Feature allerdings ein Ärgernis, denn es müllt meine Datenbank mit Einträgen zu. Jedes mal wenn ich einen Rechtschreibfehler korrigiere oder ein Stichwort hinzufüge, wird ein neue Version in der Datenbank angelegt. Und das leider nicht in einer eigenen Tabelle, sondern in der Tabelle für die generellen Blog-Einträge.
    Im Moment überarbeite ich gerade diesen Blog (dot.PsiLab alias PsiLab Journal) und meinen rein privaten Blog (»aber aber Arne …«) von Grund auf; ich bin dabei alte Einträge aus alten Blog-Versionen, die hier einmal liefen, wiederherzustellen und aufzuarbeiten. Dabei müssen zum Teil einzelne Beiträge öfters überarbeitet werden. Auf »aber aber Arne …« komme ich bei knapp 90 Blog-Einträgen (inklusive Unterseiten) auf fast 800 Datenbank-Einträge!
    Zudem verwässert dieses Versions-System einen Weblog mit fortlaufender ID für Beiträge. Früher waren Beiträge in diesem Weblog über dot.psilab.de/42 erreichbar. Wenn ich dies in der neuen WordPress-Version machen würde, würden sich bei einem regulären Blog-Betrieb (Eintrag erweitern, korrigieren, etc.) zum einen die IDs ständig ändern, weil ein Eintrag immer die ID der letzten Version bekommt. Und zum anderen können die IDs, die auf die alten Versionen verweisen, nicht mehr verwendet werden! So sind fortlaufende IDs nicht mehr möglich. Jetzt würden sich quasi die IDs 60, 42 und 327 aneinander reihen, statt 41, 42 und 43
    Update: Mit automatischem Speichern und Artikel-Speichern/-Vorschau habe ich für diesen einen Eintrag alleine schon 45(!) Versionen in der Datenbank. Und das bevor ich ihn überhaupt veröffentlicht hatte!
  2. Kategorien, Link-Kategorien und Stichworte sind dasselbe. Ein Umstand der mich in den letzten Tagen des öfteren die Haare raufen lies: Wenn ein Stichwort der Name einer Kategorie ist, wird die Kategorie als Stichwort hinzugefügt. Da bei mir die Stichworte aber nur klein geschrieben sein sollen/dürfen, ist dieses Feature wirklich ärgerlich.
    Das Problem rührt wohl daher, dass diese drei Kategorie-Arten in einer einzigen Tabelle in der Datenbank liegen. Was vielleicht auch noch kein Problem wäre, wenn in dieser Tabelle zweimal die gleiche URL-Form erlaubt wäre. Dies ist aber leider bei der Standard-Installation von WordPress nicht der Fall. Zwar wird bei der internen Verarbeitung von Kategorien und Stichworten unterschieden, aber nicht in der Datenbank und an der Benutzer-Oberfläche.
    Ein konkretes Beispiel, um das Problem etwas zu veranschaulichen: Ein Blog-Eintrag soll in die Kategorie »Foo Bar«, diese Kategorie hat die URL-Form foobar. Im Blog kann man diese Kategorie durch /category/foobar erreichen. Nun soll dieser Beitrag mit dem Stichwort »foobar« versehen werden. Das Stichwort soll ebenfalls die saubere URL-Form foobar haben; später soll sie dann über /tags/foobar erreichbar sein. So simpel dies klingt, so unmöglich ist dies im aktuellen WordPress. Man kann dies, mit Standard-Bordmitteln, nur erreichen, indem man entweder der Kategorie oder dem Stichwort eine unsaubere URL-Form gibt (z.B. für das Stichwort die URL-Form foobar-tag). Das ist leider, wie bei vielen Workarounds, nicht schön gelöst und sauber.

Schön wäre es, wenn es spätestens in WordPress 2.7 für das erste Problem eine Lösung gibt, die schon einige Plugins bereitstellen: Ein- oder Ausschalten des Versions-Systems oder dieses auf eine bestimmte Anzahl an alte Versionen für die Artikel limitieren. Dabei würde ich mir dann auch noch weitergehend wünschen, dass es ein Aufräum-Tool gibt, dass alte, nicht benötigte Versionen löscht und die IDs wieder aufräumt.
Für die Lösung des zweiten Problem muss wohl die Datenbank oder zumindest die Kategorie/Stichwort-Tabelle angepasst werden; was wirklich wünschenswert wäre, denn der oben angerissen Workaround ist wirklich hässlich.