#macosx

Nun, dann und wann erfreue auch ich mich am Eskapismus in virtuelle Welten: Dabei interessieren mich die kleinen, auch merkwürdigen, Spiele; lasse ich mich von Super Level Lost Levels inspirieren und bin Jahre hinter dem Hype.

Heute: Catlateral Damage. Der »first-person destructive cat simulator« stand wohl schon länger auf meiner Liste: Der cheesige Infomercial-Clip ist immerhin von 2015, der erste (und einzige) Bericht bei Super Level von 2014 und die offizielle Website habe ich mir spätestens seit Dezember 2018 gemerkt!

Bis zum Vergnügen des Auf-Schränke-und-Tische-Springens und Regalmeter-weise-Bücher-herunter-Stupsens galt es aber ein Installations-Minigame zu lösen: Unter macOS Catalina (10.15.5) lies sich die Spiele-Datei, trotz 64-Bit-Version, nicht starten: »The application „Catlateral Damage (64-bit)“ can’t be opened.« OK, Google: Anscheinend liegt es an der Art, wie das macOS-eigene Archivierungsprogamm die ZIP-Datei entpackt, mit The Unarchiver entpackt, funktioniert es und die Spiele-Datei lies sich starten. Nur noch der macOS-Sicherheits-Limbo und: RAMPAGE!

Pow, Pow, Meow! Aber halt, schon am Ende des Tutorials geht es nicht weiter: Das Bild ist von der Wand geholt, aber es wird nicht als zerstört erkannt und im Pause-Menü funktioniert der Quit-Button nicht. Merkwürdig. Hey Siri: Anscheinend mag es das Spiel nicht, wenn es nicht im vorgesehenem Ordner liegt … Also: Ab damit in den großen Programme-Ordner und das Spiel schnurrt wie ein zufriedenes Kätzchen nach einem Zerstörungsfeldzug durch die Wohnung.

Vorletzte Woche Mittwoch hat leider meine MacBook-Festplatte ihren Geist aufgegeben, zum Glück konnte ich aber noch alle Daten auf einer externen, mit HFS+-formatierten Festplatte sichern (HFS+ wird auch »Mac OS Extended« genannt). Um wenigstens etwas weiterarbeiten zu können, wollte ich die externe Festplatte mit meinem Linux-Rechner mounten (derzeit mit Ubuntu 12.04 LTS), dazu habe ich einfach die Pakete hfsplus und hfsutils über apt-get nachinstalliert:

apt-get install hfsplus hfsutils

Beim Versuch die Festplatte über KDE mittels der »Geräteüberwachung« zu mounten, erschien immer die Warnmeldung:

Requested filesystem type is neither well-known nor in /proc/filesystems nor in /etc/filesystems

Allerdings ließ sich die Festplatte ohne Probleme händisch mounten (wobei ich den Mount-Punkt zuvor mit mkdir /media/BackupDisk angelegt habe):

mount /dev/sdc2 /media/BackupDisk

Um aber die Festplatte nicht immer händisch ein- und aushängen zu müssen und um die Geräteüberwachung von KDE nutzen zu können war nur ein kleiner Kniff nötig:

Auf meinem System existierte die Datei /etc/filesystems noch nicht, also habe ich sie kurzerhand mit nano angelegt:

nano /etc/filesystems

Hinein musste nur der (richtige) Name des Dateisystems:

hfsplus

Datei mit STRG + O speichern und schon lässt sich die externe HFS+-Festplatte problemlos über die Geräteüberwachung ein- und aushängen.

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 auf dem Desktop zu einem hohem CPU-Verbrauch durch den Finder führen können, 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.

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.