tanman 0.4

Nur so nebenbei, und für den Fall, daß ich nicht der einzige bin, der tanman benutzt: Version 0.4 ist fertig. Mit überarbeitetem Quellcode, einer Manpage, englischem Code und deutscher Lokalisierung ... und iTAN-Unterstützung.

Viel Spaß ;-)

b8-0.4 out soon

Die neue Version meines Spam-Filters b8 steht in den Startlöchern. Mein Part (der Großteil ;-) ist schon fertig, ich warte jetzt nur noch darauf, daß Laurent Goussard mir seine angepaßte Speicherklasse für SQLite schickt. Dann gibt's das neue Release 0.4!

Geändert hat sich einiges.

• Wenn schon, denn schon. Der Filter heißt b8, also sollte auch die Klasse b8 heißen, und nicht mehr bayes. Und die ganzen internen Variablen entsprechend. Aber das war nur Kosmetik ;-)
• Der Filter ist jetzt deutlich sauberer implementiert: Keine global(...);-Aufrufe mehr (die kürzlich erst für Kollisionen gesorgt hatten), der ganze interne Kram spielt sich jetzt tatsächlich innerhalb der Klassen ab; das einbindende Script sollte damit in keinster Weise mehr behelligt werden.
• Der ganze Code ist viel objektorientierter geworden, z. B. gibt es eine große Basis-Klasse, von der sich alle andern ableiten. Das ist aber eher eine Code-Qualität-Maßnahme gewesen und braucht den End-Anwender nicht zu interessieren ;-)
• Die Funktionen, die einen Text zerlegen, wurden in eine extra Klasse ausgelagert. Wenn also jemand einen speziellen Zerleger für spezielle Anwendungen will, kann er einfach einen einfügen und muß nur einen Eintrag in einer Konfigurationsdatei ändern (und bitte mir schicken, damit ich ihn ins nächste Release einbauen kann!).
• Die Konfigurationsdateien sind jetzt tatsächlich Konfigurationsdateien und enthalten keinen PHP-Code mehr.
• Das Interface wurde komplett überarbeitet. Es wird nun nicht mehr auf die eigentlich Datenbank zugegriffen, sondern eine SQL-abfragbare Arbeits-Datenbank erstellt (über ein weiteres Storage-Backend). Das Datenbank-Layout von b8 ist einfach nicht für das Sortieren aller Einträge nach irgendwas o. Ä. gedacht, sondern für den effizienten Betrieb während der eigentlichen Filter-Aufgabe. Also erschien mir das als die vernünftigste Lösung. Wenn alle Arbeit getan ist, kann aus der Arbeits-Datenbank wieder eine b8-Datenbank gemacht werden. Obschon hier auch nochmals darauf hingewiesen sei, daß man am besten den Filter einfach seine Arbeit machen lassen sollte, und das eher für Interessierte und für's Debugging gedacht war/ist.
• Die Speicherklassen können jetzt alle per Eintrag in der jeweiligen Konfigurationsdateien ihre Datenbanken selber erstellen.
• Es gibt viel mehr Fehler-Abfangen und Fehlermeldungen, wenn was schiefgeht.

Für MySQL-Nutzer hat sich auch einiges geändert:

• Die MySQL-Speicherklasse setzt jetzt nur noch addressierte Queries ab. Das heißt, die Queries werden jetzt nur noch mit einer Resource gemacht, nicht mehr „einfach so“. Falls also das Script, was b8 benutzt, ohnehin eine MySQL-Verbindung aufbaut, dann einfach den Rückgabewert von mysql_connect(...) an b8 weitergeben. Z. B.: $b8 = new b8($mysqlRes);. Das ist sinnvoll, wenn eben das Script sowieso eine MySQL-Verbindung macht, und die b8-Tabelle auch in der selben Datenbank liegt.
  Ansonsten können in der MySQL-Konfigurationsdatei auch Zugangsdaten zu einem MySQL-Server angegeben werden, und die Klasse macht sich ihre Verbindung selber.
• WICHTIG: Bitte macht ein Datenbankupdate. Nicht erst, wenn Version 0.4 da ist, sondern gleich: eine Tabelle, die mit den Angaben aus der bisherigen Anleitung erstellt wurde, macht keinen Unterschied zwischen der Groß- und Kleinschreibung der Token-Namen. Das ist aber wichtig für ein besseres Arbeiten von b8! Einfach folgenden Query absetzen: ALTER TABLE (Tabellen-Name) CHANGE token token VARCHAR(255) BINARY;. Das behebt den Fehler. BerkeleyDB- und SQLite-Nutzer sind davon nicht betroffen. Falls tatsächlich einer noch bayes-php <= Version 0.2.1 einsetzen sollte, bitte erst das in der aktuellen Version beschrieben Datenbankupdate durchführen.

So, das waren mal die groben Änderungen. jedenfalls alle, die mir gerade einfallen ;-) Sobald die SQLite-Speicherklasse da ist, gibt's das Release. Bis dahin: noch viel Spaß ;-)

Sichere Datensicherung

Vor kurzem habe ich mal meine sämtlichen alten, gebrannten CDs durchgeschaut, um mal zu sichten, was sich da alles angesammelt hat im laufe der Jahre. Waren ein paar interessante Sachen dabei, wie z. B. meine allererste Homepage, die ich für die JU Konradsreuth Anno 1999 online gestellt habe ;-)

Die Misere mit optischen Datenträgern

