RackBlogger

Sehr schöne Kampagne von solidar.ch.

Bei uns kommt im Büro übrigens ausschließlich fair gehandelter Kaffee in die Maschine. Ãœblicherweise GEPA Bio Caffè Crema, oder - wenn die Vorräte spontan knapp werden - ONE WORLD Bio Caffè Crema von “Feinkost Albrecht”

Schmeckt verdammt lecker, produziert keine Berge an Alukapsel-Müll, und man hat keinen Vendor Lock-In.

Wer kennt sie nicht - die guten alten AOL-CDs, mit welchen man Ende der 90er-Jahre regelrecht überschüttet wurde.

Irgendwie beschleicht mich das Gefühl, dass Google mit seinen AdWords-Gutscheinen die selbe Vermarktungsstrategie verfolgt. Da wird zwar nicht ganz so viel Müll in Form von CDs produziert, aber immerhin genug unnötiges Papier (Zeitschriftenbeilagen, Flyer, Postkarten, …) und Spam. Selbst wenn man ein AdWords-Konto hat (und nutzt) bekommt man noch Werbe-E-Mails mit unbrauchbaren Gutscheinen (da sich diese ja nur an Neukunden richten)…

Beim Durchstöbern meiner RSS-Feeds bin ich eben auf die Meldung von Icinga gestoßen, wonach diese künftig zur Abstraktion der Datenbankabfragen Doctrine einsetzen, statt für jede unstützte Datenbank eigene SQL-Befehle zu pflegen.

Der Hintergrund ist folgender: möchte man seine Daten beispielsweise sowohl in einer MySQL- als auch in einer Oracle-Datenbank speichern können, müssen beide Datenbanksysteme häufig mit unterschiedlichen SQL-Statements angesprochen werden. Das liegt darin begründet, dass jeder Datenbankhersteller sein eigenes Süppchen kocht - verschiedene Standards (SQL-92, SQL-99) werden zwar relativ breit unterstützt, aber manchmal hört es mit der Kompatibilität schon auf, wenn man nur einen Datum-Wert in einem Statement verwenden möchte. Sowas wird übrigens gerne auch als Vendor Lock-In bezeichnet.

Ein Ansatz ist eben, die eigentlichen Zugriffe durch die Verwendung eines Objektpersistenz-Frameworks zu abstrahieren. Der Vorteil ist ganz klar eine ordentliche Trennung der verschiedenen Funktionsbereiche und eine saubere Klassenstruktur. Ein Nachteil dabei kann aber sein, dass man auf die Performance durch Optimierung der Abfragen vielleicht keinen Einfluss hat (kommt sehr auf den jeweiligen Einzelfall an).

Ein anderer Weg wäre, für alle zu unterstützenden SQL-Dialekte eigene SQL-Statements zu pflegen. Davon rate ich aber entschieden ab: zum Testen muss die komplette Anwendung somit auf allen unterstützten Datenbanksystemen vollständig geprüft werden, der Pflegeaufwand ist sehr hoch und entsprechend auch sehr fehleranfällig.

Bei LiveConfig standen wir vor einer ganzen Weile vor genau dem selben Problem. Es sollen verschiedene Datenbanksysteme unterstützt werden (vorerst SQLite und MySQL, später PostgreSQL und vielleicht auch Oracle), während aber nicht für jedes DBMS eigene SQLs gepflegt werden sollen. Doctrine kam nicht in Frage (schließlich entwickeln wir in C/C++), und besonders viele leichtgewichtige C/C++-Persistenz-Frameworks auf SQL-Basis scheint’s nicht zu geben.

Wir haben daher einen völlig anderen Ansatz verfolgt. Das war zwar mit einem recht hohen Initial-Aufwand verbunden, zahlt sich aber (unserer Ansicht nach) auf Dauer aus: die Entwicklung eines eigenen SQL-Ãœbersetzers. Man muss sich das so vorstellen: die Anwendung “spricht” einen relativ generischen SQL-Dialekt (im Groben und Ganzen ein SQL99), und bevor ein Statement zur Datenbank gesendet wird, wird es in den entsprechenden Ziel-Dialekt übersetzt.

