qrios

Die aktuelle Version der EULA für den GeForce-Treiber verbietet die Nutzung des Treibers (der Karten) in Rechenzentren. Als einzige Ausnahme wird in den Nutzungsvereinbarungen explizit Blockchain-Verarbeitung genannt.

Keine Bereitstellung in Rechenzentren: Die SOFTWARE wird nicht für die Bereitstellung in Rechenzentren lizenziert. Als Ausnahme ist Blockchain-Verarbeitung im Rechenzentrum gestattet.

Die Karten – insbesondere die 1080ti – ist allerdings extrem beliebt, da sie mit mehreren tausend Cores und bis zu 11GByte RAM eine Alternative zu den Tesla- und Quadro-Karten mit ihren signifikant höheren Preisen darstellen.

Etliche Hoster bieten Konfigurationen mit einer oder mehreren GeForce-Karten an. Eingesetzt werden diese im professionellen Umfeld für Simulationen und Data-Scientists-Aufgaben. Neben üblichen statistischen Berechnungen zählen dazu auch Machine Learning und Deep Neural Networks (DNN). Das erklärt auch, warum sowohl Golem (die das Thema zuerst im deutschsprachigen Newsland™ aufgegriffen hatten) und Heise zu der Verkürzung “kein Depp Learning mehr mit GeForces” kamen.

Für den “kleinen” Data Scientist in einer Firma ändert sich damit zunächst allerdings nichts: er wird seine Python- und R-Scripte weiterhin auf seinem Arbeitsplatzrechner auf einem kleinen Sample entwickeln und dann auf der Computational Engine im Rechenzentrum auf dem vollständigen Datensatz rechnen lassen.

Die spannende Frage ist jetzt, welche Karte in dem Server im Rechenzentrum steckt. Falls es sich um eine virtualisierte Umgebung handelt, kann es bereits jetzt nur eine Karte aus der Tesla- oder Quadro-Liga sein. Auch bisher hatte NVIDIA Funktionen aus dem Umfeld des High Perfomance Computing auf bestimmte Karten beschränkt, u.a. die Virtualisierung.

Solche Umgebungen sind bei Data Scientists sehr beliebt. In den meisten Fällen sind die Kalkulationen und damit die wahrscheinlich anfallenden Kosten relativ genau bekannt und damit die Kosten überschaubar. Ein typisches ML-Model benötigt bei gegebener Rechenpower dort vielleicht ein/zwei Tage. Man bezahlt dafür möglicherweise einige hundert Dollar. Eine  Workstation, die das gleiche Model rechnet, kostet demgegenüber gerne zehntausend Dollar oder mehr und verlangt eigenen administrativen Aufwand, der in einer Enterprise-Umgebung nicht gegeben ist. Mögen sich die Kosten nach 10 Aufgaben amortisiert haben, die Workstation braucht allerdings für das gleiche Model eine Woche statt nur zwei Tage.

Ebenfalls unproblematisch ist die neue Einschränkung für Wald- und Wiesen-Hoster. Wenn ein Kunde sich einen Server mit vier 1080ti clickt muss der Hoster den Kunden – wahrscheinlich – nicht mal darauf hinweisen, dass der GeForce-Treiber bestimmte Restriktionen auferlegt. Im Normalfall wird der Hoster den Treiber auch nicht selbst installieren. Es bleibt dem Kunden überlassen sich dem unternehmerischen Risiko auszusetzen, von NVIDIA rechtlich belangt zu werden. Und auch dieses Risiko hält sich in Grenzen: der Treiber selbst dürfte in solchen Umgebungen keine Möglichkeit haben, zu ermitteln, dass er in einem Rechenzentrum läuft, welches Framework grade ausgeführt wird und überhaupt darf ein Treiber nicht ins Netz. Die Firewall-Rules müssen ihn daran hindern.

