Ausflug nach K-Town
Nach noch nicht einmal 4 Monaten (März, April, Mai und Juni) kehre ich kurz an die TU Kaiserslautern zurück. Allerdings nur um einen kurzen Vortrag über IT-Sicherheit zu halten. Wenn den jemand sich ansehen möchte:
Donnerstag, 26. Juni 2008, 17:15 – 18:45 in Hörsaal 46-210
Für alle, die meinen alten Sicherheitsvortrag schon kennen: Es gibt einen neuen, und es hat sich mehr verändert als nur das Folienlayout. Allerdings sind knapp 160 Folien in 90 Minuten eine Herausforderung. Und ich verwende nicht den Stil von Alec Muffet.
Erste Gehversuche mit Grails
Heute habe ich erste Gehversuche mit Grails gemacht. Ich bin mir aber noch nicht sicher, ob ich da auf den heiligen Gral gestoßen bin.
Gut – ich habe ein wenig Erfahrung mit dem Programmieren. Java und Visual Basic sind mir geläufig. Da sollte Grails, sozusagen Groovy on Rails, ja nicht der große Schritt sein. Trotzdem kann ich mich noch nicht an die teilweise sehr einfache Art des Programmierens gewöhnen.
Viele Ideen sind ja einleuchtend und überzeugen mich sofort. Alleine dass die Zeilen
class DocumentController {
def scaffold = Document
}
einem das langwierige Programmieren einer Website mit CRUD-Funktionalität abnehmen, erleichtern den Einstieg in das Programmieren total.
Was mich aber als alter Datenbankliebhaber richtig begeistert hat, ist das GROM (Grails Relational Object Mapping): Es legt direkt die notwendigen Tabellen in der genutzten Datenbank an und füllt diese mit Daten, die über die Formulare eingegeben werden. Im Normalfall nutzt Grails eine einfache relationale Engine im Hauptspeicher, doch kann man durch eine einfache Änderung alles in eine JDBC-taugliche Datenbank schreiben. Total cool: Ich mache mir meine Gedanken zum Datenkonzept ohne ein bischen Hintergrundwissen darüber, wie das in einer relationalen Datenbank aussehen würde. Dann programmiere ich so, als ob es die Datenbank bereits gebe. Grails macht den Rest erzeugt sie.
Der eine oder andere wird jetzt sagen: Schon mal was von Ruby on Rails gehört?
Ja, habe ich. Ich kenne sowohl Ruby als auch die Schienenvariante. Die Konzepte gefallen mir auch, die Sprache aber nicht. Ich programmiere allerdings zu selten, um mir neben meiner Java-Kenntnisse ein zweites Standbein aufbauen zu wollen. Groovy und Grails stellen für den Java-Gewohnten eine interessante Erweiterung dar, da die Syntax sehr ähnlich ist und man seine gewohnten Bibliotheken weiterhin nutzen kann. Daher bleibe ich erst mal bei Groovy und Grails.
Matthias, ja, dieser Blogeintrag ist definitiv auf Dich zurückzuführen.
Das Ziegenproblem
Jahr der Mathematik, nächster Versuch. Heute Ziegen.
Genauer gesagt zwei Ziegen und ein Auto. In den 1990er Jahren waren Gameshows mit drei Toren angesagt. Harry Wynford versuchte es mit “Der Preis ist heiß”, Zonks und anderes Getier krabbelten durch die Fernsehlandschaften.
Man stelle sich eine solche Situation bildlich vor. In einer Gameshow steht der Kandidat von drei Toren, hinter einer Tür ist der Hauptpreis (ein schnelles Fluchtfahrzeug, um ganz der Show entfliehen zu können), hinter den andern beiden Türen sind Ziegen, die Nieten symbolisieren sollen. Der Kandidat hat keine Ahnung, was sich wo verbirgt, der neben ihm stehende Moderator allerdings schon.
Also wählt der Kandidat blind eines der Tore aus. Der Moderator öffnet daraufhin eines der beiden nicht ausgewählten Tore, darin ist eine Ziege (Es ist klar, dass der Moderator die Spannung erhalten möchte und daher unter keinen Umständen die Tür mit dem Auto öffnet. Er wird eine Ziegentüre öffnen).
Das Spiel hat sich verändert. Nur noch ein Gewinn und eine Niete sind im Spiel. Und dann die Frage des Moderators: “Möchten Sie wechseln?”
Auf den ersten Blick ein triviales Problem – die Chance auf das Auto steigt, wenn man in diese neue Situation ohne Vorwissen gehen würde, auf 50%. Doch Moment mal, man hat Vorwissen. Man weiss, dass man mit einer Wahrscheinlichkeit von 1/3 das Auto gewählt hat, also müsste man es doch mit einer Wahrscheinlichkeit von 2/3 nicht gewählt haben.
Marilyn vos Savant hat über dieses Problem einen langen akademischen Streit mit diversen Verfechtern der 50:50-Theorie geführt. Nachzulesen hier!
Alles in allem geht es um ein Problem mit bedingter Wahrscheinlichkeit. Die Auswahl in der ersten Runde bedingt das Verhalten des Moderators und damit die zweite Auswahlrunde. In einem Drittel der Fälle (dann, wenn man das Auto ausgewählt hat), ist hinter dem verbleibenden nichtgewählten Tor eine Ziege. In zwei Dritteln der Fälle ist hinter dem verbleibenden nichtgewählten Tor ein Auto. Also rentiert sich der Wechsel in 2 von 3 Fällen. Soweit die umgangssprachliche Erklärung.
Die Mathematik kann das auch, und zwar beispielsweise mit dem Theorem von Bayes. Bayes, in der Wirtschaftsinformatik gern zitierter presbyterianischer Pfarrer aus dem England des 18. Jahrhunderts, hat sein Theorem über bedingte Wahrscheinlichkeiten veröffentlicht, der mathematisch korrekte Beweis von Wikipedia übernommen. Gegeben sei der Fall, dass der Moderator Tor B geöffnet und man selbst das Tor A gewählt habe. Dann ist P(Gewinn in C | Moderator hat B geöffnet):
Noch deutlicher wird die Bedeutung der bedingten Wahrscheinlichkeit übrigens in der Medizin. Folgende Ausgangssituation (ausführlich beschrieben samt der psychologischen Folgen bei Gerd Gigerenzer im Buch “Das Einmaleins der Skepsis”): Eine Krankheit tritt bei etwa 2 von 10.000 Menschen auf. Nun hat gibt es einen Test zur Diagnose eben jener Krankheit, der die Krankheit in 99% der Fällen findet, in 1% der Fälle bei einem Gesunden fälschlicherweise aber auch anschlägt.
In Bayes-Notation:
- Krankheit tritt bei einem bestimmten Menschen aus der Grundgesamtheit aller Menschen auf: P(A) = 0,002%
- Test fällt positiv aus: P(B) = 0,0100196 (kann aus den übrigen Angaben errechnet werden)
- Krankheit wird vom Test bei einem erkrankten Menschen gefunden = P(B|A) = 99%
- Krankheit wird vom Test nicht bei einem erkrankten Menschen gefunden = P(B|AC) = 1% (AC = Komplement von A)
Setzt man dies nun in das Bayestheorem ein, erhält man als Erkrankungswahrscheinlichkeit bei positivem Test rund 2%! Das bedeutet: Man ist mit einer Wahrscheinlichkeit von etwas weniger als 1 gesund.
Das erscheint unglaublich. Aber da hilft ein bischen “Mengenlehre”. Nachfolgendes Bild zeigt drei Kreise. Der größte Kreis symbolisiere die Grundgesamtheit. Er hat einen Radius von 10 Längeneinheiten, und somit eine Fläche von etwa 314 Flächeneneinheiten. In diesem Kreis befindet sich ein zweiter Kreis. Der Kreis hat einen Radius von etwa 1 und eine Fläche von 3,202 Flächeneinheiten. Er symbolisiert die Menge aller Personen, bei denen der Test positiv anschlägt. Innerhalb dieses Kreises befindet sich ein weiterer kleiner Kreis. Er hat eine Fläche von 0,00628 Flächeneinheiten, also 0,002%*314, und symbolisiert die Menge aller Erkrankten. (Er schaut ein wenig aus dem Kreis heraus. Das sind die wenigen erkrankten Fälle, bei denen der Test nicht anschlägt).
Bei diesen Zahlenspielen ist aber eines noch zu beachten: Hier wurde als Grundgesamtheit eine repräsentative Stichprobe aller Menschen gewählt. Sollte man einen Test nicht auf eine solche Grundgesamtheit anwenden, sondern auf eine Menge, in der die Erkranktenquote sehr viel höher ist (beispielsweise Leute, die erste Symptome einer Krankheit aufweisen) steigt P(B|A) sofort merklich an.
Als Beispiel: Das Resultat des ersten Tests liege vor, und man kann nun einen zweiten Test verwenden, dessen Ergebnis von dem des ersten unabhängig sei. Statt 0,002% Erkrankungsquote ist die Quote jetzt bei 2% , sofort steigt die Wahrscheinlichkeit, bei positivem Ergebnis erkrankt zu sein, auf etwas über 66%. Ein dritter, unabhängiger Test erhöht sorgt bei positivem Ergebnis dann für annähernde Gewissheit: Also immer mehrere, unabhängige Tests verwenden, dann steigt die Chance einer korrekten Antwort.
Just another funny benchmark…
Benchmarks sind was feines, insbesondere wenn man damit angeben kann. Ein richtig cooler Benchmark ist der TPC-C, mit dem man OLTP-Lasten simuliert und benchmarken kann. Der Benchmark ist so cool, dass IBM ihn selbst nicht mag und ihn gerne duch dessen Nachfolger ersetzen möchte: ftp://ftp.software.ibm.com/eserver/benchmarks/wp_TPC-E_Benchmark_022307.pdf . Dennoch nutzt IBM diesen Benchmark gerne, um die Leistungsfähigkeit ihrer Maschinen zu unterstreichen.
Gut, der Benchmark hat seine Schwächen. Er erlaubt Modifikationen an den verwendeten Datenbanken, die sich niemand für ein reales System erlauben würde. Er erlaubt auch Hardwarekombinationen, die sich kein Mensch leisten würde. Ein richtig krasses Beispiel hat IBM sich jetzt erlaubt – eine Konfiguration jenseits jedlicher Realität:
Der in 6 Monaten sogar erhältliche IBM Power 595 Server Model 9119-FHA hat das beeindruckende Resultat von 6.085.166 Transaktionen erreicht (Power 6 Prozessor mit 5 GHz. Liegt da ein Abo für Klimaanlagen-Upgrades bei?) .
Was aber klar sein sollte: TPC-C korreliert extrem mit der Anzahl der angeschlossenen Festlatten. Und davon hat IBM immerhin “nur” 10.192 angeschlossen. Man stelle sich das mal bildlich vor: Angenommen IBM bekommt 48 Platten auf 4 Höheneinheiten unter, so braucht man 852 Rackunits, um die Platten unterzubringen. Das entspricht etwa 22 Racks mit 42 RU.
IBM bekommt aber 48 Platten nicht auf 4 Rackunits unter. IBM benötigt dafür 68 DS4800 (4RU) und 784 DS4000 EXP810 (3RU) . Das sind in Summe 2624 RU oder 63(!) Racks. Die Stellfläche hat nicht jedes Rechenzentrum zu Verfügung.
Alles vollgepackt mit surrenden Festplatten und in der Mitte ein großer Kubus mir Power-Prozessoren – bei einem gebündelten Abluftstrom würde ein durchnässter Admin (3 Liter Wasser in der Kleidung bei einer Körperoberfläche von 2m²) binnen 6 Sekunden getrocknet werden – allerdings müsste man ihn mit Seilen gegen Wegfliegen sichern. Klingt sehr nach einer Konfiguration aus dem wirklichen Leben.
IBM hat ja schon Erfahrung in der Kraft-Wärme-Kopplung. Vielleicht sollten sie mit ihrem Benchmarkcenter eine Großstadt mit Fernwärme versorgen.
Happy Birthday, liebe Systemhelden!
In München kämpfen Rolf, Andreas, Christian, Constantin und Marc für mehr Ruhm zu Ehren der Helden des Systems. Und ihre Huldigungsplattform www.systemhelden.com wird heute 2 Jahre alt.
Herzlichen Glückwunsch zu diesem Erfolg, und möge das Aufheulen des Thumpers im Heldenfunk noch viele Jahre lang aus dem iPod schallen!
Hier noch ein Kuchen für Euch, auch wenn das Datum nicht ganz stimmt 
