www.firehead.de - Blog von Rene Schneider

The Build Lamp: Lavalampe meets Ethernet meets Jenkins

Inzwischen habe ich nun endlich mal ein kleines Bastelprojekt fertigbekommen, an dem ich schon ne ganze Weile schraube. Es geht um ein Extreme Feedback Device für das Projekt, in dem ich jobmäßig gerade beschäftigt bin. In dem wird nämlich Jenkins als Continuous-Integration-Plattform eingesetzt, d.h. in regelmäßigen Abständen wird ein Software-Build automatisch ausgeführt und das Ergebnis dann getestet, wobei sich ein Status von grün (alles bestens) über gelb (Build ok, aber mindestens ein Test ist fehlgeschlagen) bis rot (Build-Fehler) ergibt. Den kann man dann im Webinterface des Jenkins sehen, was sehr praktisch ist, weil man so mit nur kurzer Verzögerung nach Code-Checkins darüber informiert wird, ob die eigenen Code-Änderungen gut mit denen anderer Entwickler harmonieren oder im Zusammenspiel mit diesen irgendetwas unerwarteterweise kaputt gegangen ist. Aber eigentlich ist das ziemlich langweilig, das immer nachzugucken, und die Mails, die das CI-System automatisch bei Problemen versendet, sind auch irgendwie nett, aber unspektakulär. Deswegen kam vor vielen Jahren mal jemand auf die geniale Idee, irgendwelche realen Gerätschaften so mit einem Rechner zu koppeln, dass sie den aktuellen Build-Zustand quasi "greifbar" in der realen Welt visualisieren - und DAS sind Extreme Feedback Devices, oder kurz XFDs.

Bevor es losgeht mit diesem doch eher länglichen Artikel zeige ich am besten zur "Motivation" mal gleich das Endergebnis :-)

Es ist eine Lava-Lampe! Eine Lava-Lampe mit Netzwerkanschluss!! Eine bunte Lava-Lampe mit Netzwerkanschluss, die ihre Farbe wechseln kann!!! Die Farben korrespondieren wie eben erklärt mit dem Zustand des zu überwachenden Builds - ist die Lampe also grün, ist alles bestens, wird sie gelb ist irgendwo mindestens ein Test fehlgeschlagen und wenn sie rot ist, ist die Kacke gewaltig am Dampfen!

Die Hardware

Grundsätzlich kann man fast alles für den Zweck eines XFDs hernehmen, was man auf irgendeinem Wege elektronisch an- und abschalten kann. Drei farbige Lampen sind immer beliebt, auch in kreativen Variationen wie z.B. in Bär-Form :-). Ebenfalls ein Klassiker sind Lava-Lampen - die Idee hat mir grundsätzlich sehr gut gefallen, aber ich fand es etwas zu simpel, einfach nur eine Lampe an- oder abzuschalten bzw. mehrere Lampen für die verschiedenen Farben hinzustellen. Warum denn nicht eine Lampe nehmen, die immer an ist, aber die Farbe wechseln kann?

Stellte sich heraus, dass es in der Tat sogar höchst passendes Rohmaterial dafür gibt. Und nicht nur irgendeine Lava-Lampe, nein, sogar ein limitiertes Original von Mathmos, dem Erfinder der Lavalampen! Mehr Style geht nun wirklich nicht mehr :-) also musste so ein Ding her!

Als nächstes war zu klären, wie die Lampe beleuchtet und der Farbwechsel gesteuert werden sollte. Da die Lampe von sich aus schon auf LED-Technologie basiert, war die Leuchtmittelfrage schnell geklärt - LEDs sind simpel zu schalten, billig, brauchen wenig Strom und in jeder Farbe zu bekommen, ich würde also entweder die eingebauten LEDs dafür hernehmen oder eigene stattdessen einbauen, je nachdem was praktikabler ist. Beim ersten Öffnen der Lampe stellte sich dann raus, dass wohl letzteres der Fall ist: es sind zwar nur zwei unterschiedliche LED-Farben verbaut, nämlich blau und rot (blau wird durch die Eigenfarbe der "Lava" optisch zu grünem Licht, und durch Mischung mit Rot kann man ein Gelborange erzeugen), aber die LEDs saßen direkt auf einer kleinen Platine, welche die Heizung für die Lava steuert - da kann ich mich nicht so einfach mit meiner eigenen Steuerung dazwischenklemmen. Es würde also eine eigene "Beleuchtungseinheit" erforderlich werden - und wenn ich das eh schon mache, kann ich auch gleich noch ein paar mehr LEDs für mehr Power verbauen und zudem gelbe LEDs dazunehmen, um die gelbe Farbe intensiver hinzubekommen als nur durch die Mischung. Gelb ist immerhin wichtig, zeigt es doch an, dass die Tests fehlgeschlagen sind, also den Hauptfehlerfall bei einer vorbildlich guten Testabdeckung *räusper* ;-).

Gut, Beleuchtung geklärt, bleibt die Steuerung. Die meisten Selbstbau-XFDs, die man im Web so findet, hängen einfach an irgendeinem alten Rechner, der dann die CI-Webseite pollt, den Status ausliest und dann per USB-Steckerleiste oder ähnlichem Strom ein und aus schaltet. Das hat den Vorteil, dass es simpel zu bauen und zu programmieren ist, aber man hat eben ständig einen Rechner mehr laufen - irgendwie unelegant. Wollte ich so nicht haben - meine Idealvorstellung war mehr sowas wie eine Netzwerkbuchse an der Lampe, die darüber selbsttätig den Status abfragt und das Licht dann sanft zur neuen Farbe überblendet. Ein Mikrocontroller musste also her, und ein Netzwerkinterface dafür! Damit war auch gleich sichergestellt, dass die Lampe nicht nur einen hohen Style-, sondern auch einen ausreichend hohen Nerd-Faktor haben würde :-)

Praktischerweise bietet Pollin da einen schönen Bausatz unter dem Namen AVR NET-IO an, der für günstiges Geld ziemlich genau das enthält, was ich brauchte: einen ausreichend potenten Mikrocontroller, ein Ethernet-Interface (zwar nur 10 MBit, aber die Datenrate bekommt man mit einem 8-Bit-Mikrocontroller eh nicht mal ansatzweise ausgereizt), direkte Kompatibilität mit den 12V Spannung, mit der auch die Lavalampe läuft und mehr als genug steuerbare Ausgänge. Zwar ist die Platine relativ groß, so dass diese definitiv nicht ins Lampengehäuse passen würde, aber immerhin hat sie Europakartenformat, so dass man dafür viele passende Gehäuse findet. Oh, und es gibt im Wiki von mikrocontroller.net eine Menge Infos zu dem recht beliebten Bausatz und auch einiges an Code im Netz, der dafür geschrieben wurde, was immer praktisch ist, weil man dann nicht ganz von Null anfangen muss. Den Bausatz habe ich dann letztlich in ein schlichtes schwarzes Kunststoffgehäuse gesteckt, in dessen Blenden ich Löcher für das Netzwerkkabel, den seriellen Port (nutze ich im Moment gar nicht, aber just in case...) und einen Taster gesägt habe - und natürlich für das fünfadrige Kabel zur LED-Einheit, über welches die Schaltung auch mit Strom aus der Lampe versorgt werden würde. Das Ganze sah dann in verbauter Form wie auf folgendem Bild aus:

Zurück also zur Beleuchtung. Die LEDs sollten auf möglichst einfache Weise angeschlossen werden, also versuchte ich es im ersten Schritt mit einer simplen Reihenschaltung von drei (blau) bzw. 5 (gelb und rot) 3mm-LEDs sowie pro Farbe einem Transistor zum Schalten. Vorwiderstände hatte ich keine eingeplant, und um maximale Helligkeit zu erhalten waren die Reihenschaltungen so ausgelegt, dass die LEDs an ihrer Maximalspannung laufen würden. Das sah erst ganz gut aus: die resultierende Platine hatte gerade mal 3cm im Durchmesser, die LEDs leuchteten kräftig. Aber nach dem Einbau in die Lampe wie auf dem folgenden Bild gezeigt - der Einfachheit halber setzte ich die LED-Platine direkt auf die Originalplatine, die senkrecht in der Lampe steckt - erwies sich die Schaltung als problematisch.

Die LEDs erzeugen durch die hohe Spannung und den daher hohen Strom einiges an Wärme, und zusammen mit der Hitze von der Heizeinheit, die direkt über der Platine montiert war, knockte das die LEDs der Reihe nach aus. Nach einer halben Stunde Testbetrieb flackerte alles nur noch, und als ich die Platine dann anschließend wieder ausbaute waren deutliche Flecken darauf zu erkennen. Das Ding war reif für den Müll.

Beim zweiten Versuch war ich dann vorsichtiger:

Mehr LEDs pro Reihenschaltung und ein 20-Ohm-Vorwiderstand sollten den Strom und damit auch die Verlustwärme begrenzen.

Statt 3mm-LEDs kamen 5mm-LEDs zum Einsatz - dadurch wird zwar die Platine größer (5cm Durchmesser statt 3cm), aber die größeren LEDs sind robuster und außerdem auch heller, was den geringeren Strom ausgleichen sollte.

Statt einer Montage auf der bestehenden Steuer-Platine der Lampe entschied ich mich dafür, diese Platine flach auf den Boden der Lampe zu legen und in die Halterung stattdessen ein Stückchen Holz zu stecken. Auf diesem wiederum klebt, durch Zweikomponentenkleber befestigt, eine Münze, deren Oberfläche mit schwarzem Lack isolierend lackiert ist und die dann die LED-Platine trägt. Da sind gleich mehrere Ideen zusammengekommen: die Metallmünze sollte Wärme besser nach unten ableiten als der Kork, mit dem ich vorher gearbeitet hatte, und das Holz statt der Original-Platine erlaubte es mir, die Befestigungshöhe frei zu wählen, so dass die LED-Platine nun einige Zentimeter weiter entfernt vom im Betrieb sehr heißen Heizelement sitzt.

Dieser neue Aufbau funktionierte dann problemlos. Im Schaltplan und auf dem Board sieht das folgendermaßen aus...

...und in montierter Form dann so:

Im Betrieb ergibt das ein wunderbares Farbenspiel :-)

Und auch nach Aufsetzen des Lampengehäuses mit der Heizplatte kommt das Licht noch problemlos wie geplant durch das Loch in der Mitte:

Also nichts wie ins Büro damit! Der erste Praxistest war dann aber leider sehr ernüchternd :( es stellte sich raus, dass die ambiente Helligkeit da doch ein klein wenig höher ist wie in meiner dunklen Bude, mit dem Effekt, dass man die Farbe der Lampe selbst ohne direkte Sonneneinstrahlung kaum erkennen konnte. Daraufhin hab ich die Lampe dann erst mal aus akutem Frust ein paar Monate in die Ecke gepfeffert.

Irgendwann wollt ich es dann aber doch nochmal probieren, diesmal mit den richtig dicken Brocken unter den LEDs: 1- bzw. 3-Watt-Brummer sollten die Milliwatt-Funzeln ablösen. Da ich davon max. 3 unter das Loch bekommen würde, und zwei rote in Reihe grad passend an 5V betrieben werden konnten entschied ich mich dafür, die gelbe Variante auszulassen und Gelb stattdessen durch gleichzeitiges Aktivieren der einen blauen 3-Watt-LED und der zwei roten 1-Watt-LEDs zu bilden, wie das die Originalschaltung der Lampe auch getan hat.

Zur Stromversorgung kommt ein 7805 (in der Variante 78S05 für größere Stromstärken) zum Einsatz, der die 12V auf 5V runterregelt. Im Foto sieht man vor allem den Aufsteckkühlkörper, der das Ding auf Betriebstemperatur halten soll. Aufgebaut ist alles auf der guten alten Lochrasterplatine :) ja, ich war faul, insbesondere zu faul, mein Platinen-Ätz-Werkzeug rauszukramen.

Aber: es funktioniert! Und die Helligkeit ist "augenlichtraubend"!

