qrios

IT ist kurios!

Archive for the ‘code’ Category

Stolpern und Zaudern: Erste Schritte mit FPGAs

with 2 comments

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.

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-small

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.

Written by qrios

December 25th, 2013 at 2:29 pm

Posted in code,gadgets

Google Reader ist tot. Es lebe das Meshing!

without comments

Die Hackernews sind derzeit eine der besten Quellen für interessante Nachrichten aus dem Bereich Computer, Programmiersprachen und dem ganzen Rest.

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 Aurfbereitung von arXiv.org

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.

Written by qrios

April 3rd, 2013 at 2:05 am

Posted in code

Apples Pläne mit dem Ex-Adobe-CTO Kevin Lynch

with 2 comments

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.

Written by qrios

March 31st, 2013 at 8:20 pm

Posted in code,gadgets

Was ist Deep Packet Inspection (DPI)?

with 2 comments

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.

Written by qrios

December 5th, 2012 at 3:27 pm

Posted in code,netzpolitik

Apache Do-Not-Track-Bug fixen

with 2 comments

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.

Written by qrios

September 19th, 2012 at 12:45 pm

Posted in analytics,code

Können Algorithmen die Basis für autopoietische Systeme sein?

with 2 comments

 

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:

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.

Written by qrios

September 10th, 2012 at 4:52 pm

Posted in code,science

Frustration mit dem @Raspberry_Pi

with 4 comments

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).

Written by qrios

July 18th, 2012 at 12:38 pm

Posted in code,gadgets

Abgehakt: Adobe ✔

with 2 comments

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.

Written by qrios

July 1st, 2012 at 2:56 pm

Posted in code,web

Tagged with , , ,

Bitlove-Proxy läuft

with 10 comments

Mit etwas Verspätung wg. anderer Projekte ist nun doch der Bitlove-Proxy fertig. Unter “Bitlove-Proxy for the rest of us” ist ausführlich erklärt worum es geht und was der Proxy tun soll. Im Kern geht es darum, die ganze Arbeit mit den Podcast-Torrents und vor allem die Terabyte Mediendaten auf einen echten Server auszulagern und im Hintergrund laufen zu lassen.

Das minimale Interface für den Proxy bietet vor allem das Abspielen on demand. Bei mp4 auch das Springen zu einer Position, die noch nicht geladen ist.

Der Service besteht aus vier Teilen: Apache, node.js-Script, XSL-Template und einem Torrent-Daemon. Der Apache ist notwendig wg. der Auslieferung von Chunks aus MP4. Allerdings ist er nur für das Medienverzeichnis zuständig. Alle anderen Requests leitet er als Proxy an den node.js-Server durch. Das node.js-Script kümmert sich um die Requests des Browsers und verwaltet die torrent- und Medien-Files. Das XSLT verarbeitet die Feed-Daten und baut die HTML-Seite zusammen. Derzeit geschieht letzteres noch im Browser.

In einem XML stehen die Podcasts mit den jeweiligen Feeds drin. Wird die jeweilige Seite jetzt aufgerufen, wird der Feed geparsed und der lokale Server abgefragt, ob die Mediendatei vorliegt. Wenn nicht, wird geschaut, ob eine entsprechende Torrent-Datei gespeichert ist. Falls auch letzteres nicht der Fall ist, wird die Datei von Bitlove.org geholt und der lokale Torrent-Client angewiesen, den Torrent-Download zu starten.

Da der Server mit mehreren hundert MBit angebunden ist, läuft der Download schnell ab. Naja, schnell ist untertrieben: im Falle der letzten mobilemacs-Folge von Gestern waren es laut Logfile von transmission 32 Sekunden. Immerhin handelt es sich um knapp 100MB.

Jun 22 15:44:27 transmission-daemon[23676]: Saved ".config/transmission-daemon/torrents/mm090-speerspitze-der-digitalen-revolution-tm.m4a.898d7344f4a76b76.torrent" (bencode.c:1683)
Jun 22 15:44:37 transmission-daemon[23676]: mm090-speerspitze-der-digitalen-revolution-tm.m4a Starting DHT announce (firewalled, 120 nodes) (tr-dht.c:671)
Jun 22 15:44:59 transmission-daemon[23676]: mm090-speerspitze-der-digitalen-revolution-tm.m4a State changed from "Incomplete" to "Complete" (torrent.c:1869)

Die Quellen kann man hier runterladen. Allerdings empfehle ich das nur wirklich erfahrenen Leuten (Apache-Konfiguration, node.js-Module, etc.), da es keine Dokumentation gibt und ich kaum Zeit für Support habe.

Written by qrios

June 22nd, 2012 at 4:34 pm

Posted in code,web

Bitlove-Proxy for the rest of us

with 5 comments

[Update] Der Bitlove-Proxy läuft inzwischen und steht zur freien Verfügung unter: “Bitlove-Proxy läuft” [/Update]

tl;dr Der Bitlove-Proxy ist ein Aggregator für das automatische Laden neuer Podcast-Folgen über Torrent auf der Basis von Bitlove und Prittorrent. Momentan nicht mehr als ein proof of concept. Jeder fühle sich frei, die Idee zu klauen und eine bessere Implementierung zu machen.

Das Medienimperium metaebene schickt sich an, die Podcast-Distribution zu revolutionieren. Statt einfacher Downloads sollen in Zukunft die Nutzer selbst den Vertrieb übernehmen. Peer-to-Peer auf der Basis von Bittorrent soll das dringende Problem der tröpfelnden Bits der neuesten NSFW-Folge lösen. Dazu haben sich @timpritlove und @astro1138 zusammengetan, Prittorrent entwickelt und Bitlove.org gelauncht. Bei soviel Liebe konnte ich nicht anders, als mitzumachen.

