Duden Korrektor für OpenOffice unter Linux (Ubuntu)

So wie wahrscheinlich viele, leide auch ich unter der mangelhaften Rechtschreibkorrektur. Viele Fehler werden entweder gar nicht erkannt, oder falsch als Fehler gekennzeichnet. Insbesondere bei vielen zusammengeschriebenen Wörtern versagt die Prüfung komplett.

Um diesen Mangel zu beseitigen, benutzte ich schon seit Jahren unter Windows den Duden Korrektor (seit Version 3.5) für OpenOffice. Unter Windows klappt so weit alles gut, da der XP bis dahin praktisch nur in 32-Bit-Version lief.

Seit über 3 Jahren nutze ich vermehrt Linux, als primäres Betriebssystem, und seit einem Jahr noch Mac OS X 10.5 (Leopard) für meine Frau. Also wurde kurzerhand der Duden Korrektor (Version 5.0 mittlerweile) auch auf diese Systeme installiert, theoretisch. Bei Mac gibt es keine Probleme. Die Erweiterung läuft auf 64-Bit.

Unter Linux ist ein 64-Bit-System dagegen eine absolute Bremse. Es funktioniert einfach nicht. Auch konnte ich bis jetzt keine Workarounds finden, die eine funktionierende Umgebung erzeugen. Unter 32-Bit läuft es dagegen ohne Probleme (EeePC 1000H).

Die Anfragen an Duden Verlag direkt ergaben nichts. Es kommt nur die Antwort, das 64-Bit-Systeme nicht unterstützt werden, auch nicht in der Zukunft. Mittlerweile steht sogar in den Systemanforderungen (Version 6.0), dass Windows XP und Vista nur in den 32-Bit-Versionen unterstützt werden. Bei Linux wird merkwürdigerweise keine solche Ausnahme angegeben.

P.S.: Ein schneller Test der Version 5.0 mit OpenOffice 3.1 unter Windows 7 x64 RC1 zeigte, dass auch hier keine Inkompatibilitäten auftreten.

Testbericht: SanDisk Ultra Backup 32GB

Vor ein paar Wochen wurde in tecchannel.de nachgefragt, ob jemand einen 32 GB großen USB-Stick mit Backup Funktionen testen könnte. Ich habe mich da kurzerhand angemeldet und nach kurzer Zeit den USB-Stick auch zum Testen geliefert bekommen. Meinen Testbericht können Sie bei tecchannel.de nachlesen:

SanDisk Ulta Backup 32GB

Mittlerweile stehen auch Testberichte von 3 weiteren Testern zur Verfügung:

Erfahrungsbericht des SanDisk Ultra Backup 32GB als Festplattenersatz (von Legionen)

TecChannel Lesertest: SanDisk Ultra Backup 32 GByte (von Linuxgirl)

Lesertest 32 Gbyte SanDisk Ultra Backup USB-Stick (Test)

3D Kino in Mathaser (München)

So wie mein Freund Jan, wollte ich auch den Ice Age 3 in 3D sehen (sein Beitrag „3D Kino im Matthäser – so nicht“). Habe mich aber dazu durchgerungen, die 13,50 EUR auch zu bezahlen. Den „gewaltigen“ Preisunterschied kann ich irgendwie auch nicht nachvollziehen.

In Mathaeser wird für die 3D Darstellung die „Real D“ Technik verwendet, die mit nur einem Projektor auskommt. Dabei wird jedes Bild durch einen Aufsatz mal rechts drehend, mal links drehend polarisiert. Der Projektor muss dabei natürlich auch die doppelte Bildfrequenz schaffen, im Vergleich zu Verfahren, die zwei Projektoren nutzen. Wie im ct‘ Magazin aber berichtet, ist dieses Verfahren aber trotzdem günstiger (die silberbeschichtete Leinwand muss auch hier verwendet werden, um die Polarisation zu erhalten).

In Forumkinos wird mit zwei synchronisierten Projektoren gearbeitet, die das Bild jeweils horizontal oder vertikal polarisieren. Der Nachteil dieser Technik ist, dass beim Neigen des Kopfes der 3D-Effekt verloren geht und man Geisterbilder sieht. Bei Real D Technik passiert es nicht. Meiner Meinung nach ist es aber kein ausreichender Grund, um die Preise so zu salzen.

Ich muss aber zugleich zugeben, dass der 3D Kinosaal rappel voll war und die Betreiber wohl kaum die Preise senken werden, solange der Andrang so groß ist. Ich denke, dass die Preise in 6-12 Monaten auf Normalniveau fallen, sobald 3D nicht mehr eine Ausnahme, sondern eher die Regel für die Kinos wird und auch die anderen Kinos in München nachziehen. Dann wird der Konkurrenzdruck auch die Preise besser regeln.

Das Einzige, was mir noch den absoluten Spaß am Kino verdirbt, ist die mangelnde Auflösung in den digitalen Kinosälen (auch 3D). Eine 2k-Auflösung ist der Standard fürs Zuhause, aber nicht fürs Kino. Mit einem guten Fernseher der neueren Generation entfällt der Mehrwert eines Kinobesuchs, leider.

