 Hallo, ihr hört den Vortrag Schlangen und Kaninchen, wie der CCC einen Open Source Hardware-Erfolg geformt hat, in der Übersetzung von Stefan und Juppie. Viele Leute, die hier teils schon seit Jahren zum Kongross kommen, seit Jahren aus allen Teilen der Welt, die sich vielleicht noch nie persönlich getroffen haben. Bunny kommt aus Singapur, Tim kommt aus Australien und es ist toll zu sehen, wie sich hier alle zusammenfinden. Die beiden werden heute darüber reden, wie der CCC eine große diverse Zahl von Menschen zusammengebracht hat, um ein tolles Projekt gemeinsam zu stemmen, das ohne diese gemeinsame Zusammenarbeit nicht hätte stattfinden können. Herzlich willkommen, Bunny und Tim. Dankeschön. Vielen Dank, dass ihr zu unserem Vortrag kommt. Spannende Nacht heute für den Kongross. Der Vortrag heißt Schlangen und Kaninchen und ich überlasse es euch, die Verbindungen herzustellen. Es geht um ein Erfolg und was bedeutet Erfolg in diesem Zusammenhang, zum Beispiel, dass das Gerät ausgeliefert werden kann. Um anzufangen, möchte ich kurz zeigen, um wen es dir geht. Ich bin Bunny, ich mache Hardware, ich beschäftige mich mit Atom und Atome sind schwer. Ich werde euch ein bisschen erklären, warum das so schwer ist, nicht weil ich nicht jammern will, sondern weil die Entscheidungen relativ schwierig sind. Atome gehören normalerweise jemanden oder zumindest glauben Leute das. Und deswegen glauben Leute, dass sie dir erklären können, dass sie dir bestimmen können, was du damit machen kannst. Und als Ingenieur ist es sehr hilfreich, wenn du die Leute nicht überzeugen musst, was zu tun, sondern wenn du das richtig designen kannst. Und Atome unterliegen der Entropie und deswegen geht es viel um testen und validieren. Atome sind meistens nicht da, wo man sie braucht. Tantalum wird in diesen Ländern abgebaut und man braucht die unter anderem für Kondensatoren. Und man muss sie also finden und holen und Atome einzusammeln. Selbst wenn es heißt, dass der Versand umsonst ist, bezahlt wird er auf jeden Fall. Und aus Sicht von dortem Hardware, da geht es häufig darum, wie man Probleme beseitigen kann, was sehr schwer ist, weil häufig die Hardware ganz woanders ist und als Mensch an der richtigen Stelle zu sein, um Probleme lösen zu können. Dafür muss man reisen und das ist schwierig. Und es gibt sehr unbequeme Wahrheiten, wenn es um Atome geht. Wir haben Mülleimer, da kann man Sachen reinwerfen, dann sind sie weg. Aber der Müll geht natürlich irgendwo hin. Wir beschäftigen uns mit diesen ungeangenehmen Wahrheiten. Wir glauben vielleicht, dass wir freie und offene Software haben, die frei von Problemen sind. Trotz all diesen Problemen mag ich immer noch Atome. Ich kann es zwar nicht erklären, aber ich habe durch ein dekupiliertes Genom durchgeguckt und habe da gelesen, lernt nicht von seinen Fehlern. Also ich habe mir damals an einem Lötkolben die Hand verbrennt und irgendwie habe ich das nicht gelernt, weil ich habe weiter gelütet. Jetzt darf euch Mithro was über sich erzählen. Hi, ich bin Mithro. Ich bin ein Software-Engineer. Ich habe nicht mit Atomen zu tun, sondern mit Bits. Bits sind spannend und interessant, weil sie ein bisschen einfacher sind als Atome, aber auch schwerer. Als Hardware-Engineer stellt man sich Software vielleicht so als 1 und 0 vor. Aber in Realität schreiben halt Menschen Software und Menschen sind keine Roboter und sind scheiße im repetitiven Sachen erledigen. Software ist repetitiv. Also schaut Software mehr so aus, hat viele Bugs. Ich habe viele Bugs geschrieben und ich werde auch gut bezahlt dafür Software zu schreiben, aber sogar mit besten Standards passieren halt Bugs. Und manchmal sind sie sehr groß. Ich habe große Bugs geschrieben. Software ist halt sehr anders verglichen mit Hardware, weil wenn sie passiert sind, kann man sie dann wieder beheben. Und dann ist das, als ob sie nie existiert hätten. Das ist cool, weil ich habe viele Bugs geschrieben und dann kann ich sie beheben und ihr habt das Gefühl, ich habe sie nie geschrieben. Und deshalb sind Atome unglaublich furchteinflößend. Es ist viel schwerer Atome zu patchen. Und irgendwie sieht man dann immer, dass du dann da was behoben hast. Also es ist ziemlich schwer Hardware zu patchen. Also habe ich das gar nicht so viel gemacht mit Hardware, bis ich FPGAs entdeckt habe. Und die sind super cool für Software-Engineure wie mich, weil sie verwandeln ein Hardware-Problem in ein Software-Problem. Und ich liebe Software-Probleme. Das heißt, ich kann meine Hardware beheben, nachdem ich sie ausgeliefert habe. Das ist super, weil ich bin ja ein Software-Engineur, ich mach Bugs. Also ich lebe in einer ganz anderen Welt als Bunny. Und es ist interessant, dass wir hier die Bühne teilen mit sehr unterschiedlichen Hintergründen. Wie ist es eigentlich zu dem gekommen? Bunny würde ich jetzt erzählen, wo fängt diese Geschichte eigentlich an? Also ein bisschen über den Ursprung von dieser ganzen Reise. Mal lange her und weit, weit weg, hat ein Atome-Engineur ein Problem gehabt. Hier ein Diagramm von Jumbi. Geht so von links unten nach rechts oben. Und die Preise werden höher nach rechts und nach oben. Glas ist teuer und große Gläser sind teurer. Also was man machen will, ist, dass Glas loswerden. Also wie können wir LCDs verhindern? Also Glasstücke, die unsere Produkte teuer machen. Wir haben gesehen, alle haben schon ein Stück Glas bei sich in der Wohnung. Das ist ein Fernseher. Also wäre es doch cool, wenn wir die Bits mit dem Fernseher hier eigentlich selber spielen könnten. Und das Problem hier ist, die LCDs, die haben da so diesen verschlüsselt. Die kann man nicht modifizieren zwischen Gerät und Bildschirm. Ich habe da mal ein bisschen rumgedattelt und dann war da noch ein Schlüssel, der rauskam. Dann habe ich da einen Man in der Mitte-Angriff machen können. Da werde ich euch jetzt nicht mehr dafür erzählen. Der Effekt war, mit so einem Chroma-Schlüssel hintergrund, wie dieser pinke, links da oben. Und rechts war das Video und dann konnte man das zusammenführen und dann kriegt man so ein Overlay. Obwohl man einen Encrypted-Link hatte. So war NETV geboren worden. Die Firma ging unter, aber dank Open Hardware war die Hardware noch da. Und deshalb konnte ich am 28 C3 in 2011 eine Präsentation darüber geben. Und wenn euch die Details interessiert, dann könnt ihr dem Link in den Folien folgen. Die gute Nachricht ist, der Vortrag wurde aufgezeichnet. Und diese Aufzeichnung spielte eine sehr große Rolle in Tims Entscheidung für seine Tätigkeiten, weiter zu Tim. Für Leute, die gut mit Akzenten sind, die so werden festgestellt haben, dass ich Australier bin. Und das ist Australien. Es gibt, vielleicht fällt euch auf, dass es was Besonderes gibt. Australien ist relativ weit weg von allem. Und Neuseeland zählt nicht. Australien ist riesengroß. Es ist so groß wie die gesamten Vereinigten Staaten. Und das bedeutet, da wir physische Atome sind, es ist sehr schwer zu anderen Orten zu kommen. Man braucht fast 24 Stunden reine Flugzeit, um hier zum Kongress zu kommen. Und fliegen macht mir nicht wirklich Spaß. Ich muss es eine Menge machen, aber es macht mir keinen Spaß. Und deswegen war ich sehr daran interessiert, wie ich an die Inhalte der Konferenzen rankomme, ohne physisch vor Ort sein zu müssen. Also wollte ich irgendwie finden, wie man Konferenzen und Usergroup Treffen aufzeichnen kann. Dann habe ich angefangen, dieses Projekt zu starten, um solche Aufzeichnungen herzustellen. Und mit diesem Setup haben wir das gemacht, um eine Konferenz aufzuzeichnen. Und das wirklich wichtige bei technischen Konferenzen sind die Folien. Man möchte also eine richtig gute Aufzeichnung der Folien haben, damit die Leute die Folien tatsächlich lesen können. Denn viele Leute machen wirklich ganz, ganz kleinen Text auf die Folien, der ansonsten sehr schwer zu lesen ist. Und am Anfang hatten wir Twin Packs, die sehr gut darin waren, VGA-Signale aufzuzeichnen. Und das war sehr gut. Und wir konnten damit sehr viele Konferenzen aufzeichnen. Und dann passierte was ganz Schlimmes. Wir mehr und mehr Veranstaltungen haben zu HDMI gewechselt. Und die analoge Aufzeichnungs-Hardware, die wir hatten, konnten wir nicht mehr verwenden. Also haben wir uns auf die Suche gemacht, ob wir irgendwelche Hardware finden, die HDMI-Signale aufzeichnen kann. Und ich habe überall gesucht und habe verschiedene Geräte gekauft. Aber es war mir nicht möglich, Hardware zu finden, die mir, die in der Lage war, mir zu sagen, was hier falsch läuft. Egal, wie viel Geld ich bereit gewesen wäre, auszugeben, ich konnte keine Hardware finden, die mir es erlauben würde, diese Probleme auf einer niedrigen Ebene zu verstehen. Und das hat mir echte Kopfschwärzen bereitet. Wir hatten ein ganz tolles Aufzeichnungssystem, aber mehr und mehr konnten wir nicht mehr die eigentlichen Sachen aufzeichnen. Und beim drüber nachdenken, bin ich dann über eine Aufzeichnung eines Vortrags gestoßen, vom 28 C3, über ein Gerät, das HDMI-Signale verarbeiten kann. Und ich habe dort mir das angeguckt und habe gedacht, hm, Bunny hat das, hat ein HDMI-Man in the Middle-Gerät gebaut, aber er hat es absichtlich so designt, dass nichts aufgezeichnet werden kann. Weil er mit verschlüsselten Daten arbeitet und wenn man mit dem Gerät das aufzeichnen könnte, wäre das in vielen Ländern illegal. Was ich also für meinen Fall jetzt brauche, sind unverschlüsselte HDMI-Signale, denn die Vortragenden wollen ja ihre Slides allen Leuten zeigen und deswegen sind sie nicht verschlüsselt. Und wenn man in das NETV reinschaut, dann sieht man einen FPGA. Und wie ich eben erwähnt habe, das konvertiert Hardware-Probleme in Software-Probleme. Und als Software-Engineur möchte ich, ja, kann ich alles mit Software lösen. Und dann habe ich mir gedacht, dann lass uns mal versuchen, genau das zu tun, was Bunny nicht machen wollte. Wie kriegen wir das dazu, HDMI aufzuzeichnen und ich habe dann eine Hardware entworfen, die HDMI zu USB überträgt. Und wir haben versucht, einige der Sachen, die Bunny gemacht haben, nachzubauen. Und da kommt dann aber dazu, ich habe gelogen, NFPGA und Verilog, die Beschreibungssprache, ist doch keine Software. Verilog verwirrt mich sehr. Als ich versucht habe, Bunny's Code für NETV zu verwenden und wir konnten nur ganz wenig Fortschritt erzielen, denn es waren hunderttausende Zeilen an Code, sehr wenige Features und nichts hat irgendwie richtig funktioniert. Und es war sehr traurig und ich hatte den Eindruck, dass Bunny eine ganz komische Person ist. Und dann habe ich hier dieses Ding gefunden, Mijen. Das ist ein sehr interessantes Projekt, das auch auf dem Kongress präsentiert wurde. Das wusste ich am Anfang nicht, habe aber dann Videos dazu gefunden. Wenn ihr euch dieses Diagramm anschaut, dann kann man mit Python befehlen, kann man diese Synchronologik beschreiben und erzeugt daraus Verilog für einen. Und es lässt es auch durch die FPGA Toolchain-Doll laufen. Wenn ihr meinen anderen Talk gesehen habt über SymbiFlow, dann wisst ihr, dass ich auch dieses Problem versuche zu beheben und damit konnten wir dann Fortschritte erzielen. Und mit diesen in dieser ganzen Umgebung, da gab es schon eine ganze Menge Tools, die im Wesentlichen das getan haben, was wir machen wollten. Und damit konnten wir diese Einzelbestandteile zusammensetzen und konnten das dann zusammensetzen zu einem kompletten Aufnahmesystem innerhalb von nur vier Wochen zu einem vollständig funktionierenden System zusammensetzen. So sind wir damit erfolgreich geworden, um Konferenzen aufzeichnen zu können. Und wir benutzen das, um verschiedene Open Source-Konferenzen aufzuzeichnen, überall auf der Welt, weil es halbwegs vernünftig erfolgreich war. Habe ich gedacht, Leute beim Kongress würden vielleicht Interesse haben zu verstehen, wie es funktioniert. Und aus irgendeinem Grund haben sie den Talk sogar akzeptiert. Also beim 33C3 habe ich meinen ersten Kongress-Talk gegeben, den ersten überhaupt. Und der wurde aufgezeichnet, den könnt ihr euch anschauen. Und der Vortrag beschreibt, wie wir dieses Aufzeichnungs-Setup genau aufgebaut haben, inklusive Python und allem. Und ich war hier beim 33C3, und Bunny war auch hier. Und Bunny hatte sich natürlich auch nicht auf die faule Haut gelegt für die letzten sieben Jahre. In diesen sieben Jahren, seit 2011, was da passiert ist mit Atomen, die sind dann EOL, End of Life, Ende der Lebenszeit. Diese Komponenten mit den roten Pfeilen, die kann man gar nicht mehr kaufen. Nicht mal mehr die originale LEDs, nicht die Speicherchips und auch nicht die CPU, die wird gar nicht mehr produziert. Da wäre also in der Version 2 gefragt, aber Overlay ist schon ziemlich veraltet. Aber leider ist das illegal zu replizieren so. Zum Beispiel chinesisch in Englisch zu konvertieren. Und da müsste man die Kryptografie brechen von diesem Link. Und das ist nicht legal. Also haben wir immer noch das Problem, dass wir irgendwie mit dem Video-Signal etwas anfangen müssen. Jetzt habe ich es kaputt gemacht. Also wir überspringen das Video. Das Problem mit dem Overlay hier ist eben, dass es illegal ist wegen der DMCA. Und das Internet ist kaputt, wir kommen jetzt nicht mal zur nächsten Folie. Hier sind wir. Am 21. Juli 2016, da ist etwas passiert. Hier ist das Team vom EFF. Die haben da eine Anklage gemacht gegen die US-Regierung wegen der Absatz 1201 in der DMCA. Da ging es da eigentlich genau um dieses Problem. Also durfte ich jetzt auch hier auf die Videodaten zugreifen und versuchen zu entschlüsseln. Hier ist der erste Prototyp von NETV2. Aus einer PCI-Karte könnte man gut irgendwo verstecken. Und dann 33C3 hatte ich da ein paar Beispiele dabei. Und wollte dann ein bisschen Benutzervalidierung durchführen und schauen, ob das Leute überhaupt brauchen wollen. Und wir waren beide da, an 33C3. Da hatten wir eine kleine Diskussion, eine Besprechung, ob wir da irgendwas so ein bisschen zusammen machen wollen. Und da kam es hinaus, dass Hacker und kleine Boards sind, keine gute Kombination mit sehr kleinen Dimensionen, was schwierig, um eine Community involvieren zu können. Aber das war gut, ich musste da noch mal von vorne beginnen. Aber genau das war gut, weil ich kam zum Kongress und ich fand da heraus, ich wollte das falsche bauen und jetzt kann ich da die Chance nutzen, konnte ich die Chance nutzen und hatte hier noch etwas korrigieren können, bevor ich da mit der Massenproduktion überhaupt angefangen hätte. Zurück noch mal einen neuen Entwurf gemacht. TV2 MWP, das minimale Produkt. Das wurde dann eine ganze Größe, Standardgröße von einer PCI-Karte mit Ethernet und konnte SD-Karten lesen, wo man zum Beispiel Linux draufladen könnte. Also Vielzeug, das man eigentlich gar nicht wirklich benutzen müsste für die grundsätzliche Funktionalität, aber super für die ganze Community, die da vielleicht noch etwas mehr damit machen wollten. Man hat auch noch eine Hülle dazu entwickelt, damit Leute nicht unbedingt da schon irgendwie rumfritzen müssten. Also man sieht hier gar nicht, dass das eine PCI Expresskarte ist, sondern man kann einfach sein Zeug rein tun und dann funktioniert alles. Die Hardware ist komplett hackbar. Mit einer Standardart, die das Board zu befestigen, wir haben hier noch einen großen Teil hier, der noch leer ist, das war Absicht. Und auch die ganze Testinfrastruktur hatten wir geöffnet. Also konnte auch die Community hier den Test selber durchführen. Hatten hier Xclave ein ganzes Framework dazu, das entwickelt wurde. Jetzt konnten wir es mit Python betreiben. Und dieser Xclave Comic ist cool, ich finde ihn toll. Wie kommt es, dass du fliegen kannst und antwortet Python. Und Tim hat mich da überzeugt, mit LightX das auszuprobieren. Ich hätte das schnell zusammenbauen können und ja, danke Tim, das war super. Und ja, dann Python. Da kommt ein Stacktrace, keine Ahnung, was muss ich jetzt hier tun? Ich bin ein Hardware-Typ. Also, hm, verflucht Tim, wieso? Aber wieso ich jetzt dabei geblieben bin? Auf dieser Folie sieht man, wie der FPGA ausgenutzt wird. Links ist das propriertäre Tool. Und rechts mit MiGen. Und links, da sieht man sehr viel für Speicher und ganz wenig für Logik. Und rechts ist eigentlich die ganze Applikation, was alles in dieser FPGR läuft. Also, man sieht hier links, da gibt es ganz viel Arbeit, nur um den Speicher zu halten. Und rechts, da haben wir noch ganz viel Platz. Also, als Hardware-Person habe ich da gesehen, ja, das ist wichtig. Also, ich will dieses Problem lösen, Atome gehören nicht Menschen. Und habe gemerkt, ja, es ist vermutlich einfacher, Python zu lernen, als Leute davon zu überzeugen, mehr zu bezahlen für ein Produkt. Ein anderer kleiner Vorteil war, dass mit Leitex und MiGen konnte ich das Ganze in 10 Minuten zusammenbauen, anstatt in 1,5 Stunden, 3,4 Stunden mit Vivado, obwohl die etwas besser geworden sind. Momentan haben wir eine Crowdfunding-Kampagne. Da könnt ihr hingehen, falls ihr interessiert seid und mit dem rumspielen wollt. Hat einen klassischen Modus für den Overlay, so wie eigentlich vorher. Und dann gibt es noch den Libre-Modus. Wenn man eben so Konferenzen aufnehmen will oder Rechte hat, an dem Video, das nicht verschlüsselt ist, kann man das in eine Videoprozessierungs-Pipeline einbauen. Ich bin da zum Kongress gekommen mit mehreren von diesen Boards. Und vielleicht will da euch Tim, einer von diesen Boards geben, etwas über Python beibringen, falls das euch interessieren könnte. Und jetzt sehen wir auch noch Interaktion zwischen MiGen, die uns damit helfen. Auf'n, super! Aber... Nichts ist wirklich frei kostenlos im Leben. Abstraktionen sind sehr leistungsfähig, aber sie kosten auch was. Python ist toll, ist sehr toll, um Sachen aus Komponenten zusammenzubauen. Und der Grund, warum ich sehr glücklich, warum ich sehr erfolgreich war mit HDMI to USB, dass ich relativ einfach in verschiedenen Konfigurationen Sachen aus Teilen zusammensetzen konnte. Ich konnte die Leute, ich konnte spezialisieren, die Leute, die in ganz besonderen Reifen brauchten, die haben mir einen tollen Reifen gebaut. Und ich konnte dann tatsächlich den Reifen bei mir einfach integrieren. Und genauso besondere Sitze, jemand hat einen tollen Sitzdesign, den kann ich bei mir einfach einbauen. Das ist für mich extrem praktisch, der nicht so viel Zeit hat, der sich auch nicht um diese Details kümmern möchte. Das bedeutet Effizienz, wir können diese Komponenten sehr viel besser zusammensetzen und wir können auch bestimmte Sachen einfach weglassen, die wir nicht brauchen. Und dadurch wird das Ganze sehr viel effizienter, man braucht diese ganzen anderen Sachen nicht. Aber es gibt Kosten und die Kosten durch Python, Python funktioniert gut, um Sachen aus Komponenten zusammensetzen, aber es gibt natürlich ein Impedanzproblem zwischen Python und Hardware. Python ist nicht wirklich designed, um Hardware zu bauen. Bunny als Hardwareperson möchte vielleicht das bestimmte Sachen existieren, weil er erwartet, dass es so da ist. Eine Sache über die sich Bunny immer beschwert, in Mijen gibt es 0 oder 1. Aber in der Hardware ist es in Wirklichkeit ein bisschen kompliziter. Es gibt Unbekannt oder Hochohmig. In Hardware wird mehr modelliert als zwei Zustände. Der Grund dafür ist, dass das war, wie das Signal in Theorie aussieht. So sieht es in Wirklichkeit aus, wie es in der echten Hardware aussieht. Und wenn das so aussieht, dann sind die Sachen, von denen man erwartet, dass sie funktionieren, die sind in Wirklichkeit anders. Zwei Zustände existieren nur in Teil der Zeit. Und worum es wirklich geht, ist genau das, tatsächlich einzubeziehen und zu benutzen. Was Python uns ermöglicht, ist, dass Bunny sich genau um solche Aspekte kümmern kann. Im Moment kann er tatsächlich die Hochohmig und unbekannt Zustände nicht kodieren, aber er kann einen ganz tollen Reifen bauen, den der Rest der Community dann verwenden kann. Und er kriegt ganz viel geschenkt, auch wenn das, was für ihn wichtig ist, dann etwas schwerer ist. Insgesamt ist es aber sehr viel effizienter. Es gibt ein paar weitere Erkenntnisse. Zum Beispiel, wie gut Leute Sachen testen. Wenn man einen Code umsonst bekommt, dann geht man davon aus, dass er nicht getestet wurde. Als ich Hardware-Design gelehrt habe, wenn man eine Schaltung hat, die blinken soll und es blinkt nicht, dann liegt es nicht daran, dass die Hardware kaputt ist, sondern das Design ist falsch. In 99,99% der Fälle hat man das falsch zusammengesetzt. Wir haben eine Million Exemplare eines Geräts hergestellt, und es war tatsächlich genau ein Teil, wo tatsächlich das Bauteildeffekt war. In der Software ist es ein bisschen anders. 90% der Zeit ist es der eigene Code, der falsch ist. 10% der Zeit ist es, dass in der Library ein Problem besteht. Also der Reality-Check ist, wenn man ein Produkt tatsächlich liefern will, ein Hardware-Produkt, bei dem es sehr schwierig ist, Sachen zu reparieren, zu patchen, dann muss man sehr viel testen. Für NETV haben wir fünf Monate extra nur fürs Testen im Projektplan vorgesehen. Wenn ich, was ich versucht habe, die schlechtesten Geräte zu finden, damit ich gucken kann, ob selbst unter ganz schlimmen Situationen immer noch alles richtig funktioniert, das für jeden Test. Und wenn man einen elektronischen Schalter einbaut, dann geht es natürlich um die Übertragungsleitung, die da verändert wird, und damit hat man ganz andere elektrische Eigenschaften. Ich habe dann erwartet, dass, wenn ich die Geräte, die Nullserie baue, das ein Großteil funktioniert, ungefähr 40% haben noch nicht mal gebotet. Es gab ein Corner-Case, ein Problem, das uns zu diesem Fehler geführt hat. Und dadurch, dass wir fünf Monate uns Zeit gelassen haben, um die Sachen tatsächlich zu finden, zu identifizieren, konnten wir das vor der Massenproduktion problemen. Die gute Nachricht ist, dass wir mit den fünf Monaten Leuten viel Ärger erspart haben für die Zukunft, aber wir mussten eben auch sehr viel Arbeit da reinstecken. FOS, Free and Open Source, ist toll, aber Xilinx hat über 3.500 Mitarbeiter, hat sehr viel Umsatz und die kümmern sich darum, dass das, was sie da an Modulen für ihre FPGAs produzieren, dass das 99,99% korrekt ist. Andererseits, Alpha Max, die Firma, die den NETV produziert, hat ein Angestellten, hat knapp 80.000 Dollar Jahresumsatz, hoffentlich wird er im Januar ausgeliefert. Tut mir nicht weh, ich hoffe, dass Alpha Max etwas länger aushält, als der Gerichtsprozess um die DNCA. Es ist sehr schwer, alle diese Sachen einzubeziehen, wenn man so ein Gerät auf den Markt bringen will. Und den ganzen Code tatsächlich zu checken, der dann technisch und auch legalerweise richtig funktioniert. Wir haben da noch diese Erkenntnis und noch eine weitere. Wie Bunny gesagt hat, ist es schwierig, Leute davon zu überzeugen, dir Geld zu geben für Atome, vor allem, wenn man ehrlich ist, was man dann eigentlich damit produziert. Als Bunny NETV gemacht hat, hat er das vor allem mit Beziehungen in der Firma gemacht, aber heutzutage ist das mit Crowdfunding auch viel einfacher möglich. NETV II wurde Crowdfunded, der HDMI USB, hatten wir da auch ein bisschen Crowd gefundet mit anderen Projekten. Da kommen verschiedene Leute zusammen mit denselben Einstellungen und gibt ihnen die Möglichkeit, Geld dahin zu stecken, wo sie es wirklich wollen. Aber es ist interessant, dass man auch schaut, wer, wen zieht man eigentlich an? Anstatt, dass wir hier nur Softwareentwickler oder Entwickler an sich anpeilen, dass das funktionierte da mit dem HDMI zu USB, die konnten dann auch mal testen vor einer Konferenz, denen konnte man einfach so eine Platine geben, das gehört ja zum Setup-Teil. Und Bunny will eigentlich etwas ausliefern, dass man einstecken kann und das dann funktioniert jedes Mal, wenn man es einsteckt und das sind zwei verschiedene Einstellungen. Und ich habe auch keine Ahnung, wie man so eine schöne Kiste darum herum baut. Und Bunny weiß halt, wie das geht, außerdem, ja, die machen mir ein bisschen Angst. Also es ist wichtig, schad euch die Community an und gebt der Community auch das, was sie wollen. Da sieht man eben mit dem HDMI zu USB, das funktionierte mit den Entwicklern so als Platine, aber wenn wir da ein bisschen auf den Konsumentenmarkt einziehen wollen, dann brauchen wir etwas Polierteres. Die vierte Lektion ist, dass ja, irgendwas zu öffnen braucht viel Zeit und Geduld. Und Open Source Software und Hardware braucht viel Zeit. Zum Beispiel denkt man da über die Mobiltelefone. Ihr erwartet da, dass jedes Jahr ein neues kommt oder für Weihnachten. Und Leute denken, woher die haben hier aber ganz viel investiert. Und die Tatsache ist, die haben da mehrere Jahre mit mehreren Teams, die in einer Pipeline arbeiten. Und so kriegen das große Firmen hin, dass man dann jedes Jahr eben etwas Neues rausbringen kann. So funktioniert das, wenn viel Geld herum ist in diesen Close Source Firmen. Und Open Source, ja, da ist man glücklich, wenn man einmal da was rausbekommt. Wenn man jetzt geht und sagt, ja, ich will jetzt hier ein Telefon bauen. Und das Problem ist, sobald man das fertigbekommen hat nach mehreren Jahren, dann sind alle anderen schon viel weiter und die wollen dann gar nicht mehr das, was du gebaut hast. Also, anstatt dass man hier so dieses glamouröse Messergefühl hat, ist das mehr so, als ob man durch einen Wald spaziert. Es braucht halt Zeit. Das kann man nicht forcieren. Es stellt sich heraus, dass dieser Art von Community der Leute, die da so ein Video-Overlay machen, tun oder eine Konferenz aufnehmen wollen, bei denen muss man da nicht so mit dem Konsumentenzyklus rechnen. Also, wir haben hier sieben Jahre gebraucht und die sind dann nicht einfach weggelaufen und haben sich was anderes gekauft. Es braucht Zeit und da ist es halt auch wichtig, dass man das richtige Projekt auswählt. Es braucht auch Geduld. In Software ist es meistens so, ja, wenn es für mich funktioniert, dann ist das super. Und wenn es dir nicht gefällt, ja, dann gib mir noch was du da gemacht hast. Das ist dann funktioniert und du kannst mich da nicht irgendwie dazu verdornen, das zu fixen. Das ist eben auch Teil der zwei Klausel-BSD-Lizenz. Das kann man nicht für Hardware tun. Da kann man nicht draufschreiben, ja, wenn es nicht funktioniert, dann kannst du es nicht zurückgeben. Da gibt es eben Konsumentenschutz-Gesetze. Die Situation ist sogar schlimmer, wenn ich dir einen Toaster mit einem Slot verkaufe und dann findest du aber in der Verpackung ein Zwei-Slot-Toaster, wo ein Slot einfach zugeleimt wurde, dann würdest du dann sagen, ja, ich sende das zurück, weil das funktioniert ja nur zur Hälfte. Aber in Software, wie oft habt ihr das schon mal erlebt, oder ihr holt euch eine Bibliothek und dann funktioniert die Hälfte irgendwie nicht so ganz. Das ist halt irgendwie Standard. Da haben wir uns daran gewöhnt und das braucht auch viel Geduld, weil da hat man dann Features, die funktionieren gar nicht von Anfang an, die muss man dann halt irgendwie selber noch machen. Es ist also ziemlich fruchtentflößend, Hardware mit Open-Source-Software da irgendwie auszuliefern. Was ist denn, wenn jetzt ein Software-Bug hier ein funktionelles Problem im Produkt macht und da habe ich schon mal Schweiß gebadet, aufgewacht und mich da gefragt, oh, das muss an aber irgendwann mal noch gefixt werden. Trotz allem dem, trotz allem dem, ich liebe immer noch Hardware zu bauen und das liegt wahrscheinlich daran, dass ich aus meinen Fehler nicht wirklich gut lerne. Und wir werden sehen, was sich daraus ergibt. So, und Tim hat noch eine letzte Lektion. Es gibt zwei unterschiedliche Perspektiven aus der Sicht eines Menschen, der Hardware macht und eines anderen Menschen, der sehr viel mehr bereit ist, seine Humanität zuzugeben. Das Interessante an CCC ist, dass es uns beide zusammenbringt. Wir haben beide Vorträge hier bei dieser Konferenz gehalten, tatsächlich sehr gleichartige Vorträge gehalten und jetzt arbeiten wir zusammen und deswegen möchten wir uns bedanken mit einem großen Applaus bei den Organisatoren und die Sachen, an denen wir arbeiten, würden nicht so gut sein, wie sie sind ohne diese Konferenz. Vielen Dank. Vielen Dank, dass ihr uns zusammengebracht habt und alle, die hier auch immer teilnehmen und das erste Mal, wo wir uns getroffen haben, warst du tatsächlich nur als Teilnehmer dabei. Und wir haben jetzt Zeit für Fragen. Vielen Dank an die Vortragenden, dass sie uns hier einen Grund geben, alle gemeinsam hier zu sein. Wir haben hier Zeit für Fragen. Um kurz zu erklären, was eine Frage ist, ein oder zwei kurze Sätze, mit einem Fragezeichen am Ende, nicht eure Lebensgeschichte, bitte. Es gibt hier eine ganze Reihe von Mikrofonen. Auch ganz hinten haben wir Mikrofonen ganz hinten. Frage Mikrofon Nr. 1. Und bitte sagt, an wen ihr die Frage richtet, sonst beantworten wir die beide. Kurze Unterbrechung noch, bitte ganz nah ans Mikrofon. Magst du Hardware oder Software? Was magst du mir ab? Ich mag Hardware. Ja, ich bin echt ein Hardware-Typ. Wie sagt man? Es gibt da wortwörtlich irgendwie so eine chemische Reaktion, die ich durch Hardware in meinem Gehirn erleide. Wenn man mir ein Stück Hardware gibt, dann geht mein Puls hoch und ich kriege schwitzige Hände, das finde ich einfach super. Das Problem ist, dass in der Realität es als Hardware nerd, wenn man da Hardware rausgibt ohne Software, dann sind es einfach so Türstopper, die bringen dann nichts. Also ist Software halt so ein notwendiges Übel, das man braucht, um Hardware nutzbar zu machen. Die gute Sache ist, Hardware sind Atome, da sieht man das Problem physisch, oder dieses Signal ist nicht gut. Das ist dann möglich. Software ist brutal komplex, da kann man Stunden damit verbringen und man findet nie den Barg. Aber ich habe da auch viel Respekt dafür, was die Software-Leute tun und versuche mich da auch mit solchen Software-Leuten zu umgeben, in dunkelnächten, wenn ich meinen Code versuche, zum laufen zu kriegen. Und denke auch, dass die Leute, die die Hardware kaufen, auch ein besseres Erlebnis haben sollten, dank der Software. Wir nehmen auch Fragen aus dem Internet an, aber da sind im Moment keine. Hier eine weitere Frage von Mikrofon Nummer 1. Frage an beide. Wenn wir ein Projekt oder ein Produkt-Design, das Hardware-basiert ist, würde dir empfehlen, dass ein bisschen länger haltbar ist, dass sich auf eine andere Architektur portieren lässt. Würde dir empfehlen, ein FPGA empfehlen oder doch lieber ein System on the Chip, das sehr günstig ist, das hilft das FPGA, für ein langlebiges Produkt zu sorgen. Ich gebe eine Präsentation zu meiner Theorie über FPGA-Entwicklung. Und die erste Erkenntnis ist, dass FPGA ist eigentlich so die letzte Option. Wenn man es mit Software auf einer CPU machen kann, sollte man es lieber so tun, weil das FPGA ist eigentlich so die letzte Option. Wenn man es mit Software auf einer CPU machen kann, sollte man es lieber so tun, weil es ist so viel einfacher und viel schneller, die Software zu entwickeln. Und man kann da auch viel produktiver sein mit dem. Es gibt halt Probleme, die man nicht mit einer CPU knacken kann. Und man ist da auch etwas, die mitiert in der Flexibilität. Ich hoffe, dass Projekte wie SymbiFlow, der FPGA-Entwicklung ein bisschen einfacher machen oder so einfach wie Software, und dann ändert das vielleicht. Aber für den Moment ist das FPGA wirklich nur zu benutzen, wenn man es benutzen soll oder muss besser als ein System on a chip. Es gibt da auch ein paar Chips, wo man dann sagen kann, okay, brauche ich jetzt vielleicht lieber ein FPGA und das man vielleicht noch etwas flexibler was Input-Output anbelangt. Tim ist da richtig, was ich da noch zur Langlebigkeit sagen würde, ist eben die CPU, die kann man nicht mehr kaufen, die ich da gebraucht habe. Also jetzt haben wir auf ein Raspberry Pi umgestellt und dann löst jemand anders das Systemproblem. Heutzutage kann man immer noch alte FPGAs kaufen und alten Coat da auflaufen lassen. Diese Hardware-Beschreibung, die können halt ewig noch weiterleben und da kann man nach ohne andere Teile überleben. FPGAs haben halt auch ein End-of-Life, aber der Horizont da ist viel weiter weg als bei herkömmlichen Chips. Eine weitere Frage per Microphone Nr. 1. Ich habe Hinweise gesehen, dass man im Zusammenhang mit der Finanzierung und mit der Nachhaltigkeit von bestimmten Tätigkeiten kann Open-Hardware da helfen. Was sind eure Gedanken dazu, wie Open-Hardware so ein besseres Weltbeitrag beitragen kann? Ich möchte da klarstellen, Open-Hardware ist für mich ein Hobby. Ich habe da eine gut bezahlte Software-Arbeitstelle für mich, also habe ich da eine ganz andere Perspektive zu Open-Hardware als Bunny, der sein Leben davon bezahlen muss, also Bunny. Ich verdiene auch kein Geld mit Open-Hardware, ich gebe einfach weniger Geld aus. Ich kann mich dann mit dem Durchkriegen mit den kleinen Marschen auf Open-Hardware. Wir haben hier so ein bisschen der Kontrast zwischen der Finanzierung und der offenen Hardware und wenn man finanziert wird, dann hat man eine große Idee und entweder gibt man da Vollgas oder man gibt es auf. Da macht man dann Versprechen, die riesig sind. Da haben wir ganz viele Beispiele gesehen, dass das gar nicht funktioniert oder die versprechen da etwas und das wird dann nicht gehalten. In Open-Hardware haben wir mehr so hobbyartige Projekte, die sterben da nicht, aber sie werden zu Zombies. Also ist die Frage, hier kann man hier einen Impuls der Großgenugis generieren aus der Community hinaus, um das zu tragen und das braucht viel Energie, um hier eine Community aufzubauen, mit Leuten zu sprechen, sie an Bord zu holen. Das zu machen, das ist ein sehr zeitintensiver Prozess, aber den finde ich auch sehr lohnenswert. Es ist ein bisschen Äpfel und Birnen vergleichen. Etwas, was ihr hier gesehen habt, ja, wir haben kein Open-Source-Telefon. Wir wollen zwar alle irgendwie eins, aber das kriegen wir nicht, weil das ist halt so ein großes Investment. Es geht gar nicht genug Geld, wir Open-Hardware zu machen, dass man da überhaupt so ein Telefon entwickeln könnte. Es gibt da gewisse Sachen, die man mit Open-Hardware gar nicht tun kann, weil die Ressourcen nicht existieren. Mikrofon Nummer zwei. Ich war überrascht, dass das Rivaldo-Tooling so viel schlechter als das Open-Source-Tooling ist. Was ich in der Vergangenheit beobachtet habe, ist, dass die proprietären Tools besser und zuverlässiger sind. Habt ihr geschaut, warum dieser Unterschied bei euch so war? Ja, wir haben da ein paar Theorien. Es gibt viele verschiedene Theorien dazu. In meiner Meinung nach, wenn man eine Firma ist wie WixiLex, dann optimiert man für die Leute, die die FPGAs kaufen. Das sind nicht Leute wie ich oder Bunny, die ein wenig Volumen hier einnehmen. Die Firma, die kümmern sich dann um Leute, die hunderte von Millionen mit zu einer FPGA machen. Und die Leute da, denen geht es vielleicht etwas weniger darum, wie groß der Kern da ist, sondern mehr darum, dass man eine höhere Verfügbarkeit hat. Und extra Sachen, die da ein bisschen die Checkboxen abklicken. Was da alles eigentlich rein reinkommen sollte. Wir können da nur die Sachen bauen, die wir wirklich wollen. Und die andere Sache noch zu Python Zeugs. Wenn das rauskommt, dann taucht das Nebenware-Log auf. Das bedeutet, dass die FPGA Toolchain gar nicht rausfinden muss, dass das Zeug nicht benutzt wird und herausgenommen werden kann. Und das hilft sich ja auch, diese Preprozessierung. Lightram ist nicht unbedingt besser oder zuverlässiger als Mink, aber definitiv kleiner. Und hat definitiv genug Features, um einige Produkte zu auszuliefern. Und es ist auch interessant, dass eine Firma, die mehr Geld damit verdient, dass du größere FPGAs kaufst. Ja, das ist klar. Nächstes ist gratis. Also du kriegst die Software gratis, du zahlst dann mit der Hardware dafür. Wir haben leider keine Zeiten für weitere Fragen mehr, aber ich bin mir sicher, dass die beiden noch weiterhin für Fragen zur Verfügung stehen während der Konferenz. Vielen Dank an die beiden Vortragenden.