Auf Bitlove haben Podcaster die Möglichkeit, ihre Inhalte als Torrent-Dateien anzubieten. Viele sind dem Vorbild der deutschen Podcast-Ikone Tim Pritlove gefolgt und haben ihre Feeds dort eingetragen. Die Akzeptanz der Podcaster ist offensichtlich kein Problem. Die Akzeptanz der Nutzerschaft lässt nach meiner Einschätzung allerdings noch zu wünschen übrig. Selbst solche Strassenfeger wie Not Safe For Work haben im Peek momentan nur selten über 100 Torrent-Downloads. Die Zahl der Torrent-Seeder überschreitet derzeit nur selten die zehn. Für ein neues Projekt sicher nicht schlecht. Da ist aber sicher mehr drin, denn unter der Hand sprechen Reichweitenmesser wie die agof und die IVW schon davon, dass Podcasts das Broadcastingradio längst hinter sich gelassen haben. (Nein, nicht wirklich ;)

Um dem Projekt mehr Schub zu geben, entwickle ich grade einen Bitlove-Proxy. Zur Erklärung, was der tun soll, hilft sicher eine Beschreibung, wie ich und meine Partnerin Podcasts konsumieren: In unserem Haushalt gibt es eine recht hohe Dichte an Apple-Geräten. Ich selbst höre Podcasts auf den täglichen Radwegen von und zur Arbeit und wenn wir mit dem Auto auf Reisen sind. Meine Partnerin hat einen täglichen Arbeitsweg von zwei mal einer Stunde, entweder mit der Berliner S-Bahn oder wenn die wiedermal nicht fährt mit dem Auto. In der Woche hören wir manchmal bis zu 20 Stunden Podcast.

Ein ernstes logistisches Problem stellt sich dabei recht schnell ein. Auf welchem der neun Rechner/Telefone/Tablets muss eine Folge vorrätig sein? Immerhin reden wir über permanent mindestens zehn Podcast-Feeds mit teilweise über hundert Folgen (CRE aus der metaebene) und manchmal vier Stunden Dauer (mobilemacs ebenfalls aus der metaebene). Und wöchentlich kommt ein neuer Podcast hinzu, in den wir demnächst mal reinhören wollen (z.B. omega tau mit spannenden Wissenschaftsthemen).

Die einfache Lösung besteht in unserem Alltag darin, bei Bedarf auf die WebSite seiner Wahl zu gehen und das mp3 direkt im Browser abzuspielen. Ein ebenso unpraktisches, wie unsoziales Verfahren. Unpraktisch, weil die Browserexperience recht bescheiden ist. Unsozial, weil man damit die Hosting-Rechnung des Podcast-Anbieters belastet.

Hier kommt jetzt wieder Bitlove ins Spiel. Was, wenn nicht meine ganzen iDevices dutzende Kopien der MP3s vorrätig halten (und damit natürlich wiederum die Hosting-Rechnung …) sondern mein eigener Server – auf dem meine Blogs laufen – die Arbeit übernimmt und sich auch noch überaus sozial an der Distribution der Podcasts beteiligt? Ein Bitlove-Proxy also.

Diesem Server gebe ich einfach die Feed-Adressen meiner gewünschten Podcasts. Bei der Einrichtung eines neuen Feeds und in regelmässigen Abständen fragt der Server dann bei Bitlove nach, ob es die jeweiligen Folgen als Torrent-Datei gibt. Wenn ja, lädt er diese runter und startet automatisch den Torrent-Leech.

Bin ich nun unterwegs und möchte einen Podcast hören lade ich einfach eine simple Webseite meines Servers und kann die gewünschte Folge als MP3 von meinem eigenen Server hören.

Tatsächlich kann ich in Zukunft auch iTunes selbst auf meinen eigenen Server schicken, da dieser mir den Feed so umbauen kann, dass er Folgen nur dann einträgt, wenn diese bereits komplett runtergeladen sind. Da die Seeder bei Bitlove offensichtlich über gute Anbindungen verfügen, dauert dies im Allgemeinen nur wenige Minuten.

Technisch ist meine Implementierung eher ein Hasardeurstück: Ein Apache routet die Anfragen an einen internen node.js-Server durch. Dieser dient hauptsächlich dazu, per Komandozeile einen Saxon-Prozessor unter Java aufzurufen, der die Feeds mittels XSLT in eine Webseite umwandelt. Das XSLT ruft beim Transformieren wiederum den lokalen node-Server auf und führt dadurch dazu, dass bei Bitlove vorhandene Torrent-Dateien lokal gespeichert werden und an den XSLT-Prozessor meldet, welche MP3s tatsächlich verfügbar sind. Derzeit sind keinerlei Personalisierungsfeatures eingebaut. Da ich es selbst eigentlich nur als proof of concept begreife, bin ich mir auch nicht ganz sicher, ob ich den Code auf Github stellen sollte.

Vielen Dank bei der Gelegenheit an Astro von Bitlove, der so nett war, die Unterstützung des HEAD-Protokolls mal eben so zu implementieren und neben Bitlove noch so coole Sachen, wie node-expat macht. Ein Eventgesteuerter XML-Parser für node.js. Ich begrüße das!

Written by qrios

May 26th, 2012 at 4:06 pm

Posted in code