Beispiel: es sollen die Datensätze 11 bis 15 einer Tabelle abgerufen werden. In MySQL macht man das mit

SELECT a, b, c FROM table WHERE b=1 ORDER BY a LIMIT 5 OFFSET 11

während man mit Oracle (als Extrembeispiel) etwas mehr tricksen muss:

SELECT a, b, c FROM (SELECT a, b, c, rownum AS limit_rownum FROM (SELECT a, b, c FROM table WHERE b=1 ORDER BY a)) WHERE limit_rownum BETWEEN 11 AND 15

Unsere Lösung wird in Form einer eigenen C-Bibliothek in den Code eingebunden und stellt eine datenbankunabhängige API zur Verfügung. Die Bibliothek kümmert sich dabei selber um das Laden der notwendigen Datenbank-Treiber (libmysqlclient, OCI, …); somit weiß man auf Anwendungs-Ebene im Grunde auch gar nicht, auf welchem System die Anfragen nun tatsächlich ausgeführt werden.

In unserem Fall würde die Anwendung für o.g. SQL-Anfrage also folgendes Statement verwenden:

SELECT a, b, c FROM table WHERE b=:1 ORDER BY a LIMIT :2 OFFSET :3

Intern wird dieses dann automatisch in den gewünschten Ziel-Dialekt (s.o.) übersetzt. Jede Anfrage wird dabei als Prepared Statement abgearbeitet, welches durch unsere Bibliothek intern auch noch zur Wiederverwendung gecached wird. Die Vorteile liegen auf der Hand:

• die Ãœbersetzung in den Ziel-Dialekt muss während der gesamten Laufzeit nur ein einziges Mal durchgeführt werden
• auch die Datenbank muss das Statement nur ein einziges mal parsen
• da alle Parameter über Variablen gebunden sind, sind SQL Injections praktisch unmöglich

Das Ergebnis: eine unschlagbare Performance und gleichzeitig voller Einfluss auf den Aufbau der SQL-Statements. Die Bibliothek lässt sich isoliert wunderbar testen (für alle SQL-Anfragetypen haben wir entsprechende checklib Unit Tests geschrieben), und auch für andere Projekte prima recyclen.

Der Hauptaufwand bestand in der Entwicklung des entsprechenden SQL-Parsers (hier auf Basis von lex und yacc) sowie der möglichst vollständigen Unit-Tests. Natürlich wird nur ein Bruchteil des kompletten SQL-Sprachumfangs abgedeckt, aber eben alles, was unsere Anwendungen benötigen. Als letztes “Leckerli” können wir natürlich auch zentral alle SQL-Anfragen loggen, und diese Logs analysieren (z.B. die Häufigkeit der Statements auswerten, oder fertig übersetzte Statements zur Optimierung der Tabellen-Indizes verwenden).

Für Perl bin ich vor Jahren mal über SQLFairy gestoßen, was scheinbar einen ähnlichen Ansatz verfolgt. Eine andere (etwas schwergewichtigere) Alternative wäre übrigens ODBC.

Gestern habe ich (als o2-Kunde) folgende SMS auf mein Handy erhalten:

Von: o2 Team [26 Jul. 2011 13:47]
Seit 06.06 gilt für Sie im EU-Ausland die Reise-Option. Infos dazu und zur kostenlosen Wechselmöglichkeit zum EU-regulierten Tarif: o2.de/goto/ausland-preise.

Das ich da rückwirkend über eine Preisänderung vor über sechs Wochen informiert werde fand ich schon etwas merkwürdig - Grund genug, mal die Preise anzuschauen. Und siehe da - es ist für mich tatsächlich eine satte Verteuerung, da sich diese neue Option nur bei langen Gesprächen im Ausland (ab ca. sechs Minuten) rechnet. Und ich telefoniere im Urlaub am liebsten überhaupt nicht, und wenn dann nur möglichst kurz.

Passenderweise kam heute die Rechnung per Post, und vor einigen Wochen war ich tatsächlich im Urlaub (in Österreich, Italien und Schweiz). Ein kurzer Blick auf den Einzelverbindungsnachweis - und tatsächlich: mir wurden bereits die “neuen” Preise berechnet.

