qrios

Googling for the simplest neural net always provide the XOR example with a hidden layer implemented with two neurons. A short but detailed explanation can be found in The Nature of Code – Chapter 10. Neural Networks written by Daniel Shiffman. The trainingssets work like this input(0,1) -> output(1), input(1,1) -> output(0) as in 1 XOR 1 = 0 and so on.

Searching for a “c simple neural net” may come up on top with an article of Santiago Becerra on torwardsdatascience “Simple neural network implementation in C“.  Santiago provides the code at GitHubGist (which is  C++ instead of plain C). There are plenty of other articles about implementations of the original description of the perceptron by Rosenblatt, as in Python, Haskell, Ada, and Assembler(x86).

The cpp-code is straight forward and only addresses the XOR-case, but is easily adoptable to different layouts and input types. Most of the parts of the code are explained in the article in detail, even if the code differs. Only one issue can be spotted in the listing: there is no valid random seed, so the results will always the same on every run. A simple initial srand (time(NULL)) before calling the init_weight function will provide different weights on every run.

Q: Is the original description of a perceptron really the simplest neural net?

A: No (and Yes).

The XOR example of a perceptron expect two inputs and one output. As always the first (and only) hidden layer is implemented with two neurons/nodes. To adopt the example code to different types of inputs the layout of the hidden layer may be changed to more or even less nodes. Use cases with more input attributes could be something like sensor inputs from pressure and temperature together with a timestamp.

But it is possible to think about usage scenarios with only a single input value. For the simplicity an example can be implemented where the output is the sin of the input. The training kernel will then look like:

for (int n=0; n < EPOCHES; n++) {
  for (int i=0; i<NUMTRAININGSSETS; i++) {
    // Starting training
    hiddenLayer = sigmoid(hiddenLayerBias + (training_inputs[i] * hiddenWeights));
    outputLayer = sigmoid(outputLayerBias + (hiddenLayer * outputWeights));
    // Starting backpropagation
    double deltaOutput = (training_outputs[i] - outputLayer) * dSigmoid(outputLayer);
    double deltaHidden = (deltaOutput * outputWeights) * dSigmoid(hiddenLayer);
    outputLayerBias += deltaOutput * lr;
    outputWeights += hiddenLayer * deltaOutput * lr;
    hiddenLayerBias += deltaHidden * lr;
    hiddenWeights += training_inputs[i] * deltaHidden *lr;
  }
}

In this example the activation function is a sigmoid. Due to reducing the input dimension all inner loops can be removed and the flow is much more readable.

For a training set with only ten inputs (from 0.1 to 1.0) after 10.000 epochs the prediction varies from 0.1% to 13% accuracy. It is always way better as the expected 50%

If this works, the question is, if a single dimension hidden layer is either a more simple (and simplest) neural network or no neural network at all. This is for sure only a philosophical question as the definition of a generic  network is not provable per se.

A potential use case for such a neural net could be a replacement for lookup tables in embedded devices. LUTs often used to have functions like sine available in systems not providing these functions in hardware. The simple net implementation would only need the four network values (two weights and two bias). But for sure the number of calculations is significant more cost intensive compared to a LUT implementation.

Q: What other implications coming from this proof of concept?

A: Don’t know, but …

As this implementation was part of an effort to come up with a generic solution to parallelise NN-kernel code on accelerator hardware like GPUs and FGPAs, one interesting aspect is the question if one solution could be to see the whole net as stacked pipelines. Both the forward pass and the back propagation then would be the only point where the stacks depends on another. Such architecture could first of all boost the training massive. But – probably more important – could also make the training more predictable and could give more insight into the condition and behaviour of the net while it is trained.

An interesting second idea is: how could be an architecture looks like, which reduces all nodes and layers in a net to black boxes realised with such a simple “net”. This would provide much more degree of freedom for the layout design of a neural net not even ending up in a dynamic layout (like place and route for hardware design) for the net itself.

Finally, a really silly idea would be to use such a “net” as an entropy source, where some or all weights are fed by a chain of similar networks.

Die letzte Folge der dritten Staffel von Halt and Catch Fire wurden grade ausgestrahlt. Wer die Serie bisher nicht kennt, sollte sie unbedingt ansehen, wenn er sich auch nur marginal für Computer und deren Entstehungsgeschichte interessiert.