Bleib zu hoffen, dass es nicht so lange bleibt.

Erste Erfahrungen mit TYPOlight unter IIS und MySQL

TYPOlight mit XAMPP oder bei einem Shared Host Provider aufzusetzen, ist vergleichsweise einfach und unproblematisch.

Vor kurzen wurde mir aber eine Aufgabe gestellt, die nicht mehr so einfach zu lösen war. TYPOlight sollte auf einem Windows 2003 Server laufen, und möglichst mit Windows Bordmitteln. Das hieß nichts anderes, als dass CMS unter IIS 6.0 und MS SQL 2005 laufen sollte.

Die Verwendung der MS SQL Datenbank scheiterte nach mehreren Versuchen komplett. Da fehlt einfach noch die Erfahrung in der Community. Es ist zwar ein Abstraktionslayer für die MS Datenbank vorhanden, aber bis jetzt gibt es keine positiven Rückmeldungen, dass TYPOlight wirklich damit läuft, und vor allem, wie man dieses einrichtet. Vielleich finde ich noch in meiner Freizeit ein wenig Zeit und probiere es zum Laufen zu bekommen.

Als erstes Testsystem benutzte ich Windows XP mit IIS 5.0.  Grundsätzlich läuft TYPOlight auch unter IIS 5.0, allerdings mit mehr Einschränkungen, als unter IIS 6.0. Auf beiden Windowsumgebungen wurde PHP 5.3 und MySQL 5.0 verwendet (Version 5.1 hat einen defekten Windows Installer, der unter Server 2003 die Installation versagt).

Der einzige Unterschied zwischen IIS 5.0 und IIS 6.0, den ich feststellen konnte, war, dass es unter IIS 5.0 keine Suchmaschinenfreundliche URLs möglich sind. Man muss immer „Keine Seitenaliase verwenden“ aktivieren, damit die Seiten überhaupt aufgerufen werden können. Somit ergeben sich aber folgende URLs:
www.domain.de/index.php?id=123

Unter IIS 6.0 können suchmaschinenfreundliche URLs verwendet werden, so wie diese standardmäßig von TYPOlight generiert werden (ohne Zuhilfenahme von HTACCESS).
www.domain.de/index.php/alias.html

Weiterhin müssen für den TYPOlight Ordner (oder nur tl_files und tmp Ordner) die Rechte für den IIS-Benutzer (Vollzugriff) gesetzt werden, damit TYPOlight in diese Ordner auch schreiben kann. Wer die Dateien über die integrierte Verwaltung hoch laden will, wird hier auf mein anderes Eintrag verwiesen, damit die PHP-Temp-Einstellung richtig funktioniert.

Solange man MySQL als Datenbank einsetzt, spricht eigentlich nichts dagegen den IIS als Webserver zu nutzen. Microsoft ist ja immer mehr bemüht auch PHP direkt in Visual Studio und andere Produkte einzubinden, sodass eine bessere Zusammenarbeit zu erwarten ist. Für eine leichte Installation ist sowohl FastCGI als auch PHP 5.2 über den Microsoft Web-Installer verfügbar (www.microsoft.com/web). Die einzige Schwierigkeit, die noch bleibt, ist die Unterstützung von .htaccess Dateien, die man von Apache her kennt und die von vielen PHP-Projekten für die Generierung freundlicher URLs verwendet werden. Es gibt zwar schon ISAPI Erweiterungen die htaccess nachbilden, aber zumindest bei TYPOlight ist es noch nicht ausreichend, um 100% Funktionalität und Stabilität zu gewährleisten.

Datei-Upload unter IIS in Verbindung mit PHP

Nach den ersten Gehversuchen mit TYPOlight unter Windows läuft das System nun stabil und flott (mit ein paar Einschränkungen). Nach dem der Kundenbereich erstellt wurde, sollte auch eine Uploadmöglichkeit her. Also schnell ein Formular mit Upload-Möglichkeit angelegt und getestet. Theoretisch funktioniert, aber nicht so wirklich. Im Uploadordner landen merkwürdigerweise nur 0kB große Dateien.

Zugriffsberechtigungen überprüft, stimmt alles, also blieb nichts anderes übrig, als zu googln. Der erste Hinweis kam, dass in der PHP.ini ein Temp-Ordner für Uploads definiert ist, auf den der IIS-Benutzer aber keine Schreibrechte hat (c:\Windows\Temp). Also in der PHP.ini den Ordner auf c:\Upload-Temp geändert und dem IIS-Benutzer auf diesen Ordner volle Rechte vergeben. Zwecklos. Es landen weiterhin 0kB Dateien im Zierordner. Auch ein Neustart brachte keine Besserung.

Nach mehreren Stunden Recherche im Internet kam der entscheidende Hinweis, dass der Temp Ordner unbedingt innerhalb des Root-Verzeichnisses der aufrufenden Homepage liegen muss, sonst kann IIS in Verbindung mit PHP keine temporären Daten in diesen schreiben.

Die Änderung der PHP.ini-Datei führte nun zum gewünschten Ergebnis. Der Upload funktioniert nun einwandfrei.