Deshalb habe ich die ganze Erstellung der Grafik einfach auf die Client-Seite verschoben. HTML5 bietet nämlich mit dem Canvas-Element und etwas Javascript eine hervorragende Möglichkeit dafür.

Ich habe kurzerhand die ursprüngliche Vorgensweise mehr oder weniger neu mit Javascript gecoded jetzt kann man kann dabei zusehen, wie das Fraktal gemalt wird.
Hier direkt ein Ergebnis:

Wer tatsächlich live zusehen will, wie eine Drachenkurve mit 16 Iterationen gemalt wird, kann hier drauf klicken: Drachenkurve, 16 Iterationen, Live-Beispiel (es wird ein aktueller Browser mit Canvas-Unterstützung benötigt, z.B. Firefox, Chrome, Safari undso).
Da die Berechnung und das Zeichnen auf dem Client-Computer ablaufen, kann es schonmal ein paar Sekunden dauern, bis es anfängt zu zeichnen – abhängig von der Rechen-Leistung des Computers.
Für diejenigen, denen es zu lange dauert, weil mein Code vermutlich keinen Geschwindigkeits-Preis gewinnen würde, hier das fertige Bild.

Nachtrag: Ich hab grad mal versucht, die Seite mit dem Script im Standard-Browser von meinem Android Handy (Milestone, übertaktet auf 1GHz) zu starten… nunja, es funktioniert, aber es dauert laaaaaange…

Changelog

Also: wenn man eine Piwik-Installation aktualisieren möchte, am besten in der %piwik%/config/config.ini.php schauen, ob als Adapter “MYSQLI” ausgewählt ist und auf “PDO_MYSQL” ändern. Im schlimmsten Fall muss man das Server-System soweit aktualisieren, dass PDO_MYSQL unterstützt wird (bei mir war das nicht nötig).

[Fri Apr 15 16:05:40 2011] [warn] [client xxx.xxx.xxx.xxx] mod_fcgid: HTTP request length 138452 (so far) exceeds MaxRequestLen (131072), referer: (...)

Eine plausible Erklärung dazu wird hier sehr gut beschrieben.

Die Lösung besteht aus dem Hinzufügen der Zeile

FcgidMaxRequestLen 104857600

zur Datei “/etc/apache2/mods-available/fcgid.conf”. Nach einem Neustart des Apache2-Servers sollten dann Datei-Uploads bis 100 MB erlaubt sein.

Nach einer kurzen Debugging-Phase kam ich dahinter, dass sich die Methode open() der PHP-Klasse ZipArchive mit dem Fehler-Code 5 (ZIPARCHIVE::ER_READ) zurückmeldet. In den Kommentaren zu dieser Methode habe ich dann auch noch einen Hinweis auf zwei PHP-Bugs gefunden (40873 und 8714), die aber nicht ganz zu meinem Problem zu passen scheinen, denn ich konnte die Zip-Datei auf Konsolen-Ebene völlig problemfrei per “unzip” entpacken.

Ich habe mich nicht weiter mit den Bugbeschreibungen auseinandergesetzt, nachdem ich las, dass mit PHP 5.3 das Problem anscheinend gelöst wäre.
Wenn ich mein System von Lenny auf Squeeze aktualisiere, müsste es also mit etwas Glück wieder passen…

Das kam in dem Moment aber nicht in frage, also habe ich die Datei in PIWIK/tmp/latest/ entpackt und den verantwortlichen Code auskommentiert, der das Entpacken des Archivs übernimmt… und siehe da: es funzt natürlich!
Danach kam nur noch ein Datenbank-Update, der problemfrei durch lief.

Wer es genauer wissen will, ich habe in der Datei PIWIK/plugins/CoreUpdate/Controller.php ein paar Zeilen der Methode oneClick_Unpack() auskommentiert.
Die Methode sah danach so aus:
Achtung: Ich habe das nur für Version 1.1 zum Upgrade auf Version 1.2 durchgeführt! Andere Versionen sehen wahrscheinlich anders aus!

private function oneClick_Unpack()
{
$pathExtracted = PIWIK_USER_PATH . self::PATH_TO_EXTRACT_LATEST_VERSION;
unlink($this->pathPiwikZip);
$this->pathRootExtractedPiwik = $pathExtracted . 'piwik';
}


Update: Habe gerade ohne Problem Piwik per One-Click-Update von der Version 1.2 auf die Version 1.2.1 aktualisiert. Kurz zuvor hatte ich noch ein System-Update von Debian Lenny gemacht, in dem die PHP-Pakete aktualisiert worden waren (aber immer noch PHP 5.2.6-1), daher kann ich nicht sagen, ob der ein Bugfix von Piwik 1.2 gegriffen hat oder die neueren PHP-Pakete dafür verantwortlich sind.
Jedenfalls klappts jetzt wieder! Yay.

sed '1234,1345d' quelldatei.txt >neuedatei.txt