Aber es kommt noch besser: mein Handy speichert freundlicherweise die letzten paar hundert SMS; ich lösche das eigentlich nur wenn ich wieder Platz für neue Nagios-Alarmierungen brauche. Darunter waren auch Preis-Informationen, wie man sie üblicherweise erhält, sobald man sich in ein ausländisches Netz einbucht. Wie zum Beispiel diese Meldung:

Von: o2 Preise [28 Jun. 2011 16:39]
In der Schweiz und in die EU kosten Anrufe 54ct/min, eingehende Anrufe 26ct/min, exkl. Sonderrufnummern. SMS Versand: 39ct. SMS Empfang ist kostenlos.

Da steht definitiv nichts von zB. 0,75€/Anruf, wie es die neue Reise-Option nun berechnet…

Ich habe mich heute entsprechend bei der Hotline beschwert - man prüft meinen Fall nun und will sich in ca. drei Tagen noch mal melden.

Ich finde das schon eine ziemlich dreiste Abzocke, und kann nur hoffen, dass das noch ein Nachspiel haben wird. Laut teltarif scheinen sich ja schon EU-Kommission und Bundesnetzagentur dafür zu interessieren.

Wer also auch kürzlich im Urlaub mit o2 telefoniert hat, oder das in den nächsten Wochen vor hat, sollte mal einen genauen Blick auf seine Rechnung werfen. Die Preis-SMS scheint ja ziemlich unverbindlich zu sein…

Schon bei der Ãœbernahme von MySQL durch Oracle hatte ich irgendwie kein gutes Gefühl im Bauch. Die letzten Monate über hat sich das immer weiter bestärkt. Am 30.12.2010 kam ein Brief aus den USA (per DHL-Express - ich will gar nicht wissen was das gekostet hat), mit dem alle bisherigen Partnerverträge von Sun fristlos aufgekündigt wurden. Danach hat es einige Monate gedauert, bis Oracle das hauseigene “OPN” (Oracle Partner Network) um eine Hand voll MySQL-Produkte erweitert hat (in der Zwischenzeit ging bekanntlich “gar nichts”). Nach einem mehrstufigen Registrierungsprozess, spontanen Anrufen von Oracle-Callcentern und etlichen Webcasts kann darf man dann (theoretisch) MySQL-Produkte verkaufen - aber nur, wenn man mindestens den “Gold-Level” (für schlappe $2.995,- pro Jahr) hat.
Das eigentliche Problem besteht aber woanders: stellt man nun eine (kommerzielle) Software her, die nicht unter GPL-Lizenz steht und auch nicht die Kriterien für die FOSS-Ausnahmen erfüllt, dann kann man derzeit MySQL-Datenbanken nicht unterstützen. Die Verwendung der Client-Bibliotheken ist alternativ nämlich nur mit einer OEM-Lizenz möglich, und die gibt es bei Oracle derzeit irgendwie nicht. Ich stehe nun schon seit Wochen in Kontakt mit dem “Orakel” (u.a. mit dem viel zitierten “OEM Sales Team”), aber habe schlicht und ergreifend noch gar keine Antwort erhalten. Telefonisch wies man mich mit Floskeln auf die eben erwähnte Gold-Level-Mitgliedschaft im OPN hin, wenngleich diese auch keine OEM-Lizenzen oder vergleichbare Berechtigungen beinhaltet. Und selbst wenn - ich sehe es nicht ein, Geld für die Anbindung eines Open-Source-Datenbanksystems zu zahlen.

Wie geht es weiter? Nun, die Idee, die eigene Software einfach mit den MySQL-Client-Bibliotheken einer Distribution zu verlinken, klappt auch nicht, da immer noch die unter GPL stehenden MySQL-Header genutzt werden (müssen). Ich sehe derzeit folgende alternative Ansätze:

• eine Ausnahme in der (alten) MySQL-Lizenzvereinbarung, die es erlaubt, bisher veröffentlichte Produkte mit MySQL-Client-Bibliotheken in der selben Version auch weiterhin veröffentlichen zu dürfen -> ist halt blöd wenn man Updates machen will
• eigene Header-Files, welche ABI-kompatibel zum derzeitigen MySQL-Client sind, und unter “großzügigeren” Lizenzen stehen. Ist aber auch blöd, weil dann natürlich alle Funktionsnamen, Strukturen usw. an die “eigenen” Header angepasst werden müssen. Außerdem ist die Lizenzfrage in so einem Fall immer noch recht strittig: der MySQL-Client steht nämlich unter GPL und nicht LGPL
• Verwendung des Drizzle-Clients, der (angeblich) zu MySQL kompatibel ist. Problem: nach einer kürzlichen Code-Konsolidierung des Clients in den Haupt-Codebaum kaum separat bzw. “von Hand” compilierbar…
• Entkoppelung der Datenbankanbindung durch eine eigene Bibliothek, die unter einer der FOSS-Lizenzen steht. Nachteil: diese Zwischen-Bibliothek müsste dann aber im Sourcecode veröffentlicht werden.

Vielleicht liest zufällig ja jemand bei Oracle diesen Artikel, und möchte dann Kontakt mit mir aufnehmen. Ich hatte auch auf der CeBIT einige Gespräche in dieser Richtung, und viele Entwickler sind derzeit äußerst zurückhaltend was die MySQL-Unterstützung betrifft, da Oracle es nicht schafft mal eine klare Aussage zu treffen.

Mir wäre es ja am liebsten, wenn Oracle das bisherige “MySQL Enterprise Driver Software License Agreement” wieder aktivieren und fortführen könnte… *wink_mit_dem_Zaunpfahl*

Ich hatte eben 12 (!) Tabs im Browser geöffnet, nur um mir alle Informationen zusammen zu suchen, die man benötigt um eine Zollnummer zu beantragen. Daraus könnte man glatt ein Adventure-Spiel machen.

Am besten hat mir dieser Ausfüllhinweis gefallen:

Letzte Woche kam bei uns ein unerwartetes Paket an:

Ein Unternehmen aus der Region hatte eine Domain an einen berüchtigten Domaingrabber verloren. Mit dieser Auswahl feiner fränkischer Weine bedankten sie sich nun für die Unterstützung zum Zurückholen der Domain, was (zum Glück) offenbar reibungslos geklappt hatte.

Das Paket wäre natürlich nicht nötig gewesen, aber ich bedanke mich an dieser Stelle trotzdem ganz herzlich.
(die Tatsache, so indirekt auch vom Domaingrabbing zu profitieren, lasse ich mal besser auf Seite )

Da ab morgen das De-Mail-Gesetz in Kraft tritt möchte ich auch mal meinen Senf dazu geben: ich werde diesen Blödsinn definitiv nicht unterstützen. Unsere Rechnungen werden nach wie vor in Papierform oder digital mit qualifizierter elektronischer Signatur versendet.

Der Grund: ich möchte kein System unterstützen, das nach Außen Sicherheit vorgaukelt (”Verschlüsselung”), zum Zwecke der Virenprüfung dann aber doch alle Daten dekodieren kann. Es gibt dort eben keine Ende-zu-Ende-Verschlüsselung, sondern nur eine Absicherung des Kommunikationskanals zwischen Nutzer und Serverbetreiber. Und das bekommt man mit jedem normalen Mailserver und SSL/TLS auch hin.
Es gäbe übrigens eine ganz einfache Lösung zu der Viren-Problematik: nur den Versand von Textmitteilungen erlauben. Was keinen Virus enthalten kann, muss auch nicht zentral “geöffnet” werden können. Und mit “nur Text” meine ich auch “nur Text”: keine PDFs, kein XML. So wie das nun seit über zwanzig Jahren auch mit normalen ASCII-E-Mails funktioniert.

Aber selbst dann hätte ich so meine Bedenken. Schließlich gibt es auch dann noch unverschlüsselte Daten - die sogenannten “Verkehrsdaten” (wer schreibt wem wie oft E-Mails), die praktischerweise quasi zentral (bei nur einer Hand voll Anbietern) anfallen. Die TKÃœV ist somit viel einfacher umzusetzen…