In einem wunderschönen und wunderschön schlichten Moment des Staffelfinales – und der IT-Geschichte – treffen sich die Hauptprotagonisten zu einem Meeting in der es um die Frage geht, ob sich aus der Entwicklung dieses Hyptertext-Systems vom Cern irgendwas für die Zukunft machen liesse.

Wie so oft ist es Joe MacMillan (Lee Pace), der die Bedeutung einer Erfindung – diesmal das “WWW” – erkennt. Er argumentiert, dass dies die Befreiung der vernetzten Welt aus den umzäunten Vorgärten der AOLs, CompuServes, etc. ist. Um dies zu verdeutlichen schreibt er den Code des Browsers an das Whiteboard.

John MacMillan vor dem originalen Browser-Code von Tim Berners-Lee (aus Europe!)

Man findet den Code heute auf dem Internet Archive in einer Browser-Collection. Interessant an dem Code ist, dass der erste Browser im wesentlichen eigentlich nur ein Wrapper zu dem RTF(D)-Framework von NEXTSTEP war. Die wichtigsten Zeilen der Datei WorldWideWeb.m befassten sich mit den Einstellungen für die PostScript-Darstellung wie PaperType, LeftMargin, etc.

In der Serie wurde der Code fast fehlerfrei geschrieben. Allerdings zeigt die Archive-Version, dass zwei Zeilen auskommentiert wurden (NXArgc & NXArgv). In vielen Zeilen findet sich der Kommentar /* TBL */ – ganz offensichtlich von Tim Berners-Lee selbst.

Den original Browser kann man sich übrigens auf oldweb.today ansehen und ausprobieren.

Mit ein wenig Hintergrundwissen ist jedem eigentlich klar, was man unter einem Field Programmable Gate Array verstehen kann. Ein Gitter aus Schaltungen, die man nach Belieben zusammen stecken kann und die dann Signaleingänge logisch verschalten und entsprechende Signale wieder ausgeben. So weit die Theorie hinter FPGAs. In der Praxis stellt sich das für einen durchschnittlichen Programmierer schon um einiges schwieriger dar.

Dschungel aus unbekannten Chips und Boards

Für FPGAs gibt es keinen Standard-PC, alle Systeme sind Embedded Systeme. Jedes verfügbare Board ist anders als die anderen. Schnittstellen, Adressen, Speicher usw. unterscheiden sich, haben unterschiedliche Größen und sogar Spannungen. Sogar die Chips der gleichen Reihe vom gleichen Hersteller sind verschieden. Ein echter Prozessor-Zoo.

Ein erfolgreiches Kickstarter-Projekt: Ein Schield für BeagleBone Black oder Raspberry Pi mit einem Spartan 6 FPGA.

Wichtig im Markt sind drei Chiphersteller: Xilinx, Altera und Lattice. Jeder von ihnen bietet eine große Palette an FPGAs. Die Größten kommen derzeit von Xilinx mit 4 Mio logischen Elementen. Diese kosten dann aber auch mehrere tausend Dollar und Entwicklungsboards etwa mit PCIe kommen gerne auf $70.000 pro Stück. Am unteren Ende der Skala finden sich Chips für wenige Cent. Allerdings sind Boards mit preiswerteren FPGAs auch nicht grade billig. Den Zynq 7010 verkauft Xilinx beispielsweise für unter $10 bei Abnahme von größeren Stückzahlen. Allerdings ist die Entwicklung eines Boards so aufwendig und die Zielgruppe so klein, dass ein typisches Board dann doch gerne $200 kostet.

Allerdings bieten solche Chips und Boards dann gerne auch mehr als es ein Arduino oder ARM-Pendent könnte. Die Zynq-Reihe von Xilinx ebenso wie die Cyclone-Reihe von Altera enthalten neben dem unterschiedlich dimensionierten FPGA auch einen ARM-Core (beim Zynq sogar einen Dual-Core). Diese Form des Designs hat sich schon früher mit PowerPC-Cores durchgesetzt und ist für die Entwicklung eine unglaubliche Erleichterung. Man kann dadurch den FPGA-Core dort einsetzen, wo er wirklich sinnvoll ist: Signalanalyse und -verarbeitung. Entsprechend viele Ein- und Ausgänge bieten solche Boards. Einen Sonderfall stellt das Parallella von Adapteva dar. Neben einem Zynq 7020 (Dual ARM und FPGA mit knapp 90k Logic Cells) hat es noch einen Parallelprozessor mit 16 Cores. Für $100 ein absolut faszinierendes Stück für Experimentalprojekte.

