 |
|
…and Urbans Blog-O-MatSpaß an "krummen Dingen" |
Aufgrund des vorherigen Artikel bekam ich einen Tipp, den ich hiermit gerne weitergebe. Apple/IPod User sollten es gewohnt sein, dass alles “Spezial” ist, sodass alle erdenklichen Adapter nicht miteinander kombinierbar sind. Doch beim Entenkopf gibt es eine interessante Ausnahme, ein handelsübliches Kabel eines Radios / Elektrorasierers passt direkt in den Netzteil-Stecker. Dieses ist nicht nur interessant, wenn der Entenkopf defekt ist sondern auch, wenn das Kabel zu kurz ist.
Terminal Befehl gleich mit Copy/Paste übernehmen.
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister \ -kill \ -r \ -domain local \ -domain system \ -domain user
Als Anwort bekommt man die wenig ausdrucksstarke Meldung:
ThrottleProcessIO: throttling disk i/o
Wieso für das Entfernen ungültiger Einträge der Disk I/O gedrosselt wird, wissen anscheinend nur die “Apfel-Leute”, aber mir soll’s recht sein.
Zugegeben, TimeMachine Backups über SMB-Mounts werden offiziell nicht von Apple unterstützt. Daher hilft bei auftretenden Problemen alles jammern nicht, Lösungen müssen her. Immer wieder kann es vor allem bei zu kurzem Sicherungs-Intervall bzw. Unterbrechungen bei den Sicherungen zu einer Korruption des Sparsebundles kommen. Der Sicherungs-Intervall lässt sich sehr komfortabel mit der Freeware TimemachineEditor vergrößern, mir persönlich reicht 1 Backup / Tag.
Sollte die TimeMachine die Sicherung aufgrund eines Fehlers ablehnen, sind Reparaturmaßnahmen erforderlich.
Vor der Aktion mit dem Festplatten-Dienstprogramm weiter unten sollte man das Sparsebundle komprimieren und optimieren. Hierzu kommt der Terminal-Befehl hdiutil compact zum Einsatz. Wichtig dabei: Das Volume innerhalb des Sparsebundles darf nicht gemountet sein, ist also mit “xxxx auswerfen” über den Finder zu entfernen.
Copy/Paste Befehl:
hdiutil compact \ -batteryallowed \ -sleepallowed \ -verbose \ /Volumes/TimeMachine/xxxxx.sparsebundle
Hat die Optimierung geklappt folgt ein Reparaturversuch mit dem Festplatten-Dienstprogramm. Hierzu ist das Verzeichnis, welches das Sparsebundle enthält, einfach per Finder zu verbinden, sodass das Volume es im Festplatten-Dienstprogramm erscheint. das sparsebundle links in der Liste selektieren und den Button ” Volume reparieren ” anklicken. ” Volume überprüfen ” kann man sich schenken.
Leider kommt es trotz aller Maßnahmen zu irreparablen Sparsebundles. Daher bin ich nun dazu übergegangen, das sparsebundle via ROBOCOPY mithilfe eines geplanten Tasks auf eine externe USB-Disk zu sichern. Das geht sehr schnell und hat mich mittlerweile auch schon so manches Mal davor bewahrt eine vollständig neue TimeMachine aufzusetzten.
Als alter Unixer läuft bei mir stets ein Terminal mit “tail -f /var/log/system.log“. Mein AppleScript Projekt …. schreibt zu Kontrollzwecken über den logger Befehl ebenfalls in dieses Logfile. Aufgrund eines Progammfehlers lief das Script nicht mehr, aber in der System.log taucht jedesmal folgende Zeile auf:
... /System/Library/CoreServices/AppleScript Runner.app/ Contents/MacOS/AppleScript Runner[3844]: CPSGetFrontProcess(): This call is deprecated and should not be called anymore. ...
Selbstverständlich suchte ich die Ursache dafür in meinem Code, konnte aber nichts finden. Und CPSGetFrontProcess() sagte mir nun rein gar nichs. Die Meldung erschien jedesmal, wenn ein Script als Ordneraktion ausgeführt wurde, im AppleScript Editor ausgeführt erschien sie nicht. Also googelte ich um Hilfe und wurde auch an diversen Stellen fündig. Offensichtlich schleift MacOSX diese Meldung schon seit eingien Jahren mit sich herum. Es ist ein Hinweis für die Entwicker des AppleScript Runners, also dem Stück Software, welches die Scripte laufen lässt. Darin wird anscheinend immer noch die Funktion CPSGetFrontProcess() benutzt, obwohl sie nicht mehr verwendet werden sollte. Es ist also eine Meldung, für die man selbst keine Schuld hat, sie aber auch nicht abstellen kann. Das wollte ich testen und habe einfach mal ein paar Orginal-AppleScripte als Ordneraktion angehängt. Und tatsächlich werden auch hiermit diese Meldungen ins system.log geschrieben. Man müsste mal hochrechnen, wie viele Macs weltweit im Einsatz sind und wie viele davon AppleScripte verwenden. Bei jeder Ausführung eines solcher Scripte wird seit Jahren eine solche Zeile ins Logfile eines jeden Rechners geschrieben. Auch eine schöne Variante einen Computer zu beschäftigen.
Mich stört so etwas jedenfalls ungemein, hauptsächlich jedoch, weil man stundenlang durch solche unnötigen Meldungen bei der Fehlersuche von eigenen Programmen fehlgeleitet wird. Na klar, auch bei einer solchen Geisterjagd wird man nicht dümmer, aber es hält einen doch sehr davon ab, sein eigentliches Ziel zu verfolgen.
Durch CVS bin ich das erste Mal mit einer Versionsverwaltung in Berührung gekommen und seit dieser Zeit “mach ich’s nicht mehr ohne”. SVN habe ich seit den Anfängen verfolgt und konnte kaum das erste stable-release abwarten. Bislang habe ich noch nie einen Datenverlust bzw. -bschädigung erfahren und arbeite mit “Hosenträger UND Gürtel”. Doch dir Welt dreht sich weiter. Über einen Artikel in einer Fachzeitschrift stieß ich auf Mercurial und war sehr interessiert. “Git” hatte ich zwar auch schon gehört, aber nicht wirklich verfolgt.
Doch dann fand ich http://de.whygitisbetterthanx.com/
Über diese Vergleichsseite trat nun wiederum “Git” in meinen vordersten Fokus, vor allem, weil es dafür bereits eine Schildkröte für den Windows-Explorer gibt, als auch mit EGit [zu deutsch:"Igitt" 
] ein Plugin für Eclipse.
Weiterhin ist wichtig, dass die Gemeinde um dieses Tool “lebt” und dass es Mirgrationsmöglichkeiten vom SVN gibt.
Noch habe ich nicht die Muße gefunden, mich tiefer damit zu befassen, kann aber nur noch eine Frage der Zeit sein.
Weiterfühernde Links:
Aufgrund meiner Erfahrung mit Java, verwende ich für meine PHP Entwicklungen analog Eclipse for PHP als IDE. Seitdem ich auf WordPress 3.x umgstiegen bin und diesen Code ebenfalls ins Eclipse geladen habe, bewegte sich alles nur noch wie in dickem Brotteig, regelmäßig wurden mir Fehler um die Ohren gehauen wie:
!ENTRY org.eclipse.core.jobs 4 2 2010-09-25 17:12:57.455 !MESSAGE An internal error occurred during: "Semantic Highlighting Job". !STACK 0 java.lang.OutOfMemoryError: Java heap space at org.eclipse.php.internal.core.ast.scanner.php53.CUP$....
Die Suche nach der Lösung bzw. Linderung führten mich in die gefürchteten Abgründe diverser Developer Mailforen, wo ein Stackdump mit dem nächsten beantwortet wird. Nicht unbedingt förderlich ist dabei meine Plattform (Mac, Snow Leopard). Aber schließlich wurde dann doch fündig
In der Eclipse.app befindet sich die eclipse.ini zur Steuerung der Java-VM.
Hier meine aktuellen Einstellungen, mit denen sowohl mein selbstkompliliertes Subversion-JavaHL sauber erkannt wird, als auch kein Java Heap Space Error mehr auftaucht. Die IDE-Perfomance ist wieder so fix wie früher, ich habe endlich wieder das Gefühl auf meinem lokalen Rechner zu arbeiten und nicht in einer VM, welche ich über min. 3 dazwischengeschaltete Remote-Sessions bediene.
Inhalt von:
/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
-startup ../../../plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.0.v20100503 -product org.eclipse.epp.package.php.product --launcher.defaultAction openFile -showsplash org.eclipse.platform --launcher.XXMaxPermSize 768m --launcher.defaultAction openFile -vmargs -Dosgi.requiredJavaVersion=1.5 -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=768m -Xms128m -Xmx1024m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Djava.library.path=/usr/local/subversion/lib