Weil die neuen LEDs leider anders wie die kleinen einen sehr breiten Abstrahlwinkel von 120 Grad haben, musste ich mir allerdings noch was einfallen lassen, um möglichst alles Licht nach oben durch das Loch zu kanalisieren. Die Lösung ist pragmatisch simpel: ein Lichttunnel aus Pappe, innen ausgekleidet mit Alufolie. Der hat auch noch den angenehmen Nebeneffekt, dass er einiges an Wärmestrahlung von den LEDs, die ja selber genug Wärme produzieren, fernzuhalten scheint. Da hätte ich mal früher drauf kommen sollen ;-)

In dieser Variante war die Lampe dann auch hell genug für die typische Tageslichtsituation im Büro, wenngleich die kräftigen Farben nach wie vor erst bei Einbrechen der Dämmerung so richtig zur Geltung kommen.

Die Software

Auf Softwareseite begann ich mit einem von Simon K. veröffentlichten Opensource-Projekt, das einen sehr simplen Webserver auf dem Net-IO implementiert und seinerseits auf einer angepassten Version des uIP-Protokollstacks basiert. Dabei handelt es sich um einen speziell für den Einsatz in kleinen 8-Bit-Mikrocontrollern entwickelten, aufs Nötigste reduzierten TCP/UDP/IP-Stack. Ein solcher ist erforderlich, weil diese kleinen, simplen und billigen Controller dem Entwickler in Zeiten von Gigabyte-RAM-Riegeln, Terabyte-Festplatten und Gigahertz-CPUs geradezu absurd wirkende Limitationen aufzwingen: der auf der Net-IO standardmäßige Atmel-Controller AtMega32 z.B. besitzt 32 Kilobyte Flash-Speicher für Programm und statische Daten, 2 Kilobyte RAM, 1 Kilobyte EEPROM und läuft mit 16 MHz. Würde man einen gewöhnlichen TCP/IP-Stack darauf einsetzen, wäre der RAM schon mit einem Paket der gängigen Paketgröße von 1400 Byte fast zugekleistert - mal ganz davon abgesehen, dass der Stack-Code niemals in den Flash-Speicher passen würde. Der uIP-Stack umgeht diese Probleme z.B. dadurch, dass er erlaubt, unnötige Teile "auszuklammern", die dann gar nicht erst einkompiliert werden - ich benötige keine UDP-Unterstützung, also kompiliere ich sie gar nicht erst mit. Außerdem arbeitet er mit sehr viel kleineren Paketgrößen und ACK-Window-Sizes wie normale Stacks, um weniger kostbaren RAM als Puffer zu beanspruchen, hat gewisse Einschränkungen hinsichtlich der Fehlerkorrektur im TCP-Protokoll und bietet leider auch nicht die vom PC her gewohnte Abstraktion durch das Modell des Sockets. Das drückt alles gewaltig auf die erreichbare Übertragungsrate und macht die Softwareentwicklung auf Basis dieses Stacks nicht eben einfacher, aber hey, dafür kann man TCP/IP so in weniger als 12 Kilobyte Flash und 1 Kilobyte RAM quetschen :-)

Dass in besagtem Sourcecode nicht nur das nackte TCP/IP-Protokoll, sondern auch gleich noch ein rudimentärer Webserver mit GET- und POST-Request-Verarbeitung implementiert war, machte mir das Erreichen eines der eher ambitionierteren Ziele meines Projekts erheblich einfacher: meine XFD-Lampe sollte ein Webinterface haben, über welches sie konfiguriert und auch direkt gesteuert werden kann. Also bohrte ich den Webserver entsprechend auf, erstellte eine Konfigurationsseite (unnötigen Schnickschnack wie User-Authentifizierung habe ich im Interesse eines kompakten Ergebnisses weggelassen, so dass am Ende wirklich eine Seite für das ganze Interface genügte) und schrieb einen ganzen Batzen Code zur dynamischen Erzeugung dieser Seite bzw. zum Parsen von POST-Antworten, wenn der User über die Seite irgendwas ändern will. Dabei lernt man eine ganz andere Seite der Webentwicklung kennen: so Krempel wie Rails oder Java Servlets oder PHP hat man auf einem Mikrocontroller natürlich nicht zur Verfügung - da muss wirklich jedes Zeichen händisch in C-Code an seine Stelle in der fertigen Seite gesetzt und die Seite dabei parallel schon mal an den Empfänger rausgesendet werden (denn in die verbliebenen paar hundert Byte RAM auf dem Controller passt nicht einmal meine spartanische Konfigurationsseite in ihrer Gänze hinein!) - Antworten vom Webbrowser werden ebenso Zeichen für Zeichen durchgeackert.

Aber die ganze Mühe wurde belohnt: Nicht nur funktioniert das Webinterface einwandfrei mit allen Browsern auf meinem Rechner, nein, sogar mit dem iPhone kann die Lampe gleich out-of-the-box gesteuert werden :-)

Damit die Lampe ihren eigentlichen Zweck erfüllen konnte, brauchte sie jedoch noch eine letzte Komponente: einen HTTP-Client, der den Jenkins-Server nach dem RSS-Feed des gewünschten Projekts fragen und anschließend daraus den Status des letzten Builds extrahieren könnte. Auch für diese Aufgabe fand sich in einem der Beispielprojekte aus der uIP-Original-Release-Version praktischerweise eine Vorlage, die mit einigen Handgriffen für meine Zwecke angepasst werden konnte - na ja gut, ein paar mehr Handgriffe waren nötig, denn speziell das Parsen des RSS-Feeds, das auch wieder komplett Low-Level Zeichen für Zeichen vonstatten gehen muss, war schon eine gewisse Aufgabe. Aber schlussendlich war alles Nötige beisammen und der erste Funktionstest bestanden. Sicher befindet sich noch der ein oder andere Bug in der Software, aber wer Interesse haben sollte und nicht vor meinem hässlichen, irgendwie zusammengestöpselten und großteils mies kommentierten C-Code zurückschreckt kann sich das ganze Paket im Quellcode gern hier herunterladen.

Ich geh jetzt jedenfalls erst mal ein paar Builds schrotten, um die roten LEDs "lastzutesten" ;-)

Wenn dem Atomstrom das Licht ausgeht

Wer hätte das gedacht: 25 Jahre nach Tschernobyl blickt die Menschheit wieder mit Angst und Schrecken auf einen einzigen Punkt der Welt, auf eine Kiste aus Beton und Stahl, in deren Inneren Vorgänge ablaufen, über die jegliche Kontrolle verloren gegangen ist. Vorgänge, die in ihrer Macht das näheste Äquivalent zum göttlichen Akt der Schöpfung darstellen, das wir Menschen kennen - nur eben andersrum, statt Schöpfung steht gnadenlose Zerstörung auf dem Programm, wenn sich eine mehrere tausend Grad heiße nukleare Brühe Stück für Stück durch meterdicke Betonfundamente frißt, dabei aus sich selbst heraus immer heißer und heißer werdend, während sie zig Quadratkilometer Land um sich herum auf Jahrzehnte hinaus kontaminiert.

Ich geb zu, ein gewisser Teil von mir ist fasziniert von dem, was da in den drei außer Kontrolle geratenen Reaktoren in Japan gerade abläuft. Ja, ich weiß, das ist politisch sowas von inkorrekt, wie kann ich das nur wagen, immerhin sind geschätzte Zehntausende Menschen bei dem vorangegangenen Erdbeben samt Tsunami ums Leben gekommen, Betroffenheit zu zeigen ist doch das Mindeste. Aber ganz ehrlich...nach dem ersten Schock (und in diesem Fall einem kleinen zweiten, der kam, als mir klar wurde, dass Shanghai - die sehr coole und sehenswerte chinesische Metropole, in der eine meiner Schwestern erst letztes Jahr einige Monate Praktikumszeit und ich mit meiner Familie einen Urlaub verbracht haben - keine tausend Kilometer von Japan entfernt liegt) hält sich so richtige Betroffenheit bei mir nie lange, wenn es nicht um Dinge geht, die in meinem direkten Umfeld passieren und mir daher persönlich besonders nahe gehen. Und darin, weiterhin Betroffenheit zu heucheln, bin ich nicht besonders gut, zumal ich gerade so ein Verhalten für eine Verhöhnung der Opfer halte.

Also beobachte ich jetzt eben interessiert, wie sich die Lage dort unten entwickelt, und fast noch interessierter, was hier bei uns im Land seither geschieht. Denn man könnte meinen, dass einige Leute hier schlagartig eine ähnliche Ehrfurcht vor den Mächten der Atomphysik gepackt hat wie mich, nur dass dieselben Personen noch vor wenigen Monaten gemeint haben, diese Mächte derart sicher gezähmt zu haben, dass man sie ruhig noch ein Jahrzehnt länger zur Energiegewinnung nutzen könne - und dann vielleicht noch eines, und noch eines, und warum nicht noch eines? "Salamitaktik" nennt man diese im politischen Betrieb äußerst gängige Verhandlungsmethodik, deren Auftakt wir letztes Jahr mit dem Beschluss der Laufzeitverlängerung für die von den Energiekonzernen geliebten, weil längst abgeschriebenen Uralt-Meiler miterleben durften - nur dass die Salami in diesem Zusammenhang in jedem weiteren Zentimeter, den man abschneidet, eine tödliche Überraschung bergen könnte.

Und ich meine "tödlich" im Sinne von "uns ausrottend", nicht im Sinne von "einmal im Jahr fällt jemand mal beim Montieren von Solarpanels vom Dach" (kein Scherz, solche "Argumente" gegen regenerative Energien musste ich schon ernsthaft lesen). Wenn im an allen Ecken und Enden dicht besiedelten Deutschland ein glühender, radioaktiver Schleimball einen bedeutenden Teil des Landes unbewohnbar machen sollte, sterben nicht nur Zehntausende, sondern die Überlebenden können sich auch darauf gefasst machen, in der wirtschaftlichen Entwicklung ein paar Jahre bis Jahrzehnte in die Vergangenheit katapultiert zu werden. Angesichts solcher Aussichten ist es auch kein Wunder, dass sich beispielsweise meines Wissens kein einziger Versicherer der Welt darauf einlässt, vollumfänglich allein für die wirtschaftlichen Schäden eines möglichen Super-GAUs in Deutschland geradezustehen. Und nein, da hilft auch kein "aber die Wahrscheinlichkeit ist doch soooo gering"-Gelaber - Risiko ist nach gängiger Lehrmeinung Eintrittswahrscheinlichkeit multipliziert mit zu erwartendem Schaden, und wenn letztere Variable dem Unendlichen zustrebt, kann die erstere noch so klein sein, das resultierende Risiko ist einfach nicht tragbar.

Im Klartext: wer jetzt noch Atomkraft für eine saubere, billige und sichere Energiequelle hält, sollte dringend mal die Blase, in der er offensichtlich lebt, zum Platzen bringen und einen Abgleich mit der Realität durchführen. Wo man bei Tschernobyl noch hämisch auf die Steinzeit-Technik der Russen herabblicken konnte, muss man im Fall von Japan unumwunden eingestehen, dass all die tolle Hightech am Ende auch nicht der Weisheit letzter Schluss war. "Aber Erdbeben der Stärke 9.0 und Tsunamis gibt es in Deutschland nicht" hab ich in letzter Zeit häufig als Erwiderung gelesen und gehört - ja, stimmt, sowas ist hier wirklich äußerst unwahrscheinlich, nur gibt es solch starke Erdbeben selbst in Japan fast nie, statistisch alle irgendwastausend Jahre einmal, was auch der Grund dafür war, dass die Kraftwerke nur bis zu einer deutlich niedrigeren Bebenstärke und Tsunami-Höhe abgesichert sein mussten. Nicht vorhandene Parallelen zwischen dem japanischen Ausnahmefall und dem deutschen Alltagsfall als Beleg für eine Unvergleichbarkeit beider Situationen heranzuziehen ist echt eine lausige Argumentationsweise, insbesondere wenn es um einen Super-GAU geht, der per Definition schon eine Situation beschreibt, die außerhalb dessen liegt, was man sich üblicherweise an Störfällen so vorstellen kann und welche ein Atomkraftwerk daher aushalten muss. Diese Dinger haben es nun mal an sich, dass man sich vorher nicht ausmalen kann, wie es dazu wohl jemals kommen könnte, und nachher dasteht und sich fragt, wieso man das nicht vorhergesehen hat.

