Als Gedankenstütze (damit ich nicht wieder danach suchen muss):

Einstellungen Canon HV20 für Low-Light-Lichtverhältnisse:

* Kinomodus (statt P, Av und Tv)
* Custom Mode
* Kontrast +1
* Farbe +1
* Schärfe +1
* Belichtung 0
* Modus: 1080 25p

Ergebnis: wesentlich weniger Bildrauschen bei wenig Licht

Apples mail verstaut seine Informationen im Hintergrund in einer SQlite-Datenbank. Hier können sich besonders beim Umgang mit IMAP-Postfächern im Laufe der Zeit einige alte und damit obsolete Einträge ansammeln, die im normalen Programmablauf nicht entsorgt werden und dadurch die Applikation unnötig verlangsamen.
Man kann von Hand die Datenbank von nicht mehr benötigten Einträgen bereinigen und damit für deutlich mehr Speed sorgen.
Hierzu öffne man das Terminal bei beendetem mail und wechsle ins Biliotheksverzeichnis seiner Mails.

cd ~/Library/Mail

Nun kann man SQlite starten und die betreffende Datenbank öffnen:

sqlite3 Envelope\ Index

Wenn alles geklappt hat sollte sich nun das DBMS mit sqlite> melden und auf Eingaben warten. Mit folgendem Kommando werden nicht mehr benötigte Einträge geleert:

vacuum subjects;

Anschließend kann man SQlite durch Steuerung + D wieder beenden und mail wieder starten.
Zur Sicherheit empfiehlt sich vor durchführen dieser Schritte ein Backup der Mail-Datenbank ~/Library/Mail/Envelope Index.

Immer wieder versuchen nervige Script-Kiddies, Spam-Bots oder sonstige bösgestimmte Zeitgenossen, durch viele Anfragen an Webserver in sehr kurzer Zeit deren Funktion zu beeinträchtigen und die Auslieferung der Inhalte an „normale“ Besucher dadurch zu erschweren oder gar ganz zu verhindern.
Heutzutage generieren sich viele Webprojekte aus dynamisch erzeuten Seiten; die Bildung der Inhalte benötigt daher Rechenzeit und Speicher auf derm Webserver, was das DoS-Problem verstärkt. Durch zu viele Anfragen in zu kurzer Zeit steigt die CPU-Auslastung an und in ungünstigen Situation ist kein Seiteaufbau mehr möglich, da dem Server der RAM ausgeht.
Um hier Entlastung zu bringen wurde das Apache-Modul mod_evasive entwickelt (Download-Mirror), welches die maximal möglichen Verbindungen pro IP-Adresse kontrolliert und im Bedarfsfall abblockt. (weiterlesen…)

Ist der Bildschirmhintergrund mal wieder viel zu öde? Soll es neben der Arbeit ein bisschen Action auf dem Screen geben? Oder möchte man nur einmal mehr die Windows-User ein bisschen neidisch machen?
Mit einem simplen Einzeilen-Kommando im Terminal kann man den aktuell eingestellten Bildschirmschoner als quasi animierten Desktop-Hintergrund starten.
Einfach das Terminal öffnen und dort folgenden Befehl eingeben:

/System/Library/Frameworks/ScreenSaver.framework/Resources/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine -background &

…und schon wird es bunt und rappelig auf dem Schreibtisch.

Dank des Grafikframeworks von MacOS schluckt die Spielerei auch bei grafisch aufwendigen Savern nur wenig Prozessor-Power und stört somit den normalen Betrieb nicht merklich.
Und wenn’s genug gezapplet hat und/oder die Arbeit ungestört weitergehen soll: einfach das Terminal-Fenster schließen und der Spuk hat ein Ende.

