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ß ;-)
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!
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 ;-)
Was les ich da im tagesschau-Newsticker? „Microsoft zu Milliardenstrafe verurteilt“. Schön! Aber warum? Weil wohl das MP3-Format nicht allein vom Fraunhofer-Institut entwickelt wurde, sondern wohl auch patentierte (!) Datenkompressionsverfahren der Bell Labs benutzt wurden, die später von Lucent gekauft wurden, die später von Alcatel gekauft wurden. Oder so. Und Alcatel fand's nicht lustig. Wie das genau zusammenhängt, weiß ich nicht. Und wer jetzt warum welche Ansprüche auf was hat, weiß ich auch nicht.
Aber ich kann mich eines leicht diabolischen Grinsens einfach nicht erwehren, wenn ich lese, daß Micro$oft wegen eines Softwarepatents mal so richtig in Schwierigkeiten kommt und jetzt eventuell einen riesen Haufen Geld zahlen muß. Hallo, Herr Ballmer (*wink*). Aber wie sieht's dann mit allen anderen aus, die MP3 benutzen? Wird jetzt jeder verklagt, der MP3 benutzt? Warum muß gerade Microsoft zahlen?
Egal wie: auch, wenn das jetzt vielleicht klingt wie im Heise-Forum: Mit Ogg Vorbis wär das nicht passiert!
Ich predige ja schon immer jedem, daß Vorbis einfach der bessere Audiocodec ist. Macht kleinere Dateien bei besserer Qualität und das auch noch schneller (zumindest als LAME). Und: Vorbis ist komplett patentfrei. Die Spezifikation ist „public domain“, die Bibliotheken, die die Vorbis-Entwickler geschrieben haben, stehen unter einer BSD-artigen Lizenz.
Und das heißt: jeder, der will, kann Vorbis benutzen, ohne etwas dafür zahlen zu müssen. Jeder Hersteller kann es in seine Software stecken oder in seinen MP3-Player einbauen. Oder damit machen, was er will.
Aber die wenigten tun das. Warum auch immer. DRM-WMA kann jeder. Na toll. Wie konnte ich nur bisher ohne leben?! Aber Vorbis spielen die wenigsten Autoradios und MP3-Player ab. Grausam eigentlich, daß sich „MP3-Player“ tesafilmartig für alle tragbaren Geräte durchgesetzt hat, die komprimierte Audiodateien abspielen können. Ich nenne aus Prinzip das meiner Freundin, den Trekstor i.Beat organix, eine lobenswerte Ausnahme der obigen Regel, „Vorbis-Player“.
Ist vielleicht etwas illusorisch, aber vielleicht findet ja, wenn das Urteil so durchgeht, doch ein kleines Bißchen Umdenken bei den Herstellern statt …