Dazu kommt die Mär vom "billigen" Atomstrom, bei deren rechnerischem Beleg konsequent die unkalkulierbaren (wie praktisch :-) ) aber mit Sicherheit gewaltigen (...schade aber auch :-( ) Folgekosten der Stromerzeugung mittels Kernspaltung unter den Teppich gekehrt werden. Die ungeklärte Endlagersituation fällt einem da ja im Allgemeinen als Erstes ein, etwas weniger bekannt ist ein anderer Aspekt, über den z.B. Technology Review in einem auf heise online verlinkten Artikel einmal berichtet hat: der sogenannte Rückbau, also der umweltverträgliche Abriss der alten Kernkraftwerke. Weil die Dinger wie verrückt strahlen, muss ein gewaltiger Aufwand getrieben werden, dessen preisliche und zeitliche Dimensionen die des Aufbaus derselben Anlage um ein Vielfaches übersteigen - von 18 Jahren und 3 Milliarden Euro ist in besagtem verlinkten Artikels die Rede, und das für ein eher kleines Kraftwerk aus DDR-Zeiten. Ich wiederhole: 3 Milliarden! 18 Jahre! EIN EINZIGES Kraftwerk! Und wir haben noch 17 weitere davon in der Gegend rumstehen! Kein Wunder, dass sich deren Besitzer mit Händen und Füßen dagegen wehren, die Dinger endgültig abzuschalten - nicht nur bringen sie dann kein Geld mehr in die Kasse, nein, zusätzlich müsste man dann auch noch von seinem bequemen Sessel aufstehen und den Dreck unter Einsatz irrwitziger Geldsummen beseitigen, der sich jahrzehntelang angesammelt hat. Das hat irgendwie was von "Ja Mama, morgen bring ich den Müll ganz bestimmt raus" - mit dem kleinen Unterschied, dass die Atomindustrie bis heute nicht weiß, wo eigentlich die Mülltonne steht.

Nun gut, in gewisser Weise mache ich es mir auch leicht - sich über etwas zu beschweren ist eines, eine Alternative anzubieten eine ganz andere Sache. Fakt ist mal, dass ich auch nicht die perfekte Alternative zur Hand habe. Klar gehören regenerative Energien weiter ausgebaut, ich bin auch ein großer Fan der Idee, brachliegende Gegenden wie Wüsten mit Solarkollektoren zuzukleistern, so lange man das örtlich und in Kombination mit anderen Energiequellen diversifiziert genug betreibt, um keinen "Single Point of Failure" zu schaffen. Die "eine, fette Energiequelle" wird es in absehbarer Zukunft - zumindest bis zur Erfindung der wirtschaftlich nutzbaren Kernfusion - wohl nicht mehr geben, der Trend geht erst einmal in Richtung Dezentralisierung mit vielen kleineren Energiequellen an unterschiedlichsten Orten, wobei das auch nicht unbedingt alles regenerative Quellen sein müssen. Eine gute, in meinen Augen aber viel zu wenig beachtete Alternative zu den großen Kohlekraftwerken stellen z.B. Gasturbinen dar, die neben erheblich weniger CO2-Ausstoß große Vorteile bezüglich schneller Anfahrzeiten und guter Effizienz auch bei kleineren Baugrößen haben, was sie geradezu prädestiniert, um in einem stark dezentralisierten Energieversorgungsnetz als Ausgleich für die schwankenden Erträge vieler regenerativer Energiequellen zu dienen. Erdgas ist außerdem auch noch im Vergleich zu beispielsweise Öl relativ reichhaltig vorhanden, nicht zuletzt durch neue Fördertechniken wie Hydraulic Fracturing (ich weiß, das hat seine ganz eigenen Probleme, allerdings sind die potenziell in den Griff zu bekommen - wichtig ist erst mal, dass der Rohstoff überhaupt "da" ist). Und der verbleibenden CO2-Problematik ist letzlich auch mit technischen Mitteln allemal besser zu begegnen als einer Verstrahlung von Mensch, Tier und Land, gegen die man ganz genau gar nichts ausrichten kann.

Aber sehen wir mal, was die nächsten Wochen so bringen, sowohl in Sachen Japan als auch in der heimischen Politik. Die Landtagswahlen in Baden-Württemberg sind gerade jedenfalls nochmal deutlich spannender geworden, nachdem schwarz-gelb jetzt nach der Stuttgart-21-Geschichte und dem Guttenberg-Fiasko mit den Atom-Mappus das Triumvirat der unpopulären Positionen komplettiert hat. Wie sehr denen gerade der Arsch auf Grundeis geht sieht man an den ungewöhnlichen weil erstaunlich schnellen Zugeständnissen, mit denen selbst die Opposition nach der Erfahrung in der Guttenberg-Salamitaktik-Posse jetzt etwas überrumpelt zu sein scheint (wobei...wenn man mal genau auseinandernimmt, wie da "zugestanden" wird, scheint das wohl auch eher hektischer Aktionismus denn reale Einsicht zu sein - also alles wie immer). Aber so ist das eben, wenn man aufs falsche Pferd gesetzt und gehofft hat, es passiert bis zur Ziellinie nix.

Dass Japan das schlimme Schicksal ereilt, als "Tschernobyl der Moderne" in die Geschichte einzugehen, konnte in der Tat niemand wissen.

Update: Ah, gut zu wissen dass ich nicht der Einzige mit dieser Meinung bin.

HERRGOTTSAKRAMENTNOCHAMAL!!!!

Liebes Bundeskanzleramt,

DAS VERDAMMTE INTERNET IST SCHON LANGE KEIN RECHTSFREIER RAUM MEHR!

Meine ersten Erfahrungen mit Anwälten durfte ich aufgrund einer Abmahnung machen, die ich als Web-Dienste-Betreiber erhielt. Das Gewerbe- und Steuerrecht hat mich - wie die meisten Bundesbürger - nie besonders interessiert, bis ich selber ein Gewerbe anmelden musste, um Einnahmen aus dem Betrieb von Web-Diensten korrekt zu versteuern. Kontakt mit der Polizei hatte ich auch nur äußerst selten und mit dem Verfassungsschutz noch nie - bis...ihr ahnt es vermutlich.

ALSO HALTET ENDLICH EURE BESCHEUERTEN FRESSEN und faselt nicht gebetsmühlenartig immer und immer wieder von diesem angeblichen "rechtsfreien Raum". JEDER, aber wirklich JEDER, der irgendwie schöpferisch im Netz tätig wurde oder wird, kann bestätigen, dass es kaum einen weniger mit (häufig auch noch weitgehend sinnbefreiten) Regelungen überzogenen "Raum" wie den deutschen Cyberspace gibt!

Sorry, aber das musste mal raus jetzt.

WiX unter Linux

Wenn man Windows-Software hat, die man in ein schönes Setup-Paket verpacken möchte, dann hat man heutzutage unterschiedliche Möglichkeiten. Die Auswahl kann man vorrangig anhand seines Geldbeutels und dem Willen, sich in neue Dinge einzuarbeiten, treffen. Auf der einen Seite gibt es das (annähernd marktbeherrschende) InstallShield, mit welchem man mit wenig Klicks zu einem Setup-Paket kommt und trotzdem noch "advanced" Dinge umsetzen kann - beliebige Erweiterungen des Setup-Prozesses, Web-basierte Setups, solche Dinge. Den Komfort bezahlt man natürlich auch durch saftige Preise. Möchte man das umgehen, stehen noch Open-Source-Alternativen wie Inno Setup im Raum, die in einem gewissen Maß mehr Einarbeitung erfordern und manche Dinge nicht unterstützen, aber stabil und weit verbreitet sind - und kostenlos :)

WiX - ein von Microsoft-Mitarbeitern gepflegtes Open-Source-Toolset - ist eine solche schöne Alternative zu InstallShield. Gegenüber dem bereits erwähnten Inno Setup hat es den Vorteil, dass es auf Windows Installer aufsetzt, also .msi-Dateien erzeugt, die ohne weitere Executable unter allen aktuellen Windows-Versionen installiert werden können - quasi das "Windows-Paketmanagement". Einer der Nachteile aber ist meiner Erfahrung nach, dass es erheblich schwerer ist, WiX-basierte Setup-Pakete unter Linux-Systemen zu bauen.

Aber: es geht! Wichtig ist:

Da WiX auf .NET basiert, ist natürlich Mono zur Ausführung erforderlich - allerdings nicht, wie man erst meinen könnte, Mono für Linux, sondern Mono für Windows, ausgeführt in Wine. Wine kapselt also Mono für Windows, welches wiederum die auszuführende WiX-Tool-Executable kapselt. Dieser Bohei ist notwendig, weil einige der WiX-Tools native MSI-APIs nutzen, die Mono logischerweise nicht mitbringt, Wine aber schon.

Je nach verwendeter Wine-Version kann es vorkommen, dass der WiX-Linker "light" mit einer Fehlermeldung von einer ihm unbekannten Windows-Codepage 1252 abbricht. Der Grund hierfür ist Bug #25182, ein erst in Wine-Version >= 1.3.8 gefixter Fehler in einer der MSI-Funktionen. Speziell die in vielen Linux-Distributionen über das Paketmanagement verfügbaren Versionen sind ja meist etwas älter, weshalb ich z.B. die aktuellste Head-Version von Wine ziehen und kompilieren musste.

Wenn man diese Dinge beachtet hat, kann man die WiX-Tools anschließend mit einer Kommandozeile nach dem Muster

wine mono candle.exe (...)

starten, und der Tag ist gerettet :o)

Kill Switch

Lange habe ich gerätselt, ob die Leute, die sowohl in Amerika als auch Deutschland schon "Not-Aus-Knöpfe" für das Internet gefordert haben, einfach nur dumm wie Brot sind oder so verblendet, dass sie wirklich glauben, das sei für irgendwas nützlich.

Seit gestern wissen wir, wofür Internet-Kill-Switches tatsächlich eingesetzt werden. So viel zum Thema, das sei eine gute Idee, einer Regierung zu erlauben, sowas zu installieren. Und jetzt kommt mir mal keiner damit, wir wärn ja eine Demokratie undsoweiter, da würde schon nix derartiges passieren - in 95% der lupenreinen Demokraten, die da im Bundestag sitzen, schlummert doch auch ein kleiner Diktator, der nur zu gern etwas mehr an die frische Luft käme. Demokratien zeichnen sich im Gegenteil dadurch aus, dass sie erst gar keine in Diktaturen erprobten Volks-Repressionsmittel brauchen!

Der neue Sozialismus

"Sozial", was für ein durch und durch positiv belegter Begriff..."sozial sein", das heißt, sich für seine Mitmenschen einzusetzen, dem Egoismus zu entsagen und überhaupt ganz selbstlos gute Dinge für andere zu tun. Selbst den Amerikanern, die ja "socialism" nach wie vor primär als Schimpfwort verstehen, ist noch nicht so recht aufgegangen, dass "social" den Wortstamm besagten Schimpfworts darstellt, und so findet man auch über dem großen Teich "social stuff" meist recht gut, insbesondere wenn er im Internet stattfindet, am Besten natürlich in "social networks". Das dachte sich wohl auch Blizzard, als man dort die Pläne für RealID, die Grundlage des auf Deutsch sogenannten "Freundschaftssystems" schmiedete. Warum nicht auf Basis der zweifelsohne existenten, großen Spielercommunity um Blizzard-Spiele eins dieser heißbegehrten Social Networks schneidern, die immer größere Teile des Internet und vor allem der Online-Zeit seiner Bewohner verschlingen?

Schnapsidee. Punkt!