Ohne einen separaten ARM-Core kommt der inzwischen sehr weit verbreitete Spartan 6 von Xilinx. Boards mit diesem Chip bekommt man schon für etwas über $50. Das hervorragend designte Mojo wurde erfolgreich über Kickstarter finanziert. Mit dutzenden digitalen und einigen analogen I/Os ist es ausgezeichnet für Frequenzanalyse, Robotik und Steuerung geeignet.

Entwicklungstools: eingeschränkte Auswahl

Xilinx ISE: Eine Oberfläche als wäre sie direkt von Bill und Melinda Gates programmiert worden. Man wartet eigentlich permanent auf Karl Klammer.

Mit der Auswahl auf einen Chip hat man sich leider aber auch auf eine Toolchain für die Entwicklung festgelegt. Jeder Chiphersteller bringt seine eigene Entwicklungsplattform mit. Bei Xilinx nennt sich diese ISE (statt IDE). Es handelt sich um ein Monster, das Eclipse wie einen schlanken Editor erscheinen lässt. Alles soll man damit machen und alles kann man damit machen. Aber für jeden Schritt gibt es verschiedene Subtools, unterschiedliche Interfaces und einen riesigen Katalog an eigenen Begriffen. Wer aus der Softwareentwicklung kommt ist hier vollkommen lost. Es empfiehlt sich vor dem Beginn ein Blick auf die vielen Tutorials bei Youtube.

Bevor man sich die Tutorial jedoch ansieht, muss man sich entscheiden, in welcher Sprache man denn programmieren (Es heisst nicht programmieren!) will. Verilog ist eher in den Staaten verbreitet und VHDL in Europa. Zu den Unterschieden und den Grundlagen von VHDL gibt es eine gute Einführung von der Uni Kiel.

Prinzipiell ist es auch möglich, die Programmierung mit Comandline-Tools zu machen. Allerdings wird man Helfer wie make oder ant vermissen. Je nach Projekt muss man sich mit Shell-Scripten behelfen und diese anpassen. Alle notwendigen Anleitungen findet man in dem Tutorial “Using Xilinx Tools in Command-Line Mode“.

Die Entwicklung unter OSX ist nicht ohne einige Klimmzüge möglich. Mit einer VM in der Linux läuft, die die Xilinx-Tools beherbergt kann man sich aber helfen. Die Übertragung der fertigen Binärfiles funktioniert auch unter OSX z.B. mit verfügbaren Python-Scripten.

Es läuft!

Hat man all die Hürden überwunden, wird man aber ein ähnliches Hochgefühl haben, wie bei seinem ersten Assembler-Programm. FPGAs sind definitiv die hohe Kunst der Programmierung und zeigen erst wirklich, wie (klassische) CPUs tatsächlich funktionieren. Sie sind extrem energiesparend, alle Prozesse laufen gleichzeitig und sie sind in ihren Möglichkeiten nahezu unbeschränkt. Nur an den Tools muss noch gearbeitet werden. Aber es gibt ja auch schon einen FPGA-Assembler und eine Forth-Implementierung für FPGAs.

Die Mobilized Hackernews

Google Reader ist tot, das Leistungsschutzrecht ist da, die User sind nur noch auf facebook und twitter, und URLs werden immer geshorted, um dann nach wenigen Wochen in Vergessenheit zu geraten, weil der URL-Shortener schon wieder seinen Dienst eingestellt hat. Was für eine Welt! Es gibt viel zu wenig meta und vom “semantischen Web” sind wir heute noch weiter entfernt als vor der Erfindung von RTFD und Hypercard.

Also eine gute Zeit, um selbst aktiv zu werden. Mit ein wenige XSLT und uralt HTML/JS kann man noch heute etwas bauen, was auch nur kurze Zeit funktioniert, dafür aber die Informationsbedürfnisse auch wirklich erfüllt.