Zu einem Problem wird die Neureglung jedoch für die vielen kleinen Spezialhoster, die sich auf Data Scientists und Machine Learning als Marktnische eingelassen haben. Um mit Amazon und Google konkurrieren zu können haben sie eigentlich nur den Preis als Hebel. Und für sie boten sich die GeForce-Karten ideal an. Bei den meisten Anwendungen erreicht eine 1080ti ein Viertel Rechenpower im Vergleich zu einer Tesla-Karte und das zu fast einem Zwanzigstel des Preises. Es verwundert also nicht, dass NVIDIA sich bei einem solchen Betreiber gemeldet hat.

Vor diesem Hintergrund würde es nicht verwundern, wenn Amazon als größter NVIDIA-Kunde ein “aktives” Interesse an dieser Einschränkung bekundet hat; so unter Freunden, wissen schon …

Im Rahmen einer Machbarkeitsstudie stellte sich grade die grundsätzliche Frage, ob eine Blockchain-Implementierung prinzipiell für IoT-Kommunikation denkbar ist und welche Probleme es dabei geben könnte. Es zeigte sich sehr schnell, dass einer der Parameter mit großem Hebel, die Kosten (Operations/Watt) für die Berechnung (Hash-Validierung, Signing, En-/Decryption) der Blockchain ist. Eine sehr kleine Veränderung dieses Parameters führt umgehend zu einem “rechnet sich nicht mehr”.

Viele IoT-Devices basieren derzeit auf ARM-Chips verschiedenster Ausprägung. Teil der ARM-Lizenz ist in vielen Fällen auch das AXI-Protokoll. Dieses Protokoll bietet verschiedene Modi für den schnellen Zugriff auf den Speicher und kommuniziert über ein DMA-Register mit der jeweiligen Memory Management Unit(MMU). Der schnellste Modus ist dabei Scatter/Gather. Ein Verfahren, das noch aus den Urzeiten der IT kommt und erstmals bei SCSI verbreitet eingesetzt wurde. Es wird auch als Vectored I/O bezeichnet und stellt im Kern eine verkettete Liste dar.

In das MMU-Register wird bei dem AXI-Protokoll die erste und die letzte Speicheradresse geschrieben. In den Blöcken der Liste ist jeweils die Adresse des nächsten Speicherblocks hinterlegt. Die jeweilige AXI-Implementierung legt fest, wann der eigentliche Transfer des Speichers stattfindet. Im Allgemeinen geschieht dies, wenn die letzte Adresse in das MMU-Register geschrieben wird.

Ein Block enthält jeweils verschiedene Transaktionen und einen Link auf den nächsten Block. (Quelle: “A gentle introduction to blockchain technology“)

Eine Blockchain selbst ist im Prinzip nichts anderes als eine verkettete Liste. Das bedeutet, dass man lediglich das Format der Blockchain so definieren müsste, dass es die Anforderungen des Scatter/Gather-Protokolls erfüllt. Im Wesentlichen sind dies die Position der Next-Block-Adresse und die Größe des einzelnen Blocks. Diese Größe ist bei AXI variabel muss aber auf Speicheradressen 0×40 aligned sein. Wichtig ist dabei, dass alle Blöcke einer Chain eine identische Größe haben müssen. Sollten sich die Blöcke als zu klein erweisen wäre ein Resizing notwendig.

Die eigentlichen Kosten für die Validierung und Modifikation der Blockchain belaufen sich mit einer solchen Implementierung lediglich auf die Kosten für den Transport der Block-Daten aus dem Speicher und in den Speicher. Sowohl FPGAs als auch ARM GPUs (Neon, Mali) sind in der Lage, alle notwendigen Kalkulationen (Hash-Validierung, Signing, En-/Decryption) für einen Block durchzuführen, während die MMU damit beschäftigt ist, den Speicherinhalt zu laden/speichern. FPGAs hätten sogar noch den Vorteil, die privaten Schlüssel im Bitstream vorhalten zu können, ohne ein Leak befürchten zu müssen.

Am 30. November stellte Amazon ein Developer-Programm für ein neues Serverangebot vor. Unter dem schlichten und schlicht schönem Namen F1 stehen nun Rechner mit FPGAs zur Verfügung. Leider sind die Preise noch nicht bekannt, sollen aber schon bald verfügbar sein. Bei der avisierten Ausstattung kann man aber damit rechnen, dass Stundenpreise im zweistelligen Dollar-Bereich zu zahlen sind.