Warum es gut ist, ein bisschen schizophren zu sein...

Praktisch jeder, der das Internet schon etwas länger nutzt, vielleicht dessen erste Boom-Phase Ende der Neunziger aktiv erlebt hat, besitzt ein "zweites Ich", eine Online-Identität unter einem (oder einer Reihe von sich oftmals ähnelnden) Pseudonymen. Unter dieser Identität, diesem "Nickname" ist man in Foren aktiv, kommentiert Blogpostings, chattet im IRC und tut alles sonst, was man so an "sozialen" Dingen im Netz tut - und schon lange tun konnte, bevor die Social Networks all das als ihr Territorium betrachteten und begannen, die durch den frei wählbaren Nickname recht sauber von der normalen, bürgerlichen Identität eines Menschen abgetrennte Online-Identität mehr und mehr aufzulösen, einfach indem statt des Nickname der "echte", bürgerliche Name, der "Realname", als zentrales Identifikationsmerkmal herhalten durfte.

Das bringt unzweifelhaft ein paar Vorteile mit sich. Den echten Namen wechselt man nicht so leicht wie einen Nickname, notorischen Störern wird also eine höhere psychische Hürde bei der Ausübung ihrer Störereien in den Weg gelegt. Auch findet man aus dem normalen Leben bekannte Personen leichter im virtuellen Raum, wenn diese hier wie dort auf denselben Namen hören. Und man muss sich keine Nicknames mehr einfallen lassen, unter denen nicht schon zigtausend andere Menschen unterwegs sind.

Damit hat sich's dann aber auch schon erledigt mit den Vorteilen - zumindest auf User-Seite. Die Nachteile sind deutlich umfangreicher, zeigen sich aber tückischerweise erst längerfristig, weshalb sie - anders als die Vorteile - nicht jedem sofort ins Gesicht springen.

Eine hervorstechende, positive Eigenschaft des Internet, oft betont gerade in den Neunzigern, als die breite Masse sich zaghaft an das neue Medium heranwagte, war, dass online jeder Mensch zunächst ein völlig unbeschriebenes Blatt war. Hautfarbe, Religion, Nation - sowas gab es online nicht, weil man nichts hatte, woran man sein Gegenüber in eine der im Real-Life sonst so gern genutzten Schubladen stecken konnte. Was heutzutage trotz gebetsmühlenartiger gegenteiliger Beteuerungen seitens der Personaler am laufenden Band passiert, dass Bewerber mit ausländisch klingenden Namen klar benachteiligt werden, das gab es online nicht. Wie denn auch, wo sich jeder jeden Namen geben konnte? Online war jeder Mensch zunächst einfach nur ein Mensch.

Diese alternative, zweite Identität ist gleichbedeutend mit einer enormen Steigerung der Selbstbestimmungsmöglichkeiten. Ein Online-User mit konsequent vom Reallife getrenntem "Online-Leben" hat sehr viel mehr Macht über die Wahrnehmung seiner eigenen Person durch Andere, wie jemand, der diese Trennung nicht konsequent vollzog und aufrechterhält. Derartige Macht kann und wird natürlich mißbraucht, etwa bei der Vorspiegelung völlig falscher Tatsachen, um einen anderen Menschen dazu zu ermuntern, etwas für ihn schädliches zu tun. Aber genauso wird die Freiheit, nachts ohne verhaftet zu werden auf die Straße gehen zu können von Einzelpersonen mißbraucht, um im Schutz der Dunkelheit Einbrüche zu begehen. Niemand würde auf die Idee kommen, man müsse deswegen sofort Ausgangssperren verhängen. Warum sollte also ein enormer Freiheitsgewinn, ein Gewinn an Möglichkeiten, sein Leben online wie offline selbstbestimmt zu leben, im Internet wegen ein paar nervigen Trollen in irgendwelchen Foren und ein paar Trickbetrügern geopfert werden?

Mit denen wurde und wird man seit jeher anders fertig, mit Reputation-Systemen in Foren z.B. oder Bewertungssystemen für User-Generated Content. Für die ganz harten Betrugsfälle gibt es außerdem zig Möglichkeiten der Rückverfolgung, jedenfalls dann, wenn die Betrüger nicht versiert genug für den Umgang mit echter, wirksamer Anonymisierungstechnologie sind - und die beachtlichen Aufklärungsquoten von online begangenen Verbrechen mit nennenswertem Umfang zeigen recht anschaulich die Effektivität dieser Möglichkeiten. Keiner braucht hier wirklich echte Namen, zumindest nicht, so lange es nicht um das Reallife direkt betreffende Transaktionen geht (das Online-Banking z.B.), für welche die Kenntnis der "echten" Identität eine Grundvoraussetzung ist.

...und wer von echten Namen wirklich profitiert!

Aber um derartiges geht es in aller Regel auch gar nicht, wenn mal wieder ein Betreiber irgendeines Webdienstes meint, einen auf Social Network machen zu müssen. Denn Betreiber solcher Dienste haben noch ganz andere, direkt in monetäre Wertsteigerung ihrer Angebote umsetzbare Vorteile davon, wenn sie die Realnames ihrer Nutzer kennen, optimalerweise gleich mit Adresse, sexueller Neigung, politischer Orientierung und Monatseinkommen. Derartige Informationen erhöhen den Wert der Nutzerdatensätze massiv, und mit ihnen auch den Wert aller Daten, die man mit diesen Nutzerdatensätzen zusammenführen kann (z.B. der Information, wer sich für Diskussionen zu einem bestimmten Thema interessiert). Wenn für Social Networks Milliardensummen bezahlt werden, dann geschieht dies in erster Linie, weil der Wert der Nutzerdaten und -community auf diese Unsummen geschätzt wird, nicht weil die dahinterstehende Software so toll wäre (Facebook in seinen Anfängen konnte man als geübter Entwickler praktisch als Urlaubsprojekt ohne großartige Einbußen in der Funktionalität nachbauen; der technische Anspruch war geradezu lächerlich).

Nach Google nun Blizzard?

Verständlich also, dass sich keiner "sein" Stück von diesem Kuchen nehmen lassen möchte und jeder bestrebt ist, seine Dienste enger mit der realen Identität der Nutzer zu verweben. Dass sowas aber auch ganz gewaltig nach hinten losgehen kann, musste Google beispielsweise vor nicht allzu langer Zeit am eigenen Leib erfahren, als der zweite Vorstoß des Web-Giganten in Richtung Social Network medienwirksam gegen die Wand donnerte.

Es geht natürlich um Buzz, Googles auf GMail aufsetzendes "Social Network". Und damit ist im Kern auch schon gesagt, warum das Ding an die Wand donnerte: auf das Medium e-Mail - ein gleichermaßen für höchst vertrauliche wie banale Kommunikation eingesetztes Medium - ein soziales Netzwerk mit der für diese Netze typischen Sorglosigkeit im Umgang mit Informationen zur Verknüpfung von Personen untereinander aufzusetzen ist Irrsinn, der besonders deutlich wird, wenn man mal einen genaueren Blick auf die Bedeutung eines "Freundes" in einem beliebigen Social Network und die Bedeutung eines Mailkontaktes wirft. In einem Social Network ist ein "Freund" jemand, den ich freiwillig in diesen Status erhebe. Ich muss das nicht tun, ich habe erst mal keinerlei Nachteile, wenn ich das bei einem bestimmten Menschen nicht tue, ich habe weitgehend freie Wahl.

Bei e-Mail gestaltet sich das etwas anders. Die Gründe, warum ich mit jemandem per Mail kommuniziere, können höchst unterschiedlich sein, und haben oftmals nichts damit zu tun, dass ich die Person in irgendeiner Weise "mögen" würde - man denke nur einmal an rein geschäftlichen Mailverkehr. Aus Mailkontakten also auf "Freundschaften" zu schließen, wie es eben Google mit Buzz automatisiert versuchte, ist daher praktisch von vorneherein zum Scheitern verurteilt. E-Mail ist einfach von Grund auf ein anderes Medium wie Social Networks; sie wird für andere Zwecke eingesetzt und taugt nicht als Grundlage für ein solches Netzwerk.

So, und nun zu Blizzard: die bekannte Spieleschmiede verkündete kürzlich, dass sie in ihren Foren zukünftig nur noch echte Vor- und Nachnamen als Absender verwenden wollen statt der bisherigen Pseudonyme. Ohne Zweifel geht dieses Vorhaben Hand in Hand mit den zuvor schon erwähnten RealID-Bemühungen und dient dem längerfristigen Ziel, aus der Blizzard-Community eine Art Social Network zu formen, in welchem der Umgang mit Realnamen gang und gäbe sein soll. Nur: es stellt sich ein ähnliches Grundproblem wie bei Buzz, die Ausgangsbasis passt einfach nicht wirklich auf die Gegebenheiten in Social Networks.

Die Tatsache, dass ich in irgendwelchen (öffentlich einsehbaren!) Foren über ein Spiel diskutiere, dessen Community ich angehöre, hat mit meinem Reallife erst einmal nichts zu tun. Es geht um das Spiel, in dem ich (wie im Fall von World of Warcraft z.B.) eventuell sogar explizit einen Charakter in einer Fantasiewelt, ein Alter Ego also, spiele. Da braucht es keine Querverbindungen zu meinem sonstigen Leben, denn für die wenigen Mitspieler, denen ich diese Querverbindung ermöglichen möchte - Gildenmitglieder, die ich persönlich kenne z.B. - kann ich dies ermöglichen, ohne dass Blizzard erst mal eine generelle und erzwungene Entpseudonymisierung implementieren muss, die praktisch jedermann erlaubt, besagte Querverbindungen herzustellen. Welche Probleme man sich mit sowas einhandeln kann musste ein Community Manager von Blizzard am eigenen Leib spüren, nachdem er - noch vor Einführung des besagten Realname-Systems in den Foren - seinen realen, bürgerlichen Namen freiwillig gepostet hat, um die Nutzer von der Harmlosigkeit dieser Aktion zu überzeugen: der Schuss ging gewaltig nach hinten los, denn kurze Zeit später kannte man eine Fülle von privaten Informationen über ihn, inklusive seiner Telefonnummer, alles zusammengetragen durch geschickte Nutzung von Google, Social Networks und weiterer, allgemein verfügbarer Datenquellen. Schade für den gebeutelten Mitarbeiter, aber ein hervorragendes und lebendiges Beispiel, welche Problematik in Blizzards Vorhaben liegt. Ich sage: danke dafür, und "selbst schuld", armer Mitarbeiter!

Klar, noch kann ich durch Nicht-Nutzung der offiziellen Blizzard-Foren der Realname-Veröffentlichung entgehen. Aber es reicht aus, den eingeschlagenen Weg nur minimal in die Zukunft zu extrapolieren, um sich vorstellen zu können, dass der Realname in Zukunft beispielsweise auch in Armory-Profilen der eigenen Charaktere oder ohne die Bedingung, auf einer Freundesliste zu stehen, direkt ingame sichtbar sein könnte. "Salamitaktik" nennt man ein derartiges Vorgehen auch, bei welchem dem Gegenüber in kleinen Schritten immer weitere Zugeständnisse abgerungen werden, bis er letztlich alles tut, was man ursprünglich wollte, aber glaubt, nur wenig Zugeständnisse gemacht zu haben.

Wie viele "Einzelfälle" wie den des besagten Blizzard-Mitarbeiters muss es noch geben, bis die breite Masse den Wert von Pseudonymisierung und Anonymität wieder erkennt und die Betreiber effektiv gezwungen sind, derartige Wünsche zu respektieren? Ich weiß es nicht, aber ich tippe auf "ziemlich viele" :-(

BREAKING NEWS: Geplantes Developer Agreement für iPhone OS 5 geleakt!

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). Applications must be originally written by developers which have to be dressed in a black turtleneck sweater and which are sitting at a desk with a minimum size of 30 by 58 by 22 inches when writing code (e.g. writing code that links to Documented APIs when being naked is prohibited, writing code that links to Documented APIs on the toilet is prohibited, writing code that links to Documented APIs when sitting naked on the toilet is strictly prohibited). The single approved source of liquid for developers while writing code that links to Documented APIs is grape juice from California's Navarro vineyards, because that is Steve Jobs' favorite (*** NOTE: REMOVE REFERENCE TO SOURCE OF RULE BEFORE PUBLISHING IN IPHONE DEV CENTER ***).