Für die Developer unter den Lesern gibt es nun die mobile Version der Hackernews aka Ycombinator. Funktioniert wirklich nur auf dem mobilen Gerät. Lädt alle 10 Minuten die neuesten Einträge nach und stellt sie in typischer iOS-Webview dar.

Eher “magazinig” ist die Aufbereitung von arXiv.org

Für die eher wissenschaftlich orientierten Leser gibt es die täglichen Updates aller eingereichten Papers bei arXiv. In der Mehrheit kommen sie aus den Bereichen Physik, Mathematik, Computerwissenschaften und KI. Als kleines AdOn kann man hier noch die Artikel bewerten.

Zum Einsatz kommt bei beiden Seiten XSLT 2.0 von saxon. Für den Einsatz auf einem Server ist es als minimales (minimalstes!) Java-Servlet umgesetzt. Per  ”d:htmlparse” werden die HTML-Seiten in valides XML umgewandelt um von da an als wohlgeformt verwendet werden zu können. Beide Templates sind jeweils unter einhundert Zeilen groß und die Transformation ist selbst bei Last ausreichend schnell.

Früher oder später wird es beide Quellen und sicher noch weitere als aufbereitete RSS-Feeds geben. Und die Frage, warum man das im Jahr 2013 noch selbst machen muss ist einfach zu beantworten: weil es die Anbieter nicht tun.

Der Schock war groß bei den Apple-Kennern. Der Adobe-Manager, der am lautesten Apples Politik in Sachen Flash kritisiert und für falsch erklärt hat soll in Zukunft die technische Zukunft Apples mitbestimmen? Das kann doch nur ein schlechter Scherz sein. Vielleicht noch ein strategischer Zug, um Flash den endgültigen Todesstoß zu geben. Als ob es das noch bräuchte!

Worauf deutet die Personalie wirklich hin?

Apple hat wie immer wenig bis gar nichts zu den Motiven gesagt. Schaut man sich die bekannten Fakten an, ergeben sich jedoch neue Perspektiven.

Kevin Lynch (hier seine Vita) ist ein eingefleischter Mac-Fan. In seiner Vita finden sich etliche Berührungspunkte mit Apples Geschichte. So war er unter anderem an der Entwicklung und Portierung von FrameMaker für den Mac beteiligt. Bei Macromedia hatte er mit Phil Schiller zusammengearbeitet. Als Adobe-CTO war er maßgeblich verantwortlich für die Migration des Businessmodells von der Lizenz zur Cloud. Gerade die Cloud-Dienste sind bei Apple eine schwelende Wunde.

Die Hauptaufgabe von Lynch bestand jedoch darin, die Virtuelle Maschine namens Flash auf alle möglichen Geräte, CPUs und Betriebssysteme zu bringen. Adobe versprach sich von einer möglichst flächendeckenden Verbreitung sprudelnde Einnahmequellen in der Zukunft zum Beispiel von Lizenzgebühren aus dem Rechtemanagement von Filmen im Netz. Laut eigener Aussage hätte er allerdings gerne schon früher Flash durch HTML ersetzt, meinte jedoch, dass dies nicht gelänge.

Kevin Lynch wird zukünftig direkt an Bob Mansfield reporten. Dieser ist Chef einer nicht näher spezifizierten Abteilung für zukünftige Technologien. Und Bob Mansfield ist Apples Mann für die Hardware.

Könnte Apple eine JavaScript-VM-CPU planen?

Als SoC liesse sich ein JavaScript-Core platz- und energiesparend umsetzen.
/cc by @in_aha

Apple hat in den letzten Jahren mehrere CPU-Schmieden eingekauft. Inzwischen entwickeln sie ihre eigenen ARM-Layouts als SoC für iPhone und iPad. Laut etlicher Quellen gibt es schon länger Referenzdesigns für ein MacBook Air mit einem ARM-Prozessor.

Dieses Know How über Prozessor-Design und Produktion zusammen mit dem Wissen von Lynch über Virtuelle Maschinen für Flash würde es Apple ermöglichen einen neuen Co-Prozessor zu entwickeln: eine JavaScript-CPU.

Der Computer eines Normalanwenders verbringt heute einen großen Teil seiner Zeit mit dem Verarbeiten von JavaScript. Zukünftig wird dieser Anteil noch höher werden. Dies allein schon dadurch, dass eher mehr als weniger verschiedene Plattformen bei Smartphones, Tablets, Fernsehern und Computern zu erwarten sind.