Zum Einsatz kommen Xilinx UltraScale+ VU9P Virtex FPGAs (~2,5M Logic Units). Bis zu sieben Boards sind in einem Server verfügbar. Eine solche Karte kostet auf der Strasse bis zu 20.000 Euro. Das Investment von Amazon kann also als signifikant bezeichnet werden. Und es dürfte sich dabei nicht nur um ein simples “Me Too” gegenüber Microsofts Bekenntnis zu FPGAs handeln.

Auf einer Karte, die über PCIe x16 angebunden ist stecken 64GByte DDR4-RAM. Angebunden ist der Speicher mit einem 288bit Bus. Die Anbindung verspricht (theoretische) 400Gbps Transferraten. Xilinx spricht von einem “bidirectional ring” ohne näher zu erklären, was sie damit genau meinen. Sie weisen darauf hin, dass man das Zugriffsprotokoll selbst implementieren muss. Was in den meisten Fällen auf eine AXI-DMA-Lösung hinausläuft.

Obwohl die 400Gbps noch nicht an die Top-Karten von NVIDIA rankommen sind sie zusammen mit den 64GByte RAM eine echte Alternative zu der Verwendung von GPUs für Machine Learning. Denn im Gegensatz zu einer symmetrischen Core-Konfiguration können FPGA intelligenter auf den Speicher zugreifen. Mit einem Bus von 288 bit Breite stellt sich das neulich beschriebene Problem Resourcen-hungrigen AXI-Implementation als nicht mehr so dramatisch dar.

Die F1-Instanzen stellen eine virtuelle JTAG-Instanz zur Konfiguration des FPGA-Bitstreams bereit. Dabei dürfte es sich vermutlich um einen Device-Driver von Xilinx für CentOS handeln. Allerdings hat Xilinx Vivado offensichtlich auch für den Einsatz auf CentOS selbst fit gemacht. D.h. man kann den gesamten Workflow auf die Cloud auslagern. Was sicher die Synthese beschleunigt, wenn man selbst nur einen kleinen Arbeitsplatzrechner zur Verfügung hat. Ob das aber ein wirklich praktisches Setup ist, muss jeder selbst entscheiden. Bei den zu erwartenden Preisen rechnet sich ein neuer Arbeitsplatzrechner bereits nach einer Woche Download, Install, Konfiguration, Tests mit Vivado.

Jeff Barr (“Chief Evangelist for the Amazon Web Services”) beschreibt in einem kurzen Hands On wie man zu seinem ersten AFI (Amazon FPGA Image) kommt. Leider wird nicht klar, ob es sich dabei nur um einen Bitstream-Wrapper handelt oder tatsächlich um neues Format. Unklar ist derzeit auch noch, ob sequentielle Updates für die Bitstreams möglich sind. Die Chips bieten diese Option prinzipiell. Auch über verschlüsselte Bitstreams ist nichts in Erfahrung zu bringen.

Amazon wird mit der Verfügbarkeit der F1-Instanzen ein Github-Repository unter https://github.com/aws/aws-fpga(derzeit noch 404) veröffentlichen, das Samples und SDK enthält. Es wird spannend, ob sie tatsächlich einen neuen AXI-Stack als freies IP veröffentlichen oder ob man sich das entsprechende Lizenz-File für die lokale Synthetisierung laden kann.

Um eine Preview-Membership kann man sich hier bewerben.

Fazit

Die Idee, FPGAs in der Cloud anzubieten ist nicht neu. Der Anbieter POMMP verspricht seit Jahren signifikante Beschleunigungen für viele rechenintensive Prozesse. Es ist schön zu sehen, dass nun auch die Großen der Branche auf den Zug aufspringen. Wenn sich nun noch etwas an der Tool-Front tut dürfte dem Erfolg nichts mehr im Weg stehen.