Okay, natürlich ist das da oben ein Fake. Entstanden in Verbitterung darüber, dass sich Apple nun offenbar anmaßt, die Ausgangssprache für iPhone-Apps festzulegen. Warum stinkt mir das? Weil es technisch völlig ohne Belang ist! Die Quellsprache, in der man als Entwickler arbeitet, ist für die Lauffähigkeit des Resultats auf einer Plattform genauso irrelevant wie es irrelevant ist, ob man den Code zwischen 9 und 17 Uhr im Büro oder mit der Pizza in der Hand spät nachts im Bett liegend schreibt. Wenn es läuft und die Qualitätsstandards von Apple erfüllt (die angesichts des 90%-absoluten-Schrott-Anteils im App Store ja auch nicht besonders hoch zu liegen scheinen) kommt es in den Store, und wenn es seinen Preis für die Käufer wert ist wird es gekauft. Dem Endkunden ist es vollkommen wurst, auf welchem Weg die Anwendung erstellt wurde, so lange ihre Qualität stimmt, und mit dieser Endkunden-zentrierten Sicht sollte auch Apple an die Sache rangehen.

Aber der Endkunde steht bei Apple ja schon lang nicht mehr im Fokus - viel wichtiger ist, das Business-Modell des App Store und die damit verbundene Gelddruckmaschine zu protegieren und die Lock-In-Effekte in die iPhone-OS-Plattform sowohl für Entwickler als auch Endkunden zu maximieren. Ein augenöffnender Artikel von John Gruber (den man mit etwas Vorsicht genießen muss, weil er bekennender Apple-Enthusiast ist und daher...nun ja...zumindest in meinen Augen etwas voreingenommen pro Apple schreibt) erklärt recht gut die Business-Seite hinter dieser Aktion und warum sie aus Apples Sicht Sinn macht. Das zweifel ich auch gar nicht an - ich zweifel nur stark seine Schlussfolgerung an, dass es letztlich auch für den Endkunden eine vorteilhafte Entscheidung sei.

Denn für den zählt nur: gibt es eine App, die mir bei dem, was ich machen will, hilft, und ist sie qualitativ gut genug, dass sie ihren Preis wert ist? Ob die App in Objective C geschrieben ist oder mittels eines Cross-Compilers erzeugt wurde ist bei gleicher Qualität des Endergebnisses irrelevant, und wenn die Cross-Compiler das Erstellen einer qualitativ ebenbürtigen App verunmöglichen sollten regelt entweder die Apple-Qualitätskontrolle oder schließlich der Markt die Situation, sprich die App wird nicht gekauft. Das ist aber eine Frage, die in jedem Einzelfall zu klären ist und die sich nicht mittels "Generalerlass" contra alternativer bzw. Cross-Compiler erschlagen lässt.

Nachtrag

Stevieboy himself hat scheinbar auch den Gruber-Artikel gelesen und bestätigt damit die geschäftlichen Überlegungen. Viel interessanter ist aber die Gegenargumentation von Greg Slepak, nämlich dass es durchaus Fälle hochqualitativer Cross-Platform-Applikationen auf der Mac-Plattform gab (die iPhone-Plattform selbst kann noch nicht für Beispiele herhalten, weil die Cross-Platform-Entwicklung dort noch in den Kinderschuhen steckt und da nun wohl auch nie rauskommen wird) und es somit auf eine Einzelbetrachtung ankommt.

Das Geheimnis von Googles Erfolg - und Niedergang?

Wenn es etwas gibt, wovon Google erwiesenermaßen wirklich gar keine Ahnung hat, dann sind das Social Networks. War bislang das trotz seines schon recht frühen Starts international am Rande der Irrelevanz herumkrebsende Orkut die einzige Peinlichkeit, die sich der Gigant aus Mountain View in diesem Bereich geleistet hat, legte das Unternehmen vergangene Woche mit "Buzz" nach - und lieferte einen weiteren Fehlschlag ab, der diesmal dafür so richtig in die Hose ging.

Ein Spiegel-Online-Artikel fasst die Reaktionen aus der Netzgemeinde und Googles fast panisch anmutendes Gefrickel an ihrer neuen Schöpfung ganz gut zusammen, so dass ich mir das jetzt spare und mich lieber gleich der Frage widme: warum kriegt Google diesen Social-Kram partout nicht auf die Kette? Es zeichnet sich ja schon so ein gewisses Muster ab: für alles, was "nur" das Herumschieben gigantischer Datenmassen erfordert, hat Google ein gut am Markt platziertes Tool am Start (Suche? Google Search! Web-Traffic-Analyse? Google Analytics! E-Mail? Google Mail! Web-Videos? YouTube! Karten? Google Maps! undsoweiterundsoweiter), aber bei diesem neumodischen sozialen Kram muss sich Google ständig von anderen Unternehmen die Show stehlen lassen. Schon das bereits erwähnte Orkut kennt außerhalb Brasiliens kein Schwein, auch kenne ich niemanden, der ein "Google Profile" pflegen würde - dafür aber eine Unzahl von Leuten, die entweder bei Facebook, MySpace oder einem der deutschen Copycats StudiVZ, Wer-kennt-Wen, Lokalisten, ... oder gleich bei allen Genannten gleichzeitig irgendwelche Profile und Freundeslisten pflegen.

Praise the Holy Algorithm...

Google huldigt seit jeher, seit den Anfängen als reiner Search-Provider bis heute, dem heiligen Algorithmus und seiner unermesslichen, zeitfressende manuelle Arbeit wegrationalisierenden Macht. Zur Anfangszeit des World Wide Web, also lange vor Google, waren Webverzeichnisse die erstbeste Anlaufstelle zur Orientierung im damals noch nicht sooo großen, aber doch schon über das Aufnahmevermögen eines einzelnen Menschen hinausgehenden Informationskosmos. Aus diesen Verzeichnissen gingen mehr oder weniger die ersten Giganten wie Yahoo! hervor, aber sie hatten einen gewaltigen Nachteil: waren die paar Hansel, die diese Verzeichnisse pflegten, anfänglich noch ausreichend, um das spärliche Angebot angemessen zu durchforsten und zu katalogisieren, stieg der Bedarf an Manpower bald ins Unermessliche, ohne dass dem - trotz der im Zuge der .com-Blase ins Irrwitzige gehypedten Unternehmenswerte - ausreichend finanzielle und personelle Ressourcen gegenüberstanden. Als Resultat davon sank die Relevanz händisch erstellter Web-Verzeichnisse rapide und ein neuer Markt, nämlich der für Volltext-Web-Suchmaschinen, tat sich auf, auf dem sich zunächst neue Player sowie alteingesessene Portale, die sich nicht nur auf ihre Verzeichnisse verlassen wollten, breit machten. Schnell stellte sich jedoch heraus: mit dem einfachen Adaptieren bestehender Suchindex-Technologien auf das Web und damit einhergehend dem Auswerfen von Seiten, die ein gesuchtes Wort enthalten, war kein Blumentopf zu gewinnen - uuuuund Auftritt: Google und der revolutionäre PageRank-Algorithmus!

Wo andere auf manuelle Arbeit vertrauten, steckte Google lieber seine Energie in die Entwicklung eines wie die Faust aufs Auge passenden Algorithmus und dessen effiziente Implementierung, die dann dank immer billiger werdender Rechenleistung sehr viel besser mit den wachsenden Informationsbergen skalieren konnte wie jedweder manueller Ansatz. Das war Googles initialer Wettbewerbsvorteil und erlaubte es dem Unternehmen, mit geringem Startkapital und gerade mal einem einzigen Rack mit Servern das damals zugegebenermaßen noch winzige World Wide Web fast so effizient wie über Linkverzeichnisse durchsuchbar zu machen und mit dem wachsenden Web bezahlbar zu skalieren. Damals wurde Google zur Kirche des heiligen Algorithmus, und wenn sich über all die Jahre ein Pattern wirklich gehalten hat dann ist es jenes, dass Google immer und zuallererst versucht, Probleme durch das Fassen in Formeln und Automatisierung zu lösen - dabei fielen viele großartige Dinge wie riesige Mailkonten plus komfortabler Suche darüber, ein Mapping-Dienst mit erstaunlichem Interpretationsvermögen für Sucheingaben und ähnliche Meisterleistungen ab, aber auch manch netter, wenn auch logisch erklärbarer Fauxpas wie zum Beispiel die lustigen Google-Suggest-Ergebnisse (und die da sind nur die Spitze des Eisbergs, gewissermaßen eine für die prüden Amis verträgliche Auswahl, da gab es noch welche von ganz anderem Kaliber). Und eben auch Totalausfälle wie Googles Versuche mit dem "social stuff".

Manche Dinge lassen sich einfach nicht zufriedenstellend durch das Anwenden von Algorithmen lösen. Und auch wenn es gang und gäbe ist, dass Algorithmen uns an unzähligen Stellen Arbeit abnehmen: Manchmal möchte man als Mensch einfach nicht durch einen besserwisserischen Algorithmus "bevormundet" werden. Zum Beispiel bei der Auswahl seiner Freunde - und das gilt selbst wenn es nur um "virtuelle Freunde" geht, also das, was der durchschnittliche Social-Network-Nutzer (zugegebenermaßen in einer etwas böswilligen Betrachtung ;-)) als Schwanzverlängerung zu begreifen scheint und wovon er daher versucht, absurde drei- bis vierstellige Mengen zu sammeln. Ein Algorithmus, der eine solche Liste mit den Leuten "befüllt", mit denen man mehrmals Mails ausgetauscht hat, scheint erst einmal diesem Wunsch voll und ganz zu entsprechen - das Problem dabei ist nur: während viele Menschen kein Problem damit zu haben scheinen, "irgendwen" den sie kaum kennen auf ihrer Friendlist stehen zu haben (lässt ja den Freundeszähler um eins ansteigen!), kennt jeder ganz bestimmte Personen, die er da um keinen Preis stehen haben möchte. Und das sind nicht unbedingt Leute, zu denen man keinen Mail-Kontakt hat - ganz im Gegenteil: Mails von der oder dem Ex hat man möglicherweise tonnenweise auf seinem Account rumliegen, fein säuberlich archiviert in einem Ordner, und man will die vielleicht auch nicht unbedingt löschen. Das heißt jedoch nicht, dass der Ex via Buzz künftig über alle eigenen Aktivitäten informiert werden soll, bis hin zum aktuellen Aufenthaltsort. Dasselbe gilt für den Chef oder im Falle von Freelancern dem aktuellen Auftraggeber - da ist intensiver Mailkontakt durchaus normal, gleichzeitig will man diesen Personen aber nicht gleich alle weiteren privaten wie beruflichen Kontakte offenlegen, weil es sich bei diesen Kontakten eben nur selten um echte "Freunde" handelt, denen man alles erzählen kann (und will!). Es gibt keinen Algorithmus, der derartige zutiefst menschliche Dinge ausreichend gut berücksichtigen könnte, dass man ihn ohne zwingend erforderliche Bestätigung durch die betreffende Person auf eine öffentlich einsehbare Kontaktliste loslassen könnte; und wenn es ihn doch gibt, dann hat selbst Google kein Datenmaterial in auch nur annähernd ausreichendem Umfang zur Verfügung, auf dessen Basis er operieren könnte. Google glaubte indes, sie könnten auch das Finden von Freunden automatisieren - und fiel damit verdientermaßen auf die Schnauze. Für derartige Arroganz gehört der Konzern in der Tat mal bestraft.

...und woran Google wirklich scheitern könnte