Die Versuche, JavaScript zu beschleunigen sind mit der aktuellen Entwicklung von asm.js jetzt an ihr natürliches Ende gelangt. Das gilt allerdings nur, wenn man sich die Möglichkeiten von Software ansieht. Der nächste logische Schritt ist eine Hardwareunterstützung der VM.

JavaScript ist auf Grund seiner extrem einfachen Struktur hervorragend geeignet, in Hardware gegossen zu werden. Wenige Typen, eine simple Statemaschine, Single Threads und Sandboxing sind ideale Voraussetzungen für einen kleinen Core mit Anbindung an den Haupt- und Grafikspeicher.

Sprachspezifische CPUs gab und gibt es immer wieder. Nicht zuletzt lässt sich ein solches Projekt sogar mit herkömmlicher FPGA-Technik umsetzen. Für Java gab es beispielsweise Ansätze von Sun selbst oder die Open-Source-Variante JOP, ein optimiertes Java auf einem FPGA-Chip.

Chancen am Markt

Für Apple hätte ein solcher Schritt viel Charme. Auf drei wichtigen Geräteklassen (iPhone, iPad und ARM-MacBook) würde JavaScript ohne Anpassung durch die Entwickler plötzlich Dimensionen schneller laufen. Und zwar auch erheblich schneller als auf vergleichbaren Geräten der Android und Chromebook-Konkurrenz. App-Entwickler würden noch häufiger lieber zu Webkit und JavaScript greifen als zu nativer Programmierung.

Viel wichtiger als die Performance wäre jedoch der Gewinn bei der Batterielaufzeit der Geräte. Zwei Tage bei einem iPhone und 12h bei einem MacBook wären durchaus im Rahmen des Möglichen.

Damit hätte Apple zwei Verkaufsargumente, die in einem engen Markt wichtig sind. Zumal die Konkurrenz Jahre bräuchte, um auf den gleichen Stand zu kommen, wenn sie es denn – ob restriktiver Patentauslegung – überhaupt könnte.

Die ITU tagt grade in Dubai und möchte jetzt endlich die Verwaltung des Internets übernehmen. Um ihren Anspruch zu unterstreichen, möchten sie als erstes mal einen Standard für Deep Packet Inspection einführen. Zu einer ordentlichen Verwaltung gehört doch auch immer eine lückenlose Kontrolle. Aber was versteht man eigentlich unter DPI?

Prinzipiell ist das Internet ein paketorientiertes Netz. Sehr einfach dargestellt, werden alle Daten in Pakete gepackt, mit einer Adresse und einem Absender versehen. Diese Pakete werden dann von Router zu Router über sogenannte Gateways gereicht, bis sie es zum Empfänger geschafft haben. Dabei ist es diesen Routern eigentlich vollkommen egal, was in diesen Paketen ist. Nur eine Beschränkung gibt es: die Paketgröße oder Maximum Transmission Unit (MTU). Sie ist in einem typischen Ethernet 1500 Bytes. Das bedeutet, dass fast alles, was im Netz stattfindet auf mehrere Pakete aufgeteilt werden muss.

Die verschiedenen Arten der Kommunikation zwischen zwei Rechnern im Netz kann man einem Paket von aussen nicht ansehen. Und bei jeder Art von Kommunikation handelt es sich um einen Dienst respektive Service. Dabei ist es relativ egal, wer jetzt grade der Diensteanbieter (also Server) ist und wer der Empfänger (Client). Für das WWW der http-Service oder -Protokoll eingesetzt. Bei Mail kommen verschiedene Dienste in Frage: IMAP, POP und SMTP. Bei Chats gibt es dutzende verschiedene Protokolle und letztlich kann sich jeder seinen eigenen Dienst ausdenken und ihn auch benutzen.

Für DPI wird bei den Gateways zusätzliche Hardware installiert, die in der Lage ist, Inhalte der Pakete zu analysieren. Dazu müssen die Pakete nach ihrer fortlaufenden Nummer untersucht werden, da die erste wichtige Information bei allen Diensten in den ersten Paketen zu finden ist. Bei dieser wichtigen Information geht es um die Art des verwendeten Dienstes, also z.B. ob es sich um http, imap oder smtp handelt. Diese Erkennung ist notwendig, weil alle Dienste verschiedene Sprachen sprechen. Und diese Sprache muss bekannt sein, damit man analysieren kann, wer die beiden Teilnehmer und was der Inhalt der Kommunikation ist.