Die meisten Nutzer von Web-Analytics-Lösungen sind früher oder später vom Output ihrer Tools desillusioniert. Oft wegen der Zahlen selbst, aber häufiger ob der (geringen) Aussagefähigkeit der Kurven, Torten und Tabellen. Die versprochenen “Insights” verstecken sich in einem Wust banaler, irrelevanter und teils absurder Aussagen. Was wäre, wenn ein Automat die wichtigen von den unwichtigen Bezügen trennen könnte? Wäre Artificial Intelligence also Machine Learning dazu in der Lage?

Zu viele Fragestellungen an Web-Analyse-Tools

Die meisten Lösungen für Web-Analytics decken ein zu großes Zielpublikum ab. Marketingabteilung, HR, Vertrieb und Support stellen meistens sehr unterschiedliche Fragen an die Tools. Bei vielen Kunden wird dann nur ein geringer Teil des tatsächlich Möglichen implementiert und alle Abteilungen erhalten wesentlich weniger “Insights” als ursprünglich erwartet.

Für alle Abteilungen einer mittelständischen Firma könnte eine wichtige Fragestellung an ein Web-Analyse sein: Wie viele Besucher, die auf der Suche nach einer spezifischen Information (z.B. Stellenanzeige, Produktdokumentation oder Ansprechpartner) sind, finden diese Information nicht. Eine klassische Lösung kann diese Frage nicht beantworten. Der Nutzer müsste sich komplexe Filter zusammenbauen und würde dennoch nur eine Teilantwort erhalten. Mit Hilfe von Machine Learning wäre diese Frage beantwortbar.

Konfiguration eines Netzes

Im Gegensatz zu typischen Anwendungen wie beispielsweise Bild- oder Spracherkennung stellt sich bei der Web-Analyse eine besondere Hürde für die Verwendung eines neuronalen Netzes: die Anzahl der Parameter für den Input ist im Prinzip unbegrenzt. Zu einer User-Session gehören grundsätzlich neben den aufgerufenen Seiten und dem Referrer alle Eigenschaften des Netzes wie des Browsers.

Diese Parameter sind jedoch variabel. D.h. dass beispielsweise Referrer sich im Laufe sehr kurzer Zeit verändern, ebenso wie die User-Agent-Strings oder die (möglicherweise anonymisierte) IP. Einige dieser Parameter komplett zu ignorieren würde jedoch viele mögliche Aussagen (z.B. “Stellensuche funktioniert nicht mit Safari”) im Vorfeld ausschliessen.

Der Umgang mit den Parametern – das Encoding – bestimmt die Art und vor allem Größe des verwendeten Netzes. In den Daten gibt es grundsätzlich zwei verschiedene Arten von Daten. Fast alle Daten lassen sich in der Form key=value aufbereiten. Dabei lassen sich alle Values gruppieren (z.B. Browser=Safari|Firefox|Chrome…). Im Prinzip sind damit auch die Timestamps modellierbar.

Ausgehend vom ImageNet erschien allerdings ein anderer Ansatz zielführender. Betrachtet man die für das Training verwendeten Bilder, so enthalten sie natürlich zuerst die Bilddaten selbst. Darüber hinaus ist jedes Bild jedoch auch mit Metadaten qualifiziert. D.h. wenn auf einem Bild eine Axt zu sehen ist, dann enthält die Beschreibung diese Information zusammen mit den Koordinaten.