So richtig interessant wird das alles aber erst, wenn man sich vor Augen hält, was Google überhaupt dazu motiviert hat, einen Dienst wie Buzz zu veröffentlichen: die kalte Angst vor einem Web, in dem Google nicht mehr die Funktion des mächtigsten Traffic-Verteilers innehält, und in der Google sein praktisch einziges profitbringendes Standbein, die Online-Werbung, schneller wegbrechen könnte als die Firma eine ähnlich lukrative Geldquelle auftreiben kann.

Vor 6-7 Jahren sah das Web noch sehr viel anders aus als heute: klar, es waren weniger Leute drin unterwegs, weil ein Internetzugang noch so ein bisschen was für Nerds war und die große Masse noch nicht recht wusste, was das eigentlich alles soll, aber insbesondere gab es viel weniger große Gatekeeper, die abgeschottete "Sub-Webs" betrieben, während es heute eine Unmenge davon gibt. Vor 7 Jahren hatte der typische "Netizen" eine klassische Website zur Selbstdarstellung, entweder bei einem der unzähligen Free-Webspace-Provider oder bei den günstigen Shared-Webhosting-Anbietern ála 1&1 oder Strato, die in diesen Jahren ihren großen Boom erfuhren. Er trieb sich in diversen meist öffentlichen Webforen (und als richtiger Nerd natürlich auch im Usenet!) herum, fing dann vielleicht später das Bloggen an, und all dieses Tun erzeugte in der Regel Content, der von Suchmaschinen wie Google indexiert und verwertet werden konnte - weil er öffentlich einsehbar war. Und alles, was nicht von jedermann durch simple Kenntnis der URL abrufbar war - E-Mails zum Beispiel, oder Beiträge in geschlossenen Forenbereichen - war ganz bewusst privat, nicht erreichbar für die Crawler. Die Trennung war sauber und einfach, alles war irgendwie "gut".

Heute hat der Durchschnitts-Netznutzer keine Website mehr, sondern ein bis unzählige Profile bei einem bis unzähligen "Networks". Gepostet wird nicht mehr in Usenet oder Webforen, sondern in "Gruppen", die per se nur Mitglieder des zugehörigen sozialen Netzwerks einsehen können. Auch Nachrichten werden immer häufiger innerhalb der Networks ausgetauscht und nicht mehr per klassischer Mail. Praktisch alle Social Networks arbeiten mit Hochdruck daran, ihre eigenen Mikrokosmen im großen WWW aufzubauen und klar ihre Claims gegen die Konkurrenz abzustecken - zu nichts anderem dienen nämlich APIs wie die von Facebook, über welche zum Beispiel die unter Facebook-Nutzern sehr beliebten Zynga-Games (Farmville, Mafia Wars etc.) und unzählige weitere kleine und größere "Apps" realisiert sind. Alles natürlich nur erreichbar, wenn man im "Facebook-Web" eingeloggt ist, also auch unerreichbar für klassische Web-Crawler, und zwar völlig egal ob es sich dabei um tatsächlich private Dinge handelt oder um ein Hilfegesuch zu einem Programmierproblem und die darauffolgende Hilfestellung, wie es sie millionenfach im "alten" Web gab und aus denen noch Jahre später unerwarteter Nutzen von Menschen gezogen wird, die darüber bei einer Websuche stolpern. Genau diese Entwicklung kann ganz schnell zu einem Problem für Google werden und ist sicher mit ein Grund dafür, dass der Suchmaschinenbetreiber in den letzten Jahren mit steigender Intensität nach weiteren Geschäftsfeldern sucht und eine Anwendung nach der anderen veröffentlicht in der Hoffnung darauf, sich auf diese Weise weit genug diversifizieren und vom bislang noch zu wichtigen Haupt-Standbein "Werbung in den Suchergebnissen" unabhängig machen zu können.

So unglaubwürdig es klingt: Google kann schneller obsolet werden, als man das für möglich hält - insbesondere wenn man das Internet "vor Google" und den Aufstieg des Suchmaschinenriesen miterlebt hat. Unter dieser Prämisse stellen sich Engagements wie die Android-Plattform oder Googles neuerlicher Vorstoß in den Bereich Car Navigation plötzlich in einem etwas anderen Licht dar: statt um die Weltherrschaft geht es vielmehr um das profane, nackte Überleben im zersplitterten Internet von Morgen.

26C3.1

Dieses Jahr hab ich mich - unter anderem, weil ich mich jetzt räumlich mit Düsseldorf doch n bisschen näher an Berlin befinde als vorher - nun endlich mal dazu aufgerafft, mal einen C3 nicht nur per Stream, sondern live mitzuverfolgen. Was ich jetzt nach den ersten 2 Tagen auf jeden Fall sagen kann ist: es wird nicht der Letzte sein ;-)

Das Ganze kann man sich im Grunde wie ne LAN-Party für Erwachsene vorstellen, nur weitgehend ohne Kiddies und dafür mit umfangreichem Vortragsprogramm und mit mindestens so viel Spaß. Die Vorträge waren es auch in erster Linie, die mich interessiert haben; großartig viele Leute kannte ich dort ja nun nicht, und coden kann ich auch zuhause. Nichtsdestotrotz konnte ich abseits der Vorträge die eine oder andere interessante Unterhaltung verbuchen, spontan Leute finden die gerade an ähnlichen Themen wie ich arbeiten und - ganz wichtig, weil das hatte ich mir mehr oder weniger vorgenommen - mal als Kandidat am Hacker Jeopardy teilnehmen.

Tag 1

Mit geilen Vorträgen wurde diesmal wirklich nicht gegeizt, gleich in den ersten beiden Tagen waren zahllose Perlen dabei. Das ging los mit der sehr schönen Keynote und dann gleich in eine "Rundreise durch die Welt der Zensur" - ich dachte ja, grob zu wissen, wo auf der Welt das Internet wie zensiert wird (und damit die Länder zu kennen, die niemals als Urlaubsziel in Frage kommen), aber in diesem Vortrag gab es doch noch ne Menge zu lernen abseits der üblichen Verdächtigen wie China oder Kuba. Martin Haase, quasi der Neusprech-Experte des CCC, nahm anschließend ähnlich wie auf dem letzten Congress wieder Politiker-Rabulistik auseinander, diesmal sehr anschaulich an aktuellen Beispielen von der Leyen (haha, fast so ein gutes Wortspiel wie der Titel des Vortrags: "Leyen-Rhetorik"!). Extrem sehenswert für jeden, der sich fragt, wie Medienprofis es immer wieder schaffen, ganze Säle geradeheraus zu belügen, ohne dass das überhaupt irgendwem auffällt. Leider lief parallel ein Vortrag zur Debatte um die Computerspiele, in der ich ja auch irgendwie persönlich involviert bin und den ich daher gern verfolgt hätte, aber wozu gibt es die Aufzeichnungen ;-)

Danach folgte ein Griff ins Klo: es sollte um Wikipedia gehen, genauer um die Methoden, die von den Wikipedia-Autoren und Administratoren intern genutzt werden, um Störenfriede draußen zu halten. Durchaus interessant für jeden, der die Wikipedia-Debatte in den letzten Monaten mitverfolgt hat, weil da eben die Chance bestand, "die andere Seite" mal live und in Farbe zu betrachten, ohne sich dafür in den begehbaren Kleiderschrank in Berlin stehlen zu müssen, in dem Wikimedia Deutschland seine "Debatte" zu dem Thema abhielt. Die Betonung liegt aber auf "Chance", denn der Redner ist leider nicht besonders brauchbar gewesen: mit einer an Monotonie kaum zu überbietenden, unverständlichen englischen Stimme hangelte er sich quer durch überfrachtete und unverständliche Folien, während sein Publikum sich über die Zeit des Vortrags hinweg einmal komplett auszutauschen schien. Na ja, reden wir nicht weiter drüber...

Anschließend folgte aber ein echtes Juwel: der Wikileaks-Vortrag, den ich jedem, der ihn verpasst hat, auch als Aufzeichnung noch ans Herz lege. Wikileaks ist ja als Website mittlerweile sehr bekannt, aber die Personen hinter Wikileaks waren zumindest für mich immer eher Mysterien (was sicher auch so gewollt ist, um möglichst wenig Angriffsfläche für gelangweilte Rechtsabteilungen zu bieten). Nach diesem Vortrag gibt es zu Wikileaks nun immerhin mal zwei Gesichter :o). Die beiden konnten sich der uneingeschränkten Aufmerksamkeit des Publikums während ihres packenden Vortrags absolut sicher sein, ja, manch einer sah sie gar als Helden, und irgendwo ist da wahrscheinlich auch etwas Wahres drin, auch wenn sie selbst bescheiden bemerkten, dass die "wahren Helden" ja eigentlich diejenigen seien, welche die Gruppe um Wikileaks mit den geheimen Dokumenten versorgen, ohne die Wikileaks nichts zu publizieren hätte. Sehr lohnenswerter Vortrag in jedem Fall!

Philippe Oechslin, ein nicht ganz unbekannter Kryptographieexperte, nahm anschließend einige Krypto-Implementationen sprichwörtlich "auseinander", um zu zeigen, dass Produkte mit echten, guten Krypto-Algorithmen oftmals gar nicht durch Brechen der meist sehr starken Algorithmen selbst, sondern durch Finden von Implementationsschwächen geknackt werden können. Die Lehre aus diesem ebenfalls sehr gut moderierten Vortrag ist offensichtlich: Die Verwendung guter Krypto-Algorithmen ist gut, aber nur die halbe Miete, die Einbindung der Algos in die eigene Anwendung muss ebenso sorgfältig beschaffen sein wie die Algorithmen selbst. Auch dieser Vortrag ist ein klarer Watch-Tip!

Wie voll es im Saal 1 tatsächlich werden kann zeigte anschließend der Talk "GSM: SRSLY?", der mal eben trotz zwei parallel laufender (und durchaus äußerst interessanter, zumindest den Titeln nach, das Anschauen der Recordings steht bei mir noch aus...) Vorträge den Saal zum Bersten brachte. Zwar nutzte ein offenbar amerikanischer "Einpeitscher" - ich weiß bis heute leider nicht, wer das genau war, doch er hatte das und die Unterhaltung während der Vortragspausen echt drauf! - diese erste richtige Gelegenheit, um die Zuhörer auf sehr humorvolle aber bestimmte Art auf die übrigen Sitz- und Stehplätze zu verteilen, ohne dass die Gänge dabei verstopfen, aber letztlich bildeten sich vor den Türen beachtliche Schlangen und gemäß der "whoever leaves his seat is gone"-Policy wurde nur noch für jeden, der den Saal verließ, ein neuer Zuhörer reingelassen. Nachdem jeder Millimeter ausgenutzt war, lieferten die beiden Vortragenden (unter anderem der nicht ganz unbekannte Karsten Nohl) einen hervorragenden und interessanten Report über die Fortschritte beim Knacken des in GSM genutzten A5/1-Algorithmus per geschickt berechneter Rainbow Tables ab.

Eigentlich hätte ich mir anschließend gern in Saal 3 "Wireless Power Transfer" gegeben, aber bedingt dadurch, dass ich einen exzellenten Platz in Saal 1 gesichert hatte und die letzten zwei Events des Tages dort mitbekommen wollte blieb ich in Saal 1 und ließ mir von Christoph Faulhaber, einer Art Aktionskünstler, erzählen, wie er durch sein eigentlich harmloses Kunstprojekt "Mister Security" unversehens aufs Radar des FBI gelangte. Alles in Allem recht interessant und unterhaltsam, wenn auch sehr "Einspiel-Film-Lastig" und manchmal hart an der Grenze zur Lächerlichkeit (ein Einspieler zeigt den Künstler z.B., wie er in einem selbst gedichteten Rap-Song die Geschichte seiner fiktiven Figur "Mister Security" erzählt - vom Text hab ich nicht viel verstanden, aber der Film war...nun ja...ich hatte ein Dauergrinsen ;-) ).