Nachdem der Dienst und damit das Datenformat der Kommunikation bekannt ist, wird der Inhalt des Paketes an einen anderen Prozessor weitergereicht, der nur dieses entsprechende Protokoll versteht. Dieser kann nun die Weiterreichung unterbinden, weil zum Beispiel der entsprechende Server auf einer schwarzen Liste steht. Zu dieser Sperrung genügt die bloße IP-Adresse meistens nicht, weil z.B. ein Web-Server unter verschiedenen Domains auf der gleichen IP-Adresse verschiedene Inhalte ausliefern kann.

Wenn es jedoch darum geht ganz bestimmte Inhalte zu sperren – etwa ein urheberrechtsgeschütztes Bild – muss das Paket mit dem Request noch genauer untersucht werden. Erst die GET-Anforderung gibt Aufschluss über die tatsächlich angeforderte Adresse. Problematisch bei http ist aber beispielsweise, dass vor dem GET beliebig viele Zeilenumbrüche erlaubt sind. Unter Umständen muss also nicht nur das erste Paket mit den 1500 Bytes ausgepackt werden, sondern noch weitere Pakete.

Noch komplizierter wird es, wenn die Inhalte selbst Gegenstand der Untersuchung werden. Es können verschiedene Zeichensätze zum Einsatz kommen, oder die Übertragung kann beispielsweise mit Zip gepackt sein. Diese müssten also vorher umgewandelt oder ihrerseits wieder ausgepackt werden.

Bei Milliarden von Paketen, die stündlich über ein typisches Gateway laufen bräuchte man dafür eigentlich schon einen Supercomputer. Wenn es da nicht diese kleinen FPGAs gäbe. Dabei handelt es sich Computer, die keine CPUs im herkömmlichen Sinne haben, sondern viele sehr einfache Recheneinheiten, die für bestimmte Aufgaben hardverdrahtet (allerdings mittels Software) werden. Sie verhalten sich eher wie Signalprozessoren, die bei einem bestimmten Signal eine Ausgabe generieren, während sie ansonsten nichts tun.

Für eine Paketanalyse werden viele dieser FPGAs mit allen möglichen Regeln programmiert. Letztlich agieren sie dann wie ein Weichensystem, dass in dem Paketstrom alle Pakete an eine Adresse rausfiltert, dann die Pakete mit http-Daten an andere weiterleiten, diese wiederum, die Pakete mit bestimmten Hostnamen rausfiltern u.s.w.

Einer der Hersteller von solcher Hardware ist übrigens die Berliner Firma Rohde&Schwarz. Die haben auf der letzten CeBIT bekanntgegeben, dass sie eine Partnerschaft mit Adyton Systems aus Leipzig eingehen. Es geht dabei um eine “revolutionäre” Technik der Leipziger für Deep Packet Inspection. Und von Rohde&Schwarz ist auch ein Vertreter der Deutschlands auf der ITU in Dubai. So schliesst sich der Kreis.

Seit der Version 2.4.3 behandelt der Apache den Internet Explorer 10 gesondert: in der globalen Konfiguration ist nun festgelegt, dass bei diesem Browser der Header für Do Not Track gelöscht wird. Dies geschieht sogar unabhängig von der mit DNT bezeichneten Requestinformation belegten Wert. Für alle nachfolgenden Prozesse oder virtuellen Konfigurationen gibt es dadurch keine Möglichkeit mehr, zu ermitteln welche Einstellung der Nutzer des IE 10 gesetzt hatte.

Für jeden Systemadministrator ergibt sich daher nun nach einem Update die Frage “Wie gehe ich damit um?”.

Letztlich kann man als Betreiber einer Seite danach nicht mehr ausschliessen, dass mindestens ein Nutzer im vollen Besitz seiner geistigen Kräfte seinem Explorer gesagt hat: “Bitte informiere den/alle Server darüber, dass ich nicht getrackt werden möchte.”