Bei einigen CDs gab es allerdings Probleme beim Auslesen und ein paar Dateien waren einfach weg. Unwiederbringlich. Zum Glück keine wichtigen. Aber bei dieser Gelegenheit habe ich erstmals am eigenen Leib erfahren, daß Datensicherung auf optischen Medien im Prinzip keine Datensicherung ist, sondern eher Datenroulette – „Werd ich das in zehn Jahren auch noch auslesen können?“ – wahrscheinlich nicht. Jedenfalls nicht ohne Fehler.

Da ich Backup-technisch ziemlich aktiv bin (zum Glück habe ich noch nie eines gebraucht!), hab ich mir schon länger überlegt, meine ganzen Fotos, etc. auch mal einfach auf CDs zu brennen und z. B. bei meinen Eltern einzulagern. Oder auch die DVD mit den Konzertmitschnitten meiner Band. Aber was hat man davon, wenn die Rohlinge vor sich hingammeln und früher oder später eh nicht mehr lesbar sind? Nichts. Richtig. Aber es gibt Abhilfe.

Die Rettung: Redundanz

Über dieses Problem haben sich zum Glück schon Leute Gedanken gemacht, die was von Mathematik verstehen. Und das, was die sich ausgedacht haben, macht sich (unter anderem) das Projekt dvdisaster zu nutze. Mit diesem Programm kann man Reed-Solomon-codierte redundante Datensätze für ein ISO-Image einer CD oder DVD erstellen. Im Klartext heißt das folgendes:
Wenn man eine CD mit unkorrigierbaren Lesefehlern hat, hat aber eine solche Rettungsdatei mit z. B. 20 % Redundanz erzeugt (die dann entsprechend 20 % so groß ist, wie der Quell-Datensatz), dann kann man damit 100 % der ursprünglichen Daten wiederherstellen, sofern 80 % der CD noch lesbar sind. Irgendwelche 80 % wohlgemerkt.
Um das ganze mal anschaulich zu machen: Ich hab einen Test durchgeführt. Eine CD gebrannt, eine Korrekturdatei mit 20 % Redundanz erzeugt; dann zwei mal mit dem Bürostuhl drübergefahren, mit dem Tapetenmesser fiese Kratzer reingemacht und an ein paar Stellen die Datenschicht komplett weggekratzt. Auf dem Foto sieht die CD etwas schlimmer aus, als es tatsächlich war, aber die CD hat schlimm ausgesehen.

Ergebnis der Wiederherstellungsaktion: dvdisaster konnte tatsächlich 100 % dieser arg geschundenen CD mittels der 20 % redundanten Daten wiederherstellen. Respekt.

Datensicherung

Konsequenzen daraus? Ich archiviere wieder ruhigen Gewissens Daten auf CDs. Nach dem Brennen werden Rettungsdateien mit 14 % Redundanz erzeugt (weil so schlimm wie im Beispiel richte ich meine Datenträger für gewöhnlich nicht zu ;-) Von fünf dieser Rettungsdateien wird ein ISO-Image gemacht, was seinerseits um redundante Daten erweitert wird (reicht noch für ~ 37 %) und auf eine Rettungs-CD gebrannt.
Einmal im Jahr werden alle Archiv-CDs und -DVDs auf Lesefehler geprüft. Auch das kann dvdisaster. Fällt dabei auf, daß ein Datenträger Daten verloren hat, ist ja auch davon auszugehen, daß auf der CD oder DVD, die die Rettungsdaten enthält, Lesefehler sind. Die wird man aber aufgrund der hohen Redundanz innerhalb der CD oder DVD selber sehr wahrscheinlich korrigieren können. Mit der so wiederhergestellten Rettungs-Datei kann man dann die beschädigte CD oder DVD retten und eine neue brennen.

Wenn man das so durchzieht, dann braucht man sich eigentlich keine Sorgen darüber machen, ob die Urlaubsbilder auch in zehn Jahren noch lesbar sein werden. Jedenfalls dann, wenn man handelt, bevor das Kind in den Brunnen gefallen ist!

www oder nicht www?

Darüber habe ich mir bisher noch nie Gedanken gemacht. Bis ich auf irgendeiner Seite einen Link auf http://no-www.org/ gefunden habe. Das ist eine Kampagne gegen das „www.“ vor Domainnamen.

Worum geht's da? Im Prinzip braucht man kein www. vor der Domain. Scheint ein Relikt aus vergangenen Zeiten zu sein. Argument: wenn man eine E-Mail an jemanden schreibt, muß man ja auch nicht an adresse@mail.server.de schreiben. Warum sollten dann Inhalte für einen Browser über die www-Subdomain laufen? Der Browser weiß doch ohnehin, daß er den Port 80 benutzen soll. Leuchtet irgendwie ein.
Meine Homepage ist (wie die meisten anderen wohl auch) sowohl unter http://nasauber.de/ als auch unter http://www.nasauber.de/ erreichbar. Wozu sollte man folglich dieses www. da hinschreiben? Bei Subdomains schreibt man das ja auch nicht hin.
Außer bei der Uni Erlangen, die höchst nervige www-Sub-Subdomains benutzt, wobei dann sowas rauskommt wie http://www.dekanat.med.uni-erlangen.de/. Wobei die Variante ohne www. übrigens nicht erreichbar ist.

Je länger ich darüber nachdenke, desto weniger Sinn sehe ich hinter diesen in den allermeisten Fällen redundanten vier Buchstaben. Also habe ich konsequenterweise den .htaccess-Rewrite, der bisher http://nasauber.de/ auf http://www.nasauber.de/ weitergeleitet hat, rausgeschmissen. Und die Links in meinen Atom-Feeds zeigen jetzt auch auf http://nasauber.de/.

Im Prinzip ist's ja eigentlich egal. Aber ohne www. sieht's irgendwie moderner aus ;-)