Das bewiesene Sitzfleisch zahlte sich aber aus: Fabian Yamaguchi von der in Security-Kreisen nicht ganz unbekannten Gruppe Phenoelit stellte im folgenden Vortrag einen sehr ausgeklügelten Angriff auf ein fiktives Unternehmensnetz vor und demonstrierte, wie einzelne, für sich genommen wenig kritische Softwarefehler in geschickter Kombination das Aushebeln eines ganzen Netzwerks ermöglichen können. Auch ein Stream-Tip für jeden, der sich im Bereich Netzwerksicherheit tummelt!

Den Tag beendet hat dann ein auf diesem C3 erstmalig präsentiertes Spiel: das Chaos-Familienduell. Die Regeln kennt man ja aus der uralten RTL-Gameshow, nur hieß es hier eben: "Wir haben 100 Hacker gefragt...". Das Spiel wurde sehr cool moderiert und mit Hilfe einer schönen Fake-Familienduell-Software (in Java geschrieben, das freut den Java-Freak in mir :D ) originalgetreu präsentiert - ein großer Spaß auf jeden Fall, wenn auch gegen Ende vielleicht etwas langgezogen. Lohnt sich auch als Aufzeichnung!

Tag 2

Der zweite Tag begann für mich mit dem Vortrag einer Amerikanerin: "Why Germany Succeeded Where America Has Failed in Achieving Meaningful Voting Computer Changes". Der Titel weckt Erwartungen, die leider nur teilweise erfüllt wurden. Es war zwar alles in allem interessant, aber leider wird irgendwie zumindest für mich nicht ganz hinreichend erklärt, warum denn nun das höchste Gericht in Deutschland den Wahlcomputern in der bisherigen Form den Garaus gemacht hat und in Amerika nichts dergleichen passiert ist. Die Tatsache, dass ein guter Teil des Vortrags aus einer Filmvorführung bestand und im Rest irgendwie doch sehr auf die Tränendrüse gedrückt wurde machte die Sache nicht unbedingt besser. Ein Reinfall war es zwar nicht, aber ich hätte rückblickend doch lieber den JTAG-Mikrocontroller-Vortrag live verfolgt.

Dann kam aber wieder ein Juwel. Die "Part Time Scientists", ein Zusammenschluss von über 30 Leuten weltweit und Teilnehmer am Google Lunar X Prize, stellten ihr Konzept vor, mit dem sie in den nächsten Jahren mit relativ gesehen fast lächerlich geringem Budget (ich meine mich an 20 oder 25 Millionen Dollar zu erinnern) einen selbst entwickelten Rover auf den Mond transportieren und von dort einen HD-Videostream zur Erde senden lassen wollen. Ein hehres Ziel, aber der exzellent und professionell geführte Vortrag schaffte es tatsächlich, auch bei eher skeptischeren Zeitgenossen wie mir das Gefühl zu erzeugen, dass die da vorne das tatsächlich schaffen könnten! Auch auf kritische Detailfragen (von denen es zur Genüge gab, ich hab unter anderem auch eine gestellt) kamen plausible Antworten, es war vollkommen klar: das ist keine Schnapsidee, diese Leute haben ihr Vorhaben von vorne bis hinten durchgedacht. Ein besonderes Highlight stellte eine Skype-Liveschaltung mit einem Veteranen aus dem alten Apollo-Team (ja, dem Team, das die Apollo-Missionen technisch konzipiert hat!) dar: der pensionierte Ingenieur, dessen Namen ich leider schon wieder vergessen habe, arbeitet aktiv am Projekt mit und bringt seine Erfahrung in das Team der "Part Time Scientists" ein. Leider musste man bedingt durch die nicht ganz optimale Audioübertragung sehr viel Konzentration aufwenden, um das nicht leicht verständliche Englisch des "Remote-Speakers" zu entschlüsseln, aber allein das Event hatte irgendwie was und ein paar fachliche Dinge konnte man durchaus mitnehmen. Definitiv angucken!

Einen spontanen Applaus erzeugte btw die Anmerkung des Lead Speakers, die recht animationslastigen Präsentationen des Teams seien nicht mit Powerpoint, wie man ob der Optik vielleicht meinen könnte, sondern mit einer selbstgebastelten Präsentationssoftware auf OpenGL-Basis erstellt. In mir zündete diese Anmerkung neben der besagten rhythmischen Handbewegung auch noch eine sehr interessante Idee für ein neues "Pet-Project" ;-) aber ich weiß nicht ob ich dazu kommen werde das umzusetzen, mein momentaner Zeitmangel ist echt unschön :(

Der nächste Vortrag "Privacy and Stylometry" klang zunächst vielversprechend, konnte die hohen Erwartungen von meiner Seite aber leider nicht ganz befriedigen. Lag aber evtl. auch an mir - schon beim Wikileaks-Vortrag am Vortag fand ich die (durchaus auch von einigen Zuhörern gestellte bzw. gestreifte) Frage sehr interessant, wie man ausschließen kann, dass individuelle Markierungen jedweder Art in sensiblen Dokumenten eine Spur zum wahren Urheber eines Leaks legen. Ich erhoffte mir hierzu ein paar mehr Erkenntnisse aus diesem durchaus thematisch verwandten Vortrag, aber der Vortragende konzentrierte sich (durchaus zu Recht) eher auf den Bereich der Erkennung einzelner Autoren an ihrem natürlichen Schreibfluss.

Eher in die Kategorie "Fun" gehörte das anschließende Bashing diverser Protokoll- und API-Kuriositäten in "Vier Fäuste für ein Halleluja". Fefe und Erdgeist beackerten von C-Socket-APIs bis HTTP mehrere Themenbereiche der Softwareentwicklung, in denen teils vollkommen blödsinnige, aber durch ständiges Wiederholen mit dem biologischen Äquivalent zu Sekundenkleber im Programmiererhirn festbetonierte Codeschnipsel mit vollem Erfolg dafür sorgen, dass Code, der "hard to write" war, auch weiterhin "hard to read" bleibt - und Copy-and-paste aus alten Projekten eine der wichtigsten Kernkompetenzen. Unbedingt empfehlenswert für jegliches humorbegabtes menschliches Wesen!

Als Teilnehmer an der Massenverfassungsklage gegen die Vorratsdatenspeicherung interessierte mich natürlich der darauffolgende Vortrag besonders: es sollte um den aktuellen Verfahrensstand gehen, aber Constanze Kurz und Frank Rieger, die beide live bei der Anhörung in Karlsruhe zugegen waren, nutzten die Gelegenheit auch, um einige für uns lustige Seitenhiebe an die anderen Verfahrensbeteiligten wie etwa den BKA-Präsidenten zu verteilen und über ihre persönlichen Eindrücke und Schlussfolgerungen zu berichten.

Anschließend folgte ein Vortrag von Phenoelit-Head FX über einen neuen Ansatz, durch ein auf Basis von .NET entwickeltes Filterprogramm schädliche Programmteile in Flash-Animationen noch vor deren Ausführung im Flash-Player aufzuspüren und nach Möglichkeit unschädlich zu machen. Sehr interessanter Ansatz, für den ich durchaus Potenzial sehe - entweder als Komponente im Browser, dem eigentlichen Closed-Source-Flash-Player vorgeschaltet, oder als Bestandteil des Players selbst (Adobe hat laut dem Vortragenden schon ein gewisses Interesse an der Arbeit bekundet).

Äußerst interessant war auch der darauffolgende Vortrag über das (erfolgreiche) Knacken der Security des "Legic Prime" RFID-Systems. Karsten Nohl und Henryk Plötz zerlegten die "Security by Extreme Obscurity" des Systems sehr anschaulich; der Vortrag ist definitiv ein Tipp für alle, die mit RFID-Techniken zu tun haben oder sich dafür interessieren. Dieser Vortrag ist unter anderem deshalb sehr brisant, weil auf Legic Prime eine ganze Reihe von Kleinbetrags-Zahlungssystemen z.B. in Mensen oder Kantinen beruhen, in denen es durchaus um veritable Geldbeträge gehen kann. Vermutlich haben sich die beiden Vortragenden auch deshalb etwas zurückgehalten mit Details - ungewohnt für einen Hacker-Vortrag, normalerweise ist es durchaus erwünscht, dass die Zuhörer anschließend theoretisch in der Lage sind, den beschriebenen Angriff selbst durchzuführen, weil dies den gewünschten Druck auf die das kompromittierte System einsetzenden bzw. vertreibenden Unternehmen enorm erhöht und eher dazu führt, dass Fehler korrigiert bzw. sicherere Verfahren eingesetzt werden. Die Ausführungen der Beiden waren nichtsdestotrotz nachvollziehbar genug, dass nun sicher keiner im Auditorium mehr länger als eine Sekunde über den Einsatz eines Legic-Prime-Systems mehr nachdenken wird. Großes Security-Kino in jedem Fall!

Ein etwas unkonventioneller Beitrag folgte anschließend, in welchem Bicyclemark einige interessante bis lustige bis haarsträubende Geschichten zum Besten gab, wie Journalisten im Ausland über die Schulter geguckt wird - häufig, ohne dass diese sich dessen bewusst sind. Die Kernbotschaft dieses Talks war denn auch, dass Journalisten heutzutage im Grunde schon während ihrer Ausbildung (so sie denn eine solche zu ihrem Beruf brachte) zumindest die Grundlagen der IT-Security lernen müssten, um abhör- und manipulationssicher mit ihren Redaktionen kommunizieren zu können und mit den Wegen vertraut zu sein, wie ihre Rechercheergebnisse möglicherweise in falsche Hände geraten könnten. Dieses Wissen ist wohl laut dem Redner selbst bei sehr kritisch recherchierenden, auf Enthüllungen spezialisierten Top-Journalisten viel zu selten vorhanden.

Abgeschlossen wurde dieser zweite Tag mit meinem persönlichen Highlight: dem Hacker Jeopardy! Im Stream habe ich dieses fast schon legendäre Congress-Event immer sehr gern verfolgt, so dass ich es mir nicht nehmen lassen konnte, diesmal die erweiterten Möglichkeiten der Live-Version zu nutzen - sprich: selbst mitzuspielen :D. Sicher hatte auch die Überdosis Koffein durch ununterbrochenen Konsum von Club Mate (ich muss mich echt mal umsehen, wo ich den Kram in Düsseldorf herbekommen kann) einen gewissen Einfluss, aber der schien mir bei fast allen anderen Teilnehmern ebenfalls vorhanden zu sein ;-) War jedenfalls sehr spaßig; in der ersten Runde konnte ich doch glatt dank der Kategorie "DFÜ", in der man Ton gewordene Datenübertragungen erkennen musste, haushoch gewinnen, um dann aber das Finale mit einer falsch beantworteten 500-Punkte-Double-Jeopardy-Frage (natürlich standesgemäß erhöht auf 1000 Punkte!) glorios zu versemmeln. Hätte ich doch mal lieber den Fefe-Joker eingesetzt ;-)

So viel erst mal zu den ersten zwei Tagen, die anderen beiden kommentiere ich später in einem zweiten Posting (hoffentlich jedenfalls :D)

Googles Masterplan

In den letzten Wochen gab es, was Google betrifft, zwei interessante Meldungen: zum Einen wurde das schon länger angekündigte Chrome OS in einer ersten Preview-Version der Öffentlichkeit präsentiert, und zum Anderen hat Google einen kostenlosen und öffentlichen DNS-Service enthüllt.

Was beide Meldungen gemeinsam haben? Sie verraten, wenn man zwischen den Zeilen liest, eine Menge über Googles Strategie - und die hat es in sich, wenn man mal ein Weilchen darüber nachdenkt (und ja, ich verspreche, die zwar berechtigte, aber in letzter Zeit gebetsmühlenartig immer und immer wieder auf dieselbe Weise runtergeleierte Datenschutz- und Profiling-Debatte hier kein einziges Mal zu erwähnen).