Der ImageNet (2011) Browser für die Beispielbilder (Quelle: http://imagenet.stanford.edu/synset?wnid=n02764044 )

mehr…

Jessas! Nicht Algorithmen “werten”, sondern ihre Programmierer. P[rogrammierer] ist mit A[lgorithmus] eine soziotechn Einheit (weil Werkzeug), P[rogrammierer] handelt und P[rogrammierer] wertet.

— Christoph Kappes (@ChristophKappes) September 9, 2012

@christophkappes @kathrinpassig Das ist mechanistische Sichtweise. Wenn P[rogrammierer] ein autopoietisches System entwickelt, kann P[rogrammierer] nicht mehr werten.

— Rene Meissner (@qrios) September 10, 2012

Darauf entspann sich zwischen mir und @kathrinpassig eine Diskussion über die Praxisrelevanz meiner Aussage. Mein Verweis auf neuronale Netze und genetische Algorithmen waren ihr wohl noch zu akademisch. Daher verwies ich auf MapReduce:

@kathrinpassig @christophkappes MapReduce erfüllt in der Praxis auch die Anforderung dass P nicht 100% der Ergebnisse kennen kann.

— Rene Meissner (@qrios) September 10, 2012

Tatsächlich habe ich nahezu täglich mit diesem Effekt zu tun. Bei der WebAnalyse und dem Social-Media-Monitoring für größere Auftraggeber werden unter anderem Google Analytics oder facebook Insights eingesetzt. Beide verwenden MapReduce und tun dies auf der Basis von Stichproben. Alltägliche Erfahrung ist, dass zu unterschiedlichen Zeiten die Ergebnisse für den gleichen Zeitraum unterschiedlich sind.

Grade bei zeitnahen Abfragen werden Stichproben verwendet. Da MapReduce in großen Systemen wie Google und fb asynchron läuft hängt das Ergebnis unter anderem davon ab, welcher Server grade Zeit hat und daher verwendet wird. Dadurch werden bei zwei aufeinanderfolgenden Abfragen möglicherweise vollkommen andere Datensätze verwendet. Wie solche Systeme trotz der Abweichungen valide Daten liefern können beschreibt zum Beispiel die Arbeit “Early Accurate Results for Advanced Analytics on MapReduce“.

Als Programmierer könnte ich daher trotz Kenntnis über alle eingehenden Daten nicht vorhersagen, welche Ergebnisse “mein” Algorithmus liefern wird. Ich könnte lediglich eine Aussage darüber treffen, welche Werte minimal und welche maximal berechnet würden und welche Werte am wahrscheinlichsten sind.

Eine solche Unbestimmtheit würde sich noch fortpflanzen, wenn das Ergebnis – zum Beispiel in einem Mashup-System – selbst wieder zum Input für ein selbstorganisierendes System würde.

Der Programmierer spielt in einem solchen Setup kaum noch eine Rolle. Schon gar nicht wertet er. Einen spürbaren Einfluss auf das Ergebnis hat sicher noch derjenige, der bestimmte Parameter wie die Stichprobengröße oder die Anzahl der verteilten Prozesse festlegt. Allerdings sind auch diese meistens variabel. Denn sie sollten sich möglichst optimal auf Geschwindigkeit, Genauigkeit und Stromverbrauch einpegeln.

Wenn der Programmierer nicht wertet, wertet denn dann der Algorithmus? Eigentlich nicht. Ebenso wenig, wie das einzelne Neuron in unserem Gehirn rechnet, aber das Gehirn selbst rechnen kann. Vielmehr ist es der Systemzustand selbst, der über das Ergebnis entscheidet. Der gleiche Algorithmus (vom gleichen Programmierer) kommt bei gleichen Daten und bei gleicher Systemarchitektur zu unterschiedlichen Zeiten zu einem unterschiedlichen Ergebnis.

Wobei bereits die Bezeichnung “gleiche Systemarchitektur” ungenau ist. Betrachtet man mehrere Server in einem Rechenzentrum, so kommunizieren die darauf laufenden Services über TCP/IP welches seinerseits meistens über Ethernet läuft. Dieses Protokoll verwendet aber eine auf Zufallszahlen basierende Kollisionsvermeidung. Würden zwei Server bei einer verteilten MapReduce-Anwendung die Ergebnisse gleichzeitig abliefern wollen, würden die Nachrichten kollidieren. Beide würden es nach zufällig langer Pause wieder probieren. Fehlt dem Server zum Zeitpunkt der Kollision nur noch ein Ergebnis für seine Stichprobe würde er nur noch eines nehmen, das andere Ergebnis würde verworfen. Das Ergebnis hängt also tatsächlich von den Zufallsalgorithmen zweier Netzwerkkarten ab. Und die Ergebnisse der Zufallsalgorithmen können wiederum von nahezu beliebig vielen anderen Faktoren abhängen.

Letztlich sind demnach schon heute Algorithmen die Basis für autopoietische Systeme. Nicht nur bei neuronalen Netzen oder genetischen Algorithmen sondern bei jeder Cloud um die Ecke.

Die Schufa untersucht mit Unterstützung des Hasso-Plattner-Instituts, ob Informationen aus sozialen Netzwerken relevante Daten für die Kreditausfallbewertung zu finden sind. Nach Personalchefs und der Polizei kommen nun also auch träge deutsche Firmen auf die Idee, ihre Datenqualität zu verbessern. Das ist nicht verwunderlich und sehr lange prophezeit z.B. für Krankenversicherungen.

Der wirklich interessante Punkt daran ist die Tatsache, dass Kreditscoring vergleichbar ist mit Social Media Reputation.

Die meisten facebook-Nutzer, die man fragt geben unumwunden zu, dass sie bei neuen Freundschaftsanfragen, sich zunächst ein Bild über den facebook-Wert der Person machen (auf diesem Interesse basieren nicht umsonst etliche fb-Würmer). Wie viele Freunde, wie viele Likes haben die Posts, wer antwortet der Person? Diese Bewertung soll gewährleisten, dass sich investierte Social-Coins™ nicht als Fehlinvestition erweisen. Denn die Social-Media-Identität ist heute ein signifikanter Part der Identität. Durchaus vergleichbar mit den Schulhofpsychomechanismen bei der man durchaus gravierende Fehler machen konnte, wenn man sich mit den falschen Leuten rumgetrieben hat.

Tatsächlich könnte eine gesellschaftliche Reputation zukünftig das Scoring-System ersetzen. Sehr interessant beschrieben hat das Charles Stross in seinem Roman Accelerando.

[Update] Wie kritisch die automatische also maschinelle Bewertung von Social-Media-Inhalten in Bezug auf die Qualität der Daten zu sehen ist, schreibt goowell in seiner Diskussion mit @mspr0. Meine Erfahrungen mit Tools wie Vico Research bestätigen seine Einschätzung. Der Informationsgehalt von SM-Inhalten tendiert auf Grund des sehr oft fehlenden Kontextes gegen Null. [/Update]

Hier und da poppt seit Jahren eine mehr oder minder starke Furcht vor Algorithmen auf. Egal ob von Meckel, Schirrmacher oder anderen Fuilleton-Natives ist der Tenor immer ähnlich: wir werden alle störben Algorithmen sind dabei den Menschen einzuschränken. Da freut es denjenigen, der sich im Studium mal intensiv mit Technikkritik beschäftigt hat dann doch, dass auch mal eine etwas kenntnisreichere Stimme zu Wort kommt. In der SZ erschien ein Artikel von Kathrin Passig mit dem Titel “Warum wurde mir ausgerechnet das empfohlen?“.

Nun ist Kathrin Passig nicht unbedingt jedem als ausgewiesene Algorithmus-Expertin bekannt, hebt sich aber durch digitale Erfahrung erfrischend von den Mahnern ab. Nur leider hat sie das Thema auch nicht verstanden. Was schade ist, da mspr0 ihr gleich zur Seite springt und ihre (Falsch-)Aussagen kunstvoll in seine These vom Kontrollverlust und der darauf zwangsläufig folgenden Postprivacy einflechtet. Warum Falschaussagen? Weil sie zum Beispiel eine Bestsellerliste einem Algorithmus gegenüberstellt. Dabei ist eine Bestsellerliste genau das: das Ergebnis eines Algorithmus. Den können zwar alle verstehen aber dadurch wird er nicht zum Nicht-Algorithmus.

Für sie ist – wie für die Mahner – ein Algorithmus etwas, das (bei genügend großer Komplexität) ein Mensch nicht mehr verstehen kann. Dazu wird ein (unverlinktes) Zitat bemüht:

Die am Wettbewerb beteiligten Teams [die Programmierer der Algorithmen] gaben in Interviews an, nicht mehr nachvollziehen zu können, wie ihre eigenen Algorithmen zu manchen Ergebnissen gelangen.

Diese Aussage kann man jetzt in mindestens drei Richtungen deuten. Die Programmierer verwenden Code, den sie nicht selbst geschrieben haben (Framework, Compiler) und dies führt zu einem Black-Box-Verhalten, die Programmierer haben Code geschrieben, der sich selbst verändert oder die Programmierer kennen nicht mehr alle Werte, der zu diesem Ergebnis geführt hat.

Der erste Fall kommt recht häufig vor ist aber sicher nicht gemeint, da die konkrete Implementierung egal ist, solange das gewünschte Ergebnis produziert wird. Sollte mein Code trotz eingehender Prüfung nicht mehr das tun, was ich gerne hätte, würde ich überprüfen, ob die beteiligten Frameworks nicht das tun, was ich erwarte und im letzten Schritt, ob der Compiler merkwürdige Seiteneffekte produziert. (Aber normalerweise würde ich erst mal schlafen gehen, weil sich das Problem am nächsten Tag meistens in Luft aufgelöst hat.)

Der zweite Fall ist schon etwas komplizierter. Selbstveränderlichen Code gibt es bereits und wird insbesondere von Virenprogrammierern eingesetzt. Dabei geht es aber nicht um eine Veränderung der prinzipiellen Funktionsweise im Sinne von Evolution sondern lediglich um Mimikri. Ein solcher Code würde im Idealfall tatsächlich dazu führen, dass selbst die Entwickler ihn nicht mehr ohne eingehendes Studium von jedem anderen Code unterscheiden könnten und nicht sagen könnten, was der Code tut. Und dies obwohl sie ihn selbst geschrieben haben.

Es ist mit hoher Wahrscheinlichkeit in dem Zitat der dritte Fall gemeint. Eine Liste von Eingabewerten wird immer wieder durch die Maschine geschickt und kalibriert die vorgegebenen Schwellwerte an Hand von Erfolg und Misserfolg. Dabei kommt in den einzelnen Zwischenschritten viel Stochastik zum Einsatz und ab und zu wird mal der Zufallsgenerator angeworfen, um das ganze System vor der zwangsläufigen Stasis zu beschützen. Die eingesetzen Algorithmen sind in den meisten Fällen mit den mathematischen Fähigkeiten eines Realschülers zu verstehen. Die anscheinende Komplexität entsteht nur aus der Anzahl der Eingabedimensionen und der Anzahl der Iterationen.

Wichtig an diesem Punkt ist besonders der Begriff des Schwellwertes. Denn hierbei handelt es sich nicht um ein einzelnes Bit, dass gesetzt ist oder nicht. (Aber selbst bei solchen Systemen kommen schon komplexe Verhalten zu Stande. Dazu möge man sich die dreißig Jahre alten Arbeiten über zelluläre Automaten von Stephen Wolfram ansehen.)

Schwellwerte werden normalerweise als Fließkomma implementiert. Computer und damit auch Algorithmen sind allerdings recht ungenau im Umgang mit Zahlen wie 1/3 oder Wurzel aus 2. Da es sich um endlose Zahlen handelt muss eine CPU diese Werte runden. Und je nach dem, in welchen Zustand (z.B. in welchem Speicher sich die Werte befinden) kommt eine etwas andere Zahl bei der Operation raus. Genau genommen haben wir es hier mit einer Heisenbergschen Unschärfe zu tun.

Da ein Algorithmus jedoch nichts anderes ist als eine Aneinanderreihung von Operationen ist, werden selbst bei exakt bekannten Eingangswerten die Ergebnisse um so unvorhersagbarer je öfter eine solche Rundung stattfindet.

Einer der wichtigsten aktuell im Einsatz befindlichen Algorithmen ist die Page-Rank-Berechnung von Google. Obwohl bisher nicht nach aussen gedrungen ist, wie er exakt aufgebaut ist, basiert darauf die ganze SEO-Branche. Für viele handelt es sich um reines Google-Voodoo. Dabei kann man an Hand unterschiedlicher Ergebnisse eine Art Verhaltensforschung betreiben. Und obwohl ich noch niemanden gehört habe, der meint, es würde sich um ein Lebewesen handeln verhält er sich dennoch anscheinend so. Ich kann ihn untersuchen an Hand möglichst vieler Parameter, die er auch (vielleicht) sieht. Seine vollständige Funktionsweise könnte ich jedoch nur ermitteln, wenn ich ihn immer wieder in den gleichen Zustand versetzen könnte, was ginge. Ich müsste allerdings auch seine Umwelt wieder in den gleichen Zustand versetzen, was nicht ginge.

Nichts desto trotz ist der Page-Algorithmus einfach und Lerry Page versteht ihn sicher nach wie vor und etliche seiner Mitarbeiter auch.

(Quelle animiertes Gif: http://de.academic.ru/dic.nsf/dewiki/279011)

Douglas Adams schrieb im ersten Teil des Anhalters durch die Galaxis über die Entdeckung des unendlichen Unwahrscheinlichkeitsdrives durch einen Studenten, der das Labor putzen musste und sich fragte, was eigentlich passieren würde, wenn er die Aperatur an eine wirklich heisse Tasse anschlösse und dabei zufällig die wichtigste Entdeckung des Universums machte, sinngemäß, dass das, was Wissenschaftler wirklich nicht ertragen könnten, Besserwisserei sei. Tatsächlich war es jedoch so, dass sie es einfach nicht ertragen konnten, nie zu den wirklich wichtigen Partys eingeladen zu werden.

Schade eigentlich, dass ihr nie zu den wirklich wichtigen Partys eingeladen werdet. Aber so, wie ihr Euch grade gebärdet werden aber auch in Zukunft nur die Typen mit den langen oder gar keinen Haaren eingeladen …

Und es geht eben nicht um die Frage “Wozu Atomkraftwerke?” sondern um die Frage ,warum sich Wissenschaftler instrumentalisieren lassen. Warum sie, zu dem was sie antreibt nicht stehen. Warum sie sich durch Drittmittelanträge, dreijährige Hiwi-Stellen und Fußnoten-#dickbars von ihren ursprünglichen Antrieben abtreiben lassen. Leute, die was wollen werden nicht reich. Punkt.

Es gilt heute bei vielen als gegeben, dass private Datensätze in verschiedenen Datenbanken mittels geeigneter Techniken gematcht werden können und damit ein Bezug zwischen zugeordneten und losen Daten hergestellt werden kann. Oder konkret: wenn ich auf der einen Site mein Geburtsjahr, -ort und Geschlecht angebe und auf der anderen Site den Geburtsort, Geschlecht und Ausbildung, kann ein Dritter mit Zugriff auf beide Datensätze, eine Beziehung zwischen beiden Datensätzen herstellen. Für viele (nicht alle) ist die Vorstellung, dass ihre sauber getrennten Identitäten in verschiedenen sozialen Aspekten verknüpft werden können ein Graus.

Die Frage ist daher, ob es ein Verfahren gibt, die Vorteile von digitalen Identitäten zu geniessen ohne die Kröte der erodierenden Privatsphäre in Kauf nehmen zu müssen. Eine erste Lösung stellte Latany Sweeney 2002 in dem Aufsatz k-Anonymity: A Model for Protecting Privacy dar. Die Idee ist recht einfach. Es werden einfach Daten ‘dequalifiziert’ oder unscharf gemacht. Aus dem Geburtsort könnte so zum Beispiel der Landkreis werden. Eine deutsche Darstellung, wie das Verfahren funktioniert hat Dietmar Hauf von der Uni Karlsruhe veröffentlicht.

In einem neuen Papier auf arXiv beweisen drei Autoren der Purdue University jedoch, dass dieses Verfahren ohne Erweiterung keinen ausreichenden Schutz bietet. Sie verknüpfen in der Arbeit “Provably Private Data Anonymization: Or, k-Anonymity Meets Differential Privacy” das Modell der k-Anonymity mit der als Differential Privacy bezeichneten Methode, die zum Beispiel für den facebook-Gegenentwurf diaspora diskutiert wird.

Der Artikel ist inzwischen nach http://opendgps.de/2cm-gps-genauigkeit-fur-alle/ umgezogen. Das Projekt OpenDGPS beschäftigt sich damit aus der damaligen Idee ein Open-Source-/Open-Data-Initiative zu machen.