Belässt man es als Administrator dann jedoch dabei, geht man ohne Frage ein rechtliches Risiko ein. Immerhin hat die Serverkonfiguration die Kommunikation modifiziert und damit die Intention des Nutzers mindestens fahrlässig ignoriert, wenn nicht sogar vorsätzlich sabotiert.

Falls man keinen Zugriff auf die globale Konfiguration des Web-Servers hat – wie beispielsweise bei den meisten Billighostern – muss man entweder in der Virtual-Host-Konfiguration oder in der .htaccess folgende Zeilen eintragen.


<IfModule headers_module>
RequestHeader set DNT 1 env=bad_DNT
</IfModule>


Damit wird der DNT-Header für alle Requests gesetzt bei denen durch die globale Konfiguration die Environment-Variabel “bad_DNT” gesetzt wurde. Dieses Vorgehen empfiehlt sich nicht nur, wenn man keinen Zugriff auf die globale Konfiguration hat sondern z.B. auch automatische Updates für den Apache einspielen lässt. Dann diese Überschreiben eigene Änderungen jedes mal.

Übrigens: Man sollte natürlich den Wunsch der User auch Rechnung tragen. Der Apache wird durch das Anfügen von “ env=!HTTP_DNT” an die CustomLog-Zeile dazu angehalten, alle Requests nicht in das Logfile zu schreiben. Das ist nicht nur eine nette Geste.

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.

Nach mehreren Nächten mit dem Raspberry Pi stellt sich bei mir erhebliche Frustration ein. Einem schönen Stück Hardware fehlt ein konsistentes und konsequentes Software-Packaging. Das Ausmaß der Ziellosigkeit wird seit gestern für jeden deutlich. Auf der Downloadseite liest man seit neuestem unter “Raspbian ‘wheezy’“:

If you’re just starting out, this is the image we recommend you use.

Folgt man jedoch dem Link zu der Projektseite von Raspbian liest man dort als Antwort auf die erste Frage in den FAQ’s:

First of all, you need to know that Raspbian is under active development and is not suitable at this point for someone new to Linux or small ARM based systems such as the Raspberry Pi.

Das favorisierte System eines Lerncomputers für Menschen/Kinder, die an die Programmierung herangeführt werden sollen, ist nicht geeignet für Leute, die noch keine Erfahrungen mit Linux oder ARM-Systemen haben? WTF!

Das neue System ersetzt dabei eine Debian-Distribution, die nur marginal an das Board angepasst war. Von vielen Nutzern wurde kritisiert, dass die Distribution das Board einfach überfordert. Die Standardpakete installieren vollkommen unsinnige Abhängigkeiten. Möchte man beispielsweise Bluetooth installieren wird gleich mal das riesige Druckersystem CUPS mitinstalliert. Bei dem GPS-Deamon bekommt man dann auch noch die Lüfterkontrolle mit dazu. Buy one get 493 for free.

Dabei sollte eigentlich schon längst eine spezielle Fedora-Version verfügbar sein. Noch im März verkündete man, die Fedora-Distribution wäre fertig und könne verwendet werden. Aus der angekündigten Version Fedora 17 wurde bis jetzt nichts. Kein Wunder, dass Raspberry nun nervös geworden ist und eine angepasste Debian-Version zwischengeschoben hat.

Zusammen mit dem Arch Linux ARM und QtonPi gibt es damit derzeit fünf verschiedene OS-Alternativen (plus dutzende Branches). Davon sind oder waren drei von Rapsberry Pi selbst empfohlen. Hinzu kommt noch ein Firmware-Update. Dieses braucht man zum Beispiel, um Webcams oder TV-Tuner anzuschliessen.

Aus diesem OS-Zoo erwächst schon jetzt ein grundlegendes Problem: wo bekomme ich als Neuling Hilfe her? Eine große kenntnisreiche Community hat bereits alle möglichen Artikel über die Einrichtung das Systems veröffentlicht. Da sich aber das empfohlene System permanent ändert, haben selbst erfahrene Anwender erhebliche Probleme zu unterscheiden, welche die richtige Vorgehensweise ist.

Bei mir hat das Firmware-Update zwar dazu geführt, dass die Kamera inzwischen funktioniert, aber jetzt hängt das System beim Start wenn ein Bluetooth-Dongle angeschlossen ist. Sicher ein lösbares Problem – für mich. Aber für einen Anfänger? (Ja, ich glaube, dass viele mit einer Bluetooth-Maus und einer WebCam spielen wollen.)