Fangen wir mit Chrome OS an. "Nur eine weitere Linux-Distribution", mag man im ersten Moment meinen, aber schon der oben verlinkte Artikel klärt anhand der veröffentlichten Preview auf: Chrome OS basiert zwar auf Linux, aber auch nur deshalb, weil Google keine Lust hatte, ein komplettes Betriebssystem "from scratch" zu entwickeln, wenn doch schon ein ausgereiftes mit allerlei Treiberunterstützung und problemlos verfügbarem Quellcode auf dem Silbertablett bereitliegt. In der Praxis dürfte sich der potente Linux-Unterbau ziemlich langweilen, denn die einzige Anwendung auf Chrome OS ist - ein Browser!

Google fährt mit Chrome OS mehrere Angriffe parallel auf die anderen etablierten Platzhirsche des IT-Sektors. Gleich zwei Salven gelten Microsoft, die als dominantester OS-Hersteller in der durchaus geschickten Position sind, dass dieser ganze neumodische Webanwendungs-Kram ohne Browser nun mal nicht läuft, und auch wenn der IE weiterhin Marktanteile verliert - die alternativen Browser laufen auch nicht ohne Betriebssystem auf einem PC bzw. Netbook. Spätestens an dieser Stelle greifen die meisten Menschen dann zu Microsofts Produkten, sei es aus Gewohnheit oder einfach nur, weil Windows eben gleich auf dem Rechner installiert war. Die erste Attacke gilt daher ganz klar der Windows-Plattform, die im Grunde bei einem rein zum Internet-Surfen genutzten PC/Netbook genauso unterfordert ist wie der Linux-Unterbau von Chrome, nur dass Letzterer von Google immerhin ein Stück weit "downsized" werden kann, um z.B. die Kaltstartgeschwindigkeit zu erhöhen.

Angriff Nummer Zwei ist weniger offensichtlich, aber er zielt auf eines der größten Machtinstrumente des einundzwanzigsten Jahrhunderts: die Default Settings. Momentan teilt sich diese Macht - hier mal nur betrachtet für den Web-Bereich bzw. alles, was zum Websurfen nötig ist - auf mehrere Marktteilnehmer auf. Microsoft hat einen guten Teil vom Kuchen abbekommen (IE als vorinstallierter Standard-Browser, vorkonfigurierte IE-Einstellungen etwa für die Suche), weitere Teile halten die alternativen Browserhersteller (Werkskonfiguration ihrer Browser) und nicht zuletzt die Provider (die bei der Einwahl übermittelten DNS-Server-IPs). Die Macht, die diesen Voreinstellungen innewohnt, entspringt teilweise der Faulheit und Unkenntnis der meisten User, zu einem guten Teil aber auch der Komplexität, die z.B. eine Browserkonfiguration heutzutage erreicht hat: bei etwas so komplexen kann selbst ein Fachmann kaum mehr alle Einstellungen händisch durchgehen, die Bedeutung jedes Reglers erforschen und dann manuell einstellen (wer mir nicht glaubt: Firefox starten, "about:config" aufrufen und ob der vielen Optionen staunen). Will sagen: die meisten Standardeinstellungen werden nie geändert, demzufolge hat derjenige, der sie kontrolliert, effektiv die von der Mehrheit der User genutzte Konfiguration völlig in der Hand. Wer ernsthaft an der Macht zweifelt, die dieser "Kontrolle über die Massen" innnewohnt, der sehe sich mal die durchaus berechtigten Klagen der Webentwickler über den Internet Explorer und seine nach wie vor "merkwürdige" Umsetzung vieler Webstandards näher an. KEINER, wirklich ABSOLUT NIEMAND, der auch nur den Hauch einer Ahnung von diesem Job hat, will freiwillig für den IE entwickeln. Während man die anderen drei großen Browser-Engines fast in einem Abwasch abfertigen kann, weil das, was etwa für den Firefox entwickelt wurde, mit großer Sicherheit und wenigen bis gar keinen Modifikationen auch auf Opera und Safari/Chrome läuft, kann man mit ebensolcher Sicherheit davon ausgehen, dass man für den IE erst noch unzählige Verrenkungen unternehmen muss, bis der Code da auch das tut, was er soll. Trotzdem kann jeder brauchbare Webentwickler eine Unzahl von Hacks und Tricks für solche "Verrenkungen" aus dem Ärmel schütteln, einfach weil die Hälfte seiner Arbeit darin besteht, die Kompatibilität mit dem IE sicherzustellen - denn ignorieren kann man diesen Schrottbrowser aufgrund des immer noch beachtlichen Marktanteils nur in den allerseltensten Fällen. DAS ist eine winzige Kostprobe der Macht, die sich aus Default Settings ergeben kann.

Neben den Browsern hatte ich noch einen weiteren Punkt genannt, und nicht ohne Grund: die Standard-DNS-Server, die normalerweise der Provider bestimmt, indem er ihre IP-Adressen etwa bei der DSL-Einwahl (z.B. per PPPoE oder ähnlichen Protokollen) an seine Kunden überträgt. DNS ist ein vom durchschnittlichen User eher wenig beachteter Dienst; Beachtung erfährt er eigentlich nur, wenn er mal ausfällt, denn dann ist "das Internet kaputt". Stimmt zwar eigentlich technisch gesehen nicht, aber wer kennt schon die IP von www.spiegel.de auswendig? Eben: keiner. DNS ist daher für die Nutzbarkeit einer Internetverbindung mittlerweile genau so wichtig wie die Verbindung selbst, und durch seine momentane Funktionsweise ein gewaltiges Machtinstrument. Nicht etwa, weil man durch das Ausknipsen von DNS-Servern "das Internet kaputt machen" kann, das wäre viel zu sehr mit dem Holzhammer gedacht. Viel interessanter ist es, DNS-Antworten manipulieren zu können. Der weltweit populärste Weg, Internetzensur technisch umzusetzen, baut auf Manipulation des DNS auf. Abseits von knallharter Zensur kann man aber noch mehr mit der Manipulation von DNS-Antworten anfangen, wie z.B. eine mittlerweile recht gängige Praxis vieler Provider demonstriert: Anfragen nach unbekannten Domains werden nicht, wie vorgesehen, mit einer Fehlermeldung beantwortet, sondern unisono auf eine spezielle IP umgeleitet, auf der der fragliche Provider selbst eine Art Portalseite betreibt, die den User über die nicht existente Domain informiert und gleichzeitig - und hier beginnt der Nutzen für den Provider - irgendwelche Suchergebnisse zu dem betreffenden Domainnamen plus schön passend ausgewählter Werbung darstellt.

Die DNS-Server wären sicher auch ein erster Ansatzpunkt, wenn ein Provider danach strebte, die normalerweise vorhandene Netzneutralität für seine Kunden gezielt zu brechen. Angebote wie dieses sind glücklicherweise noch Fiktion, aber mit Sicherheit sehen einige feuchte Providerträume so ähnlich aus wie das satirische Beispiel. Das DNS wäre der bequemste Weg, um solcherart "Partitionierung" des Netzes durchzuführen: der Server erkennt einfach anhand der anfragenden IP, welche Pakete ein Kunde gebucht hat, und gibt dementsprechend die korrekte Server-IP heraus oder leitet den User auf eine Seite des Providers um, wo ihm großzügigerweise gleich der Kauf des entsprechenden Pakets angeboten wird. Zwar ließe sich so eine "Sperre" einfach umgehen - ein Punkt, der ja beispielsweise in der Diskussion zur sogenannten Kinderpornosperre immer und immer wieder (zu Recht) betont wurde - aber vermutlich würden sich entweder genügend Deppen finden, die trotzdem zahlen, oder man sperrt gleich per simpler und billiger Port-Komplettsperre jegliche Anfragen auf den DNS-Port 53 nach außerhalb des Provider-Netzes. IP-Sperren wären natürlich noch effektiver, aber auch aufwendiger in Einrichtung und Wartung und damit teurer.

Und diese Macht, die auch der Kontrolle über das DNS innewohnt, bringt mich direkt zu Google-Aktivität Nummer Zwei: dem neuen Google-DNS-Serverdienst. Der ist im Grunde für Google echtes Neuland. Bislang beschränkte sich Google auf das Anbieten von für den User direkt sichtbaren Diensten oberhalb von HTTP - Webanwendungen eben: Google-Suche, Maps, YouTube, Text und Tabellen, etc., alles für sich genommen nützliche Dienste. DNS ist für sich genommen gar kein nützlicher Dienst: was brächte es mir, wenn ich herausfinden kann, dass www.spiegel.de auf 195.71.11.67 verweist, wenn dort nichts zum Lesen bereitläge? DNS ist eine Art unterstützender Dienst: er macht die anderen, direkt und für sich genommen nützlichen Dienste besser erreichbar und damit noch nützlicher.

Warum also betritt Google dieses Neuland, das doch die Provider eigentlich praktischerweise schon abdecken? DNS-Server zu betreiben kostet immerhin Geld. Die Antwort erschließt sich, wenn man sich Googles Position in der Netzneutralitätsdebatte vor Augen führt: Google ist sehr stark pro Netzneutralität eingestellt und sieht Provider und Carrier am liebsten als willenlose Datentunnel an, die einfach nur dafür zu sorgen haben, dass die Gigabytes an Daten, die Google jede Sekunde rauspustet, zuverlässig und schnell bei den Google-Nutzern landen. Das hat simple ökonomische Gründe: das eigentliche Geld wird heute nicht mit Zugängen, sondern mit Content verdient, und so kann Google das Maximum an Profit selbst abschöpfen. Von diesem Kuchen sollen die Provider nach Möglichkeit nichts abbekommen, weswegen es äußerst sinnvoll ist, sie so weit wie möglich in die Rolle des reinen Datenkanals zu drängen - zum Beispiel, indem man sie von allen möglichen weitergehenden Aufgaben neben dieser Bereitstellung des "dummen" Kanals entbindet, und genau hierzu zählen DNS-Server. Google festigt mit seiner eigenen DNS-Infrastruktur seine Position und seinen Anspruch als Top Dog unter den Content-Verwertern und drängt die Provider stärker in die ihnen von Google zugedachte Rolle des reinen Infrastrukturanbieters.

Das bringt allerdings alles nichts, wenn die User die Google-DNS-Server nicht nutzen...und genau an dieser Stelle kommt nun wieder die Macht der Default Settings ins Spiel. Ob ein Internet-Device nämlich die vom Provider angebotenen DNS-Server nutzt oder nicht, ist in erster Linie Sache der Konfiguration, und die wiederum rührt kaum ein User jemals an. Es ist also äußerst vielversprechend für Google, so viele Default Configs wie möglich unter seine Fuchteln zu bekommen, und diese anschließend einheitlich auf Googles DNS-Server einzunorden. Und wenn man das mal so betrachtet ist Google nicht schlecht dabei...die ganzen Android-Handys z.B. sind potenzielle Kandidaten (ich weiß leider aus Mangel eines Android-Smartphones nicht, welche DNS-Settings die aktuellen Versionen so per Default mitbringen, aber ich vermute dass das entweder schon Googles DNS-Server sind oder diese dort bald zum Standard werden). Ebenso natürlich alle auf dem zukünftigen Chrome OS basierenden Internet-Surf-Stationen bzw. -Nettops - erste Geräte mit Chrome OS sind für kommendes Jahr angekündigt. Und ich bin mir sicher: Chrome für den Desktop wird auch irgendwann dem User freundlicherweise anbieten, die Google-DNS-Server in die Windows-Netzwerkkonfiguration als Standard einzutragen, um "das Internet-Erlebnis schneller und noch dynamischer zu machen". Oder die Namensauflösung des Betriebssystems gleich umgehen.

Insgesamt ist die größte Gemeinsamkeit dieser beiden Maßnahmen, dass Google versucht, unerwünschte Mittelsmänner bzw. "Zulieferer" zu umgehen oder in ihrer Bedeutung zu beschneiden, ob das nun Microsoft im einen Fall oder die diversen Provider im anderen sind. Ein durchaus schlauer Schritt mit generell nicht ganz unerfreulichen Effekten in Richtung Festigung der Netzneutralität...ich bin mir nur noch nicht so wirklich sicher, ob ich das "big picture" als Ganzes ebenso gutheißen will.