Hier wird der Inhalt der Datei quelldatei.txt ohne die Zeilen 1234 bis inklusive 1345 in die Datei neuedatei.txt kopiert.

Mein letzter Anwendungsfall für diesen Befehl war der Import eines 500 Megabyte grossen Datenbank-Backup-Dumps, bei dem gewisse Teile nicht in die neue Datenbank eingespielt werden mussten. Nachdem ermittelt wurde, welche Zeilen weggelassen werden sollten, konnte ich den Dump problemfrei einspielen.

Die Frage lautet also übersetzt: “Wie viele Ohren hat der durchschnittliche Mensch?”. Ein Kollege wollte daraufhin wissen, ob Google eine Antwort darauf hat. Ein direkter Test ergab nur eine Liste mit Webseiten, die Foren mit solchen Sicherheitsfragen hatten.

Aber da gibt es ja noch diese tolle Wundermaschine, von der keiner mehr was weiss, die aber damals durch alle Social Media Dinger gegeistert ist: Wolfram Alpha!
Ich hatte den Dienst letztens erst in Anspruch genommen, um die Fakultät einer grösseren Zahl zu ermitteln. Wolfram Alpha liefert da erstaunlich viele Ziffern…

Jedenfalls habe ich die Anti-Bot-Frage mal dort gepostet und siehe da: die Antwort erschien plausibel:

Wolfram Alphas Antwort: 2.

Ein weiterer Test mit der Frage “What is the first letter of the English alphabet?” aus der selben Forum-Software führte aber leider zu keinem befriedigenden Ergebnis.

Pidgin -> Konten -> Konten verwalten -> ICQ -> Bearbeiten... -> Erweitert -> clientLogin benutzen

Also einfach den Haken dort zusätzlich setzen und dann müsste es wieder klappen. Ich könnte mir vorstellen, dass man den Haken wieder entfernen muss, sobald die Server-Geschichten fertig sind…

SELECT INTERVAL '600' SECOND;
Das sieht doch gar nicht soo falsch aus und liefert auch keinen SQL-Fehler zurück. Leider ist das Ergebnis nicht gerade richtig: das Intervall zeigt ’00:00:00′ an.

Richtig wäre es so:
SELECT INTERVAL '600 SECOND';
Und siehe da: das Intervall ist ’00:10:00′, sprich: 10 Minuten. Yay!

• Internet Explorer 6.0 (Win XP)
• Internet Explorer 7.0 (Vista)
• Firefox 3.5.3 (Win XP)
• Firefox 3.0.14 (Debian/Iceweasel)
• Apple Safari 4.0 (Win XP)
• Opera 9.64 (WinXP und Debian)
• Google Chrome 2.0 (Win XP)
• Konqueror 4.3.1 (Debian)

In keinem dieser aufgelisteten Browser gab es ein derartiges Problem! Der einzige Browser, der im Ansatz Schwierigkeiten gemacht hatte, war der Internet Explorer 6.0 – aber nur, weil er die Facebook-Seiten erst gar nicht anzeigen wollte und dann komplett abgestürzt war. Nach dem dritten Versuch hatte er dann die Seite und das Formular ohne zu Mucken dargestellt – und eine Auswahl der Destination zugelassen.

Als ich erfuhr, dass der Kunde den Internet Explorer 8 verwendete, war ich erstmal ratlos, denn ich hatte gerade keinen zur Hand und ich konnte mir beim besten Willen nicht vorstellen, warum eine simple Select-Box ein Problem darstellen sollte. Nach einem Telefonat mit einem Freund, der ein System mit Internet Explorer 8 hatte, wurde mir der Fehler bestätigt. Leider hat das aber nicht erklärt, warum dieser Browser sich so verhielt – vor allem machte mich stutzig, dass die Vorgänger-Versionen ja nicht derartige Probleme aufwiesen.

Mir blieb also nichts anderes übrig, als ein eigenes System mit Internet Explorer 8 zum Experimentieren aufzusetzen. Zum Glück hatte ich noch eine Vista64-Lizenz rumfliegen. Nach etlichen Stunden der Installation und Updates und Probleme mit einer zu kleinen Systempartitionen (30 GB reichen für ein leeres Vista64 nicht aus, wenn man alle Updates inkl. SP1 haben will!), konnte ich endlich rumexperimentieren.

Die Lösung:
Ich kann zwar immer noch nicht erklären, warum sich der IE8 in diesem Fall so merkwürdig verhält, aber ich habe ein Workaround gefunden. Und zwar stellte sich heraus, dass immer nur die erste Select-Box betroffen war. Nachfolgende Dropdowns funktionierten einwandfrei. Mein Workaround: Banal und unschön, aber es funktioniert. Man baue vor der ersten Select-Box eine Dummy-Select-Box ein, die per Style unsichtbar gemacht wird (“display:none”) und siehe da, das Formular funktioniert so, wie erwartet – und der Benutzer kriegt davon normalerweise gar nichts mit.