Der Hype um das Projekt hat offensichtlich so viel Druck erzeugt, dass eine viellecht mal vorhandene Softwarestrategie über den Haufen geworfen wurde. Und dieser Fehlstart wird dem System wahrscheinlich lange anhängen. Viele Neulinge werden frustriert die Hände davon lassen. Schade.

Zum Verständnis: Ich würde dem Projekt für Idee und Initiative 100 Punkte für guten Stil geben. Und auch die Hardware kann nach meinem bescheidenen Verständnis in diesem Bereich 95 von 100 Punkten erhalten (Abzug für HDMI).

Vor über zwei Jahren hatte Adobe eine Warnung an seine Aktionäre ausgegeben, dass ihnen Apple das Leben schwer machen würde und sie damit mit Risiken für ihr Geschäft rechnen. Das hatten sie drei Jahre nach dem Erscheinen des iPhones und wenige Monate nach Launch des iPad getan. Dabei war von vornherein klar, dass es kein Flash auf mobilen Geräten geben würde. Nicht nur weil Apple als Zugpferd der Touchbranche, es nicht gestattete, sondern weil es schlicht und einfach nie funktionieren würde.

Dabei besteht das Problem von Flash auf Touchgeräten nicht mal nur in Fixierung des gesamten Systems auf Maus und Maus-Cursor, die es eben auf einem Touch-Screen nicht gibt, sondern in der absoluten Trotteligkeit von mindestens 95% aller “Flasher”. Spricht man mit solchen Leuten, stellt man fest, dass diese sich sehr oft gar nicht als Programmierer begreifen, sondern eher als Kreative für Animation. Die Entwicklungsumgebung für Flash zieht offensichtlich viele Leute an, die eigentlich gerne mit Maya oder ähnlichem gearbeitet hätten, denen aber das notwendige Vorstellungsvermögen für die z-Achse fehlt. Einzig Ebenen übereinanderlegen und gegeneinander verschieben können die meisten.

Diese Beobachtung ist sicher subjektiv. Sie spiegelt aber sogar die Adobe-eigene Wahrnehmung wieder: schon 2008 kotzte sich einer der Chefentwickler von Flash über die “Flasher” aus.

Mit der Ankündigung der Aufkündigung von Flash für Android verabschiedet sich Adobe nun aus dem (Web-)Mobilmarkt. Weder für iOS noch für Android noch für Windows Phone oder Blackberry wird es Flash geben. Zwar haben Entwickler nach wie vor die Möglichkeit, Flash für die App-Entwicklung zu benutzen. Bis auf einige wenige Games findet dieser Weg keine Anhänger. Denn die Nutzer mögen keine seltsam aussehenden Apps.

Damit geht der letzte Akt in einem elenden Kapitel des Web zu Ende. Es begann Mitte der neunziger als der Netscape Navigator 2.0 mit der PlugIn-Schnittstelle veröffentlicht wurde. Jede Wald-und-Wiesen-Softwarebude brachte damals PlugIns für irgendwelche proprietären Formate raus. Mit dabei war Macromedia mit einem sehr erfolgreichen PlugIn für Shockwave Director. Eine kleine Firma entwickelt FutureSplash. Es ist einfach zu bedienen und lässt die Herzen der Animateure und derer Kunden schneller schlagen. Microsoft launcht auf dieser Basis die MSN-Zentrale. Damals hatten Compuserve und AOL noch statische Portale.

Microsoft hatte es damals allerdings versäumt, die Firma FutureWave zu kaufen. Statt dessen hat Macromedia zugegriffen, die dann später von Adobe gekauft wurden. Schon 1996 war allerdings klar, dass die Idee der PlugIns eigentlich eine dumme war. Für die Darstellung von PDFs bot ein Browser keinen Zusatznutzen sondern restriktierte den User nur unnötigerweise. Nur Audio und Videos liessen sich wegen Lizenzen und Codecs nicht ohne unter das Volk bringen.

Mit dem Versuch aus dieser komfortablen Situation der Abhängigkeit der Nutzer von proprietären PlugIns, Kapital zu schlagen sind jedoch alle gescheitert. Real, Microsoft und nun auch Adobe. Sie hätten es wissen können.