Vorhin wurde ja schon über die neue Version 2.5 von Skype für Macintosh berichtet. Wie dort angesprochen wurde hierbei der Video-Codec nochmals verbessert und somit die Übertragungsqualität gesteigert. Trotzdem ist die Auflösung der übertragenen Videobilder nach wie vor bescheiden und erreicht immer noch nicht viel mehr als das berühmte ‘Briefmarkenformat’. Der Gesprächspartner kann das Fenster zwar bis auf Vollbild aufzoomen, dabei kommt jedoch die niedrige Auflösung nur noch deutlicher zum Vorschein.
In Skype 2.5 lässt sich nun jedoch, wie auch schon bei der Windows-Version, mit einem kleinen Eingriff in die Skype-Config-Datei die von der Kamera zu lieferne Auflösung „hochschrauben“ — und somit sind ruckelfreie Übertragungen mit bis zu 640×480 Pixel möglich.
Während unter Windows die Sache ein ziemliches Gefrickel mit dem Videotreiber darstellt, klappt es unter MacOS und iSight-Kamera mit zwei kleinen Textzeilen.
Man findet in seinem Homeverzeichnis unter Library/Application Support/Skype/<skypename>/ die Datei config.xml. Diese einfach mit einem normalen Texteditor öffnen (sinnvollerweise während Skype nicht läuft) und dort nach dem Eintrag <Video> suchen (dieser XML-Block sollte schon existieren, wenn Skype einmal seine Video-Funktion konfiguriert hatte.
Innerhalb dieses Blockes nun einfach folgende beiden Zeilen zufügen:

<CaptureWidth>640</CaptureWidth>
<CaptureHeight>480</CaptureHeight>

Damit sollte die Sache ungefähr so aussehen (evtl. sind noch ein paar zusätzliche Einstellungs-Tags dabei):

<Video>
   <CaptureWidth>640</CaptureWidth>
   <CaptureHeight>480</CaptureHeight>
   <Device>Built-in iSight</Device>
</Video>

Voilà – ab sofort ist die Video-Auflösung in Skype doppelt so hoch
Es sollte jedoch auch erwähnt werden, dass dadurch der Resourcenhunger von Skype ansteigt. Die Empfehlung geht von einem CoreDuo-Prozessor und einer Upload-Leistung von mindestens 128 kbit/s (besser mehr) aus.

Vielleicht standet ihr auch schon vor dem Problem: die URL-Struktur einer Webpräsenz hat sich geändert, Skripte, welche Inhalte dynamisch generieren, liegen an anderen Orten und u.U. hat sich auch die Struktur der zu übergebenden GET-Variablen geändert.
Prinzipiell eigentlich kein Problem, schließlich sollten die dynamischen Inhalte aus dem Gesamtkontext mit der neuen Struktur erzeugt werden; anders sieht es jedoch aus, wenn es sich bei den Skript-Dateien um wichtige Inhalte handelt, die auch bei Google schon gut indiziert sind.
Es wäre ärgerlich, wenn die bei Google geführten Links nicht mehr gültig sind und ins Leere laufen – oder sogar 404-Fehler erzeugen.
Um die Struktur von Web-Präsenzen auf neue Ziele „umzubiegen“ bietet sich ein Regelwerk in der sogenannten .htaccess-Datei an.
Leider ist die Umleitung von GET-Variablen nicht ganz trivial.
Der erste Gedanke wäre z.B. folgende Lösung, um die Parameter des Skripts datei.php — param1 sowie param2 auf die neue Location umzuleiten:

RewriteRule ^datei\.php\?param1=([^&]+)&param2([^&]+) /neu/datei/$2/$1 [R=301,L]
#falsch!!

So klappt es leider nicht, da mod_rewrite diese Behandlung von QueryParametern nicht toleriert.
Der richtige Ansatz läuft über Analyse des QueryStrings, um die GET-Parameter zu separieren:

RewriteEngine On 
RewriteCond %{QUERY_STRING} ^param1=([^&]+)&param2=([^&]+)$ 
RewriteRule ^datei\.php$ /datei/%2/%1? [R=301,L] 

Per %n wird hier auf die ‘Variablen’ der vorigen RewriteCond zugegriffen.
Nach diesem Muster lassen sich auch anspruchsvolle Umstukturierungen “google-freundlich” durchführen. Beispiele für weitere Rewrite-Methoden gibt es in der Apache-Dokumentation.